RAG, A2A, détection d’anomalies : Confluent enrichit son arsenal IA

Des pipelines RAG plus évolutifs

Du côté de la recherche vectorielle et des systèmes RAG, le contributeur principal de Kafka mise sur sa deuxième technologie de prédilection : Apache Flink. Le moteur de traitement de données de streaming (et batch) est utilisé pour créer des vues de données enrichies qui combinent des données relationnelles, des extraits issus d’API REST et des documents vectorisés. Flink peut lire uniquement le contenu de tables externes stockées dans ces SGBD.

Confluent prenait déjà en charge MongoDB, Pinecone, Couchbase, et Elastic. Il ajoute Azure Cosmos DB et Amazon S3 Vectors en disponibilité générale, en exploitant un algorithme de recherche des plus proches voisins (kNN).

Ces vues enrichies, potentiellement mises à jour en quasi temps réel, peuvent servir de base contextuelle à un chatbot ou à un agent IA, imagine Confluent. À son idée, cette mise en contexte se fait avant qu’un usager écrive un prompt.

L’éditeur assure que ses clients peuvent exécuter « un pipeline de streaming unique qui gère l’ingestion, la transformation, la création d’embeddings, la recherche vectorielle et l’inférence des modèles ». Par défaut, cinq étapes au sein d’une requête Flink SQL suffisent pour mener ce travail. Et de promettre un gain d’agnosticité par rapport aux SGBD et aux LLM sollicités tout au long de ce processus.

Pour les clients qui utiliseraient Azure ou AWS PrivateLink, Confluent promet une « connectivité de VPC à VPC » pour interroger les LLM, les bases vectorielles et les tables externes afin d’éviter l’exposition de leurs données traitées par des modèles d’IA à l’Internet public. La fonction est en disponibilité générale.

 Confluent signale toutefois que les appels externes, vers des modèles d’IA, des bases de données vectorielles « peuvent introduire des risques ». « Le retraitement peut submerger les systèmes externes avec un trafic de rejeu, les défaillances réseau ou la latence élevée peuvent se propager en cascade à l’ensemble des pipelines, et les rejeux historiques peuvent obtenir des données actuelles au lieu de l’état à un moment précis, compromettant ainsi la cohérence des audits », prévient l’éditeur dans sa documentation. En clair, un déploiement réussi réclame une étude approfondie et des limites claires, estime-t-il.

Confluent se prépare à la version 1.0 d’Agent2Agent

Cela ne l’empêche pas de poursuivre le développement de son système multiagent orienté événement et des « streaming agents ». Après la prise en charge du protocole MCP (Model Context Protocol), il propose un serveur MCP pour interagir avec ses distributions de Kafka et Flink, à travers ses API Confluent Cloud. Depuis Claude Desktop et Goose CLI, les usagers peuvent gérer des topics Kafka, des connecteurs et des requêtes Flink SQL. Ce serveur MCP ne date pas d’hier, mais l’éditeur le met plus largement à disposition.

En préversion ouverte, il s’attaque à l’intégration du protocole Agent2Agent. Il s’agit de permettre à n’importe quels frameworks et outils compatibles avec la technologie A2A (Salesforce, Databricks, Snowflake, SAP, CrewAI, AutoGen, LangGraph, ADK, Amazon Bedrock, etc.) d’interagir avec Flink et les fonctions de Confluent Cloud.

Et l’éditeur d’illustrer un cas d’usage qui impliquerait un agent de streaming capable d’identifier une anomalie réseau chez un opérateur 5G, de la transmettre à un agent ServiceNow pour créer le ticket relatif à la zone impactée et d’appeler un agent Salesforce pour obtenir les informations sur les SLA applicables aux clients professionnels impactés. Et ce, afin d’enclencher des flux de remédiation automatiques ou préparer l’intervention d’un technicien en chair et en os.

Pour l’instant, l’implémentation de Confluent ressemble à un prototype calqué sur le fonctionnement de MCP dans la sphère de l’éditeur. La documentation ne semble pas assez touffue pour reproduire de but en blanc le scénario d’anticipation décrit plus haut.

Il faut dire qu’une certaine prudence s’impose. Sur le papier, le protocole open source contribué par Google évolue doucement. A2A n’a pas quitté sa version 0.3.0 depuis le mois de juillet 2025. En consultant les commits les plus récents du dépôt GitHub du projet, LeMagIT découvre que les ingénieurs chez Google préparent l’arrivée prochaine de la version 1.0 du protocole. Les modifications portent sur le respect des standards RFC, REST, gRPC, JSON-RPC et une taxonomie pour mieux gérer les erreurs. Confluent semble se tenir prêt, donc.

Détection d’anomalies multivariées : les statistiques ne disparaissent pas

Mais la fonctionnalité « d’IA » la plus intéressante de la mise à jour Q1 2026 de Confluent Cloud n’a pas grand-chose à voir avec l’IA agentique. En accès anticipé, l’éditeur introduit un algorithme de détection d’anomalies multivariées dans Confluent Cloud for Apache Flink à travers l’expression ML_DETECT_ANOMALIES_ROBUST. Il proposait déjà de détecter des anomalies avec un modèle statistique de prévision basé sur la technique ARIMA (Autoregressive Integrated Moving Average). Celui-ci détecte les anomalies à une seule variable au sein de séries temporelles en modélisant les tendances et la non-stationnarité des données (leur caractère évolutif).

La détection d’anomalies à plusieurs variables (une demande des clients) s’appuie sur l’écart absolu médian (Median Absolute Deviation, MAD). Cette autre technique statistique offre explicabilité et simplicité d’exécution tout en garantissant une robustesse face aux valeurs aberrantes et au bruit dans les données. Il s’agit de propulser davantage de cas de maintenance prédictive en lien avec les systèmes Kafka-Flink. Confluent veut répondre ainsi aux besoins des industriels et des institutions bancaires, tout comme des e-commerçants. La même approche permet d’affiner la détection de fraudes et l’analyse des parcours d’achats.