Codage agentique : le contexte fait la différence

Chaque semaine, une nouvelle démonstration d'agent de codage montre comment un prompt se transforme en une merge request en moins de cinq minutes. Ces démonstrations mettent souvent en avant un cas d'utilisation très spécifique qui n’est pas encore en production, et font l'impasse sur tout ce qui se passe après le commit.

La merge request ne contient pas de lien vers le ticket qu'elle était censée corriger. Le pipeline CI/CD échoue car l'agent ignorait l'existence d'une règle de linter ajoutée récemment. Un scan de sécurité signale une dépendance que l'agent a intégrée sans vérifier la liste des dépendances approuvées du projet.

Il s’agit là de défaillances liées au contexte, qui déterminent si le codage agentique accélère la livraison ou ralentit le travail des équipes. Mais lorsque les équipes de développement utilisent des agents de codage avec GitLab, ceux-ci s'appuient sur les tickets, les pipelines et les politiques de sécurité déjà présents dans la plateforme afin de détecter les problèmes et y remédier dans le workflow de développement.

Cet article présente les changements qui interviennent lorsque vous fournissez à un agent de codage un contexte de cycle de vie de plus en plus riche, allant d'une visibilité limitée à un dépôt à une visibilité complète sur la plateforme, en s'appuyant sur deux tutoriels GitLab. Vous découvrirez comment le contexte de la plateforme améliore la qualité du code, les évaluations de sécurité et les cycles de revue, et ce que les équipes plateforme peuvent faire dès aujourd'hui pour combler cet écart.

Mise en pratique du contexte

Les tutoriels GitLab montrent ce qui se passe lorsque vous fournissez à un agent de codage externe un contexte de plateforme complet de manière progressive. Le premier tutoriel présente trois workflows avec Claude Code : la correction d'un crash de capteur C++, l’enrichissement d'une session avec le serveur Model Context Protocol (MCP) de GitLab et l’utilisation de Claude Code comme agent externe dans une merge request pour traiter les retours de revue. Le second tutoriel suit la même progression avec Codex et GitLab, en corrigeant cette fois-ci un bogue de filtrage WebSocket en Rust dans ces trois scénarios.

Scénario 1 : l'agent ne voit que le dépôt
Vous dirigez l'agent vers le code source et décrivez le problème dans un prompt. L'agent lit les fichiers, propose un correctif et lance le build. Le correctif fonctionne, mais il repose uniquement sur ce que l'agent déduit des fichiers locaux et de votre prompt. Il ne comprend pas le contexte de votre organisation : les critères d'acceptation du ticket, les exigences non fonctionnelles, ni les normes de revue définies dans la configuration CI de votre projet. Le code se compile, mais ne correspond pas forcément aux besoins de votre équipe.

Scénario 2 : l'agent voit le dépôt et le ticket GitLab
Connectez le serveur MCP de GitLab pour que l'agent puisse récupérer le ticket avant d'écrire la moindre ligne de code. Il lit alors les exigences fonctionnelles, les notes d'implémentation, les labels et les jalons. Dans le tutoriel Codex et GitLab, cela signifie que l'agent ajoute Closes #32 à la description de la merge request, car il comprend la relation entre la modification du code et le ticket. Dans le tutoriel Claude Code, l'agent utilise get_issue pour récupérer le rapport de bogue, puis create_merge_request pour créer la merge request avec les bonnes références. Cette fois, le correctif correspond à ce que l'équipe avait planifié.

Scénario 3 : l'agent intervient dans la merge request
Une fois la merge request créée, le flow Code Review de GitLab s'exécute automatiquement et partage ses retours. Dans les deux tutoriels, l'agent de codage est invoqué en tant qu'agent externe au sein de la merge request pour traiter ces retours. Il ajoute les tests manquants, met à jour les commentaires de documentation et corrige les lacunes de validation détectées lors de la revue. L'agent effectue un commit directement sur la branche de la merge request, les pipelines CI/CD s'exécutent automatiquement sur le nouveau commit, et un relecteur humain peut inspecter le résultat sans changer d'outil.

Dans ce scénario, les deux tutoriels démontrent une réduction du nombre de cycles de revue et un délai réduit avant le merge.

Importance du codage agentique et de la visibilité sur la plateforme

Si vous dirigez une équipe plateforme, vous décidez de la manière dont le développement assisté par l'IA fonctionne au sein de votre organisation. Vous définissez quels agents sont autorisés, quels outils ils peuvent utiliser, comment leurs données de sortie sont vérifiées et à quel moment du processus les décisions humaines interviennent.

L'agent a besoin de contexte pour produire des modifications auxquelles votre organisation peut se fier, et ce contexte réside dans votre plateforme DevSecOps. Votre outil de suivi des tickets répertorie les exigences. La configuration CI/CD définit le niveau de qualité attendu. Les instructions de revue de code codifient le style et les normes de l'équipe. Les scanners de sécurité appliquent les politiques en matière de vulnérabilités. Enfin, c'est dans la merge request que tout converge : l'étape où s'effectue le contrôle humain.

