ZenML : orchestrer des pipelines Python sur une infrastructure que l'on choisit

Le problème : du code Python qui ne sait pas où il tourne

Le README situe la cible sans ambiguïté : des ingénieurs ML ou IA en entreprise, sur des cas d'usage de ML classique, de workflows LLM ou d'agents. Le point de départ est un pipeline écrit en Python, par exemple l'entraînement d'un modèle ou une boucle agentique. Le point d'arrivée est le même pipeline exécuté sur une infrastructure que l'auteur du pipeline n'a pas choisie au moment de l'écrire. ZenML nomme ce second élément une stack. La séparation entre les deux est l'argument central du projet : le code décrit ce qui doit être fait, la stack décrit où et avec quels outils. Ce n'est pas un détail de vocabulaire. Une équipe qui garde cette frontière nette peut changer de backend sans réécrire ses étapes. Une équipe qui la brouille, en appelant directement un service cloud depuis une étape, perd exactement ce que le cadre apporte.

Pipelines, steps et artefacts : ce que le dépôt expose

Le README mentionne les concepts couverts par l'exemple quickstart : pipelines, steps, artefacts, snapshots et déploiements. Un pipeline regroupe des steps, chaque step étant une unité de code Python. Les artefacts sont les sorties qui circulent entre steps, et c'est par eux que passe le suivi : le README indique que ZenML enregistre les exécutions avec métriques, journaux et métadonnées. Les snapshots figent une configuration de pipeline, et les déploiements concernent la mise en service. Cette liste est ce que le matériel fourni permet d'affirmer. Les détails de sérialisation des artefacts, la politique de rétention des métadonnées et le format de stockage des snapshots ne figurent pas dans le README : il faut les chercher dans la documentation produit, à l'adresse docs.zenml.io, ou dans la référence du SDK sur sdkdocs.zenml.io. Je ne peux pas les décrire ici sans les inventer.

Architecture client-serveur et conteneurisation automatique

Le README décrit une architecture client-serveur avec un tableau de bord web séparé, hébergé dans le dépôt zenml-io/zenml-dashboard. Deux modes sont proposés. En développement local, pip install "zenml[local]" fait tourner client et serveur sur la même machine. En production, le serveur est déployé à part et le client s'y connecte avec pip install zenml suivi de zenml login <server-url>. Le README précise aussi que pip install zenml installe un client plus léger, l'extra server ajoutant les capacités serveur. Côté mécanique, le README annonce que ZenML conteneurise et trace automatiquement le code, et qu'il abstrait la complexité de l'infrastructure. C'est la partie la plus difficile à évaluer sans exécution : la conteneurisation automatique implique une reconstruction à chaque changement de dépendances, et le coût de cette reconstruction dépend de la stack visée. Le README ne donne aucun chiffre à ce sujet, et je n'en avancerai pas.

Mise en route : trois commandes et un exemple

La séquence documentée tient en trois commandes. pip install "zenml[server]" installe le paquet avec les capacités serveur. zenml init initialise le dépôt ZenML. zenml login démarre un serveur local ou connecte le client à un serveur distant. Le README recommande ensuite de commencer par l'exemple quickstart, situé dans examples/quickstart/, qui illustre pipelines, steps, artefacts, snapshots et déploiements. Deux autres exemples sont cités : examples/agent_comparison/, qui compare des agents avec des workflows LangGraph, une intégration LiteLLM et des visualisations via des materializers personnalisés, et examples/deploying_ml_model/. Les intégrations mentionnées dans le README incluent MLflow, Langgraph, Langfuse, Sagemaker et GCP Vertex. Cette liste est celle du README, pas un inventaire exhaustif. Pour une stack absente de cette liste, la documentation des stacks reste la seule source à consulter avant de planifier un déploiement.

Ce que la documentation ne tranche pas

Trois zones restent floues dans le matériel fourni. D'abord la gestion des secrets : le README ne dit rien sur la manière dont les identifiants des stacks sont stockés ou injectés dans les steps. Ensuite le mode de défaillance : rien n'indique ce qui se passe quand un serveur distant devient injoignable pendant une exécution, ni si les runs reprennent ou échouent. Enfin la compatibilité entre versions : le README ne décrit aucune politique de dépréciation, alors que les releases 0.96.2, 0.96.3 et 0.96.4 se sont enchaînées entre le 17 juillet et le 4 septembre 2026, soit environ une par mois sur cette fenêtre. Ce rythme n'est pas un défaut en soi, mais il implique de figer une version dans vos dépendances plutôt que de suivre la branche principale. Aucune de ces trois zones ne peut être résolue à partir du README seul.

ZenML face à un orchestrateur généraliste

L'alternative la plus directe est un orchestrateur de workflows généraliste, par exemple Airflow. La différence d'approche est nette. Airflow organise des tâches selon un graphe orienté et un planificateur, avec une sémantique temporelle : les DAG s'exécutent selon un calendrier, les tâches sont des opérateurs, et la donnée circule surtout par des chemins de fichiers ou des connexions configurées. ZenML part de l'inverse : un pipeline est du code Python exécuté, les steps sont des fonctions, et les artefacts sont des objets typés suivis par le cadre. La conséquence pratique est qu'Airflow excelle sur la planification récurrente et l'orchestration hétérogène, tandis que ZenML vise l'itération sur du code de modèle ou d'agent, avec un suivi des sorties. Une équipe qui a surtout besoin de déclencher des traitements à heure fixe sur des systèmes variés n'a pas de raison particulière de préférer ZenML. Une équipe qui entraîne et évalue des modèles en Python, et qui veut suivre les artefacts entre les étapes, est dans le cas visé.

Coût de maintenance et licence

Le projet n'est pas archivé et la dernière poussée sur la branche main date du 9 septembre 2026, ce qui indique une activité de développement continue. Le coût de maintenance se répartit sur deux postes. Le premier est l'infrastructure : un serveur ZenML doit être déployé, sauvegardé et mis à jour, et le tableau de bord est un composant distinct dans un autre dépôt. Le second est la montée de version : avec des releases rapprochées, chaque mise à jour demande de relire le changelog publié à docs.zenml.io/changelog avant de changer d'épinglage. Sur le plan juridique, le dépôt est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec des obligations de conservation des mentions de licence et d'avis. Le README renvoie par ailleurs vers une offre ZenML Pro hébergée. La frontière exacte entre ce qui relève de l'édition open source et ce qui relève de l'offre Pro n'est pas décrite dans le matériel fourni. Ce point mérite une vérification directe avant tout choix d'architecture, et je ne donne ici aucun avis juridique.

Conclusion éditoriale

ZenML convient aux équipes qui écrivent déjà du Python pour l'entraînement de modèles ou pour des boucles d'agents et qui veulent détacher ce code de la machine qui l'exécute. Il convient mal à un notebook unique, à un script cron de quelques dizaines de lignes, ou à quiconque refuse de faire tourner un serveur, même local, à côté de son code. Avant d'adopter, vérifiez trois choses dans votre propre environnement : que pip install "zenml[server]" puis zenml init et zenml login aboutissent à un serveur local fonctionnel, que la stack que vous visez figure bien dans la documentation des stacks, et que la version épinglée correspond à celle que vous testerez en production, sachant que les releases 0.96.2, 0.96.3 et 0.96.4 se sont succédé entre le 17 juillet et le 4 septembre 2026.

Sources officielles

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. zenml-io/zenml on GitHub