- ▸ L'IA ne répare pas les données qu'elle consomme
- ▸ Quatre briques qui survivent au remplacement du modèle
- ▸ 85 % des décideurs IT veulent tracer leurs LLM en interne
- ▸ L'IA fait grossir les équipes plutôt qu'elle ne les taille
Déployer un modèle génératif ne suffit pas : sans données exploitables en amont, le projet s’effondre avant la mise à l’échelle. Gartner chiffre l’ardoise à trois projets sur cinq abandonnés d’ici 2026. Ce dossier décompose les quatre briques architecturales qui séparent un pilote qui tourne d’un système qui tient en production — et pourquoi la vraie contrainte n’est ni le modèle ni le GPU, mais la couche qui les alimente.
Ce qu’il faut retenir 1. Gartner prévoit l’abandon de 60 % des projets IA d’ici 2026 faute de données prêtes à l’emploi — l’équivalent de trois initiatives sur cinq stoppées avant le passage en production. 2. Dans le rapport 2026 d’Elastic, 85 % des décideurs IT comptent activer l’observabilité de leurs LLM internes : la traçabilité passe de confort à condition d’exploitation. 3. Près de 70 % des cadres interrogés par Deloitte en 2025 prévoient d’agrandir leurs équipes en réponse à l’IA générative, à rebours des annonces de coupes. 4. Quatre éléments structurent une architecture qui dure : la qualité des données, l’ingénierie du contexte, la gouvernance-observabilité et l’expertise humaine. 5. Ces fondations doivent absorber la bascule vers les systèmes agentiques sans être reconstruites à chaque génération de modèle.
L’IA ne répare pas les données qu’elle consomme
Une idée fausse circule dans les directions techniques : puisque les modèles génératifs comprennent le langage naturel, ils s’accommoderaient de n’importe quelle base. La réalité de terrain dit l’inverse. Un modèle amplifie la qualité de ce qu’on lui donne, il ne la corrige pas. Des données fragmentées, périmées ou incohérentes produisent des réponses fragmentées, périmées ou incohérentes — à grande échelle et avec l’aplomb d’un système qui a l’air sûr de lui.
Le chiffre qui cadre l’enjeu vient de Gartner : d’ici 2026, 60 % des projets IA non adossés à des données prêtes à l’emploi seront abandonnés, selon l’analyse relayée par MIT Technology Review. Trois projets sur cinq. Le taux ne mesure pas l’échec des modèles ; il mesure l’échec des infrastructures qui les précèdent. La cause de mortalité se loge en amont du prompt, dans les entrepôts de données que personne n’a nettoyés avant de brancher un LLM dessus.
Adnan Adil, directeur des systèmes d’information d’Elastic, formule la dépendance sans détour : « The data is a durable part of AI architecture because without it, these models won’t run, won’t provide the right context, or won’t give the right level of services that we’re looking to implement » (source). Traduction opérationnelle : la donnée n’est pas un consommable qu’on renouvelle à chaque projet, c’est la partie durable de l’architecture, celle qui survit au remplacement du modèle sous-jacent.
Le point mérite qu’on s’y arrête, parce qu’il inverse la priorité budgétaire habituelle. Les organisations investissent d’abord dans l’accès aux modèles les plus performants, puis découvrent que le goulot d’étranglement est ailleurs. Notre lecture : la qualité des données héritées, les schémas incohérents entre systèmes et l’absence de format lisible par machine constituent le vrai plafond de verre. Tant qu’il n’est pas traité, changer de modèle revient à repeindre une façade sur des fondations fissurées. Les enjeux de gouvernance des données en entreprise précèdent, dans l’ordre logique, toute discussion sur le choix du modèle.
Quatre briques qui survivent au remplacement du modèle
Passer d’un pilote qui impressionne en démonstration à un système qui tient en production suppose de distinguer ce qui change vite de ce qui doit rester stable. Les modèles se remplacent tous les six mois. L’architecture, elle, doit encaisser ces rotations sans être reconstruite. Quatre éléments composent cette assise, d’après le cadre décrit par MIT Technology Review.
Premier élément, la qualité des données. Elle conditionne tout le reste et se mesure à la confiance qu’elle génère. Adnan Adil le résume : « The data quality has to be good; otherwise, the user loses confidence in the system. » Un utilisateur qui reçoit une mauvaise réponse une fois se méfie ; deux fois, il déserte l’outil. La confiance est un capital qui se dépense vite et se reconstitue lentement.
Deuxième élément, l’ingénierie du contexte. Le terme désigne la discipline consistant à fournir au modèle exactement les informations utiles à sa tâche, ni plus ni moins. Le principe tient en une phrase relevée dans le rapport : « Minimum context, correct and current data, and machine-readable information are critical to effective context engineering. » Trois exigences y sont empilées — contexte minimal, données correctes et actuelles, format lisible par machine. Un excès de contexte noie le signal ; un déficit provoque l’hallucination. L’ajustement est un travail d’ingénieur, pas un réglage cosmétique.
Troisième élément, la gouvernance et l’observabilité — la capacité à surveiller ce que le système fait réellement une fois en service. Quatrième élément, l’expertise humaine, sur laquelle nous revenons plus loin. Le tableau ci-dessous récapitule le rôle de chaque brique et le coût de sa négligence.
| Brique architecturale | Fonction | Ce qui casse si on la néglige |
|---|---|---|
| Données prêtes à l’emploi | Alimenter le modèle en information fiable et à jour | Abandon du projet — Gartner chiffre le risque à 60 % d’ici 2026 |
| Ingénierie du contexte | Cadrer précisément l’information transmise au modèle | Hallucinations, réponses hors-sujet, perte de pertinence |
| Gouvernance / observabilité | Tracer coûts, décisions et comportements en production | Dérive silencieuse, coûts incontrôlés, perte de confiance |
| Expertise humaine | Concevoir, superviser, corriger et faire monter en charge | Déploiements bloqués, absence de montée en compétence |
Ce qui unit ces quatre briques : aucune ne dépend du modèle du moment. Une base de données propre reste propre que l’on branche dessus la génération de LLM de 2025 ou celle de 2027. C’est précisément ce qui les rend « durables » au sens d’Adnan Adil. Investir dans le modèle, c’est louer ; investir dans ces fondations, c’est capitaliser. La distinction éclaire pourquoi tant de pilotes IA ne franchissent jamais le cap de la production : ils reposent sur la couche louée et ignorent la couche capitalisable.
85 % des décideurs IT veulent tracer leurs LLM en interne
La troisième brique — l’observabilité — mérite un traitement à part, parce qu’elle est en train de basculer du statut d’option à celui de prérequis. Dans son rapport 2026, Elastic mesure que 85 % des décideurs IT prévoient d’activer l’observabilité des LLM pour leurs applications génératives internes (source). Ce n’est plus une frange d’avant-gardistes : c’est la quasi-totalité des responsables interrogés.
Observer un LLM ne consiste pas à vérifier qu’il répond. Il s’agit de savoir combien chaque requête coûte, quelles décisions le système prend, où il dérive et pourquoi. Un modèle génératif est une boîte dont le comportement varie selon le contexte fourni ; sans instrumentation, l’entreprise pilote à l’aveugle un composant qui facture au token et se trompe sans prévenir.
Le chiffre-phare : 85 %. Près de neuf décideurs IT sur dix font de l’observabilité des LLM une brique de leur architecture 2026. La surveillance quitte le registre du confort technique pour celui de la condition d’exploitation.
La valeur de cette instrumentation dépasse le contrôle. Le rapport la présente comme un levier à trois usages : « Observability is actually huge. We can use observability data for cost control, decision-making, and engineering efficiency. » Trois bénéfices distincts dans une seule phrase. Contrôle des coûts d’abord — savoir quelle fonctionnalité consomme quels volumes. Aide à la décision ensuite — arbitrer sur des données réelles plutôt que sur des impressions. Efficacité d’ingénierie enfin — repérer où le système gaspille avant que la facture ne l’annonce.
Rapprochons les deux chiffres du dossier. D’un côté, 60 % de projets qui meurent faute de données saines ; de l’autre, 85 % de décideurs qui veulent instrumenter leurs modèles. La convergence n’est pas fortuite : on n’améliore que ce qu’on mesure. L’observabilité est l’outil qui rend visible la dégradation de la qualité des données avant qu’elle ne fasse fuir les utilisateurs. Les deux briques se répondent — la première prévient l’échec, la seconde le détecte à temps. Une architecture qui adopte l’une sans l’autre reste borgne.
L’IA fait grossir les équipes plutôt qu’elle ne les taille
Le récit dominant associe déploiement d’IA et réduction d’effectifs. Les données de terrain racontent une autre histoire. Près de 70 % des répondants à l’enquête Deloitte 2025 auprès de cadres technologiques prévoient d’agrandir leurs équipes en réponse directe à l’IA générative (source). Sept dirigeants sur dix recrutent à cause de l’IA, pas malgré elle — un contraste net avec les annonces de coupes largement médiatisées.
Le paradoxe se dissout dès qu’on regarde ce que réclame une architecture solide. Nettoyer des données, concevoir l’ingénierie du contexte, instrumenter l’observabilité, superviser les sorties : chacune de ces tâches demande des compétences humaines rares. Le modèle exécute ; l’humain conçoit le système autour du modèle et le tient en état de marche. Plus le déploiement est ambitieux, plus cette couche d’expertise s’épaissit.
Le rapport assume cette lecture : « We think the people aspect is largely what’s going to make AI impactful going forward. » L’impact ne viendrait donc pas du modèle seul mais de l’organisation humaine qui l’entoure. La promesse formulée porte sur la vitesse d’exécution — « We fundamentally believe that with these tools, velocity of work will get much faster » — et sur la nature même du travail : « We are really focused on how we can do work with these tools in ways we had not thought of before. » Accélérer l’existant d’un côté, inventer des façons de travailler inédites de l’autre : deux registres qui supposent des équipes plus étoffées, pas plus maigres. La question des compétences à recruter pour industrialiser l’IA devient centrale dès qu’on quitte le stade du pilote.
Le vrai test arrive avec les systèmes agentiques
Ces quatre briques ne sont pas un aboutissement mais un socle, et le socle va être éprouvé. La bascule en cours vers les systèmes agentiques — des modèles qui enchaînent des actions de façon autonome plutôt que de répondre à une requête isolée — multiplie chacune des exigences décrites plus haut. Un agent qui déclenche une suite d’opérations sans supervision humaine à chaque étape amplifie tout : la moindre donnée périmée se propage sur plusieurs actions, le moindre défaut de contexte se répercute en cascade, et l’observabilité cesse d’être un tableau de bord pour devenir un garde-fou.
C’est là que se joue la différence entre les organisations qui auront investi dans les fondations et celles qui auront couru après le dernier modèle. Une architecture bâtie autour de données propres, d’un contexte maîtrisé, d’une observabilité systématique et d’équipes compétentes encaisse la transition agentique sans rupture. Une architecture qui a fait l’impasse sur ces briques devra les reconstruire sous pression, en production, avec des agents déjà en train de multiplier les erreurs.
Il faut nuancer l’optimisme du rapport, qui émane d’un éditeur — Elastic — dont le métier est précisément l’observabilité et la donnée. La perspective n’est pas neutre : présenter la donnée et la traçabilité comme les briques décisives sert aussi son offre. Cela n’invalide pas les chiffres, indépendamment sourcés chez Gartner et Deloitte, mais invite à lire le cadre pour ce qu’il est — une thèse cohérente et défendable, pas une vérité désintéressée. Reste que la statistique de Gartner, elle, ne dépend d’aucun vendeur : 60 % d’abandon est un constat de marché, pas un argument commercial.
L’enseignement pratique pour une direction technique tient en une inversion de séquence. Avant de comparer les modèles, avant de négocier des capacités de calcul, auditer l’état réel de ses données et sa capacité à les instrumenter. Le projet IA qui échoue rarement échoue par manque de puissance de calcul ; il échoue parce que la couche en dessous n’était pas prête. Les quatre briques ne garantissent pas le succès — elles évitent d’entrer dans la statistique des 60 %.
Questions fréquentes
Qu’est-ce que l’ingénierie du contexte dans une architecture IA ?
C’est la discipline consistant à fournir au modèle exactement l’information utile à sa tâche. Le rapport 2026 d’Elastic en pose trois conditions : un contexte minimal, des données correctes et actuelles, et un format lisible par machine. Trop de contexte noie le signal ; trop peu déclenche l’hallucination. L’objectif est le cadrage précis de ce que le modèle reçoit.
Quels sont les principaux freins aux projets d’IA en entreprise ?
Selon les sources disponibles à ce jour, le premier frein n’est ni le modèle ni le calcul, mais la donnée : qualité insuffisante des bases héritées, schémas incohérents entre systèmes, absence de gouvernance claire. Gartner en tire une projection nette — 60 % des projets non adossés à des données prêtes à l’emploi seront abandonnés d’ici 2026, faute d’avoir traité ce socle en amont.
Faut-il craindre que l’IA réduise les effectifs IT ?
Les données Deloitte 2025 pointent l’inverse pour l’instant : près de 70 % des cadres technologiques interrogés prévoient d’agrandir leurs équipes en réponse à l’IA générative. Concevoir, superviser et instrumenter ces systèmes demande des compétences que le modèle n’apporte pas de lui-même.
Sources – MIT Technology Review, The foundational elements of AI architecture that IT leaders need to scale, 7 juillet 2026 — technologyreview.com (données Gartner, rapport Elastic 2026, enquête Deloitte 2025, citations d’Adnan Adil, CIO d’Elastic).
