Un référentiel regorge d'instructions, mais toutes ne s'adressent pas à l'agent
Le moyen le plus rapide de rendre un agent de codage IA peu fiable est de prétendre que chaque ligne du contenu du dépôt est tout aussi fiable. Un dépôt ne se limite pas au code source. Il contient également des fichiers README, des fils de discussion sur les tickets, des commentaires de pull requests, des métadonnées de dépendances, des entrées de journal des modifications, des scripts shell, des extraits de code d’exemple et de la documentation copiée ailleurs. Une partie de ce texte est destinée à donner des instructions à un humain. Une autre partie est destinée à donner des instructions à un système de construction. Une autre partie encore est obsolète. Une partie est malveillante. Dès qu’un agent est autorisé à lire le dépôt comme contexte, l’équipe doit déterminer quel texte constitue une donnée, quel texte une instruction, et quel texte nécessite une vérification humaine avant de pouvoir influencer le comportement. Cela devient essentiel dès que l’agent peut exécuter des commandes, ouvrir des pull requests, modifier des fichiers ou agir au nom de l’équipe.
C’est pourquoi la génération actuelle d’outils basés sur des agents converge vers le même modèle, bien qu’en partant de directions différentes. L’architecture de workflow des agents de GitHub met l’accent sur l’isolation, les sorties restreintes, les écritures par étapes et la journalisation. Les recommandations de Codex d’OpenAI insistent sur l’exécution délimitée, le sandboxing et l’approbation explicite pour les actions à haut risque. Les travaux d’Anthropic sur l’injection de prompts mettent clairement en évidence le modèle de menace : chaque fois qu’un agent traite du contenu non fiable, un attaquant peut tenter de transformer ce contenu en instructions. Ce sont là les limites pratiques de la délégation. La présence d’un humain aux commandes n’est pas une exigence symbolique ; c’est le seul moyen d’empêcher que l’interprétation du contenu du dépôt ne devienne arbitraire.
Le modèle utile est simple : traiter le contenu du référentiel comme des données par défaut, et ne le considérer comme une instruction que lorsque le système le valide explicitement. Un commentaire dans un ticket ne devrait pas pouvoir réécrire la politique. Un paragraphe dans un fichier README ne devrait pas pouvoir autoriser l’accès au réseau. Une page de dépendances ne devrait pas pouvoir ordonner à l’agent de révéler des secrets ou d’ignorer des tests. Ces limites sont évidentes, mais elles sont les premières à céder lorsque la pression sur la productivité s’intensifie et que les équipes commencent à assouplir les contrôles au nom de la rapidité.
Pourquoi ce problème est-il devenu plus visible aujourd’hui ?
Le codage par agent a transformé la manière dont le travail logiciel est effectué. Les développeurs ne se contentent plus de demander à des modèles de rédiger du code dans la fenêtre de discussion. Ils délèguent des tâches qui parcourent le référentiel, inspectent les journaux, exécutent des tests, comparent des fichiers et ouvrent des pull requests. Les récentes mises à jour de GitHub concernant la révision de code en sont un bon exemple : le modèle de révision recueille désormais un contexte plus large du dépôt afin de rendre les retours plus précis et moins « bruités ». Ce contexte supplémentaire est utile. Il fait également partie de la surface d’attaque. Plus la fenêtre contextuelle est large, plus l’agent a de chances de rencontrer quelque chose qui ressemble à une instruction mais qui ne lui était pas destinée.
C’est le scénario qu’Anthropic met en avant dans ses recommandations sur l’injection de prompts. Du texte malveillant peut se cacher à l’intérieur de pages, de documents, de commentaires ou d’autres artefacts légitimes et tenter de rediriger le modèle. Dans les dépôts, cela passe plus facilement inaperçu, car le texte hostile peut se trouver au sein d’une base de code par ailleurs normale. Un commentaire malveillant sur un ticket, un fichier README de dépendance, un exemple de code copié ou même une note de configuration obsolète peuvent devenir un vecteur d’attaque. Il suffit de pousser l’agent à formuler une hypothèse erronée sur ce qu’il est autorisé à exécuter.
Les dépôts contiennent un historique, pas la vérité. Ils contiennent des intentions humaines, des intentions abandonnées et des exemples de mauvaises instructions. Un agent incapable de faire la distinction entre ces catégories finira par commettre des erreurs avec conviction. L’objectif est de faire en sorte que le système soit précis quant à ce qui peut influencer ses décisions.
Mettez délibérément en avant le contexte, sinon c’est lui qui s’imposera de lui-même
La plupart des équipes ont déjà une notion de limites de confiance au sein de leur infrastructure. L’erreur consiste à supposer que ces limites existent toujours dès lors qu’un agent commence à lire des fichiers. Un modèle ne sait pas qu’un commentaire dans un fichier Markdown est de la documentation, tandis qu’une commande dans un bloc shell est exécutable. Il sait seulement que les deux sont des tokens dans leur contexte, à moins que le système environnant ne lui indique le contraire. Cela signifie que la conception de l’agent doit inclure une couche de politique qui classe les entrées avant qu’elles ne façonnent le comportement.
Voici à quoi ressemble une version pratique de cette politique :
Repository content: readable, but not authoritative by default Issue and PR text: readable, but never a source of permission Documentation: readable, but must not override sandbox policy Code comments: informative only Machine-generated manifests: usable as data if validated External web content: untrusted until explicitly curated Human approval: required for cross-boundary actions
Cette liste est volontairement ennuyeuse. C’est une bonne chose. Il est bien plus facile d’auditer un workflow qui stipule « cette catégorie de texte peut être lue, celle-ci peut être résumée, celle-là ne doit jamais autoriser d’action » qu’un workflow qui repose sur la formulation des invites et sur l’espoir. Un référentiel n’est pas une seule et immense invite. C’est un mélange d’entrées présentant différentes propriétés de sécurité. Un agent de codage a besoin d’un classificateur, pas d’une humeur.
C’est également là que la notion d’« injection de prompt » doit être comprise dans un sens technique plus large. Il ne s’agit pas seulement d’une astuce ingénieuse dissimulée dans une page Web malveillante. Il s’agit de toute situation dans laquelle un texte non fiable persuade un agent de réinterpréter sa propre mission, ses autorisations ou ses contraintes. Dans le domaine du développement logiciel, cela peut se produire par les voies les plus simples : exemples copiés, documentation des outils, notes d’installation, code généré, fichiers README des fournisseurs et modèles de tickets. Si une équipe n’a pas attribué de niveaux de confiance à ces entrées, l’agent les déduira, et cette déduction finira par être erronée.
Pourquoi l’humain reste aux commandes
On entend parfois parler d’« intervention humaine » et on imagine une personne cliquant sur « approuver » à chaque petite action. Ce n’est pas la version utile. La version utile est à la fois plus ciblée et plus puissante. L’humain définit la politique qui détermine ce qui peut être lu, ce qui peut être écrit, ce qui peut accéder au réseau et ce qui doit être bloqué pour examen. L’agent peut alors effectuer le travail de routine dans le respect de ces règles. L’humain n’est pas là pour microgérer chaque frappe. L’humain est là pour contrôler la limite de confiance.
Cette distinction est importante car la « fatigue de validation » est bien réelle. Si un agent interrompt le flux de travail pour chaque action sûre et réversible, les utilisateurs finiront par élargir les autorisations ou ignorer les garde-fous. Les modifications à faible risque peuvent être effectuées au sein du bac à sable. Les changements à haut risque nécessitent une étape de vérification délibérée. Les actions intersystèmes, l’accès à l’environnement de production et les opérations impliquant des informations confidentielles doivent rester explicitement sous la responsabilité humaine.
Les recommandations de Codex d’OpenAI sont utiles à cet égard, car elles considèrent les validations et le bac à sable comme complémentaires, et non comme concurrents. Le bac à sable définit la limite technique ; les validations définissent la limite politique. Un système incapable d’écrire en dehors de son espace de travail ne devrait pas nécessiter de longue discussion pour justifier cette limite. Un système qui souhaite intervenir sur l’environnement de production ou accéder à un domaine inconnu devrait être bloqué par conception.
La télémétrie fait partie intégrante du plan de contrôle, ce n’est pas un élément ajouté après coup
Les limites de confiance sont plus faciles à maintenir lorsque le flux de travail est observable. Si l’équipe ne peut pas reconstituer ce que l’agent a lu, ce qu’il a tenté de faire, ce qu’il a modifié et pourquoi il s’est arrêté, alors la limite est déjà plus fragile qu’elle ne le paraît. L’architecture de flux de travail agentique de GitHub insiste explicitement sur la nécessité de tout consigner dans les journaux, car ce sont ces journaux qui rendent possibles la révision, la restauration et la réponse aux incidents. Les recommandations Codex d’OpenAI soulignent le même point concernant la télémétrie native aux agents : le système doit conserver suffisamment d’informations pour que les opérateurs puissent comprendre l’intention et le résultat, et pas seulement les codes de sortie du processus.
Cela revêt une importance particulière lorsque l’agent opère sur le contenu d’un dépôt présentant des niveaux de confiance hétérogènes. La question n’est pas seulement de savoir si l’agent a accepté une instruction malveillante. La question est de savoir si l’équipe peut voir comment cette instruction est entrée dans le contexte, si elle a été prise en compte ou ignorée, et si des instructions similaires sont désormais présentes ailleurs dans le dépôt. De bons journaux transforment un incident isolé en un schéma que vous pouvez analyser. De mauvais journaux en font une histoire dont il manque des pièces.
La télémétrie modifie également les comportements avant même qu’un problème ne survienne. Lorsque les ingénieurs savent que les appels d’outils, les validations et les sources de contenu sont enregistrés, ils conçoivent des flux de travail plus faciles à comprendre. La meilleure barrière de sécurité n’est pas seulement une barrière. C’est un enregistrement qui explique à l’ingénieur suivant ce qui s’est passé et pourquoi.
Les modes de défaillance sont généralement banals, et non pas dignes d’un film d’action
Il est tentant d’imaginer l’injection de prompt comme une prise de contrôle spectaculaire : un commentaire malveillant pousse l’agent à exfiltrer des secrets, à supprimer du code ou à réécrire un dépôt. Ces défaillances se produisent bel et bien lors d’exercices de « red team », mais le problème le plus courant est plus subtil. L’agent lit une instruction obsolète et passe du temps à optimiser pour la mauvaise cible. Il traite un texte d’exemple comme une règle. Il suit un fichier README de dépendance de manière plus littérale qu’il ne le devrait. Il copie une commande non sécurisée depuis une page de documentation dans un workflow. Il élargit la portée d’une correction parce que le texte environnant donnait l’impression que cette étape supplémentaire était raisonnable.
Ces défaillances sont dangereuses précisément parce qu’elles ressemblent à de la productivité normale. Un bon agent est censé être rapide, autonome et prêt à combler les lacunes. Ce même comportement devient une faiblesse lorsque les lacunes concernent la confiance, et non la syntaxe. Une petite erreur dans le choix du contexte peut conduire à un correctif apparemment sensé, mais qui repose en réalité sur une prémisse erronée. L’équipe passe alors du temps à examiner un diff généré à partir d’une hypothèse fausse. C’est pourquoi la qualité de la révision dépend de l’hygiène des données d’entrée. Si le contexte est vicié, le diff est contaminé avant même qu’un humain ne le voie.
Un autre mode de défaillance courant est l’autorité trop étendue. L’agent est autorisé à inspecter le dépôt, il commence donc à se comporter comme si chaque artefact associé était à sa disposition. Il est autorisé à modifier des fichiers, il commence donc à apporter des modifications opportunistes en dehors de la tâche initiale. Il est autorisé à consulter la documentation, il commence donc à faire davantage confiance à la documentation qu’à la politique. Il ne s’agit pas uniquement de bogues du modèle. Ce sont des bogues de délégation. Le système a accordé au modèle plus de droits que ne l’exigeait la tâche, puis s’est montré surpris lorsque le modèle en a fait usage.
À quoi ressemble un modèle opérationnel sensé
Un bon modèle opérationnel pour le développement assisté par l’IA ne cherche pas à éliminer l’ambiguïté. Il l’intègre. Il laisse à l’agent suffisamment de marge de manœuvre pour se montrer utile, tout en conservant aux humains le contrôle des décisions critiques. En pratique, cela se traduit par quelques règles concrètes.
- Séparer le contexte lisible des instructions faisant autorité.
- Par défaut, ne conservez pas d’informations confidentielles dans la mémoire accessible à l’agent.
- N’autoriser les écritures que dans le périmètre le plus restreint possible.
- Exiger une autorisation pour l’accès au réseau, l’accès à l’environnement de production et les modifications irréversibles.
- Consigner les appels d’outils, les sources de contexte, les autorisations et les annulations.
- Réviser régulièrement la politique, et pas seulement le diff final.
Ces règles n’ont rien de prestigieux, mais c’est précisément ce genre de discipline sans glamour qui permet aux équipes d’utiliser l’IA sans perdre le contrôle. La validation de sécurité de GitHub pour les agents de codage tiers va dans le même sens : même lorsqu’un agent externe génère du code directement dans un dépôt, la plateforme exécute tout de même CodeQL, des vérifications de dépendances et une analyse des secrets avant que le travail ne soit considéré comme sûr. C’est la bonne approche. Génération ne rime pas avec confiance. C’est la validation qui transforme un correctif en quelque chose que l’équipe peut accepter.
Une habitude utile consiste à poser une question simple chaque fois que l’agent suggère une modification : « Quelle catégorie de texte l’a convaincu que c’était une bonne idée ? » Si la réponse est un fichier source, tant mieux. S’il s’agit d’un paragraphe du fichier README, d’un commentaire sur un ticket, d’un extrait copié ou d’un document fournisseur dont la provenance n’est pas claire, l’équipe doit prendre le temps de réfléchir. Cette question ne vise pas à mettre le modèle en doute, mais à comprendre quelle partie de l’environnement a influencé la décision.
Conclusion : garder la limite visible
Les arguments en faveur du développement assisté par l’IA sont solides lorsque la tâche est bien délimitée, que la politique est explicite et que le résultat peut être vérifié. Ces arguments s’effondrent lorsque le système part du principe que tout le contenu du dépôt est tout aussi fiable. Un référentiel contient du contexte utile, mais il contient également des conventions obsolètes, des exemples copiés, des instructions accidentelles et parfois des pièges délibérés. Si un agent est autorisé à traiter ce mélange comme une source de vérité unique et incontestable, l’équipe n’a pas construit un assistant. Elle a construit un délégué facilement induit en erreur.
Le meilleur modèle est simple : laissez l’agent lire largement, mais ne lui accordez une confiance limitée. Laissez-le rédiger, inspecter et résumer, mais ne le laissez pas transformer un texte en instruction sans décision politique préalable. Gardez les transitions dangereuses visibles. Veillez à ce que les journaux soient complets. Laissez l’humain responsable de la délimitation des limites. C’est ce qui rend le système suffisamment sûr pour être utilisé et suffisamment honnête pour s’améliorer.
Le référentiel n’est pas le chef. C’est l’humain qui l’est. C’est ce plan de contrôle qu’il faut préserver, et c’est la seule façon pour que les outils de codage basés sur l’IA deviennent plus que de simples moyens rapides d’automatiser les erreurs.
