Ingénierie du contexte pour les agents de codage

L'ingénierie du contexte consiste à déterminer ce que voit un agent de codage avant qu'il n'agisse. C'est le principal facteur qui influe sur la qualité du résultat, car un modèle performant ne vaut que par la qualité des données que vous lui fournissez.

Dans Jira, le contexte dont un agent a besoin fait déjà partie intégrante du ticket. Ce dernier contient l'objectif et les critères d'acceptation, et le Teamwork Graph le relie au code, aux décisions et à la documentation qui s'y rapportent, ce qui permet à un agent d'agir en fonction d'une intention réelle plutôt que d'un prompt vide de sens. Ce contexte reste accessible à l'ensemble de votre équipe, et n'est pas confiné dans des fichiers locaux sur une seule machine.

Ce guide explique ce qu'est l'ingénierie du contexte, pourquoi la fenêtre de contexte constitue la véritable contrainte pour les agents de codage, et comment mettre en place l'ingénierie du contexte dans Jira afin que les agents disposent des informations dont ils ont besoin sans que vous ayez à les leur communiquer manuellement dans chaque prompt. Concrètement, cette approche se résume à quelques mesures à mettre en œuvre dans le cadre de vos activités existantes :

• Fournissez l'objectif à l'agent, pas seulement un prompt. Rédigez le ticket Jira sous forme de spécification, avec les critères d'acceptation sur lesquels l'agent est évalué.

• Laissez le graphique donner le contexte général. En prenant le ticket comme point de départ du prompt, le Teamwork Graph l'étend aux documents, aux décisions et au contexte associés à la tâche.

• Veillez à ce que les normes soient connues de tous et à jour. Les conventions sont centralisées dans Confluence, où tous les collaborateurs et agents y ont accès à partir d'une même source.

• Fournissez à tous les agents le même socle de contexte. Le même contexte organisationnel est accessible à tous les agents de codage, tels que Claude Code, Cursor, Codex, GitHub Copilot, l'agent de codage Jira, et bien d'autres encore.

Qu'est-ce que l'ingénierie du contexte ?

L'ingénierie du contexte consiste à déterminer délibérément quelles informations sont mises à la disposition d'un modèle à chaque étape, afin qu'un agent de codage dispose de tout ce dont il a besoin pour effectuer correctement son travail. Ces données vont bien au-delà du simple prompt : il s'agit de la base de code, de vos normes, des dépendances, de l'historique Git, des définitions des outils, des objectifs et des critères d'acceptation. La nouvelle mission consiste à établir cet ensemble pour chaque tâche.

L'ingénierie de prompt consiste à sélectionner vous-même les informations et à les intégrer dans une seule instruction. L'ingénierie du contexte consiste à faire en sorte que le système apporte à l'agent tout ce dont il a besoin tout au long d'une tâche comportant plusieurs étapes : ce qui est saisi, ce qui est récupéré, ce qui est résumé et ce qui est omis, afin que l'agent puisse trouver le reste à la demande.

Il est important de noter qu'un contexte plus riche n'est pas nécessairement un meilleur contexte :

• Le contexte à forte valeur informative désigne les informations qui contribuent réellement à la réalisation de la tâche en cours

• Le contexte à faible valeur informative désigne le contenu obsolète, hors sujet ou en double que le modèle doit tout de même lire

À mesure qu'une fenêtre de contexte se remplit de jetons à faible valeur informative, les réponses deviennent plus lentes et moins précises, même si le modèle n'a pas changé. Ce phénomène de dégradation est appelé pourrissement du contexte (en anglais, « context rot ») : il s'agit de la baisse progressive de la qualité de la sortie à mesure que la fenêtre de contexte se remplit de jetons obsolètes, de faible pertinence ou contradictoires. Une bonne ingénierie du contexte consiste tout autant à supprimer le contexte obsolète qu'à ajouter le bon contexte.

Pourquoi la fenêtre de contexte constitue-t-elle une contrainte pour les agents de codage ?

Un modèle de codage ne peut raisonner que sur ce qui se trouve dans la fenêtre de contexte, qui est restreinte par rapport à votre base de code, à votre documentation et à l'historique de votre équipe. Même un développeur compétent peut livrer du code erroné ou non sécurisé lorsque vos conventions, votre architecture ou la décision à l'origine d'une tâche n'ont jamais été intégrées dans cette fenêtre.

