L'IA n'est pas le problème.
Le contexte l'est.

L'argumentaire économique et de précision en faveur du grounding des LLMs pour la modernisation des logiciels d'entreprise

Lorsque l'IA remplace des développeurs juniors sur des tâches de codage à portée limitée, génère du code entièrement nouveau ou analyse des applications petites et simples, l'équation économique est simple. Dans ces scénarios, les LLMs sont moins coûteux et plus productifs que les développeurs humains . L'IA opère dans un contexte restreint, se concentrant sur une portion délimitée de code où son raisonnement probabiliste fonctionne relativement bien.

Mais lorsque l'on demande à l'IA de rétro-concevoir de très grands systèmes logiciels personnalisés qui fonctionnent comme le « cerveau de l'entreprise » dans des organisations software-intensives, les LLMs peinent, et la recherche comme le terrain confirment la cause profonde : l'IA a un besoin impérieux de contexte architectural, de graphes de dépendances, de flux de transactions et de données. Ce besoin devient encore plus prononcé lorsqu'il s'agit de transformer un « système d'applications », c'est-à-dire un ensemble d'applications interconnectées qui soutiennent ensemble des workflows critiques à l'activité de l'entreprise.

État des lieux

L'industrie de l'IA dépense des sommes sans précédent en puissance de calcul brute. Les hyper-scalers ont investi plus de 370 milliards de dollars dans l'infrastructure AI en 2025 seulement. La consommation mondiale d'électricité des data centers devrait doubler pour atteindre 945 TWh d'ici 2030. Pourquoi ? Parce que des recherches évaluées par les pairs issues du MIT (2025) et d'autres institutions ont mis en évidence un point frappant : la majorité des progrès de l'IA ces dernières années sont venus d'une augmentation du hardware et de l'énergie alloués au problème, et non d'algorithmes plus intelligents. Mais plus de compute ne signifie pas plus de précision. Pour la transformation des logiciels d'entreprise, l'écart entre « plausible » et « juste » est là où les projets échouent.

Certains affirmeront que les LLMs s'améliorent visiblement d'une année sur l'autre, et les fournisseurs soulignent à juste titre les avancées en reinforcement learning axé sur le raisonnement, le pre-training à plus grande échelle et les nouvelles architectures de modèles. Ces progrès sont réels. La question est : dans quelle proportion ? Et la réponse soutient la thèse de cet article : l'IA a besoin d'inputs plus intelligents et contextuels pour réaliser son plein potentiel.

Si la capacité de l'IA est essentiellement une fonction de la quantité de compute utilisée, alors une IA non-groundée — celle qui doit découvrir son environnement par une exploration pas à pas — brûle la ressource la plus coûteuse de l'économie AI, tout en produisant des niveaux de précision et d'intégrité structurelle trop faibles pour la modernisation en entreprise. Les approches non-groundées coûtent 10 fois plus cher et produisent des résultats bien trop peu fiables pour une modernisation à grande échelle. Sans grounding, les LLMs font de l'archéologie probabiliste sur des millions de lignes de code, et l'archéologie probabiliste produit des résultats probabilistes.

La thèse

La mitigation la plus efficace n'est pas un meilleur prompt ni un modèle plus grand. C'est l'injection d'intelligence déterministe dans l'équation : des flux de données réels, de véritables chemins d'exécution, des points d'intégration factuels. Des informations sur lesquelles l'IA peut s'appuyer pour raisonner sur des dizaines de milliers de composants interconnectés. Plutôt qu'opposer intelligence déterministe et probabiliste, cet article soutient que les grandes entreprises devraient combiner la puissance de l'IA avec la précision et l'exactitude de la technologie d'analyse déterministe, pour atteindre la précision et l'intégrité structurelle que la modernisation en entreprise exige, à une fraction du coût.

I. La physique du progrès en IA.
Le compute est (presque) tout

1. La sagesse conventionnelle

Le récit populaire du progrès de l'IA ressemble à ceci : des chercheurs dans les meilleurs laboratoires inventent de nouveaux algorithmes, architectures et techniques d'entraînement astucieux. Ces avancées rendent les modèles plus intelligents. Le hardware aide, mais la vraie magie réside dans le logiciel.

