Prompt flow : un DAG YAML pour industrialiser les applications LLM

Le problème que le projet prend en charge

Une application LLM se compose rarement d'un seul appel. Il y a un gabarit de prompt, une connexion à un modèle, du code Python de post-traitement, des entrées et des sorties typées. Sans cadre commun, chacun recolle ces morceaux dans un script, et la revue de code devient difficile parce que le prompt vit dans une chaîne de caractères au milieu d'une fonction. Prompt flow impose un format de description. Le README annonce une suite d'outils pour couvrir le cycle complet : idéation, prototypage, test, évaluation, déploiement et supervision. Le public visé est donc l'ingénieur qui doit faire évoluer un prototype jetable vers quelque chose qu'une équipe peut relire, tester et redéployer. Les topics du dépôt le confirment : prompt engineering, applications IA, GPT, ChatGPT. Le projet est en Python, publié sous licence MIT, et la branche par défaut est main.

Un DAG décrit dans flow.dag.yaml

Le mécanisme central tient dans un fichier. Le README indique que le dossier généré contient un flow.dag.yaml qui décrit le flux : entrées et sorties, nœuds, connexion et modèle. Les nœuds relient des LLM, des prompts, du code Python et d'autres outils. C'est une architecture en graphe orienté acyclique, pas un script linéaire, ce qui permet de tester un nœud isolément et de réutiliser un même nœud dans plusieurs flux. Le fichier est aussi le point d'ancrage du reste de la chaîne : la même description sert au test interactif en local, à l'exécution sur un jeu de données plus large, puis au déploiement. C'est le choix de conception le plus structurant du projet. Il rend le flux diffable dans Git, et il rend le prompt visible dans une revue de code. En contrepartie, tout ce qui ne se laisse pas décrire comme un graphe statique devient difficile à exprimer. Une boucle d'agent qui décide à l'exécution quel outil appeler ne rentre pas naturellement dans ce moule, et la documentation consultée ne propose pas de mécanisme de contrôle de flux dynamique.

Mise en route : trois commandes et une connexion

L'installation passe par deux paquets : pip install promptflow promptflow-tools. La documentation recommande Python entre 3.9 et 3.11. Le README propose aussi un environnement préconstruit via GitHub Codespaces, ce qui évite de gérer l'interpréteur pour un premier essai. Ensuite, pf flow init --flow ./my_chatbot --type chat crée le dossier et les fichiers nécessaires. La connexion au modèle se déclare séparément, avec un fichier YAML de référence. Pour OpenAI : pf connection create --file ./my_chatbot/openai.yaml --set api_key=<your_api_key> --name open_ai_connection. Pour Azure OpenAI, la commande ajoute api_base : pf connection create --file ./my_chatbot/azure_openai.yaml --set api_key=<your_api_key> api_base=<your_api_base> --name open_ai_connection. Le README signale que l'option --set évite de modifier le fichier YAML, ce qui compte si ce fichier est versionné. Le test interactif se lance avec pf flow test --flow ./my_chatbot --interactive, et Ctrl + C met fin à la session. Une réserve pratique : le nœud chat généré référence une connexion nommée open_ai_connection et un modèle gpt-35-turbo dans le champ deployment_name. Si votre déploiement Azure porte un autre nom, il faut éditer ce champ avant que le flux ne fonctionne.

Évaluation et intégration continue

Le README présente l'évaluation comme une étape distincte : mesurer la qualité et la performance du flux sur des jeux de données plus volumineux, puis intégrer ces tests au système CI/CD. C'est là que le format déclaratif paie, parce qu'un flux décrit en YAML peut être exécuté de façon non interactive dans un pipeline, sans intervention dans une interface graphique. Le projet fournit un tutoriel de quinze minutes consacré à l'amélioration de la qualité, qui enchaîne réglage du prompt, test par lots et évaluation. Un autre exemple, Chat with PDF, va jusqu'à la construction d'une application de conversation avec métriques d'évaluation. Je n'ai pas exécuté ces tutoriels et je ne peux donc pas dire ce que produisent les métriques ni si elles sont stables d'une exécution à l'autre. Ce que le matériel fourni ne tranche pas non plus : le coût d'un passage d'évaluation sur un grand jeu de données, et la façon dont les résultats sont comparés entre deux versions du flux. Ces deux points conditionnent pourtant l'usage réel en CI.

