Par Andrew Tan
Pourquoi 85 % des entreprises ne sont pas prêtes pour l'IA
Le benchmark 2026 de Fivetran a révélé que 85 % des entreprises utilisant l'IA agentique fonctionnent sur une infrastructure qui n'est pas prête. Le modèle n'est pas le problème. Les data pipelines qui l'alimentent le sont.
Voici un schéma qui apparaît dans un nombre croissant d'endroits :
Une entreprise passe six mois à évaluer les LLM : elle effectue des benchmarks, négocie des contrats, construit une preuve de concept. Le modèle semble excellent. Puis elle le déploie en production et les agents commencent à halluciner de manière totalement indépendante du modèle.
L'IA va bien, mais les données qui l'alimentent ne vont pas.
C'est ce que le rapport Enterprise Data Infrastructure Benchmark 2026 de Fivetran mesure réellement lorsqu'il dit que 85 % des entreprises ne sont pas prêtes pour l'IA agentique. Ce n'est pas que leurs modèles sont erronés, mais que leurs pipelines le sont.
Ce que "pas prêt" signifie réellement
L'expression "infrastructure prête pour l'IA" est souvent utilisée pour vendre beaucoup de choses. Elle signifie généralement quelque chose de vague sur la scalabilité Cloud. Ce n'est pas ce que le rapport de Fivetran mesure.
Les trois problèmes concrets qu'ils ont identifiés :
Données obsolètes. L'agent raisonne sur l'état d'hier. Pour un agent de service client, cela signifie qu'il ne sait pas qu'un remboursement a déjà été émis. Pour un agent de détection de fraude, il travaille à partir de schémas vieux de 18 heures. Les pipelines par lots fonctionnant toutes les heures ou toutes les nuits ne peuvent pas soutenir des agents qui doivent agir sur ce qui se passe maintenant.
Pas de respect du schéma. Les systèmes sources changent constamment. Les colonnes sont renommées, les types sont élargis, de nouveaux champs apparaissent. Si votre pipeline n'applique pas de contrats de schéma en aval, un agent peut recevoir des données mal formées qui semblent valides — et agir en toute confiance sur celles-ci.
Pas d'observabilité. La plupart des surveillances de pipeline vous indiquent si un travail a été exécuté. Elles ne vous disent pas si les données sont correctes. Un agent peut consommer des données d'un pipeline qui fonctionne techniquement mais qui laisse silencieusement tomber 20 % des événements. Vous ne le saurez pas avant que quelqu'un ne remarque que l'agent agit étrangement, et à ce moment-là, le mal est fait.
Ce ne sont pas de nouveaux problèmes. Ce sont les mêmes problèmes de qualité des données qui ont tourmenté les équipes d'analytique pendant des années. Ce qui a changé, c'est le rayon d'impact. Un problème de qualité des données dans un tableau de bord BI est un mauvais graphique. Un problème de qualité des données dans un système agentique est une décision autonome prise sur de mauvaises informations.
L'inadéquation de la pile
Le problème de la pile de données prête pour l'IA est une inadéquation profonde dans les hypothèses d'architecture.
La plupart des piles de données d'entreprise ont été construites autour du traitement par lots. Travaux ETL nocturnes. Rafraîchissements quotidiens des entrepôts. Tableaux de bord qui se mettent à jour chaque matin. Tout le système était optimisé pour le throughput plutôt que pour la fraîcheur.
Les agents IA ont des exigences différentes. Ils ont besoin de données à jour, pas seulement précises. Ils doivent agir sur ce qui se passe dans les dernières secondes ou minutes, pas les dernières douze heures. Et quand ils se trompent, ils ont besoin que le système le détecte — pas seulement qu'il le consigne et passe à autre chose.
Les entreprises qui sont prêtes — les 15 % — n'ont pas nécessairement remplacé toute leur pile. La plupart d'entre elles sont passées au temps réel là où c'est important et ont gardé le traitement par lots là où cela a du sens. Le flux de commandes clients fonctionne en temps réel. La comptabilité des coûts trimestrielle fonctionne toujours la nuit. La différence est l'intentionnalité : elles ont pris des décisions explicites sur les données qui nécessitent de la fraîcheur et ont construit des pipelines en conséquence.
Les trois propriétés qui comptent vraiment
Il y a beaucoup de bruit sur ce que l'infrastructure "prête pour l'IA" nécessite. C'est généralement une liste de contrôle d'un fournisseur qui correspond commodément à son produit. Voici donc la version qui correspond aux modes de défaillance réels :
Fraîcheur. Pas seulement "temps réel pour tout" — c'est coûteux et souvent inutile. Mais pour les données sur lesquelles vos agents agissent réellement, vous devez connaître le décalage et avoir des garanties à ce sujet. Si vos données client ont 4 minutes de retard, très bien — tant que votre agent le sait et agit en conséquence. Ce qui casse les agents, c'est quand ils supposent que les données sont à jour et qu'elles ne le sont pas.
Cohérence. Les agents combinent souvent des données de plusieurs sources pour prendre une décision. Si ces sources fonctionnent à des horaires différents ou à des niveaux de fraîcheur différents, vous obtenez des incohérences subtiles difficiles à déboguer. Une recherche client indique que le compte est actif ; le flux de transactions n'a pas encore rattrapé son retard et le montre comme en attente de clôture. L'agent prend une décision qui est correcte pour chaque source individuellement mais erronée pour l'état combiné.
Observabilité au niveau de l'événement. La surveillance des pipelines vous informe sur les travaux. La fiabilité des agents nécessite la surveillance des événements individuels. Les événements sont-ils traités ou abandonnés ? Le schéma correspond-il à ce que l'agent attend ? Y a-t-il des pics qui submergent les consommateurs en aval ? C'est une classe de surveillance différente de celle que la plupart des équipes ont construite.
Ce que cela signifie pour la décision de construire ou d'acheter
La vague de l'IA met en lumière une facture qui s'est accumulée dans de nombreuses organisations d'ingénierie : le coût de traiter l'infrastructure de données comme un problème résolu.
Les équipes qui ont construit des pipelines par lots personnalisés il y a deux ans et ont considéré cela comme terminé font maintenant face à un choix difficile : adapter le temps réel à un système qui n'a pas été conçu pour cela, ou reconstruire. Aucune option n'est bon marché. L'adaptation tend à produire le problème des deux pipelines — un système par lots pour l'historique, un système de streaming pour le temps réel, deux bases de code faisant à peu près la même chose avec une logique légèrement différente et des résultats perpétuellement divergents.
Les équipes qui gèrent bien cela sont celles qui n'ont pas à faire ce choix. Lorsque le batch et le streaming fonctionnent comme les mêmes pipelines avec les mêmes outils, passer un Workflow d'une exécution horaire à temps réel est un changement de configuration, pas une réécriture. L'observabilité, le respect du schéma, la gestion des échecs — cela vient avec la plateforme, pas comme une construction personnalisée par-dessus.
C'est ce sur quoi layline.io est construit. Pas seulement le temps réel pour lui-même, mais la capacité de prendre des décisions explicites et intentionnelles sur la fraîcheur des données à travers la pile — sans maintenir deux systèmes séparés pour y parvenir.
La question à méditer
Le chiffre de 85 % est frappant. Mais la question plus intéressante est : combien de ces entreprises savent qu'elles font partie de ces 85 % ?
Les équipes qui sont en difficulté ne sont généralement pas celles avec des pipelines manifestement cassés. Ce sont celles avec des pipelines qui semblent fonctionner — travaux en cours, tableaux de bord chargés, aucun incident actif — mais avec des problèmes de fiabilité silencieux qui ne se manifestent que lorsqu'un agent IA commence à prendre des décisions conséquentes sur les données.
Si vos agents agissent étrangement et que vous avez déjà écarté le modèle, examinez les données.
Andrew Tan est un entrepreneur en série et fondateur de layline.io, construisant une infrastructure de traitement de données d'entreprise qui gère à la fois les charges de travail par lots et en temps réel à grande échelle.
