Huit fois plus de code, huit fois plus de bogues ?

La question semble innocente. Avec l'IA, on produit beaucoup plus de code, beaucoup plus vite. Si le volume explose, n'est-il pas normal que le nombre de bogues suive ? Après tout, plus on écrit, plus on se trompe.

C'est une logique tentante. Et c'est exactement la mauvaise.

Le piège du raisonnement proportionnel

Le raisonnement « 8x plus de code = 8x plus de bogues, donc c'est acceptable » repose sur une confusion : il traite la qualité comme une fonction du volume produit, alors qu'elle est une propriété de ce qu'on livre.

Un client, un utilisateur, un enseignant qui se sert de votre logiciel ne sait pas — et ne veut pas savoir — combien de lignes vous avez écrites pour arriver là. Il vit avec le résultat. Si votre produit plante deux fois plus souvent qu'avant, le fait que vous ayez « produit 8 fois plus » n'est pas une excuse, c'est un aveu.

La densité de défauts (bogues par millier de lignes, ou mieux : par fonctionnalité livrée) est le vrai indicateur. Et cette densité ne devrait pas augmenter avec le volume. Elle devrait baisser.

Pourquoi l'IA devrait réduire le taux de défauts, pas l'augmenter

Si l'IA fait une partie du travail, c'est précisément le travail qu'un humain faisait avec un taux d'erreur connu. L'argument inverse — « l'IA écrit, donc c'est bon par défaut » — est aussi faux que le premier, mais il pointe vers la bonne intuition.

L'IA change le coût marginal de plusieurs activités qui, historiquement, étaient les premières sacrifiées sous pression :

Les tests. Écrire une suite de tests complète coûtait cher en temps humain. Ce coût s'effondre. Il n'y a plus d'excuse pour livrer du code peu couvert.
La revue. Une deuxième paire d'yeux sur chaque changement était un luxe. Maintenant c'est instantané et systématique.
La documentation et la lisibilité. Refactoriser pour la clarté ne consomme plus une demi-journée.

Autrement dit : l'IA ne nous donne pas seulement plus de vitesse à produire des bogues. Elle nous donne, au même prix, les outils qui historiquement attrapaient les bogues. Si on n'utilise que la première moitié de l'équation, c'est un choix, pas une fatalité.

La vraie position : 8x plus de code, moitié moins de bogues

Voici la barre qu'on devrait se fixer. Pas « tolérer 2x plus de bogues parce qu'on livre 8x plus ». Plutôt : livrer 8x plus et réduire le nombre absolu de défauts.

Ça paraît absurde uniquement si on croit que la qualité est un sous-produit accidentel de l'écriture. Ce n'est pas le cas. La qualité est le produit du filtre qu'on applique. Et l'IA améliore le filtre autant qu'elle accélère la production — à condition qu'on l'instrumente pour ça.

Le danger réel n'est pas technique, il est psychologique : la tentation de prendre tout le gain de vitesse en fonctionnalités et zéro en vérification. C'est le chemin qui mène à une dette technique générée 8x plus vite qu'avant.

Ce que ça change en pratique

Si vous dirigez une équipe ou un produit, la question à poser n'est pas « combien de bogues peut-on se permettre ? ». C'est :

Notre densité de défauts baisse-t-elle, livraison après livraison ? Si elle monte, le volume est en train de nous échapper.
Le gain de vitesse de l'IA est-il réinvesti dans la vérification, ou entièrement dépensé en sortie ? Le bon ratio n'est pas 100/0.
Mesure-t-on les bogues en production, ou seulement ceux qu'on attrape ? Le seul chiffre qui compte est celui que le client voit.

Conclusion

Non, on ne peut pas se permettre 8x plus de bogues parce qu'on livre 8x plus de code. Et non, on ne peut pas non plus présumer que l'IA rend le code bon par défaut.

La bonne posture est exigeante et cohérente : l'IA doit faire monter la qualité, pas seulement le volume. Si on livre 8 fois plus avec 2 fois moins de bogues, on a compris l'outil. Si on livre 8 fois plus avec 2 fois plus de bogues, on a simplement automatisé notre dette.

La qualité n'a jamais été une variable d'ajustement du volume. L'IA ne change pas cette règle — elle la rend juste impossible à ignorer.