Senar : pourquoi les agents d'IA ne remplacent pas les développeurs et transforment le processus de développement

Dans la deuxième partie de la série sur SENAR, l'auteur ne s'intéresse pas à la qualité des modèles, mais au processus de développement avec des agents d'IA. L'idée centrale est simple : un agent peut écrire du code plus vite qu'un humain, mais il ne se comporte pas comme un ingénieur face à une lacune de connaissances.

Où l'agent se trompe

Le cas le plus parlant est l'audit d'un vieux système Java de 17 modules, sans documentation à jour. L'agent a produit une cartographie d'architecture convaincante : dépendances, interfaces, descriptions des composants, liens entre services. Presque tout paraissait exact, jusqu'à une ancienne couche proxy laissée par la migration vers une file de messages. Dans le code, cette couche ressemblait à un appel HTTP ordinaire, et l'agent l'a décrite avec aplomb comme un élément normal de l'architecture. Pour les personnes qui avaient déjà travaillé sur le projet, il s'agissait pourtant d'un bricolage temporaire, vestige d'une ancienne solution.

C'est là que se révèle la différence clé entre un agent et un développeur. Un humain remarque en général une construction étrange, signale le risque et va demander à l'équipe ou à l'auteur du code l'historique de la décision. L'agent, lui, comble le plus souvent l'explication manquante : il formule une raison logique, invente une finalité et ne distingue pas le fait issu du dépôt de sa propre reconstruction. Plus un tel résultat paraît soigné, plus le risque est grand que l'erreur passe la relecture et qu'une hypothèse soit prise pour une vérité d'architecture.

«

La différence entre un développeur et un agent n'est pas la vitesse ».

Cinq enseignements clés

De ce cas, l'auteur tire cinq schémas récurrents qui, selon son expérience, apparaissent sur presque tous les projets utilisant des agents d'IA pour le développement. Ils concernent non seulement la qualité du code, mais aussi la façon dont l'agent perçoit la tâche, le contexte et les conséquences de ses décisions. Ensemble, ils expliquent pourquoi le même outil peut accélérer nettement le développement sur des tâches simples et créer tout aussi vite des problèmes cachés sur des tâches complexes.

• L'agent n'a pas de mémoire du projet : si l'historique des décisions ne lui est pas transmis explicitement, il n'existe pas pour lui.
• Il exécute la tâche à la lettre et ne complète pas le contexte métier comme le ferait un développeur expérimenté.
• Une seule hypothèse erronée se multiplie vite dans une série de fichiers et d'utilitaires similaires.
• L'agent ne voit pas l'architecture au-delà du prompt en cours et choisit la voie la plus commode localement.
• Il ne vit pas avec les conséquences de ses décisions : la responsabilité de la mise en production et des données reste donc à l'humain.

La conclusion pratique de ces observations est sévère : une tâche doit contenir non seulement un objectif et des critères d'acceptation, mais aussi des scénarios négatifs, des contraintes, des interdits et des cadres d'architecture. Si on laisse des vides, l'agent les comblera lui-même. C'est pourquoi la porte d'entrée qualité de SENAR exige de réunir d'abord la spécification et le contexte, et seulement ensuite de lancer la génération. La vitesse n'est utile ici que si un humain a réduit en amont la marge d'interprétation.

Le prix de l'automatisation rapide

Le code rapide d'un agent crée un autre type de dette : la dette cognitive. Un module peut fonctionner, les tests passer, le linter se taire, sans que l'équipe comprenne pourquoi il est conçu ainsi ni quelles décisions y sont inscrites. L'auteur cite l'exemple d'un module de cache d'environ 500 lignes : deux semaines plus tard, il a fallu changer la stratégie d'éviction des données périmées, et au lieu d'une heure de travail, il a fallu une demi-journée pour reconstituer une logique qu'aucun humain n'avait explicitement décidée ni consignée.

Pour ne pas masquer les défaillances systémiques par des corrections manuelles, l'auteur propose de mesurer le MIR : la part des tâches où il a fallu remettre les mains dans le code après le travail de l'agent. Sur les projets matures, cette métrique s'est maintenue autour de 5–15 % ; au démarrage d'un nouveau projet, autour de 20 %. L'objectif n'est pas un joli rapport, mais un retour d'information : si les corrections manuelles se répètent, le problème ne vient pas d'un fichier, mais du contexte, de la spécification, des limites d'architecture ou du modèle choisi.

Le nouveau rôle de l'ingénieur

Le rôle de l'humain dans l'équipe change aussi. Selon l'estimation de l'auteur, jusqu'à 60 % du temps est désormais consacré à formuler les tâches, à réunir le contexte et à prendre des décisions d'architecture, environ 30 % à vérifier les résultats et encore 10 % à configurer les outils, les métriques et le processus lui-même. Écrire du code n'est plus le cœur du travail : l'ingénieur ressemble de plus en plus à celui qui fixe les tolérances, décompose un système complexe et vérifie que la sortie soignée de l'agent ne s'est pas transformée en erreur coûteuse.

Une conclusion est tranchée : tout ce qui n'est pas écrit n'existe pas pour l'agent. Si les frontières des modules, les conventions d'API, les raisons des décisions passées et les dépendances interdites ne vivent que dans la tête du tech lead, l'agent les enfreindra presque à coup sûr, car techniquement l'import peut fonctionner et les tests peuvent passer. C'est pourquoi la documentation dans le modèle SENAR n'est pas là pour le reporting, mais sert d'interface de travail entre l'humain, l'agent et les futurs développeurs qui devront maintenir ce code.

Ce que cela signifie

Pour les équipes qui intègrent sérieusement des agents d'IA au développement, la principale nouvelle n'est pas qu'ils accélèrent le travail. Une autre chose compte bien davantage : sans spécification stricte, sans consignation des décisions et sans vérification permanente, la vitesse se change vite en dette cognitive, et l'ingénieur passe d'auteur du code à éditeur, architecte et contrôleur qualité.