Au-delà du prompt : le context engineering face à la charge cognitive des IA

L’ère des IA qui répondent aux questions est terminée. Bienvenue dans l’ère des agents qui agissent. Mais pour qu’ils tiennent leurs promesses, nous devons comprendre une de leurs limites fondamentales, illustrée à l’extrême par le cas des agents de développement logiciel.

Une transformation silencieuse est en cours. Hier, nous demandions à l’intelligence artificielle de nous donner des informations; aujourd’hui, nous attendons d’elle qu’elle réalise des tâches. C’est l’avènement des agents IA autonomes. Un agent juriste qui analyse un contrat, un agent financier qui audite des rapports, un agent scientifique qui synthétise des recherches… la promesse est de déléguer des missions complexes, basées sur des contextes riches et spécifiques.

Parmi tous ces nouveaux collaborateurs virtuels, les agents de développement logiciel sont sans doute les plus avancés et les plus exigeants. Pourquoi ? Parce que le code est un langage d’une logique implacable, où l’ambiguïté n’a pas sa place et où le résultat est objectivement vérifiable. C’est pourquoi nous utiliserons l’agent développeur comme principal cas d’étude dans cet article. Les défis qu’il rencontre sont les mêmes que pour tous les autres agents, mais amplifiés à l’extrême.

Le problème que l’on observe aujourd’hui, souvent au cœur des approches du context engineering et des frameworks comme BMAD ou SuperClaude, est le suivant : pour qu’un agent agisse, on a tendance à vouloir lui donner “tout” le contexte, en partant du principe que sa mémoire est parfaite. C’est une erreur. Bien que ce ne soit pas l’unique défi fondamental, c’est celui que nous allons chercher à résoudre dans cet article. Notre thèse est simple : le véritable enjeu du context engineering n’est pas de “tout donner” au modèle, mais de comprendre et de gérer sa charge cognitive. Car un LLM, fondamentalement amnésique (stateless), dispose d’une mémoire de travail limitée et faillible. Maîtriser cette discipline est une étape clé, mais transitoire, avant la prochaine évolution : celle des IA dotées d’une véritable mémoire à long terme.

La charge cognitive de l’agent : anatomie d’une surcharge cognitive

Pour comprendre le problème, il faut se rappeler d’un principe technique fondamental : un LLM est stateless. En dehors des informations que vous lui fournissez dans un unique appel (contexte + prompt) il ne se souvient de rien. Chaque nouvelle interaction est une discussion avec un interlocuteur brillant mais totalement amnésique.

C’est ici que l’analogie de la charge cognitive prend tout son sens. La fenêtre de contexte d’un LLM n’est pas un disque dur où l’on stocke passivement des données. C’est sa mémoire de travail, une ressource active et limitée. La différence avec un développeur humain est la suivante : un développeur expérimenté construit des abstractions, une “carte mentale” du projet, et sait instinctivement où chercher l’information. Un LLM, lui, est comme un développeur extrêmement rapide mais forcé de relire et ré-analyser l’intégralité des documents pertinents à chaque nouvelle instruction.

Pire encore, l’agent est inconscient de sa propre charge cognitive. Contrairement à un humain qui dirait “Attends, c’est trop d’informations, je vais me perdre”, le LLM s’engage avec une confiance absolue dans des tâches pour lesquelles sa mémoire de travail est manifestement insuffisante.

Par exemple, lors d’un refactoring complexe, sa mémoire de travail sature, après plusieurs compressions de contexte, il finit par “se perdre en chemin”; il oublie ses objectifs, hallucine des étapes ou perd le fil de sa propre logique, laissant derrière lui un code hybride, à moitié refactorisé, qui ne respecte plus aucune règle.

Ce problème est si déterminant que les outils les plus avancés, conçus pour un travail en mode agentique, intègrent nativement des solutions pour le gérer. Un outil comme Cline, par exemple, dont la fonction principale est d’agir comme un agent de développement, expose des fonctionnalités de “moniteur de charge cognitive”. Ces dernières ne sont pas un gadget, mais une nécessité : pour qu’un agent soit fiable, le développeur doit pouvoir visualiser et contrôler la composition du contexte.

Inévitablement, cette surcharge cognitive entraîne des symptômes concrets, directement issus des retours terrain :

