Seuls 33% des développeurs font confiance aux réponses de l'IA : comment apprendre à un agent à travailler selon une spécification

« On va déployer l'IA, et dans six mois la moitié de l'équipe ne sera plus nécessaire » : l'auteur de cette analyse publiée sur Habr entend cette idée beaucoup trop souvent de la part de dirigeants. Ils imaginent qu'un agent reçoit une tâche en un seul prompt, écrit le code, le teste lui-même et le met en production, et qu'il ne reste aux humains qu'à cliquer sur Merge. La réalité est différente.

Supposons que vous demandiez à un agent d'accélérer le traitement des remboursements dans une boutique en ligne. Il supprime une relecture « superflue » en base de données, les tests passent au vert, mais en cas de requêtes parallèles, le client reçoit plus d'argent qu'il n'en a payé : cette lecture protégeait une règle métier, et personne n'en avait informé l'agent. D'où le chiffre de l'enquête Stack Overflow 2025 : seuls 33% des développeurs font confiance aux réponses de l'IA.

L'auteur propose de travailler par spécifications (SDD, spec-driven development) : on décrit d'abord ce que le code doit faire, puis on l'écrit et on le vérifie par rapport à cette description. Pour cela, il utilise le framework OpenSpec.

Pourquoi les démos mentent

En démo, l'agent assemble un CRUD ou accélère une requête SQL en cinq minutes. Une telle tâche n'a pas d'historique, et le résultat attendu est évident. Un système en production, lui, contient des intégrations et des règles consignées nulle part : l'agent ne sait pas quel client lit ce champ. Il comble lui-même les manques, et le code obtenu est plausible, mais pas forcément correct.

Les chiffres de Stack Overflow 2025 le confirment. 84% des développeurs utilisent l'IA ou comptent le faire, mais 33% font confiance à l'exactitude de ses réponses et 46% ne lui font pas confiance. Le grief le plus fréquent, dans 66% des cas, concerne des solutions presque correctes, mais pas tout à fait, et 45% estiment que déboguer du code généré prend plus de temps. Les auteurs du rapport DORA 2025 qualifient l'IA d'amplificateur : dans les équipes solides, elle renforce les points forts ; dans les équipes faibles, les problèmes.

Un test simple pour un dirigeant : avant de planifier des suppressions de postes, mener avec l'IA une de ses propres tâches réelles de bout en bout, c'est-à-dire concevoir une fonctionnalité, rédiger les exigences, obtenir le code, le vérifier et le mener jusqu'en production. Au bout de quelques jours, on constate que l'IA accélère le travail, mais que c'est toujours à un humain de juger si le résultat est correct.

Des spécifications plutôt que des tickets d'une ligne

Un ticket d'une ligne, l'agent le complète de sa propre initiative ; avec une spécification complète, assortie de contraintes et de cas limites, il travaille dans un cadre défini. GitHub Spec Kit, rendu public en septembre 2025, adopte une approche similaire. Son mainteneur principal, Manfred Rim, a comparé l'agent à un stagiaire très capable et très rapide, qui a besoin d'un cahier des charges précis et d'un mentor.

OpenSpec est un framework léger : les spécifications se trouvent dans le dépôt, à côté du code, en Markdown ordinaire. Il prend en charge plus de 30 outils, dont Claude Code, Cursor et GitHub Copilot. Le dossier openspec/ comprend trois parties : specs/ décrit le fonctionnement actuel du système, changes/ contient les modifications proposées (proposal, design, tasks et deltas d'exigences), et config.yaml porte le contexte du projet, transmis à l'agent lors de la création des artefacts.

Les exigences s'écrivent avec les mots-clés SHALL/MUST et des scénarios GIVEN/WHEN/THEN. Par exemple, pour un remboursement partiel : la somme de tous les remboursements d'une commande MUST NOT dépasser le montant payé, et une requête répétée avec la même clé d'idempotence ne crée pas de second remboursement. Le cycle repose sur trois commandes : /opsx:propose crée le plan, qui est relu avant l'écriture du code ; /opsx:apply réalise les tâches ; /opsx:archive fusionne les deltas dans les spécifications principales. La tâche suivante démarre ainsi avec une image à jour du système.

Contexte, invariants et skills

L'agent arrive dans le projet comme un nouveau venu à son premier jour ; il faut donc conserver à côté du code une description du système : périmètre du produit, processus métier, pipelines CI/CD, glossaire et invariants, c'est-à-dire les règles qu'aucun refactoring ne doit enfreindre. Ces derniers sont les plus souvent sous-estimés, d'où l'histoire des remboursements. Le glossaire résout un problème voisin : l'analyste écrit « annulation », alors que le code contient Refund, Reversal et Cancellation, et sans dictionnaire, l'agent choisira au hasard. L'auteur propose d'inclure la mise à jour du contexte dans la Definition of Done, au même titre que les tests.

Les skills sont des instructions réutilisables, du type « comment nous écrivons une migration » ou « comment nous relisons une PR ». Le skill review-against-spec confronte chaque scénario du delta au code et aux tests, vérifie que les invariants n'ont pas été affaiblis et produit une liste d'écarts, sans effectuer de corrections de lui-même. À la demande « regarde si tout est correct », l'agent répond en général que tout va bien, alors qu'une checklist l'oblige à chercher. Le dernier mot, en revue, reste à l'humain.

Les humains et la boucle des bugs

Les spécifications ne remplacent pas les compétences : un développeur junior voit du code qui compile et passe les tests, alors qu'un développeur expérimenté y voit une race condition ou un invariant violé. Un signal d'alerte : l'employé-relais, qui transmet le ticket à l'agent puis envoie le résultat en revue sans le lire. Toute la vérification retombe alors sur le lead, qui devient un goulot d'étranglement.

Pendant le déploiement, il faut un mentor expérimenté en SDD : il configure les règles et les skills, apprend à l'équipe à rédiger des spécifications et à relire du code généré par IA. L'auteur le compare à un scrum master : le rôle est temporaire, mais sans lui, la méthodologie se dissout dans un « on a Cursor, non ? ».

L'auteur met par ailleurs en garde contre l'antipattern « une personne, quatre rôles » : analyste métier, analyste système, développeur et testeur réunis en une seule personne. Chaque rôle contrôle les autres, et sans formation ni vérification externe, ces contrôles disparaissent. Or l'IA met en œuvre une spécification faible aussi vite qu'une bonne.

Sans processus, l'équipe réécrit des morceaux du système à chaque bug en production et en génère de nouveaux. La solution : après chaque erreur, déterminer ce qui a manqué à l'agent, que ce soit le contexte, une règle ou une vérification dans un skill. On complète ce qui manquait et on le fait passer en revue, comme une PR ordinaire. Si l'on ne corrige que le code, l'agent reproduira la même erreur dans la fonctionnalité suivante.