CrateDB veut faire passer les données industrielles de la minute à la milliseconde

Une intelligence artificielle ne vaut que par les informations qu’elle peut mobiliser. Dans une usine, attendre plusieurs minutes avant de détecter une anomalie sur une machine, de retrouver une procédure de réparation ou d’actualiser une prévision peut suffire à rendre un système beaucoup moins utile. C’est sur ce délai, souvent discret mais décisif, que CrateDB entend se différencier : rapprocher les données produites sur le terrain des outils d’analyse et des applications d’IA, avec une latence mesurée en millisecondes plutôt qu’en minutes.

La promesse doit être lue pour ce qu’elle est : celle d’un éditeur d’infrastructure de données qui cherche à répondre à une difficulté désormais centrale pour les entreprises. L’IA générative, les assistants internes et les modèles de prédiction ont besoin de données nombreuses, variées et surtout suffisamment fraîches. Or, beaucoup d’organisations disposent encore de systèmes où les données sont déplacées, transformées et chargées à intervalles réguliers. Ce fonctionnement est robuste pour de nombreux usages, mais il n’est pas toujours adapté à une décision immédiate.

Pourquoi la vitesse des données devient-elle un sujet d’IA ?

Pendant longtemps, les entreprises ont principalement utilisé leurs données pour dresser des bilans : chiffre d’affaires de la veille, niveau des stocks à la fin de la journée, alertes consolidées chaque heure. Les traitements dits « par lots » rassemblent les données à un moment donné, puis les analysent ensemble. Cette méthode reste pertinente pour la comptabilité, le reporting ou des calculs lourds qui ne demandent pas de réponse instantanée.

Les usages d’IA modifient toutefois l’équation. Un système de maintenance prédictive, par exemple, gagne en intérêt s’il reçoit les mesures de température, de vibration ou de consommation d’une machine au fil de l’eau. Un assistant destiné à un technicien doit aussi pouvoir associer un message d’erreur récent à la bonne documentation, sans s’appuyer sur un état des équipements devenu obsolète.

Le défi ne se limite donc pas au volume. Les directeurs des systèmes d’information doivent faire évoluer leurs infrastructures selon trois critères liés : la capacité à absorber davantage de données, la rapidité avec laquelle ces données sont disponibles, et l’efficacité des requêtes qui les interrogent. Comme le relève un article de CIO.com évoqué par CrateDB, augmenter simplement la taille des systèmes ne suffira pas à couvrir les besoins futurs de l’IA.

CrateDB se présente dans ce contexte comme une couche de données unifiée pour l’analyse, la recherche et l’IA. L’idée est de réduire le nombre de passages entre des outils distincts. Plus une donnée traverse de copies, de connecteurs et de traitements différés, plus le risque augmente de la consulter avec retard ou dans une version incomplète.

Des pipelines par lots aux requêtes quasi immédiates

La plupart des systèmes d’information utilisent des pipelines asynchrones. Concrètement, une application enregistre des événements, un processus les récupère ultérieurement, les prépare, puis les transmet à un entrepôt ou à un outil d’analyse. Cette architecture peut très bien fonctionner, mais elle introduit un décalage temporel entre la production d’une information et son exploitation.

Stéphane Castellani, vice-président marketing de CrateDB, estime que la priorité consiste désormais à réduire ce délai. Selon lui, la plateforme peut donner accès à des données pertinentes en quelques millisecondes, y compris dans des environnements où les données sont complexes et volumineuses. Il évoque une réduction des temps de requête allant de plusieurs minutes à quelques millisecondes.

Une telle formulation ne signifie pas que chaque traitement d’IA s’exécutera en quelques millisecondes. Le temps de réponse final dépend aussi du réseau, de la complexité de la requête, de la préparation des données et, dans le cas d’un grand modèle de langage, du temps nécessaire au modèle pour générer sa réponse. La contribution revendiquée par CrateDB porte plus précisément sur l’accès et l’agrégation des données utiles.

