Comment j'ai bâti Ada, mon employée IA (et comment tu pourrais bâtir la tienne)

La version courte : écris des specs avec une ligne « terminé veut dire », garde les tâches petites, mets des barrières entre l'IA et tout ce qui est réel, révise son travail comme celui d'un collègue, réinjecte chaque échec dans les instructions, et garde la production derrière un humain. Le reste du billet, c'est à quoi ça ressemble en pratique, plus un prompt qui monte le tout pour toi.

La plupart des nuits, mon téléphone vibre autour de 3 h du matin. Ce n'est pas une personne. C'est Ada, qui me dit qu'elle a fini une fonctionnalité, roulé les tests et poussé le code pour révision. Je me rendors. Le matin, je lis son travail comme je lirais celui de n'importe quel collègue, et si c'est bon, ça part.

Ada, ça ne s'achète pas. C'est un système que j'ai bâti : un modèle d'IA qui roule dans une boucle, avec des garde-fous que j'ai ajoutés un à un, à mesure que les choses tournaient mal. Je suis ingénieur logiciel et ça m'a pris des mois avant qu'elle fonctionne pour vrai. Pas des mois à écrire du code. Des mois à comprendre comment déléguer à une IA sans que tout se défasse en silence.

Ce billet, c'est la méthode au complet. La première moitié fonctionne que tu écrives du code ou non. La deuxième moitié, c'est le montage concret, avec un prompt que tu peux coller dans Claude Code pour monter ta propre version de départ.

La méthode

Chaque règle ci-dessous existe parce que quelque chose a mal tourné sans elle.

1. Écris des specs, pas des souhaits

La différence entre un résultat d'IA utile et un résultat d'IA qui gaspille ta soirée, c'est presque toujours l'instruction que tu lui as donnée.

Un souhait, ça ressemble à ça : « ajoute de la validation au formulaire d'inscription ».

Une spec, ça ressemble à ça : « les courriels invalides et les mots de passe vides doivent être rejetés avec des messages d'erreur visibles. Écris d'abord des tests qui soumettent ces entrées, puis fais passer les tests. Terminé veut dire : tous les tests au vert, aucun autre fichier modifié ».

Chaque tâche qu'Ada prend a une spec avec une ligne « terminé veut dire ». Si je ne suis pas capable d'écrire cette ligne-là, la tâche n'est pas prête à être confiée.

2. Découpe le travail petit

Ada ne reçoit jamais « bâtis le système de facturation ». Elle reçoit une tranche délimitée à la fois, chacune finissable en une seule exécution. Les petites tâches échouent petit. Les grosses échouent d'une façon que tu découvres seulement trois jours plus tard.

Si tu délègues quoi que ce soit à une IA, la taille des tâches est ton principal bouton de risque. Baisse-le.

3. Construis des barrières que l'IA ne peut pas contourner

Je ne fais pas confiance à Ada. Je fais confiance aux barrières.

Rien de ce qu'elle écrit ne compte comme terminé tant que ça n'a pas passé la suite de tests, le vérificateur de types, le linter et un build de production complet. Ça roule chaque fois, et elle ne corrige pas ses propres devoirs.

Si tu n'es pas technique, la même règle ressemble à ça : le résultat de l'IA ne va jamais directement à destination. Il y a toujours un point de contrôle qu'il doit franchir et que l'IA ne contrôle pas. Une liste de vérification, une deuxième lecture, un envoi test à toi-même avant le vrai envoi.

4. Révise comme si c'était un collègue, pas de la magie

Chaque matin, je lis ce qu'Ada a livré pendant la nuit, ligne par ligne, comme je lirais une pull request d'un coéquipier humain. Des fois c'est excellent. Des fois je le renvoie avec des notes. La révision n'est jamais facultative.

Un résultat d'IA a l'air sûr de lui, qu'il ait raison ou non. La révision, c'est là que tu attrapes la différence.

5. Tiens un journal des apprentissages

Quand quelque chose tourne mal, je ne fais pas juste le réparer. J'écris ce qui s'est passé, pourquoi, et quelle règle l'aurait empêché. Ces notes-là retournent dans les instructions permanentes d'Ada. Elle est meilleure ce mois-ci que le mois passé parce que les instructions se sont améliorées, pas parce que le modèle l'a fait.

Presque tout le monde saute cette étape. C'est celle qui a un effet cumulatif.

6. Garde la dernière porte humaine

