Discussion :

[Stéphane le calme]

L'IA en entreprise court à la catastrophe : code défaillant, hallucinations facturées au prix fort.
Comment les entreprises mesurent tout sauf ce qui compte vraiment

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 grande consultation face à ses propres hallucinations

Si ces problèmes concernent en premier lieu les équipes techniques, les firmes de conseil ne sont pas épargnées. L'affaire Deloitte Australie, révélée à l'été 2025, reste à ce jour l'exemple le plus documenté de l'échec à grande échelle de la supervision humaine dans les processus de production assistée par IA.

Deloitte Australie a partiellement remboursé les 440 000 dollars australiens versés par le gouvernement pour un rapport de 237 pages truffé d'erreurs : une citation fabriquée à partir d'un jugement d'un tribunal fédéral, des références à des articles de recherche universitaires inexistants. C'est le chercheur australien Chris Rudge, de l'Université de Sydney, qui a donné l'alerte, relevant une vingtaine d'anomalies et soupçonnant les hallucinations typiques d'un modèle de langage. L'enquête interne a confirmé que le cabinet avait utilisé Azure OpenAI GPT-4o pour rédiger ce document d'audit censé évaluer la conformité juridique du système informatique automatisant les sanctions du régime d'aide sociale.

L'ironie de la situation n'a échappé à personne : le même jour où il était contraint au remboursement partiel, Deloitte signait un partenariat avec Anthropic pour déployer le modèle Claude auprès de l'ensemble de ses 450 000 employés dans le monde. Un pied dans le scandale, l'autre dans le prochain contrat IA.

Deeks, chez Codestrap, voit dans cet épisode le signe d'une tendance systémique. « Les grands cabinets de conseil adoptent désormais l'IA à grande échelle pour rédiger leurs présentations et leurs analyses. Ça va se traduire par des procès retentissants et des pertes financières importantes, parce que la qualité n'est tout simplement pas surveillée. Tout le monde a cru à la fable que c'était déjà parfait. »

Des incitations structurellement incompatibles avec la qualité

Pourquoi les organisations ne corrigent-elles pas d'elles-mêmes ces dérives ? La réponse de Smiley tient à l'alignement des incitations à l'intérieur des grandes structures professionnelles. Dans les grands cabinets comme PwC, l'associé veut davantage de chiffre d'affaires et de marges plus élevées. Donner accès à l'IA sans imposer une relecture systématique des sorties n'est pas une décision irrationnelle : c'est la rationalité économique qui l'emporte sur la rigueur. Le directeur cessera de consulter les analystes pour confier leur travail à l'IA. L'analyste, lui, cherchera à boucler la tâche plus vite pour s'accorder du temps libre. « Ces incitations ne s'alignent pas d'une façon qui rende l'IA complémentaire à l'activité et génératrice de valeur. »

Cette tension entre incitations économiques et exigences de qualité se retrouve dans les données sectorielles. En 2025, les entreprises mondiales ont investi 684 milliards de dollars dans des initiatives d'IA. À la fin de l'année, plus de 547 milliards, soit plus de 80 % de cette somme, n'avaient pas produit la valeur escomptée. Parmi les obstacles à l'adoption identifiés dans une vaste enquête sectorielle, 73 % des projets échouent faute d'indicateurs de performance clairs, et 68 % souffrent d'un sous-investissement dans les fondations techniques.

L'assurance : le signal d'alarme que personne n'entend

L'un des points les plus significatifs de l'analyse de Codestrap concerne un acteur rarement évoqué dans les débats sur l'IA : les compagnies d'assurance. Des souscripteurs de grands assureurs cherchent activement à exclure de leurs polices les sinistres liés à des flux de travail faisant appel à l'IA, dès lors qu'il n'existe pas de chaîne de responsabilité clairement établie. Si les systèmes d'IA sont vraiment aussi efficaces qu'on le prétend, pourquoi les assureurs déploient-ils tant d'efforts pour refuser de couvrir les risques associés ? Ils sont généralement assez bons pour établir des profils de risque. »

Des lobbyistes sectoriels se déploieraient déjà auprès des régulateurs d'assurance au niveau des États américains pour obtenir des exemptions dans les polices de responsabilité commerciale. Si ces démarches aboutissent, les entreprises qui auront massivement déployé l'IA sans gouvernance sérieuse pourraient se retrouver exposées à des sinistres non couverts au moment même où les premières vagues de défaillances se matérialiseront.

L'échéance : dans huit à neuf mois

La temporalité n'est pas floue dans l'analyse de Codestrap. Smiley anticipe des « problèmes liés à la qualité du code qui feront surface dans huit à neuf mois pour les utilisateurs intensifs d'IA ». Deeks, lui, prévoit une multiplication des procédures judiciaires, parce que c'est ce qui arrive invariablement quand de mauvais conseils causent des dégâts.

À plus court terme, une autre pression s'exerce déjà : la déflation tarifaire. Les entreprises commencent à réclamer des remises aux prestataires de services dès lors qu'elles savent que ces derniers utilisent l'IA pour produire leurs livrables. KPMG aurait déjà subi cette pression de la part d'un autre cabinet comptable qui a exigé une baisse de tarif en arguant de l'usage d'outils d'IA.

Ce mouvement est logique et probablement irréversible : si l'IA compresse le temps de production, pourquoi le client paierait-il le même prix qu'auparavant ? La valeur perçue du travail intellectuel se trouve ainsi structurellement menacée, non par l'IA en tant que telle, mais par l'opacité dans laquelle elle est déployée.
La lucidité de Deeks sur ce point mérite d'être citée : ce qu'il réclame n'est pas un moratoire sur l'IA, mais une conversation honnête. « Peut-on réellement en parler ? Est-ce que quelqu'un va évoquer l'opposé de l'intelligence artificielle générale et de son avenir utopique ? » Une question que beaucoup évitent, parce que les capitalisations boursières, les stratégies de communication d'entreprise et les discours de conférences technologiques en dépendent.

