Pourquoi est-ce important aujourd’hui ?
Les agents de codage ne sont plus de simples assistants qui se contentent de compléter une ligne dans un éditeur. En 2026, ils lisent les tickets, modifient plusieurs fichiers, installent des dépendances, exécutent des commandes, résument les erreurs, proposent des corrections et ouvrent des pull requests. Cette évolution est utile pour les équipes de développement, mais elle modifie la nature des risques. Lorsqu’un agent agit avec les autorisations d’un développeur, une mauvaise instruction, une dépendance inventée ou une révision trop optimiste peut se transformer en incident de sécurité, en régression ou en dette technique difficile à reconstituer par la suite.
La publication par l’OWASP d’un aide-mémoire pratique intitulé « Secure Coding with AI » (Codage sécurisé avec l’IA) donne un cadre concret à cette réflexion. Elle ne dit pas que les développeurs doivent rejeter les agents. Elle affirme au contraire que si les agents s’intègrent de plus en plus naturellement dans la chaîne de développement, ils doivent être considérés à la fois comme une surface d’attaque et comme un processus d’ingénierie nécessitant une gouvernance. C’est exactement l’attitude dont les équipes ont besoin si elles souhaitent gagner du temps sans transformer l’IA en une boîte noire.
Le message central est clair : l’IA peut aider à produire, analyser et corriger du code, mais elle ne doit pas devenir le décideur implicite. La responsabilité reste humaine. Un développeur, une équipe ou une organisation doit décider ce que l’agent est autorisé à lire, ce qu’il peut exécuter, quelles dépendances peuvent être intégrées au produit, quels tests sont réellement pertinents et qui approuve la mise en production.
De l’assistance à l’action : le saut opérationnel
Le premier changement est d’ordre opérationnel. Un assistant classique suggère du texte ; un agent agit. Il peut appeler un shell, écrire dans le référentiel, modifier la configuration CI, interroger de la documentation externe, utiliser des serveurs MCP ou publier une branche. Cette capacité supprime des boucles de travail entières, mais elle confère également au modèle un rôle au sein du système de production logicielle. À partir de là, les contrôles habituels doivent s’appliquer : principe du moindre privilège, journalisation, séparation des environnements, révision indépendante et politique explicite.
Un agent de codage évolue également dans un environnement regorgeant d’entrées non fiables. Une issue GitHub, un commentaire de pull request, un fichier README, une trace d’erreur ou une page web peuvent contenir des instructions que le modèle considère comme pertinentes. L’OWASP insiste sur ce point, car cela transforme l’injection de prompt en un problème de chaîne d’approvisionnement. Une instruction malveillante n’a pas besoin d’être envoyée directement par un développeur ; elle peut être dissimulée dans le contexte que l’agent consulte pendant qu’il effectue son travail.
Pour un responsable technique, la conclusion pratique n’est pas « d’interdire l’agent », mais « de le contraindre ». Restreindre le contexte, désactiver l’accès au réseau lorsqu’il n’est pas nécessaire, exécuter les commandes dans un bac à sable, bloquer l’accès aux secrets de production et examiner les modifications inattendues constituent des contrôles raisonnables. Ils rendent l’agent plus fiable sans lui ôter sa valeur.
Les dépendances suggérées par l’IA doivent être vérifiées
La sélection des dépendances représente un risque très concret. Les assistants peuvent suggérer des noms de paquets inexistants, obsolètes ou proches de bibliothèques réelles. Les attaquants peuvent alors enregistrer ces noms dans des registres publics et attendre que les développeurs les installent. Cela est particulièrement dangereux lorsque les agents fonctionnent en mode d’acceptation automatique, car une suggestion peut se transformer en commande d’installation sans intervention humaine.
La solution est d’ordre procédural. Chaque dépendance suggérée par l’IA doit être vérifiée avant d’être intégrée au projet : existence réelle, responsable de maintenance, ancienneté du paquet, activité, vulnérabilités connues, popularité, licence et compatibilité avec l’architecture existante. Les audits automatisés tels que npm audit, pip audit, govulncheckOSV ou la base de données consultative de GitHub ne remplacent pas le jugement humain, mais ils constituent un filet de sécurité indispensable.
Cette discipline permet d’éviter une erreur courante : évaluer la qualité d’un agent uniquement à l’aune du nombre de tâches qu’il accomplit. Un agent qui ajoute rapidement une dépendance inutile ou fragile peut accélérer le travail aujourd’hui, mais le ralentir demain pour toute l’équipe. Le rôle du développeur senior est de transformer la proposition en décision : accepter, rejeter, remplacer ou isoler.
La révision par l’IA n’est pas une validation
GitHub documente désormais des capacités plus étendues de révision de code par Copilot : analyse du contexte du dépôt, commentaires sur les pull requests, suggestions pouvant être appliquées rapidement et possibilité de déléguer certaines corrections à un agent cloud. Cela s’avère utile, notamment pour repérer les incohérences, demander des améliorations en matière de lisibilité ou accélérer le retour d’information sur de petites modifications. Mais la documentation précise également que Copilot peut passer à côté de certains problèmes et commettre des erreurs. Elle recommande de valider soigneusement ses retours et de les compléter par une révision humaine.
Cette nuance est importante. Une révision générée par l’IA peut constituer un excellent premier filtre, mais elle ne doit pas devenir une validation définitive. Le danger apparaît lorsqu’une équipe cumule deux automatisations : un agent rédige la correction, un autre agent la révise, et un pipeline « vert » crée un sentiment de sécurité. Si personne ne vérifie l’intention, les invariants métier, la sécurité et les effets secondaires, la chaîne est rapide mais non responsable.
La meilleure pratique consiste à rendre la révision par IA visible et subordonnée. Les commentaires de l’IA doivent aider le réviseur humain, et non le remplacer. Les règles de fusion doivent clairement stipuler qu’un responsable humain approuve la modification. Les pull requests générées par des agents doivent être identifiables, liées à une demande explicite, accompagnées d’un résumé des fichiers modifiés, et soumises aux mêmes normes que le code écrit par des humains.
Les tests générés par des agents ne suffisent pas
Les agents sont très doués pour produire des tests plausibles, mais un test plausible n’est pas nécessairement un bon oracle. Il peut figer le comportement défectueux que l’agent vient de créer, éviter les cas limites, supprimer une assertion gênante ou augmenter artificiellement la couverture. C’est l’un des pièges les plus importants du développement assisté par l’IA : confondre la réussite des tests avec la validation de l’exigence.
Un workflow robuste sépare les rôles. L’agent peut proposer des tests, mais un humain doit vérifier ce que ces tests démontrent. Pour les domaines critiques, l’équipe peut exiger une vérification indépendante : tests existants protégés contre la suppression, assertions métier rédigées avant la génération, révision par un développeur n’ayant pas piloté l’agent, analyse statique, fuzzing ou exécution dans un environnement isolé. La question n’est pas « le pipeline est-il vert ? », mais « le pipeline mesure-t-il le bon risque ? ».
Cette distinction est particulièrement importante pour les petites équipes. Lorsque la pression liée à la livraison est forte, l’agent peut donner l’impression que tout est sous contrôle : code produit, tests ajoutés, résumé convaincant rédigé. Or, ce résumé fait partie du résultat issu du même système. La décision finale doit rester fondée sur des preuves externes : diff lisible, tests pertinents, journaux, métriques et révision humaine.
Concevoir le workflow avec des points d’arrêt
La bonne architecture pour la collaboration entre l’humain et l’agent n’est pas l’autonomie totale. Il s’agit d’une délégation avec des points de contrôle. Avant le début du travail, l’humain définit l’objectif, la portée, les fichiers autorisés, les outils disponibles et les critères d’acceptation. Pendant le travail, l’agent exécute, explique et laisse des traces. Une fois le travail terminé, l’humain révise, demande des corrections, vérifie les dépendances, exécute des tests et décide si la modification peut être fusionnée.
Ce modèle fonctionne car il tire parti des atouts de chaque partie. L’agent est rapide pour explorer, appliquer un modèle répétitif, produire une première ébauche ou résumer une base de code. L’humain est plus à même de comprendre le contexte organisationnel, d’évaluer les risques, de rejeter une solution séduisante mais fragile, de détecter les incohérences métier et d’assumer la responsabilité de la mise en production. La productivité résulte de cette combinaison, et non de la suppression de l’un ou l’autre de ces rôles.
Les équipes peuvent formaliser ce modèle à l’aide de règles simples : pas d’acceptation automatique sur les dépôts sensibles, pas d’accès aux secrets de production, pas de nouvelles dépendances sans validation, pas de modification des tests existants sans justification, pas de fusion sans responsable humain, et des journaux des outils utilisés. Ces règles ne ralentissent pas l’innovation ; elles empêchent l’innovation de dépendre du hasard.
Ce que les équipes peuvent faire cette semaine
L’aide-mémoire de l’OWASP et la documentation de GitHub sur la révision par Copilot convergent vers la même idée : l’adoption d’agents nécessite un système de contrôle. Une équipe peut commencer modestement. Elle peut dresser l’inventaire des outils d’IA utilisés, identifier les cas où l’acceptation automatique est activée, vérifier quelles informations confidentielles sont accessibles depuis les environnements de développement, documenter les règles de révision pour les pull requests générées par des agents, et ajouter une étape d’audit des dépendances.
- Désignez un responsable humain pour chaque modification assistée par l’IA.
- Limitez les autorisations au dépôt, aux fichiers et aux outils nécessaires à la tâche.
- Vérifiez les dépendances proposées par l’IA avant toute installation.
- Conservez les traces : invite initiale, résumé de l’agent, commandes exécutées et fichiers modifiés.
- Utilisez la révision par l’IA comme une aide, jamais comme une validation finale.
Ces mesures sont pragmatiques. Elles ne nécessitent ni une vaste plateforme de gouvernance ni un comité lourd. Elles établissent simplement que l'agent fait partie du processus de développement et doit donc être observable, limité et vérifié.
Le rôle du responsable technique évolue lui aussi
La gouvernance des agents n’est pas seulement une question d’outils. Elle modifie la manière dont un développeur en chef, un directeur technique ou un responsable de la sécurité dirige son équipe. L’organisation doit clarifier quelles tâches peuvent être déléguées, quels dépôts nécessitent une supervision plus stricte, comment documenter une décision prise avec l’aide de l’IA, et comment former les développeurs juniors à examiner les résultats des modèles sans se laisser intimider par ceux-ci. Le risque n’est pas que les développeurs recourent trop à l’IA ; le risque est qu’ils l’utilisent sans disposer d’un langage commun pour aborder la confiance, l’incertitude et les preuves.
Une pratique utile consiste à considérer les premières demandes de fusion générées par l’agent comme des cas d’apprentissage. L’équipe peut examiner ensemble les différences, comparer le résumé de l’agent avec les modifications réelles, identifier les fichiers inattendus, noter les dépendances qui ont été ajoutées et se demander ce qu’une révision rapide aurait pu manquer. Cela permet de développer une nouvelle compétence : superviser un travail logiciel partiellement produit par une machine. Cela renforce également la responsabilité, car chacun constate que la rapidité n’a de valeur que lorsqu’elle reste explicable.
À terme, les organisations les plus efficaces ne seront pas celles qui laissent les agents agir partout sans entrave. Ce seront celles qui adapteront le niveau de contrôle au niveau de risque : une grande autonomie pour la documentation interne ou les refactorisations mécaniques, une validation stricte pour la sécurité, les paiements, les données personnelles et les migrations irréversibles. La maturité consiste à choisir consciemment où gagner du temps et où ralentir délibérément pour protéger le produit.
Pour les équipes de plateforme, cela signifie également que la politique relative aux agents doit s’inscrire dans le prolongement des contrôles techniques existants. Les règles de référentiel, la protection des branches, les vérifications d’intégration continue (CI), les listes blanches de dépendances, l’analyse des secrets et les tableaux de bord d’observabilité expriment déjà la manière dont l’organisation gère les risques. Les agents IA doivent s’intégrer à ce système plutôt que de le contourner. Lorsqu’un agent ouvre une pull request, les mêmes contrôles doivent s’appliquer, et lorsque ces contrôles échouent, le résultat de l’agent doit être considéré comme un brouillon nécessitant des corrections, et non comme la preuve que le processus est trop strict. Cela permet aux développeurs de rester dans un cadre familier : l’outil est nouveau, mais la discipline d’ingénierie reste reconnaissable. L’objectif concret est une accélération prévisible, et non des exploits non encadrés de la part des équipes.
Conclusion : accélérer sans déléguer la responsabilité
Les agents de codage ne cesseront de s’améliorer. Ils s’intégreront de plus en plus aux tickets, aux discussions d’équipe, aux IDE, aux pipelines d’intégration continue et aux systèmes de révision. C’est une bonne nouvelle pour les développeurs qui souhaitent réduire les tâches répétitives et se concentrer sur l’architecture, la qualité et la livraison. Mais plus l’agent devient performant, plus la gouvernance prend de l’importance.
L’approche durable ne consiste pas à choisir entre une confiance totale et le rejet de l’IA. Elle consiste à mettre en place un workflow dans lequel l’IA accélère l’exécution tandis que les humains conservent le pouvoir de décision. L’OWASP met en évidence les risques, GitHub souligne les limites de la révision automatisée, et les équipes logicielles disposent désormais d’une feuille de route claire : déléguer le travail, pas la responsabilité.
