Aller au contenu principal
Definity intègre des agents dans les pipelines Spark pour détecter les erreurs en amont des systèmes d'IA autonomes
InfrastructureVentureBeat AI1h

Definity intègre des agents dans les pipelines Spark pour détecter les erreurs en amont des systèmes d'IA autonomes

Résumé IASource uniqueImpact UE
Source originale ↗·

Definity, une startup spécialisée dans la fiabilité des pipelines de données, basée à Chicago, a annoncé mercredi une levée de fonds de 12 millions de dollars en série A, menée par GreatPoint Ventures avec la participation de Dynatrace, StageOne Ventures et Hyde Park Venture Partners. La société a développé une approche radicalement différente de la surveillance des pipelines : plutôt que d'analyser ce qui s'est passé après l'exécution d'un job, elle intègre un agent directement à l'intérieur du moteur Spark ou DBT, pendant que le pipeline tourne. Concrètement, un agent JVM s'installe en une seule ligne de code sous la couche plateforme, capturant en temps réel le comportement des requêtes, la pression mémoire, le déséquilibre des données et les patterns de shuffle. L'agent peut alors intervenir activement : réallouer des ressources à mi-parcours, stopper un job avant que des données corrompues ne se propagent, ou bloquer un pipeline en aval si la table d'entrée en amont est périmée. Un client entreprise a identifié 33 % de ses opportunités d'optimisation dès la première semaine de déploiement, réduit de 70 % l'effort de débogage, et résout désormais les problèmes Spark complexes jusqu'à dix fois plus vite.

L'enjeu va bien au-delà de l'efficacité opérationnelle : avec l'essor des systèmes d'IA agentiques, la fiabilité des données en entrée devient critique. Un pipeline qui échoue silencieusement ou livre des données obsolètes ne casse plus seulement un tableau de bord, il compromet l'ensemble du système d'IA qui en dépend. La distinction est fondamentale : la détection et la prévention sont en temps réel, tandis que l'analyse des causes profondes et les recommandations d'optimisation s'effectuent à la demande, avec tout le contexte d'exécution déjà assemblé. L'agent n'ajoute qu'environ une seconde de calcul sur un job d'une heure. Seules les métadonnées transitent à l'extérieur, et un déploiement entièrement on-premises est disponible pour les environnements sensibles.

