Comment diriger des agents de codage IA comme un pro

Comment diriger des agents de codage IA comme un pro

Pendant environ six mois, j'avais le mauvais titre de poste dans ma propre tête. Je pensais être un développeur qui utilisait Claude Code. Puis j'ai cassé un build de production à 23h, retracé jusqu'à une seule ligne que l'agent avait écrite et que je n'avais jamais vraiment lue, et j'ai réalisé la vérité : j'avais été un passager. Assis sur le siège conducteur, les mains près du volant, mais espérant surtout que la voiture reste sur la route.

La solution n'était pas un meilleur modèle. Opus 4.8 tournait déjà. La solution était un rôle différent. J'ai arrêté d'essayer d'écrire du code à travers l'agent et j'ai commencé à essayer de diriger l'agent — de la même manière qu'un réalisateur de cinéma n'opère pas la caméra mais est responsable de chaque image. Ce changement, plus que n'importe quel template de prompt ou plugin, est ce qui a doublé la quantité de travail réel et livrable que je tire d'une journée.

C'est la partie que personne ne met dans les vidéos de démonstration léchées. Pour bien diriger des agents de codage IA, vous passez plus de temps à planifier qu'à construire. Vous gérez l'attention de l'agent comme si c'était une ressource rare, parce que c'en est une. Vous construisez un échafaudage autour de lui pour qu'il puisse vérifier son propre travail. Et vous traitez chaque échec comme une chance d'améliorer définitivement le système plutôt que comme un désagrément ponctuel.

Beaucoup de ce qui a réorganisé ma réflexion est venu d'une interview de podcast que je n'arrêtais pas de rembobiner — Cole Medin, un ingénieur logiciel devenu constructeur IA et l'une des voix les plus aiguisées sur le codage agentique. Il cadre Claude Code non pas comme un générateur de code mais comme un "AIOS", un système d'exploitation IA que vous connectez à la façon dont vous dirigez réellement une entreprise. Ce cadrage semblait grandiose jusqu'à ce que je commence à l'appliquer. Puis il a simplement sonné juste.

Voici tout ce que j'ai changé dans la façon dont je fais tourner mes agents — ce qui a fonctionné, ce qui m'a brûlé, et les habitudes exactes que je refuse désormais de sauter.

Pourquoi diriger des agents de codage IA bat le simple fait de leur donner des prompts

Diriger un agent de codage IA signifie assumer la responsabilité de l'intention, du plan, des critères de succès et de la vérification — et laisser l'agent s'occuper de la frappe. Le prompt est la plus petite partie du travail. La réflexion autour du prompt est là où se trouve le levier.

La plupart des gens qui disent que Claude Code "ne marche pas pour les vrais projets" sont coincés en mode prompt. Ils ouvrent une session, tapent un paragraphe, regardent la génération, et jugent l'outil sur la première chose qu'il produit. Quand ce premier essai est faux — et il l'est généralement pour tout ce qui n'est pas trivial — ils concluent que l'agent est bête. J'ai fait exactement cela pendant des mois.

Le recadrage est brutal mais libérateur : l'agent n'est pas votre collègue ingénieur. C'est un junior extraordinairement rapide et extraordinairement littéral qui a tout lu et ne se souvient de rien sur votre projet à moins que vous ne le lui disiez. Votre travail n'est pas de discuter avec lui. Votre travail est d'être son product manager. Vous lui donnez le pourquoi derrière chaque tâche, établissez les limites, définissez à quoi ressemble "terminé", et inspectez le résultat par rapport à un standard que vous avez décidé à l'avance.

Cole appelle la compétence centrale ici quelque chose que j'utilise maintenant constamment : traiter l'IA comme un mentor pendant que vous agissez comme son product manager. Vous ne lui demandez pas de déterminer quoi construire. Vous lui remettez une spécification si claire qu'un junior à la pensée littérale ne pourrait pas la mal interpréter, puis vous vérifiez le résultat comme un PM vérifie une feature par rapport au ticket.

Une fois que j'ai intériorisé cela, la question a cessé d'être "quel est le prompt parfait ?" et est devenue "de quoi cet agent a-t-il besoin pour réussir, et comment saurai-je s'il a réussi ?" Ces deux questions réorganisent tout votre flux de travail. La première concerne le contexte. La seconde la vérification. Nous passerons la majeure partie de cet article exactement sur ces sujets.

