Les deux vitesses : pourquoi coder plus vite ne suffit pas

L'IA promet de produire du logiciel plus vite. Beaucoup plus vite.

Elle peut générer une fonction, expliquer une erreur, corriger un test, écrire une documentation, proposer une pull request, refactorer un composant ou créer une première version d'application en quelques minutes. Pour les équipes produit et tech, la promesse est évidente : réduire les délais, augmenter le volume, livrer plus souvent.

Mais une question devient de plus en plus importante : que se passe-t-il quand la vitesse de production dépasse la vitesse de validation ?

Car le logiciel n'est pas seulement du code écrit. C'est du code compris, testé, relu, intégré, déployé, observé, maintenu et corrigé. Et cette chaîne-là n'accélère pas automatiquement parce qu'un modèle sait générer 200 lignes en dix secondes.

L'IA peut aller vite. La qualité, elle, demande encore du temps.

Produire du code n'a jamais été le vrai problème

Dans beaucoup d'équipes, le goulot d'étranglement n'est pas l'écriture brute du code. C'est tout ce qu'il y a autour.

Comprendre le besoin. Identifier les impacts. Choisir la bonne architecture. Vérifier les cas limites. Écrire les tests. Relire une pull request. Déployer sans casser. Surveiller la production. Corriger les effets secondaires. Maintenir le système six mois plus tard.

L'IA accélère surtout la partie visible : la génération.

Mais si elle produit plus de code que l'équipe ne peut en relire, en tester ou en comprendre, elle ne réduit pas forcément le risque. Elle le déplace.

C'est le paradoxe actuel : nous gagnons en vitesse d'écriture, mais pas toujours en vitesse d'assurance qualité.

Et dans un logiciel réel, la qualité ne se mesure pas au nombre de lignes produites. Elle se mesure à la capacité du système à fonctionner correctement, longtemps, dans un environnement qui change.

Les projets informatiques échouaient déjà très bien sans IA

Il faut commencer par une vérité inconfortable : les projets informatiques n'avaient pas besoin de l'IA pour mal tourner.

Les grandes études sur les projets IT montrent depuis des années des taux d'échec, de retard et de dépassement de budget très élevés. Une analyse McKinsey-Oxford portant sur plus de 5 400 grands projets IT a montré qu'ils dépassaient en moyenne leur budget de 45 %, prenaient 7 % de temps en plus et livraient 56 % de valeur en moins que prévu. Pour les grands projets logiciels, les chiffres étaient encore plus sévères : environ 66 % de dépassement de budget et 33 % de retard.

Plus inquiétant : 17 % des grands projets IT étudiés allaient si mal qu'ils pouvaient menacer l'existence même de l'entreprise.

C'est important, parce que l'IA arrive dans un secteur où la difficulté n'a jamais été seulement de coder. Les problèmes historiques sont ailleurs : objectifs flous, dette technique, mauvaise coordination, dépendances cachées, sous-estimation de la complexité, gouvernance faible, validation insuffisante.

Autrement dit, l'IA n'entre pas dans une usine parfaitement optimisée.

La mauvaise qualité logicielle coûte déjà très cher

La qualité logicielle a aussi un coût macroéconomique massif.

Le CISQ a estimé que la mauvaise qualité logicielle coûtait 2,41 billions de dollars aux États-Unis en 2022. Ce chiffre inclut notamment les défaillances opérationnelles, les projets échoués, les failles de sécurité, les systèmes hérités difficiles à maintenir et la dette technique.

Ce coût est souvent invisible jusqu'au moment où il devient brutal. Une erreur de logique, une dépendance vulnérable, un mauvais contrôle d'accès ou un patch mal testé peuvent rester silencieux pendant des mois, puis apparaître en production sous la forme d'un incident, d'une fuite de données ou d'un arrêt de service.

L'IA peut réduire certains coûts. Mais elle peut aussi en créer de nouveaux si elle augmente le volume de code sans augmenter la qualité des garde-fous.

Les chiffres sur le code généré par IA invitent à la prudence

Les données récentes ne disent pas que l'IA est inutile. Elles disent quelque chose de plus intéressant : l'IA est utile, mais pas gratuitement.