Lorsque c'est à l'agent qu'il revient de recueillir le contexte, certains types d'échecs reviennent sans cesse :

• L'agent s'égare dans une tâche qui s'éternise, car la décision qu'il a prise au début est évincée de la fenêtre de contexte à mesure que de nouveaux jetons, dont la valeur informative est plus faible, viennent s'y accumuler.

• Il récupère trop de données, faisant entrer dans la fenêtre bien plus d'informations qu'il n'en utilise et dépensant ainsi son budget de jetons dans des éléments parasites.

• Il ne tient jamais compte d'une norme que vous ne lui avez pas présentée, puis livre du code qui va à l'encontre des pratiques suivies par le reste de l'équipe.

• Il fonctionne très bien en solo, mais n'a aucune idée de ce que fait le reste de l'équipe ou un autre agent dans la même zone.

En revanche, en rendant le contexte pertinent facilement accessible, l'agent peut identifier lui-même les informations dont il a besoin au fur et à mesure, ce qui vous permet de formuler des prompts globaux plutôt que de devoir détailler manuellement chaque convention et chaque décision.

Comment définir le contexte pour les agents de codage dans Jira ?

Dans Jira, c'est le travail lui-même qui constitue le contexte : l'intention réside dans le ticket, les connaissances associées sont reliées via le Teamwork Graph, et les normes et décisions pérennes sont extraites de Confluence et de Loom, où chaque agent et chaque collaborateur puise dans la même source. Jira ne se limite pas aux fichiers locaux stockés sur un seul ordinateur : il englobe les objectifs, les décisions et les échanges en cours, ainsi que l'historique de l'ensemble de votre travail. Toutes ces informations sont ainsi mises en commun, ce qui permet à l'agent d'agir dans un contexte structuré, à jour et cohérent pour l'ensemble de l'équipe.

L'ingénierie de contexte repose sur trois principes :

1. Sélection des bonnes informations

2. Maintien de la structure

3. Garantie de la pérennité

1. Sélection et récupération : rédiger le ticket sous forme de spécification

La sélection consiste à choisir l'ensemble de contexte le plus petit présentant une forte valeur informative pour une tâche donnée ; la récupération consiste à extraire les informations pertinentes à la demande, plutôt que d'intégrer d'emblée l'intégralité des données dans la fenêtre. Dans Jira, ces deux processus partent du ticket.

• Fonctionnement dans Jira : indiquez l'objectif dans la description et les critères d'acceptation dans une checklist. Vous donnez ainsi à l'agent l'intention et les critères d'évaluation, sous une forme qu'il peut comprendre. Attribuez ensuite le ticket à un agent connecté. Le point de départ est le ticket et son contexte associé, et non l'ensemble de la base de code. Le sparring (échanges) avec l'agent pour peaufiner cette spécification fait partie du travail : il permet d'en apprendre beaucoup très vite et vous aide à repérer les lacunes avant même de vous lancer.

• Bientôt disponible : le Planificateur Jira transforme les idées en plans et en tickets prêts à être traités par les agents, avec le contexte déjà intégré. Inscrivez-vous sur la liste d'attente.

2. Contexte partagé : créez un lien vers le travail, ne le collez pas

La structure et le format sont essentiels : organisez le contexte de sorte qu'un agent puisse s'y repérer, et veillez à ce qu'il reste connecté plutôt que copié. Le Teamwork Graph permet d'accéder au contexte environnant sans avoir à le reconstituer manuellement à chaque fois.

• Fonctionnement dans Jira : associez le ticket aux tickets connexes, au code et aux pages Confluence contenant la spécification, la demande de modification (RFC) ou le compte-rendu de décision. L'agent hérite du contexte autour de la tâche, et pas seulement du texte du ticket. Une présentation Loom compte également : l'enregistrement d'une reproduction de bug ou d'une justification de conception intègre sa transcription et son résumé dans le graphique ; ainsi, une explication que vous auriez donnée à un coéquipier devient un contexte qu'un agent peut lire. Vous pouvez ainsi exploiter les « faits pertinents » issus de votre travail réel, et non d'un stockage vectoriel distinct que vous devriez créer et gérer.