Un agent intégrant le contexte de la plateforme suit le même workflow que celui utilisé par les équipes de développement, avec les mêmes garde-fous. La différence réside dans les cycles de revue, les taux de réussite des pipelines et le délai avant le merge.

Un agent basé sur un IDE ou un terminal, aussi performant soit-il, ne voit que les fichiers qu'on lui fournit. La plateforme, elle, accède à l'ensemble du cycle de vie du ticket, du pipeline et de la politique de sécurité jusqu'à la cible de déploiement et aux règles d'approbation. Cet écart de visibilité explique pourquoi la plateforme de votre organisation, et non l'agent, détermine ce qui est livré en toute sécurité.

Production de code accélérée par les agents : l'impact sur la sécurité

Dans tous les tutoriels, les pipelines CI/CD et la revue de code s'exécutent automatiquement sur chaque merge request créée par l'agent de codage. Les scans de sécurité font partie des pipelines, même si les tutoriels se concentrent sur la qualité du code plutôt que sur les résultats de sécurité. Pour les équipes plateforme, le contexte devient encore plus crucial lorsque la sécurité entre en jeu.

Les agents de codage produisent davantage de code, plus rapidement. Plus de code signifie plus de vulnérabilités introduites, plus de problèmes signalés par les scanners et plus de merge requests de correction générées.

• Avant l'arrivée des agents de codage dans le workflow, le goulot d'étranglement dans la gestion des vulnérabilités se situait du côté de la sécurité applicative : scan, hiérarchisation des résultats, transmission des plus importants aux équipes de développement, puis attente d'un correctif.
• Désormais, grâce aux agents qui accélèrent la production de code et la remédiation, le goulot d'étranglement se déplace. Le workflow passe de la question « quelle vulnérabilité corriger en premier » à « quelle merge request de correctif générée par l'IA doit être revue et approuvée par un humain en premier ».

Cette décision nécessite des informations contextuelles dont l'agent de codage ne dispose pas : le code du projet dans son ensemble, le flux de données complet, la cible de déploiement et les politiques de sécurité applicables au sein de votre organisation.

• Avec un contexte, la priorisation s'affine : un agent qui s’appuie sur le code environnant, le flux de données et les politiques applicables peut classer les résultats en fonction de l'exposition réelle dans votre environnement, plutôt que selon des scores de gravité génériques et mettre en évidence les éléments réellement importants avant que les relecteurs n'y consacrent du temps.

Tout comme l'agent de codage du second scénario produisait un meilleur code lorsqu'il pouvait lire le ticket GitLab, la couche de sécurité produit de meilleures évaluations lorsqu'elle peut lire le contexte complet de l'application plutôt qu'un seul fichier.

La couche de sécurité de GitLab analyse les résultats en tenant compte du contexte complet du projet, filtre les faux positifs détectés et signale les vulnérabilités confirmées. Lorsqu'une vulnérabilité est confirmée, la résolution agentique des vulnérabilités SAST lit le code vulnérable et son contexte environnant à partir du dépôt, puis crée automatiquement une merge request avec un correctif proposé. Le pipeline s'exécute pour valider le correctif. Un relecteur humain le vérifie et prend la décision finale de fusionner la merge request. L'agent se charge de la remédiation ; et le modèle de gouvernance reste intact.

Les contrôles qualité CI/CD, les instructions de revue de code et les scans de sécurité opèrent tous dans la merge request, là où les agents de codage effectuent également leur travail. Plus ces contrôles sont efficaces au moment de la création du code, moins les vulnérabilités atteignent la production.

Instructions personnalisées avec AGENTS.md

Les deux tutoriels s'appuient sur les fichiers AGENTS.md présents dans le dépôt. Il s'agit d'instructions personnalisées destinées aux agents, qui portent sur la structure du projet, les commandes à exécuter et les exigences en matière de qualité du code, y compris ce qu'il ne faut pas modifier.

Dans le tutoriel Codex et GitLab, le fichier AGENTS.md définissait tout, de l'édition Rust au modèle de concurrence asynchrone en passant par la politique d'épinglage des images CI. L’agent n’avait pas besoin que le contexte soit répété dans le prompt. Il lisait le fichier et suivait les règles.

Cet investissement ponctuel porte ses fruits à chaque interaction avec l’agent, que celui-ci s'exécute en local dans le terminal d'un développeur, qu'il soit connecté via MCP ou qu'il fonctionne en tant qu'agent externe dans une merge request. Standardiser le fichier AGENTS.md d’un projet à l’autre améliore la qualité des résultats fournis par les agents, car chaque session d'agent, qu’elle soit locale ou distante, lit les mêmes règles.

