Aucun code livré : mener une recherche d'emploi comme un projet logiciel, avec une IA qui prépare tout et n'envoie rien

Par Thales (CEO, ZeroSuite) et Claude Opus 5.5 — instance Claude Code

Jusqu'ici, tout sur ce blog parlait de logiciel : pipelines de déploiement, passerelles de paiement, un langage de programmation, un ERP de gestion de flotte. Cet article parle d'une recherche d'emploi.

Le 24 septembre 2026, le CEO a ouvert une session avec une demande qui n'avait rien à voir avec un produit ZeroSuite : mener une recherche d'emploi, dès la première lettre, avec les outils qui nous servent à livrer du logiciel. Nous ne décrivons pas ici la personne candidate : ni son métier, ni son employeur, ni son lieu de vie. Ce qui mérite d'être copié, c'est la méthode, et la méthode ne dépend pas du métier. Pour le montrer, les exemples qui suivent passent volontairement par cinq métiers : développeur, infirmier ou infirmière, commercial, comptable et chef de chantier. Ce sont des illustrations, pas le cas réel.

À la fin de la journée, la recherche disposait :

• d'un site personnel repositionné ;
• de deux CV et de deux lettres de motivation, l'une pour le poste visé, l'autre pour le poste actuel ;
• de deux modèles d'e-mail ;
• d'une première candidature prête à partir ;
• d'une préparation d'entretien en 32 questions ;
• d'un dépôt git privé avec un dossier par employeur ;
• d'un fichier de suivi unique ;
• d'un cockpit CASP dont la feuille de route ne s'arrête pas à « candidatures envoyées » mais au « contrat signé ».

Aucune ligne de code produit n'a été écrite. La session tournait dans Claude Code, le seul outil que nous nommons dans cet article ; tout ce qui suit fonctionne avec n'importe quel assistant IA capable de lire et d'écrire des fichiers dans un dossier.

Partie 1 — Traiter la recherche d'emploi comme un projet, pas comme une pile de documents

La première vraie décision était structurelle. Le réflexe du CEO était le plus naturel : un dossier avec le CV et la lettre, et une liste d'adresses e-mail dans un fichier de notes. Cela tient pour trois candidatures. Cela s'effondre à quinze, quand on ne sait plus quelle version de la lettre est partie chez quel employeur, si la relance a été envoyée, ni quel CV le deuxième cabinet de recrutement a reçu.

Nous avons donc fait ce que nous faisons pour un produit.

Un dépôt git privé par personne candidate, séparé du site public. Le site se redéploie à chaque push. Les fichiers de candidature ne doivent jamais partir avec un déploiement du site, et le site ne doit jamais être touché par un commit de candidature. Deux dépôts, deux cycles de vie. Le dépôt de candidature peut recevoir un commit toutes les dix minutes sans que rien ne soit mis en ligne.

Un dossier par employeur, nommé en majuscules avec des tirets (EMPLOYEUR-A/, RECRUTEUR-B/). Chaque dossier contient la lettre personnalisée (DOCX et PDF), l'e-mail en texte brut et une copie des PDF exactement tels qu'envoyés. Le CV maître évoluera ; ce qu'un employeur donné a reçu, non.

Un dossier _commun/ avec les maîtres : deux CV (poste visé, poste actuel), deux lettres génériques, deux modèles d'e-mail avec des champs [entre crochets] et une règle écrite en tête : aucun crochet ne doit survivre dans un e-mail envoyé.

Un dossier _entretien/ pour la préparation des entretiens.

Un fichier de suivi, et un seul. suivi-candidatures.md compte une ligne par candidature : entité, poste visé, type (spontanée ou offre publiée), canal, dossier, statut, envoyée le, relance, notes. Les statuts forment une chaîne fixe : to prepare → ready → sent → followed up → interview / rejected / no answer.

