Règles Cursor pour les ingénieurs du recrutement

Un fichier Cursor .cursorrules calibré pour les patterns de travail d’un ingénieur du recrutement interne (ou d’un responsable recruiting-ops qui code) : construire des intégrations ATS, écrire des serveurs MCP pour les outils de recrutement, automatiser l’intake, et connecter Ashby, Greenhouse, et Lever au reste de la stack de recrutement. L’artefact est un fichier unique — apps/web/public/artifacts/cursor-rules-recruiting-engineer/.cursorrules — que vous déposez dans le répertoire .cursor/rules/ de votre projet.

La propriété définissante du code de recrutement est que chaque ligne touche des données sur de vraies personnes qui ne savent pas que vous existez. La journalisation d’audit, la sécurité contre les biais, la conformité juridictionnelle, et le consentement ne sont pas des contraintes optionnelles — elles sont la différence entre un ingénieur du recrutement et une procédure d’application. Les règles de ce bundle encodent cette réalité afin que l’assistant IA de Cursor ne suggère pas le type de code qui fait condamner un cabinet ou nuire à un candidat.

Quand utiliser

Vous êtes un ingénieur du recrutement ou un responsable recruiting-ops qui écrit du code d’intégration (Python, TypeScript) contre un ATS, un outil de sourcing, ou un fournisseur d’évaluation. Votre équipe livre au moins quelques scripts par trimestre qui touchent des données de candidats. Cursor est votre IDE.

Quand NE PAS utiliser

• Vous n’avez pas de rôle d’ingénieur du recrutement dédié et vos « intégrations » sont des Zaps installés par le fournisseur. Les règles supposent qu’un ingénieur est dans la boucle et rédige du code ; elles n’aideront pas un setup configuration uniquement.
• Vous construisez un produit de recrutement externe (un ATS, un fournisseur d’évaluation, etc.). Les règles sont calibrées pour le consommateur des API de recrutement, pas le constructeur. La posture de conformité est différente.
• Votre cabinet n’a aucun candidat dans l’UE, en Californie, à New York, ou en Illinois et il est peu probable d’en avoir. Plusieurs règles du bundle référencent la NYC Local Law 144, l’Illinois AVDA, le RGPD, et le CCPA — elles ne sont pas nuisibles dans d’autres juridictions mais ne sont pas load-bearing non plus.

Configuration

1. Copier l’artefact. Récupérez .cursorrules du bundle ci-dessus (ou téléchargez le zip) et déposez-le dans le répertoire .cursor/rules/ de votre projet. L’indicateur Project Rules de Cursor devrait afficher que les règles sont actives à la prochaine ouverture de fichier.
2. Ajuster la liste des outils. Les règles couvrent Ashby, Greenhouse, Lever, Gem, hireEZ, et les outils de recrutement basés sur MCP par défaut. Réduisez ou étendez les sections spécifiques aux outils pour correspondre à votre stack — une équipe qui n’utilise qu’Ashby + Workable devrait supprimer les sections Greenhouse/Lever plutôt que de conserver des conseils obsolètes que le modèle doit peser.
3. Renseigner la destination d’audit. Les règles exigent que chaque lecture et écriture produise une entrée d’audit, mais ne dictent pas où. Modifiez la section « Piste d’audit » pour pointer vers votre destination de logs (Datadog, BigQuery, une table d’audit personnalisée) afin que les suggestions de Cursor référencent le vrai appel.
4. Définir le gestionnaire de secrets. Les règles interdisent les credentials inline et dirigent le modèle vers votre gestionnaire de secrets de choix. Choisissez-en un (1Password CLI, Doppler, AWS Secrets Manager, Vault) et modifiez la section « Secrets et accès » afin que le modèle suggère le bon appel.
5. Tester sur une tâche représentative. Demandez à Cursor : « écrire un script qui lit les 100 dernières candidatures Ashby, les note contre une fiche de poste, et publie les 10 meilleurs dans un canal Slack. » La sortie devrait poser les bonnes questions (quelle destination d’audit, quels champs sont des données personnelles, quel est le repli de révision humaine) avant de générer du code. Si ce n’est pas le cas, les règles ne sont pas chargées — vérifiez l’indicateur Project Rules de Cursor.

