Agents d'IA dans le développement de logiciels : adopter avec gouvernance

Un assistant IA attend que vous le demandiez. Un agent IA se voit attribuer un objectif et agit jusqu’à ce qu’il l’atteigne ou jusqu’à ce qu’il se retrouve bloqué en essayant.

Cette différence constitue aujourd’hui la frontière la plus importante dans le développement de l’IA. Les agents de codage ne suggèrent pas d'extraits : ils acceptent une tâche, ouvrent le référentiel, modifient les fichiers, exécutent les tests, lisent ce qui a échoué, le corrigent et ouvrent une pull request pour examen.

La question pour ceux qui dirigent n’est pas de savoir si cette capacité existe. Cela existe et cela fonctionne. La question est de savoir comment l’adopter sans échanger la productivité contre le chaos.

Qu'est-ce qu'un agent de codage en pratique

Un agent travaille en boucle. Il reçoit un objectif, planifie les étapes, exécute une action, observe le résultat et décide de la prochaine étape. Répétez cette opération jusqu'à ce que vous ayez terminé ou abandonné.

Ce qui différencie l'agent de l'assistant, c'est l'autonomie sur les actions. Il ne se contente pas d'écrire le code : il exécute la commande, lit la sortie du terminal, se rend compte que le test est échoué et réessaye. Vous n'êtes pas coincé au milieu de chaque itération.

Cela vous permet de déléguer des tâches entières. « Migrer ce service vers la nouvelle version de la bibliothèque et garantir la réussite des tests » cesse d'être un script que vous exécutez manuellement et devient une demande que l'agent répond, et vous examinez le résultat final.

C'est puissant. Et c’est précisément parce qu’elle est puissante qu’elle a besoin de règles.

Où les agents interviennent

Les agents brillent dans des tâches bien définies, vérifiables et fastidieuses. Plus la définition de prêt est claire, meilleur est le résultat.

Ils sont payants en écrivant des tests pour du code existant, car les critères sont objectifs : le test réussit ou non, couvre ou non. Ils aboutissent à des refactorisations mécaniques répétées sur des dizaines de fichiers, le type de changement qui fatigue les humains et les incite à manquer d’attention. Elles se traduisent par des migrations de dépendances, des mises à jour de syntaxe et des corrections d'erreurs apparaissant dans le build.

Ils bénéficient également de l’exploration de bases inconnues. Demander à un agent de décrire le fonctionnement d'une fonctionnalité ou l'endroit où une règle métier est implémentée permet d'économiser des heures de lecture. La phase de maintenance, toujours la plus coûteuse dans les systèmes durables, est celle où je vois le plus grand retour avec le moins de risques.

Le dénominateur commun est simple : une tâche avec des critères de réussite vérifiables. Lorsqu’il existe un test indiquant « ça a fonctionné », l’agent est guidé.

Une autre caractéristique des tâches exécutées par les agents est la rapidité du feedback. Lorsque l'agent exécute une commande et voit le résultat en quelques secondes, il la réitère et la corrige lui-même. Lorsque le signal de réussite est lent, vague ou n’apparaît qu’en production, la boucle se rompt et l’agent continue de tourner. C'est pourquoi il vaut la peine de préparer le terrain : une base avec de bons tests et une construction rapide extrait beaucoup plus de valeur d'un agent qu'une base sans filet de sécurité, où chaque erreur n'apparaît que tardivement.

Là où les agents échouent

Ils échouent lorsque les critères de réussite sont ambigus ou inexistants. Décisions architecturales, choix de produits, compromis qui dépendent du contexte commercial : rien de tout cela n'a de test permettant de déterminer si c'est juste, et l'agent produira quelque chose de plausible qui pourrait être complètement faux dans votre cas.

Ils échouent dans des tâches qui nécessitent de comprendre le pourquoi, et pas seulement le comment. Un agent refactorise une fonction pour lui donner un aspect plus propre et, en cours de route, efface un handle de bord qui existait pour une raison qui n'est écrite nulle part.