Les outils existants, qu'il s'agisse de Datadog (qui a racheté Metaplane l'an dernier), des system tables Databricks, ou de plateformes comme Unravel Data et Acceldata, lisent tous les métriques une fois le job terminé. Comme le résume Roy Daniel, CEO et co-fondateur de Definity : « Le moment où vous apprenez qu'un problème s'est produit, il s'est déjà produit. » Le marché de l'observabilité des données est en pleine structuration, porté par la multiplication des pipelines complexes et l'exigence croissante des systèmes d'IA en production. Nexxen, plateforme adtech opérant de large pipelines Spark pour la publicité en temps réel, fait partie des premiers clients en production. La participation de Dynatrace au tour de table est notable : l'entreprise, spécialiste de l'observabilité IT, investit ainsi dans une approche concurrente à ses propres capacités de monitoring, signe que la niche de l'exécution inline commence à être prise au sérieux.

Impact France/UE

Dynatrace, éditeur autrichien d'observabilité IT coté en bourse, participe au tour de table de Definity, signalant l'intérêt croissant des acteurs européens pour la surveillance inline des pipelines de données critiques aux systèmes d'IA en production.

Dans nos dossiers

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

L'AI-RAN redefinit l'intelligence et l'autonomie en bordure de reseau pour les entreprises
1VentureBeat AI 

L'AI-RAN redefinit l'intelligence et l'autonomie en bordure de reseau pour les entreprises

Les réseaux radio à intelligence artificielle, connus sous l'acronyme AI-RAN, s'imposent progressivement comme une refonte profonde de l'infrastructure sans fil en entreprise. Lors d'une conversation avec VentureBeat, Chris Christou, vice-président senior chez Booz Allen, et Shervin Gerami, directeur général au Cerberus Operations Supply Chain Fund, ont détaillé les contours de cette transformation. Christou résume l'enjeu : l'AI-RAN permet d'étendre les promesses de la 5G, et demain de la 6G, en hébergeant directement de l'inférence IA au niveau de la périphérie du réseau, pour des cas d'usage comme la fabrication intelligente ou les entrepôts autonomes. Gerami va plus loin : selon lui, l'AI-RAN n'est pas une mise à niveau réseau, c'est un système d'exploitation pour les industries physiques. Le concept se décline en trois niveaux distincts : l'IA pour le RAN (optimisation interne du réseau), l'IA sur le RAN (exécution de charges de travail IA comme la vision par ordinateur ou l'inférence LLM locale), et enfin l'IA et le RAN conjointement, où applications et infrastructure radio sont conçues ensemble comme un système distribué coordonné. L'impact concret de cette convergence est considérable pour les secteurs industriels, logistiques et de santé. Le principe ISAC (Integrated Sensing and Communications) transforme le réseau lui-même en capteur, capable de détecter des mouvements, de suivre des actifs avec une précision inférieure au mètre dans des usines ou des hôpitaux, d'identifier des intrusions périmètriques ou d'optimiser la consommation énergétique de bâtiments intelligents. Là où les entreprises gèrent aujourd'hui des dizaines de systèmes distincts -- caméras, radars, capteurs de mouvement, traceurs d'actifs -- l'ISAC pourrait consolider ces capacités nativement dans le réseau, réduisant les coûts de maintenance, d'intégration et de gestion des fournisseurs. Pour les applications critiques comme la robotique en temps réel, l'inspection qualité instantanée ou la maintenance prédictive, la réduction de latence qu'offre l'IA en périphérie représente souvent la différence entre un système opérationnel et un système inutilisable. Cette dynamique s'inscrit dans un mouvement plus large de convergence entre cloud computing et infrastructure physique. Pendant des décennies, l'innovation applicative a été l'apanage du cloud ; l'AI-RAN ouvre la même logique d'écosystème développeur au niveau du réseau radio. Les acteurs positionnés sur ce marché -- cabinets de conseil comme Booz Allen, fonds d'investissement industriels comme Cerberus -- anticipent que la valeur ne réside plus dans le transport passif de données, mais dans la capacité à orchestrer des opérations autonomes directement depuis l'infrastructure réseau. La transition vers la 6G, attendue dans la seconde moitié de la décennie, devrait accélérer cette convergence, en faisant du réseau non plus un tuyau, mais une couche fondamentale de l'économie de l'IA physique.

UEL'AI-RAN concerne directement les secteurs industriels européens (fabrication, logistique, santé) en ouvrant la voie à une inférence IA décentralisée sur les réseaux 5G/6G, un enjeu stratégique pour la compétitivité industrielle de l'UE.

InfrastructureOpinion
1 source
Google refond sa data stack pour les agents autonomes, non plus pour les humains
2VentureBeat AI 

Google refond sa data stack pour les agents autonomes, non plus pour les humains