Ada peut livrer dans mon environnement de préproduction toute la nuit. La production, elle, attend un mot précis de ma part, et rien ne s'automatise autour de ça.

Peu importe ta version de la production, ton billet publié, ton livrable client, la page de ton cours en direct, garde une main humaine sur cette dernière porte.

La pile technique, pour ceux qui bâtissent

Ce qu'Ada est physiquement :

• Le cerveau, c'est Claude, piloté par Claude Code, le CLI agentique d'Anthropic. N'importe quel outil de codage agentique compétent pourrait remplir cette case. La boucle compte plus que la marque.
• La file d'attente, c'est un fichier markdown qui liste les tâches. Chaque tâche pointe vers une spec (quoi et pourquoi, avec les critères « terminé veut dire ») et un plan (comment, étape par étape). Je les écris pendant la journée.
• La boucle, c'est un script PowerShell qui surveille la file, prend la tâche suivante et la remet à l'IA sur sa propre branche.
• Les barrières, ce sont les tests unitaires, le mode strict de TypeScript, ESLint et un build de production complet. Les quatre doivent passer avant que quoi que ce soit compte comme terminé.
• L'alerte, c'est un bot Telegram. Ada m'écrit quand elle finit, et m'écrit différemment quand elle échoue. La vibration de 3 h du matin, c'est ce bot-là.
• Le coût, c'est un abonnement Claude plus à peu près zéro infrastructure. La boucle roule sur ma propre machine.

Il n'y a aucun produit secret là-dedans. Des specs en entrée, des barrières actives, une révision après.

Bâtis ta version de départ en un après-midi

Ça te prend trois choses : un projet qui vit dans git, Claude Code ou n'importe quel CLI agentique capable de lire des fichiers et de rouler des commandes, et à peu près une heure.

Un avertissement avant de coller quoi que ce soit : tu ne bâtis pas aujourd'hui l'Ada autonome de nuit. Tu bâtis la version de départ supervisée. Une tâche à la fois, les barrières activées, toi qui regardes. C'est le même système que je fais encore rouler. La partie nocturne, c'est un détail de planification que j'ai ajouté seulement après des mois où la boucle supervisée était plate et fiable.

Étape 1. Monte le système. Ouvre Claude Code dans ton projet et colle ceci :

Set up a minimal "AI teammate" system in this repository. Scaffolding only, no feature work yet.
 
1. Detect this project's tooling: test command, type check, lint, build. List what you found and wait for my confirmation before creating anything.
 
2. After I confirm, create an ai-team/ folder with these files:
 
- QUEUE.md: a task table with columns: id, title, spec file, status (queued / in-progress / done / failed), branch, notes.
 
- specs/TEMPLATE.md: a spec template with sections: Goal (one paragraph), Done means (verifiable criteria a command or test can prove), Out of scope, How to verify (exact commands).
 
- RULES.md with these standing rules:
  * One task at a time, always from QUEUE.md, always following its spec file.
  * Work on a fresh branch named ai/<task-id>. Never commit to the default branch. Never push, never merge, never touch remotes. The human reviews and merges.
  * Before marking a task done, run every gate this project actually has from the step-1 detection (tests, type check, lint, build). All existing gates must pass. Record each result in the task's notes, and record any gate the project doesn't have as "N/A (not configured)" rather than skipping it silently.
  * If blocked after 3 materially different attempts, stop. Mark the task failed with a note on what was tried.
  * Never run destructive commands. Never delete or modify files outside the spec's scope. List any new dependency in the notes before installing it.
  * On every failure, append a dated entry to ai-team/LEARNINGS.md: what went wrong and what rule would have prevented it.
 
- LEARNINGS.md: empty, with a one-line header explaining its purpose.
 
3. Commit the ai-team/ folder to the current branch with the message "chore: add ai-team scaffolding", show me the created files, and stop.

Deux choses à prévoir quand tu le lances. Il s'arrête après l'étape 1 et attend ta réponse, c'est voulu, c'est le premier point de contrôle humain. Et si ton projet n'a qu'une partie des quatre barrières, c'est correct, les règles s'attachent à ce que l'étape 1 a réellement trouvé.

Étape 2. Écris ta première spec. Copie specs/TEMPLATE.md et remplis-le pour quelque chose de petit et d'achalant que tu remets à plus tard. La petitesse compte ici : si ça échoue, tu dois perdre des minutes, pas ta fin de semaine. Ajoute une ligne dans QUEUE.md.

Étape 3. Roule une tâche. Ouvre une nouvelle session et colle :

