IBM et Confluent ont intégré directement les modèles Granite Time Series dans Confluent Cloud pour réaliser des prévisions et détecter des anomalies sur des données en circulation. Cette solution évite le transfert préalable de séries temporelles vers une autre plateforme d’apprentissage automatique et permet d’invoquer les modèles via SQL dans Apache Flink. La technologie est actuellement en Early Access, débutant sur Confluent Cloud sur AWS.

Les points clés de Granite Time Series sur Confluent en 30 secondes

• IBM et Confluent amènent directement des modèles de séries temporelles au traitement des flux de données en continu.
• Les fonctions AI_FORECAST et AI_DETECT_ANOMALIES permettent d’utiliser ces modèles depuis Flink SQL.
• La première version comprend quatre modèles IBM entre 1 et 260 millions de paramètres, conçus pour fonctionner sans GPU.
• Les résultats peuvent être renvoyés vers Kafka pour alimenter alertes, applications, data lakehouses ou agents IA.
• En Early Access : il ne faut pas encore considérer cette fonctionnalité comme un service garantissant une disponibilité totale.

Cette annonce présente surtout une dimension architecturale intéressante plutôt qu’une simple intégration d’autres modèles d’intelligence artificielle en cloud. IBM et Confluent cherchent à rapprocher l’inférence du lieu où se produisent les événements, en réduisant le parcours habituel entre la génération du donnée, son stockage, l’analyse et la prise de décision.

Cela peut s’avérer crucial dans des systèmes où quelques minutes de retard peuvent changer la pertinence d’une prédiction : transactions financières, télémesure industrielle, gestion des stocks, performance des applications, trafic réseau ou capteurs.

Mais il convient de relativiser certaines affirmations accompagnant l’annonce. L’intégration ne garantit pas que toute entreprise résoudra ses problèmes « en quelques secondes » ni ne prouve que streamhouse et lakehouse sont toujours comparables ou que l’une est systématiquement moins chère que l’autre. La nouveauté essentielle réside dans le fait que certaines opérations d’inférence sur séries temporelles peuvent désormais s’exécuter directement dans le flux géré par Confluent.

Passer du stockage puis analyse à une IA en flux

De nombreuses architectures analytiques suivent encore un schéma connu :

Un dispositif, capteur ou système d’entreprise génère des événements. Ces données transitent vers un système intermédiaire, qui les stocke dans un entrepôt de données, un lake ou un lakehouse, puis un autre processus entraîne des modèles, réalise des inférences ou génère des rapports à partir de là.

Ce schéma est souvent pertinent pour de nombreuses charges de travail.

Le problème survient lorsque la valeur des données diminue rapidement avec le temps.

Une anomalie de température sur une machine industrielle doit être détectée tant qu’il est encore possible d’agir. Une transaction potentiellement frauduleuse est plus utile si l’on la repère avant qu’elle ne soit finalisée. Une hausse inattendue de latence doit être détectée en temps réel, pas dans le rapport journalier.

La coopération entre IBM et Confluent vise à réduire ce décalage.

Confluent fournit le flux continu d’événements, et Apache Flink réalise le traitement. Les modèles Granite Time Series peuvent ainsi fournir prédictions ou détecter des anomalies sans déployer auparavant un service dédié à model serving.

Les résultats ne s’arrêtent pas là :

Ils peuvent être réécrits dans des topics Apache Kafka, où d’autres consommateurs peuvent les exploiter : systèmes d’alertes, tableaux de bord, applications, entrepôts analytiques ou agents IA.

Cela fait de l’inférence une étape supplémentaire dans le pipeline événementiel.

Deux fonctions SQL simplifient beaucoup la complexité

Le choix de l’interface est une décision stratégique intéressante :

Confluent expose ces modèles via deux fonctions dans Flink SQL :

AI_FORECAST pour faire des prévisions et AI_DETECT_ANOMALIES pour repérer des écarts par rapport aux comportements attendus.

Par exemple, une série de métriques CPU peut alimenter AI_FORECAST. La fonction prend la valeur, la marque temporelle et différents paramètres, pour retourner plusieurs valeurs futures et des quantiles qui reflètent l’incertitude.

La détection d’anomalies fonctionne de façon similaire. AI_DETECT_ANOMALIES compare les valeurs observées aux bandes de prédiction et retourne des informations telles que la valeur réelle, la prévision, les limites inférieure et supérieure, et un indicateur pour signaler si l’observation est anormale.