Google a dévoilé mercredi lors de sa conférence Cloud Next une refonte majeure de son infrastructure de données d'entreprise, baptisée "Agentic Data Cloud". L'annonce, portée par Andi Gutmans, vice-président et directeur général de Data Cloud chez Google Cloud, repose sur trois piliers : le Knowledge Catalog, un nouveau catalogue sémantique automatisé ; un data lakehouse multi-cloud ; et le Data Agent Kit, un ensemble d'outils MCP intégrables directement dans VS Code, Claude Code et Gemini CLI. Le Knowledge Catalog est une évolution de Dataplex, le produit de gouvernance de données existant de Google, mais avec une architecture profondément différente : là où les anciens catalogues exigeaient qu'une équipe de data stewards étiquette manuellement les tables et définisse les termes métier, le nouveau système utilise des agents pour automatiser entièrement ce travail. Il couvre nativement BigQuery, Spanner, AlloyDB et Cloud SQL, et s'interconnecte avec des catalogues tiers comme Collibra, Atlan et Datahub, ainsi qu'avec des applications SaaS telles que SAP, Salesforce Data360, ServiceNow et Workday, sans déplacement de données. Ce changement architectural répond à un problème concret qui touche les équipes data des grandes entreprises : les plateformes actuelles ont été conçues pour des humains qui posent des questions, pas pour des agents IA qui agissent en continu et de manière autonome. Avec le Data Agent Kit, les ingénieurs data peuvent désormais décrire des résultats attendus plutôt qu'écrire des pipelines, ce qui représente un changement de paradigme dans le quotidien des équipes techniques. Sur le plan de l'infrastructure, la nouvelle approche multi-cloud est particulièrement significative : BigQuery peut désormais interroger des tables au format Apache Iceberg stockées sur Amazon S3, via la couche réseau privée Cross-Cloud Interconnect de Google, sans frais de sortie de données et avec des performances comparables à celles d'un entrepôt natif AWS. Toutes les fonctions IA de BigQuery s'appliquent à ces données distantes sans modification. Une fédération bidirectionnelle est également en cours de déploiement avec Databricks Unity Catalog, Snowflake Polaris et AWS Glue Data Catalog. Cette annonce s'inscrit dans une course que se livrent les grands acteurs du cloud pour capter le marché de l'infrastructure IA d'entreprise. Les architectures de données actuelles ont été pensées pour des cycles de reporting et de tableaux de bord, ce que Google qualifie d'"intelligence réactive". Mais à mesure que les agents IA sont déployés pour prendre des décisions et déclencher des actions directement dans les systèmes métier, cette approche montre ses limites. Google n'est pas seul sur ce terrain : Databricks, Snowflake et AWS investissent massivement dans des architectures similaires. En intégrant ses outils directement dans des environnements de développement comme VS Code et Claude Code, Google cherche à s'imposer comme la couche de données de référence dans un monde où l'IA opère à l'échelle de l'entreprise, vingt-quatre heures sur vingt-quatre.

UELes entreprises européennes opérant en multi-cloud AWS/GCP pourront interroger leurs données sans frais de transfert sortant, et les équipes data pourront intégrer le Data Agent Kit dans VS Code pour automatiser leurs pipelines sans réécriture de code.

InfrastructureOpinion
1 source
3MIT Technology Review 

Déployer l'IA dans les environnements contraints du secteur public

Les institutions publiques du monde entier subissent une pression croissante pour adopter l'intelligence artificielle, mais leur contexte opérationnel diffère radicalement de celui du secteur privé. Une étude de Capgemini révèle que 79 % des dirigeants du secteur public s'inquiètent de la sécurité des données liées à l'IA, une préoccupation justifiée au regard de la sensibilité des informations gouvernementales et des obligations légales qui les entourent. Han Xiao, vice-président de l'IA chez Elastic, résume la situation : les agences gouvernementales doivent strictement contrôler les données qu'elles envoient sur le réseau, ce qui impose de nombreuses contraintes sur leur approche de l'IA. Une enquête d'Elastic auprès de décideurs publics révèle par ailleurs que 65 % d'entre eux peinent à exploiter leurs données en continu, en temps réel et à grande échelle. Là où le secteur privé présuppose une connectivité permanente au cloud, une infrastructure centralisée et une liberté de mouvement des données, les administrations publiques ne peuvent accepter ces conditions. Elles doivent garantir que leurs données restent sous leur contrôle, que les informations peuvent être vérifiées, et que la continuité des opérations est assurée, y compris dans des environnements où la connexion internet est limitée ou inexistante. S'ajoute à cela un autre obstacle matériel : les administrations achètent rarement des GPU, ces processeurs graphiques indispensables pour faire tourner les grands modèles d'IA, faute d'habitude de gérer ce type d'infrastructure. Ces contraintes cumulées expliquent pourquoi de nombreux projets pilotes d'IA dans le secteur public ne franchissent jamais le stade de l'expérimentation. Face à ces limites, les petits modèles de langage, ou SLM (Small Language Models), apparaissent comme une solution adaptée. Contrairement aux grands modèles comme GPT-4 qui mobilisent des centaines de milliards de paramètres, les SLM n'en utilisent que quelques milliards, ce qui les rend bien moins gourmands en ressources de calcul et permet de les héberger localement, sans dépendance au cloud. Des études empiriques montrent que leurs performances sont comparables, voire supérieures à celles des LLM sur des tâches spécialisées. Les données restent stockées en dehors du modèle et ne sont consultées qu'au moment des requêtes, grâce à des techniques comme la recherche vectorielle et l'ancrage sur des sources vérifiables. Des entreprises comme Elastic positionnent ces approches comme la voie réaliste vers une IA véritablement opérationnelle dans les administrations, à l'heure où la pression politique en faveur de la modernisation numérique ne cesse de s'intensifier.