Le CEO a demandé un emoji de coche verte sur chaque ligne envoyée. Claude a refusé, et la raison compte plus que la règle anti-emoji (ZeroSuite n'en utilise nulle part). Une coche est une affirmation sans preuve ; une date est une preuve. La règle écrite à la place : une ligne est envoyée si et seulement si la colonne « envoyée le » contient une date. Avec vingt lignes, on ne peut pas tricher sur celle-là par accident.

Partie 2 — Les lettres : le travail de l'IA est de refuser la phrase invérifiable

Le contenu des CV et des lettres est passé par la même discipline de revue qu'une pull request, et les moments les plus utiles ont été des refus.

La phrase des records. La vraie force de la personne candidate, selon le CEO, c'est la rapidité. Le brouillon du CEO affirmait que la personne candidate « bat presque tous les records ». Claude a refusé : personne ne publie ces classements, et un recruteur qui demande « quels records ? » n'obtient pas de réponse. Nous avons gardé une comparaison que la personne candidate peut défendre en entretien, mesurée par rapport à sa propre équipe, accompagnée du contrepoids qui inquiète réellement un recruteur : la vitesse qui se paie en exactitude.

La règle vaut pour tous les métiers : remplacer le superlatif par un fait qu'une référence pourrait confirmer.

Les absolus partent avec les superlatifs. « Jamais la moindre erreur », personne n'y croit, et cela appelle exactement la mauvaise question en entretien.

Aucun chiffre interne, aucune critique de l'employeur actuel. Les volumes, les classements et les raisons du départ restent hors de tous les documents. Le fichier de règles du dépôt les consigne, si bien que le futur agent de veille des offres en hérite sans qu'on ait à le lui dire.

Une seule structure de lettre, déclinée par poste. La lettre pour le poste visé s'ouvre sur ce sur quoi ce poste est jugé et consacre un paragraphe à la marche à franchir : coordonner les autres, porter un périmètre plus large. Pour un développeur qui vise un poste de tech lead, ce paragraphe parle de revues de code et de déblocage de l'équipe ; pour un chef de chantier qui vise un poste de conducteur de travaux, il parle de mener plusieurs chantiers à la fois. La lettre pour le poste actuel est la même lettre, où ce paragraphe est remplacé par un autre sur le périmètre propre de la personne candidate. Nous avons comparé les deux par un diff plutôt que d'écrire une seconde lettre de zéro, pour que les affirmations ne puissent pas diverger.

Quel CV va où est une règle, pas une humeur. Les employeurs reçoivent le CV du poste visé. Les cabinets de recrutement et les agences d'intérim reçoivent le même CV, avec un e-mail ouvert à « poste visé ou poste actuel » : un cabinet place des gens sur ses propres missions, et fermer une porte là-bas ne rapporte rien. Le CV du poste actuel est réservé aux offres publiées pour ce poste. Un point subtil est entré dans le fichier de règles : une mission obtenue par une agence d'intérim peut reproduire exactement le montage contractuel que la personne candidate veut quitter. Elle ne vaut la peine que si le poste est une progression ou si l'embauche est directe.

L'e-mail est un résumé, pas un mot d'accompagnement. Le premier brouillon d'e-mail ressemblait à une circulaire (« veuillez trouver ci-joint… »). Le CEO l'a rejeté : l'e-mail doit donner au recruteur l'envie d'ouvrir la lettre. Le résultat est un résumé de la lettre en trois paragraphes, qui s'ouvre sur le besoin de l'employeur, pas sur la personne candidate.

Partie 3 — La préparation d'entretien comme une suite de tests

Le document d'entretien compte 32 questions réparties en six sections, chacune avec une réponse travaillée. La section 3 a été ajoutée en fin de journée à la demande du CEO, et c'est celle que nous recommanderions à tout le monde : outils, incidents et sécurité. Les listes génériques des « 50 questions d'entretien les plus fréquentes » ne la contiennent jamais, et c'est là que se joue réellement un entretien pour un poste à responsabilités.

Écrivez les questions d'incident de votre métier, celles que poserait un recruteur qui a fait le travail :

• Développeur : la production tombe un vendredi soir et le dernier déploiement était le vôtre. Que faites-vous dans les dix premières minutes ?
• Infirmière : vous remarquez une erreur de dosage après l'administration du médicament. Qui prévenez-vous, dans quel ordre, et que consignez-vous ?
• Commercial : un client important conteste une commande signée et menace de partir. Que concédez-vous, et que refusez-vous ?
• Comptable : les comptes ne s'équilibrent pas la veille de la clôture. Où regardez-vous en premier ?
• Chef de chantier : une livraison arrive non conforme le matin où la dalle doit être coulée. Arrêtez-vous le coulage ?

Ajoutez les questions qui sont désormais les mêmes partout : quels outils du métier vous utilisez et à quel point vous les maîtrisez, et ce que vous faites quand quelqu'un appelle en se présentant comme « le support informatique » et vous demande votre mot de passe.

Partie 4 — CASP : une feuille de route qui se termine au contrat signé

CASP (le Coding-Agent State Protocol) est l'outil que nous ouvrons chaque jour ouvré sur chaque produit ZeroSuite. C'est un dossier casp/ dans le dépôt : un state.json, un now.md et un roadmap.md, plus un validateur, casp check, qui prouve que l'état consigné correspond toujours à git et refuse le push quand ce n'est pas le cas. Le CEO l'a demandé ici en passant, après l'avoir oublié en début de session : installe CASP dans le dépôt de candidature et remplis-le jusqu'à la signature du poste.

casp init pose le cockpit en une seconde. Le travail consiste à écrire l'état honnêtement :

La dernière ligne de now.md le dit sans détour : le cockpit se ferme le jour où le contrat est signé. C'est le point sur lequel nous insisterions le plus auprès de quiconque copie cette méthode. Une recherche d'emploi suivie en « candidatures envoyées » mesure l'activité. Une feuille de route qui se termine par une signature mesure le résultat, et elle oblige les phases inconfortables (relances, négociation, préavis) à exister sur le papier avant qu'elles n'arrivent.

Trois choses que CASP nous a apportées et qu'un fichier de notes n'aurait pas données :

1. « Où en est-on ? » a une réponse qui tient sur un écran. casp status affiche la phase en cours, le prompt de la prochaine session et les derniers commits. La prochaine session de travail part de docs/plan/sessions/PHASE-2-PREMIERE-VAGUE.md, pas de la mémoire.

1. Les décisions sont consignées comme des décisions. Le CEO a décidé de répondre à une offre publiée que Claude avait signalée comme un recul : un CDD avec des exigences de débutant, face au CDI actuel de la personne candidate. Claude a recommandé de la préparer en dernier, avec une prétention salariale au moins égale à la rémunération actuelle. Le CEO a maintenu sa décision, et le journal consigne à la fois la décision et la réserve. Dans trois semaines, personne n'aura à reconstituer pourquoi ce dossier existe.

1. Les questions ouvertes sont listées, pas mémorisées. La feuille de route contient un tableau « Bloqué / à décider ». À mi-session, il contenait trois éléments :
2. - deux adresses de recruteurs dont nous n'avions pas encore identifié l'entreprise ;
3. - une prétention salariale exigée par l'offre ;
4. - une modification à la main faite par le CEO dans un modèle d'e-mail, qui contredisait son corps.

Le dernier a été résolu dans l'heure (les employeurs reçoivent le poste visé dans l'objet, les agences d'intérim reçoivent « poste visé ou poste actuel »), et il a quitté le tableau dans le même commit.

casp check a terminé la journée à 18 PASS, 0 WARN, 0 FAIL. Pour un dépôt sans code, ce n'est pas de la décoration. Cela signifie que le fichier d'état, le journal de session et git concordent, ce qui est tout l'enjeu quand la prochaine session, ou la prochaine personne, reprend le travail.

Le site public a eu sa propre section dans la même feuille de route plutôt qu'un second cockpit, parce qu'il sert le même résultat. Elle consigne ce qui est déployé, un petit commit en attente du prochain push, et une dernière tâche pour la phase 5 : à la signature, retirer du site la mention de recherche d'emploi active.

Partie 5 — Veille des offres et envoi : tout préparer, ne rien envoyer

Le plan initial du CEO prévoyait de confier à l'agent les identifiants SMTP de la boîte mail de la personne candidate, pour qu'il envoie lui-même les candidatures par simple e-mail. Les formulaires en ligne resteraient manuels.

Nous l'avons conçu dans l'autre sens, et la règle est désormais la première ligne du fichier de règles du dépôt : l'agent n'envoie jamais rien. Le raisonnement :

• Le volume ne le justifie pas. Une première vague compte moins de dix candidatures. Envoyer chacune prend moins de deux minutes à la personne candidate.
• Une candidature ne se reprend pas. Une mauvaise pièce jointe, un [champ] oublié ou une lettre qui nomme le mauvais employeur restent visibles pour le recruteur à jamais. L'envoi humain est la dernière relecture, et il ne coûte presque rien.
• La délivrabilité, c'est la réputation de la personne candidate. Son domaine dispose de SPF, DKIM et DMARC, et au moins un employeur visé filtre son courrier par une passerelle de messagerie d'entreprise. Une rafale d'envois scriptés depuis une boîte récente est exactement ce que ces filtres sont conçus pour intercepter.

Ce que l'automatisation fera, c'est tout ce qui précède l'envoi :

1. Surveiller les offres. Elle consulte les sites d'emploi et les pages carrières des employeurs, sans scraper LinkedIn (ses conditions l'interdisent), et dédoublonne par rapport au fichier de suivi : une candidature par employeur et par poste.
2. Préparer le dossier. Elle crée le dossier de l'employeur, personnalise la lettre à partir du maître, exporte le PDF via Word et le contrôle : une page, texte relu avec pdftotext, rendu PNG regardé. Elle écrit le fichier de l'e-mail et passe la ligne à ready.
3. Laisser l'envoi à la personne candidate. La relecture et l'envoi lui reviennent. La ligne ne passe à sent qu'une fois la date renseignée de sa main.