3. Pérennité : conserver les normes et les décisions là où elles s'accumulent

La pérennité, ou mémoire, consiste à conserver des données durables d'une session à l'autre afin que l'agent ne reparte pas de zéro à chaque fois. Il faut distinguer trois catégories : ce que l'agent conserve pendant une tâche, ce qu'il doit conserver d'une tâche à l'autre, et ce qu'il peut consulter en cas de besoin.

• Fonctionnement dans Jira : les conventions, les choix architecturaux et les modèles recommandés sont centralisés dans l'espace Confluence partagé, où toute l'équipe et chaque agent puisent dans la même source via le graphique, plutôt que dans une copie stockée sur l'ordinateur d'une seule personne et inaccessible aux autres. Au fur et à mesure que le travail progresse dans le système, le graphique s'enrichit, ce qui permet à l'agent suivant de disposer de davantage d'informations sur lesquelles s'appuyer. Le contexte s'accumule alors avec l'avancement du travail, sans que le développeur ait à effectuer aucune étape manuelle supplémentaire.

Deux éléments permettent à ces principes de fonctionner au sein d'une équipe : un socle de contexte accessible à tous les agents, et une gouvernance qui garantit sa fiabilité et sa conformité.

Un seul socle de contexte pour chaque agent

Le contexte que vous mettez en place n'a de valeur que si tous les outils peuvent l'utiliser. Réapprendre vos normes à chaque agent est le moyen le plus rapide de laisser le contexte se dégrader à nouveau.

• Fonctionnement dans Jira : offrez à tous les agents de codage le même contexte organisationnel via deux voies différentes. La CLI de Teamwork Graph permet à votre agent de codage d'accéder directement à ce contexte et à ses outils depuis le terminal ; configurez-la une seule fois et votre agent pourra interroger le graphique tout en travaillant. Le serveur MCP Atlassian Rovo remplit la même fonction pour les clients MCP tels que Claude, Cursor, Codex et GitHub Copilot. C'est le Teamwork Graph qui fait toute la différence : les tickets, les décisions, les documents et le code sont reliés entre eux pour former un seul et même socle consultable. Vous définissez le contexte une seule fois, puis vous l'utilisez avec n'importe quel modèle permettant d'effectuer la tâche.

Gouvernance : garantir la fiabilité et l'autorisation d'accès au contexte

Le contexte n'est utile que s'il est à jour et si l'agent est autorisé à y accéder. La gouvernance garantit la fiabilité de la couche partagée à mesure que davantage d'agents y ont recours.

• Fonctionnement dans Jira : les agents héritent des autorisations que votre équipe utilise déjà comme base de référence. Ainsi, un agent voit ce que la personne qui l'utilise peut voir, et rien de plus, et son périmètre d'action peut être restreint davantage à l'aide de règles spécifiques à l'agent. Pour comprendre comment s'articulent l'accès, l'approbation et l'audit, consultez la page Garde-fous et sécurité de l'ingénierie agentique dans Jira.

Comment Jira s'intègre-t-il au reste de votre stack contextuel ?

Aujourd'hui, la majeure partie du contexte d'un agent de codage se trouve sur une seule machine : le dépôt qu'il a ouvert, quelques fichiers locaux et tout ce que le développeur a saisi dans le prompt. Ce système fonctionne en solo, mais il est fragmenté, propre à chaque personne et sujet à l'oubli. Jira et le Teamwork Graph rassemblent le contexte pertinent au sein d'une couche partagée, à jour et gouvernable, dans laquelle toute l'équipe et ses agents peuvent puiser.

Rien de tout cela ne remplace votre agent de codage, votre IDE ou votre configuration locale. Ce sont toujours eux qui gèrent les détails propres à chaque dépôt et le code véritable. Jira constitue la couche partagée supérieure, de sorte que le contexte dans lequel ils opèrent tous est structuré, à jour et identique pour l'ensemble de votre équipe.

Comment fournir un véritable contexte à votre premier agent dans Jira