Cela ne transforme pas totalement l’apprentissage automatique en simples commandes magiques.

La qualité des données, leur fréquence, le contexte temporel, les seuils de confiance et surtout la décision finale restent essentiels.

Une alerte fausse peut être simplement gênante. Une inférence automatique pour bloquer un paiement, ajuster un processus industriel ou ajuster un prix doit faire l’objet de contrôles rigoureux.

La simplification réside dans la manière dont on consomme le modèle, pas dans la disparition des défis liés aux modèles prédictifs.

Quatre petits modèles, pas besoin de GPU

Un autre aspect différenciant de la discussion actuelle sur l’IA concerne la taille.

IBM et Confluent ont sélectionné initialement quatre modèles Granite Time Series : PatchTST-FM-r1, FlowState-r1.1, TTM-r3 et TSPulse.

Ils n’ont pas tous la même orientation précise :

Ces quatre modèles comptent entre 1 et 260 millions de paramètres et sont conçus pour fonctionner sans GPU. TTM-r3, par exemple, vise à traiter de nombreuses séries à faible coût en utilisant uniquement le CPU.

Une approche très différente de l’utilisation d’un large modèle de langage pour analyser toute sorte de signal.

Une série temporelle a des caractéristiques propres : ordre chronologique, périodicité, tendance, saisonnalité et relations entre observations successives. Un modèle spécialisé et relativement léger peut suffire pour certains défis sans nécessiter des milliards de paramètres.

Ce point est important aussi en termes d’infrastructure :

L’inférence sur des données opérationnelles peut générer un volume énorme. Si chaque capteur, serveur, transaction ou produit nécessite une prédiction en continu, le coût par inférence devient aussi crucial que la précision du modèle.

Éviter l’usage de GPU facilite également leur intégration dans des pipelines traitant un grand nombre d’événements.

Les données peuvent rester dans Confluent Cloud

Une autre implication technique mérite d’être soulignée :

Les modèles utilisés par AI_FORECAST et AI_DETECT_ANOMALIES sont gérés par Confluent et hébergés directement dans Confluent Cloud. La documentation indique que ces fonctions ne permettent pas actuellement d’utiliser des modèles distants d’autres fournisseurs ni des modèles gérés directement par le client.

Cela simplifie certaines parties de l’infrastructure :

Il n’est pas nécessaire d’envoyer chaque événement vers un endpoint externe d’inférence, de gérer des crédentials additionnels ou de déployer un autre service pour héberger le modèle.

IBM et Confluent soutiennent que cette approche peut réduire l’infrastructure dédiée et éviter certains coûts d’entrée/sortie des données. Elle permet également aux inférences de respecter les politiques en matière de schémas, de traçabilité et de contrôle d’accès existantes dans la plateforme.

Kafka offre aussi un avantage intéressant pour les systèmes d’entreprise : les événements peuvent être conservés et reproduits.

Une décision automatisée n’a pas à devenir une boîte noire impossible à auditer.

En conservant le flux, une organisation peut contrôler quelles informations ont été reçues, investiguer une incident, évaluer le comportement du modèle ultérieurement ou refaire des inférences sur des données historiques.

Pour les applications réglementées ou les décisions ayant un impact opérationnel, cette traçabilité peut être aussi importante que la prédiction elle-même.

Du maintien prédictif à la performance des serveurs

Les exemples d’entreprise sont faciles à imaginer car pratiquement toute infrastructure moderne produit des séries temporelles : températures, vitesses, pressions, niveaux de production, ventes, inventaires, transactions, latences, erreurs, ressources consommées.

Une application en temps réel peut générer une alerte si la CPU dépasse 90 %, mais un modèle temporel cherchant à repérer un comportement anormal peut aller plus loin : il peut anticiper si une machine deviendra défaillante même sans franchir un seuil précis.

Il peut aussi prévoir quand une capacité sera atteinte.

La différence est fondamentale entre le simple suivi et la prévision : les règles sont des conditions prédéfinies. La prédiction cherche à anticiper, et la détection d’anomalies repère des comportements déviants.

Cela ne signifie pas que les seuils classiques doivent disparaître. En infrastructures critiques, combiner règles déterministes, observabilité et modèles prédictifs reste souvent la meilleure stratégie.

Un exemple de détection de fraude en temps réel

IBM cite notamment le secteur financier :

