DeepAnalyze : un LLM agentique qui exécute lui-même la chaîne d'analyse de données

Le vide que le projet cherche à combler

La plupart des assistants d'analyse de données s'arrêtent à la génération de code. L'utilisateur colle un extrait de CSV, obtient un bloc pandas, l'exécute lui-même, corrige l'erreur d'encodage, relance. DeepAnalyze prend le problème à l'autre bout : le README annonce la prise en charge de l'ensemble de la chaîne, de la préparation des données au rapport final, en passant par la modélisation et la visualisation. Le public visé est donc double. D'un côté l'analyste qui veut poser une question en langage naturel sur un dossier de fichiers sans écrire de pipeline. De l'autre l'équipe de recherche qui veut étudier le comportement d'un agent sur des tâches ouvertes, puisque le modèle, les données d'entraînement et le code sont publiés sous MIT. Le dépôt cite des sources structurées (bases de données, CSV, Excel), semi-structurées (JSON, XML, YAML) et non structurées (TXT, Markdown), ce qui donne une idée de l'étendue revendiquée : il ne s'agit pas d'un outil de reporting sur un entrepôt unique, mais d'un agent censé découvrir lui-même les données pertinentes dans un espace de travail.

Un modèle de 8B, un jeu d'instructions et un agent qui écrit du code

Le cœur du projet est un modèle de langage de 8 milliards de paramètres, publié sur Hugging Face sous le nom DeepAnalyze-8B. Le README précise qu'il a été entraîné sur DataScience-Instruct-500K, un jeu de 500 000 exemples d'instructions orientées science des données, lui aussi ouvert. C'est ce qui distingue DeepAnalyze d'un simple prompt système posé sur un modèle généraliste : le comportement agentique est en partie appris, pas seulement orchestré. Le mécanisme visible dans le matériel fourni est celui d'un agent qui écrit et exécute du code. La version 2 de l'interface web, située dans demo/chat_v2, est décrite comme s'appuyant sur une exécution de code en bac à sable Docker, et le système sous-jacent, DA-Studio, a été accepté en démonstration à VLDB 2026 selon les notes de version. Le flux est donc le suivant : une question en langage naturel entre, l'agent inspecte les fichiers disponibles, produit du code, l'exécute dans un environnement isolé, lit les erreurs, itère, puis rédige un rapport. Le benchmark CoDA-Bench, publié par la même équipe en juin 2026, décrit exactement ce scénario : un bac à sable Linux, des centaines de fichiers, et un agent qui doit trouver les données pertinentes avant de pouvoir répondre.

Mise en route : ce que le dépôt expose réellement

Le README ne fournit pas de bloc d'installation complet dans l'extrait disponible, et il faut le dire clairement : les commandes exactes de déploiement du modèle ne figurent pas dans le matériel transmis. Ce que l'on peut affirmer, c'est que le projet s'articule autour de trois points d'entrée documentés. Le premier est le modèle lui-même, hébergé sur Hugging Face sous RUC-DataLab/DeepAnalyze-8B, ce qui suppose une machine capable de servir un modèle de 8B, ou le recours à une API distante. Le deuxième est le jeu de données DataScience-Instruct-500K, utile uniquement si vous voulez affiner le modèle sur vos propres tâches. Le troisième est l'interface, avec deux générations : la version d'origine et la version 2 dans demo/chat_v2, dont le README dédié décrit l'interface, le support de l'API HeyWhale et l'exécution en bac à sable Docker. Deux modes d'accès complémentaires sont mentionnés dans les notes : un point de terminaison compatible avec l'API OpenAI depuis novembre 2025, et une interface en terminal en ligne de commande. Pour un essai rapide, la voie la plus courte consiste donc à demander une clé API via le formulaire indiqué dans le README et à viser l'endpoint compatible OpenAI, plutôt que de provisionner un GPU avant d'avoir validé le comportement sur vos données.

Le bac à sable Docker n'est pas un détail d'implémentation

Un agent qui écrit du code et l'exécute sur vos fichiers pose un problème de sécurité qui n'a rien de théorique : le code généré peut supprimer un fichier, écrire hors de son répertoire de travail, ou lancer une commande réseau. La note du 16 mars 2026 indique que la WebUI v2 prend en charge l'exécution de code en bac à sable Docker, ce qui répond directement à ce risque. C'est le point à vérifier en premier dans votre propre déploiement, car la documentation disponible décrit cette fonctionnalité sans en détailler la configuration : quelles limites de ressources, quel montage de volumes, quel accès réseau. Si vous faites tourner l'agent en dehors de ce bac à sable, vous exécutez du code non relu sur votre système de fichiers. Cette contrainte n'est pas propre à DeepAnalyze, mais elle est plus aiguë ici que dans un outil qui se contente de suggérer du code, puisque l'agent est justement conçu pour aller jusqu'à l'exécution. Le corollaire est qu'une partie de la valeur du projet dépend de l'isolation, pas seulement de la qualité du modèle.

