Les 8 niveaux de l'ingénierie des agents intelligents

Auteur : Bassim Eledath

Traduction : Bao Yu

Les capacités de programmation de l’IA dépassent de plus en plus notre capacité à la maîtriser. C’est pourquoi tous ces efforts pour augmenter les scores sur SWE-bench ne sont pas vraiment alignés avec les indicateurs de productivité que les responsables techniques privilégient. L’équipe d’Anthropic a lancé Cowork en 10 jours, alors qu’une autre équipe utilisant le même modèle n’a même pas réussi à réaliser un POC (preuve de concept) — la différence réside dans le fait qu’une équipe a déjà comblé le fossé entre capacité et pratique, tandis que l’autre ne l’a pas encore fait.

Ce fossé ne disparaîtra pas du jour au lendemain, mais se réduira progressivement par niveaux. Au total, il y a 8 niveaux. La plupart des lecteurs de cet article ont probablement dépassé les premiers niveaux, mais vous devriez être impatient d’atteindre le suivant — car chaque niveau supérieur représente une avancée considérable en termes de production, et chaque amélioration des capacités de l’IA amplifie encore ces gains.

Une autre raison d’y prêter attention est l’effet de collaboration en équipe. Votre productivité dépend davantage du niveau de vos collègues que vous ne l’imaginez. Supposez que vous soyez un expert de niveau 7, la nuit, l’agent intelligent en arrière-plan vous aide à soumettre plusieurs PR. Mais si votre dépôt nécessite l’approbation d’un collègue encore de niveau 2, qui doit examiner manuellement chaque PR, votre débit sera bloqué. Aider vos collègues à monter en niveau profite donc aussi à vous.

En échangeant avec de nombreuses équipes et individus sur leurs pratiques d’utilisation de l’IA pour la programmation assistée, voici le chemin d’évolution en niveaux que j’ai observé (l’ordre n’est pas strict) :

Les 8 niveaux de l’ingénierie IA

Niveau 1 et 2 : Complétion par onglet et IDE intelligent

Je vais rapidement couvrir ces deux niveaux, principalement pour garder une trace complète. N’hésitez pas à sauter ces sections.

La complétion par onglet est le point de départ. GitHub Copilot a lancé cette tendance — en appuyant sur Tab, le code se complète automatiquement. Beaucoup ont peut-être oublié cette étape, ou l’ont même sautée en entrant directement dans le vif du sujet. Elle est surtout adaptée aux développeurs expérimentés, qui peuvent d’abord esquisser la structure du code, puis laisser l’IA remplir les détails.

Les IDE spécialisés comme Cursor, connectant chat et dépôt de code, ont changé la donne, rendant l’édition inter-fichiers beaucoup plus simple. Mais le plafond reste la compréhension du contexte. Le modèle ne peut traiter que ce qu’il voit, et il est frustrant qu’il ne voit pas toujours le bon contexte, ou qu’il en voit trop, incluant des éléments non pertinents.

La majorité des utilisateurs de ce niveau expérimentent aussi le mode plan de leur agent intelligent : transformer une idée brute en plan structuré, le soumettre à un LLM, l’itérer, puis déclencher l’exécution. C’est efficace à ce stade, une façon raisonnable de garder le contrôle. Mais on verra plus tard que la dépendance à cette approche diminue avec le temps.

Niveau 3 : Ingénierie du contexte

C’est là que ça devient intéressant. L’ingénierie du contexte (Context Engineering), tendance phare en 2025, repose sur le fait que le modèle peut désormais suivre de manière fiable un nombre raisonnable d’instructions, en utilisant un contexte bien calibré. Un contexte bruyant ou insuffisant est tout aussi nuisible, donc l’enjeu est d’augmenter la densité d’information par token. « Chaque token doit défendre sa place dans le prompt » — c’était la règle à l’époque.

Moins de tokens pour la même information — la densité d’information est la clé (source : humanlayer/12-factor-agents).

En pratique, l’ingénierie du contexte couvre plus de domaines que ce que beaucoup pensent. Elle inclut vos prompts système et fichiers de règles (.cursorrules, CLAUDE.md), la façon dont vous décrivez vos outils (le modèle lit ces descriptions pour décider quel outil appeler), la gestion de l’historique de dialogue pour éviter que l’agent ne perde le fil après plusieurs tours, et la sélection des outils à exposer à chaque étape — trop d’options peuvent aussi paralyser le modèle, comme un humain.

