Google ADK : un pipeline multi-agents en Python pour analyser des données, tracer des graphiques et produire des rapports

Google ADK gagne un nouveau cas d'usage pratique : un pipeline multi-agents pas à pas pour l'analyse de données en Python. L'exemple ne se limite pas à un chat avec un agent. Il présente un schéma de travail complet, capable de charger des tables, de calculer des statistiques, de tracer des graphiques, de transformer des données et d'assembler un rapport final.

Comment le pipeline est construit

L'exemple repose sur google-adk, pandas, numpy, scipy, matplotlib, seaborn et openpyxl. Le développeur commence par préparer l'environnement, configurer l'accès à l'API et définir le modèle via LiteLlm. Le code utilise openai/gpt-4o-mini, un détail important : Google ADK n'est pas ici un framework réservé à Gemini, mais une couche d'orchestration capable de travailler avec des modèles externes grâce à un connecteur standard. Le tutoriel se rapproche ainsi des scénarios de production réels, où la stack se construit rarement autour d'un seul fournisseur.

Le guide met ensuite en place un DataStore commun, un espace centralisé pour les dataframes et l'historique d'analyse. On y trouve les CSV chargés, les jeux de données de test générés et les résultats des étapes intermédiaires. Un helper de sérialisation permet de renvoyer sans risque les réponses des outils en JSON. En analyse appliquée, ce n'est pas cosmétique : sans cette couche, un système multi-agents se heurte vite à des types incompatibles, à des données dupliquées et à un état peu lisible entre les étapes, surtout quand un agent reprend le travail d'un autre.

Quels rôles se partagent le travail

Au lieu d'un agent « universel », les auteurs répartissent le travail entre plusieurs rôles étroits. Le pipeline ressemble ainsi davantage à une vraie é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 seul gros script. Cette approche facilite le passage à l'échelle : chaque bloc peut être modifié, testé et réutilisé sans refondre toute la chaîne, et l'agent maître dispose d'exécutants plus prévisibles pour des tâches précises.

• data_loader charge les CSV et crée des jeux de données d'exemple : sales, customers, timeseries et survey
• statistician calcule les statistiques descriptives, les corrélations, Shapiro-Wilk, t-test, ANOVA et chi-square
• visualizer trace histogram, scatter, bar, line, box, heatmap et pie, et produit aussi un distribution report de quatre graphiques
• transformer filtre les lignes, agrège les tables et ajoute des colonnes calculées
• reporter assemble un summary report sur la qualité des données, les valeurs manquantes, les doublons et les principaux constats

Au-dessus, l'agent maître data_analyst route les requêtes entre les spécialistes. La session est conservée via InMemorySessionService et l'exécution passe par Runner. L'utilisateur peut ainsi formuler ses demandes en langage naturel : créer un dataset de ventes, vérifier la normalité d'une distribution, tracer une heatmap de corrélations, comparer le chiffre d'affaires entre groupes de clients ou assembler un rapport final. Pour ADK, c'est un bon exemple de la façon dont une architecture d'agents passe du stade de démo à celui de workflow maîtrisé, avec des rôles clairs et un enchaînement d'étapes transparent.

Du code à l'analyse

La force de l'exemple tient à ce qu'il couvre tout le parcours d'analyse, et pas seulement une étape. Le système peut partir d'une table brute ou de données générées, décrire rapidement la structure du jeu de données, calculer distributions et valeurs aberrantes, passer ensuite aux graphiques, et seulement après à des comparaisons et des conclusions plus complexes. Cet ordre compte : en analyse de données, les erreurs commencent souvent avant l'étape de modélisation, quand les données sont encore mal comprises et que les décisions reposent sur la première impression laissée par la table.

Il est également utile que le tutoriel ne s'arrête pas à l'EDA. Il comprend des étapes de transformation des tables : filtrage selon une condition, agrégations par groupes et calcul de nouveaux champs par expressions. L'agent produit ensuite un summary report avec une vue d'ensemble du dataset, le niveau de valeurs manquantes, le nombre de doublons et des insights numériques et catégoriels de base. Autrement dit, ADK ne sert pas à un « joli chat sur les données », mais à une chaîne reproductible, adaptable à l'analyse interne d'une équipe, à un bac à sable BI, à un banc d'apprentissage ou à une démonstration de l'approche par agents sur un cas métier lisible.

Ce que cela change

Pour Google ADK, de tels exemples comptent plus que les annonces tapageuses : ils montrent que le framework peut déjà servir d'ossature à de vrais assistants d'analyse. Pour les développeurs, le signal est simple : l'approche multi-agents commence à fonctionner non seulement dans les scénarios de recherche, mais aussi dans les tâches quotidiennes d'analyse de données, où il faut des étapes transparentes, des outils et un résultat reproductible.