Ce que la documentation ne couvre pas

Le README est un document d'entrée, pas un manuel d'exploitation. Plusieurs zones restent floues à sa lecture. La supervision en production est annoncée dans la description du dépôt, mais le README ne détaille ni les métriques remontées, ni le format des traces, ni le backend qui les stocke. Le traçage des interactions avec les LLM est présenté comme une fonctionnalité avec un lien vers un guide, sans description du mécanisme dans le README lui-même. Autre point : la collaboration en équipe passe par la version cloud dans Azure AI, présentée comme optionnelle mais fortement recommandée. Cette recommandation crée une dépendance de fait à un service propriétaire pour les fonctions collaboratives, alors que le paquet lui-même est sous MIT. Le README ne dit pas quelles fonctionnalités restent disponibles hors de ce service. C'est la question à poser avant de standardiser une équipe sur l'outil.

Prompt flow face à LangChain

LangChain est l'alternative la plus évidente pour un lecteur Python. La différence tient au format de description, pas aux fonctionnalités. LangChain s'utilise en composant des objets dans du code : un graphe se construit par des appels de méthodes, et la structure du flux n'existe qu'à l'exécution. Prompt flow déplace cette structure dans un fichier YAML séparé du code. Conséquence directe : chez LangChain, faire évoluer le prompt signifie modifier du Python et redéployer du code, tandis qu'avec Prompt flow le prompt et la topologie vivent dans un artefact que l'outil de ligne de commande sait lire et exécuter. L'inverse est vrai aussi. LangChain gère sans friction les chaînes construites dynamiquement et les agents qui choisissent leurs outils en cours d'exécution, ce qu'un DAG statique exprime mal. Le choix se résume donc à la nature de votre flux : topologie connue à l'avance et revue par des humains d'un côté, comportement décidé à l'exécution de l'autre. L'extension VS Code mentionnée dans le README, un flow designer graphique, n'existe pas dans l'écosystème LangChain au même degré d'intégration, mais elle ne compense pas cette différence de modèle.

Coût de maintenance et licence

Le rythme de publication est un indicateur concret du coût de suivi. Les versions listées s'enchaînent : 1.16.2 en novembre 2024, 1.17.0 le 6 janvier 2025, 1.17.1 le 9 janvier 2025. Une cadence de correctifs aussi rapprochée sur une même série signifie qu'il faut prévoir une mise à jour régulière, et que les dépendances épinglées dans un projet devront être relevées souvent. Le dépôt n'est pas archivé et le dernier envoi de code date du 26 août 2026, ce qui indique une maintenance active à cette date. La licence MIT couvre le code du dépôt : elle autorise l'usage commercial et la modification, avec conservation de l'avis de licence. Elle ne dit rien des conditions d'utilisation du service cloud Azure AI, qui relève d'un contrat distinct. Deux paquets sont à suivre séparément, promptflow et promptflow-tools, et leurs numéros de version peuvent diverger. Je ne peux pas évaluer le coût réel d'une montée de version, faute d'avoir lu les notes de version détaillées.

Conclusion éditoriale

Adoptez Prompt flow si vous voulez versionner un flux LLM sous forme de fichier YAML lisible et l'exécuter en ligne de commande, sans écrire vous-même la plomberie des connexions. Passez votre chemin si votre application est un agent à boucle d'outils dynamique : un DAG déclaratif n'est pas le bon modèle. Avant de vous engager, ouvrez le flow.dag.yaml généré par pf flow init --type chat et vérifiez que le champ connection et le champ deployment_name correspondent bien à vos ressources, car le modèle par défaut est gpt-35-turbo et la connexion attendue s'appelle open_ai_connection.

Sources officielles

1. License: MIT
2. microsoft/promptflow on GitHub
3. Project website
4. README
5. Releases