Ce que l'agent ne sait pas faire, et pour qui c'est rédhibitoire

Le matériel fourni ne contient aucun résultat de benchmark reproductible, aucune mesure de taux de réussite sur des tâches réelles, et aucune comparaison chiffrée avec des approches existantes. C'est une limite documentaire, pas nécessairement une limite technique, mais elle a une conséquence pratique : vous ne pouvez pas dimensionner votre attente avant d'avoir essayé sur vos propres fichiers. Le format des données est une seconde limite. Le README cite CSV, Excel, JSON, XML, YAML, TXT et Markdown, et mentionne les bases de données sans préciser lesquelles. Si votre source est un entrepôt propriétaire, un flux temps réel ou un format binaire métier, rien n'indique que l'agent saura s'y connecter. Troisième point, la nature même du résultat. Un rapport produit par un agent est un artefact narratif : il explique ce qu'il a fait, mais rien ne garantit que la transformation intermédiaire soit correcte. Sur une analyse exploratoire, c'est acceptable. Sur un calcul qui alimente une décision financière ou un dossier réglementaire, un pipeline écrit à la main et versionné reste préférable, parce qu'il est relisible et testable. DeepAnalyze est un bon outil d'exploration et un mauvais outil de certification.

Ce qui le sépare d'un assistant de code classique

L'alternative la plus évidente est un assistant de génération de code couplé à un notebook, ou un framework d'agents généraliste auquel on donne un interpréteur Python. La différence tient à l'entraînement. Un assistant généraliste produit du code correct sur une question bien posée ; il ne sait pas nécessairement parcourir un répertoire de cent fichiers pour trouver la table pertinente, ni enchaîner préparation, modélisation et rédaction dans un même flux. DeepAnalyze revendique précisément ce comportement, et l'a entraîné sur 500 000 exemples de science des données plutôt que de compter sur le prompt. L'équipe a d'ailleurs publié CoDA-Bench pour mesurer cette compétence chez les agents en général, ce qui suggère qu'elle considère la découverte de données comme le point difficile. L'arbitrage est clair : un assistant de code reste plus prévisible et plus simple à intégrer dans une revue de code, tandis que DeepAnalyze déplace l'effort de l'écriture vers la vérification du résultat final. Si votre tâche tient en dix lignes de pandas que vous savez déjà écrire, l'agent n'apporte rien et ajoute une couche d'incertitude.

Maintenance, licence et coût de suivi

Le dépôt est publié sous licence MIT, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver la mention de copyright et le texte de la licence. Le modèle et le jeu de données sont hébergés séparément sur Hugging Face et peuvent avoir leurs propres conditions : vérifiez-les avant un usage en production, car la licence du code ne couvre pas automatiquement les poids. Le rythme de publication est soutenu : API en novembre 2025, endpoint compatible OpenAI le même mois, clé API en décembre, WebUI v2 en mars 2026, DA-Studio en mai, CoDA-Bench en juin, DeepPrep annoncé pour juillet. Cette cadence a un revers. Chaque version de l'interface peut modifier la configuration du bac à sable ou le format des échanges avec l'API, et rien dans le matériel fourni n'indique une politique de compatibilité entre versions. Un déploiement qui s'appuie sur demo/chat_v2 devra donc suivre les changements du dépôt plutôt que de figer une version. Le coût réel se situe là : moins dans l'installation que dans le suivi des évolutions et dans la mise à jour du bac à sable à chaque nouvelle publication.

Conclusion éditoriale

DeepAnalyze convient aux équipes qui disposent déjà d'un GPU pour servir un modèle de 8B et qui veulent expérimenter l'analyse de données pilotée par agent, sur des fichiers hétérogènes et sans écrire de pipeline à la main. Il ne convient pas à un contexte réglementé où chaque transformation doit être auditée ligne par ligne, ni à une chaîne de production où l'on attend un résultat déterministe. Avant d'aller plus loin, vérifiez trois choses dans le dépôt : le contenu réel de demo/chat_v2, la présence effective de l'exécution de code en bac à sable Docker annoncée le 16 mars 2026, et les paramètres de génération utilisés par le script d'inférence, car c'est là que se joue la reproductibilité de vos analyses.

Sources officielles

1. Issues
2. License: MIT
3. Project website
4. README
5. ruc-datalab/DeepAnalyze on GitHub