Ingénierie du contexte : le travail avant l'invite
· 7 min read · Filippo Spinella · AI, Agents, Prompting, Developer Tools
Le mot du moment, dans le petit monde des agents IA, est l’ingénierie contextuelle.
Cela ressemble à un énième label inventé pour vendre quelque chose que nous faisions déjà. C’est en partie le cas. Cependant, comme cela arrive souvent, l’étiquette fait son chemin car elle donne un nom à une vraie douleur.
Le problème est le suivant : les modèles n’échouent pas simplement parce qu’ils « ne pensent pas ». Ils échouent souvent parce que nous les envoyons travailler dans la mauvaise pièce.
Nous leur donnons d'anciennes instructions. Nous lui cachons des fichiers importants. Nous leur transmettons des documents trop longs et ne disons pas ce qui compte. Nous leur montrons les logs sans priorité. Nous leur donnons dix outils sans leur expliquer quand les utiliser. On s'étonne alors si l'agent se déplace comme une personne réveillée dans un appartement inconnu.
L'invite est la phrase que vous lui dites. Le contexte est le monde que vous préparez autour de lui.
De l'ingénierie rapide à l'ingénierie contextuelle
L’ingénierie rapide était souvent considérée comme de l’écriture. Choisissez les bons mots, demandez de la bonne manière, ajoutez des exemples, précisez le format.
L’ingénierie du contexte est plus proche de l’architecture.
Vous ne vous contentez pas de demander « comment formuler la demande ? ». Il demande :
- quelles informations sont réellement nécessaires ?
- qu'est-ce que le bruit ?
- que faut-il récupérer à la volée ?
- que faut-il retenir ?
- quels outils doivent être exposés ?
- quelles instructions sont stables et lesquelles dépendent de la tâche ?
- comment faire comprendre à l'agent ce qui fait autorité ?
C'est un changement subtil mais énorme. Car lorsque vous travaillez avec des agents, le contexte n’est pas un bloc statique. Cela change à chaque étape.
L'agent ouvre un fichier, apprend quelque chose, exécute un test, reçoit une erreur, met à jour le plan, appelle un outil, découvre une dépendance. À chaque tour, il doit décider quoi emporter avec lui et quoi laisser de côté.
C'est de l'ingénierie.
Le contexte n'est pas une décharge
Les modèles avec de grandes fenêtres contextuelles nous ont donné la tentation : ajoutons tout.
C'est compréhensible. Si j'ai un million de jetons, pourquoi devrais-je choisir ?
Parce que même quand on peut tout mettre dedans, cela ne veut pas dire que tout est utile. En effet, le bruit a un coût. Cela coûte des jetons, cela coûte de l’attention, cela coûte de la latence, cela coûte de la qualité. Un modèle peut se perdre dans des détails non pertinents, tout comme nous lorsque nous ouvrons vingt onglets sans nous rappeler pourquoi.
Un bon contexte a une hiérarchie :
- instructions et politiques du système ;
- objectif spécifique ;
- situation actuelle ;
- données pertinentes ;
- contraintes ;
- outils disponibles ;
- suivre les décisions déjà prises.
Il n’est pas nécessaire de tout traiter au même niveau. Une commande utilisateur vaut plus qu’une vieille note. Un test échoué vaut désormais plus qu’une préférence esthétique d’il y a trois mois. Une politique de sécurité vaut plus qu’un raccourci de production.
L’ingénierie du contexte signifie également donner des pondérations, pas seulement des données.
Mémoire : souvenez-vous moins, souvenez-vous mieux
La mémoire des agents est l’un des sujets les plus glissants.
En tant qu'utilisateur, vous souhaitez que l'agent vous connaisse. Vous voulez qu’il se souvienne du ton, du plan, des conventions, des choses déjà décidées. En tant qu'ingénieur, vous savez que toute mémoire persistante est aussi un risque : elle peut être fausse, ancienne, trop personnelle, trop générique, invérifiable.
Un souvenir utile doit avoir au moins trois qualités :
- provenance : d'où proviennent ces informations ?
- date : quand était-ce vrai ?
- finalité : à quel type de tâche doit-il être utilisé ?
Sans ces trois choses, la mémoire devient superstition.
J'aime considérer la mémoire agentique comme un manuel et non comme un esprit magique. Il y a des notes temporaires, des décisions confirmées, des préférences de style, des contraintes techniques, des liens vers des sources. Certaines choses expirent. Certains doivent être réécrits. Certains doivent être éliminés parce que l’agent les a mal interprétés.
Un bon système doit rendre cet entretien normal. Pas héroïque.
La récupération et les outils ne sont pas la même chose
Quand on parle de contexte, on aboutit souvent immédiatement sur RAG. Incorporation, base de données vectorielles, chunking, reclassement.
Tout cela est utile. Mais la récupération n'est qu'un moyen parmi d'autres d'apporter des informations au modèle. Il n'est pas le seul.
Un agent peut obtenir du contexte en lisant des fichiers, en interrogeant une API, en appelant un serveur MCP, en ouvrant un navigateur, en exécutant des tests, en recherchant dans Slack, en consultant un tableau de bord, en interrogeant l'humain.
La partie intéressante est de décider quel itinéraire utiliser et quand.
Si l’agent a besoin de répondre à une question historique, une simple récupération suffit peut-être. S'il doit corriger un bug, il doit lire le vrai code. S'il a besoin de comprendre pourquoi un déploiement échoue, il doit consulter de nouveaux journaux. Si vous devez écrire à un client, vous devez récupérer la tonalité, l'historique et le statut du ticket. S'il doit agir sur la production, il doit demander la permission.
Le contexte n'est pas une base de données. C'est un flux de travail.
Le bon agent sait aussi ignorer
Un signe de maturité chez les agents sera la capacité de dire : je n'ai pas besoin de cette information.
Cela semble trivial, mais c'est très difficile. De nombreux systèmes agents s'accumulent. Chaque appel d'outil ajoute du texte. Chaque erreur reste dans le tampon. Chaque fichier lu s'ajoute à la pile. Au final le modèle a une très longue histoire et pas de carte.
Une compression est nécessaire. Une synthèse intermédiaire est nécessaire. Il faut qu’il soit structuré.
Non pas « c'est tout ce qui s'est passé », mais :
- objectif toujours valable ;
- hypothèse actuelle ;
- les fichiers déjà vérifiés ;
- les décisions prises ;
- risques ouverts ;
- prochaine action.
Cela rend l’agent moins théâtral et plus utile. Non pas parce qu’il semble plus intelligent, mais parce qu’il travaille avec un bureau bien rangé.
Ingénierie du contexte pour les équipes, pas pour les artistes prompts
La raison pour laquelle ce sujet m’intéresse est qu’il déplace la responsabilité de l’individu vers le système.
En ingénierie rapide, celui qui parle le mieux au modèle gagne souvent. En ingénierie de contexte, l'équipe qui organise le mieux son travail gagne : documentation, conventions, problèmes, journaux, tests, propriété, dénomination, sources.
Un référentiel propre devient un meilleur contexte. Un numéro bien écrit devient un meilleur carburant. Un runbook mis à jour évite les jetons et l'anxiété. Un journal des modifications clair réduit les hallucinations.
C’est une bonne nouvelle, mais quelque peu inconfortable. Beau car il récompense les bonnes pratiques. Inconvénient car vous ne pouvez pas tout résoudre avec une invite intelligente.
Les agents amplifient l’hygiène du système qu’ils trouvent.
Comment je l'appliquerais demain
Si je devais introduire l’ingénierie de contexte dans un projet réel, je partirais de petites choses :
- un dossier d'instructions de projet court et tenu à jour ;
- de bons exemples de résultats attendus ;
- une liste des outils disponibles et des cas dans lesquels les utiliser ;
- les décisions architecturales rédigées de manière citable ;
- problème avec un contexte minimum obligatoire ;
- facile à récupérer les journaux et les tests ;
- mémoire persistante modifiable par les humains.
Ensuite, je mesurerais une chose simple : combien de fois l'agent doit-il demander des éclaircissements ou partir dans la mauvaise direction ?
Si cela arrive souvent, je n'ajouterais pas tout de suite un modèle plus grand. Je regarderais le contexte.
Ma lecture
L’ingénierie de contexte est un mot un peu gonflé, oui. Mais le concept est solide.
Cela nous rappelle que l’intelligence d’un agent ne réside pas seulement dans le modèle. Cela réside dans l'environnement que nous lui préparons : ce qu'il voit, ce dont il se souvient, ce qu'il peut faire, ce qu'il lui est interdit de faire, quelles sources il reconnaît comme vraies.
La partie humaine est la suivante : bien préparer le contexte est une forme de soin. C'est dire à l'agent, mais aussi à l'équipe : "Je ne veux pas que vous deviniez, je veux que vous ayez ce dont vous avez besoin."
Moins de magie. Chambre plus propre. Les agents en ont autant besoin que nous.
##Sources