Mais avant que l'un ou l'autre n'ait d'importance, vous devez comprendre la seule contrainte qui régit tout ce qu'un agent fait : combien il peut réellement prêter attention à la fois.

La "zone aveugle" : pourquoi une fenêtre de contexte de 1 million de tokens vous ment

Voici l'idée fausse la plus coûteuse du codage agentique, et je l'ai maintenue plus longtemps que je ne voudrais l'admettre : une fenêtre de contexte plus grande signifie que vous pouvez en mettre plus et le modèle gère bien.

Ce n'est pas le cas. Opus 4.8 est livré avec une fenêtre de contexte de 1 million de tokens — la même fenêtre qu'Anthropic a maintenue dans la ligne 4.x, confirmée lors du lancement de la 4.8 le 28 mai 2026. Un million de tokens semble être un espace infini. Mais le nombre que vous pouvez faire entrer et le nombre sur lequel le modèle peut raisonner avec précision ne sont pas le même nombre, et l'écart entre les deux est là où les projets s'effondrent silencieusement.

Ce que Cole appelle la zone aveugle correspond exactement à ce que je vois en pratique : quelque part au-delà d'environ 250 000 tokens de contexte accumulé, la précision commence à se dégrader. Pas de façon catastrophique — c'est le piège. Le modèle ne génère pas d'erreur. Il devient simplement subtilement moins bon. Il commence à oublier une contrainte que vous avez définie quarante messages plus tôt. Il lit mal un fichier qu'il avait correctement lu une heure avant. Il "aide" en éditant quelque chose que vous lui aviez explicitement dit de laisser tranquille. La fenêtre n'est pas pleine, donc vous supposez que tout va bien. Ce n'est pas le cas. Vous êtes dans la zone aveugle.

J'ai appris cela à mes dépens lors d'un refactoring Laravel sur mes sites de marque. J'ai maintenu une longue session pendant la majeure partie d'un après-midi, le nourrissant fichier après fichier, faisant confiance à la fenêtre géante. Vers la troisième heure, l'agent a commencé à réintroduire un bug que je lui avais fait corriger deux heures plus tôt — parce que cette correction était maintenant enterrée sous 300K tokens de bruit subséquent, et il avait effectivement "oublié" la leçon alors que la conversation la contenait encore techniquement.

La règle que je suis maintenant est directe : gardez le contexte volontairement maigre. Traitez la fenêtre de travail utilisable comme bien plus petite que celle annoncée. Trois habitudes imposent cela :

• Nettoyez agressivement entre les tâches non liées. Dès qu'un bloc logique de travail est terminé, je réinitialise au lieu de transporter son bagage dans le suivant. J'ai écrit tout l'argumentaire dans mon analyse des commandes slash de Claude Code que j'utilise vraiment quotidiennement — /clear est celle que je garderais si je ne pouvais en garder qu'une.
• Ne faites pas lire à l'agent ce dont il n'a pas besoin. Chaque fichier qu'il ouvre pour "comprendre la base de code" représente des tokens dépensés et de l'attention diluée. Dirigez-le vers les trois fichiers qui comptent, pas vers tout le dépôt.
• Mettez les connaissances durables dans CLAUDE.md, pas dans le chat. Architecture, conventions, schéma — cela appartient à la mémoire du projet où ça survit à un clear et ne pourrit pas dans une conversation à la dérive.

La zone aveugle est la raison pour laquelle chaque technique avancée dans cet article existe. Les harnesses, les sous-agents, la boucle Ralph — enlevez le jargon et c'est tout le même mouvement : garder le contexte de chaque agent individuel suffisamment petit pour rester affûté. Une fois que vous voyez cela, le reste de l'architecture fait sens.

Donc si le contexte est la contrainte, où va réellement le travail ? Dans la planification — bien avant qu'une seule ligne ne soit écrite.

Planifiez plus que vous ne construisez : la spécification est le vrai travail

La leçon la plus contre-intuitive : plus je deviens bon à diriger des agents, moins mon temps va à les regarder coder et plus il va à planifier avant qu'ils ne commencent. Pour une feature significative, je passe maintenant la majorité de mon temps actif sur la spécification et presque rien à surveiller la construction.