Limites de la fenêtre de contexte

Les grands modèles de langage disposent de fenêtres de contexte déterminées, et des recherches ont montré que les performances des modèles se dégradent lorsque l'utilisation du contexte dépasse 30 à 40 %. Plus une session contient d'outils, de fichiers et d'instructions, moins le raisonnement de l’agent est fiable.

Votre organisation souhaite fournir à l'agent un contexte complet sur le cycle de vie : ticket, instructions de revue, historique des pipelines et politique de sécurité. Mais vous souhaitez également que ce contexte soit structuré, pertinent et transmis efficacement.

Au lieu que chaque session d'agent doive reconstituer le contexte en lisant des fichiers et en effectuant des appels API inutiles (ce qui dilue la fenêtre de contexte et consomme des jetons), une plateforme capable de comprendre les relations entre le code, les tickets, les pipelines et les déploiements peut fournir le bon contexte au bon moment. GitLab capture bon nombre de ces relations tout au long du cycle de vie afin de transmettre le contexte plus efficacement. Lorsque la plateforme sait à quel ticket une merge request se rapporte, quels services sont impactés par une modification du code et quels pipelines valident le résultat, elle peut transmettre ces informations sous forme de contexte structuré plutôt que de les reconstituer à partir de fragments.

L'efficacité des workflows de développement assistés par l'IA de votre organisation dépend de la capacité de votre plateforme à fournir un contexte structuré, et non de la taille de la fenêtre de contexte de votre modèle.

Un cycle de revue raccourci grâce aux agents

Lorsqu'un agent de codage traite les retours de revue d'une merge request, il agit sur la revue. L'agent lit les commentaires, apporte les modifications demandées, effectue un commit et laisse le CI/CD valider le résultat. Le relecteur humain valide toujours le résultat, en l’approuvant ou en demandant des modifications supplémentaires et prend la décision finale de fusionner la merge request.

Les règles d'approbation, les propriétaires du code, les politiques de sécurité et les pistes d'audit restent en place. L'agent accélère le cycle de revue sans contourner les contrôles qui l'encadrent.

Les agents externes de GitLab Duo Agent Platform peuvent être davantage intégrés avec des déclencheurs basés sur des événements et des flows personnalisés afin d'offrir aux équipes de plateforme un contrôle sur le moment et la manière dont les agents interviennent dans le workflow.

Vos premiers pas avec le codage agentique

Si vous évaluez la manière dont les agents de codage s'intègrent dans le workflow de développement de votre organisation :

Choisissez un bogue visible dans un projet réel. Définissez le comportement attendu dans un ticket GitLab avec des exigences claires. Suivez la même progression que celle présentée dans les tutoriels : corrigez-le localement avec l'agent travaillant depuis le dépôt, connectez le MCP de GitLab pour que l'agent travaille depuis le ticket, puis utilisez l'agent comme relecteur externe pour prendre en compte les retours dans la merge request.

Investissez dans AGENTS.md. Documentez le fonctionnement du dépôt, les commandes à surveiller et les attentes en matière de qualité du code. Ces instructions garantissent des résultats de meilleure qualité fournis par les agents, qui s’améliorent au fil du temps à mesure que davantage d’agents et d'équipes de développement interagissent avec le projet.

Surveillez la consommation liée au contexte. Si les sessions des agents sont lentes, coûteuses ou produisent des résultats superficiels, le problème est probablement dû au contexte fourni au modèle, et non au modèle lui-même. Un contexte structuré et pertinent transmis via des intégrations de plateforme, donne de meilleurs résultats que le simple dépôt de fichiers bruts.

Vérifiez la couverture de sécurité. À mesure que les agents de codage génèrent davantage de merge requests entre les projets, assurez-vous que chaque projet fait l'objet d'un scan. Appliquez des profils de configuration de sécurité au niveau du groupe afin que les scanners soient activés automatiquement, puis utilisez l'inventaire de sécurité pour confirmer la couverture et identifier les zones de concentration des vulnérabilités.

Lancez-vous dès aujourd’hui dans le codage agentique

Les organisations qui tireront le meilleur parti du codage agentique seront celles qui disposent de plateformes DevSecOps offrant aux agents le contexte et les contrôles nécessaires pour livrer en toute sécurité.

Si vous n'utilisez pas encore GitLab Duo Agent Platform, vous pouvez commencer un essai gratuit.

Si vous utilisez déjà GitLab dans l'édition gratuite, vous pouvez vous inscrire à GitLab Duo Agent Platform en suivant ces étapes.

Et si vous êtes déjà abonné à GitLab Premium ou GitLab Ultimate, lancez-vous en activant GitLab Duo Agent Platform et en utilisant les crédits promotionnels GitLab inclus dans votre abonnement.