L'IA ne sert pas à livrer plus vite : elle finance la qualité qu'on sacrifiait

Mars 2026. Une équipe que j’accompagne livre en deux jours une fonctionnalité qui en aurait pris cinq. L’agent a fait le gros du travail et le lead est ravi du gain de vitesse. Le temps économisé, l’équipe l’a automatiquement reversé dans la feature suivante.

Trois semaines plus tard, un CVE remonte sur une dépendance transitive que personne n’avait jamais regardée. Les tests affichaient 82 % de couverture ; en les ouvrant, la moitié n’assertait rien de réel. Le temps gagné par l’IA n’avait pas acheté plus de sûreté. Il avait acheté plus de surface à défendre.

L’IA n’a pas créé ce problème ; elle a accéléré le rythme auquel on le fabrique. Le vrai gain des agents n’est pas la vitesse de livraison : c’est un budget d’effort récupéré, qu’on nomme souvent le dividende de l’IA. Et la seule question qui compte, c’est où on le réinvestit.

En résumé — Les agents IA peuvent réduire significativement le coût de production du code. Ce gain n’améliore pas la qualité miraculeusement ; il libère du temps, et donc un budget qui peut enfin être alloué aux angles morts historiques : la qualité réelle et la couverture des tests, l’hygiène des dépendances, la sécurité. Le Spec-Driven Development est le cadre qui rend ce réinvestissement systématique plutôt qu’optionnel. La limite : le dividende ne se concrétise que si une stratégie décide explicitement de le dépenser là. Dans le cas contraire, il se transforme en dette.

Où part le temps que l’IA fait gagner ?

Dans toujours davantage de features, presque toujours. Et c’est exactement l’erreur à éviter.

Quand le coût marginal d’une fonctionnalité baisse, la tendance naturelle est d’en produire davantage. Le backlog se vide plus vite, le management voit la vélocité grimper. Le gain est visible, immédiat, valorisé. Personne n’est récompensé pour avoir transformé deux jours gagnés en deux jours de durcissement d’une codebase qui marchait déjà.

C’est un piège qui est cependant bien documenté. Selon le rapport DORA 2024 de Google Cloud, une hausse de 25 % de l’adoption de l’IA était associée à une baisse estimée de 7,2 % de la stabilité de livraison. L’IA accélère la production. Elle ne stabilise rien par défaut.

Le dividende de l’IA, ce n’est pas un gain de temps à dépenser en toujours davantage de production. C’est un budget à réallouer vers ce qu’on n’avait jamais le temps de faire.

La couverture de tests suffit-elle à mesurer la qualité ?

La réponse est simple : non. La couverture mesure les lignes exécutées, pas les comportements vérifiés. Et l’IA rend ce malentendu plus dangereux que jamais.

Demander à un agent « écris les tests manquants » produit en quelques secondes une suite qui fait grimper la couverture à 90 %. Le problème : un test peut exécuter une ligne sans rien affirmer d’utile à son sujet. On obtient des assertions tautologiques, des mocks qui valident le mock, des cas nominaux dupliqués et zéro cas limite. La barre verte ment ; elle dit « couvert », pas « protégé ».

La vraie métrique, c’est le mutation score : on introduit volontairement des bugs dans le code (par exemple un > qui devient >=, un + qui devient -) et on mesure combien la suite de tests en attrape. Un outil comme Stryker Mutator révèle ce que la couverture cache : des suites à 85 % de couverture qui tuent 40 % des mutants. C’est là que le dividende de l’IA devient intéressant. Le temps gagné sur la production de code paie le coût, longtemps jugé prohibitif, de tester la qualité des tests eux-mêmes.

Le réinvestissement utile n’est donc pas « plus de features développées », ou « plus de tests générés par l’IA ». C’est « plus de tests qui tuent les mutants », des tests utiles, de qualité et à forte valeur ajoutée, pas des tests qui font joli sur un tableau de bord.

Une suite de tests verte prouve que le code s’exécute, pas qu’il est protégé. Photo : Chris Ried sur Unsplash.