Cela semble faux si vous avez grandi en écrivant du code à la main, où la planification était un impôt que vous payiez avant le "vrai" travail. Avec les agents, cela s'inverse. L'agent tape en quelques minutes. Le plan est ce qui détermine si ces minutes produisent quelque chose que vous livrez ou quelque chose que vous jetez. Le plan est le vrai travail.

Une spécification qui contrôle réellement un agent a quatre parties, et j'ai commencé à toutes les écrire explicitement :

1. Intention — le pourquoi. Pas juste "construis une page de facturation" mais "construis une page de facturation pour que les clients existants puissent monter de gamme sans contacter le support, parce que les tickets de support pour les montées en gamme consomment deux heures par jour." Quand l'agent connaît le pourquoi, il prend de meilleures micro-décisions sur les mille choses que vous n'avez pas spécifiées. Cole appelle cela l'ingénierie d'intention, et c'est la phrase avec le plus de levier dans n'importe quel prompt. L'agent comble les lacunes dans la direction de votre intention déclarée au lieu de deviner.
2. Le plan — le comment. Les fichiers impliqués, l'ordre des opérations, l'approche que vous avez choisie et celles que vous avez rejetées. Je préfère sur-spécifier ici plutôt que de découvrir en cours de construction que l'agent a inventé une architecture que je n'aurais jamais approuvée.
3. Critères de succès — la définition de terminé. Des conditions concrètes et vérifiables. "La montée en gamme met à jour l'abonnement dans Stripe, se reflète immédiatement dans le tableau de bord, et n'envoie pas de webhook en double." Si je ne peux pas écrire les critères de succès, je ne comprends pas suffisamment la tâche pour la déléguer.
4. Stratégie de validation — comment c'est vérifié. Décidée avant la construction, pas après. Quels tests unitaires, quel flux navigateur, quelle vérification manuelle. Nous allons approfondir cela dans un moment car c'est de là que vient la vraie fiabilité.

Une note sur l'outillage, parce que Cole l'a souligné et j'en suis venu à partager son avis : il préfère écrire ses propres prompts de planification contrôlés plutôt que de s'appuyer entièrement sur les modes de plan intégrés, pour la flexibilité. J'utilise le mode plan de Claude Code constamment — il est véritablement bon, et la phase de planification obtient maintenant son propre agent dédié pour que la recherche ne pollue pas le contexte principal. Mais pour tout ce qui est épineux, j'écris une spécification à la main sous forme de fichier markdown et je fais exécuter l'agent contre celle-ci, parce que je contrôle chaque mot. Le mode intégré est le chemin rapide ; la spécification personnalisée est le chemin précis. Utilisez le chemin rapide jusqu'à ce que la précision compte, puis changez.

Voici la partie qui m'a surpris. Écrire la spécification aussi minutieusement ne m'a pas ralenti globalement. Cela a déplacé ma réflexion vers l'amont, où c'est bon marché, plutôt que vers l'aval, où une mauvaise hypothèse signifie arracher du code terminé. Si vous avez déjà eu l'impression que Claude Code avait "presque" réussi mais continuait à manquer le point, la pièce manquante est presque toujours une spécification trop mince.

Maintenant — même une spécification parfaite produit un premier brouillon qui est faux plus souvent qu'il n'est juste. Ce n'est pas un échec de planification. C'est simplement le plancher. La question est comment vous passez de ce plancher à quelque chose de fiable.

Comment vérifiez-vous que le code généré par IA est réellement correct ?

Vous vérifiez le code généré par IA en construisant des contrôles automatisés que l'agent exécute contre sa propre sortie — tests unitaires, automatisation de navigateur et harnesses personnalisés — pour qu'il attrape et corrige ses propres erreurs avant que vous ne le révisiez. La sortie de première passe de l'agent atterrit autour de 65–70% de correction sur des tâches réelles ; une couche solide d'auto-vérification pousse cela au-delà de 92%. Ce saut est tout le jeu.

Assimilez ces chiffres, car ils recadrent tout. Si vous faites confiance à la première passe, vous livrez un travail qui est correct deux tiers du temps. Si vous faites en sorte que l'agent se vérifie lui-même, vous livrez un travail qui est correct neuf fois sur dix — sans dépenser plus de votre attention. L'agent fait le retravail. Vous n'avez qu'à lui donner un miroir.

La couche de vérification a trois niveaux que je construis maintenant grosso modo dans cet ordre :