1. La dilution de l’attention : mauvaise interprétation et suppression de code.

C’est le symptôme le plus courant et le plus insidieux de la surcharge cognitive. Noyé sous un flot d’informations, l’agent perd sa capacité à hiérarchiser l’importance. Ce phénomène, souvent appelé lost in the middle, a été démontré par de nombreuses études : la capacité d’un modèle à retrouver une information précise chute drastiquement lorsque celle-ci est placée au milieu d’un long contexte. L’agent ne “voit” plus certaines instructions.

• Exemple concret : Vous demandez à un agent de créer un nouvel endpoint d’API pour afficher des profils. Le contexte est un long document d’architecture qui précise, en son milieu, que toute nouvelle route doit impérativement masquer les emails des utilisateurs. L’agent, se basant sur les exemples de routes plus anciennes qui n’ont pas cette protection, ignore cette directive. Il crée alors un endpoint qui expose publiquement les emails, créant une faille de sécurité critique.

2. La compression avec perte : se perdre lors d’une tâche longue.

Pour gérer un contexte trop large, le modèle le “compresse”. Imaginez une image JPEG de haute qualité que vous compressez agressivement : de loin, l’image semble correcte, mais en zoomant, les détails ont disparu. Le modèle ne travaille plus sur une représentation parfaite de la réalité, mais sur cette version dégradée.

• Exemple concret (internationalisation): Vous demandez à l’agent de remplacer toutes les chaînes de texte par des clés de traduction. Au début, il s’exécute parfaitement. Mais après 20 fichiers, il commence à “compresser” son souvenir de la règle et à créer des clés incohérentes, oubliant des cas complexes. Il ne rate pas la tâche, il se perd en chemin.

3. La dilution des instructions: suivre la lettre, mais pas l’esprit.

Face à une longue liste de contraintes, l’agent perd de vue l’intention globale. Il va traiter chaque instruction de manière littérale et superficielle, en se concentrant sur les plus faciles à mesurer au détriment des plus importantes.

• Exemple concret (le composant “à tout faire”): Vous demandez un composant React avec 20 contraintes (performance, sécurité, accessibilité, documentation, tests, etc.). Le résultat sera un composant qui est un peu tout ça, mais n’excelle dans aucun domaine, produisant un code médiocre.

4. La fuite vers la simplicité : la réécriture destructrice.

Ce dernier symptôme est une conséquence directe de la “paresse cognitive” de l’agent. Face à une modification chirurgicale dans un fichier complexe, il est cognitivement moins coûteux pour lui de réécrire tout le fichier à partir de sa compréhension “compressée” plutôt que de l’éditer précisément. Il choisit le bulldozer plutôt que le scalpel.

• Exemple concret (la perte de l’historique Git): Vous demandez à l’agent de simplement renommer une variable dans une classe de 500 lignes. Au lieu de faire un simple “rename”, l’agent réécrit la totalité du fichier. Le diff de la Pull Request montre 500 lignes supprimées et 500 lignes ajoutées, rendant la revue de code impossible et détruisant l’historique git blame du fichier.

Redéfinir le context engineering: l’art de l’ergonomie cognitive

Si le “bourrage de contexte” est une impasse, que faire ? La solution est de définir ou redéfinir ce qu’est le context engineering. Il ne s’agit pas de l’art de fournir le plus de données possibles, mais de celui de structurer l’information pour qu’elle soit la plus simple et la moins coûteuse à traiter pour le modèle. C’est de l’ergonomie, appliquée à la « pensée » des LLMs actuels. Pour y parvenir, plusieurs techniques se révèlent particulièrement efficaces pour guider l’agent et réduire sa charge cognitive.

Technique 1 : La préparation du contexte (structure et précision)

C’est le fondement de tout. Avant même de formuler une demande, il faut préparer le “terrain mental” de l’agent. Cela passe par deux actions complémentaires :

• La structure explicite : La première étape est de créer une “carte mentale” pour l’agent en utilisant des démarcations claires. Utiliser des balises (comme <règles> ou <contraintes>) et des formats comme le Markdown ou le JSON est essentiel pour délimiter clairement les différentes parties de la demande.
• La précision chirurgicale : Une fois la structure en place, le principe du “moins, c’est plus” devient la règle d’or. Il faut filtrer impitoyablement l’information pour ne fournir que le strict minimum nécessaire à l’intérieur de chaque section, chaque token superflu grignotant cette mémoire volatile.