Veracode a analysé du code généré par plus de 100 modèles sur 80 tâches de programmation. Résultat : seulement 55 % du code généré était considéré comme sécurisé. Cela signifie que près de 45 % introduisait des failles connues dans les scénarios testés.

CodeRabbit a comparé des pull requests humaines et des pull requests générées par IA. Sur 470 pull requests, les changements générés par IA contenaient en moyenne 10,83 problèmes par PR, contre 6,45 pour les PR humaines. Cela représente environ 1,7 fois plus de problèmes.

Apiiro a observé un autre signal préoccupant : dans les dépôts étudiés, le code généré par IA introduisait plus de 10 000 nouveaux résultats de sécurité par mois en juin 2025, soit une hausse de 10 fois en six mois.

Ces chiffres ne prouvent pas que l'IA écrit toujours du mauvais code. Ils montrent que la vitesse de génération peut multiplier les défauts si elle n'est pas accompagnée par de meilleurs contrôles.

Le problème n'est pas « l'IA fait des erreurs ». Les humains aussi. Le problème est que l'IA peut faire des erreurs à grande vitesse, avec beaucoup d'assurance, dans un format qui ressemble à du code prêt pour la production.

Le gain de productivité n'est pas automatique

On pourrait penser que même avec quelques erreurs, l'IA reste rentable parce qu'elle accélère massivement les développeurs. Là aussi, la réalité est moins simple.

Une étude contrôlée de METR, publiée en 2025, a observé 16 développeurs expérimentés travaillant sur 246 tâches dans des projets open source qu'ils connaissaient bien. Les développeurs pensaient que l'IA les ferait gagner environ 24 % de temps. Après coup, ils estimaient encore avoir gagné 20 %.

Mais les mesures réelles montraient l'inverse : avec les outils IA, ils mettaient en moyenne 19 % de temps en plus.

Pourquoi ? Parce que le temps gagné en écriture était absorbé par le temps passé à relire, corriger, guider l'outil, attendre les générations et nettoyer les propositions.

Ce résultat ne signifie pas que l'IA ralentit toujours tout le monde. Elle peut être très utile pour des tâches simples, des prototypes, des développeurs moins familiers d'un codebase ou des travaux répétitifs. Mais il rappelle une chose essentielle : dans un système logiciel complexe, produire une solution plausible ne suffit pas. Il faut vérifier qu'elle est correcte.

Et la vérification reste chère.

La fréquence des mises à jour augmente

En parallèle, les logiciels modernes sont mis à jour de plus en plus souvent.

Les meilleures équipes DevOps déploient à la demande, parfois plusieurs fois par jour. DORA montre depuis des années que les équipes les plus performantes combinent vitesse et stabilité : elles déploient fréquemment, récupèrent vite après incident et gardent des changements petits.

Même les grands logiciels grand public accélèrent leurs cycles. Chrome, par exemple, est passé au fil des années de cycles plus longs à des cycles plus courts, et Google a annoncé un passage vers une version stable toutes les deux semaines à partir de Chrome 153. Microsoft, de son côté, conserve un rythme mensuel structuré pour les mises à jour de sécurité Windows, avec des mises à jour publiées le deuxième mardi de chaque mois, et des correctifs hors cycle lorsque des problèmes critiques apparaissent.

Cette accélération a une logique saine. Des mises à jour plus petites et plus fréquentes peuvent réduire le risque : moins de changements à la fois, feedback plus rapide, corrections plus rapides, utilisateurs protégés plus tôt.

Mais cette logique ne fonctionne que si les fondations suivent : automatisation, tests fiables, observabilité, feature flags, rollback, revue sérieuse, sécurité intégrée.

Sans ces fondations, plus de déploiements signifie simplement plus d'occasions de casser quelque chose.

Le vrai danger : confondre vitesse et maturité

La vitesse n'est pas un problème en soi.

Une équipe mature qui déploie dix fois par jour avec des tests solides, des petits changements, une bonne observabilité et une capacité de rollback rapide peut être plus fiable qu'une équipe qui déploie une fois par trimestre dans la panique.

Le problème apparaît quand l'IA pousse une équipe à produire plus vite sans améliorer sa capacité à valider.