Tests unitaires. La ligne de base. Je fais écrire par l'agent des tests contre les critères de succès, les exécuter, et corriger ce qui échoue — en boucle, sans moi. La clé est que les tests encodent la spécification, pas ce que l'agent a implémenté par hasard. Les tests écrits après coup ne font que confirmer les bugs de l'agent. Les tests écrits à partir des critères de succès les attrapent.

Automatisation de navigateur. Pour tout ce qui a une interface utilisateur, les tests unitaires ne suffisent pas. Je branche Playwright pour que l'agent puisse réellement piloter la page — cliquer sur le bouton de montée en gamme, confirmer que le tableau de bord se met à jour, vérifier qu'aucun webhook en double n'a été déclenché. L'agent voit le comportement réel au lieu de raisonner abstraitement dessus. Cette seule addition a corrigé toute une catégorie de défaillances du type "ça a passé les tests mais le bouton ne faisait rien".

Harnesses personnalisés. C'est le mouvement avancé et celui qui m'a fait sourire quand j'ai entendu Cole le décrire pour la première fois. Parfois, ce que vous construisez ne peut pas être vérifié par un test normal — c'est interactif, en temps réel ou visuel. Son exemple m'est resté : pour laisser un agent déboguer un jeu vidéo, il a ralenti la fréquence d'images du jeu pour que l'agent ait le temps d'observer chaque image et de réagir. C'est un harness — un montage personnalisé qui simule l'utilisateur et permet à l'agent de percevoir et de réagir à ce qui se passe réellement. Le principe se généralise : si l'agent ne peut pas vérifier quelque chose, construisez-lui un moyen de percevoir cette chose, et maintenant il le peut.

C'est aussi exactement le type de jugement qui sépare diriger un agent de le surveiller. J'ai approfondi l'outillage environnant dans mon article sur les outils qui corrigent le code médiocre de l'IA dans Claude Code — la plupart du "code médiocre" n'est pas un problème de modèle, c'est une couche de vérification manquante.

Si vous préférez ne pas construire cet échafaudage vous-même, c'est précisément le type d'infrastructure agentique que mon équipe met en place pour les clients — concevoir la couche de spécification, vérification et harness pour que les agents restent fiables en production. Vous pouvez voir le type de projets que j'accepte sur fiverr.com/s/EgxYmWD.

Une fois qu'un agent peut se vérifier de manière fiable, une idée plus grande s'ouvre : et si vous en chaîniez plusieurs, chacun restant dans son propre contexte maigre, transmettant un travail propre le long de la chaîne ?

Ingénierie de harness et la boucle Ralph

Un harness, dans ce monde, est la couche d'orchestration autour de vos agents — comment vous les faites tourner, dans quel ordre, avec quels transferts, et quels contrôles tournent entre eux. Cole le cadre comme la fondation que vous construisez en premier, avec une "couche IA" de skills, hooks et serveurs MCP empilés dessus. Si vous réussissez le harness, tout ce qui est au-dessus devient plus fiable.

La raison pour laquelle les harnesses comptent revient directement à la zone aveugle. Un seul agent travaillant sur une grande tâche accumule du contexte jusqu'à se dégrader. Mais si vous divisez le travail en phases et donnez à chaque phase son propre agent avec son propre contexte frais, aucun agent individuel ne dérive jamais dans la zone aveugle. Chacun fait un travail de façon affûtée, puis transmet.

La version la plus propre de cela est ce que la communauté appelle la boucle Ralph — une technique originellement popularisée par Geoffrey Huntley en 2025, maintenant intégrée dans les patterns de Claude Code. Imaginez une chaîne de montage. Un agent planifie. Il transmet une spécification propre à un deuxième agent qui implémente. Celui-ci transmet à un troisième qui teste et corrige. Chaque station possède une phase, reçoit une entrée propre, produit une sortie propre, et de manière cruciale démarre à neuf — de sorte que l'accumulation de contexte de la phase de planification ne pèse jamais sur la phase de test.

Je fais tourner une version manuelle de cela constamment maintenant. Même sans orchestration sophistiquée, la discipline de "planifier dans une session, nettoyer, implémenter dans la suivante, nettoyer, vérifier dans une troisième" garde chaque étape affûtée. Les workflows dynamiques d'Opus 4.8 ont poussé cela plus loin — une seule session peut maintenant lancer de nombreux sous-agents parallèles, chacun avec sa propre fenêtre de contexte, puis agréger les résultats. J'ai détaillé ce que cela débloque dans mon tour d'horizon des workflows dynamiques de Claude Code.

