Déléguer le clavier, pas la réflexion
Et si je vous disais que je n'avais pratiquement pas écrit une ligne de code à la main depuis six mois ?
En novembre 2025, Claude Opus 4.5 est sorti. Pour beaucoup d'entre nous, il a clairement changé la façon d'écrire du code, au point que Claude Code est devenu viral pendant les vacances d'hiver, y compris auprès de gens qui ne codaient pas. Mon dernier article sur le sujet, "L'IA est un outil, pas un pilote", reste d'actualité. En revanche, ma manière de travailler avec ces outils a beaucoup évolué depuis.
À l'époque, je déconseillais de laisser l'IA piloter. Je le pense toujours. Sauf que "ne pas écrire le code soi-même" et "laisser l'IA piloter" ne sont pas la même chose. Tout est une question de méthode, et c'est précisément cette méthode que je veux vous détailler ici.
Mais avant de parler de comment l'utiliser, il faut comprendre de quoi on parle. Un vocabulaire complet s'est construit autour de ces outils, et le maîtriser change tout.
Le vocabulaire à connaître
Avant de parler de méthode, posons les mots. Le sujet a généré tout un vocabulaire, souvent en anglais, et beaucoup de confusions viennent simplement du fait qu'on mélange ces termes. Voici les briques de base, de la plus simple à la plus avancée.
Model
Le modèle, c'est le LLM que vous utilisez.
Un modèle, seul, n'est rien de plus qu'un prédicteur de texte. Il a été entraîné sur un certain nombre de paramètres et possède ses propres limites. (Si vous voulez comprendre comment cette prédiction fonctionne réellement, j'en parle en détail dans mon article précédent.)
La plupart des modèles sont aujourd'hui très performants. Ce n'est donc pas tant le modèle qui fait la différence que votre façon de l'utiliser.
Context
Une de ces limites, c'est le contexte du modèle. Le contexte, c'est la connaissance que vous lui apportez en plus de son entraînement.
Imaginez le modèle comme un poisson rouge. À chaque nouvelle conversation, il a tout oublié de ce que vous avez pu lui dire auparavant. Vous repartez de zéro.
Au fil d'une discussion, vous allez donc lui ajouter du contexte, petit à petit. Mais attention, ce contexte n'est pas infini. Et surtout, plus le modèle en accumule, plus il a tendance à diverger et à faire un peu n'importe quoi.
C'est contre-intuitif, parce que les chiffres annoncés donnent le vertige. Certains modèles comme Opus 4.6 affichent une fenêtre de contexte ("context window") d'un million de tokens. Dans les faits, d'après mon expérience, la qualité se dégrade bien avant d'atteindre cette limite, souvent au-delà de quelques centaines de milliers de tokens.
Le contexte est aujourd'hui le point le plus important à surveiller pour bien utiliser l'IA. On verra plus loin que la plupart des bonnes pratiques ne servent qu'à une chose : en consommer le moins possible.
Harness
Le harness, c'est l'environnement dans lequel votre modèle tourne. Codex CLI, Codex App, Claude Code, AmpCode ou Pi sont autant de harness différents.
Son rôle est double. D'abord, il fournit au modèle des pré-instructions, qui vont définir des agents (on y revient juste après). Ensuite, et c'est surtout ça qui fait sa puissance, il met à disposition du modèle une série d'outils (tools) qu'il pourra utiliser.
Un même modèle peut donner des résultats très différents selon le harness dans lequel vous le faites tourner. Le modèle est le cerveau, le harness est tout ce qu'il y a autour pour le rendre utile.
Tools
Un tool, c'est un outil mis à disposition par le harness pour étendre les capacités du modèle.
Souvenez-vous : un modèle, seul, n'est rien d'autre qu'un prédicteur de texte. Il ne peut rien faire d'autre que produire des mots. Il lui faut donc des outils pour agir sur le monde réel : lire un fichier sur votre système, en écrire un, lancer une commande, et ainsi de suite.
Chaque harness fournit ce genre d'outils de base, mais certains vont plus loin que d'autres. Dans l'application Codex, par exemple, un outil autorise l'agent à piloter un navigateur intégré. Il peut alors tester votre interface lui-même et corriger en fonction de ce qu'il voit à l'écran.
Agents
Un agent n'est rien de plus qu'un modèle auquel on a ajouté trois choses : une pré-instruction, des autorisations précises, et un ensemble d'outils mis à sa disposition.
C'est tout. Quand vous utilisez les modes "Plan" ou "Build" de votre harness, vous utilisez en réalité des agents : le même modèle de base, mais avec des instructions et des permissions différentes selon ce qu'on attend de lui.
Une image pour fixer l'idée : le modèle est un acteur, et l'agent est le rôle qu'on lui confie. Même acteur, mais selon le script qu'on lui donne (ses instructions) et ce qu'on l'autorise à faire sur le plateau (ses outils et permissions), il jouera un personnage complètement différent.
Sous-agents
Le facteur clé pour bien utiliser l'IA, c'est de garder le contexte aussi léger que possible. C'est exactement le rôle d'un sous-agent : un agent appelé par l'agent principal pour accomplir une mission précise et ne lui remonter que le résultat.
Imaginez que vous demandiez à votre agent d'intégrer une nouvelle librairie qu'il ne connaît pas. Sans sous-agent, l'agent principal devrait lire la documentation en entier, parcourir plusieurs pages, peut-être quelques exemples sur le web, et tout ça viendrait remplir son contexte. Une fois la réponse trouvée, le mal est fait : son contexte est déjà encombré de pages dont il n'a plus besoin.
Pour éviter ça, l'agent principal va mandater un sous-agent. Celui-ci part lire la documentation, fouille les exemples, fait le tri, puis remonte une réponse concise du type "voici comment s'installe et s'utilise cette librairie". Le contexte du sous-agent a grandi, mais il est ensuite jeté. L'agent principal, lui, ne récupère que l'essentiel.
Pour reprendre l'image de l'acteur : l'agent principal reste sur scène, et il envoie un assistant en coulisses faire une recherche. L'assistant revient avec la réponse, sans encombrer la scène de tout ce qu'il a dû consulter pour la trouver.
Skills
Un skill, c'est une compétence chargée à la demande. Et là encore, l'objectif est le même : garder le contexte léger.
Souvenez-vous de notre poisson rouge. À chaque conversation, le modèle a tout oublié et doit donc réapprendre une foule de choses. On pourrait lui réexpliquer à chaque fois l'intégralité de nos conventions, mais ce serait gâcher un contexte précieux pour des informations dont il n'a pas toujours besoin.
Un skill résout ça. Vous mettez un savoir dans un fichier, et vous décrivez quand ce savoir doit être chargé. Le harness garde en mémoire la liste de vos compétences et leur description, mais il ne charge le contenu complet d'un skill que lorsque le modèle en a réellement besoin.
C'est très pratique pour expliquer au modèle votre façon de coder et vous assurer qu'il respecte vos design patterns et vos préférences. La plupart des workflows IA que vous croiserez (y compris celui que je vous présenterai plus loin) ne sont au fond qu'une suite de skills bien définis.
MCPs
Un MCP (Model Context Protocol) est un protocole standard qui permet à un agent de se connecter à un service externe et de l'utiliser.
Concrètement, un serveur MCP expose deux choses : des outils que l'agent peut appeler (effectuer une action, interroger un service) et des informations qui lui expliquent comment s'en servir. Vous pouvez le voir comme une prise universelle : plutôt que d'apprendre à chaque agent comment parler à chaque service, on standardise la prise, et n'importe quel agent peut s'y brancher.
Par exemple, un MCP GitHub peut permettre à un agent de lire vos issues, créer des pull requests ou commenter du code. Un système ferroviaire pourrait exposer un MCP permettant de rechercher des trains ou consulter des horaires.
L'agent n'a pas besoin de connaître les détails de ces services à l'avance : le MCP lui fournit les outils disponibles ainsi que leur mode d'emploi.
Contrairement à un skill, qui ne charge son contenu qu'au moment où on en a besoin, un MCP injecte en général la description de tous ses outils dès qu'il est branché, et elle reste dans le contexte toute la session, que vous les utilisiez ou non. Un serveur qui expose vingt outils, c'est vingt descriptions qui occupent le contexte en permanence. La règle est donc simple : ne branchez que les MCPs dont vous avez réellement besoin.
Compaction
On arrive au dernier terme, et ce n'est pas un hasard si je l'ai gardé pour la fin : la compaction est la réponse directe au problème qui traverse tout ce chapitre, le contexte qui se remplit.
La compaction est un mécanisme qui résume le contexte actuel pour le rendre plus léger. Quand une conversation devient trop longue et que le contexte approche de ses limites, le harness prend tout ce qui s'est dit et en produit une version condensée, sur laquelle le modèle continue à travailler.
C'est utile, mais ce n'est pas magique. Qui dit résumé dit perte d'information : en compactant, on jette forcément des détails au passage. Le modèle peut alors oublier une décision prise plus tôt, ou une contrainte que vous aviez précisée. C'est pour ça que la compaction est un filet de sécurité, pas une solution. Mieux vaut éviter de remplir son contexte au point d'en avoir besoin, plutôt que de compter dessus.
Et c'est exactement là que tout ce vocabulaire prend son sens. Harness, agents, sous-agents, skills, MCPs : tous ces outils ne servent au fond qu'une seule chose, vous aider à garder le contexte léger pour ne pas en arriver à compacter dans l'urgence.
Cadrer l'IA
Je ne le répéterai jamais assez : votre objectif principal, en tout cas avec les outils actuels, c'est de réduire le contexte que vous consommez, et de rester dans une limite raisonnable. Certains harness permettent même de forcer un plafond plus bas.
Votre modèle reste un poisson rouge. Il ne sait rien de plus que ce qu'il a vu pendant son entraînement, et tout ce que vous voulez qu'il prenne en compte, c'est à vous de le lui fournir.
Beaucoup de développeurs concluent que si l'IA ne code pas comme eux, c'est qu'elle est mauvaise. Ce n'est pas le cas. Vous avez simplement l'habitude d'une certaine manière de coder, et l'IA en propose une autre. Ça n'a rien de grave, et surtout ça se corrige. Votre rôle n'est pas de subir ce qu'elle produit, mais de lui donner un cadre assez clair pour qu'elle code comme vous le souhaitez.
C'est aussi pour ça qu'une IA est presque toujours plus à l'aise dans une base de code qui existe déjà : elle peut s'appuyer sur l'existant pour comprendre vos conventions et les imiter.
Il faut aussi accepter une chose : le code "parfait" n'existe pas. Chercher la perfection est une illusion. Demandez à dix développeurs à quoi ressemble un code parfait, vous aurez dix réponses différentes. Le seul critère qui tienne sur la durée, c'est qu'un code soit maintenable et lisible par un humain.
On en a tous fait l'expérience : vous écrivez un bout de code, vous le relisez le lendemain, et vous vous demandez quel génie a bien pu pondre une horreur pareille. Si même nous ne sommes pas d'accord avec nous-mêmes d'un jour à l'autre, pourquoi attendre d'une IA qu'elle code exactement comme nous l'aurions fait ? Ce qui compte, ce n'est pas qu'elle reproduise vos habitudes à la virgule près, c'est que le résultat soit clair, cohérent, et que vous puissiez le maintenir.
Formaliser vos conventions
Une bonne façon de l'aider à s'aligner sur l'existant, c'est de lui faire faire le travail d'observation à votre place. Un prompt que j'aime bien lancer sur une base de code que je connais déjà :
Analyse cette codebase et repère les patterns récurrents qui te semblent intéressants à formaliser sous forme de skills.
L'IA parcourt le projet, repère vos conventions (comment vous structurez vos dossiers, nommez vos fichiers, organisez votre logique) et les formalise dans des skills réutilisables. Vous obtenez ainsi, presque gratuitement, un cadre que l'IA pourra recharger à la demande sur ce projet. C'est aussi un bon test : si les patterns qu'elle extrait ne correspondent pas à ce que vous pensiez avoir mis en place, c'est souvent le signe que votre code est moins cohérent que vous ne le croyiez.
Avec le temps, votre collection de skills devient une sorte de mémoire externe du projet. Chaque convention, chaque workflow récurrent, chaque décision importante peut être formalisée une fois puis réutilisée autant que nécessaire. Au lieu de réexpliquer les mêmes choses à chaque session, vous capitalisez progressivement sur ce que vous apprenez.
Les skills permettent donc de formaliser des connaissances chargées à la demande.
Le point d'entrée de votre projet
C'est précisément l'un des rôles du fichier AGENTS.md, placé à la racine de votre dépôt, est un pré-prompt que votre agent lira systématiquement au début de chaque conversation. C'est un format ouvert, compris par la plupart des harness, une sorte de README destiné non pas aux humains mais aux agents.
Il sert à préciser les points clés de votre projet : le gestionnaire de paquets que vous utilisez (yarn plutôt que npm, par exemple), vos conventions, vos décisions d'architecture.
Mais attention au piège, et c'est contre-intuitif : il ne faut surtout pas tout y mettre. C'est souvent ce qui arrive quand on lance bêtement la commande init de son harness, qui génère un fichier interminable. Or ce fichier est lu à chaque requête. S'il est trop gros, il pollue le contexte en permanence, exactement ce qu'on cherche à éviter. Pire : une information qui devient périmée (un chemin de fichier qui a changé, par exemple) ne se contente pas d'être inutile, elle induit activement l'agent en erreur.
La bonne approche est de garder un AGENTS.md court et ciblé, qui pointe vers le reste. Plutôt que de décrire la structure exacte de vos fichiers (instable, vite obsolète), décrivez les concepts et les capacités de votre projet (stables), et laissez le détail vivre ailleurs : dans des fichiers séparés, des AGENTS.md imbriqués, ou des skills, chargés seulement quand c'est nécessaire.
Mon workflow
Avant de rentrer dans le détail, une précision importante : je n'applique pas ce workflow à chaque demande.
Si je veux corriger un bug évident, renommer une variable ou générer un test simple, je vais souvent droit au but. Le workflow que je vais vous présenter est celui que j'utilise pour les fonctionnalités importantes, celles qui impliquent plusieurs décisions, plusieurs allers-retours ou qui vont vivre longtemps dans le projet.
Comme toujours avec l'IA, l'objectif n'est pas d'appliquer une méthode à la lettre. L'objectif est de trouver le niveau de structure adapté au problème qu'on cherche à résoudre.
Dans mon article précédent, je vous parlais de "prompting inversé" : au lieu d'attendre une réponse de l'IA, c'est moi qui me fais interroger par elle. Je continue à travailler ainsi, mais de façon bien plus structurée qu'avant.
Ce changement, je le dois en bonne partie à Matt Pocock. Il partage depuis plusieurs mois une série de skills et de réflexions sur l'ingénierie assistée par IA, dont plusieurs recoupent presque exactement ma propre manière de travailler.
Là où je faisais mon prompting inversé un peu à la main, ses skills viennent le formaliser et le pousser beaucoup plus loin. Une bonne partie du workflow que je décris ici s'appuie sur son travail, que je vous invite à aller lire directement.
Ce prompting inversé porte d'ailleurs un nom aujourd'hui : le grilling.
Grilling
Mon workflow commence donc par décrire la fonctionnalité que je veux construire, avec le plus d'informations possible, puis par appeler le skill /grill-with-docs.
Ce skill ouvre une session de grilling : à partir de mes informations, l'IA me cuisine de questions jusqu'à ce qu'elle et moi partagions une vision commune de ce qu'on va construire. C'est exactement le prompting inversé dont je parlais, mais mené avec méthode.
Un exemple concret vaut mieux qu'un long discours. À mon travail à la Fédération Internationale de Volleyball, on voulait créer un nouvel endpoint permettant à certains partenaires tiers de vérifier si un joueur est éligible pour participer à un tournoi. Pendant le grilling, l'IA m'a posé une première question :
La requête doit-elle prendre un identifiant de tournoi, en plus de la liste des joueurs à vérifier ?
J'ai répondu non. Je voulais quelque chose de générique, qui ne dépende pas d'un tournoi précis. Mais quelques questions plus loin, elle a resserré l'étau :
Pour ces vérifications d'éligibilité sans tournoi, quels cours obligatoires faut-il considérer ?
Et là, colle. Dans notre métier, certaines conditions sont globales, valables partout, mais d'autres sont spécifiques à un tournoi donné. Sans savoir de quel tournoi il s'agit, l'endpoint était tout simplement incapable de déterminer quelles règles appliquer. Ma volonté de "rester générique" était précisément ce qui cassait la fonctionnalité.
Rétropédalage : on prend finalement l'identifiant du tournoi dans la requête, ce qui permet de récupérer automatiquement tous les bons paramètres. Ma première intuition était mauvaise, et c'est le grilling qui me l'a montré, avant la moindre ligne de code.
Ce sont exactement les questions qu'un développeur expérimenté finirait par se poser, mais souvent trop tard, une fois le code écrit. Le grilling les fait remonter avant.
En parallèle, le skill demande au modèle d'écrire un fichier CONTEXT.md qui consigne le vocabulaire de notre application, le fameux Ubiquitous Language du DDD. L'objectif est double : s'assurer qu'on parle bien de la même chose, et faire en sorte que le modèle reprenne les bons termes quand il s'adresse à moi. Si nécessaire, il crée aussi des ADR (Architecture Decision Records) lorsqu'une décision serait surprenante sans le contexte complet du projet, difficile à revenir en arrière, ou qu'il s'agit d'un compromis assumé.
Il arrive qu'une question du grilling n'ait pas de réponse évidente. Dans ce cas, plutôt que de trancher à l'aveugle, je sors de la session pour aller tester. J'utilise /handoff pour décrire pourquoi je m'interromps et sur quelle question, puis /prototype pour construire un prototype jetable qui me permet d'expérimenter. Une fois la réponse trouvée, je reviens dans le grilling, mais cette fois avec une certitude plutôt qu'une intuition.
Product Requirements Document
Une fois la session de grilling terminée, j'enchaîne avec le skill /to-prd. Il ne relance pas d'entretien : il synthétise tout le contexte accumulé pendant le grilling pour en tirer un PRD (Product Requirements Document).
Ce document rassemble le problème qu'on cherche à résoudre, la solution imaginée, une série de user stories et les détails d'implémentation. En clair, tout ce qu'il faut pour qu'une personne (ou une IA) puisse se mettre au travail sans avoir assisté à la discussion.
Vous pouvez en voir un exemple concret sur le GitHub de mon site, pour l'ajout des tags sur les articles.
Issues
Un PRD peut être court et simple, mais aussi long et complexe. Pour éviter de donner trop de travail d'un coup au modèle (souvenez-vous de la règle clé : limiter l'usage du contexte), on le découpe avec le skill /to-issues.
Ce skill fractionne le PRD en plusieurs issues, chacune simple à traiter et, autant que possible, indépendante des autres. Il vous propose d'abord un découpage, puis crée les issues une fois que vous l'avez validé.
L'intérêt est double. D'une part, chaque issue tient dans un contexte raisonnable, donc le modèle reste concentré et performant. D'autre part, en gardant des unités de travail petites et non bloquantes, vous pouvez avancer issue par issue sans qu'une modification en casse une autre à l'autre bout du projet.
Implémentation
À ce stade, c'est à vous de décider de la suite. Jusqu'ici, on n'a fait que planifier proprement la fonctionnalité, un travail qui devrait de toute façon être fait, avec ou sans IA.
Vous pouvez donc vous arrêter là et coder la fonctionnalité vous-même. Ou bien laisser l'IA s'en charger.
Dans mon cas, j'utilise le skill /handoff, une sorte de compaction maîtrisée. Là où la compaction automatique résume votre conversation dans l'urgence en perdant des détails au passage, le handoff produit volontairement un document de passation propre, conçu pour qu'un autre agent reprenne le travail sans rien connaître de la discussion d'origine. La différence est de taille : c'est vous qui décidez de ce qui mérite d'être transmis, pas un mécanisme déclenché à la dernière minute.
Concrètement, dans l'application Codex, je formule une seule demande du type : "Crée un /handoff par issue actionnable, puis lance un thread sur chacun pour implémenter la fonctionnalité." (Certaines issues pouvant être bloquées par d'autres, seules les issues actionnables sont traitées.)
L'agent génère alors les documents de passation, puis démarre lui-même un thread par handoff, chacun avec son propre worktree, et les laisse travailler en autonomie. Quelques minutes plus tard, je me retrouve avec autant de pull requests que d'issues. Et comme chaque issue avait un scope réduit, ces PR sont simples à relire.
Conclusion
Revenons à mon aveu du début : presque pas une ligne de code écrite à la main depuis six mois. Dit comme ça, on dirait l'exact opposé de ce que je défendais dans mon article précédent. En réalité, c'est la même position, poussée plus loin.
Je n'ai pas laissé l'IA piloter. J'ai gardé la main sur tout ce qui compte : comprendre le problème, challenger la solution pendant le grilling, fixer le vocabulaire, découper le travail, relire chaque pull request. Ce que j'ai délégué, c'est la frappe au clavier, pas la réflexion. Et tout le workflow que je viens de décrire n'a qu'un seul but : garder ce contrôle tout en laissant l'IA faire ce qu'elle fait de mieux.
C'est aussi pour ça que ce n'est pas du vibe coding. Le vibe coding consiste à accepter un résultat sans regarder le chemin. Ici, c'est l'inverse : on passe l'essentiel de son temps sur le chemin (la conception, le découpage, les décisions) et l'IA ne s'occupe que de la dernière étape.
L'outil a énormément progressé depuis novembre 2025. Mais le principe, lui, n'a pas bougé d'un pouce. L'IA n'écrit pas le code à votre place, elle l'écrit sous votre direction. Et c'est encore et toujours à vous d'être responsable de ce qui part en production.