Pourquoi la gestion des dépendances est-elle l’angle mort le plus rentable ?

Parce que c’est le poste où le risque est maximal et l’attention souvent minimale. La plupart des vulnérabilités d’un projet ne vivent pas dans le code qu’on a écrit, elles vivent dans le code qu’on a installé sans le lire.

Selon le rapport Sonatype State of the Software Supply Chain 2024, la grande majorité des vulnérabilités open source proviennent de dépendances transitives : celles qu’aucun développeur n’a choisies explicitement, embarquées par les dépendances présentes dans un projet et qu’on remet trop rarement en question. Un npm install tire des centaines de paquets dont personne dans l’équipe ne connaît le mainteneur. C’est la surface d’attaque qu’on néglige précisément parce qu’on ne la voit pas.

Historiquement, tenir cet engagement de surveillance coûtait cher : suivre les CVE, trier les mises à jour, distinguer le patch de sécurité urgent du bump cosmétique, tester que rien ne casse. Du travail rébarbatif, et souvent repoussé. C’est exactement le genre de tâche que le dividende de l’IA permet de financer :

• Automatiser la détection : Dependabot et Renovate ouvrent les PR de montée de version ; un agent les trie, lit les changelogs et regroupe ce qui peut l’être.
• Évaluer le risque amont : un outil comme Socket analyse le comportement réel d’un paquet (scripts d’installation, accès réseau, accès filesystem) avant de l’ajouter, là où l’audit manuel n’avait jamais lieu.
• Valider la non-régression : c’est là que la qualité des tests de la section précédente paie ses intérêts ; une suite qui tue les mutants permet de merger un patch de sécurité en confiance.

Le réinvestissement ici est presque pur gain : un travail que personne ne voulait faire, désormais à portée parce que le temps existe pour le superviser.

La sécurité se déplace-t-elle vraiment vers l’amont avec l’IA ?

Oui, à condition de dépenser le dividende pour ça plutôt que de l’empocher en features. Le code généré n’est pas sûr par nature ; il reproduit les patterns de son entraînement ainsi que du code legacy qui l’entoure, vulnérabilités comprises.

Un agent reproduit fidèlement les vulnérabilités vues à l’entraînement. Photo : Markus Spiske sur Unsplash.

L’injection SQL, les secrets en dur, la désérialisation non sécurisée, les contrôles d’accès oubliés : un agent reproduit fidèlement ce qu’il a vu mille fois, et le catalogue de ce qu’il a vu inclut tout l’OWASP Top 10. Le volume de code augmentant, le volume de vulnérabilités potentielles suit. Reverser le temps gagné dans le durcissement n’est pas un luxe, c’est ce qui évite que la vitesse devienne une dette de sécurité à intérêts différés.

Concrètement, ce budget finance ce qu’on n’instrumentait jamais assez : un scan SAST sur chaque PR, un threat modeling sur les fonctionnalités sensibles, une revue ciblée sur les frontières du système (entrée utilisateur, API externes, authentification). Et surtout, il finance le câblage de ces contrôles dans le pipeline CI/CD comme des barrières bloquantes, pas comme des rapports qu’on lit le vendredi. Une vulnérabilité qui casse le build est traitée ; une vulnérabilité dans un rapport est ignorée.

Comment le SDD transforme-t-il ce dividende en discipline qualité ?

En inscrivant les exigences de qualité et de sécurité dans le contrat, là où elles deviennent non négociables au lieu de dépendre de la bonne volonté d’une fin de sprint.

Tout ce qui précède partage une faiblesse : ça repose sur une décision d’équipe de « bien faire », et cette décision est la première sacrifiée sous pression. Le Spec-Driven Development règle ce point en amont. Quand la spécification est la source de vérité que l’agent IA consulte avant chaque décision d’implémentation, on y encode directement les critères qui, sinon, s’évaporent :

• Les critères d’acceptation incluent les cas limites à tester, pas seulement le chemin nominal.
• Les invariants architecturaux incluent les contraintes de sécurité (« ce service ne reçoit jamais d’entrée non validée », « aucun secret hors du gestionnaire de secrets »).
• La politique de dépendances devient une contrainte explicite, pas une coutume orale.