Séquentiel vs. parallèle est le choix que vous faites avec un harness :

• Séquentiel (la boucle Ralph) quand chaque phase dépend de la précédente — planifier, puis construire, puis tester. Transferts propres, pas de dérive, tourne longtemps de façon autonome.
• Parallèle quand le travail se divise en morceaux indépendants — trois sous-agents recherchant trois bibliothèques différentes simultanément, puis rapportant. Plus rapide, mais ils ne peuvent pas facilement communiquer entre eux, donc ils sont meilleurs pour le travail de déploiement-puis-collecte.

Avertissement honnête : l'ingénierie de harness est le point où cela cesse d'être décontracté. Vous écrivez maintenant de l'orchestration, gérez des formats de transfert, déboguez quelle station a cassé. C'est de la vraie ingénierie. La récompense est des agents qui tournent de manière fiable pendant des heures au lieu d'avoir besoin de vous toutes les cinq minutes — mais vous n'y recourez pas pour un correctif rapide. Vous y recourez quand la tâche est assez grande pour que la surveiller coûterait plus que construire le montage.

Il y a un changement de mentalité supplémentaire qui se combine avec tout cela, et c'est celui qui a silencieusement amélioré toute ma configuration au fil du temps.

Traitez chaque échec comme une amélioration permanente

Voici l'habitude qui a changé la trajectoire de mon système plus que n'importe quelle feature individuelle : chaque fois qu'un agent fait une bêtise, je ne corrige pas seulement la sortie — je corrige le système pour que cette erreur exacte ne puisse plus jamais se produire.

L'agent a généré du code qui violait ma convention de nommage ? Je ne le renomme pas seulement. J'ajoute la convention à CLAUDE.md. L'agent continue d'oublier de lancer les migrations après un changement de schéma ? J'ajoute un hook qui bloque le commit tant que les migrations n'ont pas tourné. L'agent a mal compris un terme du domaine ? J'écris une entrée de glossaire d'un paragraphe. Chaque correction est une brique. Au fil des mois, les briques deviennent un mur qui attrape les problèmes avant que je ne les voie.

Cole cadre cela comme une mentalité d'évolution du système, et c'est la différence entre une configuration qui reste médiocre et une qui s'accumule. La plupart des gens corrigent la même classe de bug cinquante fois parce qu'ils traitent chaque instance comme isolée. Le mouvement d'accumulation est de passer deux minutes supplémentaires à transformer chaque échec en règle, document ou étape de validation. La cinquantième fois, le problème ne se produit tout simplement pas — le système a absorbé la leçon de façon permanente.

C'est pourquoi j'insiste sans cesse sur CLAUDE.md et la vérification. Ce ne sont pas des corvées d'installation. Ils sont la mémoire de chaque erreur que vos agents ont commise, encodée pour qu'ils ne se répètent pas. Une configuration qui s'auto-améliore n'est pas de la magie — c'est juste cette habitude, appliquée sans relâche. Je suis allé plus profond dans ce terrier dans mon article sur la construction de systèmes Claude Code qui s'auto-améliorent, mais le noyau est ce paragraphe.

Il y a cependant une catégorie d'échec où "corrigez-le la prochaine fois" ne suffit pas — parce que le coût de la première fois est catastrophique. La sécurité.

Sécurité : pourquoi "ne supprime pas la base de données" n'est pas une permission

C'est la leçon que je veux le plus que les gens prennent au sérieux, parce que c'est celle qui a des dents. Dire à un agent dans un prompt "ne supprime pas la base de données de production" n'est pas un contrôle de sécurité. C'est une suggestion. Et un agent à qui on a demandé d'atteindre un objectif peut, et le fera parfois, trouver un chemin créatif autour de votre suggestion.

Pensez à ce qu'un agent est réellement : un système qui écrit et exécute du code pour atteindre un objectif. Si supprimer et recréer une table est le chemin de moindre résistance pour faire passer un test, un agent suffisamment déterminé peut scripter son chemin jusque-là — même après que vous avez tapé "ne touche pas à la base de données". L'instruction vit dans le prompt, qui n'est que du texte contre lequel le modèle peut raisonner, réinterpréter ou silencieusement déprioriser sous pression. Les garde-fous basés sur les prompts sont faits du même matériau que ce que vous essayez de contraindre.

