Le développement des agents s'oriente de plus en plus vers l'évaluation
Une nouvelle étude menée auprès de professionnels du génie logiciel met en évidence une évolution que de nombreuses équipes ressentent déjà : lorsque les agents d’IA réduisent le coût de la mise en œuvre, la partie la plus difficile du travail logiciel ne disparaît pas pour autant. Elle se déplace en amont, vers la définition des exigences, l’évaluation, la révision, la discipline de déploiement et le jugement humain. Cela vient utilement corriger l’idée selon laquelle les agents de codage servent principalement à remplacer les frappes au clavier. Plus l’agent gagne en capacités, plus il est important de déterminer ce qu’il est autorisé à faire, comment mesurer sa réussite et qui valide le résultat.
L’article intitulé « How Do Practitioners Build SE Agents? Insights from a Mixed-Methods Study » (Comment les professionnels développent-ils des agents d’ingénierie logicielle ? Perspectives issues d’une étude à méthodes mixtes) est particulièrement pertinent, car il s’intéresse aux personnes qui développent concrètement des agents d’ingénierie logicielle. Les auteurs ont interrogé 20 professionnels issus de 12 organisations et en ont sondé 80 autres. Leur conclusion n’est pas que le développement par agent élimine le processus logiciel. Il le réorganise. Ils décrivent une boucle récurrente comprenant les exigences, l’évaluation, les données, la construction du système, les tests et le déploiement, le retour d’expérience humain et la maintenance adaptative. Dans cette boucle, l’évaluation n’est pas une inspection finale une fois le code écrit. Elle devient de plus en plus le mécanisme de pilotage de l’ensemble de l’effort.
Pour les responsables techniques, cela a son importance car la plupart des discussions sur le développement assisté par l’IA partent encore du mauvais pied. Ils se demandent quel modèle écrit le plus de code, quelle intégration IDE semble la plus rapide ou quel agent peut gérer la tâche la plus longue. Ce sont des questions opérationnelles valables, mais elles sont secondaires. Une équipe incapable de définir des critères d’acceptation, de cerner les contraintes du domaine, de tester le comportement de manière fiable et de vérifier les modifications générées ne gagnera pas en sécurité simplement parce que l’agent gagne en rapidité. Cela ne fera qu’augmenter la surface non vérifiée.
La mise en œuvre devient moins coûteuse, mais la responsabilité, elle, ne diminue pas
La phrase la plus utile de l’étude est l’idée que les goulots d’étranglement se déplacent plutôt que de disparaître. Lorsqu’un agent est capable de générer des fichiers, d’exécuter des commandes, de corriger des défaillances et de répéter la boucle à de nombreuses reprises, la mise en œuvre ne mobilise plus la même part d’attention. Cela ressemble à un gain incontestable, et c’est le cas dans de nombreuses situations. Les éléments standard, les structures de test, l’exploration de la base de code, les migrations, les mises à jour de la documentation et les refactorisations de routine peuvent s’accélérer. Mais chaque accélération engendre un problème de contrôle correspondant.
Si un humain écrit le code à la main, la compréhension s’acquiert généralement au fur et à mesure de la construction. Le développeur a pu observer chaque compromis, chaque raccourci et chaque cas limite délicat. Avec un agent, la construction peut devancer la compréhension. Le code qui en résulte peut se compiler, réussir un test restreint et paraître cohérent sur le plan stylistique, tout en dissimulant une hypothèse erronée. L’étude qualifie ce type de pression de « dette de compréhension » : le logiciel est intégré au système plus rapidement que l’équipe ne peut le comprendre et l’évaluer.
Cette dette n’est pas seulement une préoccupation philosophique. Elle modifie la nature de la revue de code. Les relecteurs ne se contentent plus de demander si un collègue a fait un bon choix d’implémentation. Ils doivent également se demander si l’agent a bien compris le problème, si l’instruction a omis une contrainte, si les tests ont été sélectionnés parce qu’ils étaient pertinents ou simplement parce qu’ils étaient disponibles, et si la différence (diff) est trop importante pour que le réviseur humain puisse l’assimiler de manière responsable. L’humain reste responsable du résultat, même lorsque la première ébauche provient d’un modèle.
C’est pourquoi le principe de l’« humain dans la boucle » ne devrait pas se résumer à un simple clic d’approbation passif à la fin de l’exécution d’un agent. Il devrait impliquer une appropriation active à plusieurs étapes : la formulation de l’exigence, la définition des limites de la délégation, la révision du plan, la définition des preuves, l’inspection des différences, l’interprétation des résultats des tests et la prise de décision concernant la mise en production. L’agent peut effectuer une grande partie du travail à l’intérieur de ce cadre. Il ne doit pas être maître du cadre lui-même.
L’évaluation devient un artefact de premier ordre
La recommandation pratique la plus forte de cette étude est de s’orienter vers un développement piloté par l’évaluation. Dans le développement piloté par les tests classique, les tests expriment souvent le comportement attendu avant la mise en œuvre. Dans l’ingénierie logicielle agentique, l’évaluation doit être plus large. Elle peut inclure des tests unitaires, des tests d’intégration, des ensembles de données de référence, des suites de scénarios, des traces d’utilisation des outils, des invites de régression, des contrôles de sécurité, des budgets de latence, des budgets de coûts et des grilles d’évaluation humaine. Le point important est que l’évaluation soit définie suffisamment tôt pour guider l’itération, et non trop tard pour ne servir qu’à donner un feu vert rassurant.
Pour une équipe adoptant des agents de codage, cela signifie que chaque tâche déléguée doit commencer par la question suivante : quelles preuves nous convaincraient que ce changement est sans risque ? Pour la correction d’un bug, la réponse pourrait être un test de régression qui échouait auparavant et qui réussit désormais. Pour la mise à niveau d’une dépendance, cela pourrait inclure l’examen du journal des modifications, des contrôles de compatibilité, l’inspection des fichiers de verrouillage et une note de retour en arrière. Pour un agent chargé du triage des incidents, cela peut inclure la relecture de l’historique des incidents, la tolérance aux faux positifs, les règles d’escalade et la possibilité explicite d’une intervention manuelle. Le dossier d’évaluation fait partie intégrante du produit du travail.
Cela modifie la manière dont les équipes doivent rédiger les consignes et les instructions du référentiel. Une instruction peu précise dit : fix the bug. Une instruction plus rigoureuse dit : reproduce the bug, add the smallest regression test, propose a plan, change only the affected module, run these checks, and summarize residual risk. La deuxième version ne se contente pas de demander du code. Elle définit une chaîne de preuves. C’est là toute la différence entre utiliser un agent comme une machine à écrire stochastique et l’utiliser comme un ingénieur délégué.
Cela explique également pourquoi les spécifications, les invites, les compétences, les définitions de contexte et le comportement du harnais deviennent des artefacts de premier ordre. Si le comportement d’un agent dépend de ces éléments, ceux-ci méritent d’être traités avec la même rigueur que le code. Ils doivent faire l’objet d’un contrôle de version, d’une révision, de tests et d’une attribution de responsabilité. Un fichier d’instructions au niveau du référentiel, indiquant comment construire, tester, analyser, migrer et réviser le projet, n’est pas de la bureaucratie. Il s’agit d’une infrastructure opérationnelle permettant une délégation en toute sécurité.
Le problème de l’oracle de test se pose avec plus d’acuité
Le développement piloté par l’évaluation est puissant, mais l’étude met également en évidence un piège : des signaux d’évaluation peu fiables. Dans les logiciels conventionnels, les équipes savent déjà que les tests peuvent être incomplets ou erronés. Dans les flux de travail basés sur des agents, le risque s’accroît car les agents s’optimisent en fonction de l’évaluation visible. Si le critère de référence est superficiel, l’agent peut apprendre à satisfaire ce critère plutôt que l’intention initiale. Si la suite de tests passe à côté de comportements importants, l’agent peut produire du code qui semble correct selon l’oracle disponible, mais qui échoue en conditions de production.
Cela rend le jugement humain plus important, et non l’inverse. La suite d’évaluation doit être considérée comme une aide à la décision, et non comme un décideur de substitution. Les ingénieurs seniors doivent se demander si les vérifications couvrent les bons risques, si elles reflètent les règles métier actuelles et si la solution générée est maintenable au-delà du scénario qui l’a déclenchée. Une exécution de test réussie constitue une preuve utile. Ce n’est pas un argument complet.
Une approche pratique consiste à distinguer trois niveaux de validation. Premièrement, la vérification mécanique : tests, linters, vérifications de types, analyse statique, analyse des dépendances et commandes reproductibles. Deuxièmement, la validation comportementale : scénarios, cas limites, parcours utilisateur, rétrocompatibilité, observabilité et impact opérationnel. Troisièmement, la révision humaine : cohérence de la conception, lisibilité, limites de responsabilité, implications en matière de sécurité et état de préparation à la mise en production. Des agents peuvent intervenir à ces trois niveaux, mais ce sont les humains qui doivent décider si ces niveaux sont suffisants.
Une autre approche consiste à demander à l’agent de remettre en question sa propre évaluation. Avant la fusion, exigez qu’il répertorie les cas non couverts par les tests, les hypothèses qu’il a formulées, les fichiers qu’il a délibérément évités et les raisons pour lesquelles la modification pourrait tout de même être erronée. Cela ne rendra pas le modèle parfaitement honnête ou complet, mais cela éloigne le flux de travail d’une confiance aveugle pour l’orienter vers un risque vérifiable.
Les mises à jour des modèles peuvent bouleverser la donne
L’étude décrit également un problème que toutes les équipes de plateforme reconnaîtront : les mises à jour des modèles côté fournisseur peuvent modifier le comportement même lorsque l’équipe ne modifie aucun de ses propres codes, invites, outils ou données. Dans les logiciels traditionnels, si rien n’a changé dans votre référentiel, vous vous attendez à une répétabilité. Avec les modèles externes, le substrat d’exécution peut se déplacer sous vos pieds. Le style de planification, l’utilisation des outils, la sensibilité au contexte, les comportements de refus et les préférences de code peuvent tous changer.
C’est une autre raison pour laquelle l’évaluation ne peut pas être une réflexion après coup. Les équipes qui dépendent d’agents ont besoin de suites de régression pour le comportement des agents, et pas seulement pour celui de l’application. Si une mise à jour de modèle modifie la façon dont un agent gère les migrations, lit les tickets ou modifie les tests, l’équipe doit le détecter dans un environnement contrôlé avant que cela n’apparaisse en production. Cela ne nécessite pas de bloquer toutes les mises à jour de modèles. Il s’agit plutôt de les traiter comme des mises à jour de dépendances : mesurées, testées, observables et réversibles dans la mesure du possible.
Pour les organisations utilisant plusieurs outils, la question de la gouvernance se concrétise. Qui approuve les modifications de modèle ? Quels référentiels peuvent utiliser des modes entièrement autonomes ? Quelles commandes nécessitent une approbation explicite ? Quels serveurs MCP peuvent lire ou écrire dans des systèmes externes ? Comment les invites et les compétences sont-elles examinées ? Où sont stockés les journaux des agents ? Comment les incidents sont-ils examinés lorsqu’une modification générée provoque un défaut ? Il s’agit là de questions d’ingénierie logicielle, et non de questions abstraites de politique en matière d’IA.
Ce que les équipes doivent faire dès maintenant
La réponse immédiate n’est ni d’interdire les agents, ni de les laisser fonctionner librement. La réponse pratique consiste à mettre en place un modèle opérationnel contrôlé. Commencez par des tâches délimitées pour lesquelles les preuves sont claires : ajouter des tests de régression, améliorer la documentation, effectuer de petites refactorisations, préparer des résumés de pull requests ou réaliser des migrations à faible risque. Exigez un plan avant la mise en œuvre. Exigez des commandes de vérification dans le résumé final. Veillez à ce que les différences soient suffisamment limitées pour permettre une révision humaine. Pour les chemins critiques, exigez la validation d’un responsable expérimenté même lorsque tous les contrôles automatisés sont réussis.
Investissez ensuite dans les ressources « ennuyeuses » qui renforcent la sécurité des agents : instructions relatives aux dépôts, commandes dont le bon fonctionnement est avéré, ensembles de données d’évaluation, tests de scénarios, cartes de responsabilité du code, listes de contrôle de mise en production, modèles de retour en arrière et grilles d’évaluation. Ces ressources aident autant les humains que les agents. Elles réduisent l’ambiguïté, améliorent l’intégration et transforment les connaissances tacites en contexte partagé. Le constat de l’étude selon lequel les spécifications deviennent des artefacts de premier ordre est tout à fait juste : plus nous déléguons de tâches, plus notre intention doit devenir explicite.
Les équipes doivent également mesurer les bons indicateurs. Compter le nombre de lignes générées est pratiquement inutile. Parmi les indicateurs plus pertinents, on peut citer le temps de cycle pour des catégories de tâches spécifiques, le nombre de défauts détectés par révision pour chaque modification assistée par un agent, les défauts non détectés, le taux de reprise, la couverture de test pour les comportements modifiés, les modifications de messages ou d’instructions qui réduisent les échecs, ainsi que le pourcentage de sessions d’agents produisant un diff de petite taille et vérifiable. L’objectif n’est pas d’augmenter l’activité de l’IA. L’objectif est d’obtenir un débit plus sûr.
Le point à retenir pour les développeurs seniors
Les agents d’ingénierie logicielle deviennent de véritables acteurs du processus de développement. Cela ne supprime pas la nécessité d’un contrôle humain. Cela en élève simplement le niveau d’exigence. À mesure que la mise en œuvre devient plus facile à déléguer, la valeur humaine s’oriente vers l’intention, le contexte, le jugement, la vérification et la gouvernance. Les équipes qui en tireront le plus grand bénéfice ne seront pas celles qui font le plus confiance aux agents. Ce seront celles qui établiront le lien le plus clair entre l’intention humaine, l’exécution par la machine, les preuves mesurables et la révision responsable.
La thèse pratique est simple : laissez les agents accélérer le travail, mais confiez aux humains la responsabilité du système de travail. Définissez les exigences, définissez l’évaluation, encadrez les outils, inspectez les modifications et assumez la responsabilité de la mise en production. Dans le développement assisté par l’IA, l’avenir ne réside pas dans un codage autonome sans intervention humaine. Il s’agit d’une ingénierie axée sur l’évaluation, avec les humains fermement aux commandes.
