# CLAUDE.md — Job·Ka > Agrégateur d'offres d'emploi québécoises du **Groupe KA** (groupe-ka.com). > Fichier d'instructions pour Claude Code. Lis-le en entier avant toute action. --- ## Règle nº 1 — En-tête d'auteur OBLIGATOIRE **Chaque fichier créé ou modifié** (code, script, config, doc, migration, test — sans exception) doit commencer par l'en-tête d'auteur suivant, adapté à la syntaxe de commentaire du langage : ```python # ============================================================================= # Job·Ka — Groupe KA # Auteur : Simon-Pierre Boucher # Contact : contact@spboucher.ai # Fichier : # Rôle : # Créé : Modifié : # ============================================================================= ``` ```javascript /** * ============================================================================= * Job·Ka — Groupe KA * Auteur : Simon-Pierre Boucher * Contact : contact@spboucher.ai * Fichier : * Rôle : * Créé : Modifié : * ============================================================================= */ ``` - Aucun fichier sans cet en-tête ne doit être commité. Point final. - Si tu modifies un fichier existant sans en-tête : ajoute-le. - Si tu modifies un fichier avec en-tête : mets à jour la date `Modifié`. - Voir la **section 17** pour la politique complète d'attribution. --- ## 2. Contexte du projet **Job·Ka** agrège les offres d'emploi **directement depuis les pages carrières des employeurs québécois** (pas depuis Indeed/Jobillico). Même philosophie que les autres plateformes du Groupe KA (Lou·Ka, Immo·Ka, Vrai-Prix, ValoPlex, Auto·Ka, Fabri·Ka, Food·Ka) : 1. **Zéro boîte noire** — chaque offre est traçable à sa source, avec URL originale. 2. **Données réelles à la source** — connecteurs automatisés, aucune saisie manuelle. 3. **Indépendance** — aucun employeur ne paie pour être mis en avant. Architecture cible : **un connecteur = un employeur** (ou une plateforme ATS partagée : Workday, Lever, Greenhouse, SmartRecruiters, BambooHR, etc.), un scheduler qui resynchronise jour et nuit, une normalisation vers un schéma unifié. --- ## 3. Règle nº 2 — Étudier le dépôt Lou·Ka AVANT tout connecteur **Avant d'écrire ou de modifier le moindre connecteur**, tu dois explorer le dépôt Lou·Ka et produire un résumé de ce que tu as compris. Job·Ka doit réutiliser les patterns éprouvés de Lou·Ka, pas les réinventer. À étudier obligatoirement dans Lou·Ka : - [ ] Structure d'un connecteur : interface commune, classe de base, conventions de nommage - [ ] Schéma de données normalisé et pipeline de normalisation - [ ] Gestion des erreurs, retries, timeouts, rate limiting par source - [ ] Scheduler / orchestration des resynchronisations - [ ] Déduplication des annonces entre sources - [ ] Détection et retrait des annonces expirées - [ ] Stockage (BD, index, cache) et exposition API/frontend - [ ] Logging et monitoring des connecteurs (taux de succès, fraîcheur) **Livrable avant de coder :** un rapport `docs/audit-louka.md` (avec en-tête d'auteur, règle nº 1) résumant l'architecture de Lou·Ka et le plan d'adaptation pour Job·Ka. Attends la validation de Simon-Pierre avant d'implémenter. --- ## 4. Schéma de données cible (offre d'emploi) Adapte les noms au style hérité de Lou·Ka, mais chaque connecteur doit tenter d'extraire : - `id_source` — identifiant unique chez l'employeur/ATS - `employeur` — nom de l'entreprise - `url_offre` — lien direct vers l'offre originale (obligatoire, zéro boîte noire) - `titre` — titre du poste - `description` — texte complet (HTML nettoyé) - `lieu` — ville, région, code postal si dispo - `mode_travail` — présentiel / hybride / télétravail - `type_emploi` — temps plein / partiel / contractuel / stage / saisonnier - `salaire_min`, `salaire_max`, `salaire_unite` — nombres, pas des strings (transparence salariale = différenciateur clé) - `avantages` — liste si disponible - `exigences` — scolarité, années d'expérience, langues - `date_publication`, `date_limite` — dates ISO normalisées - `categorie` — taxonomie interne (TI, santé, construction, etc.) - `ats` — plateforme source (workday, lever, custom, etc.) - `scrape_timestamp` — horodatage de la collecte Règles de normalisation : dates en ISO 8601, salaires convertis en $/h et $/an, géocodage adresse → lat/lng (réutiliser le pipeline Nominatim + cache de Lou·Ka, 1 req/s max). --- ## 5. Conventions de développement - Langue du code : anglais pour les identifiants, français pour la doc et les commentaires métier. - Un connecteur = un module isolé, testable seul (`make test-connector NAME=x`). - Jamais de scraping agressif : respecter robots.txt quand raisonnable, throttling par domaine, User-Agent identifiable `JobKaBot/1.0 (+https://www.job-ka.com; contact@spboucher.ai)`. - Aucun secret en dur dans le code : `.env` uniquement, jamais commité. - Chaque PR/commit : message clair en français, en-tête d'auteur vérifié (règle nº 1). - Avant de coder une fonctionnalité : présenter le plan et attendre validation. --- ## 6. Déploiement — node m3u96a + ngrok **Environnement de déploiement :** - Nœud cible : **`m3u96a`** - Exposition publique : **ngrok** avec le domaine réservé **`www.job-ka.com`** Procédure attendue : ```bash # 1. Sur le node m3u96a — build et démarrage du service # (adapter au stack hérité de Lou·Ka : pm2, systemd, docker compose…) # 2. Tunnel ngrok vers le port de l'app (ex. 3000) ngrok http --domain=www.job-ka.com 3000 ``` Règles : - Le tunnel ngrok doit être supervisé (pm2/systemd) pour redémarrer seul. - Vérifier après chaque déploiement : `https://www.job-ka.com` répond, healthcheck OK, connecteurs planifiés actifs. - Documenter toute variation dans `docs/deploiement.md` (avec en-tête, règle nº 1). - Ne jamais exposer d'interface d'admin ou de BD via le tunnel public. --- ## 7–16. Sections réservées Réservées pour les futures politiques (monitoring, SEO, alertes courriel, API publique, etc.). Ne pas supprimer la numérotation : la **section 17** doit rester la section 17. --- ## 17. Politique d'attribution d'auteur 1. **Auteur unique du projet : Simon-Pierre Boucher** (`contact@spboucher.ai`). Toute contribution générée par Claude est réputée réalisée pour le compte de l'auteur. 2. L'en-tête d'auteur (règle nº 1) est **non négociable** : il s'applique aux fichiers de code, scripts, configs, docs, tests, migrations, workflows CI, Dockerfiles et Makefiles. 3. Les métadonnées de projet doivent refléter l'auteur : - `package.json` → `"author": "Simon-Pierre Boucher "` - `pyproject.toml` → `authors = [{name = "Simon-Pierre Boucher", email = "contact@spboucher.ai"}]` - `LICENSE` et `README.md` → copyright « © Groupe KA — Simon-Pierre Boucher » 4. Configuration git du dépôt : ```bash git config user.name "Simon-Pierre Boucher" git config user.email "contact@spboucher.ai" ``` 5. Toute page publique de Job·Ka affiche dans le pied de page : « Une plateforme du Groupe KA » avec le contact `contact@spboucher.ai`. 6. **Vérification automatique** : ajouter un hook pre-commit (ou étape CI) qui rejette tout fichier sans l'en-tête d'auteur. Ce hook porte lui-même l'en-tête. --- *Dernière mise à jour : 2026-08-17 — Simon-Pierre Boucher (contact@spboucher.ai)*