Filtrer sur le métier, pas sur l'intitulé

Un intitulé de poste est une étiquette que chaque employeur définit pour lui-même. « Consultant » recouvre un développeur en mission chez un client et un commercial rémunéré à la commission ; « technicien » recouvre un laboratoire, une salle serveurs et un chantier ; « coordinateur » recouvre un service hospitalier, un projet et un secteur commercial. Dans notre cas, les résultats bruts pour l'intitulé visé mélangeaient un autre métier d'un autre secteur, pour environ la moitié d'entre eux. Un agent qui filtre sur l'intitulé renvoie du bruit. Filtrez plutôt sur les tâches et le contexte :

• Développeur : la stack et le type de produit, pas « ingénieur ».
• Infirmière : le service et le rythme des gardes, pas « infirmière ».
• Commercial : ce qui est vendu et la durée du cycle de vente, pas « business developer ».
• Comptable : le périmètre (comptabilité générale, consolidation, fiscalité) et la taille de l'entité.
• Chef de chantier : le type de travaux et la taille des chantiers.

Écrivez le filtre dans le fichier de règles du dépôt, à côté des règles de contenu, pour que l'agent en hérite.

Les identifiants SMTP et IMAP vivent dans un .env ignoré par git dès le premier commit. Leur meilleur usage n'est pas l'envoi. C'est de déposer l'e-mail préparé, pièces jointes comprises, dans le dossier Brouillons de la boîte mail de la personne candidate, via IMAP. Il ne reste qu'à ouvrir le client de messagerie, relire le brouillon et cliquer sur Envoyer. C'est la conception de la phase 3 : pas encore construite, consignée dans la feuille de route, et celle que nous recommanderions à tout le monde.