Ils échouent en silence, et c’est là le risque le plus dangereux. Le code fonctionne à nouveau, les tests réussissent, la demande d'extraction semble impeccable et la logique est subtilement défectueuse. L’IA commet des erreurs avec confiance, et la confiance contamine ceux qui révisent à la hâte.

Et ils échouent à grande échelle lorsque vous faites trop confiance. Un agent qui ouvre dix pull request par jour génère dix avis de qualité douteuse pour un humain qui n’en reste qu’un. Sans gouvernance, le goulot d’étranglement migre vers l’examinateur épuisé.

Les données qui justifient la prudence

Le chiffre qui soutient cette position mérite d’être répété. Dans l’enquête Stack Overflow 2025, menée auprès de plus de 49 000 personnes, la méfiance à l’égard de l’exactitude des outils d’IA l’emporte sur la confiance, et seule une très petite fraction, 3 %, leur fait entièrement confiance.

Ce scepticisme de la part des développeurs eux-mêmes ne constitue pas une résistance au changement. C’est l’expérience de ceux qui vivent avec l’outil et qui ont vu où il bute. Un leader qui adopte des agents doit concevoir le processus en fonction de cette réalité et non contre elle.

Faire peu confiance et vérifier beaucoup n’est pas un manque d’ambition. C'est la seule façon responsable de tirer le meilleur parti de ce que les agents ont à offrir.

Comment adopter avec gouvernance

Ici, la gouvernance n’est pas une bureaucratie, c’est un ensemble de règles qui vous permettent d’utiliser les agents en toute sécurité. Cela commence par définir ce qui peut être délégué et ce qui ne peut pas le faire.

Déléguez le vérifiable et le réversible. Tâches avec des tests clairs, des changements isolés, des travaux qu'une pull request peut contenir et inverser. Ne déléguez pas les choses irréversibles et critiques sans un humain en charge : migration de la base de données vers la production, changements de configuration de sécurité, changements qui affectent les données clients.

Gardez l'agent dans les limites techniques. Environnements isolés, autorisations restreintes, pas d'accès direct à la production, pas de possibilité de déploiement seul. L'agent propose, l'humain décide de ce qui est diffusé. Pour plus de détails sur la façon d'organiser cela, j'ai écrit sur les agents d'IA dans les environnements d'entreprise et sur la gouvernance lors de l'adoption de ces outils dans les entreprises.

Traitez chaque pull request d'agent comme une pull request d'un nouveau venu dans l'équipe : examen obligatoire, sans exception, avec une attention particulière à la logique et pas seulement à la syntaxe. Et mesurez les résultats. Si le taux de défauts augmente ou si la base devient plus difficile à entretenir, l'agent n'aide pas, même s'il semble productif.

L'humain comme critique responsable

La responsabilité n'est pas délégable. Lorsque le code entre en production, c'est la personne qui l'a approuvé qui répond, et non l'outil qui l'a généré.

Cela repositionne l’ingénieur. La valeur n'est plus d'écrire chaque ligne mais de bien définir la tâche, de bien juger le résultat et de prendre la décision. Il s'agit d'un rôle plus élevé, pas moins, et il exige plus de discrétion, pas moins.

L’examinateur responsable est celui qui comprend le code au point de ne pas l’accepter. Qui remarque le bord effacé, la fausse hypothèse, le raccourci dangereux. Une équipe qui délègue à des agents mais maintient des évaluateurs solides gagne en vitesse sans perdre le contrôle. Une équipe qui délègue et assouplit la révision ne fait qu'externaliser ses bugs.

Si vous envisagez de présenter des agents, commencez petit et vérifiable : choisissez une tâche avec des tests clairs, laissez l'agent l'exécuter et examinez-la comme s'il s'agissait du travail d'une nouvelle recrue. Vous construisez une gouvernance avant l’escalade, et non après le premier incident.

Source : Enquête sur les débordements de pile 2025.