datapizza-ai : un cadre GenAI en Python qui privilégie l'inspection à la magie

Le problème visé : garder la boucle d'agent sous vos yeux

Le README résume l'intention en une ligne : « A no-fluff GenAI framework that gets your agents from dev to prod, fast ». Traduction opérationnelle : quand un agent appelle trois outils, change de modèle en cours de route et renvoie une réponse fausse, vous voulez savoir à quelle étape cela s'est produit sans instrumenter vous-même chaque appel. Le projet s'adresse donc à des équipes qui écrivent déjà du Python et qui refusent de déléguer l'orchestration à une couche opaque. Le public visé n'est pas celui qui découvre les LLM : c'est celui qui a déjà une base de code, un fournisseur de modèle imposé par sa direction, et qui cherche une bibliothèque où la boucle d'appel reste inspectable. Le README positionne explicitement l'outil comme « Built by Engineers, trusted by Engineers », ce qui est un argument de positionnement, pas une preuve de qualité.

Un paquet central, des clients et des outils en paquets séparés

Le point d'architecture le plus concret se lit dans les commandes d'installation. Le paquet principal est datapizza-ai, mais les fournisseurs de modèles vivent dans des distributions distinctes : datapizza-ai-clients-openai, datapizza-ai-clients-google, datapizza-ai-clients-anthropic. Même logique pour les outils, avec datapizza-ai-tools-duckduckgo. Cette séparation a une conséquence directe : installer datapizza-ai seul ne vous donne aucun client utilisable. Vous payez en étapes d'installation ce que vous gagnez en surface de dépendances. Les imports suivent cette découpe, depuis datapizza.clients.openai, datapizza.agents ou datapizza.tools. Le traçage, lui, est exposé via datapizza.tracing et la classe ContextTracing. L'ensemble est publié sous licence MIT, ce qui autorise la modification et la redistribution, y compris dans un produit propriétaire, à condition de conserver la notice de licence. Ce n'est pas un avis juridique : faites relire la notice par qui de droit si votre produit embarque la bibliothèque.

Un agent, un client, une liste d'outils : le mécanisme minimal

Le README donne un exemple complet d'agent. On déclare une fonction Python décorée par @tool, on instancie OpenAIClient avec une clé d'API, puis on construit Agent(name="assistant", client=client, tools=[get_weather]). L'appel se fait par agent.run("What is the weather in Rome?"). Le mécanisme sous-jacent, tel que le matériel le décrit, est celui d'un client qui reçoit la question, décide d'appeler l'outil déclaré, récupère la valeur de retour de la fonction Python, puis formule la réponse. Le commentaire du README indique la sortie attendue : « The weather in Rome is sunny ». Deux détails méritent l'attention. D'abord, la fonction outil est du Python ordinaire : elle peut lever une exception, faire un appel réseau lent ou renvoyer une chaîne mal formée, et rien dans le README ne décrit la politique de reprise dans ces cas. Ensuite, le client est passé à l'agent à la construction : changer de fournisseur suppose de reconstruire l'agent, pas de muter une propriété. C'est cohérent avec la promesse d'interfaces claires, mais cela signifie que la configuration du modèle est fixée au moment où vous câblez l'objet.

Les agents peuvent s'appeler entre eux, sans contrat déclaré

L'exemple multi-agents du README est le passage le plus intéressant du point de vue de la conception. Trois agents partagent le même client : weather_expert avec un outil météo, web_search_expert avec DuckDuckGoSearchTool, et planner sans aucun outil. La ligne qui les relie est planner_agent.can_call([weather_agent, web_search_agent]). Le planner ne détient pas les outils de ses subordonnés : il détient le droit de les invoquer. C'est une hiérarchie explicite, et c'est plus lisible qu'un routage implicite par description. La limite est ailleurs. Rien dans le matériel fourni ne décrit ce qui se passe quand un agent appelé échoue, ni comment le planner arbitre entre deux subordonnés qui répondent tous les deux. Le README ne documente pas non plus de profondeur maximale de récursion. Si vous construisez une chaîne d'agents à plusieurs niveaux, vous devrez donc tester vous-même le comportement en cas de boucle, car la documentation ne l'annonce pas.

Le traçage comme argument central, et ce qu'il montre vraiment