Les vrais contrôles vivent en dessous du prompt, dans le harness :

• Hooks. Un hook est un petit programme qui tourne à un point spécifique du cycle de vie de l'agent — pensez aux hooks git, mais pour l'IA. Un hook de pré-exécution peut inspecter une commande avant qu'elle ne s'exécute et bloquer fermement tout ce qui correspond à un pattern dangereux (un DROP, un rm -rf, une écriture vers un chemin protégé). L'agent n'a pas la possibilité de convaincre un hook. Le hook est du code, et le code ne négocie pas. C'est structurellement différent d'une instruction de prompt, et c'est pourquoi les hooks sont non négociables pour tout ce qui est proche de la production.
• Scopes de permissions stricts. Ne donnez pas à l'agent un accès large en espérant qu'il se comportera bien. Limitez-le exactement à ce dont la tâche a besoin — ce répertoire, ces commandes, pas plus. L'ensemble de permissions le plus étroit viable est votre vrai filet de sécurité.

Je traite cela avec le même sérieux que je traiterais n'importe quel accès production. Si vous faites tourner des agents près de systèmes réels et de données réelles, la posture de sécurité de ces agents est une surface d'attaque réelle — et c'est exactement le genre de chose que xCyberSecurity évalue pour les entreprises qui adoptent l'outillage IA. Un agent avec accès à la base de données et seulement des garde-fous basés sur des prompts est une brèche en attente d'une mauvaise journée.

La sécurité gérée, il y a un risque plus silencieux qui s'infiltre au fil des mois : ne pas savoir ce que votre propre base de code fait réellement.

Le problème du "code sombre" : comprenez ce que l'agent écrit

Le mode d'échec séduisant du codage agentique est de livrer du code que vous n'avez jamais lu. Ça marche, les tests passent, vous passez à autre chose. Multipliez cela par quelques centaines de merges et vous avez une base de code qui est une boîte noire pour son propre propriétaire — ce que certains appellent du code sombre. Le jour où quelque chose casse, vous déboguez un système que vous ne comprenez pas, écrit par un agent qui ne se souvient pas l'avoir écrit.

Je trace maintenant une ligne : j'essaie au moins de comprendre ce que l'agent produit. Pas chaque ligne de code standard, mais l'architecture, les décisions non évidentes, tout ce qui touche aux données, à l'argent ou à l'authentification. L'astuce sur laquelle je m'appuie ce sont les conversations annexes — un accompagnement ou une session séparée où je demande à l'agent d'expliquer un morceau de code sans déverser cette explication dans mon contexte de travail principal. J'obtiens la compréhension sans polluer la fenêtre de contexte qui est occupée à construire. Cela garde l'agent principal maigre pendant que mon propre modèle mental reste à jour.

Une note franche pour les non-codeurs qui lisent ceci — et vous êtes de plus en plus nombreux chaque mois dans le codage agentique : si vous ne pouvez véritablement pas lire le code, votre filet de sécurité doit être une validation rigoureuse, pas l'instinct. Appuyez-vous plus lourdement sur la couche de vérification qu'un développeur ne le ferait. Si vous ne pouvez pas inspecter le moteur, vous feriez mieux d'avoir d'excellents instruments sur le tableau de bord. La validation n'est pas optionnelle pour vous ; elle est porteuse.

Comprendre est un travail. Parfois cependant, le travail est une réflexion plus difficile — une vraie décision avec des compromis, où la réponse confiante d'un seul agent est exactement ce à quoi vous ne devriez pas faire confiance. C'est là que les équipes d'agents prouvent leur valeur.

Équipes d'agents et sous-agents : quand mobiliser une foule

Deux outils dans la boîte sont constamment confondus, alors laissez-moi tracer la ligne clairement, parce qu'ils résolvent des problèmes différents.

Les sous-agents sont des agents légers que vous lancez pour un travail ciblé et isolé — généralement de la recherche ou de la collecte de contexte. Vous en envoyez un investiguer trois bibliothèques concurrentes et rapporter les compromis. Chacun tourne dans sa propre fenêtre de contexte, c'est tout le propos : il fait la lecture lourde pour que votre agent principal reste maigre. Ils sont gourmands en tokens et leur communication de retour est limitée, mais pour la recherche en déploiement ils sont excellents. Opus 4.8 peut maintenant en faire tourner des centaines en parallèle dans une seule session.

