La grande stagnation du logiciel : pourquoi les applications semblent plus défectueuses chaque année

Vous déverrouillez votre téléphone pour vérifier un vol, mais l’application se bloque sur un écran blanc. Vous cliquez sur « Acheter maintenant » sur un site Web et le bouton devient gris, mais rien ne se passe. Vous essayez de coupler votre ampoule intelligente et cela nécessite une mise à jour du micrologiciel qui échoue trois fois.

Si vous avez l’impression que la technologie devient plus fragile, vous n’imaginez rien.

Au cours de la dernière décennie, l’industrie technologique a fonctionné selon le mantra « Agir vite et casser les choses ». Des analystes indépendants évaluent désormais le coût des objets cassés. Alors que le matériel est devenu exponentiellement plus rapide et plus fiable (un téléphone phare moderne est un miracle de la physique), le logiciel qui l’exécute semble de plus en plus lié par du ruban adhésif et des prières.

Il ne s’agit pas seulement de la nostalgie d’un « âge d’or » qui n’a jamais existé. Il s’agit d’une tendance statistique mesurable. De nouvelles données provenant de grandes sociétés d’analyse de code révèlent une tendance inquiétante : à mesure que le processus de codage devient plus automatisé, l’intégrité structurelle des systèmes se dégrade. Le marché construit des gratte-ciel numériques sur des fondations de sable, et les fissures commencent à apparaître.

L’entropie de la vitesse

Le problème fondamental est un changement dans l’économie de la fourniture de logiciels. Il y a vingt ans, expédier un logiciel était un acte physique. Vous avez pressé un “Gold Master” sur un CD-ROM ou un DVD, vous l’avez mis dans une boîte et vous l’avez transporté par camion jusqu’à un magasin. Si ce disque présentait un bug critique, les coûts de rappel étaient astronomiques. L’assurance qualité (AQ) n’était pas un luxe ; c’était une nécessité existentielle pour l’entreprise.

Aujourd’hui, les frictions de livraison sont nulles. Grâce aux mises à jour Over-The-Air (OTA) et aux pipelines d’intégration continue/déploiement continu (CI/CD), un développeur peut transmettre du code à des millions d’utilisateurs en quelques minutes. Cela a effectivement transféré le risque du fournisseur à l’utilisateur.

Pourquoi payer pour une équipe d’assurance qualité dédiée alors que vous pouvez traiter votre premier million d’utilisateurs comme des bêta-testeurs ?

Cette philosophie, souvent appelée « Shift Left » dans les cercles DevOps (ce qui implique que les tests devraient être effectués plus tôt par les développeurs), a paradoxalement conduit à des situations dans lesquelles personne ne teste réellement au « niveau utilisateur ». Les développeurs testent leurs fonctions spécifiques (tests unitaires), mais les interactions complexes entre des milliers de microservices, la couche « intégration », sont laissées au hasard.

Mais depuis trois ans, un nouvel accélérateur est venu attiser cet incendie : l’Intelligence Artificielle.

Le paradoxe de la qualité du code IA

La promesse des assistants de codage IA comme GitHub Copilot, Cursor et les propres outils de Google était une révolution en matière de productivité. L’adoption est désormais quasi universelle : l’enquête 2025 auprès des développeurs de Stack Overflow a révélé que plus de 84 % des développeurs utilisent ou prévoient d’utiliser des outils d’IA. Pourtant, la confiance dans ces mêmes outils est tombée à seulement 29 %, soit une baisse de 11 points en une seule année.

Cet écart existe parce que l’écriture de code n’a jamais été le goulot d’étranglement. Lire et maintenir c’était le cas.

Le rapport « Maintainability Gap » 2026 de GitClear, construit sur 623 millions de modifications de code analysées entre 2023 et 2026, donne des chiffres précis sur la dégradation. Les blocs de code dupliqués – mesurés par million de lignes modifiées – sont passés de 40,3 en 2023 à 73,0 jusqu’à présent en 2026, soit une augmentation de 81 % et le niveau le plus élevé jamais enregistré. Le code copié/collé est passé de 9,4 % des modifications en 2022 à 15,7 % au premier semestre 2026. Pendant ce temps, la part du code déplacé – la signature du refactoring, l’entretien qui maintient la cohérence des systèmes – s’est établie à 21 % des lignes modifiées en 2022, a chuté à 13 % en 2023 et est tombée en chute libre à seulement 3,8 % en 2026 jusqu’à présent. Les développeurs sont désormais environ cinq fois plus susceptibles de dupliquer du code que de le refactoriser.

L’effet “Shotgun Coding”

Les modèles d’IA sont des moteurs probabilistes. Ils prédisent le prochain jeton le plus probable. Lorsqu’un développeur demande à une IA « d’écrire une fonction pour analyser cette date », l’IA génère une toute nouvelle fonction sur mesure. Il ne sait pas qu’un analyseur de dates parfaitement performant existe déjà dans la bibliothèque partagée de l’entreprise, trois dossiers plus haut.

Le résultat est une base de code remplie de milliers d’implémentations en double et légèrement différentes de la même logique. Cela enfreint le principe « DRY » (Don’t Repeat Yourself), l’une des lois sacrées du génie logiciel. Lorsqu’un bug est détecté dans l’analyse des dates, vous le corrigez en un seul endroit, mais les 50 autres versions générées par l’IA restent défectueuses.

L’industrie est témoin d’une inflation massive de la taille de la base de code sans augmentation correspondante des fonctionnalités. Une application simple qui contenait auparavant 10 000 lignes de code en compte désormais 50 000, non pas parce qu’elle en fait plus, mais parce qu’elle est surchargée de passe-partout générés par l’IA.

