Google ADK présente un pipeline multi-agent d’analyse de données, de graphiques et de rapports en Python

Google ADK a reçu un autre cas d'usage pratique : un pipeline multi-agent étape par étape pour l'analyse de données en Python. L'exemple démontre non pas simplement un chat avec un agent, mais un schéma de travail complet capable de charger des tables, calculer des statistiques, construire des graphiques, transformer des données et compiler un rapport final.

Comment fonctionne le Pipeline

La base de l'exemple est une combinaison de google-adk, pandas, numpy, scipy, matplotlib, seaborn et openpyxl. D'abord, le développeur configure l'environnement, définit l'accès à l'API et spécifie le modèle via LiteLlm. Le code utilise openai/gpt-4o-mini, et c'est un détail important : Google ADK agit ici non pas comme un framework exclusivement pour Gemini, mais comme une couche d'orchestration capable de travailler avec des modèles externes via un wrapper standard.

Cela rend le tutoriel plus proche de scénarios de production réels, où la pile est rarement construite autour d'un seul fournisseur. Ensuite, le guide assemble un DataStore commun—un référentiel centralisé pour les dataframes et l'historique d'analyse. Il y stocke des CSVs chargés, des datasets de test générés et les résultats d'étapes intermédiaires. Un helper séparé est ajouté pour la sérialisation, afin que les réponses des outils puissent être retournées en toute sécurité en JSON.

Pour l'analyse appliquée, ce n'est pas simplement cosmétique : sans une telle couche, un système multi-agent butte rapidement contre des types incompatibles, la duplication de données et un état indéfini entre les étapes, surtout quand un agent poursuit le travail d'un autre.

Comment les Rôles sont Répartis

Au lieu d'un seul agent « universel », les auteurs divisent le travail en plusieurs rôles spécialisés. Cela rapproche le pipeline d'une véritable équipe d'analyse, où le chargement des données, l'exploration, la visualisation, la transformation des tables et la préparation des conclusions vivent rarement dans un unique grand script. Cette approche simplifie l'évolutivité : les blocs individuels peuvent être modifiés, testés et réutilisés sans reconstruire toute la chaîne, et l'agent maître obtient des exécuteurs plus prévisibles pour des tâches spécifiques.

• data_loader charge les CSV et crée des datasets d'exemple : sales, customers, timeseries et survey
• statistician calcule les statistiques descriptives, les corrélations, Shapiro-Wilk, t-test, ANOVA et chi-square
• visualizer construit histogram, scatter, bar, line, box, heatmap et pie, et crée un rapport de distribution à partir de quatre graphiques
• transformer filtre les lignes, agrège les tables et ajoute des colonnes calculées
• reporter compile un rapport de résumé avec la qualité des données, les valeurs manquantes, les doublons et les principales conclusions

Au-dessus d'eux se trouve l'agent maître data_analyst, qui achemine les demandes entre les spécialistes. La session est stockée via InMemorySessionService, et l'exécution est gérée par Runner. En résultat, l'utilisateur peut assigner des tâches en langage naturel : créer un dataset de ventes, vérifier la normalité de la distribution, construire une heatmap de corrélation, comparer les revenus entre groupes de clients ou compiler un rapport final.

Pour ADK, c'est un bon exemple de la manière dont l'architecture d'agents se transforme d'une démo en un workflow géré avec des rôles clairs et une séquence transparente d'étapes.

Du Code à l'Analyse

Le point fort de l'exemple est qu'il couvre tout le parcours d'analyse, pas seulement un segment. Le système peut commencer par des données brutes ou des datasets générés, décrire rapidement la structure de l'ensemble, calculer les distributions et les valeurs aberrantes, puis passer aux graphiques et seulement après aux comparaisons plus complexes et conclusions.

Cet ordre est important : en analyse, les erreurs commencent souvent non pas au stade du modèle, mais plus tôt, quand les données ne sont pas encore bien comprises et que les décisions sont prises sur premières impressions du tableau.

Il est aussi utile que le tutoriel ne se limite pas à EDA. Il inclut des étapes pour la transformation des tables : filtrage par condition, agrégation par groupes et calcul de nouveaux champs via des expressions. Après cela, l'agent forme un rapport de résumé avec un aperçu du dataset, le niveau des valeurs manquantes, le nombre de doublons et les insights numériques/catégoriques basiques.

C'est-à-dire que ADK est utilisé non pour de « jolis discussions sur les données », mais pour un pipeline répétable qu'on peut adapter à l'analyse interne de l'équipe, sandbox BI, environnement de formation ou démonstration des capacités de l'approche basée sur les agents sur une tâche métier compréhensible.

Ce que Cela Signifie

Pour Google ADK, de tels exemples sont plus importants que des annonces retentissantes : ils montrent que le framework peut déjà être appliqué comme fondation pour de véritables assistants d'analyse. Pour les développeurs, le signal est simple : l'approche multi-agent commence à fonctionner non seulement dans des scénarios de recherche, mais aussi dans des tâches quotidiennes d'analyse de données, où sont nécessaires des étapes transparentes, des outils et des résultats reproductibles.