Ce récit est, au mieux, incomplet. Un corpus croissant de recherches rigoureuses et évaluées par les pairs démontre que l'infrastructure physique de l'IA — GPU, data centers et l'électricité pour les alimenter — a été le principal moteur des gains de capacité, bien plus que les améliorations algorithmiques ou les architectures de modèles.

2. Les preuves du MIT FutureTech

Deux articles du MIT FutureTech offrent le compte-rendu empirique le plus détaillé de cette dynamique : « What Drives Progress in AI? Trends in Compute » (janvier 2025), et ce qui semble être un article de suivi « On the Origin of Algorithmic Progress in AI » (janvier 2026).

Cette analyse, rédigée par Slattery, Roded, Del Sozzo et Lyu au sein du Laboratoire d'informatique et d'intelligence artificielle du MIT, pose les bases du dossier. S'appuyant sur les travaux de Thompson et al. (2022) et Ho et al. (2024), l'article constate que la mise à l'échelle du compute a contribué environ deux fois plus que les progrès algorithmiques aux gains de performance effective de l'IA (Ho et al., 2024). La puissance de calcul utilisée pour entraîner les modèles d'IA frontier a augmenté d'environ 4 à 5 fois par an, surpassant largement la loi de Moore. Les acteurs industriels dominent le développement des modèles frontier précisément parce qu'eux seuls peuvent se permettre le compute nécessaire — le coût d'entraînement d'un seul modèle frontier atteint désormais des dizaines ou des centaines de millions de dollars. Enfin, la relation entre compute et performance suit des lois de mise à l'échelle régulières et prévisibles : plus de compute produit de manière fiable de meilleurs modèles, quel que soit le domaine.

L'article conclut : « Bien que les améliorations algorithmiques jouent un rôle vital, la majorité des gains de performance provient de l'augmentation de la puissance de calcul. »

Cet article de suivi (janvier 2026) va plus loin. Plutôt que d'estimer la contribution relative du hardware par rapport aux algorithmes, il pose une question plus profonde : les gains d'efficacité algorithmique dépendent-ils eux-mêmes de la mise à l'échelle du compute ? La réponse est oui. Par suppression chirurgicale des innovations algorithmiques et des expériences de mise à l'échelle (en testant les algorithmes sur différents budgets de compute), les auteurs constatent que les estimations précédentes créditaient les algorithmes d'une amélioration de 22 000× de l'efficacité d'entraînement entre 2012 et 2023. Le nouvel article ne peut rendre compte que de « moins de 100× » d'innovations algorithmiques spécifiques testées expérimentalement. L'écart s'explique par la « dépendance à l'échelle » : deux innovations clés (la transition des LSTM aux Transformers et le passage à l'équilibrage données-paramètres optimal de Chinchilla) produisent des rendements d'efficacité croissants à mesure que le compute augmente. À petite échelle de compute, ces innovations apportent des gains modestes. À l'échelle frontier, elles semblent transformatrices.

Le résultat principal : « jusqu'à 91 % des gains d'efficacité mesurés dépendent du scaling exponentiel historique du compute. » Si les budgets de compute étaient restés constants, les innovations algorithmiques seules n'auraient produit que moins de 10 % des améliorations observées à la frontier actuelle. L'article introduit également un concept critique : la « dépendance au cadre de référence ». Une séquence de modèles Transformer progressivement plus grands (mais par ailleurs identiques) peut sembler montrer un progrès algorithmique continu par rapport à une baseline LSTM, même si rien dans la procédure d'entraînement n'a changé. Le « progrès » est entièrement un artefact du déplacement le long d'une courbe de scaling où l'écart avec la référence croît avec le compute. Cela crée ce que les auteurs décrivent comme « l'apparence d'un progrès algorithmique sans nouvelles innovations. »

Conclusion : « Les algorithmes ne sont pas plus intelligents. C'est le hardware qui les fait paraître plus intelligents. »

Cela peut sembler sévère, mais les résultats du MIT ne sont pas isolés. Ils sont cohérents avec un large corpus de recherches :