L'ingénierie du contexte consiste essentiellement à donner à un agent les outils et les informations nécessaires pour qu'il trouve par lui-même ce dont il a besoin. Jira et le Teamwork Graph constituent la couche de contexte partagée à laquelle il accède via MCP ou CLI. Le travail consiste donc à maintenir cette couche précise et connectée.

Commencez par un ticket bien structuré pour observer la différence entre un agent qui devine et un agent qui travaille à partir d'une intention.

1. Donnez à l'agent un critère de référence pour son évaluation. Choisissez une tâche avec un périmètre bien défini, à faible risque et facile à annuler, comme un refactoring autonome ou une petite correction de bug, puis rédigez l'objectif dans la description en incluant les critères d'acceptation dans une checklist.

2. Permettez à l'agent d'hériter du contexte plutôt que de le saisir. Reliez le ticket à son code en référençant la clé du ticket dans votre branche, votre commit ou vos pull requests, et ajoutez un lien vers la documentation ou la décision qui le sous-tend. L'agent récupère le contexte associé à la tâche, et pas seulement le texte du ticket.

3. Référez-vous à un standard partagé. Liez la convention qu'il doit respecter à une page Confluence afin que le prochain agent et ses coéquipiers utilisent la même source.

4. Assignez le ticket à un agent. L'agent part du ticket et de son contexte associé, un point de départ plus ciblé que l'ensemble de la base de code ou un prompt vierge.

5. Évaluez par rapport aux critères qui en sont à l'origine. Vérifiez la pull request par rapport aux critères d'acceptation que vous avez rédigés dans le ticket, afin que la sortie soit évaluée selon les exigences initiales que vous avez fixées à l'agent.

6. Demandez à l'agent de boucler la boucle. Envoyez-lui un prompt pour actualiser le ticket à la fin en y ajoutant un résumé de la session, les décisions clés et les compromis, ainsi que la pull request associée, afin que le prochain coéquipier ou agent puisse reprendre là où il s'est arrêté grâce au Teamwork Graph.

Traitez quelques tickets de cette manière et le graphique se remplira au fur et à mesure : chaque agent laisse un résumé, ses décisions clés et la pull request associée dans le ticket, de sorte que le suivant dispose d'une vue d'ensemble plus complète que son prédécesseur. C'est ce qu'on appelle l'ingénierie du contexte, qui s'enrichit au lieu de se réinitialiser à chaque exécution.

FAQ sur l'ingénierie du contexte

Quelle est la différence entre l'ingénierie du contexte et l'ingénierie de prompt ?

L'ingénierie de prompt consiste à sélectionner manuellement les informations pertinentes pour un seul prompt. L'ingénierie du contexte consiste à implémenter un système qui fournit des informations à un agent tout au long d'une tâche en plusieurs étapes, notamment la récupération, la structure, la mémoire et l'objectif lui-même, afin de faire émerger les détails à la demande, selon les besoins.

Comment les agents de codage IA récupèrent-ils le contexte depuis Jira ?

Les agents extraient le contexte du ticket, de sa description et de ses critères d'acceptation, ainsi que du Teamwork Graph, qui relie les tâches, les documents et le code connexes. L'agent agit ainsi en fonction d'une intention réelle, et non d'un prompt vide de sens.

Pourquoi les agents de codage produisent-ils du code erroné même avec un prompt correct ?

Un prompt reflète rarement vos conventions, votre architecture ou la décision qui sous-tend une tâche. La plupart des échecs des agents sont des échecs de contexte, et non des échecs du modèle ; un meilleur contexte résout davantage de problèmes qu'une meilleure formulation.

Ai-je encore besoin d'ingénierie du contexte si mon agent lit déjà mon dépôt ?

Oui. Un dépôt indique à un agent quel est le code, mais pas pourquoi il a été conçu de cette manière, ni quelles normes respecter, ou ce qui se passe ailleurs dans l'équipe. L'ingénierie du contexte fournit le reste.

Qu'est-ce que le pourrissement du contexte ?

Le pourrissement du contexte est la dégradation progressive de la qualité de la sortie d'un agent à mesure que sa fenêtre de contexte se remplit de jetons périmés, de faible pertinence ou contradictoires. Les réponses deviennent plus lentes et moins précises, même si le modèle n'a pas changé.