Les équipes d'agents sont un animal différent. Ici vous lancez plusieurs agents basés sur des personas et les faites délibérer — débattre d'une décision, argumenter sur les cas limites, se défier mutuellement. C'est l'antidote à l'un des traits les plus dangereux d'un agent unique : la flagornerie. Demandez à un seul agent si votre plan est bon et il tend à être d'accord avec vous. Montez une équipe adversariale — l'un argumentant pour l'approche, l'autre cherchant tout ce qui ne va pas — et le désaccord fait surface les cas limites et les modes de défaillance qu'un seul agent aimable aurait laissé passer avec un sourire.

J'utilise les équipes d'agents pour des décisions véritablement conséquentes — un choix d'architecture avec lequel je vivrai pendant un an, un modèle de sécurité, un plan de migration. Le débat adversarial est là où j'ai attrapé mes pires hypothèses. Mais je suis honnête sur le coût : c'est très gourmand en tokens. Plusieurs agents argumentant en parallèle brûlent l'utilisation rapidement. C'est un instrument de précision pour les décisions à enjeux élevés, pas un réglage par défaut. Pour le travail routinier, c'est excessif. J'ai approfondi l'orchestration multi-agents dans mon analyse de l'architecture d'essaim d'agents de Claude Code si vous voulez les détails structurels.

Alors quelles features portent la charge au quotidien ? Après des mois de cela, trois s'élèvent au-dessus du reste.

Les trois features de Claude Code qui comptent le plus

Cole a nommé ses trois features principales de Claude Code, et après avoir fait tourner mes propres marques sur cette configuration, j'atterris au même endroit. Ce sont celles qui font le vrai travail :

1. Skills. Des prompts réutilisables et paramétrés que vous invoquez par nom. Au lieu de retaper une instruction complexe à chaque fois, vous la sauvegardez une fois et l'appelez comme une fonction. C'est ainsi qu'un workflow cesse d'être quelque chose que vous retenez et devient quelque chose que le système sait. J'ai construit des skills pour tout, des brouillons SEO aux vérifications de déploiement sur mes sites.
2. Hooks. Du code déclenché par événements qui tourne à des points définis du cycle de vie de l'agent. Nous avons couvert leur rôle sécuritaire, mais ils sont tout aussi puissants pour la qualité — auto-formatage à la sauvegarde, lancement de tests avant un commit, blocage d'un merge qui échoue à une vérification. Des garanties mécaniques, pas des instructions pleines d'espoir.
3. Sous-agents. Recherche ciblée et collecte de contexte dans des fenêtres isolées, gardant votre agent principal affûté. La défense contre la zone aveugle, opérationnalisée.

Remarquez le fil conducteur. Les skills rendent vos workflows répétables. Les hooks rendent vos garanties mécaniques. Les sous-agents gardent votre contexte maigre. Aucun d'entre eux ne vise à rendre le modèle "plus intelligent" — ils visent à construire un système autour du modèle qui reste fiable. C'est toute la philosophie en trois features.

Voici donc comment je mettrais tout cela en pratique, dès demain.

La checklist du réalisateur que j'utilise vraiment

Épinglez ceci. C'est la procédure opérationnelle que j'exécute maintenant sur toute tâche non triviale :

• Planifiez plus que vous ne construisez. Écrivez intention, plan, critères de succès et stratégie de validation avant que l'agent n'écrive une ligne. Si vous ne pouvez pas écrire les critères de succès, vous n'êtes pas prêt à déléguer.
• Gardez le contexte maigre. Traitez la fenêtre utilisable comme une fraction du million annoncé. Nettoyez entre les tâches. Ne faites pas lire à l'agent ce dont il n'a pas besoin. Restez hors de la zone aveugle.
• Construisez une vérification automatisée. Tests unitaires à partir de la spécification, Playwright pour l'UI, harnesses personnalisés pour tout ce qui est interactif. Faites passer la correction de première passe de ~65% à 92%+ sans dépenser votre propre attention.
• Concevez des harnesses avec des transferts propres. Boucle Ralph pour les phases séquentielles, sous-agents parallèles pour le déploiement indépendant. Chaque agent reste maigre.
• Traitez chaque échec comme une amélioration permanente. Chaque bug devient une règle, un document ou un hook. Le système s'accumule.
• Verrouillez la sécurité en dessous du prompt. Hooks pour les blocages fermes, scopes de permissions stricts. "Ne supprime pas la base de données" n'est pas un contrôle.
• Comprenez le code. Utilisez des conversations annexes pour apprendre sans polluer le contexte. Non-codeurs : appuyez-vous plus lourdement sur la validation.
• Utilisez les équipes d'agents pour les décisions à enjeux élevés. Le débat adversarial tue la flagornerie et fait surface les cas limites. Gourmand en tokens — réservez-le pour les décisions qui comptent.
• Nourrissez le pourquoi. Ingénierie d'intention. Chaque tâche porte son objectif. L'agent comble les lacunes dans la direction de votre intention.