• La « Bitter Lesson » de Richard Sutton (2019). L'influent chercheur en IA a soutenu, à partir de 70 ans d'histoire de l'IA, que « les méthodes générales qui exploitent le calcul sont au final les plus efficaces, et de loin. » Les méthodes exploitant la connaissance humaine du domaine perdent systématiquement face aux méthodes qui montent à l'échelle avec le compute.
• L'analyse « AI and Compute » d'OpenAI a documenté que le compute utilisé pour entraîner les modèles frontier a augmenté d'environ 10× par an, et que « dans de nombreux domaines actuels, plus de compute semble mener de façon prévisible à de meilleures performances. »
• Harvard Kempner Institute, « The Power of Scale in Machine Learning » (2025) a montré que GPT-3 était 100× plus grand que GPT-2 mais reposait sur la même architecture. Les gains de capacité provenaient principalement de la mise à l'échelle, et non d'une grande nouveauté algorithmique.
• Toby Ord, « Evidence that Recent AI Gains are Mostly from Inference-Scaling » (2025) : même pour les modèles de raisonnement de pointe, 82 % des gains de performance sur les benchmarks MATH provenaient de l'inference-scaling (dépenser plus de compute au moment du test), et non d'avancées algorithmiques.
• Epoch AI, « Can AI Scaling Continue Through 2030? » (2024) : projette une expansion de la production de GPU de 30 à 100 % par an jusqu'en 2030, identifiant la croissance des clusters GPU comme le principal moteur de la poursuite du progrès de l'IA.

3. Les marchés financiers et les fournisseurs d'énergie sont d'accord

Le marché lui-même révèle où la valeur est créée. Le grand gagnant corporate de l'ère IA n'est pas une entreprise d'algorithmes — c'est NVIDIA. Les hyper-scalers racontent la même histoire. Amazon, Microsoft, Google et Meta ont collectivement dépensé plus de 200 milliards de dollars en capex d'infrastructure IA en 2024, avec des projections dépassant 330 milliards de dollars en 2025.

Du côté de l'énergie, l'Agence internationale de l'énergie projette que la consommation mondiale d'électricité des data centers doublera pour atteindre environ 945 TWh d'ici 2030, soit environ deux fois la consommation totale d'énergie de la France en 2024. Le département de l'Énergie des États-Unis rapporte que l'électricité consommée par les data centers est passée de 58 TWh (2014) à 176 TWh (2023), avec des projections de 325 à 580 TWh d'ici 2028.

II. L'économie du grounding de l'IA.
La taxe agent vs la réduction grounding

Le coût d'une IA non-groundée se manifeste selon deux dimensions. La première est économique : tokens gaspillés, exploration redondante, compute incontrôlé. La seconde, que l'on voit dans la Partie III, est plus conséquente : dégradation de la précision et compromission de l'intégrité structurelle du logiciel qui en résulte.

1. La taxe d'exploration

Lorsqu'un agent IA opère sur un codebase large, complexe et multi-technologique sans contexte architectural déterministe, il doit découvrir la structure du système par l'exploration, les hypothèses, les questions et les essais-erreurs. Chaque prompt exploratoire, chaque rechargement de contexte, chaque faux départ dû aux hallucinations, chaque cycle d'itération consomme des tokens. Les agents IA font face à un problème de découverte exponentielle, que l'on peut décrire simplement comme suit :

1. L'IA examine un composant et identifie des dépendances inconnues.
2. L'IA examine les dépendances les plus prometteuses, découvrant des inconnues supplémentaires par dépendance.
3. Le schéma se répète, créant un arbre de découverte qui peut atteindre des centaines de nœuds.

Ce qui devrait être une tâche ciblée devient une « expédition de cartographie » consommant potentiellement des millions de tokens, avec une précision qui se dégrade en cours de route en raison de la nature probabiliste de chaque boucle, construisant essentiellement probabilité sur probabilité sur probabilité. C'est un problème de précision. Chaque inférence probabiliste devient le fondement de la suivante. Au moment où l'agent a enchaîné des dizaines de dépendances inférées, la confiance cumulée est extrêmement faible. Le gaspillage de tokens et la perte de précision partagent la même cause profonde : l'agent devine, et chaque supposition amplifie la précédente.

2. Quantifier le gaspillage

Les rares études empiriques disponibles — principalement issues de SWE-bench — mesurent les agents sur des dépôts Python open source bien structurés de 10K à 100K lignes. Les cibles de modernisation en entreprise sont fondamentalement différentes : plus grandes (souvent 1M à 10M+ LOC), multilangage (Java, COBOL, C, frameworks, SQL, PL/SQL), peu documentées, avec des décennies de dette technique accumulée, des commentaires trompeurs, des dépendances circulaires et des conventions de nommage qui rendent inefficace l'exploration par mots-clés.