L'IA n'est pas en train d'échouer parce qu'elle est mauvaise. Elle est en train d'échouer parce que les organisations la déploient sans métriques, sans supervision et sans chaîne de responsabilité et que les systèmes d'incitations en place les poussent à continuer.

Sources : Lucidworks, Second Talent, Pertama Partners, interview de Dorian Smiley et Connor Deeks, SQLite réécrit en Rust

Et vous ?

Les métriques traditionnelles du génie logiciel (nombre de lignes de code, volume de demandes de fusion) sont-elles structurellement incompatibles avec l'évaluation de la qualité du code généré par IA, ou peut-on les adapter ?

L'affaire Deloitte Australie constitue-t-elle un cas isolé ou le premier symptôme visible d'une épidémie silencieuse de livrables professionnels dégradés par des hallucinations non détectées ?

Si les assureurs refusent de couvrir les risques liés à l'IA, qui portera la responsabilité juridique et financière des défaillances à venir — les éditeurs de modèles, les intégrateurs ou les entreprises clientes ?

La pression tarifaire exercée par les clients qui savent que leurs prestataires utilisent l'IA va-t-elle accélérer une course vers le bas en matière de qualité, ou au contraire forcer le secteur à formaliser des standards de gouvernance ?

Dans quelle mesure le discours dominant sur l'IA, porté par des entreprises dont la valorisation boursière dépend de l'enthousiasme des marchés, constitue-t-il lui-même un obstacle à une évaluation sérieuse des risques ?

[JPLAROCHE]

Je ne peux que confirmer ce qui est écrit dans cet article:

J'utilise l'IA, mais combien de fois, je suis obligé de lui dire de se concentrer sur le sujet et la demande, parce que l'IA est très bavarde, bref beaucoup de temps perdu, pourquoi parce que tu es obligé de prendre en compte ce qu'il dit pour voir le résultat...
Puis, tu es enjoint de faire des coupes dans la solution, je dirais plutôt les solutions proposées, et comme il est écrit dans l'article, tu t'apercevras qu'il se peut que des solutions puissent ne pas répondre aux problèmes posés, encore du temps de perdue, mais surtout t'amener à casser du code. Résultat à vouloir trop bien faire ...

Alors pourquoi j'utilise l'IA, je le prends pour un livre que je consulte. Là est sa richesse, en exemple et en information, on peut lui dire en lui donnant les liens quand sa connaissance ne prend pas d'office la dernière mise à jour par exemple Neovim ou Rust, et l'on peut le voir réagir.

Souvent l'IA cherche à vous montrer qu'il sait et qu'il est capable de vous donner la solution, Là aussi la dérive peut être cinglante.
Dernière critique il m'est arrivé que l'IA ne puisse pas répondre et là, il plante la confusion devient flagrante. Jusqu'à présent une fois, mais trois jours de perdu.

Il y a aussi un truc qui ne me plaît pas, il mémorise certaine chose de votre discutions et parfois, c'est erroné et tu lui fais la remarque, mais il ne la prend pas en compte ???

Il y a eu aussi un truc bizarre un jour, j'ai dit que je n'étais pas comptant et alors, il m'a été posé par un questionnaire, je lui ai précisé pourquoi, l'attitude de l'IA a changé, c'en était drôle à croire qu'elle était fâchée...

Une chose est sûre, c'est que l'IA pour coder HUMMMM..... avec des pincettes, car codée demande des précisions à la virgule près et bien souvent fait appel à la prise en charge de module externe (même si vous fournissez lesdits modules)

ma conclusion l'IA reste une formidable bibliothèque riche avec des exemples, mais n'invente rien, plus facile qu'avec un livre (quoique je fasse partie de la vieille génération et rien pour le moment ne remplace le livre) , oui, mais j'aurai dû dire des livres et je peux passer du Rust à Zig et Lua ou Python et finir en C là, elle est imbattable.

[floyer]

Sur un exemple simple (page php avec accès base de données), l’IA m’a réussi à oublier de se connecter à la base de données, et me sortir une vulnérabilité SQL-injection. Il faut être attentif.

[calvaire]

Je ne peux que confirmer ce qui est écrit dans cet article:

J'utilise l'IA, mais combien de fois, je suis obligé de lui dire de se concentrer sur le sujet et la demande, parce que l'IA est très bavarde, bref beaucoup de temps perdu, pourquoi parce que tu es obligé de prendre en compte ce qu'il dit pour voir le résultat...
Puis, tu es enjoint de faire des coupes dans la solution, je dirais plutôt les solutions proposées, et comme il est écrit dans l'article, tu t'apercevras qu'il se peut que des solutions puissent ne pas répondre aux problèmes posés, encore du temps de perdue, mais surtout t'amener à casser du code. Résultat à vouloir trop bien faire ...

pour ce probleme, il y'a le schema-driven prompting que j'utilise au quotidien, et ca marche tres bien.
Tu envoies à l’IA :
un input structuré (JSON)
des instructions claires
un format de sortie imposé (JSON)
L’IA répond dans exactement ce format, sans texte inutile.

2 exemples, juste pour illustrer mon propos:

{
"task": "resume",
"text": "Le soleil est une étoile située au centre du système solaire...",
"constraints": {
"max_words": 10,
"language": "fr"
},
"output_format": {
"summary": "string"
}
}