L’illusion de l’exactitude

Le deuxième problème est la « fragilité » du code synthétique. Les systèmes génératifs sont excellents en syntaxe (la grammaire du code) mais ont du mal avec la sémantique (la signification du code). Ils produisent du code qui semble parfait ; il compile et s’exécute, mais il ne parvient souvent pas à gérer les cas extrêmes ou les états d’erreur rares.

Un développeur humain qui écrit un système de traitement des paiements se demande : « Que se passe-t-il si le réseau tombe juste après le débit de la carte mais avant l’enregistrement de la commande ? » Ils écrivent du code pour gérer cet état transactionnel. Une IA, à moins d’y être explicitement invitée, adopte souvent par défaut le “Happy Path”. Cela suppose que tout fonctionne.

Cela conduit à des « Heisenbugs », des bogues qui disparaissent ou se modifient lorsque vous essayez de les étudier, souvent causés par des conditions de concurrence et des états non gérés qui n’apparaissent que sous charge.

Il semble même que le gain de productivité lui-même soit en partie une illusion. Une étude randomisée réalisée en 2025 par le groupe de recherche METR a révélé que les développeurs expérimentés travaillant dans leurs propres bases de code pensaient que l’IA les rendait plus rapides – alors que le résultat mesuré était qu’ils étaient environ 19 % plus lents sur ces tâches. Les outils semblent rapides car ils produisent du texte rapidement ; la facture de débogage arrive plus tard.

La spirale de la mort des microservices

Parallèlement au boom de l’IA, il y a le changement architectural vers les microservices. Au lieu d’une seule grande application (un « monolithe »), les applications modernes sont composées de centaines de petits services indépendants qui communiquent entre eux sur un réseau.

Sur le papier, c’est génial. Cela permet aux équipes de travailler de manière indépendante. En pratique, cela transforme chaque appel de fonction en une requête réseau qui peut échouer.

Dans une application monolithique, la fonction A appelle la fonction B. Cela fonctionne 100 % du temps car elles se trouvent dans le même espace mémoire. Dans une application de microservices, le service A envoie un paquet JSON au service B.

• Le réseau est peut-être lent.
• Le service B est peut-être en train de redémarrer.
• Le format JSON a peut-être légèrement changé.

La complexité de ces interactions croît de façon exponentielle et non linéaire. Si vous disposez de 10 services, vous disposez de 45 paires de connexion possibles. Si vous avez 100 services, vous en avez 4 950. De nombreuses applications d’entreprise modernes en possèdent des milliers.

Les ingénieurs ont construit des systèmes qui échappent à la compréhension cognitive d’un seul être humain. Personne ne sait plus comment tout cela fonctionne. Lorsque quelque chose tombe en panne, le débogage n’est pas un processus de déduction logique ; c’est une fouille archéologique à travers des journaux distribués.

La régression de l’expérience utilisateur

Comment cela se manifeste-t-il pour vous, l’utilisateur ?

1. La roue qui tourne : à mesure que les applications s’appuient davantage sur la récupération de données en temps réel pour chaque interaction, l’interface utilisateur devient dépendante de la stabilité du réseau.
2. **L’erreur générique « Quelque chose ne s’est pas passé » ** : étant donné que la gestion des erreurs est complexe dans les systèmes distribués, les applications affichent souvent par défaut un message d’erreur générique « fourre-tout » qui ne vous dit rien.
3. Feature Rot : les fonctionnalités qui fonctionnaient auparavant s’arrêtent soudainement ou fonctionnent de manière irrégulière, car une dépendance de trois couches de profondeur a été mise à jour et personne n’a vérifié la compatibilité.

L’écosystème entre dans l’ère du « Logiciel Probabiliste ». Cela fonctionne probablement. Le plus souvent.

La solution : la fiabilité comme fonctionnalité

Le pendule commence à revenir en arrière. Dans le monde B2B, les entreprises se rendent compte que le « 5 neuf » (disponibilité de 99,999 %) constitue un avantage concurrentiel qui vaut la peine d’être payé.

Le marché voit émerger des équipes de « Platform Engineering », groupes spécialisés dont le seul métier est d’apprivoiser cette complexité. Ils construisent des plates-formes de développement internes qui imposent la standardisation, obligeant essentiellement les assistants IA à utiliser les bibliothèques approuvées plutôt que d’en halluciner de nouvelles.

Par ailleurs, une nouvelle génération d’outils « Agentic QA » fait son apparition. Si l’IA est le problème, elle pourrait aussi être la solution. Les nouveaux agents de test autonomes peuvent naviguer dans les applications comme un utilisateur humain, cliquer sur des boutons, remplir des formulaires et signaler des bogues 24h/24 et 7j/7. Contrairement aux tests automatisés fragiles du passé, ces agents « voient » l’écran et peuvent identifier lorsqu’un bouton est cassé, même si le code indique qu’il devrait fonctionner.

Le verdict

Les logiciels semblent plus bogués parce que l’industrie a donné la priorité à la vitesse plutôt qu’à la stabilité pendant quinze ans. Les entreprises technologiques ont donné à chaque développeur un moteur Ferrari (AI) mais ont supprimé les freins (QA). Les équipes de développement s’écrasent actuellement sur les garde-corps.

Les prochaines grandes entreprises technologiques ne seront pas celles qui proposeront le plus de fonctionnalités. Ce seront eux dont le logiciel fonctionne simplement et silencieusement. Dans un monde de chaos numérique, la fiabilité est le luxe ultime.

En attendant, vous souhaiterez peut-être continuer à actualiser cette page. Cela pourrait fonctionner la deuxième fois. Probablement.