UELes administrations françaises et européennes, contraintes par le RGPD et les exigences de souveraineté des données, trouvent dans les SLM déployables en local une voie concrète pour dépasser le stade pilote et accélérer leur modernisation numérique sans dépendance au cloud.

InfrastructureOpinion
1 source
Dégradation du contexte, dérive d'orchestration et montée des défaillances silencieuses dans les systèmes d'IA
4VentureBeat AI 

Dégradation du contexte, dérive d'orchestration et montée des défaillances silencieuses dans les systèmes d'IA

Les systèmes d'intelligence artificielle déployés en entreprise souffrent d'un angle mort critique : leurs pannes les plus coûteuses ne déclenchent aucune alarme. Un système peut afficher un uptime parfait, une latence dans les clous et un taux d'erreur nul, tout en produisant des réponses fausses, construites sur des données périmées ou des contextes corrompus. C'est ce que les ingénieurs spécialisés en infrastructure IA appellent le « reliability gap », l'écart entre la santé opérationnelle d'un service et sa fiabilité comportementale. Contrairement aux bugs classiques, ces défaillances silencieuses n'apparaissent ni dans Prometheus, ni dans Datadog, ni dans aucun tableau de bord traditionnel. Le modèle lui-même est rarement en cause : c'est la couche d'infrastructure qui l'entoure, pipelines de données, systèmes de récupération d'information, logique d'orchestration, workflows aval, qui dérive sans être détectée. Quatre patterns de rupture reviennent systématiquement dans les déploiements en production. La dégradation du contexte survient quand le modèle raisonne sur des données obsolètes ou incomplètes sans que l'utilisateur final ne s'en aperçoive : la réponse paraît soignée, le grounding a disparu, et la détection n'arrive que des semaines plus tard via des conséquences indirectes. La dérive d'orchestration touche les pipelines agentiques : stables en test, ils se comportent très différemment en charge réelle, quand les latences se cumulent et que les cas limites s'enchaînent. Les pannes partielles silencieuses, elles, font basculer un système dans la méfiance des utilisateurs bien avant qu'un ticket d'incident ne soit créé. Enfin, le blast radius de l'automatisation est propre aux workflows IA : une mauvaise interprétation tôt dans la chaîne se propage à travers plusieurs systèmes et décisions métier, avec des conséquences organisationnelles très difficiles à inverser. Ce problème prend de l'ampleur à mesure que les entreprises industrialisent leurs usages de l'IA dans des domaines critiques, opérations réseau, logistique, plateformes d'observabilité. Les deux dernières années ont été consacrées à évaluer les modèles eux-mêmes : benchmarks, scores de précision, red-teaming. Mais en production, c'est l'infrastructure qui cède. La réponse technique passe par l'ajout d'une couche de télémétrie comportementale en complément des outils existants, non pour les remplacer, mais pour capturer ce que le modèle a réellement fait avec le contexte reçu, et pas seulement si le service a répondu. La question n'est plus « le service est-il en ligne ? » mais « le service se comporte-t-il correctement ? » Ce sont deux instruments différents, et l'industrie commence à peine à construire le second.

InfrastructureOpinion
1 source