SPB Git forge
spboucher.ai ↗

spb/job-ka

Public
226commits 1branches 0releases
37.5 MBsize
maindefault branch
9 h agolast push
HTML 82.1% Python 14.6% TypeScript 1.9% CSS 1% JavaScript 0.5%
7.5 KB
View source Raw Blame History

# 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 : <chemin/nom_du_fichier>
# Rôle    : <description en une ligne>
# Créé    : <YYYY-MM-DD>   Modifié : <YYYY-MM-DD>
# =============================================================================
javascript
/**
 * =============================================================================
 * Job·Ka — Groupe KA
 * Auteur  : Simon-Pierre Boucher
 * Contact : contact@spboucher.ai
 * Fichier : <chemin/nom_du_fichier>
 * Rôle    : <description en une ligne>
 * Créé    : <YYYY-MM-DD>   Modifié : <YYYY-MM-DD>
 * =============================================================================
 */
  • 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 <contact@spboucher.ai>"
    • 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)