Aujourd’hui, on parle moins d’ingénierie du contexte, car la tendance va vers des modèles capables de tolérer un contexte plus bruyant et de raisonner dans des environnements plus chaotiques (grands context windows). Mais la consommation de contexte reste critique. Voici quelques scénarios où cela demeure un goulot d’étranglement :

• Les petits modèles sont plus sensibles au contexte. Les applications vocales utilisent souvent des modèles plus légers, et la taille du contexte influence la latence de réponse.

• Tokens consommés en masse. Protocoles comme MCP (Model Context Protocol) ou l’entrée d’images peuvent rapidement épuiser le quota de tokens, poussant Claude Code vers un mode « session compressée » plus tôt que prévu.

• Les agents intégrant des dizaines d’outils. Le traitement des définitions d’outils peut consommer plus de tokens que le travail effectif.

Au niveau macro, l’ingénierie du contexte n’a pas disparu, elle évolue. L’objectif est désormais de s’assurer que le bon contexte apparaît au bon moment, plutôt que de filtrer le mauvais. Ce changement a ouvert la voie au niveau 4.

Niveau 4 : Ingénierie composite

L’amélioration du contexte concerne la session en cours. L’ingénierie composite (Compounding Engineering, proposée par Kieran Klaassen) concerne chaque session suivante. C’est une révélation pour moi et beaucoup d’autres : cela nous a fait réaliser que le « programming par intuition » ne se limite pas à faire des prototypes.

C’est un cycle de « planification, délégation, évaluation, consolidation ». Vous planifiez une tâche, fournissez à l’LLM un contexte suffisant pour qu’il réussisse, déléguez, évaluez le résultat, puis, étape cruciale, vous enregistrez ce que vous avez appris : ce qui fonctionne, ce qui ne fonctionne pas, le mode à suivre la prochaine fois.

Ce cycle de consolidation — planifier, déléguer, évaluer, consolider — permet à chaque itération d’être meilleure que la précédente.

Le vrai pouvoir réside dans la étape de « consolidation ». L’LLM étant sans état, si hier il a réintroduit une dépendance que vous aviez explicitement supprimée, il le fera encore demain, sauf si vous lui indiquez de ne pas le faire. La solution la plus courante consiste à mettre à jour votre fichier CLAUDE.md (ou autre règle) pour intégrer ces leçons dans chaque nouvelle session. Mais attention : vouloir tout mettre dans le fichier de règles peut être contre-productif (trop d’instructions, c’est comme n’en avoir aucune). Mieux vaut créer un environnement où l’LLM peut découvrir par lui-même ce qui est pertinent — par exemple, en maintenant un dossier docs/ constamment à jour (détaillé au niveau 7).

Les praticiens de l’ingénierie composite sont très sensibles au contexte fourni à l’LLM. Lorsqu’une erreur survient, leur réflexe est de vérifier si le contexte manque d’informations, plutôt que de blâmer le modèle. C’est cette intuition qui rend possibles les niveaux 5 à 8.

Niveau 5 : MCP et compétences

Les niveaux 3 et 4 traitent du contexte. Le niveau 5 concerne la capacité. MCP et compétences personnalisées permettent à votre LLM d’accéder à des bases de données, API, pipelines CI, systèmes de design, outils comme Playwright pour le test navigateur, Slack pour la notification. Le modèle ne se limite plus à réfléchir sur votre dépôt — il peut agir directement.

Il existe déjà beaucoup de ressources de qualité sur MCP et compétences, je ne vais pas les détailler ici. Mais voici quelques exemples que j’utilise : une compétence partagée pour la revue de PR, qui peut lancer des sous-agents conditionnels selon la nature du PR — un pour vérifier la sécurité de l’intégration avec la base de données, un pour analyser la complexité et repérer redondances ou sur-ingénierie, un autre pour vérifier la santé des prompts, etc. Elle peut aussi faire du linting ou utiliser Ruff.

Pourquoi investir autant dans la revue de PR ? Parce qu’à grande échelle, la revue manuelle devient un goulot. Latent Space avance que la revue de code traditionnelle est morte. À la place, on a une revue automatisée, cohérente, basée sur des compétences.

Pour MCP, j’utilise Braintrust MCP pour que l’LLM consulte les logs d’évaluation et fasse des modifications. J’utilise DeepWiki MCP pour que l’agent accède à la documentation de n’importe quel dépôt open source, sans avoir à l’intégrer manuellement dans le contexte.