Ces études se concentrent sur la consommation de tokens. Mais l'économie va au-delà du coût des tokens : la vraie dépense réside dans les échecs et les reprises causés par une précision et une intégrité insuffisantes. Sans grounding, chaque inférence probabiliste amplifie la suivante, et les reprises dues aux hallucinations s'accumulent à travers les itérations. Le gaspillage le plus important n'est pas les tokens eux-mêmes, mais un niveau de précision si bas que les projets de modernisation basés uniquement sur l'IA sont de plus en plus perçus comme des échecs.

Pour rendre cet article difficile à contester, les estimations présentées ci-dessous sont délibérément conservatrices. Elles s'extrapolent à partir de données mesurées sur des codebases plus simples et visent à établir un ordre de grandeur. Les lecteurs sont invités à considérer que les conditions réelles en entreprise sont susceptibles de pousser la consommation effective au-delà de ces estimations, non en deçà.

2.1 Rétro-ingénierie et refactoring

2.1.1 Premier niveau : Rétro-ingénierie

Cette couche couvre le travail analytique de compréhension de l'architecture de chaque module, ses dépendances, ses flux de données et sa logique métier. Elle est réalisée une fois par module, typiquement environ 50 modules pour une application d'entreprise de taille moyenne JavaScript/Java/SQL composée de 500K LOC.

(1) Note sur la phase de découverte : La règle générale selon les sources indique qu'1 token ≈ 4 caractères pour du texte anglais, mais le code est plus dense, environ 3 à 4 caractères par token selon la verbosité du langage. Le nombre de tokens statique du codebase complet de 500K LoC serait d'environ 6 millions de tokens (opérations de lecture seules). L'agent ne lit pas l'ensemble lors de la phase de découverte, car la fenêtre de contexte (200K effective pour 1M nominale) ne peut pas le contenir. L'agent lit donc sélectivement environ 5 à 10 % du codebase, soit 250K à 500K tokens de code brut, plus les prompts, l'historique, etc. 500K tokens pour une découverte « grossière » semble être le bon ordre de grandeur, 300K pour être conservateur. À noter que, comme l'agent ne peut jamais « voir » plus qu'un petit fragment de l'application à un instant donné, il travaille à travers un trou de serrure, tour après tour, en relisant des fragments et en essayant d'assembler un modèle mental qu'il ne peut en réalité pas maintenir.

(2) Avec le grounding, l'agent reçoit la carte des composants, sait exactement quels fichiers modifier et comprend les dépendances en amont. Similaire à la réduction de 23 à 54 % constatée par SWE-Pruner, mais le grounding va plus loin que le pruning : il élimine totalement l'exploration pour la partie contexte architectural (architecture réelle précalculée, graphes de dépendances, call flows, transactions de bout en bout depuis les entrées utilisateur jusqu'à l'accès aux données). Une estimation conservatrice devrait se situer entre 100K et 150K tokens par tâche de refactoring.

(3) La perte de précision se cumule entre les phases. Une limite de module mal identifiée en Phase 1 conduit à un mappage incorrect des dépendances en Phase 2, qui produit une analyse erronée des flux de données en Phase 3, qui corrompt la traçabilité de la logique métier en Phase 4. Au moment où l'agent atteint la validation, il vérifie son travail par rapport à son propre modèle défaillant — et non par rapport à la réalité.

2.1.2 Deuxième niveau : Refactoring

Un refactoring complet est un ensemble de tâches, une « tâche » étant un seul ticket Jira ou pull request, un changement/fonctionnalité/correction spécifique (ex. : « extraire la logique de validation des paiements dans un service séparé », « refactorer la gestion des erreurs dans le flux de paiement », etc.)

Ces tâches se répartissent en plusieurs catégories :