Read ai-team/RULES.md and follow it exactly. Pick the topmost queued task in ai-team/QUEUE.md, mark it in-progress, and do it on its own branch per the rules. When the gates pass, mark it done, summarize what you changed and why, and stop for my review.

Regarde-le travailler les premières fois. Tu apprends ce qu'il fait bien de façon fiable, et lui bâtit ses propres règles dans LEARNINGS.md.

Étape 4. Révise la branche comme une PR. Lis le diff. Si c'est bon, tu la fusionnes toi-même. Sinon, ajoute des notes à la spec, remets la tâche dans la file et relance-la.

Étape 5. Gradue lentement. Quand dix tâches d'affilée ont été plates, mets-en plusieurs dans la file en même temps. Quand ça aussi devient plate, cherche le mode headless de ton CLI (Claude Code en a un), mets la commande d'exécution sur un horaire, et ajoute une notification pour quand une exécution se termine.

La version Telegram de cette notification, puisque le monde le demande toujours : écris à @BotFather sur Telegram, envoie /newbot, et il te remet un jeton de bot. Envoie n'importe quel message à ton nouveau bot depuis ton propre compte, puis ouvre cette URL dans un navigateur et copie le numéro chat.id dans la réponse :

https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates

À partir de là, une seule ligne à la fin de ton script d'exécution, c'est tout le système de notification :

curl -s "https://api.telegram.org/bot<YOUR_TOKEN>/sendMessage" -d chat_id=<YOUR_CHAT_ID> -d text="Ada: run finished"

C'est ça, la vibration de 3 h du matin, et ça fait du bien seulement à cause de chaque garde-fou que tu as ajouté en montant.

Ce qui a brisé en chemin

Tu devrais savoir de quoi ça a l'air quand ça tourne mal, parce que ça va arriver.

L'arrêt nocturne. Ma machine s'est déjà éteinte en pleine exécution et a laissé le travail d'Ada orphelin, à moitié fini. Maintenant, la boucle vérifie les exécutions périmées au démarrage et les récupère au lieu de faire comme si elles n'avaient jamais existé.

La mauvaise branche. Au début, la boucle n'avait aucune conscience des branches. Une nuit, la branche de la tâche précédente avait été nettoyée, et Ada a commité en silence toute une fonctionnalité sur la mauvaise branche, en sautant complètement ma barrière de révision. Rien de mauvais n'est parti en production, mais le système vérifie maintenant où il se tient avant son premier commit, chaque fois.

Les processus zombies. Des serveurs de développement qui ne mouraient jamais s'empilaient jusqu'à ce que la machine rampe. Maintenant, rien n'est présumé mort. La boucle vérifie ce qui roule réellement et tue par identifiant de processus.

Aucun de ces cas n'était un échec de l'IA. Mes garde-fous avaient des trous, les trous se sont manifestés en incidents, et chaque incident est devenu une règle.

Si tu n'écris pas de code

Tu peux appliquer la même méthode avec rien d'autre qu'une IA conversationnelle et un peu de discipline :

1. Tiens un document d'instructions permanentes : qui tu es, à quoi ressemble un bon résultat, ce qu'il ne faut jamais faire. Colle-le dans chaque projet, ou utilise un outil qui le conserve.
2. Écris une spec pour chaque vraie tâche, avec une ligne « terminé veut dire ».
3. Garde les tâches assez petites pour qu'un mauvais résultat te coûte des minutes, pas des jours.
4. Mets un point de contrôle entre le résultat de l'IA et le monde réel. Toujours.
5. Tiens une note courante de chaque raté et de l'instruction qui l'aurait empêché. Réinjecte-la.
6. Révise tout ce qui sort avec ton nom dessus. L'IA a l'air sûre d'elle dans les deux cas. C'est toi qui es capable de faire la différence.

Tu n'auras pas les livraisons de 3 h du matin. Tu auras la partie qui compte plus : une délégation qui continue de s'améliorer, parce que tu continues de réinjecter les ratés.

Pourquoi je te raconte ça

Je bâtis Classentra en public. C'est une plateforme d'enseignement en direct pour les éducateurs et les créateurs, et je partage le quotidien sur Instagram à @adinashby, incluant les victoires d'Ada et ses plantages. Si tu arrives ici par un reel, c'est le guide que je t'ai promis.

Viens me dire ce que tu confierais en premier à un coéquipier IA. Je réponds moi-même à mes DM.