Une transaction peut être évaluée pendant qu’elle circule encore. Si son comportement diverge des schémas attendus, le système peut immédiatement en tirer une inférence : la bloquer, demander une vérification ou fournir un contexte supplémentaire à un autre système IA.

C’est là une des applications illustrant la puissance de la combinaison streaming + IA :

Le résultat d’un modèle ne doit pas forcément être la fin du processus.

Il peut devenir un autre événement.

Une anomalie décelée peut être publiée dans Kafka. Un autre système peut l’enrichir avec des données client, un agent peut l’analyser, et une autre action peut être déclenchée.

L’architecture devient ainsi moins « envoyer des données à une IA » et plus « intégrer l’inférence dans un système distribué événementiel ».

Le lakehouse n’a pas disparu avec l’intégration de l’IA dans le streaming

Il faut cependant distinguer deux points importants :

L’exécution directe de l’inférence sur le flux ne supprime pas l’intérêt d’un data lake, d’un warehouse ou d’un lakehouse.

Ce sont des problématiques différentes :

Les organisations ont toujours besoin de stockage historique pour l’analyse, la formation, la conformité, la recherche ou le reporting.

Le streaming est surtout précieux quand il faut agir sur le moment tout en conservant une certaine actualité.

Les deux peuvent cohabiter :

IBM explique que les inférences générées peuvent être distribuées depuis Kafka vers des systèmes opérationnels ou des data lakehouses.

Il est donc plus précis de parler d’« apporter de l’intelligence au flux de données » plutôt que de vouloir remplacer systématiquement une architecture analytique par une autre.

Une solution encore en Early Access

Il reste une précaution importante concernant la disponibilité :

Granite Time Series dans Confluent Cloud est actuellement en Early Access.

La première disponibilité concerne Confluent Cloud sur AWS. IBM et Confluent prévoient d’ajouter ultérieurement un support pour Confluent Platform en locaux et en environnement hybride.

De plus, la documentation de Confluent précise que ces fonctions en Early Access ne bénéficient pas d’un engagement de niveau de service et restent des fonctionnalités d’expérimentation sous leurs conditions d’utilisation.

Cela est particulièrement crucial pour des applications pouvant impacter des processus critiques.

La technologie peut déjà être testée, mais il reste un gap entre l’expérimentation sur un flux et la mise en production sous des exigences strictes de disponibilité.

L’annonce d’IBM et Confluent est donc intéressante, sans demander une révolution immédiate.

Le secteur de l’IA en entreprise a longtemps été associé à des modèles de langage, chatbots ou agents. Les séries temporelles rappellent qu’une part importante des données d’entreprise sont de cette nature : valeurs qui évoluent en permanence avec le temps.

Les serveurs, usines, réseaux, magasins, véhicules, marchés financiers et autres systèmes génèrent ce type d’information sans interruption.

Appliquer de petits modèles directement sur ces flux peut être beaucoup plus pertinent pour certains acteurs que de déployer un autre chatbot.

Et c’est probablement la partie la plus significative de l’annonce : l’IA commence à se déplacer d’applications nécessitant une interaction humaine vers des infrastructures capables de surveiller en continu et d’émettre une alerte avant même qu’une question ne soit posée.

Foire aux questions

Que vient d’annoncer IBM avec Confluent ?

IBM Granite Time Series s’intègre à Confluent Cloud pour faire des prévisions et détecter des anomalies directement sur des données en streaming via Apache Flink. La disponibilité initiale est en Early Access sur Confluent Cloud en AWS.

Quels modèles Granite Time Series seront accessibles ?

La première gamme inclut PatchTST-FM-r1, FlowState-r1.1, TTM-r3 et TSPulse. Ces modèles comptent entre 1 et 260 millions de paramètres, conçus pour fonctionner sans GPU.

Comment utiliser l’IA avec Apache Flink ?

Confluent offre deux fonctions SQL dans Flink : AI_FORECAST et AI_DETECT_ANOMALIES. Elles permettent de choisir le modèle, configurer la prévision ou la détection d’anomalies via SQL, sans gérer une infrastructure séparée pour déployer ces modèles.

Cette technologie peut-elle remplacer un lakehouse ?

Pas nécessairement. L’inférence en flux permet des réponses rapides sur les événements, tandis que les lakehouses et autres stockages restent indispensables pour l’analyse historique, la formation ou le reporting. Les architectures d’IBM et Confluent prévoient que les résultats du streaming alimentent aussi ces systèmes.