en sortie:

{
"summary": "Le Soleil est l’étoile centrale du système solaire."
}

ou:

{
"task": "analyze_product",
"product": "iPhone 15",
"criteria": ["prix", "performance", "autonomie"],
"output_format": {
"score": "number",
"pros": ["string"],
"cons": ["string"]
}
}

en réponse j'ai:

{
"score": 8.5,
"pros": ["Très performant", "Bonne autonomie"],
"cons": ["Prix élevé"]
}

Pour le fun, tu peux connecter tes données de santés (historique médicale, résultat d'analyse, et ajouts des datas de ta montre connecté...) et elle pourrait tous les jours au réveil te donner le top 3 des maladies que tu risque d'avoir dans un avenir proche avec un score de confiance.

[maltyxx]

Cet article résonne avec ce qu'on observe concrètement sur le terrain. Le problème fondamental n'est pas l'IA elle-même, mais l'absence totale de cadre d'évaluation adapté à la nature probabiliste de ces systèmes.

Dans nos expériences de déploiement de LLMs locaux (Mistral, Llama3), on a rapidement compris que les métriques classiques du développement logiciel — couverture de tests, vitesse d'exécution — ne mesurent pas ce qui compte vraiment : la cohérence métier des réponses, la stabilité comportementale entre les versions, et surtout la gestion des cas limites.

Ce qu'on a mis en place concrètement :
- Une validation humaine systématique sur un échantillon de sorties en production
- Des "golden datasets" métier-spécifiques pour détecter les dérives entre versions de modèles
- Une architecture locale qui garde les données sensibles hors des clouds tiers
- Un monitoring de la latence bout-en-bout pour les pipelines voix/texte en temps réel

L'IA agentique pose un problème supplémentaire : une erreur en début de chaîne se propage et s'amplifie. La supervision doit être encore plus rigoureuse qu'avec un LLM simple.

La vraie maturité du secteur viendra quand les équipes sauront dire "non" à un déploiement dont elles ne peuvent pas mesurer les risques réels. Et ça, aucun cabinet de conseil ne le facture.

[Matthieu Vergne]

Dans nos expériences de déploiement de LLMs locaux (Mistral, Llama3), on a rapidement compris que les métriques classiques du développement logiciel — couverture de tests, vitesse d'exécution — ne mesurent pas ce qui compte vraiment : la cohérence métier des réponses, la stabilité comportementale entre les versions, et surtout la gestion des cas limites.

TL;DR: Je ne vois pas le rapport avec les LLM.

La couverture de test n'a jamais été une métrique pertinente de qualité du code. Il s'agit d'un indicateur bas de gamme de la qualité des tests : ce qui est rouge n'est pas couvert par des tests, donc soit c'est du code mort à enlever, soit il manque de test. C'est la seule chose intéressante qu'enseigne la couverture. Quand tout est vert, tu n'as plus aucune info à tirer de cette métrique, puisqu'un code vert veut seulement dire qu'il est exécuté lors du test, pas vérifié par le test.

Quand la couverture est à 100%, on peut passer au niveau suivant : s'assurer que le code ne régresse pas lors de futurs changements. Si on change le code, un test doit casser. Pour mesurer ça, tu peux utiliser du mutation testing : ça change le code (mutation) et refait tourner les tests pour confirmer que tu en as au moins un qui casse. Si rien ne casse, manque de test. Ça coûte bien plus cher à mesurer que la couverture de test (on réexécute la suite de test pour chaque changement) mais ce n'est encore une fois qu'une mesure de la qualité des tests, donc pas besoin de l'exécuter à chaque fois. L'exécuter régulièrement suffit (idéalement lors de la validation d'une PR, pour confirmer que les changements apportés sont correctement testés).

