LLM workflows : 7 étapes pour des flux fiables et mesurés

Mis à jour le 12 octobre 2026

Les LLM workflows sont des enchaînements d’étapes (prompt, code, appels au modèle, évaluation) que l’on peut rejouer, tracer et mesurer. Pour qu’un workflow soit fiable, il faut trois choses : des prompts versionnés, des traces de chaque exécution et un jeu de tests qui note les réponses. Voici la méthode que je recommande, avec Promptflow comme exemple, et une réserve importante sur son avenir.

Qu’est-ce qu’un LLM workflow ?

Un LLM workflow est un pipeline qui orchestre un ou plusieurs appels à un modèle de langage avec du code autour : préparation des données, construction du prompt, appel du modèle, post-traitement, puis évaluation. Sa valeur tient à la reproductibilité : on peut relancer le même scénario sur 50 cas et comparer deux versions d’un prompt chiffres en main.

Un appel isolé à une API ne suffit pas en production. Dès qu’un prompt change ou qu’un modèle est mis à jour, vous devez savoir si la qualité monte ou baisse. C’est le rôle du workflow et de son évaluation.

Promptflow est-il encore un bon choix en 2026 ?

Promptflow reste utilisable pour apprendre la méthode, mais pas pour démarrer un projet de long terme. La documentation officielle indique que le développement de nouvelles fonctionnalités s’est arrêté le 20 avril 2026, avec un passage en lecture seule le 20 avril 2027. Microsoft recommande une migration vers Microsoft Agent Framework.

Concrètement : vos flux existants continuent de tourner jusqu’à cette date. Si vous créez un nouveau projet, gardez les principes de cet article (prompt isolé, traces, jeu de test, juge) et vérifiez que l’outil choisi les couvre. Les commandes ci-dessous valent surtout pour comprendre et maintenir l’existant.

Quelles sont les étapes pour construire un LLM workflow fiable ?

Il y a sept étapes, de l’environnement jusqu’à l’évaluation. Chacune réduit une source d’erreur précise : dépendances instables, prompts dispersés, étapes opaques ou régressions invisibles. Le tableau résume l’ensemble, le détail suit.

Étape	Objectif	Livrable
1. Environnement	Isoler les dépendances et les secrets	venv, variables d’environnement
2. Espace de travail	Ranger prompts, code et données	Dossier structuré, dépôt Git
3. Fichier Prompty	Isoler le prompt et ses paramètres	Fichier .prompty
4. Flux flexible	Mélanger code déterministe et LLM	Fonction ou classe Python
5. Traçage	Voir chaque étape exécutée	Traces consultables
6. Exécution unitaire et par lots	Tester sur de vrais cas	Fichier JSONL, résultats de run
7. Évaluation	Mesurer la qualité à chaque changement	Métriques comparables

1. Configurer l’environnement

Créez un environnement virtuel Python, installez promptflow et promptflow-tools (c’est la commande d’installation indiquée sur le dépôt GitHub du projet), puis stockez la clé API du fournisseur dans une variable d’environnement. Une clé ne doit jamais apparaître dans un fichier versionné.

python -m venv .venv
source .venv/bin/activate
pip install promptflow promptflow-tools
export OPENAI_API_KEY="..."

2. Organiser un espace de travail propre

Un dossier par workflow, avec le prompt, le code, un jeu de données de test et un fichier de dépendances. Mettez le tout dans Git : un prompt modifié sans historique est une régression que personne ne saura expliquer trois semaines plus tard.

3. Définir un fichier Prompty

Un fichier .prompty est un fichier Markdown en deux parties, d’après la documentation Promptflow : un en-tête YAML (nom, modèle, paramètres comme temperature ou max_tokens, entrées déclarées) et un gabarit de prompt au format Jinja avec des sections system: et user:. Les secrets se lisent via ${env:NOM_DE_VARIABLE}.

from promptflow.core import Prompty

p = Prompty.load(source="resume.prompty")
print(p(question="Quelle est la capitale de la France ?"))

Pour un test rapide en ligne de commande : pf flow test --flow resume.prompty. La documentation classe cette fonction comme expérimentale, donc son comportement peut changer.

4. Concevoir un flux flexible

Un flux flexible (flex flow) est une fonction ou une classe Python qui sert de point d’entrée à votre application, selon la page dédiée. Un fichier flow.flex.yaml optionnel désigne cette entrée. L’intérêt : faire le travail déterministe en code (nettoyage, calcul d’un indice, récupération de documents) puis injecter le résultat dans le prompt. Tout ce qui peut se calculer sans modèle doit se calculer sans modèle.

