DATAGEN : un graphe LangGraph à huit agents pour enchaîner hypothèse, code et rapport

Le problème : un pipeline d'analyse qui ne tient pas dans une seule invite

Demander à un modèle unique de nettoyer un CSV, choisir une méthode, produire des graphiques et rédiger un rapport donne un résultat difficile à auditer. DATAGEN découpe ce travail en rôles nommés. Le README énumère huit composants : hypothesis_agent, process_agent, visualization_agent, code_agent, searcher_agent, report_agent, quality_review_agent et note_agent. Chacun a une fonction décrite en une ligne, du nettoyage des données à la revue qualité.

Le public visé est celui qui a déjà un fichier tabulaire et une question, mais pas l'envie d'écrire un orchestrateur. Le projet s'appelait auparavant AI-Data-Analysis-MultiAgent, ce qui décrit mieux sa nature : un assemblage d'agents autour de LangGraph, pas une bibliothèque d'analyse statistique. Si vous cherchez un moteur de calcul, vous êtes au mauvais endroit. Si vous cherchez une chaîne d'agents à modifier, la structure est là.

Le graphe LangGraph et ses cinq étapes

Le README décrit un state graph LangGraph qui gère l'ensemble du processus. Cinq étapes : génération d'hypothèse, choix humain (continuer ou régénérer l'hypothèse), traitement (analyse de données, visualisation, recherche, rédaction), revue qualité, puis révision si nécessaire.

L'étape 2 est la plus intéressante. Le système ne part pas seul dans une direction : il propose une hypothèse et attend un arbitrage. C'est un choix de conception qui coûte de l'interaction et qui évite de brûler des appels de modèles sur une piste absente du jeu de données.

Le rôle de note_agent mérite attention. Le README le présente comme un agent qui enregistre le processus de recherche, et la section des fonctionnalités parle d'un système de rétention du contexte. Autrement dit, la mémoire du graphe n'est pas seulement l'état LangGraph : une partie du contexte est reformulée en notes. Cette reformulation a un coût en jetons et introduit une perte d'information possible à chaque passage. Le dépôt ne documente pas de mécanisme de vérification de ces notes, et je n'ai pas exécuté le système pour mesurer cet effet.

agent_models.yaml : un modèle par agent, pas un modèle pour tout

La configuration se fait par fichier, pas par variable d'environnement unique. Le README donne un exemple de structure pour agent_models.yaml :

agents: hypothesis_agent: provider: openai model_config: model: gpt-5-nano temperature: 1.0 note_agent: provider: google model_config: model: gemini-2.5-pro temperature: 1.0 code_agent: provider: anthropic model_config: model: claude-haiku-4-5 temperature: 1.0

Deux clés par agent : provider (openai, google, anthropic, ollama, groq d'après le README) et model_config, qui contient model et temperature, cette dernière allant de 0.0 à 2.0. Le fichier vit dans CONFIG_DIRECTORY, dont la valeur par défaut est config. Le README conseille config_local pour le développement local, déjà présent dans .gitignore.

C'est le point le plus solide du projet. On peut mettre un petit modèle sur la génération d'hypothèses et un modèle plus capable sur la rédaction, sans toucher au code. Le revers : les noms de modèles cités dans l'exemple (gpt-5-nano, gemini-2.5-pro, claude-haiku-4-5) sont ceux du README à un instant donné. Ces identifiants changent côté fournisseurs. Un fichier de configuration qui ne se valide pas au démarrage transforme une mise à jour de modèle en panne silencieuse au milieu d'un graphe.

Installation : conda, requirements.txt et un ChromeDriver

Le README demande Python 3.10 ou supérieur. La séquence :

git clone https://github.com/starpig1129/DATAGEN.git conda create -n datagen python=3.10 conda activate datagen pip install -r requirements.txt

Ensuite, renommer .env Example en .env et remplir les valeurs. Trois variables sont marquées requises : WORKING_DIRECTORY (chemin de stockage des données, également utilisé par le serveur MCP filesystem), CONDA_ENV (nom de l'environnement conda, datagen dans l'exemple) et CHROMEDRIVER_PATH. Ce dernier point est concret : le projet attend un binaire ChromeDriver, l'exemple pointe vers ./chromedriver-linux64/chromedriver. Une machine sans Chrome ni binaire compatible ne fera pas tourner la partie navigation.

Le reste est optionnel mais structurant. OPENAI_API_KEY, ANTHROPIC_API_KEY et GOOGLE_API_KEY couvrent les fournisseurs de modèles. FIRECRAWL_API_KEY et CRW_API_KEY concernent la récupération web, avec CRW_API_URL qui bascule par défaut sur le cloud géré et peut pointer vers une instance auto-hébergée. TAVILY_API_KEY alimente un serveur MCP de recherche web, GITHUB_TOKEN un serveur MCP GitHub. LANGCHAIN_TRACING_V2 et LANGCHAIN_PROJECT servent au suivi. Le README précise qu'une clé Firecrawl absente réduit les capacités de requête.

Le lancement passe par main.py. On place le fichier de données dans le répertoire data, puis on modifie la variable user_input de la fonction main() :

user_input = ''' datapath:YourDataName.csv Use machine learning to perform data analysis and write complete graphical reports '''

Puis python main.py. Cette variable est une chaîne de texte libre, avec un champ datapath: suivi du nom du fichier. Il n'y a pas d'interface en ligne de commande documentée dans le README. Pour automatiser, il faut donc éditer le fichier ou l'importer comme module.

La revue qualité : le maillon dont le README ne dit presque rien

quality_review_agent est décrit en une ligne : effectue des revues qualité. Le workflow le place après le traitement, puis prévoit une révision si nécessaire. Mais le README ne précise pas ce que l'agent examine : le code exécuté, les sorties numériques, la cohérence du rapport, ou seulement la prose.

Cette ambiguïté est la principale réserve. Un code_agent qui écrit du code d'analyse peut produire une sortie qui s'exécute sans erreur et qui répond à côté de la question. Une revue qui ne relit que le rapport ne détectera pas ce cas. Tant que cette portée n'est pas lue dans le code du graphe, il faut considérer la revue qualité comme une relecture rédactionnelle, pas comme une validation statistique.

Même remarque pour le nettoyage des données. Le README mentionne un nettoyage robuste et une assurance qualité automatisée, sans décrire les règles appliquées. Sur des données de production, la question du traitement des valeurs manquantes et des valeurs aberrantes n'est pas cosmétique : elle change les conclusions. Le projet ne documente pas de journal d'audit de ces transformations.

Ce que DATAGEN n'est pas, et à quoi le comparer

Le README emploie un vocabulaire marketing qui ne correspond pas à ce que le dépôt montre : entreprise, production-ready, scalable. Le code visible est un prototype de recherche Python, sans release publiée à ce jour et sans page d'accueil. Ce décalage entre le discours et l'artefact est un signal à prendre en compte au moment de l'évaluation.

Comme alternative réelle, on peut citer l'usage direct de LangGraph avec ses propres nœuds. La différence n'est pas le fournisseur de modèles, puisque DATAGEN accepte openai, google, anthropic, ollama et groq. La différence est le périmètre : LangGraph fournit le moteur de graphe et l'état, sans agents prédéfinis, sans fichiers de rôle, sans note_agent, sans quality_review_agent, sans ChromeDriver, sans configuration MCP. Vous écrivez tout, mais vous contrôlez chaque étape et chaque transformation de données.

Un notebook Jupyter avec appels manuels au modèle est une autre option, plus proche de l'exploration ponctuelle. DATAGEN vise la répétition : même graphe, même découpage des rôles, modèles interchangeables. Si vous analysez un fichier une fois, le coût d'installation (conda, ChromeDriver, clés multiples, configuration YAML) dépasse le bénéfice. Si vous répétez le même type d'analyse sur des jeux de données successifs, la structure se défend.

Coût de maintenance et implications de la licence MIT

La maintenance porte sur trois surfaces qui bougent indépendamment du code du projet : les identifiants de modèles dans agent_models.yaml, les API des fournisseurs, et les binaires externes (ChromeDriver, fastCRW). Une mise à jour de modèle côté fournisseur peut casser une configuration sans qu'aucune ligne du dépôt n'ait changé. Le suivi via LANGCHAIN_TRACING_V2 aide à diagnostiquer, mais il ajoute une dépendance de service et envoie des traces à un tiers.

La licence MIT est permissive : usage commercial, modification et redistribution autorisés, avec conservation du texte de licence et de l'avis de copyright. Elle n'impose aucune obligation de publication des modifications. Elle ne dit rien non plus sur les licences des dépendances listées dans requirements.txt, qu'il faut vérifier séparément, ni sur les conditions des fournisseurs de modèles et des services de scraping. Ce paragraphe décrit la licence telle qu'elle est déclarée dans le dépôt ; il ne constitue pas un avis juridique.

Dernier point de maintenance : le README renvoie à une architecture de configuration par divulgation progressive pour les agents, section tronquée dans le matériel disponible. La structure exacte des fichiers sous CONFIG_DIRECTORY (agent_models.yaml, agents/, mcp.yaml) est donc partiellement documentée. C'est à vérifier en premier dans le dépôt.

Conclusion éditoriale

DATAGEN convient aux équipes qui veulent un squelette de recherche reproductible, avec modèles interchangeables par agent et point d'arrêt humain, et qui acceptent de lire le code avant de faire confiance aux résultats. Il ne convient pas à la production décisionnelle sans surveillance : la revue qualité agit sur le rapport, pas sur les chiffres. Avant de l'adopter, vérifiez deux choses dans le dépôt : la portée exacte de quality_review_agent dans le graphe, et si vos données peuvent sortir vers un fournisseur externe, puisque le README liste OpenAI, Anthropic et Google comme fournisseurs pris en charge.

Sources officielles

1. Issues
2. License: MIT
3. README
4. zi-yue-1129/DATAGEN on GitHub