Quand plusieurs membres de l’équipe créent leurs propres compétences, il devient pertinent de les centraliser dans un registre partagé. Block (notamment) a écrit un excellent article : ils ont construit un marché interne de compétences, avec plus de 100 compétences, et des packs de compétences pour rôles et équipes. Les compétences et le code y sont traités comme du code : pull requests, revue, historique.

Une tendance importante : de plus en plus, les LLM utilisent des outils CLI plutôt que MCP (et chaque entreprise semble lancer le sien : Google Workspace CLI, bientôt Braintrust). La raison ? efficacité du token. MCP injecte la définition complète de l’outil dans chaque tour, qu’il soit utilisé ou non. Le CLI, lui, exécute une commande ciblée, et seul le résultat pertinent entre dans le contexte. J’utilise beaucoup agent-browser plutôt que Playwright MCP, pour cette raison.

Avant de continuer, un point : les niveaux 3 à 5 sont la base de tout le reste. Les LLM excellent dans certains domaines, mais sont faibles dans d’autres. Il faut développer une intuition de leurs limites, pour pouvoir automatiser davantage. Si votre contexte est bruyant, vos prompts insuffisants ou imprécis, ou si la description des outils est vague, alors les niveaux 6 à 8 ne feront qu’amplifier ces problèmes.

Niveau 6 : Ingénierie de l’harness

Le vrai décollage.

L’ingénierie du contexte concerne ce que voit le modèle. L’ingénierie de l’harness (Harness Engineering) concerne la construction de l’environnement complet — outils, infrastructure, boucle de rétroaction — pour que l’agent puisse fonctionner de façon fiable sans intervention humaine. Ce n’est pas seulement un éditeur, mais un système complet de rétroaction.

L’outil Codex d’OpenAI — un système d’observabilité complet permettant à l’agent de consulter, relier et raisonner sur ses propres sorties (source : OpenAI).

L’équipe d’OpenAI a intégré Chrome DevTools, des outils d’observabilité et la navigation dans le navigateur dans le runtime de l’agent, permettant de faire des captures d’écran, piloter l’UI, consulter les logs, vérifier ses corrections. En fournissant un prompt, l’agent peut reproduire un bug, enregistrer une vidéo, appliquer une correction, puis valider ses modifications, soumettre PR, répondre aux revues, fusionner — tout cela sans intervention humaine, sauf pour juger si nécessaire. L’agent ne se contente pas d’écrire du code : il voit l’effet de ses actions, puis itère, comme un humain.

Mon équipe travaille sur des agents vocaux et chat pour le diagnostic technique. J’ai créé un outil CLI appelé converse, qui permet à tout LLM d’interagir avec notre backend en mode conversation. Après modification du code, l’agent peut tester en ligne, puis itérer. Parfois, cette boucle d’auto-amélioration tourne plusieurs heures. Lorsqu’un résultat est vérifiable, c’est particulièrement puissant : la conversation doit suivre ce processus, ou utiliser certains outils dans des cas spécifiques (par ex. transfert à un support humain).

Le concept clé qui soutient tout cela est la rétropression (Backpressure) — un mécanisme de rétroaction automatisé (système de types, tests, linters, hooks pre-commit) permettant à l’agent de détecter et corriger ses erreurs sans intervention humaine. Si vous souhaitez une autonomie, il faut un mécanisme de rétropression, sinon vous obtenez une machine à produire du « déchet ». Cela s’étend aussi à la sécurité : le CTO de Vercel souligne que l’agent, ses codes générés et vos clés doivent être dans des domaines de confiance séparés, car une injection dans les logs pourrait inciter l’agent à voler vos credentials — si tout partage le même contexte de sécurité, c’est une faille. La frontière de sécurité, c’est la rétropression : elle limite ce que l’agent peut faire en cas de dérapage, pas seulement ce qu’il doit faire.

Deux principes pour clarifier cette idée :

• Conception pour le débit, pas la perfection. Exiger la perfection à chaque soumission mène à des boucles infinies de bugs et de corrections mutuelles. Mieux vaut tolérer de petites erreurs non bloquantes, faire une dernière vérification avant déploiement. C’est aussi ce qu’on applique avec nos collègues humains.

• La contrainte prime sur l’instruction. Les prompts étape par étape (« fais A, puis B, puis C ») deviennent obsolètes. Selon mon expérience, définir des limites est plus efficace qu’une liste de tâches, car le modèle se focalise dessus et ignore tout le reste. La meilleure approche est de donner une indication claire du résultat attendu, puis de laisser l’agent continuer jusqu’à ce que tous les tests soient passés.