Cette différence a une conséquence pratique : une IA ne doit pas seulement répondre correctement, elle doit répondre à partir d’une situation qui correspond encore à la réalité. Dans des cas d’usage peu sensibles au temps, quelques heures de décalage ne sont pas un problème. Pour la supervision d’équipements, la détection d’incidents ou l’assistance aux équipes de terrain, le contexte doit être actualisé beaucoup plus vite.

Le processus en quatre étapes défendu par CrateDB

CrateDB décrit son rôle comme un « tissu connectif » entre les données opérationnelles et les systèmes d’IA. Derrière cette expression se trouve un enchaînement en quatre étapes : l’ingestion, l’agrégation, l’alimentation des pipelines d’IA et l’activation de boucles de rétroaction entre les modèles et les données.

La première consiste à accueillir les événements à mesure qu’ils sont produits. Dans l’industrie, il peut s’agir de télémétrie provenant de machines. Le terme désigne les mesures remontées automatiquement par des équipements : état de fonctionnement, capteurs, alertes ou paramètres techniques.

La deuxième étape est l’agrégation en temps réel. Plutôt que d’examiner isolément chaque mesure, le système doit pouvoir calculer rapidement une tendance, comparer une valeur à un seuil ou rapprocher plusieurs signaux. Cette phase est essentielle pour faire émerger une information utilisable, par exemple une dérive progressive dans le comportement d’une machine.

Vient ensuite la fourniture des données aux pipelines d’IA. Un pipeline est la chaîne qui prépare et transporte les informations nécessaires à un modèle ou à une application. Pour un assistant conversationnel, cela peut signifier retrouver les éléments pertinents avant de formuler une réponse. Pour un modèle prédictif, il s’agit de transmettre les variables dont il a besoin pour produire une estimation.

Enfin, les boucles de rétroaction visent à faire circuler les résultats dans l’autre sens. Une alerte produite par un modèle, une intervention réalisée par un technicien ou une nouvelle mesure d’équipement peuvent enrichir le système. Cette circulation ne rend pas automatiquement un modèle meilleur : elle doit être encadrée, vérifiée et adaptée à chaque usage. Mais elle peut contribuer à réduire le fossé entre un modèle théorique et la réalité du terrain.

L’usine, un terrain d’application concret

Le secteur manufacturier illustre clairement l’intérêt d’un accès rapide aux données. Les équipements industriels génèrent en continu des signaux qui peuvent alimenter des modèles de maintenance prédictive. L’objectif est d’identifier des indices de défaillance avant une panne, afin de planifier une intervention et de réduire les arrêts non prévus.

CrateDB met également en avant un scénario d’assistance au personnel. Lorsqu’une machine génère un code ou un message d’erreur précis, un opérateur pourrait interroger un assistant virtuel. Celui-ci chercherait alors les manuels et les instructions liés au problème rencontré afin de guider le diagnostic. La qualité de cette réponse dépend de plusieurs éléments : l’accès aux documents adéquats, la compréhension du contexte et la fraîcheur des données sur l’état de la machine.

Cette application ne consiste pas à laisser une IA décider seule d’une réparation. Dans un environnement industriel, les procédures de sécurité, les compétences humaines et les règles de validation restent indispensables. L’assistant peut en revanche diminuer le temps passé à retrouver une notice, à identifier une référence technique ou à rassembler les informations nécessaires avant une intervention.

Selon les recherches de PYMNTS Intelligence citées dans le contexte de cette annonce, l’industrie manufacturière, incluse dans le secteur des biens et services, accuse un retard dans l’adoption de certains usages. CrateDB estime que les organisations cherchent désormais à construire des flux de travail d’IA plus autonomes, même si leur forme précise évolue encore rapidement.

Que change le protocole MCP pour les grands modèles de langage ?

Le Model Context Protocol, ou MCP, cherche à standardiser la manière dont les applications fournissent du contexte aux grands modèles de langage. Dit simplement, un modèle de langage ne peut pas connaître spontanément les données internes, les capteurs d’une usine ou les documents techniques récents d’une entreprise. Il a besoin d’un mécanisme contrôlé pour demander les bonnes informations à des outils externes.

