Notation des CV (entonnoir à 3 portes)
Un CV n'est pas terminé tant qu'il n'a pas passé un entonnoir indépendant à 3 portes et que la fiche de score n'est pas enregistrée.
Les portes reflètent le recrutement : recruteur -> ingénieur principal -> responsable du recrutement. Chacune représente un œil différent qui
juge uniquement ce qu'il peut percevoir. Tous les profils, grilles d'évaluation, poids et seuils se trouvent dans
config/scoring_panel.yaml — utilisez-le textuellement ; ne les codez pas en dur ici.
Principes
- Une page vierge, à chaque fois. Un sous-agent par porte, chacun dans un contexte frais : il n'a jamais vu ce candidat et
le rencontre pour la première fois via le seul CV. On lui donne UNIQUEMENT la JD, le texte du CV et son propre
read_mode/grille d'évaluation. Ne transmettez jamais notre analyse d'adéquation, nos notes de décision ou un score précédent (ancrage). - Œil différent, grille différente. Ne donnez pas aux trois portes une seule grille partagée.
- Ne pas faire la moyenne. Le verdict est le pire niveau, marqué à la porte défaillante la plus précoce ; le numéro de suivi est le score de porte le plus bas. Un 65 du recruteur et un 82 du responsable donnent une moyenne confortable de 73,5 — mais le CV est mort à la première porte et le responsable ne le voit jamais.
- Juger ce qui est lisible, pas ce qui est vrai. Un évaluateur qui rencontre le CV d'un inconnu n'a pas de vérité terrain, donc il note à quel point le document est convaincant — une affirmation exagérée ne parvient tout simplement pas à convaincre. La véracité relève de la responsabilité de l'auteur : c'est pourquoi ce dépôt ne fabrique jamais d'expérience (voir le skill de construction).
- Noter le vrai document. Extrayez le texte du fichier
.docxconstruit une fois, vérifiez qu'il n'est pas vide, et transmettez-le en ligne aux trois portes (une porte recevant une lecture vide hallucinera et notera des déchets). - Les constatations ne sont pas des modifications. Agir sur une constatation ne doit jamais fabriquer. Un mot-clé de la JD nécessite une puce d'appui tirée d'une expérience réelle ; sinon c'est un écart honnête.
Processus
- Charger
config/scoring_panel.yaml. - Rassembler les entrées : la JD (du dossier), le texte extrait du CV, confirmer qu'il tient sur une page.
- Lancer les trois portes dans un seul message (en parallèle), chacune construite à partir de
reviewer-prompt-template.md. - Composer : attribuer un niveau à chaque porte à partir de son propre
pass/borderline; verdict = pire niveau à la porte la plus précoce (NO@recruiter,BORDERLINE@hiring_manager, ouPASS) ; numéro de suivi =min(scores totaux des portes); consensus = ce que >= 2 portes signalent indépendamment ; classer chaque déduction réparable vs inhérente. - Écrire une section
## Scorecarddans le dossier de candidature (format ci-dessous) et une ligne dans son journal.
Format de la fiche de score
## Scorecard — YYYY-MM-DD (cv : <output>.pdf)
**Entonnoir : Recruteur ✅ NN → Staff ⚠️ NN → HM ❌ NN → NO@hiring_manager**
**Porte la plus faible : NN/100**
| Porte | Score | Sous-scores | Verdict |
|---|---|---|---|
| Recruteur | NN/100 | pile NN/45, ancienneté NN/30, scan NN/25 | ✅ |
| Ingénieur principal | NN/100 | tech NN/35, projets NN/30, jd NN/35 | ⚠️ |
| Responsable recrut. | NN/100 | poste NN/65, niveau NN/35 | ❌ |
**Liste de sondage (staff) :** 1) … 2) … 3) … **Mémo des risques (HM) :** …
**Consensus (>=2 portes) :** …
**Déductions :** réparables : … · inhérentes (narrative entretien) : …
**Prochaines modifications classées :** 1) … 2) … 3) …
Erreurs courantes
- Ancrer les portes avec notre propre analyse ou un score antérieur.
- Faire la moyenne des trois scores.
- Demander à un évaluateur de noter la véracité (il ne peut noter que la persuasion).
- Laisser une porte déduire pour des éléments que le formulaire de candidature demande séparément (voir
out_of_scopedans la configuration). - Traiter un écart inhérent comme réparable par un changement de formulation.
- Augmenter le score en fabriquant des informations.