• Refactoring structurel. Extraction de classes monolithiques en services, suppression des dépendances circulaires, séparation des préoccupations (ex. : logique métier mélangée dans les contrôleurs ou les couches DAO), extraction des utilitaires partagés, réorganisation des structures de packages. Sur une application de 500K LOC, on peut en avoir des centaines.
• Modernisation de la couche données. Migration vers un framework de persistance moderne, restructuration des relations entre entités, normalisation des schémas dénormalisés, extraction des patterns repository, remplacement des procédures stockées par de la logique applicative (ou vice versa), migration d'une base de données à une autre.
• Refactoring API et intégrations. Mise en œuvre d'un mécanisme API adéquat, standardisation de la gestion des erreurs sur tous les endpoints, remplacement des appels synchrones par des patterns event-driven, etc.
• Mises à niveau framework et infrastructure. Migration depuis des versions plus anciennes, remplacement des bibliothèques dépréciées, mise à jour des patterns d'authentification/autorisation, préparation à la conteneurisation, remplacement des solutions maison de logging/config par des frameworks standard.
• Préoccupations transversales — standardisation de la gestion des exceptions, ajout d'une observabilité adéquate, renforcement de la sécurité, remplacement des configurations en dur par une configuration externalisée, introduction d'une injection de dépendances appropriée là où elle est absente, etc.
• Une règle empirique en modernisation d'entreprise est d'environ 1 tâche pour 500 lignes de code, en sachant que certaines zones nécessitent un refactoring plus lourd, d'autres ne sont que des retouches mineures. Cela donne 1 000 tâches pour 500K LOC, ce qui est cohérent avec le chiffrage/pricing typique des grands GSI pour les programmes de modernisation.

L'estimation de 1 000 tâches est dans la fourchette basse, surtout si l'on considère que chacune constitue un pull request discret et révisable.

2.2 Estimation du nombre moyen de tokens par tâche