L’ingénierie de l’harness vise aussi à faire en sorte que l’agent puisse naviguer dans le dépôt sans ton intervention. OpenAI recommande de limiter le fichier AGENTS.md à environ 100 lignes, comme un index pointant vers d’autres documents structurés, et d’intégrer leur actualisation dans le CI, plutôt que de dépendre de mises à jour ad hoc.

Une fois tout cela en place, une question naturelle se pose : si l’agent peut vérifier son travail, naviguer dans le dépôt, se corriger sans toi — pourquoi rester assis à ton bureau ?

Attention : pour ceux encore au niveau 3 à 5, la suite peut sembler futuriste (mais n’hésite pas à sauvegarder, ça viendra).

Niveau 7 : Agent en arrière-plan

Avis : le mode plan est en train de disparaître.

Boris Cherny, créateur de Claude Code, indique que 80 % des tâches commencent encore par un mode plan. Mais avec chaque nouvelle génération de modèles, la réussite après planification devient de plus en plus automatique. Je pense qu’on approche d’un point critique : le mode plan, en tant qu’étape humaine indépendante, va progressivement disparaître. Pas parce qu’il n’est pas important, mais parce que le modèle devient suffisamment intelligent pour s’auto-planifier. À condition que vous ayez bien préparé les niveaux 3 à 6 : contexte propre, contraintes claires, descriptions d’outils précises, boucle de rétroaction fermée. Si ces conditions sont remplies, le modèle peut planifier de façon fiable sans supervision. Sinon, il faut continuer à surveiller.

Pour faire simple, le mode plan en tant que pratique universelle va évoluer. Pour un débutant, il reste une étape clé (voir niveaux 1 et 2). Mais pour un agent de niveau 7 chargé de fonctionnalités complexes, « planifier » devient plus une exploration : fouiller dans le dépôt, faire des prototypes dans le worktree, explorer des solutions. Et de plus en plus, c’est l’agent en arrière-plan qui fait cette exploration à votre place.

C’est crucial, car cela débloque la capacité de l’agent en arrière-plan. Si un agent peut générer un plan fiable et l’exécuter sans votre validation, il peut travailler en tâche de fond pendant que vous faites autre chose. C’est une étape clé : passer de « je jongle entre plusieurs onglets » à « un travail avance tout seul, sans moi ».

Le cycle Ralph est une méthode populaire : un agent autonome qui tourne en boucle, exécutant le CLI de programmation jusqu’à ce que toutes les tâches du PRD soient terminées, chaque itération lançant une nouvelle instance avec un contexte neuf. D’après mon expérience, faire tourner Ralph efficacement n’est pas simple : toute erreur ou imprécision dans la description du PRD peut tout faire échouer. C’est un peu comme le « lancer et oublier ».

Vous pouvez faire plusieurs Ralph en parallèle, mais plus vous en lancez, plus vous passez de temps à coordonner, planifier, vérifier les résultats, suivre la progression. Vous ne codez plus vraiment — vous devenez un gestionnaire intermédiaire. Il faut un orchestrateur pour gérer la planification, pour que vous puissiez vous concentrer sur l’intention, pas la logistique.

Dispatch, qui lance 5 workers en parallèle sur 3 modèles, permet de garder une conversation fluide tout en déléguant le travail.

J’utilise beaucoup Dispatch, un skill que j’ai développé pour Claude Code, qui transforme votre session en centre de commandement. Vous restez dans une session propre, pendant que des workers isolés effectuent le travail lourd. Le planificateur gère la planification, la délégation, le suivi, et votre fenêtre principale reste disponible pour orchestrer. Si un worker bloque, il renvoie une question de clarification plutôt qu’un échec silencieux.

Dispatch fonctionne localement, idéal pour un développement rapide et connecté : feedback rapide, débogage facile, pas d’infrastructure. L’outil Inspect de Ramp, en revanche, est adapté pour des tâches longues et autonomes : chaque session agent tourne dans un VM cloud, avec un environnement complet. Si un PM repère un bug UI, il le signale dans Slack, et Inspect prend le relais pour traiter la suite, même quand vous fermez votre laptop. Le coût : complexité opérationnelle (infrastructure, snapshots, sécurité), mais vous gagnez en échelle et reproductibilité. Je recommande d’utiliser les deux : local et cloud.