Stéphane Castellani compare cette évolution à l’essor des API d’entreprise, amorcé selon lui il y a une douzaine d’années. Une API est une interface qui permet à des logiciels de communiquer selon des règles définies. Le MCP applique une logique comparable aux interactions entre outils et modèles de langage : au lieu de connecter chaque assistant à chaque source de données de façon particulière, le protocole cherche à établir un langage commun.

Le serveur MCP de CrateDB, alors encore expérimental, doit jouer le rôle de pont entre les outils d’IA et les bases de données analytiques. Pour le dirigeant, « nous appliquons la même approche qu’avec les API, mais pour les LLM ». L’intérêt potentiel est de permettre à un assistant d’interroger les données autorisées plus simplement, tout en évitant de construire une intégration spécifique pour chaque usage.

Le protocole ne dispense cependant pas d’une gouvernance sérieuse. Donner un accès à des données via un assistant soulève des questions de droits d’accès, de confidentialité, de traçabilité des requêtes et de vérification des réponses. La rapidité d’une base de données ne doit jamais conduire à fournir à un utilisateur ou à un modèle des informations auxquelles il ne devrait pas accéder.

Partenariat industriel et démonstrations européennes

CrateDB travaille avec Tech Mahindra afin d’apporter des solutions d’IA autonome dans l’automobile, l’industrie manufacturière et les usines intelligentes. Ce partenariat s’inscrit dans une stratégie centrée, selon Stéphane Castellani, sur la performance, l’évolutivité et l’investissement dans l’ingestion de données issues d’un nombre croissant de sources.

L’entreprise entend notamment réduire la latence à deux niveaux : lorsque les données entrent dans le système, puis lorsqu’elles sont interrogées. Cette distinction est importante. Une requête très rapide ne suffit pas si les dernières données mettent longtemps à parvenir à la plateforme. Inversement, une ingestion immédiate perd de son intérêt si l’analyse ne peut pas suivre.

Stéphane Castellani doit présenter ces usages à l’AI & Big Data Expo Europe, lors d’une intervention intitulée « Apporter l’IA aux données en temps réel, Text2SQL, RAG et TAG avec CrateDB ». Il doit aussi intervenir à l’IoT Tech Expo Europe sur l’amélioration des opérations IoT, avec des exemples liés à l’analyse de parcs éoliens en temps réel et aux diagnostics guidés par l’IA.

Text2SQL désigne la transformation d’une demande exprimée en langage courant en requête de base de données. Le RAG, pour retrieval-augmented generation, consiste à récupérer des informations pertinentes avant qu’un modèle de langage rédige sa réponse. Ces approches peuvent rendre des données opérationnelles plus faciles à interroger, à condition que les résultats soient vérifiables et que le périmètre d’accès soit correctement défini.

Ce qu’il faut surveiller

La course à l’IA d’entreprise ne se joue pas uniquement dans les modèles de langage. Elle se joue aussi dans les couches invisibles qui rendent les données disponibles, fiables et sécurisées. CrateDB défend une réponse fondée sur le temps réel et sur une plateforme unifiée, avec une cible particulièrement nette : les environnements industriels où les événements se succèdent sans interruption.

Les promesses de requêtes ramenées de plusieurs minutes à quelques millisecondes devront naturellement être évaluées au regard de chaque déploiement : type de données, architecture existante, nombre de sources connectées, contraintes de sécurité et charge réelle. Une infrastructure performante ne garantit pas à elle seule la pertinence d’un modèle d’IA, mais elle peut enlever un obstacle majeur : celui d’une IA qui répondrait vite à une situation déjà dépassée.

L’adoption du MCP sera également un point à suivre. S’il s’impose comme un standard de connexion entre applications et grands modèles de langage, il pourrait simplifier la création d’assistants capables de travailler avec des données d’entreprise. Le bénéfice dépendra alors autant de la qualité des garde-fous que de la vitesse technique : dans l’usine comme ailleurs, une réponse instantanée n’a de valeur que si elle est fondée sur les bonnes données et adressée à la bonne personne.