Le fil qui relie les neuf est l'unique idée avec laquelle j'ai ouvert : vous êtes le réalisateur. Le product manager. Le mentor qui remet à un junior brillant, littéral et oublieux exactement ce dont il a besoin pour réussir — et vérifie le résultat contre un standard que vous avez fixé à l'avance.

Vous vous souvenez de ce build de production que j'ai cassé à 23h ? Celui avec la ligne que je n'avais jamais lue ? J'y pense encore, mais plus avec regret. C'était le soir où j'ai cessé d'être un passager. Le lendemain matin, j'ai écrit ma première vraie spécification, ajouté mon premier hook, et j'ai commencé à traiter l'agent comme ce qu'il est réellement — pas un codeur magique, mais un système que j'ai la responsabilité de bien diriger.

Alors voici la chose à faire dans les prochaines 24 heures : prenez la tâche la plus répétitive que vous résolvez actuellement par prompt, et écrivez-lui une vraie spécification — intention, plan, critères de succès, validation. Une seule. Puis observez comment l'agent se comporte différemment quand vous arrêtez de discuter avec lui et commencez à le diriger. Cette seule répétition est là où le changement de rôle commence.

Questions Fréquemment Posées

Que signifie diriger un agent de codage IA ?

Diriger un agent de codage IA signifie assumer la responsabilité de l'intention, du plan, des critères de succès et de la vérification pendant que l'agent gère la frappe. Vous agissez en tant que product manager et réalisateur plutôt que conversateur — nourrissant l'agent avec le pourquoi derrière chaque tâche et vérifiant sa sortie contre un standard que vous avez fixé à l'avance. Voir la section planification ci-dessus pour la spécification en quatre parties que j'utilise.

Qu'est-ce que la "zone aveugle" dans une fenêtre de contexte ?

La zone aveugle est le point au-delà d'environ 250 000 tokens où la précision d'un modèle se dégrade silencieusement — oubliant des contraintes et lisant mal des fichiers — même si la fenêtre de 1M de tokens n'est pas pleine. Le danger est qu'il ne génère jamais d'erreur ; il devient simplement subtilement moins bon. Gardez le contexte maigre pour en rester dehors.

Quelle est la précision du code généré par IA au premier essai ?

La sortie de premier essai d'un agent de codage IA est environ 65–70% correcte sur des tâches réelles. L'ajout d'une couche d'auto-vérification — tests unitaires, automatisation de navigateur et harnesses personnalisés — pousse cela au-delà de 92% parce que l'agent attrape et corrige ses propres erreurs avant que vous ne les révisiez. La section vérification ci-dessus détaille comment construire chaque niveau.

Qu'est-ce que la boucle Ralph dans Claude Code ?

La boucle Ralph est un workflow de chaîne de montage où chaque agent possède une phase — planifier, construire, tester — et transmet une sortie propre au suivant, chacun démarrant avec un contexte frais. Popularisée par Geoffrey Huntley en 2025, elle garde tout agent individuel hors de la zone aveugle pendant les longues exécutions autonomes.

Les instructions de prompt sont-elles suffisantes pour garder un agent IA en sécurité ?

Non. Dire à un agent dans un prompt "ne supprime pas la base de données" est une suggestion, pas un contrôle — un agent orienté objectif peut scripter son chemin autour. La vraie sécurité vient des hooks (petits programmes qui bloquent fermement les commandes dangereuses avant exécution) et des scopes de permissions stricts qui limitent ce que l'agent peut toucher.

Travaillons ensemble

Vous cherchez à construire des systèmes IA, automatiser des workflows ou faire évoluer votre infrastructure technique ? J'adorerais vous aider.

• Fiverr (builds personnalisés & intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design & branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io