Une tendance étonnante : utiliser différents modèles pour différentes tâches. La meilleure équipe n’est pas composée de clones identiques. Chaque membre a ses forces, ses expériences, ses préférences. La même logique s’applique aux modèles : après un entraînement différent, ils ont des personnalités distinctes. Je confie souvent Opus à la réalisation, Gemini à la recherche exploratoire, Codex à la revue — la synergie dépasse celle de modèles isolés. C’est une forme d’intelligence collective appliquée au code.

Il est aussi crucial de dissocier la création et la revue. Si un même modèle génère et évalue son propre travail, il sera biaisé, il mentira. Il dira que tout est parfait alors que ce n’est pas le cas. Ce n’est pas de la malveillance, c’est comme se noter soi-même à un examen. La solution : faire évaluer par un autre modèle ou une instance différente avec un prompt dédié à la revue. Cela améliore considérablement la fiabilité.

Les agents en arrière-plan facilitent aussi l’intégration CI + IA. Lorsqu’un agent peut fonctionner sans supervision, il peut être déclenché par l’infrastructure existante. Par exemple, un robot de documentation qui, après chaque merge, met à jour la documentation dans CLAUDE.md, ou un robot de sécurité qui scanne les PR et propose des corrections. Un robot de gestion des dépendances qui met à jour et teste automatiquement. Avec un bon contexte, des règles consolidées, des outils puissants, et une boucle de rétroaction automatisée, tout peut fonctionner en autonomie.

Niveau 8 : Équipes d’agents autonomes

Personne ne maîtrise encore totalement ce niveau, mais certains s’y dirigent. C’est la frontière actuelle.

Au niveau 7, vous avez un orchestrateur central qui distribue les tâches aux agents. Au niveau 8, cette étape est supprimée : les agents communiquent directement entre eux — revendiquent des tâches, partagent leurs découvertes, gèrent leurs dépendances, résolvent les conflits, sans passer par un seul orchestrateur.

L’expérimentation d’Agent Teams chez Claude Code en est une première étape : plusieurs instances travaillent en parallèle sur un dépôt, en communication directe. Anthropic a construit un compilateur Linux en C avec 16 agents parallèles, et Cursor a lancé des centaines d’agents en continu pendant plusieurs semaines pour migrer un codebase de Solid vers React.

Mais en y regardant de plus près, des problèmes apparaissent. Sans hiérarchie claire, les agents hésitent, tournent en rond, n’avancent pas. Chez Anthropic, ils ont dû ajouter une pipeline CI pour éviter les régressions. Tous ceux qui expérimentent à ce niveau disent que la coordination multi-agent est un problème difficile, et qu’aucune solution optimale n’a encore émergé.

Honnêtement, je ne pense pas que les modèles soient encore prêts pour une autonomie totale sur la majorité des tâches. Même s’ils sont intelligents, pour des projets complexes comme un compilateur ou un navigateur, ils restent trop lents, trop coûteux en tokens, et peu rentables économiquement (impressionnant, mais pas encore mature). Pour notre travail quotidien, le niveau 7 reste la véritable levée. Je ne serais pas surpris que le niveau 8 devienne la norme, mais pour l’instant, je concentre mes efforts sur le niveau 7 (sauf si vous êtes Cursor — car la rupture est votre métier).

Niveau ? : La question inévitable du « et après ? »

Une fois que vous maîtrisez la coordination d’équipes d’agents sans friction, l’interface ne doit plus se limiter au texte. La conversation vocale, ou même la communication pensée à pensée, avec des agents programmatiques — un Claude Code en mode dialogue, pas seulement en dictée vocale — devient la prochaine étape naturelle. Imaginez décrire à voix haute une série de modifications, et les voir se réaliser devant vous.

Certains cherchent la perfection dans la génération unique : dire ce qu’on veut, et que l’IA le produise parfaitement en une seule fois. Mais ce modèle suppose que nous savons exactement ce que nous voulons. Or, ce n’est pas le cas. On ne sait jamais vraiment. Le développement logiciel est itératif, et le restera toujours. La différence, c’est que ce sera beaucoup plus facile, bien au-delà du simple texte, et beaucoup plus rapide.

Alors, à quel niveau êtes-vous ? Que faites-vous pour passer au suivant ?

À quel niveau êtes-vous ?

Comment utilisez-vous généralement l’IA pour commencer une tâche de programmation ?