Entre métriques trompeuses, code défaillant et rapports truffés d'hallucinations, les professionnels de l'IA commencent à décrire l'écart béant entre la promesse de la technologie et son déploiement réel. Un secteur entier, de la grande consultation aux équipes d'ingénierie, s'apprête à affronter une facture que personne ne veut encore regarder en face.Dorian Smiley et Connor Deeks sont co-fondateurs de Codestrap, une société de conseil spécialisée en stratégie d'intelligence artificielle. Tous deux ont fait leurs armes chez PwC, l'un des quatre grands cabinets d'audit mondiaux. Leur verdict, formulé dans une interview accordée à The Register en mars 2026, est sans appel : personne ne sait vraiment comment intégrer l'IA dans son organisation. « Personne ne connaît les bonnes architectures de référence ou les bons cas d'usage pour son institution », reconnaît Smiley. « Beaucoup font semblant de le savoir. Mais il n'existe pas de guide à suivre. »
Cette absence de méthode n'est pas anodine. Elle traduit une réalité que le secteur peine à formuler : l'enthousiasme affiché par les directions est souvent de la mise en scène, une réponse à la pression des marchés financiers et des conseils d'administration, davantage qu'une transformation réelle des processus métier. Selon Deeks, si on construisait un système d'IA en repartant de zéro, il ressemblerait bien peu à ce qui est proposé aujourd'hui. Tout le discours sur la disparition des métiers d'ingénierie ou du travail de bureau, dit-il, « nous n'y souscrivons pas ».
Ce constat rejoint les données du terrain. D'après une étude de Lucidworks portant sur plus de 1 600 responsables IA et 1 100 entreprises, plus de sept organisations sur dix ont introduit l'IA générative dans leurs opérations. Pourtant, seulement 6 % ont pleinement déployé l'IA agentique, qui représente la prochaine étape de l'automatisation intelligente. L'adoption de surface est massive ; la transformation profonde, rarissime.
Des métriques qui mesurent tout sauf ce qui compte
Le problème fondamental que soulèvent Smiley et Deeks tient à la manière dont les organisations évaluent le succès de leurs déploiements d'IA. Dans le domaine du développement logiciel, les entreprises se félicitent d'une augmentation du nombre de lignes de code produites ou du volume de demandes de fusion (pull requests) traitées. Ce sont précisément les mauvaises métriques.
« Le code peut sembler correct, passer tous les tests unitaires, et être néanmoins défaillant », explique Smiley. « La façon de mesurer cela passe par des tests de performance. Beaucoup d'entreprises n'ont pas encore mis en place la boucle de retour nécessaire pour évaluer l'impact réel de la programmation assistée par IA sur les résultats qui leur importent. Les lignes de code, le nombre de demandes de fusion : ce sont des passifs, pas des indicateurs d'excellence technique. »
Les véritables métriques du génie logiciel sont d'un autre ordre : fréquence de déploiement en production, délai entre la conception et la mise en service, taux d'échec des modifications, temps moyen de rétablissement après incident. Smiley insiste : il nous faut un nouvel ensemble d'indicateurs pour mesurer l'impact de l'IA sur la performance des équipes d'ingénierie. « Nous ne savons pas encore quels sont ces indicateurs. »
Les chiffres disponibles renforcent son inquiétude. Selon une analyse de 2026 portant sur des systèmes en production, le code généré par IA introduit 1,7 fois plus de problèmes que le code écrit par des humains. Les erreurs de maintenabilité sont 1,64 fois plus fréquentes, les erreurs logiques 1,75 fois plus répandues, et les failles de sécurité augmentent d'un facteur 1,57 dans les bases de code où l'IA est fortement sollicitée. Le sentiment positif à l'égard des outils de programmation assistée par IA est d'ailleurs passé sous la barre des 60 % en 2025, contre plus de 70 % les années précédentes.
SQLite réécrit en Rust : un cas d'école dévastateur
Pour illustrer concrètement les dérives de cette mécanique, Smiley cite l'exemple d'une tentative de réécriture de SQLite en langage Rust, entièrement pilotée par une IA. Le résultat ? Un code 3,7 fois plus volumineux que l'original, affichant des performances 2 000 fois inférieures. « Pour une base de données, des performances 2 000 fois inférieures, c'est un produit non viable. On jette tout ça à la poubelle. Tout l'argent investi ne vaut rien. »
Ce cas illustre l'un des angles morts les plus préoccupants de l'IA appliquée à l'ingénierie logicielle : les modèles de langage n'ont pas la capacité d'évaluer eux-mêmes la qualité de leur production. « Un modèle ne peut pas relire son propre travail. Il ne sait pas si la réponse qu'il vous a donnée est juste. Ce sont des problèmes fondamentaux que personne n'a résolus dans la technologie des grands modèles de langage (LLM). Et vous voulez me dire que ça ne va pas se manifester dans des problèmes de qualité du code ? Bien sûr que ça va se manifester. »
À cela s'ajoute la non-déterminisme des modèles de raisonnement : la passe en avant à travers les réseaux de neurones produit des résultats différents à chaque exécution, en particulier pour les modèles qui mobilisent un monologue interne pour augmenter l'efficacité de la prédiction du prochain token. Autrement dit, demander deux fois la même chose à un modèle de raisonnement peut donner deux réponses différentes — sans que le système en soit conscient.
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
Envoyé par Mathis Lucas
à tous,