L'observabilité est présentée comme une exigence de premier plan, et le README cite OpenTelemetry comme base d'instrumentation. L'usage tient en un bloc : on enveloppe l'appel dans with ContextTracing().trace("my_ai_operation"), puis on lit le résumé. Le rendu montré dans le README affiche un nombre de spans, une durée, puis un tableau avec le modèle, les prompt tokens, les completion tokens et les cached tokens. C'est le genre de sortie qui répond à la question « pourquoi cette requête a-t-elle coûté cher », pas seulement « pourquoi a-t-elle échoué ». Le README mentionne aussi un basculement optionnel pour journaliser les entrées, les sorties et le contexte en mémoire, ainsi que la possibilité de créer des spans personnalisés pour découper des phases fines. Un avertissement de bon sens : journaliser les entrées et le contexte mémoire revient à écrire du contenu utilisateur dans vos journaux. Le README présente la fonction, il ne discute pas de cette conséquence.

Ingestion documentaire : le pipeline existe, les détails manquent

La section sur l'ingestion annonce le traitement de PDF, DOCX et images via Azure AI et Docling, un découpage en chunks sensible au contexte, l'embedding et un reranking intégré, avec Cohere cité en exemple. Le README décrit la chaîne dans son ensemble, mais le texte fourni s'interrompt au milieu de la phrase qui devait détailler le découpage. Impossible donc de vérifier ici les paramètres de chunking, la taille par défaut ou la façon dont les métadonnées de document sont conservées jusqu'à la recherche. C'est une lacune du matériel, pas nécessairement du projet : la documentation hébergée sur docs.datapizza.ai est l'endroit où chercher ces valeurs. En l'état, considérez la partie RAG comme annoncée mais non vérifiable depuis le dépôt seul, et prévoyez un test sur vos propres PDF avant de bâtir dessus.

Quand choisir autre chose : LangChain, LlamaIndex et la question du périmètre

La différence avec LangChain tient à la surface. LangChain vise l'intégration large : des dizaines de chargeurs de documents, de vector stores et de fournisseurs, au prix d'une couche d'abstraction que vous subissez dès que vous sortez du chemin prévu. datapizza-ai prend le pari inverse, avec cinq fournisseurs listés dans le README (OpenAI, Google Gemini, Anthropic, Mistral, Azure) et des paquets optionnels à installer un par un. Face à LlamaIndex, l'écart porte sur le centre de gravité : LlamaIndex organise tout autour de l'index et de la récupération, là où datapizza-ai place l'agent et le client au premier plan, le RAG venant ensuite. Si votre besoin principal est de brancher un vector store exotique ou un modèle servi en interne, la liste courte de clients du README devient un obstacle : vous écrirez l'adaptateur vous-même. Le projet n'est pas non plus le bon outil si vous cherchez une plateforme avec interface graphique d'évaluation et jeu de données versionné : rien dans le matériel fourni ne décrit cela.

Coût de maintenance : une API encore jeune

Les versions publiées racontent une histoire utile. v0.0.7 en octobre 2025, v0.0.9 en novembre 2025, puis v0.1.0 en mars 2026. Le passage de 0.0.x à 0.1.0 signale une stabilisation partielle, pas une garantie de compatibilité : en version 0.x, une rupture d'API entre deux mineures reste possible. Le dépôt a reçu des commits jusqu'en mai 2026, donc le projet est actif, mais l'absence de version 1.0 signifie que vous devez épingler vos dépendances, par exemple en fixant datapizza-ai==0.1.0 et la version correspondante du client, plutôt que de laisser pip résoudre à chaque déploiement. La séparation en paquets multiples ajoute un coût de suivi : une montée de version du noyau peut exiger d'aligner simultanément datapizza-ai-clients-openai et datapizza-ai-tools-duckduckgo. La licence MIT limite le risque juridique de ce suivi, elle ne le supprime pas. Enfin, le README évoque une « migration-friendly » depuis d'autres frameworks, sans fournir de guide de migration dans le matériel disponible : traitez cette affirmation comme une intention, pas comme un chemin balisé.

Conclusion éditoriale

Adoptez datapizza-ai si vous voulez garder la boucle d'agent et le pipeline d'ingestion dans du Python lisible, avec un traçage OpenTelemetry standard et des clients interchangeables. Évitez-le si vous avez besoin d'un écosystème d'intégrations large : le README ne liste que OpenAI, Google Gemini, Anthropic, Mistral et Azure, et l'API a bougé entre v0.0.7 et v0.1.0. Avant de vous engager, vérifiez deux choses concrètes : la compatibilité de votre version de Python avec l'exigence 3.10+ annoncée par le badge du README, et le contenu réel de datapizza-ai-clients-<votre fournisseur> sur PyPI, puisque l'installation du paquet principal ne suffit pas à obtenir un client.

Sources officielles

1. datapizza-labs/datapizza-ai on GitHub
2. License: MIT
3. Project website
4. README
5. Releases