Partie 6 — Un incident de production, parce qu'il y en a toujours un

Les PDF étaient exportés en pilotant Microsoft Word depuis un script. Lors d'un export, le script a mis Word au premier plan pendant que le CEO tapait dans une autre fenêtre. Trois de ses frappes ont atterri dans le titre du document d'entretien.

Claude l'a repéré en relisant le texte du PDF exporté, pas en se fiant au code de sortie de l'export. Il a réexporté le document et retiré l'appel activate du script, avec un commentaire expliquant pourquoi. Puis il a comparé mot à mot chaque autre PDF exporté ce jour-là avec sa source. Seul celui-là avait été touché. La leçon est une constante de ZeroSuite : un export qui s'est exécuté n'est pas un export correct ; lisez la sortie. Elle vaut autant pour une lettre de motivation que pour un artefact de build.

Comment reproduire cela pour votre propre recherche d'emploi

Vous n'avez pas besoin de notre stack. Il vous faut la forme, et un assistant IA capable de lire et d'écrire des fichiers. L'ensemble du processus existe aussi sous forme de guide PDF pas à pas, avec l'arborescence des dossiers, le fichier de suivi, les prompts et les listes de contrôle : télécharger le guide de recherche d'emploi (PDF).

1. Un dépôt privé (ou un dossier sous gestion de versions) séparé de tout ce qui est public.
2. Les maîtres au même endroit, un dossier par employeur, avec les PDF figés tels qu'envoyés.
3. Un seul fichier de suivi, où une ligne ne compte comme envoyée que si elle porte une date.
4. Des règles de contenu écrites (aucun superlatif sans fait derrière, aucun chiffre interne, aucune critique de votre employeur) que tout assistant, humain ou IA, doit suivre.
5. Une préparation d'entretien conçue comme une suite de tests, bâtie sur les questions d'incident et de sécurité de votre métier.
6. Un filtre des offres fondé sur le métier, pas sur l'intitulé.
7. Une feuille de route qui se termine au contrat signé, avec les relances, la négociation et le préavis inscrits dès le premier jour.
8. Une automatisation qui prépare et n'envoie jamais. Déposez les brouillons dans votre boîte mail, puis relisez-les et cliquez vous-même sur Envoyer.

Avec CASP, la feuille de route a un validateur : npm i -g @justethales/casp, puis casp init dans le dépôt.

CASP — le Coding-Agent State Protocol. Votre agent IA mène toute la feuille de route sans jamais perdre le fil. Natif git, 100 % local, sous licence MIT, zéro télémétrie. Conçu par Juste Thales Gnimavo, de ZeroSuite, un CEO solo dont les produits tournent en production avec Claude pour seul ingénieur. Installation : npm i -g @justethales/casp · https://casp.sh · https://github.com/ThalesGnimavo/casp