Plus de code généré signifie plus de pull requests. Plus de pull requests signifie plus de revue. Plus de revue signifie plus de charge cognitive. Plus de changements signifie plus d'interactions entre composants. Plus d'interactions signifie plus de bugs subtils.

Si les équipes ne changent pas leurs pratiques, l'IA peut transformer une dette technique lente en dette technique rapide.

Avant, on écrivait laborieusement du mauvais code. Maintenant, on peut le générer en masse. Le problème se trouve au niveau du débit.

L'IA amplifie l'organisation existante

Les rapports DORA récents sont particulièrement intéressants sur ce point. En 2024, l'adoption de l'IA était associée à une baisse estimée du throughput logiciel et surtout à une baisse de stabilité. En 2025, le lien avec le throughput devient plus positif : les équipes semblent apprendre à intégrer l'IA dans leurs workflows. Mais DORA continue d'observer une relation négative avec la stabilité.

Cette nuance est importante.

L'IA n'est pas seulement un outil individuel. C'est un amplificateur organisationnel.

Dans une équipe avec de bons tests, une CI rapide, des revues solides, des pratiques de sécurité et une architecture compréhensible, elle peut accélérer des tâches utiles.

Dans une équipe désorganisée, avec peu de tests, des déploiements fragiles et une dette technique mal connue, elle peut produire plus vite des problèmes que l'équipe ne sait déjà pas absorber.

L'IA ne remplace pas les fondamentaux. Elle les rend plus visibles.

Ce que les équipes doivent mesurer

Si les entreprises veulent utiliser l'IA sérieusement dans le développement logiciel, elles doivent arrêter de mesurer seulement le volume.

Le nombre de lignes générées n'est pas une métrique de valeur. Le nombre de tickets fermés non plus, si les tickets reviennent sous forme de bugs. Le nombre de pull requests peut même devenir un indicateur de bruit.

Les bonnes questions sont plus exigeantes :

• Combien de bugs arrivent en production après du code assisté par IA ?
• Combien de temps les revues prennent-elles ?
• Quel est le taux de rollback ?
• Quel est le change failure rate ?
• Combien de vulnérabilités sont introduites ?
• Combien de code généré est supprimé ou réécrit dans les semaines suivantes ?
• Combien de temps est réellement gagné entre l'idée et une fonctionnalité stable en production ?

Il faut mesurer le cycle complet : génération, revue, test, déploiement, incident, maintenance.

Sinon, on ne mesure que l'accélérateur, jamais les freins.

Ce que cela change pour la qualité informatique

La qualité informatique doit évoluer avec l'IA.

D'abord, les tests doivent devenir plus importants, pas moins. Plus l'IA génère vite, plus les tests automatisés capables de filtrer rapidement les erreurs prendront de l'importance.

Ensuite, la revue de code doit changer. Relire du code généré par IA demande une attention particulière : logique métier, sécurité, cas limites, dépendances, duplication, maintenabilité. Le code peut être bien formaté et pourtant faux.

La sécurité doit aussi être intégrée plus tôt. Si les failles sont détectées seulement en fin de chaîne, l'IA aura déjà multiplié les changements à corriger. Les outils de SAST, SCA, secret scanning, analyse de dépendances et policy-as-code deviennent encore plus importants.

Enfin, les équipes doivent réduire la taille des changements. L'IA donne envie de demander de grosses modifications d'un coup. C'est souvent une erreur. Les petits changements restent plus faciles à relire, tester, déployer et annuler.

La bonne stratégie n'est pas de ralentir l'IA. C'est de découper son travail pour que la qualité puisse suivre.

Et pour le futur ?

L'avenir du développement logiciel ne sera pas simplement « plus de code, plus vite ».

Ce sera une compétition entre deux vitesses.

D'un côté, la vitesse de génération des modèles, agents, copilotes, frameworks, prompts, automatisation.

De l'autre, la vitesse de validation par les tests, la sécurité, l'observabilité, l'architecture ou la compréhension métier.

Si la génération accélère seule, les entreprises produiront plus de dette, plus de bugs et plus de risques. Si la validation accélère aussi, l'IA pourra réellement améliorer la livraison logicielle.

Le problème n'est donc pas de savoir à quelle vitesse l'IA peut écrire du code, mais à quelle vitesse nous pouvons le relire et le corriger.