Ce que les règles font réellement

Le bundle est structuré en cinq couches, appliquées à chaque prompt Cursor dans le workspace :

1. Un préambule « avant d’écrire du code, demander ». Cinq questions que Cursor remonte à l’utilisateur avant de générer : quelle classe de données candidats est impliquée, quelles juridictions, lecture-ou-écriture, sémantique de nouvelle tentative, destination d’audit. Les règles instruisent Cursor de refuser les valeurs par défaut et de demander explicitement. C’est la section à levier le plus élevé — elle fait passer les conversations de « voici un script plausible » à « voici une question de clarification qui fait émerger la forme réglementaire. »
2. Guidance spécifique aux outils pour Ashby, Greenhouse, Lever, les outils de sourcing (Gem, hireEZ), et les serveurs MCP. Chaque section nomme des endpoints réels, des rate limits réels, des noms d’en-têtes réels, et les particularités que la documentation du fournisseur occulte. Exemple : Greenhouse Harvest nécessite un en-tête On-Behalf-Of pour l’attribution d’audit ; Cursor le suggérera désormais.
3. Valeurs par défaut à appliquer à travers l’audit, les biais/équité, l’idempotence, la validation de schéma, les secrets, la confidentialité, et les tests. Chaque valeur par défaut est concrète. Les journaux d’audit incluent (timestamp, user_identity, system, action, data_scope). Le rejet automatique exige un repli de révision humaine pour les scores proches de ±10 % du seuil. Les tests s’exécutent contre des instances de staging ou des bacs à sable fournisseurs ; jamais la production.
4. Anti-patterns à refuser. Des choses spécifiques que le modèle rejette quand l’utilisateur les demande : credentials inline dans les démos, sauter l’audit « pour le prototype », logger les payloads webhook complets à la réception, construire une fonctionnalité de scoring sans référencer NYC LL 144 / AI Act UE d’abord.
5. Une section « quand l’utilisateur a tort ». Les patterns que les ingénieurs atteignent sous la pression des délais que le modèle devrait repousser plutôt qu’exécuter. La règle la plus économique : refuser de déployer le screening IA aux candidats résidant à New York sans un audit annuel de biais documenté, car NYC LL 144 fait de cela une responsabilité par candidat.

Réalité des coûts

• Coût en tokens : zéro. Les règles Cursor sont du contexte local envoyé au modèle sur chaque prompt ; elles n’ajoutent pas de frais par requête au-delà des 4 à 5 Ko de contexte qu’elles occupent. Vous perdrez 1 à 2 % de la fenêtre de contexte effective du modèle. Cela en vaut la peine.
• Temps de configuration : ~15 minutes pour déposer le fichier et modifier la destination d’audit + le gestionnaire de secrets.
• Surcoût par tâche : le préambule « avant d’écrire du code, demander » ajoute 1 à 2 tours de dialogue avant que le modèle commence à générer. Pour une tâche de scripting de 5 minutes, c’est un surcoût significatif. Pour une construction d’intégration de 30 minutes, c’est du bruit — et les questions font émerger des décisions qui autrement émergeraient en révision de code ou, pire, en production.
• Maintenance : ~1 heure par trimestre pour réviser le fichier. Les versions d’outils dérivent ; ce qui était vrai sur l’API Greenhouse Harvest le trimestre dernier peut être faux ce trimestre. Le bundle d’artefacts est livré comme point de départ, pas comme spécification figée.

À quoi ressemble le succès