Technique 2 : Le séquençage de la tâche (planification supervisée)

Cette technique est la réponse directe aux problèmes de “perte en chemin” et de “paresse cognitive”. Au lieu de donner une tâche complexe et d’espérer le meilleur, on la décompose pour transformer une grosse charge cognitive en plusieurs petites charges parfaitement gérables.

1. Phase de planification : On demande d’abord à l’agent de planifier son travail sans l’exécuter. “Planifie toutes les étapes pour accomplir X, liste les fichiers à modifier.”
2. Phase d’exécution supervisée : Le développeur valide ce plan. Puis, il pilote l’agent étape par étape : “Maintenant, exécute seulement l’étape 1 du plan.” Cette approche force l’agent à effectuer des modifications chirurgicales, ce qui préserve la traçabilité et garantit qu’il ne s’écarte pas de la stratégie validée.

Technique 3 : La boucle de rétroaction contextuelle

C’est la technique la plus avancée, qui transforme une simple instruction en une véritable conversation de travail. Le principe est d’utiliser le résultat d’une action comme le contexte ultra-précis de l’action suivante.

• Le scénario : L’agent génère du code, mais celui-ci échoue aux tests unitaires.
• La mauvaise approche : “Ça n’a pas marché, réessaie.” (Contexte vide, l’agent risque de refaire la même erreur).
• La bonne approche : “Ton code a échoué. Voici le rapport d’erreur du test. Analyse-le et corrige le code en conséquence.”

Cette boucle peut être alimentée par des tests, des rapports de linter, ou même des revues de code faites par d’autres IA, créant un cycle d’amélioration continue où chaque contexte est plus précis que le précédent.

Il est important de noter que ces trois techniques ne sont pas exclusives. Elles sont au contraire conçues pour être combinées, formant un processus de travail complet. La préparation du contexte est le socle de toute interaction. Le séquençage s’appuie sur ce socle pour gérer la complexité, et la boucle de rétroaction vient affiner le résultat à chaque étape. C’est leur synergie qui transforme une simple instruction en une véritable collaboration.

Penser pour la machine, en attendant qu’elle se souvienne

Le véritable context engineering, celui qui fonctionne, nous apprend à respecter les limites cognitives de notre interlocuteur artificiel. Les approches “brute force” qui ignorent la notion de charge cognitive sont vouées à l’échec. Le rôle de l’ingénieur évolue donc profondément. A sa mission traditionnelle de construire des solutions, s’ajoute désormais celle d’architecturer l’information qui permettra aux agents de les construire avec lui. Et ce rôle n’est pas l’apanage des développeurs. Qu’il s’agisse de guider un agent juriste à travers des centaines de pages de jurisprudence ou d’aider un agent analyste à ne pas se noyer dans des rapports financiers, la question reste la même : comment puis-je présenter l’information pour qu’il la comprenne sans effort ?

Cette méthodologie fait émerger une nouvelle expertise de développement. Le rôle du développeur ne consiste plus seulement à maîtriser le code, mais aussi à maîtriser les contraintes de ses nouveaux outils pour en tirer le meilleur. Sa valeur se déplace de l’exécution pure vers la supervision, la validation et l’orchestration du travail de l’agent. C’est cette maîtrise des limites de l’IA qui est au cœur de la productivité, préparant le terrain pour les prochaines pratiques, du développement piloté par les spécifications à l’orchestration de systèmes multi-agents.

Cette maîtrise de l’orchestration est le prérequis indispensable pour aborder sereinement les prochaines grandes évolutions. On peut penser à la coordination d’équipes de plusieurs agents spécialistes ou à l’interaction avec des agents dotés d’une mémoire à long terme, comme l’esquissent des projets de recherche tel que MemOS. Le context engineering, bien compris, est donc le pont que nous devons construire et maîtriser aujourd’hui pour atteindre ces nouveaux paradigmes demain.

Au-delà du prompt : le context engineering face à la charge mentale des IA was originally published in ekino-france on Medium, where people are continuing the conversation by highlighting and responding to this story.