Le dividende de l’IA et le SDD se complètent exactement. L’IA libère le budget ; la spec décide où il va, et le rend opposable. Sans spec, le temps gagné retombe par gravité dans le bac « plus de features ». Avec elle, la qualité et la sécurité font partie de la définition de « terminé », au même titre que « ça compile ».

Le dividende n’est pas automatique

L’IA est un amplificateur, pas un correcteur. Elle amplifie ce qui est déjà sain dans une organisation, et elle amplifie tout aussi fidèlement ce qui est défaillant. Une équipe qui rognait les tests et ignorait ses dépendances ne deviendra pas rigoureuse parce qu’elle code plus vite : elle accumulera juste sa dette à une cadence supérieure, comme le suggère la baisse de stabilité observée par DORA.

Le dividende qualité existe, mais c’est un choix d’allocation, pas une conséquence mécanique. Le temps que l’IA rend ne se transforme en tests robustes, en dépendances saines et en code durci que si quelqu’un décide explicitement de le dépenser là, et l’inscrit dans le contrat. Pour les équipes qui font ce choix, c’est la première fois depuis longtemps que bien faire ne coûte pas plus cher que faire vite.

Sur le même sujet : Les spécifications, pilier du développement avec l’IA · Object Calisthenics comme contrat machine · Sécuriser un pipeline GitHub Actions

Questions fréquentes

L’IA améliore-t-elle automatiquement la qualité du code ?

Non. L’IA réduit le coût de production du code, ce qui est différent. Le gain de temps n’améliore la qualité que si l’équipe décide de le réinvestir dans les tests, les dépendances et la sécurité ; sinon il part en production de fonctionnalités supplémentaires, et la dette s’accumule plus vite. Le rapport DORA 2024 de Google Cloud a même observé qu’une hausse de l’adoption de l’IA était associée à une baisse de la stabilité de livraison. La qualité reste une décision d’allocation explicite, pas un effet de bord automatique de l’outil.

Pourquoi la couverture de tests ne suffit-elle pas à mesurer la qualité d’une suite ?

La couverture mesure les lignes de code exécutées par les tests, pas les comportements réellement vérifiés. Un test peut exécuter une ligne sans formuler d’assertion utile à son sujet, ce qui gonfle la couverture sans rien protéger. C’est un risque amplifié par l’IA, qui génère facilement des suites à forte couverture mais à faible valeur. La métrique pertinente est le mutation score : on introduit des bugs artificiels dans le code et on mesure combien la suite en détecte. Un outil comme Stryker Mutator révèle l’écart, souvent large, entre couverture affichée et protection réelle.

Comment gérer les dépendances générées ou ajoutées par un agent IA ?

En traitant l’ajout de dépendance comme une décision soumise à contrôle, pas comme un détail d’implémentation. La majorité des vulnérabilités proviennent de dépendances transitives, jamais choisies explicitement. Concrètement : un outil d’analyse comportementale comme Socket évalue un paquet avant son adoption, Dependabot ou Renovate automatisent les montées de version, et une suite de tests robuste valide la non-régression à chaque patch. Le budget de temps libéré par l’IA est ce qui rend ce travail, longtemps repoussé, enfin tenable au quotidien.

Le Spec-Driven Development renforce-t-il vraiment la sécurité ?

Oui, en déplaçant les contraintes de sécurité vers l’amont, là où elles ne dépendent plus de la discipline de fin de sprint. Une spécification encode les invariants de sécurité (validation des entrées, gestion des secrets, contrôles d’accès) comme des critères d’acceptation que l’agent consulte avant de générer le code. La sécurité cesse d’être une revue facultative pour devenir une condition du « terminé ». Couplée à des barrières bloquantes dans le pipeline CI/CD, cette approche transforme la sécurité d’un rapport qu’on ignore en une contrainte qui casse le build tant qu’elle n’est pas respectée.