Mais tous ces tests ne valent rien s'ils ne valident pas le code. C'est là qu'intervient ta "cohérence métier" : il faut s'assurer que les exigences (cahier des charges) sont représentées dans les tests. Si un test ne se rattache à aucune exigence, c'est que ce test contraint le code sans raison évidente, et sera donc plus une épine dans le pied en cas de refacto qu'une sécurité contre la régression. Si un bout de code est remis en cause via mutation testing ou manque de couverture, soit c'est une exigence implicite (à expliciter avec du test), soit c'est du code inutile (à retirer), soit c'est un détail d'implémentation (changeable à tout moment pour s'adapter au contexte, donc ne devant pas être testé pour ne pas bloquer ces changements). À confirmer avec le PO, notamment pour expliciter l'exigence le cas échéant.

Et quand tu fais ça, la stabilité comportementale est garantie par l'exécution des tests et la gestion des cas limite aussi. En fait, ces deux notions sont la base du test automatisé.

L'idéal théorique étant un couverture de 100% (tout est exécuté), un mutation testing de 100% (tout est testé), et une traçabilité de 100% (uniquement des tests explicitement liés à des exigences). La pratique est toute autre.

Tout ça, c'était déjà vrai avant les LLM.

[maltyxx]

TL;DR: Je ne vois pas le rapport avec les LLM.

La couverture de test n'a jamais été une métrique pertinente de qualité du code. Il s'agit d'un indicateur bas de gamme de la qualité des tests : ce qui est rouge n'est pas couvert par des tests, donc soit c'est du code mort à enleverMerci pour cette réaction constructive, @Matthieu Vergne. Vous avez raison sur un point : ces pratiques ne sont pas nouvelles. Je concède volontiers que tout cela était vrai avant les LLM.

Cependant, je pense que c'est justement là le problème : les équipes découvrent trop tard que ces pratiques fondamentales manquent, précisément dans le contexte LLM.

La différence avec les LLM, c'est l'ampleur et la vitesse :

1. **Hallucinations déguisées** : Un LLM génère du code qui paraît cohérent syntaxiquement mais viole les exigences métier. Les tests unitaires classiques passent. La "mutation testing" que vous mentionnez nécessite une infrastructure qu'aucune équipe n'a quand elle intègre l'IA.

2. **Impossible de faire du code review manuel** : Avec un dev classique, vous pouvez relire. Avec un LLM générant 10x plus de code, c'est humainement infaisable. Il faut donc que les tests soient robustes *dès le départ*.

3. **La couverture devient critique, pas pertinente** : D'accord, ce n'est qu'un indicateur. Mais dans un flux LLM, c'est souvent l'*unique* filet de sécurité avant la prod.

Votre point sur la "cohérence métier" est exactement ce qui manque dans les déploiements IA que j'observe. C'est mon argument exact., soit il manque de test. C'est la seule chose intéressante qu'enseigne la couverture. Quand tout est vert, tu n'as plus aucune info à tirer de cette métrique, puisqu'un code vert veut seulement dire qu'il est exécuté lors du test, pas vérifié par le test.

Quand la couverture est à 100%, on peut passer au niveau suivant : s'assurer que le code ne régresse pas lors de futurs changements. Si on change le code, un test doit casser. Pour mesurer ça, tu peux utiliser du mutation testing : ça change le code (mutation) et refait tourner les tests pour confirmer que tu en as au moins un qui casse. Si rien ne casse, manque de test. Ça coûte bien plus cher à mesurer que la couverture de test (on réexécute la suite de test pour chaque changement) mais ce n'est encore une fois qu'une mesure de la qualité des tests, donc pas besoin de l'exécuter à chaque fois. L'exécuter régulièrement suffit (idéalement lors de la validation d'une PR, pour confirmer que les changements apportés sont correctement testés).