La documentation de Claude Code indique qu'un développeur consomme environ 300K à 600K tokens par tâche de base (tâches de codage sur des codebases familiers et de petite taille). SWE-bench montre de son côté ~1M de tokens par tâche pour des dépôts Python petits (10K LoC) et bien structurés. Pour les tâches de refactoring Java/SQL en entreprise, l'agent doit redécouvrir le contexte à chaque fois, gérer les faux départs, les rechargements de contexte, etc. Une estimation minimum réaliste par tâche de refactoring devrait se situer entre 1,5M et 2M de tokens. Ce chiffre par tâche utilisé dans ce modèle est également délibérément conservateur. Le baselin SWE-bench de ~1M de tokens par tâche a été mesuré dans ce qui sont sans doute les conditions les plus favorables qu'un agent IA puisse rencontrer. Même dans ces conditions favorables, l'agent a consommé 693K tokens en opérations de lecture seules (911K tokens au total sur environ 51 tours d'interaction, Sonnet 4.5) pour simplement tenter de corriger un seul bug.

La découverte de l'ICLR 2026 d'une variance allant jusqu'à 10× entre des exécutions sur des tâches identiques renforce l'idée qu'une tâche dont la moyenne est de 1,5M de tokens pourrait facilement atteindre 5 à 10M lors d'une mauvaise exécution. D'une manière générale, les rapports du secteur indiquent que les workflows agentic ont multiplié la consommation de tokens par tâche par 10 à 100× depuis fin 2023 (Adaline Labs, 2025). Ainsi, l'estimation de 1,5 à 2M est une estimation que les praticiens en entreprise peuvent trouver optimiste.

3. Traduire les tokens en dollars (et en valeur business)

La modernisation de niveau entreprise justifie l'utilisation de modèles frontier ; en appliquant les estimations ci-dessus et la tarification d'Opus 4.6 (15 $/75 $ par million de tokens input/output) et un coût I/O de tokens mixte (80/20 Input/Output), un programme de modernisation de 1 000 tâches sur une application Java/SQL de 500K LOC coûterait environ 43 000 $ en consommation de tokens seule sans grounding architectural. Avec un grounding déterministe, le même programme consommerait environ 125 millions de tokens pour un coût d'environ 3 300 $, soit une économie d'environ 40 000 $ et plus de 90 % des tokens.

(*) Coût mixte (80/20 Input/Output), en ligne avec les résultats SWE-bench concernant l'équilibre Input/Output.

À noter que, sans grounding, la rétro-ingénierie et le refactoring ne sont pas clairement séparés en pratique. Ce qui se passe, c'est que l'agent reçoit une tâche (ex. : « extraire la validation des paiements dans un service séparé ») et commence à explorer le codebase pour comprendre la zone concernée, puis tente d'effectuer les modifications du code, puis explore davantage pour valider les dépendances, etc. Économiquement, cela signifie que pour chaque dollar dépensé en modifications de code réelles, trois dollars sont dépensés à redécouvrir le contexte architectural. Avec le grounding, la rétro-ingénierie est effectuée une seule fois, en dehors de l'agent, par CAST Imaging ou un autre moteur d'analyse déterministe. L'architecture précalculée devient l'input de chaque tâche de refactoring.

4. Le problème des agents incontrôlés. Et ça empire.

Les scénarios ci-dessus supposent une supervision humaine. Lorsque des organisations déploient des agents IA autonomes sans grounding déterministe, l'économie peut devenir dangereuse :

• Boucles d'exploration infinies : l'agent découvre une dépendance, l'explore, trouve d'autres dépendances, continue indéfiniment. Peut consommer plus de 1M de tokens avant une intervention humaine.
• Spirales d'hallucination : l'agent fait une hypothèse incorrecte, s'appuie dessus, reçoit un retour contradictoire, tente de réconcilier, fait une nouvelle hypothèse erronée. Absence de convergence signifie une consommation de tokens illimitée.
• Boucles test-échec : l'agent génère du code, les tests échouent, l'agent suppose une mauvaise compréhension, réexplore l'ensemble du codebase, réessaie, échoue à nouveau. Il peut brûler des millions de tokens avant l'interruption.

Chacun de ces modes d'échec ne brûle pas seulement des tokens. Il produit du code construit sur des erreurs cumulées, amplifiant la crise de précision décrite dans la partie III ci-dessous.

Les frameworks agentic modernes incluent désormais des guardrails — budgets de tokens, caps d'itérations, détection de boucles et coupe-circuits de coûts — qui préviennent les scénarios incontrôlés les plus extrêmes. Des mécanismes de guardrails et de contrôle des coûts ont émergé depuis 2025 pour prévenir les coûts incontrôlés. Les frameworks agentic (LangChain/LangGraph, CrewAI, etc.) permettent désormais de définir un nombre maximum d'« étapes de réflexion » par exécution d'agent... et Anthropic ou OpenAI appliquent des quotas de requêtes par minute et quotidiens/hebdomadaires, précisément parce que les grands utilisateurs de Claude Code brûlaient des tokens à des rythmes insoutenables. Ces mécanismes sont nécessaires et bienvenus. Mais ce sont des limiteurs de dégâts, pas des solutions. Les guardrails plafonnent le gaspillage maximal ; le grounding en élimine la cause.

III. Le risque réel.
Pourquoi la précision est le facteur décisif, et non le coût

Les économies de coûts sont importantes — mais ce n'est pas pour cela que les projets de modernisation échouent. Le véritable argument en faveur du grounding déterministe est la précision et l'intégrité structurelle.

Sans grounding architectural, les agents IA opérant sur des applications de niveau entreprise font, par conception, des « suppositions ». Ils infèrent des dépendances plutôt que de les connaître. Ils supposent des patterns standard là où des contournements legacy existent. Ils hallucinent des limites de services qui ne correspondent pas à la réalité. Les LLMs eux-mêmes, lorsqu'on les interroge directement, le reconnaissent : ils ont besoin d'intelligence architecturale déterministe (vraies cartes de composants, graphes de dépendances vérifiés, chemins d'exécution factuels, accès aux données précis...) pour raisonner de manière fiable sur des systèmes complexes.

Gemini de Google, par exemple, mentionne le besoin d'un « Architectural Cheat Sheet ». En résumé, ils demandent à être groundés, ou à être «context-aware». Une fois ce contexte fourni, la différence en termes de précision et d'intégrité est mesurable. Sans grounding, la précision de l'IA sur des applications d'entreprise complexes oscille autour de 30 % selon plusieurs projets réels. Avec un contexte architectural déterministe injecté dans le processus, ce chiffre dépasse 85 % selon un grand intégrateur de systèmes mondial ayant testé cela sur plusieurs applications de niveau entreprise.

Cela est important car dans la modernisation des logiciels d'entreprise, la précision n'est pas un spectre. C'est un seuil : un module refactorisé à 85 % n'est pas utile à 85 %. Si les 15 % restants comprennent des dépendances manquées, des frontières de transaction brisées ou des flux de données sectionnés, le module peut être pire que ce qu'il remplaçait.

Une approche uniquement basée sur l'IA peut également introduire des vulnérabilités, briser la logique métier ou corrompre silencieusement les données. Dans les industries réglementées — bancaire, assurance, santé, aéronautique, etc. — un seul défaut structurel non détecté peut déclencher des échecs d'audit, des violations de conformité ou des incidents opérationnels dont les coûts dépassent largement toute économie sur les tokens. L'intégrité structurelle amplifie cette préoccupation. Même lorsque les modifications de code individuelles semblent correctes de façon isolée, l'effet cumulatif de centaines de modifications générées par l'IA sur un système complexe peut dégrader les qualités au niveau système — résilience, sécurité, performance — de manières qui ne deviennent visibles que sous charge ou en production. L'analyse déterministe appliquée selon des normes établies (CWE pour les vulnérabilités de sécurité-résilience-efficacité, ISO 5055 pour la qualité structurelle globale au niveau système) fournit la couche de vérification que l'IA probabiliste ne peut tout simplement pas offrir seule. Sans elle, chaque modification générée par l'IA est un pari non vérifié sur la solidité structurelle, ce qui signifie que la charge de vérification humaine croît de façon exponentielle.

Les articles du MIT aident à recadrer le problème des hallucinations. Les LLMs sont des systèmes probabilistes. Lorsqu'on leur demande de déduire des relations architecturales à partir du code, ils infèrent plutôt qu'ils n'analysent. L'article du MIT de 2026 montre que les améliorations algorithmiques n'ont pas fondamentalement changé cela. Ce qui s'est amélioré, c'est que plus de compute rend les outputs probabilistes plus plausibles. Mais si « plus plausible » ou « très plausible » convient dans de nombreux domaines, en ingénierie logicielle, « plus plausible » ne signifie pas « correct ».

Ainsi, si une économie d'environ 40 000 $ sur un programme de modernisation est bienvenue, la question plus fondamentale est : quel est le coût de la modernisation incorrecte d'une application mission-critical ? Pour la plupart des entreprises, la réponse est plusieurs ordres de grandeur au-dessus du budget de tokens. Le grounding déterministe ne rend pas seulement l'IA moins coûteuse : il la rend suffisamment digne de confiance pour être utilisée sur les systèmes qui comptent le plus.

Conclusion

À 30 % de précision, un programme de modernisation de 1 000 tâches ne produit pas une application modernisée — il produit une dette. Chaque dépendance brisée non détectée, chaque flux de données sectionné, chaque transaction silencieusement corrompue est un défaut qui se manifestera lors d'un audit, en production ou lors d'une faille de sécurité.

Ce n'est pas un problème de coût. C'est une crise d'intégrité.

Les chiffres parlent d'eux-mêmes. Sans grounding, un programme de modernisation de 1 000 tâches brûle environ 43 000 $ en tokens — dont 92 % sont dépensés par l'agent à tenter de comprendre ce qu'il regarde, et non à modifier du code. Avec un grounding déterministe, le même programme coûte environ 3 300 $.

Le grounding déterministe change totalement l'équation. Non pas en rendant l'IA plus intelligente, mais en lui donnant quelque chose qu'aucune quantité de compute ne peut générer par elle-même : la vérité sur le fonctionnement réel d'un système. De vrais graphes de dépendances. Des chemins d'exécution vérifiés. Des flux de données factuels. Lorsque l'IA sait au lieu de deviner, la précision dépasse 85 %, la consommation de tokens chute d'un ordre de grandeur, et la modernisation devient un processus d'ingénierie contrôlé plutôt qu'une expérience probabiliste coûteuse.

Le choix pour les entreprises n'est pas de savoir si elles doivent utiliser l'IA — cette question est réglée. Le choix est de laisser l'IA explorer à l'aveugle, brûlant la ressource la plus rare de l'économie technologique sur des hallucinations et des reprises, ou de la grounder avec une intelligence déterministe et de diriger chaque token vers un travail productif.

Un chemin mène aux 40 % de projets d'IA agentic que Gartner prédit seront abandonnés d'ici 2027. L'autre mène à une modernisation pilotée par l'IA qui produit réellement des résultats — dans les délais, dans les budgets et avec l'intégrité structurelle que les systèmes mission-critical exigent.