5. Activer le traçage

Le traçage enregistre les appels de fonctions et les appels au modèle pour que vous puissiez voir où une réponse a dérapé. Selon le guide de traçage, on installe promptflow-tracing, on appelle start_trace() avant de créer le client OpenAI, et on ajoute le décorateur @trace sur ses propres fonctions. Les traces suivent la spécification OpenTelemetry, et le script affiche une URL pour les consulter. Cette fonction est elle aussi marquée expérimentale.

6. Exécuter des requêtes individuelles puis par lots

Testez d’abord un cas à la main, puis lancez un lot sur un fichier JSONL qui contient vos cas réels, y compris les cas difficiles (entrées vides, langue inattendue, texte très long). La commande documentée est pf run create --flow chemin/du/flow --data donnees.jsonl. Un lot de 30 cas variés apprend plus qu’une demi-journée de tests manuels.

7. Mettre en place une évaluation

L’évaluation est elle-même un flux, lancé après le lot. Le guide officiel montre un run d’évaluation relié au run précédent avec l’option --run, puis pf run show-metrics pour lire les métriques (par exemple une exactitude). L’exemple du guide compare une prédiction à une réponse attendue, sans modèle. Pour noter des textes libres, on construit un évaluateur qui s’appuie sur un LLM, ce qu’on appelle un LLM comme juge.

Comment utiliser un LLM comme juge sans se tromper ?

Un LLM juge note les réponses d’un autre modèle selon une grille. Il fonctionne bien quand la grille est précise et courte, par exemple « la réponse cite-t-elle le document fourni ? oui ou non ». Il fonctionne mal sur des critères vagues comme « la réponse est-elle bonne ? ».

• Un critère par évaluation, avec une sortie fermée (oui/non ou note de 1 à 5 définie).
• Une température basse sur le juge, pour des notes stables d’un passage à l’autre.
• Un petit échantillon relu à la main, pour vérifier que le juge ne se trompe pas systématiquement.
• Le même jeu de test avant et après chaque modification de prompt.

Quelles erreurs fréquentes éviter ?

Les échecs que je rencontre le plus souvent dans ce type de projet ne viennent pas du modèle mais de la méthode : on teste sur trois exemples flatteurs, on change deux choses à la fois, ou on ne garde aucune trace. Cette liste sert de contrôle avant toute mise en production.

• Prompt écrit en dur dans le code, impossible à comparer entre deux versions.
• Jeu de test composé uniquement de cas faciles.
• Plusieurs modifications simultanées (prompt, modèle, paramètres) : on ne sait plus ce qui a joué.
• Clé API commitée dans le dépôt.
• Aucun traçage : en cas d’erreur, on relit la réponse sans voir les étapes qui y ont mené.
• Choix d’un outil sans regarder son calendrier de maintenance, ce qui est précisément le cas de Promptflow aujourd’hui.

Questions fréquentes

Qu’est-ce qu’un LLM workflow ?

C’est un enchaînement d’étapes qui orchestre un modèle de langage avec du code : préparation des données, prompt, appel au modèle, post-traitement et évaluation. Il rend l’usage du modèle reproductible, traçable et mesurable.

Comment construire un LLM workflow fiable ?

Isolez l’environnement et les secrets, rangez le prompt dans un fichier dédié, faites le travail déterministe en code, activez le traçage, testez par lots sur de vrais cas, puis évaluez à chaque changement avec le même jeu de données.

Pourquoi mettre ses prompts dans un fichier dédié ?

Un prompt isolé se versionne, se relit et se compare. Avec Promptflow, le format .prompty regroupe le gabarit, le modèle et les paramètres au même endroit, séparés du reste du code.

Qu’est-ce qu’un flux flexible ?

C’est un flux dont le point d’entrée est une fonction ou une classe Python, d’après la documentation Promptflow. Il permet de combiner du code classique et des appels au modèle sans passer par un graphe à construire à la main. Cette fonction est marquée expérimentale.

Faut-il encore utiliser Promptflow ?

Pour maintenir un flux existant, oui, jusqu’au 20 avril 2027 selon la documentation officielle. Pour un nouveau projet, mieux vaut regarder l’outil recommandé par Microsoft (Agent Framework) et reprendre les mêmes principes de traçage et d’évaluation.