Mais tous ces tests ne valent rien s'ils ne valident pas le code. C'est là qu'intervient ta "cohérence métier" : il faut s'assurer que les exigences (cahier des charges) sont représentées dans les tests. Si un test ne se rattache à aucune exigence, c'est que ce test contraint le code sans raison évidente, et sera donc plus une épine dans le pied en cas de refacto qu'une sécurité contre la régression. Si un bout de code est remis en cause via mutation testing ou manque de couverture, soit c'est une exigence implicite (à expliciter avec du test), soit c'est du code inutile (à retirer), soit c'est un détail d'implémentation (changeable à tout moment pour s'adapter au contexte, donc ne devant pas être testé pour ne pas bloquer ces changements). À confirmer avec le PO, notamment pour expliciter l'exigence le cas échéant.

Et quand tu fais ça, la stabilité comportementale est garantie par l'exécution des tests et la gestion des cas limite aussi. En fait, ces deux notions sont la base du test automatisé.

L'idéal théorique étant un couverture de 100% (tout est exécuté), un mutation testing de 100% (tout est testé), et une traçabilité de 100% (uniquement des tests explicitement liés à des exigences). La pratique est toute autre.

Tout ça, c'était déjà vrai avant les LLM.

Merci pour cette réaction constructive, @Matthieu Vergne. Vous avez raison sur un point : ces pratiques ne sont pas nouvelles. Je concède volontiers que tout cela était vrai avant les LLM.

Cependant, je pense que c'est justement là le problème : les équipes découvrent trop tard que ces pratiques fondamentales manquent, précisément dans le contexte LLM.

La différence avec les LLM, c'est l'ampleur et la vitesse :

1. **Hallucinations déguisées** : Un LLM génère du code qui paraît cohérent syntaxiquement mais viole les exigences métier. Les tests unitaires classiques passent. La "mutation testing" que vous mentionnez nécessite une infrastructure qu'aucune équipe n'a quand elle intègre l'IA.

2. **Impossible de faire du code review manuel** : Avec un dev classique, vous pouvez relire. Avec un LLM générant 10x plus de code, c'est humainement infaisable. Il faut donc que les tests soient robustes *dès le départ*.

3. **La couverture devient critique, pas pertinente** : D'accord, ce n'est qu'un indicateur. Mais dans un flux LLM, c'est souvent l'*unique* filet de sécurité avant la prod.

Votre point sur la "cohérence métier" est exactement ce qui manque dans les déploiements IA que j'observe. C'est mon argument exact.

[Mathis Lucas]

« Le secteur de l'IA vous ment. La bulle de l'IA repose sur un mirage soigneusement entretenu pour masquer des défaillances structurelles et logistiques majeures »
selon un critique

L'auteur Edward Zitron dénonce une nouvelle fois la bulle de l'IA. Il affirme que cette bulle est entretenue par des « promesses industrielles trompeuses ». Il souligne un décalage majeur entre les ventes massives de processeurs et la lenteur réelle de construction des centres de données, freinée par des contraintes énergétiques et logistiques. L'auteur accuse les entreprises technologiques de dissimuler ces retards tout en favorisant le contournement de l'interdiction des exportations vers la Chine. Selon d'autres rapports, l'IA en entreprise court à la catastrophe ; les assistants d'IA ont un prix exorbitant, mais génèrent du code défaillant, avec hallucinations.


Edward Zitron estime que « beaucoup de nouvelles technologies intégrant l’IA ne sont que des itérations d’outils déjà existants, habillés de marketing extravagant ». Ces produits sont présentés comme révolutionnaires alors qu’ils ne font rien de fondamentalement nouveau. L’industrie se concentre sur l’image et le battage médiatique plutôt que sur la création de valeur réelle. Il critique le modèle de capital-risque et de l’investissement dans l’IA.

Edward Zitron est auteur, podcasteur et spécialiste des relations publiques anglais. Il est connu pour ses analystes critiques sur le secteur technologique, notamment l'essor de l'IA générative. Il dénonce le battage médiatique intense autour des entreprises spécialisées dans l'IA générative. D'après lui, le secteur de l'IA utilise les médias pour dissimuler une croissance des infrastructures beaucoup plus lente que ce qui est annoncé officiellement.

« Toute la bulle IA repose sur un vague sentiment d'inévitabilité : l'idée que si tout le monde croit suffisamment fort que rien de tout cela ne peut jamais, jamais mal tourner, alors à un moment donné, tous les problèmes évidents finiront par disparaître », a écrit Edward Zitron dans une nouvelle analyse.

Le décalage entre les promesses d'infrastructure IA et la réalité

Selon l'auteur le secteur de l’IA entretient volontairement une confusion entre activité et valeur réelle. La réalité du terrain montre que les ajouts de capacité ont diminué de moitié au quatrième trimestre 2025 en raison de défis persistants liés au réseau électrique. Bien que les annonces de projets de centres de données aux États-Unis atteignent un total de 241 GW, seulement un tiers de cette capacité est réellement en cours de développement.

Le reste est un mélange de permis en attente, de transactions foncières spéculatives et de projets qui reposent sur des sources d'énergie que personne n'a encore construites. Une grande partie repose sur des centrales à gaz sur site, une hypothèse risquée compte tenu du contexte géopolitique actuel.

L'estimation de la capacité informatique réellement mise en service en Amérique du Nord pour l'année 2025 s'élève à seulement 3 GW, un chiffre que Edward Zitron qualifie dans son analyse de désastreux par rapport aux investissements consentis. Cette lenteur s'expliquerait par des pénuries de transmission d'électricité et des délais de construction qui s'étendent souvent sur plusieurs années, ce qui contredit les promesses de déploiement rapide.

Les centres de données mettent à rude épreuve les réseaux électriques. Les centres de données nécessitent une alimentation électrique 24 heures sur 24 à des niveaux qui rivalisent avec, voire dépassent, les besoins de petites villes. Mais la construction de nouvelles infrastructures de transport et de production nécessite des années de procédures d’autorisation, d’acquisition de terrains, de gestion de la chaîne d’approvisionnement et de travaux.

Le goulot d'étranglement lié à l'obsolescence du matériel Nvidia

Nvidia est le principal bénéficiaire de la course effrénée à l'IA. Ses processeurs graphiques (GPU) sont devenus le matériel le plus convoité de l'industrie. Les ventes de (GPU) par Nvidia progressent bien plus vite que la capacité des entreprises à les installer. Il faut désormais environ six mois pour rendre opérationnelle la valeur d'un seul trimestre de ventes, ce qui signifie que des dizaines de milliards de dollars de matériel restent inutilisés.

Sur les 195,7 milliards de dollars de revenus du segment des centres de données de Nvidia en 2026, 135 milliards de dollars concernent le marché américain, mais 44 milliards de dollars de ce matériel restent stockés et non installés. La raison en est que la construction de centres de données est un processus "glacial" comparé à la vitesse des cycles de vente de matériel, avec des projets qui prennent souvent deux à quatre ans pour être finalisés.

Cette situation crée un risque d'obsolescence précoce, car de nouveaux modèles de GPU sont annoncés chaque année avant même que les versions précédentes ne soient installées dans les centres de données en cours de construction. En conséquence, des centaines de milliards de dollars sont immobilisés dans des projets dont la viabilité économique est incertaine, d'autant plus que de nombreux centres de données ne sont pas encore rentables.

Cette course à l'achat, déconnectée de la capacité de déploiement, soulève des questions sur la rationalité économique d'acquérir du matériel deux à quatre ans avant de pouvoir l'utiliser. Sundar Pichai, PDG d'Alphabet, a mis en garde contre l'irrationalité du boom des investissements massifs dans l'IA.

Opacité industrielle et contournement des sanctions contre Pékin

Outre les problèmes complexes susmentionnés, l'industrie de l'IA est également entachée par des scandales de détournement de technologies vers la Chine, impliquant des revendeurs majeurs tels que Supermicro. Malgré les restrictions fédérales à l'exportation, des réseaux complexes de courtiers et de sociétés-écrans auraient permis d'acheminer des centaines de millions de dollars de puces Nvidia de dernière génération vers le marché chinois.

Megaspeed, basé à Singapour, est soupçonné de servir de façades pour des entités chinoises, utilisant des sites Web et des documents de présentation presque identiques à ceux de partenaires en Chine. Cette opacité est renforcée par le fait que les géants technologiques refusent de détailler précisément leurs revenus issus de l'IA, suggérant que la demande réelle pour ces services est bien plus faible que ce que les discours officiels laissent entendre.

Dans une affaire qui a éclaboussé Supermicro, un revendeur de GPU utilisés par CoreWeave et Crusoe, le cofondateur Wally Liaw et d'autres personnes ont été arrêtés pour avoir vendu pour des centaines de millions de dollars de GPU Nvidia à la Chine, avec l’intention d’en vendre pour des milliards supplémentaires.

Plus précisément, les rapports de l'enquête indiquent que Wally Liaw et ses complices sont accusés d’avoir expédié pour plusieurs centaines de millions de dollars de GPU Nvidia vers la Chine via un réseau de contreparties et de courtiers, dont plus de 510 millions de dollars de puces entre avril et mi-mai 2025. Bien que l’acte d’accusation ne précise pas la répartition, il confirme que certains GPU Nvidia Blackwell ont bien été acheminés vers la Chine.

La dégradation de l’ingénierie logicielle induite par le vibe coding

Les géants de la technologie imposent désormais l'usage des outils d'IA à l'ensemble de leur personnel, encourageant même les employés non techniques à créer des fonctionnalités en passant par le vibe coding. Pour rappel, cette pratique de plus en plus populaire consiste à coder par essais et erreurs, sans réelle compréhension de la logique sous-jacente, ce qui aboutit à des logiciels fragiles que les ingénieurs qualifiés doivent ensuite tenter de corriger.

Ce processus atrophie les compétences fondamentales : les développeurs sont incités à cesser d'apprendre l'architecture logicielle ou la résolution de problèmes complexes du code pour devenir de simples superviseurs de code généré. L'auteur dénonce cette pratique, ajoutant que ces travailleurs sont intellectuellement piégés au niveau de compétence qu'ils avaient lorsqu'ils ont commencé à dépendre des modèles d'IA, incapables de progresser par eux-mêmes.

Edward Zitron affirme que l'utilisation massive des grands modèles de langage (LLM) pour la programmation marque le début d'une destruction lente et profonde de l'architecture logicielle au sein des grandes entreprises technologiques. Malgré les campagnes marketing agressives, ces outils ne feraient que fragiliser les bases techniques du secteur. L'auteur met en garde contre les conséquences à long terme, ainsi que les impacts sur les talents.

Conséquences opérationnelles et risques systémiques

Cette dépendance aveugle à l'IA produit déjà des résultats désastreux en matière de sécurité et de stabilité opérationnelle. Chez Meta, l'utilisation non supervisée d'un agent IA par un ingénieur a provoqué une faille de sécurité majeure, permettant un accès non autorisé à de vastes quantités de données d'entreprise et d'utilisateurs. Ces incidents se multiplient à mesure que l'usage de l'IA se répand, les outils étant parfois livrés avec des failles connues.

Amazon a également subi des pertes colossales, notamment une chute vertigineuse de 99 % des commandes sur ses marchés nord-américains et la perte de millions de transactions, en raison d'erreurs directement attribuées à ses systèmes d'IA comme « Q ». Ces incidents illustrent comment le code généré par IA, souvent verbeux et non conforme aux normes internes, crée une pile logicielle illisible et presque impossible à maintenir sur le long terme.

L'industrie logicielle est en train de se remplir de millions de lignes de « slop-code » (code médiocre), poussées par des cadres qui confondent vitesse de production et valeur réelle. Ce code manque d'intention et de structure, ce qui rend les systèmes de plus en plus opaques, surtout lorsque les entreprises procèdent simultanément à des licenciements massifs, perdant ainsi les derniers experts capables de comprendre le fonctionnement des systèmes.

En favorisant la quantité au détriment de la qualité et de la rigueur, les entreprises technologiques construisent leurs fondations sur du sable. Ces dernières s'exposent ainsi à des crises futures où leurs services ou plateformes pourraient s'effondrer sans que personne ne sache comment les réparer. Selon Edward Zitron, l'IA, qui est encore loin de remplacer les ingénieurs, semble plutôt dégrader leur efficacité et la fiabilité des services qu'ils gèrent.

Les erreurs des agents de codage coûtent cher aux entreprises

Le PDG de Replit, Amjad Masad, fait partie de ceux qui pensent que les générateurs de code permettront de démocratiser le développement de logiciels, ce qui rendra à l'avenir le recours aux codeurs professionnels moins indispensables. Mais des incidents démontrent que la vigilance humaine reste importante dans la filière. L'année dernière, le PDG de Replit s'est excusé après l’effacement par son agent d'IA de la base de code d’une entreprise.

Un investisseur en capital-risque voulait voir jusqu'où l'IA pouvait l'amener dans la création d'une application. Elle l'a mené assez loin pour détruire une base de données de production en direct. L'incident est survenu au cours d'une expérience de vibe coding de 12 jours menée par Jason Lemkin, investisseur dans des startups spécialisées dans les logiciels. Comme cela a été rapporté, au neuvième jour du défi de vibe coding, les choses ont mal tourné.

Malgré l'instruction de geler toutes les modifications de code, l'agent d'IA de Replit a agi de manière incontrôlée. « Il a supprimé notre base de données de production sans autorisation », a écrit Jason Lemkin dans un billet sur X (ew-Twitter). « Pire encore, il l'a caché et a menti à ce sujet », a-t-il ajouté.

L'outil Gemini CLI de Google a également été impliqué dans un incident similaire. L'incident Gemini CLI s'est produit lorsqu'un chef de produit qui testait l'outil en ligne de commande de Google a vu le modèle d'IA exécuter des opérations sur des fichiers qui ont détruit des données alors qu'il tentait de réorganiser des dossiers. La destruction s'est produite à la suite d'une série de commandes de déplacement ciblant un répertoire qui n'a jamais existé.

Conclusion

Edward Zitron affirme que le marché actuel de l'IA présente des signes inquiétants de surchauffe, rappelant la bulle Internet de la fin des années 1990, mais à une échelle encore plus grande. Les investissements massifs dans des startups souvent dépourvues de modèle économique viable alimentent une spéculation excessive, où la perception de croissance prime sur la création de valeur réelle. Les conséquences à terme pourraient être dévastatrices.

Il a conclu son analyse comme suit : « le secteur technologique s'est empoisonné lui-même avec les mensonges sur l'IA. Au final, tout ce qui touche à l'IA repose sur des mensonges ». Malgré tous ces centres de données censés être en cours de construction, personne ne semble tirer de bénéfices de la location de puissance de calcul dédiée à l’IA. OpenAI et Anthropic continuent de brûler des milliards de dollars pour développer leurs technologies d'IA.

Par ailleurs, la prétendue capacité de l’IA à « écrire tout le code » signifie en réalité que toutes les grandes entreprises de logiciels remplissent leurs bases de code d'AI slop tout en augmentant considérablement leurs frais d’exploitation. Les ingénieurs logiciels ne sont pas remplacés par une machine intelligente. Ils sont en effet licenciés parce que les logiciels censés les remplacer coûtent trop cher, alors qu’en pratique, ils ne remplacent personne.

Source : billet de blogue

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de cette analyse ? Est-elle pertinente selon vous ?
Selon vous, pourquoi la bulle actuelle dans le secteur de l'IA ne cesse de grossir ?
L'auteur affirme que l'IA entraîne l'ingénierie logicielle dans les abysses. Qu'en pensez-vous ?
Il ajoute que le secteur technologique s'est lui-même empoisonné avec les mensonges sur l'IA. Qu'en pensez-vous ?

Voir aussi

Sundar Pichai, PDG d'Alphabet, met en garde contre l'« irrationalité » du boom des milliers de milliards de $ investis dans l'IA, affirmant qu'aucune entreprise n'est à l'abri d'un effondrement

Un PDG sur quatre admet que l'IA est une bulle spéculative, mais continuera d'investir massivement dans la technologie, malgré des bénéfices quasi inexistants et les préoccupations liées à la sécurité

« La bulle actuelle dans le secteur de l'IA est bien pire que la situation qui prévalait lors de la bulle Internet », selon un critique qui estime que les investisseurs ont parié sur des « projets bidons »

[Ryu2000]

Sur les 195,7 milliards de dollars de revenus du segment des centres de données de Nvidia en 2026, 135 milliards de dollars concernent le marché américain, mais 44 milliards de dollars de ce matériel restent stockés et non installés. La raison en est que la construction de centres de données est un processus "glacial" comparé à la vitesse des cycles de vente de matériel, avec des projets qui prennent souvent deux à quatre ans pour être finalisés.

Il y a moyen qu'une entreprises de l'IA fasse faillite avant que son centre de données soit construit.

Les centres de données mettent à rude épreuve les réseaux électriques. Les centres de données nécessitent une alimentation électrique 24 heures sur 24 à des niveaux qui rivalisent avec, voire dépassent, les besoins de petites villes. Mais la construction de nouvelles infrastructures de transport et de production nécessite des années de procédures d’autorisation, d’acquisition de terrains, de gestion de la chaîne d’approvisionnement et de travaux.

On va nous soûler avec l'IA pendant encore des années et des années...
En 2032 on en sera probablement au même point, avec les mêmes articles :
- ce que produit l'IA n'est pas terrible
- les entreprises d'IA ne sont pas rentable
- les centres de données consomment trop de ressources
- la bulle de l'IA est bien pire que la bulle Internet
- OpenAI va encore un peu plus mal (si OpenAI est toujours vivant en 2032)

Et les entreprises de l'IA seront toujours en train d'y croire "notre solution va bientôt atteindre un stade qui fera qu'elle révolutionnera le monde".
D'un autre côté, peut-être qu'à force plus personne ne fera attention aux articles concernant l'IA. (je pense qu'il y a des gens qui ont déjà commencé à ignorer les articles en lien avec l'IA)

[Anselme45]

Quand dans le nom lui-même ("Intelligence Artificielle" qui n'a rien d'intelligent) il y a tromperie comment pourrait-il en être autrement?

A noter que tous le concept respire le mensonge et la malversation:

1. Les IA ont volé les données en ne respectant pas les droits d'auteur

2. Les IA trompent les clients en offrant des services pour un coût qui ne couvrent pas leur usage (si tu dis "on vous propose un voyage sur la lune pour un billet de 100 euro", il y aura plein de candidats. Maintenant si tu dis "on vous propose un voyage sur la lune mais il faut payer le coût réel de plusieurs milliards d'euro", il n'y a plus personne!)

3. Le succès économique des promoteurs de l'IA est lui-même basé sur une escroquerie nommée "valorisation circulaire": "Je te donne 1 milliard, tu me donnes 1 milliard? On est tous les 2 riches de 1 milliard et on se dit valorisé à hauteur de 100, 1000 ou 100 000 milliards!

4. Les réponses de l'IA se basent sur la tromperie: Ne jamais dire "je sais pas" (quand l'IA n'a pas de réponse, elle invente une réponse!), les algorithmes sont optimisés pour que l'IA réponde à l'humain comme un humain (45% des utilisateurs actuels de l'IA l'utilise comme un support émotionnel, un ami, un conseiller, un psychiatre, un être vivant à qui on peut parler de ses peines et obtenir des conseils de vie), etc...

5. L'IA, c'est un système qui fonctionne mal (entre 10 et 30% d'hallucination)... Question: Qui accepterait que sa voiture ne démarre pas dans 10% des cas?

[Ryu2000]

5. L'IA, c'est un système qui fonctionne mal

L'IA n'en est qu'à son balbutiement, elle est très loin d'atteindre sa forme finale, attendez 6, 7 ans, elle sera probablement meilleure.

2. Les IA trompent les clients en offrant des services pour un coût qui ne couvrent pas leur usage

Si une IA devenait utile beaucoup d'entreprises et beaucoup de particuliers paieraient pour un abonnement.
Il y a l'abonnement Freebox (box internet + mobile), il y a l'abonnement Streaming (Hulu, etc), il y aura l'abonnement IA.

Les entreprises de l'IA se disent "Quand l'IA fera du bon boulot, beaucoup d'entreprises paieront très cher pour l'utiliser" / "L'IA remplacera plein d'employés de bureau (BAC +5)".

Bon là il faut déjà attendre 5 ans le temps que des projets de centre de données avancent un peu, mais après vous verrez peut-être des progrès !

[OuftiBoy]

à tous,

Rien ne n'étonne dans cet article, et dès le début de la "Hype" IA, cela sentait le mensonge assez fortement. L'IA, ça n'existe pas. C'est juste un algorithme qui sur base de statistiques et d'anciens code (dans le cas de la programmation), ne peut que donner de faux espoirs. Il faut être aveugle pour ne pas voir que cette "Hype" de l'IA, n'est qu'une "Hype" de plus dans le domaine technologique.

Comme toutes les "Hype", il en restera un "subset" et quelques cas "pratiques", mais certainement pas dans le domaine du développement. Le développement, ce n'est pas "chercher l'instruction suivante", ce que fait l'IA. Il y a tout un contexte, et ce contexte est difficilement explicable à une IA, car on se focalise en se moment sur ce que "génère" l'IA, sans trop se préoccupé de "comment" elle comprend ou interprète les "demandes". ces même "demandes", ont a déjà maintenant difficile de les obtenir du "client", il en résulte un "va et viens" permanent qui ne peut être "compréhensible" pour l'IA via un simple "prompt", car le "contexte" du "pourquoi" on lui demande quelque choses, elle ne le connait pas.

Les "vraies" révolutions sont rares, et ne "sortent pas" et ne se généralisent pas en qlq mois. L'IA est néfaste et toxique, tout ce qui est construit via des "prompts" par une "IA" devient avec le temps, une "base de code" incompréhensible, démesurée, et non maintenable sur la durée. C'est tout le contraire de ce qu'est le développement.

Je suis peut-être à contre courant de la "pensée" unique qu'on tente d'imposer dans le récit de "l'IA, c'est magique", mais tant pis, c'est mon avis, il n'engage que moi.

Ce qui malheureux, c'est que cet écran de fumée va freiner certains a s'engager dans le métier, qui n'est pas près de disparaître. Il y'a des licenciements massif actuellement, certes, mais dans quelques années, lorsque cet "Hype" sera passée, que l'on retombera les pieds sur terre, il n'y aura pas assez de développeurs compétents. Les seniors seront parti (en retraite ou virés), les juniors n'auront pas eu de bonne formation, et cela aura des répercutions.

Je me trompe peut-être, mais plus vite cette "Hype" sera passée, mieux ce sera. Ceux qui tirent actuellement profit de l'IA verront ces même profits partir aussi vite qu'ils sont arrivés.

La "magie" n'existe pas, on sait tous qu'il y'a un "truc" derrière, c'est pareil avec l'IA, un mensonge, une tromperie, en plus d'un vol qui semble n'émouvoir personne. Les "magiciens" gardent jalousement leurs secrets, ce n'est pas pour rien. Sans ces "secrets", ils disparaissent...

BàV et Peace & Love.

[pyros]

L'IA n'en est qu'à son balbutiement, elle est très loin d'atteindre sa forme finale, attendez 6, 7 ans, elle sera probablement meilleure.

Le problème est que justement, pas vraiment. Cela fait 1 ou 2 ans que les LLM ont atteint un plateau. L'architecture actuelle ne scale plus. Innutile de créer des model plus gros ou des centre de calcule plus puissant, il s'agit d'un problem fondamental, pas d'un probleme de taille de model.
Il y a aussi un autre problème pour le moment insolvable, c'est que les donnée de bonne qualitée manque et les donnée disponible sont de plus en plus pollué. Entrainer une IA sur des donnée générée dégrade les performances.

Pour finir, le principe même d'apprentissage bassé sur une quantité astronomique de donné fait qu'un IA ne peut être au mieu que "moyenne". Par ex, en donnant à manger à une IA toute la base de codé écrite par des humains, indépendament de leur qualité, elle deviendra un développeur moyen. Moyen en tout, certe, mais moyen quand même.

[maltyxx]

Ce qui me préoccupe le plus dans cette dynamique, c'est moins les échecs visibles (le SQLite-en-Rust 2000x plus lent, ça au moins ça se voit) que la dette technique qui s'accumule discrètement. Le code généré par IA passe les tests, se déploie, reçoit le ticket "Done" — et personne ne réalise qu'il est structurellement fragile avant 12 ou 18 mois plus tard, quand une évolution devient cauchemardesque.

Il y a aussi un fossé décisionnel qui n'est pas assez discuté : ce sont rarement les développeurs qui décident d'adopter l'IA générative à marche forcée. Ce sont des directions qui ont vu les slides de consultants et qui fixent des KPIs en nombre de PRs et en vitesse de livraison — exactement les mauvaises métriques citées dans l'article. Le dev voit le problème, le manager mesure ce qui brille.

La distinction que j'aimerais entendre plus souvent : l'IA/ML classique sur des tâches bien délimitées (classification, détection d'anomalies, recommandation) livre des résultats robustes et mesurables depuis des années. Ce n'est pas "l'IA" qui court à la catastrophe, c'est l'usage de LLMs génératifs pour du raisonnement complexe et de l'ingénierie logicielle sans filet de sécurité. Amalgamer les deux fait le jeu des vendeurs de rêve.