• Les commentaires de révision de code sur la journalisation d’audit tombent à presque zéro. Les règles suggèrent les appels d’audit inline, donc les réviseurs arrêtent de noter leur absence.
• Zéro incident de production « nous avons oublié de gérer le cas de nouvelle tentative ». Les gestionnaires de webhook sont livrés idempotents dès la première écriture car les règles l’appliquent.
• Les conversations sur l’audit de biais se déroulent en conception, pas en révision juridique. Cursor remonte la loi pertinente (NYC LL 144, Illinois AVDA, AI Act UE) quand l’utilisateur génère du code de screening, donc la discussion se passe avant que le code soit écrit.
• Onboarding plus rapide pour les nouveaux ingénieurs du recrutement. Un nouveau collaborateur lit .cursor/rules/recruiting-engineer.md une fois et comprend la posture de l’équipe ; il n’a pas à absorber un trimestre de commentaires de révision de code pour apprendre les conventions.

Par rapport aux alternatives

• Aucune règle du tout (statu quo). Cursor génère du code de recrutement plausible qui passe la révision jusqu’à ce qu’il ne passe plus. La première fois qu’un gestionnaire de webhook n’est pas idempotent et produit 1 200 enregistrements candidats en double, vous auriez aimé que la règle existe.
• Un document de conventions de codage d’équipe que personne ne lit. Fonctionnellement équivalent à l’absence de règles — le document n’est pas chargé dans le contexte de l’IA, donc les suggestions ne le reflètent pas. Le fichier de règles Cursor est le document de conventions d’équipe qui est effectivement chargé sur chaque prompt.
• Un linter ou hook de pre-commit. Attrape certains patterns (secrets codés en dur, appels d’audit manquants si vous écrivez une règle personnalisée). Ne façonne pas les suggestions de l’IA pendant l’écriture — il ne détecte les problèmes qu’après coup. La couche de règles Cursor est en amont du linter ; les deux peuvent coexister, et devraient.

Points de vigilance

• Les règles nécessitent le support Cursor Project Rules. Les versions antérieures de Cursor ne chargent pas .cursorrules depuis la racine du projet. Vérifiez sur la version de Cursor utilisée par votre équipe ; l’indicateur en bas à droite de l’éditeur confirme que les règles sont actives. Garde : incluez une vérification d’une ligne dans le README de votre projet (« Cursor 0.40+ ; l’indicateur de règles doit afficher ‘recruiting-engineer.md active’ »).
• Ne pas sur-spécifier. Ajouter des règles pour chaque préférence de style produit des suggestions trop restrictives et des directives conflictuelles. Gardez le fichier focalisé sur les règles qui empêchent le risque matériel de biais, de confidentialité, ou de données candidats ; laissez le formatage se gérer avec Prettier ou Black. Garde : plafonnement strict du fichier à ~300 lignes.
• Dérive des API des outils. Ashby et Greenhouse publient des modifications incompatibles 1 à 2 fois par an. Une règle référençant un endpoint obsolète génère du code cassé. Garde : révisez le fichier trimestriellement contre le changelog de chaque outil ; versionner la règle qui mentionne la version d’API (ex. # Greenhouse Harvest v1 (vérifié 2026-T2)).
• Les règles ne remplacent pas les audits de biais ni la révision de code. Elles façonnent ce que Cursor suggère pendant l’écriture. Elles ne s’exécutent pas en CI, elles ne détectent pas ce que l’ingénieur remplace, et elles ne constituent pas un audit de biais NYC LL 144. Garde : maintenez la révision humaine et l’infrastructure d’audit comme couches d’application séparées ; les règles complètent, ne remplacent jamais, celles-ci.
• Les remplacements par dépôt comptent. Une règle qui est juste dans votre dépôt d’automatisation du sourcing peut être incorrecte dans votre dépôt d’intégration d’évaluation. Utilisez le support de règles par répertoire de Cursor (remplacements .cursor/rules/<subdir>/) quand les conventions divergent réellement. Garde : préférez un fichier de règles partagé avec des exceptions documentées plutôt que de forker le fichier par dépôt.

Stack

• Cursor — IDE et moteur de règles
• .cursor/rules/recruiting-engineer.md — versionné dans le dépôt, soumis à révision de code comme toute autre configuration
• Gestionnaire de secrets de choix — référencé depuis les règles, jamais inline
• Destination d’audit — Datadog, BigQuery, ou une table d’audit dédiée ; nommée explicitement dans les règles afin que les suggestions pointent vers le vrai appel