Prompt Flow: The Complete Guide

Salut, c'est Alex de DEV STORIES DOT EU. Prompt Flow : Le guide complet, épisode 1 sur 14. La plupart des libraries d'IA essaient d'abstraire la complexité en cachant tes prompts au fond de fonctions wrapper. Mais quand tu passes en production, ces prompts sont exactement ce que tu as besoin de contrôler. C'est la philosophie de base de Prompt Flow. Commençons par dissiper un malentendu courant. Prompt Flow n'est pas un framework comme LangChain. LangChain est un framework de développement qui fournit des chains et des agents pré-construits, qui encapsulent souvent les prompts sous-jacents. Prompt Flow est une suite d'outils conçue pour l'expérimentation et l'évaluation. Il existe parce que le principe classique d'encapsulation en ingénierie logicielle devient un vrai handicap quand tu développes des applications avec des grands modèles de langage. En programmation classique, tu caches la logique complexe derrière une interface de fonction propre. Tu n'as pas besoin de savoir comment la fonction marche en interne, tu t'intéresses juste à ce qu'elle retourne. Mais les prompts sont très volatils. Ce n'est pas de la logique statique. Si tu passes ton modèle d'une version à une autre, un prompt qui marchait parfaitement hier peut planter aujourd'hui. Si tu utilises une library tierce opaque pour résumer des documents, et que le prompt sous-jacent est verrouillé à l'intérieur de cette library, tu ne peux pas corriger un mauvais résumé. Tu es entièrement dépendant des mainteneurs de la library. Prompt Flow inverse ce design pattern en exposant les prompts. Il les traite comme des assets développeur à part entière. Tu dois les voir, les tuner et les versionner en continu. Au lieu d'une boîte noire, tu obtiens une toolchain transparente où tu contrôles exactement le texte et les variables qui entrent dans le modèle de langage. C'est ça le plus important. Parce que les prompts sont volatils, développer des applications d'IA demande une façon de travailler fondamentalement nouvelle. Dans le logiciel classique, tu écris des tests unitaires. Tu fais une assertion pour vérifier qu'un input spécifique produit un output spécifique. Les modèles de langage sont probabilistes, ce qui veut dire qu'ils ne donnent pas de réponses déterministes. Tu ne peux pas écrire une simple assertion pour vérifier si un e-mail généré est poli ou si un résumé est précis. À la place, tu dois adopter un workflow centré sur l'évaluation. Tu dois faire tourner ton prompt sur des centaines d'exemples variés et mesurer des métriques comme la pertinence ou la précision du formatage. Prompt Flow est construit directement autour de ce workflow. Il intègre le tuning de prompts avec l'évaluation de masse. Quand tu changes un seul mot dans ton prompt, les outils t'aident à voir statistiquement si ce changement a amélioré ton taux de succès sur ton dataset ou s'il l'a dégradé. Le dernier pilier de cette philosophie, c'est d'optimiser pour la visibilité. Les applications d'IA sont rarement un seul appel d'API. Ce sont des graphes d'exécution complexes. Tu peux prendre une question utilisateur, requêter une base de données vectorielle, formater les données récupérées, les injecter dans un prompt, et ensuite appeler le modèle. Quand la réponse finale est fausse, tu as besoin de savoir exactement où la chain s'est cassée. Prompt Flow rend ce graphe d'exécution visible. Tu peux inspecter chaque nœud pour voir les inputs et outputs précis à cette étape exacte du processus, ce qui rend le debugging super simple. La chose la plus importante à retenir, c'est que les prompts sont des variables vivantes et volatiles qui demandent une observation constante, pas du code statique que tu peux écrire une fois et cacher dans un coin. Si tu trouves ces épisodes utiles et que tu veux soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon. C'est tout pour cet épisode. Merci d'avoir écouté, et continue à développer !

Bonjour, c'est Alex de DEV STORIES DOT EU. Prompt Flow : Le guide complet, épisode 2 sur 14. Avant même d'écrire la moindre ligne de code, tu dois arrêter de voir les applications LLM comme des scripts monolithiques. Si tu essaies de les écrire de façon linéaire, le suivi des dépendances et le debug de l'état à travers plusieurs services externes deviennent vite ingérables. La solution structurelle pour ça, c'est de voir ton application comme un graphe d'appels de fonctions indépendants, un concept connu dans Prompt Flow sous le nom de Flows et d'architecture DAG. Un flow est simplement un workflow exécutable. Au fond, une application LLM est une séquence orchestrée d'appels externes, liés par une logique. Tu peux par exemple appeler un moteur de recherche, faire une query sur une base de données, exécuter un script Python pour formater les données récupérées, et enfin envoyer un prompt à un LLM. Prompt Flow modélise cette séquence sous la forme d'un Directed Acyclic Graph, ou DAG. Dans ce graphe, chaque étape distincte de ton application est un node, et les connexions entre ces nodes représentent le flow de données. Il est directed parce que les données avancent d'une fonction à la suivante, et il est acyclic parce que le chemin des données ne fait pas de boucle sur lui-même. Prends l'exemple d'une application simple qui répond à des questions à partir de données internes de l'entreprise. L'utilisateur pose une question, qui sert d'input initial. Cet input passe dans le premier node, une fonction Python qui exécute une query en base de données. La base de données renvoie un bloc de texte. Ce texte, ainsi que la question initiale de l'utilisateur, passent dans le node suivant, qui fait le véritable appel au LLM. Le LLM génère une réponse, qui devient l'output final de tout le graphe. En structurant l'app de cette manière, chaque fonction est strictement isolée. Tu sais exactement ce qui est entré dans l'appel à la base de données et exactement ce qui en est sorti avant même de trigger le LLM. Quand ils construisent ces workflows, les développeurs rencontrent souvent deux termes et se demandent lequel est le meilleur : Flex flow et DAG flow. C'est là que ça devient intéressant. Les deux aboutissent exactement au même résultat. Ils offrent juste des expériences développeur différentes. Flex flow est une approche code-first. Tu encapsules ta logique dans une fonction ou une classe Python standard, tu la désignes comme entry point, et tu écris du code brut. Prompt Flow se contente de l'exécuter. Le DAG flow, de son côté, définit le routage avec un fichier YAML. En listant explicitement les fonctions comme des nodes et en liant leurs inputs et outputs dans YAML, tu permets à la plateforme de générer une représentation visuelle de ton application. Les DAG flows sont très UI-friendly, ce qui permet d'inspecter l'architecture en un coup d'œil. Si tu choisis l'approche DAG flow, tu vas travailler avec trois types de flows spécifiques. Le premier est le Standard flow. C'est ton pipeline général où tu connectes des outils, du code Python et des modèles pour créer des applications classiques. Le deuxième est le Chat flow. Il s'appuie directement sur le Standard flow, mais il est spécifiquement conçu pour les applications conversationnelles. Il ajoute un support natif pour gérer l'historique de chat et configure automatiquement les inputs et outputs de chat nécessaires. Le troisième type est l'Evaluation flow. Tu n'utilises pas ce flow pour servir les utilisateurs finaux. À la place, tu exécutes un Evaluation flow sur les outputs de tes Standard ou Chat flows. Il sert de mécanisme de test pour calculer des métriques comme l'exactitude factuelle ou la pertinence, en se basant sur les données produites par ton flow principal. Que tu définisses ta logique en pur Python ou que tu la câbles visuellement avec YAML, ton application LLM n'est finalement qu'un pipeline qui route du texte entre des systèmes externes. Maîtrise le graphe, et tu contrôles l'application. C'est tout pour cet épisode. Merci d'avoir écouté, et continue à développer !

Salut, c'est Alex de DEV STORIES DOT EU. Prompt Flow : Le guide complet, épisode 3 sur 14. Tu as conçu le workflow parfait pour ton application d'IA, mais un plan tout seul ne traite pas de données. Il te faut des composants qui exécutent vraiment le travail, comme récupérer des URLs, formater des strings et appeler des APIs. Si les flows sont le plan de ton application, les tools en sont les briques. Aujourd'hui, on va s'intéresser aux tools. Dans Prompt Flow, les tools sont les briques de base exécutables d'un flow. Chaque nœud de ton graphe est un tool. Quand ton flow s'exécute, il transmet simplement les données d'un tool à l'autre. Même si tu peux étendre la plateforme, il y a trois tools intégrés que tu vas utiliser dans presque tous tes projets : le Python tool, le Prompt tool et le LLM tool. Prenons un scénario pratique pour voir comment ils s'articulent. Tu veux une application qui récupère une page web, formate le texte brut et génère un résumé. D'abord, tu dois récupérer le contenu de la page web. Tu utilises le Python tool. Ce tool te permet d'écrire des scripts Python custom et sert de pont avec le monde extérieur. Tu écris un petit script qui prend une URL en input, fait une requête HTTP et retourne le texte brut de la page. Le Python tool gère l'exécution et transmet ce texte brut pour la suite en tant qu'output. Ensuite, tu dois préparer les instructions pour le modèle de langage. Tu utilises le Prompt tool. Ce tool prend des inputs texte, comme le texte brut de ton Python tool et un system prompt qui définit le persona de l'IA, et les formate en une seule string bien propre. C'est la partie qui compte. Le Prompt tool n'appelle pas de modèle d'IA. Il se contente strictement de préparer et de formater du texte. Séparer cette étape rend ton flow beaucoup plus facile à lire et à tester, surtout quand tu gères des prompts complexes en plusieurs parties. Enfin, tu envoies cette string préparée au modèle en utilisant le LLM tool. Ce tool gère la connexion réelle à un endpoint de Large Language Model. Tu lui passes la string formatée par ton Prompt tool, tu configures les paramètres du modèle comme la température, et il te retourne le résumé généré. Le LLM tool fait le gros du travail en formatant le payload de l'API et en interagissant avec le provider. Même si ces trois-là couvrent la plupart des cas d'usage principaux, ce ne sont pas tes seules options. Prompt Flow supporte des partner tools fournis par des tiers. Un exemple courant est le Vector DB Lookup tool, qui cherche du texte similaire dans des bases de données vectorielles en se basant sur les embeddings. Tu peux aussi installer des packages custom ou créer tes propres tools pour des intégrations très spécifiques. Peu importe leur origine, ils fonctionnent tous exactement sur le même principe : ils prennent des inputs, exécutent une fonction spécifique, et retournent un output. La chose la plus importante à retenir, c'est la stricte séparation des responsabilités. N'écris pas de code Python pour formater des prompts, et n'utilise pas le LLM tool pour concaténer des strings. Utiliser le bon tool intégré pour sa fonction précise permet de garder tes graphes propres et faciles à débugger. Merci d'être resté à l'écoute. J'espère que tu as appris quelque chose de nouveau.

Bonjour, ici Alex de DEV STORIES DOT EU. Prompt Flow : Le guide complet, épisode 4 sur 14. Rien ne ruine un deploy en production plus vite qu'une clé API accidentellement commitée dans le version control. Même si tu évites ce désastre, jongler avec les credentials entre le développement local et les environnements cloud mène souvent à des fichiers de configuration emmêlés et à des risques de sécurité. Gérer les secrets avec des connections résout ça en isolant complètement tes données sensibles de la logique de ton flow. Dans Prompt Flow, une connection est une ressource dédiée qui stocke les endpoints et les credentials nécessaires pour interagir avec des services externes. Si ton flow a besoin d'appeler un modèle de langage externe, de faire une recherche sur le web via un service externe, ou de requêter une base de données distante, il a besoin d'une autorisation. Au lieu d'écrire tes clés API directement dans tes scripts Python ou tes fichiers de configuration, tu crées une connection. Ton flow référence ensuite cette connection par son nom. En utilisant des connections, tu découples tes données secrètes de ta logique d'exécution. Ton code sait seulement qu'il a besoin d'une connection nommée, par exemple, main_language_model. Il ne connaît pas la véritable clé API. Voyons comment ça marche quand tu passes un projet de ton ordinateur portable au cloud. Quand tu développes en local, tes connections sont stockées sur ton disque local. Pour maintenir la sécurité, Prompt Flow chiffre les valeurs secrètes avec une clé de chiffrement locale. Tu peux builder et tester ton flow avec cette configuration locale sans laisser de clés en clair exposées dans ton répertoire de travail. Quand tu es prêt à deploy ce flow sur Azure AI, l'environnement change, mais ton code ne change pas. Dans Azure AI, les connections sont sécurisées par Azure Key Vault. Les secrets sont stockés et gérés dans l'infrastructure Key Vault, protégés par des politiques d'accès strictes. C'est la partie qui compte. Parce que ton flow référence uniquement la connection par son nom, passer d'un environnement local au cloud ne demande aucun changement dans la logique de ton flow. Tu dois simplement t'assurer qu'une connection avec le même nom existe dans ton workspace Azure. Quand le flow tourne dans le cloud, il demande main_language_model. Le système intercepte cette requête de façon transparente et fournit les credentials de Key Vault au lieu de ceux chiffrés en local. Ton code reste propre et agnostique de l'environnement. Prompt Flow catégorise ces connections en deux types principaux. Le premier, ce sont les connections fortement typées. Ce sont des templates intégrés pour des services très utilisés comme Azure OpenAI. Ils fournissent des champs prédéfinis pour l'URL de l'endpoint, la clé API et le type d'API. Le système sait exactement comment gérer ces champs, ce qui garde la configuration des tools standards très simple. Le deuxième type, c'est la connection custom. Quand tu as besoin d'intégrer une API interne à l'entreprise ou un service tiers qui n'a pas de template intégré, tu utilises une connection custom. Ça agit comme un dictionnaire flexible où tu définis tes propres paires clé-valeur. Tu peux marquer explicitement certaines clés comme des secrets. Une fois marquées, ces secrets custom reçoivent exactement le même chiffrement local et la même protection Key Vault que les connections intégrées. La vraie valeur des connections, c'est qu'elles agissent comme une couche d'abstraction stricte pour l'authentification, ce qui garantit que ton flow reste complètement portable et que tes secrets restent sécurisés dans n'importe quel environnement d'exécution. C'est tout pour cet épisode. Merci de m'avoir écouté, et continue de builder !

Salut, ici Alex de DEV STORIES DOT EU. Prompt Flow : Le guide complet, épisode 5 sur 14. Arrête de noyer tes prompts de modèle de langage dans d'immenses strings Python. Quand tu hardcodes des prompts dans la logique de ton application, le suivi des modifications, l'exécution de tests standalone et la collaboration avec les prompt engineers deviennent un véritable cauchemar. La solution, c'est la spécification Prompty. Un Prompty est un format standard pour gérer les prompts. Il sort ton prompt de ton code pour le mettre dans un seul fichier markdown versionnable, avec une extension point prompty. Ce fichier est divisé en deux sections distinctes. En haut, tu as un front matter YAML. En bas, tu as un template de prompt au format Jinja. Trois tirets séparent les deux. Le bloc YAML sert de centre de contrôle. Tu peux y définir des métadonnées de base comme le nom, la description et l'auteur. Plus important encore, il contient la configuration du modèle. Tu spécifies le type d'API, comme chat ou completion. Tu définis les détails de configuration, comme pointer vers un deploy Azure OpenAI de GPT-3.5. Tu verrouilles aussi les paramètres du modèle juste ici. Si un prompt spécifique demande une température de zéro virgule sept et une limite max de mille tokens, tu le déclares dans le YAML. Ça lie directement les paramètres d'exécution au texte du prompt, ce qui garantit que le prompt se comporte de manière cohérente, peu importe où il est utilisé. La section YAML définit aussi les inputs et les samples. Si ton prompt attend une variable dynamique, tu la listes ici et tu fournis des valeurs d'exemple. Ça rend le fichier complètement autonome. N'importe qui l'ouvrant sait exactement quelles données il attend sans avoir à faire du reverse-engineering sur le code de ton application. Sous le YAML et les trois tirets se trouve le template de prompt à proprement parler. Cette section utilise la syntaxe Jinja2 pour injecter dynamiquement les inputs que tu as définis au-dessus. Comme les modèles de langage modernes utilisent des interfaces de chat, le template supporte la désignation des rôles. Tu définis les rôles avec un format texte simple, en séparant les instructions system des inputs user. Prends un scénario de chat minimal où tu veux un prompt qui salue un utilisateur par son prénom. En haut de ton fichier point prompty, tu écris le front matter YAML. Tu définis ta section model, en réglant le type d'API sur chat et en pointant la configuration vers un deploy GPT-3.5. Ensuite, tu ajoutes une section inputs qui déclare une variable appelée first name. Tu ajoutes aussi un bloc sample où first name est défini sur Jane. Tu tapes trois tirets pour terminer le front matter YAML. Maintenant, tu construis le template. Tu tapes le mot system suivi de deux points, puis tu donnes au modèle ses instructions de base, comme lui dire d'être un assistant utile. En dessous, tu tapes le mot user suivi de deux points. Enfin, tu écris le message d'accueil, en entourant la variable first name de doubles accolades pour que le moteur Jinja sache où injecter le texte. Tu as maintenant un asset complet et réutilisable. Traiter les prompts comme des fichiers autonomes plutôt que comme de simples strings dans ton code est la première étape vers un prompt engineering rigoureux, car ça impose un contrat clair entre l'application qui fournit les données et le modèle de langage qui génère la réponse. Merci d'avoir passé quelques minutes avec moi. À la prochaine, et porte-toi bien.

Bonjour, ici Alex de DEV STORIES DOT EU. Prompt Flow : Le guide complet, épisode 6 sur 14. Tu construis un prompt template bien réglé pour la production, mais quand tu veux le tester sur un modèle moins cher ou ajuster la température pour un edge case spécifique, tu te retrouves à modifier manuellement le fichier source. Un template statique crée de la friction quand ton environnement ou ta logique doit changer à la volée. C'est exactement cette friction que la Dynamic Prompty Execution est conçue pour éliminer. Un asset Prompty définit généralement les settings du modèle comme le nom du deployment, la connexion API et les paramètres dans son bloc header. Cependant, hardcoder ces valeurs limite la façon dont tu utilises le fichier à travers différents environnements. L'exécution dynamique te permet de traiter le fichier Prompty comme une couche de base flexible, en faisant un override de ses configurations directement en Python ou via la command line au runtime. Pour exécuter un fichier Prompty en Python, tu utilises la fonction load prompty de la core library de Prompt Flow. Tu passes le chemin du fichier à cette fonction, et elle te retourne un objet callable en mémoire. Pour l'exécuter, il te suffit d'appeler cet objet, en lui passant tes variables de prompt comme des keyword arguments standards. La library gère la compilation et l'appel API, et te retourne l'output texte final. C'est exactement là que l'exécution dynamique prouve sa valeur. Tu peux intercepter l'exécution pour overrider les settings du modèle sans toucher au fichier de base. Supposons que tu aies un Prompty configuré pour un deployment Azure OpenAI standard, mais que pour un batch job spécifique, tu aies besoin de le pointer vers un endpoint Azure différent et d'augmenter la température pour obtenir des réponses plus variées. Au lieu de dupliquer le fichier, tu définis un dictionnaire dans ton code Python contenant tes nouveaux settings. Tu ajoutes ton endpoint alternatif et ta nouvelle valeur de température à ce dictionnaire. Ensuite, quand tu appelles ton objet Prompty chargé, tu passes ce dictionnaire au keyword argument model, en plus de tes inputs de prompt standards. Le runtime Prompt Flow fusionne ton dictionnaire avec la configuration du fichier de base. Tes overrides dynamiques prennent le dessus, le prompt s'exécute avec les nouveaux settings, et le fichier d'origine reste complètement inchangé. Ça te permet de swapper des clés API, de changer les max tokens, ou de rediriger la cible du modèle de façon programmatique en fonction de l'état de ton application. Parfois, tu n'as pas envie d'écrire un script Python juste pour voir si un prompt donne un bon résultat. Pour une validation rapide, tu peux tester un fichier Prompty directement depuis ton terminal. Tu utilises la commande pf flow test, en fournissant le chemin vers ton fichier avec le flag source. Tu peux ajouter le flag inputs pour passer tes variables directement dans la commande sous forme de paires clé-valeur. La command line interface exécute le Prompty et affiche la réponse du modèle directement sur la standard output. Ça te donne une feedback loop immédiate pendant le développement, sans avoir à écrire de code wrapper. La vraie valeur d'un asset Prompty n'est pas de verrouiller les configurations, mais d'isoler le texte du prompt de l'environnement d'exécution. En injectant des overrides de modèle dynamiquement au runtime, un seul fichier peut servir de manière transparente ta sandbox de test locale, tes pipelines automatisés et tes endpoints de production. C'est tout pour cet épisode. Merci pour ton écoute, et continue de développer !

Salut, c'est Alex de DEV STORIES DOT EU. Prompt Flow : Le guide complet, épisode 7 sur 14. Tu pourrais penser qu'utiliser un framework spécialisé pour les grands modèles de langage implique d'apprendre une interface visuelle complexe ou de maintenir d'énormes fichiers de configuration. Mais si tu sais déjà écrire un script Python, tu en sais déjà assez pour créer une application entièrement traçable. Les Flex Flows basés sur des fonctions résolvent complètement cette tension. Dans le développement standard avec Prompt Flow, tu construis un graphe acyclique orienté. Cette structure est super efficace pour des pipelines stricts à plusieurs étapes, mais parfois les développeurs veulent écrire du code Python pur sans s'adapter à un système de nœuds visuel. Les Flex Flows te permettent de faire exactement ça. Tu encapsules la logique de ton application LLM dans des fonctions Python standard, et la plateforme gère le tracking et l'orchestration en arrière-plan. Prenons l'approche basée sur les fonctions. Tu commences par écrire une fonction Python normale. Donne-lui un nom descriptif, comme chat, et définis ses inputs, par exemple en prenant une question comme paramètre de type string. À l'intérieur de cette fonction, tu écris ta logique exactement comme tu le ferais d'habitude. Tu pourrais charger un fichier Prompty pour récupérer ton message système, initialiser ton client de modèle de langage, passer la question au modèle, puis retourner la réponse texte sous forme de string. À ce stade, tu as tout simplement un script Python standard. Il tourne en local, il est facile à tester, et il ne demande aucune connaissance particulière du framework. Pour transformer ce script Python pur en un composant Prompt Flow traçable, tu importes le décorateur trace depuis le package de tracing promptflow. Tu places ce décorateur juste au-dessus de ta fonction chat. Quand tu lances ton code, ce décorateur dit au système de surveiller l'exécution silencieusement. Il enregistre automatiquement les inputs passés à la fonction, l'output texte retourné, le temps d'exécution exact, et toute erreur interne. Si tu appliques le décorateur trace à d'autres fonctions utilitaires dans ton script, le système construit un call tree complet. Tu obtiens toute l'observabilité d'un flow visuel, y compris la possibilité de voir la trace d'exécution dans l'interface utilisateur locale, sans changer la façon dont tu structures ta logique. Maintenant, le tooling a besoin d'un moyen de savoir que cette fonction spécifique est le point d'entrée de ton application. Tu fournis ça en créant un seul fichier de configuration très court appelé flow.flex.yaml dans le même dossier que ton code. Ce fichier ne définit pas de graphe de routing complexe. Il a juste besoin d'une information critique, qui est le mapping de l'entry. Tu écris le mot entry suivi du nom de ton module Python, de deux points, et du nom de ta fonction. Si ton fichier s'appelle app.py et que ta fonction est chat, la valeur de ton entry est tout simplement app deux points chat. Quand tu testes ou que tu lances ce flow en utilisant l'outil en ligne de commande Prompt Flow ou l'extension VS Code, le système lit ce fichier yaml. Il cherche la fonction chat dans ton module app, injecte les inputs fournis, exécute ton code Python pur, et collecte les traces générées par le décorateur. La vraie puissance des flex flows basés sur des fonctions, c'est qu'ils suppriment la friction entre le prototypage d'un script et le deploy d'une application en production ; ta logique Python pure reste entièrement sous ton contrôle, pendant qu'un seul décorateur et un fichier de configuration de deux lignes débloquent une observabilité de niveau entreprise. C'est tout pour cet épisode. Merci pour ton écoute, et continue de builder !

Bonjour, ici Alex de DEV STORIES DOT EU. Prompt Flow : Le guide complet, épisode 8 sur 14. Tu déploies une nouvelle app de language model, mais chaque fois qu'un utilisateur envoie un message, ça prend de précieuses secondes juste pour établir la connexion à la base de données et charger les credentials du client. Quand ton application a besoin de maintenir une connexion persistante ou de retenir l'historique de la conversation, un script standalone ne suffit pas, parce qu'il repart complètement de zéro à chaque run. La solution à ce problème, ce sont les Flex Flows : le développement basé sur les classes. Quand tu développes des applications qui scale, le state management devient une préoccupation majeure. Si ton flow repose sur une ressource externe, comme un client Azure OpenAI, l'initialisation de ce client nécessite de lire des secrets, de vérifier des endpoints et d'allouer de la mémoire. Si tu mets cette logique dans une séquence d'exécution basique, tu payes ce lourd coût de démarrage à chaque fois qu'une requête arrive. Utiliser une classe Python comme entry point pour ton Flex Flow te permet de séparer fondamentalement ta logique d'initialisation de ta logique d'exécution. Un flow basé sur une classe s'appuie sur deux méthodes Python standards pour gérer ce cycle de vie. La première, c'est le constructeur, ou la méthode init. C'est ta phase de setup. Prompt Flow exécute cette méthode exactement une fois, quand le flow est chargé en mémoire pour la première fois. C'est là que tu fais le plus gros du travail. La deuxième méthode, c'est la méthode call. C'est ta phase d'exécution, et elle tourne à chaque fois que le flow est déclenché par une requête utilisateur. Imagine une classe de chat flow. Tu définis ta méthode init pour accepter un objet de connexion Azure OpenAI et une string de system prompt. À l'intérieur de la méthode init, tu crées ton client Azure OpenAI et tu le stockes comme propriété sur l'instance de la classe elle-même. Le client est maintenant prêt et en attente. Ensuite, tu définis ta méthode call. Cette méthode accepte une nouvelle question de l'utilisateur et une liste d'anciens messages qui représentent l'historique du chat. Comme le client est déjà complètement initialisé, la méthode call formate immédiatement le prompt, envoie l'historique du chat au language model et retourne la réponse. L'exécution est rapide parce que le setup coûteux du client a été complètement contourné. Pour que ça marche, Prompt Flow a besoin de savoir comment instancier ta classe. Tu configures ça en créant un fichier YAML pour ton flow. L'entry point dans ce fichier de configuration utilise un format spécifique, en nommant le module Python suivi de deux points et du nom de ta classe. C'est la partie qui compte. Ta configuration YAML ne fait pas que pointer vers la classe, elle définit les paramètres requis par ta méthode init. Si le constructeur de ta classe a besoin d'une connexion Azure et d'un nom de modèle, tu déclares ces inputs dans le fichier YAML sous une section init dédiée. Quand le moteur Prompt Flow démarre, il lit le YAML, injecte ces paramètres configurés dans le constructeur de ta classe, puis garde cet objet instancié en vie dans la mémoire pour gérer les appels entrants. Tester un flow basé sur une classe en local est incroyablement simple, parce qu'il repose sur le comportement standard de Python. Tu n'as pas besoin d'un environnement de test complexe. Tu écris juste un script Python standard, tu importes ta classe, tu crées une instance en passant des connexions mockées ou des credentials locaux au constructeur, et ensuite tu invoques l'objet directement en lui passant un message de test. Tu peux debugger la logique de setup et la logique d'exécution indépendamment. L'essentiel à retenir, c'est que les flows basés sur les classes te donnent la structure architecturale pour séparer le gros du travail de l'initialisation du travail répétitif de l'exécution, ce qui garde ton state persistant et tes réponses rapides. Si tu trouves ces épisodes utiles et que tu veux soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon. C'est tout pour celui-ci. Merci pour ton écoute, et continue de développer !

Bonjour, ici Alex de DEV STORIES DOT EU. Prompt Flow : Le guide complet, épisode 9 sur 14. Parfois, fixer un mur de code ne suffit pas pour comprendre une application complexe. Quand les prompts, les scripts et les appels d'API interagissent de dizaines de façons différentes, tu as besoin de voir physiquement les données circuler entre eux pour repérer les bottlenecks. Les DAG flows sont la réponse pour les équipes qui veulent une clarté architecturale explicite. DAG signifie Directed Acyclic Graph. Dans Prompt Flow, un DAG flow est une méthode pour construire des applications d'IA en reliant différents tools entre eux sous forme de nodes. Au lieu d'écrire un seul gros script, tu définis la structure de ton application dans un fichier nommé flow point dag point yaml. Ce fichier sert de plan principal. Il déclare les inputs de départ, les étapes individuelles, et les outputs finaux de ton application. Chaque étape dans un DAG flow s'appelle un node. Un node représente un tool spécifique qui effectue une seule tâche. Tu peux avoir un node qui exécute un snippet Python, un autre node qui formate un prompt, et un troisième node qui appelle un Large Language Model. Le fichier yaml décrit comment ces nodes sont reliés entre eux via des dépendances d'input et d'output. C'est ce mapping de dépendances qui fait fonctionner le flow. Tu ne dis pas manuellement au système dans quel ordre exécuter les étapes. À la place, tu spécifies que le node B a besoin de l'output du node A. Comme le node B ne peut pas démarrer avant que le node A soit terminé, un ordre d'exécution se forme naturellement. Si tu ajoutes un node C qui dépend uniquement de l'input utilisateur initial, Prompt Flow va reconnaître qu'il n'a pas besoin d'attendre le node A ou le node B. Il exécutera le node C en parallèle automatiquement. Le moteur lit le fichier yaml, résout le graphe et gère l'orchestration. Écrire et maintenir ce fichier yaml à la main peut devenir difficile quand ton application grossit. C'est pour ça que la plupart des développeurs utilisent l'extension VS Code de Prompt Flow. Cette extension lit ton fichier flow point dag point yaml et génère une interface utilisateur visuelle en drag-and-drop. Tu peux voir ton application comme une véritable carte de blocs connectés. Prenons un scénario concret. Tu construis une application pour lire des rapports financiers et rédiger de courts résumés. Dans l'éditeur visuel, tu crées un node de type tool Python et tu le nommes Extract Text. À côté, tu ajoutes un node de type tool LLM nommé Summarize. Plutôt que d'écrire du code pour gérer le state entre ces deux opérations, tu utilises l'interface. Tu cliques sur le port d'output du node Extract Text et tu tires une ligne vers le port d'input du node Summarize. Tu viens de câbler visuellement le chemin des données. L'extension met instantanément à jour le fichier yaml sous-jacent pour enregistrer cette connexion. Tu obtiens la vitesse et la clarté d'un builder visuel low-code, mais tu génères quand même un fichier de configuration en plain text que tu peux suivre en version control. Cette approche visuelle impose une discipline architecturale. Le graphe est acyclique, ce qui veut dire que les données ne peuvent aller que vers l'avant. Il n'y a pas de boucles infinies. Les données entrent, traversent ta séquence de tools, et sortent. Ce flow directionnel strict rend le debugging super simple. Si un résumé final a l'air faux, tu peux ouvrir le graphe visuel, cliquer sur la connexion entre les nodes d'extraction et de résumé, et inspecter la string exacte qui est passée par ce câble. Tu sais exactement d'où viennent les données et où elles sont allées. Le vrai avantage d'un DAG flow, c'est que ton diagramme d'architecture système et ton application exécutable sont exactement la même chose. C'est tout pour cet épisode. Merci d'avoir écouté, et continue à développer !

Salut, c'est Alex de DEV STORIES DOT EU. Prompt Flow : Le guide complet, épisode 10 sur 14. Quand un modèle de langage renvoie une réponse complètement hallucinée, comment tu sais si c'est le modèle lui-même qui a planté, ou si ta logique de formatage de prompt avait un bug ? Tu peux éparpiller des print statements un peu partout dans ton application, mais ça devient impossible à maintenir quand ton application grossit. Le tracing des interactions LLM règle ce problème en capturant le contexte exact de chaque exécution. Le tracing transforme une application LLM black-box en une séquence d'événements transparente et débuggable. Il enregistre précisément quelles données entrent dans une fonction, ce qui en sort, et combien de temps prend l'exécution. Dans cet écosystème, tu gères ça avec le package promptflow-tracing. Les données qu'il génère sont basées sur la spécification OpenTelemetry, ce qui veut dire que tes enregistrements d'exécution suivent un format standard de l'industrie pour l'observabilité. Pour capturer les interactions de base avec un modèle, tu utilises une fonction qui s'appelle start trace. Si tu appelles cette fonction au tout début de ton script Python, Prompt Flow instrumente automatiquement les clients de modèles supportés. Par exemple, si tu utilises le package Python standard d'OpenAI, tu n'as pas du tout besoin de modifier tes appels d'API. Le tracer intercepte discrètement l'interaction, en loggant le system message, le prompt utilisateur, les paramètres spécifiques du modèle et la string de réponse finale. Capturer l'appel d'API, ce n'est que la moitié du travail. C'est généralement dans la logique qui précède cet appel que se cachent les bugs. Pour tracer la logique de ta propre application, tu appliques le décorateur trace à tes fonctions personnalisées. Imaginons une fonction qui s'appelle math to code. Cette fonction prend un utilisateur qui décrit un problème de maths, récupère le contexte nécessaire, construit un prompt, et pour finir, demande du code Python à GPT-4. En plaçant le décorateur trace juste au-dessus de la définition de la fonction math to code, tu dis à Prompt Flow d'enregistrer chaque exécution de ce bloc de logique spécifique. Il va logger la string d'input de l'utilisateur, le code final renvoyé, et la latence de toute l'opération. Comme tu as aussi exécuté start trace en haut de ton fichier, le système comprend la relation entre ton code et l'appel au modèle. Il construit un enregistrement hiérarchique. Ta fonction math to code devient le parent span, et l'appel interne à OpenAI devient un child span imbriqué à l'intérieur. Tu visualises cette hiérarchie en utilisant la Trace UI locale. Quand tu exécutes un script tracé, Prompt Flow lance un serveur local que tu peux ouvrir dans ton navigateur web. Cette interface te donne une timeline visuelle du flow de ton application. Tu peux sélectionner le parent span math to code pour vérifier les arguments qu'il a reçus. Ensuite, tu peux sélectionner le child span OpenAI pour inspecter la raw prompt string exacte qui a été envoyée avec succès au modèle sur le réseau. Si ta logique d'assemblage de contexte a oublié une variable, tu verras immédiatement l'espace vide dans le raw prompt. La vraie puissance du tracing, ce n'est pas juste de collecter des logs d'exécution, mais de prouver définitivement ce qui s'est passé à la frontière exacte entre le code de ton application et le modèle externe. C'est tout pour cet épisode. Merci d'avoir écouté, et continue à développer !

Salut, c'est Alex de DEV STORIES DOT EU. Prompt Flow : Le guide complet, épisode 11 sur 14. Tu viens de passer trois mois à développer une application complexe avec LangChain. La logique fonctionne globalement, mais quand un agent part dans une mauvaise loop ou perd le contexte, trouver exactement où il a déraillé est un vrai cauchemar, et tout réécrire juste pour avoir de meilleurs logs est complètement hors de question. Le tracing avancé pour LangChain et AutoGen, c'est comme ça que tu règles le problème directement. Quand tu développes avec des frameworks d'orchestration, tu gagnes en vitesse grâce à l'abstraction. Le framework cache les détails un peu brouillons du séquençage des prompts, de l'exécution des tools et du parsing. Mais l'abstraction crée forcément une boîte noire. Quand ton agent te renvoie une réponse confuse, tu as besoin de voir sa chain of thought interne. Tu dois connaître le sub-prompt exact qu'il a généré, la réponse API brute qu'il a reçue, et quel tool call spécifique a échoué. Prompt Flow inclut une fonctionnalité de tracing standalone conçue exactement pour ça. Ça ne t'oblige pas à utiliser Prompt Flow pour ta logique ou ton exécution. Tu gardes ton code LangChain ou AutoGen existant exactement comme il est. Tu attaches juste le système de tracking de Prompt Flow à ton application externe. Pense à ton script Python actuel qui fait tourner un agent LangChain. Pour avoir une visibilité totale, tu ne touches pas aux définitions de tes chains. Tu vas juste tout en haut de ton fichier d'exécution principal. Tu importes la fonction de setup de la trace depuis le module Prompt Flow, et tu l'appelles une seule fois avant que ton agent commence son travail. Cette seule commande, c'est toute l'intégration. Quand tu appelles cette fonction, elle instrumente ton environnement. Comme le tracing de Prompt Flow est basé sur les standards OpenTelemetry, il sait comment écouter les événements spécifiques déclenchés par ces frameworks populaires. Pendant que ton application LangChain tourne, l'instrumentation intercepte automatiquement les appels API sous-jacents. Elle capture les inputs, la durée d'exécution, les outputs et l'utilisation des tokens pour chaque étape. Ça s'applique aussi de façon transparente à AutoGen. Les setups multi-agents dans AutoGen sont connus pour être super difficiles à débugger parce que plusieurs agents s'envoient des messages de manière autonome. Tracker qui a passé quel contexte à qui, ça veut généralement dire fouiller dans des murs de texte massifs dans le terminal. En initialisant la trace tout en haut de ton script AutoGen, chaque échange de messages est automatiquement capturé et structuré. Une fois que ton script a fini de s'exécuter, tu ouvres l'UI locale de Prompt Flow Trace. Au lieu de scroller dans les print statements de la console, tu obtiens une timeline visuelle. Tu vois un arbre d'exécution clair. Tu cliques sur le run de l'agent de plus haut niveau, tu déplies le node, et tu vois la séquence des appels LLM imbriqués et des exécutions de tools. Si un agent a halluciné à l'étape quatre, tu peux cliquer directement sur l'étape quatre pour lire le texte exact et non formaté qui a été envoyé au modèle. Tu gagnes une visibilité complète sur un framework opaque sans avoir à migrer une seule ligne de ta vraie logique métier. Le vrai avantage ici, c'est la liberté architecturale ; tu peux orchestrer ton application en utilisant le framework qui convient le mieux à ton équipe, tout en gardant ton debugging et ton observabilité centralisés dans une seule interface visuelle claire. Comme toujours, merci pour ton écoute. On se retrouve au prochain épisode.

Bonjour, ici Alex de DEV STORIES DOT EU. Prompt Flow : Le guide complet, épisode 12 sur 14. Ton prompt a parfaitement fonctionné sur ta question de test, mais que se passe-t-il quand tu le run sur dix mille requêtes de vrais utilisateurs ? Généralement, il plante. Tester un prompt manuellement avec deux exemples, c'est facile, mais prouver qu'il fonctionne sur des centaines de edge cases exige quelque chose de plus robuste. C'est là qu'intervient le passage à l'échelle : les batch runs avec des données. Un batch run prend ton flow unique et l'exécute sur un grand dataset. Ça te permet de passer de la construction de la logique à sa vérification à grande échelle. Au lieu de taper des inputs dans une interface utilisateur, tu déclenches ce processus via la ligne de commande. La commande principale est pf run create. En l'exécutant, tu demandes à Prompt Flow de lancer une nouvelle instance de run, de lire un répertoire de flow spécifique et de lui fournir un fichier contenant tous tes records de test. Le moteur traite ces records en exécutant l'intégralité de ton flow graph indépendamment pour chaque ligne de ton dataset. Le format de données requis pour ce fichier d'input est JSONL. JSONL signifie JSON Lines. Si tu es habitué au JSON standard, tu t'attends peut-être à un seul grand array qui enveloppe tous tes objets. JSONL laisse tomber l'array. Chaque ligne du fichier texte est son propre objet JSON valide et indépendant, représentant exactement un cas de test. Ce format est très apprécié en machine learning et dans les data pipelines car il est léger et se streame facilement. Le moteur peut le lire ligne par ligne sans avoir à charger un fichier massif en mémoire en une seule fois. Prenons l'exemple d'un flow de classification web. Ton flow est conçu pour prendre une adresse web, scraper le contenu et utiliser un language model pour le catégoriser. Le flow graph attend une string d'input spécifique nommée url. Tu veux tester cette logique sur une centaine de sites web différents pour voir comment elle gère les edge cases. Tu crées ton fichier JSONL. Chaque ligne contient un objet JSON avec une clé, par exemple nommée web link, contenant l'adresse cible. Pour lancer le batch run, tu tapes pf run create. Tu spécifies le répertoire de ton flow avec le flag flow, et tu pointes vers ton fichier JSONL avec le flag data. Mais il y a une incompatibilité structurelle immédiate. La logique de ton flow exige strictement un input nommé url, alors que ton fichier de données fournit un champ nommé web link. Si tu lances la commande maintenant, elle va échouer. Le moteur ne devine pas quels data fields correspondent à quels inputs du flow. Tu combles cette lacune en utilisant le flag de column mapping. Ce flag indique précisément au moteur d'exécution comment connecter les clés de ton fichier JSONL aux input nodes spécifiques de ton flow. Dans les arguments de ta ligne de commande, tu écris le nom de l'input du flow, un signe égal, puis une référence à la data column. Prompt Flow utilise une binding syntax spécifique pour ces références. Tu écris un signe dollar, suivi du mot data, d'un point, puis du nom de la colonne dans ton fichier. Pour le scénario de classification web, tu le map en écrivant url equals dollar sign data dot web link. Cette instruction explicite lie le data field à l'exigence du flow. Le moteur va maintenant extraire la string web link de la ligne un de ton fichier JSONL et l'injecter dans l'input url de ton flow. Puis il répète ce processus exact pour la ligne deux, la ligne trois, et ainsi de suite jusqu'à ce que le fichier entier soit traité. Tu peux mapper plusieurs inputs de cette façon. Si ton flow attend une url et un user id, il te suffit d'ajouter une autre instruction de mapping à la même commande. Découpler tes données de test des inputs de ton flow grâce à un column mapping explicite signifie que tu n'as plus jamais besoin de modifier ton core code juste pour run un nouveau dataset. Merci d'avoir passé quelques minutes avec moi. À la prochaine, à plus.

Salut, c'est Alex de DEV STORIES DOT EU. Prompt Flow : Le Guide Complet, épisode 13 sur 14. Tu ne peux pas écrire un test unitaire standard pour vérifier que la réponse d'un large language model correspond à une string exacte. Si l'output change à chaque fois, comment tu prouves mathématiquement que ton application fonctionne vraiment avant de la deploy ? La réponse, c'est le paradigme d'évaluation. En software engineering traditionnel, les tests unitaires sont déterministes. Tu passes un input spécifique à une fonction, et tu t'attends à un output exact. Les large language models sont stochastiques. Ils sont imprévisibles par nature. Demande à un modèle de classifier une page web, et il peut te sortir le mot sports, ou te dire que la catégorie est sports, ou juste te donner un emoji lié. Une assertion de test standard va fail sur deux de ces trois cas, même si le modèle a fondamentalement trouvé la bonne réponse. Pour prouver que t'es prêt pour la release, tu dois aller au-delà des tests unitaires et adopter l'évaluation statistique. Dans Prompt Flow, c'est géré par un Evaluation Flow. Un Evaluation Flow est juste un flow normal, mais au lieu de générer du texte pour un utilisateur final, son seul job est de noter l'output d'un autre flow. Il prend les prédictions que ton application principale a générées, les compare à un set connu de bonnes réponses, et te sort des métriques calculées. Rendons ça concret. Disons que tu viens de terminer un batch run d'un flow de classification web. Il a processé une centaine d'adresses web et a sorti une catégorie prédite pour chacune. Maintenant, tu as besoin de savoir exactement à quel point ces prédictions sont précises. Tu prends les outputs de ce base run et tu les passes à un nouvel Evaluation Flow dédié, conçu pour calculer l'accuracy de la classification. Tu déclenches ça depuis la ligne de commande en utilisant la commande run create. Tu spécifies ton Evaluation Flow, mais au lieu de juste lui donner un fichier statique de nouveaux inputs, tu lui passes une référence vers ton batch run précédent. L'Evaluation Flow a besoin de deux infos pour faire son job. Il a besoin de la prédiction du modèle, et il a besoin de la ground truth, qui est la réponse historiquement correcte. Tu fournis un data mapping qui relie ces points. Tu dis au système de mapper l'input de prédiction de l'Evaluation Flow à l'output de catégorie de ton base run. Ensuite, tu mappes l'input de ground truth à la colonne du vrai label située dans ton dataset de test d'origine. C'est la partie qui compte. L'Evaluation Flow s'exécute ligne par ligne, en parcourant tout l'historique du run précédent. Pour chaque ligne, il regarde ce que ton flow principal a prédit et le compare à la ground truth. Il attribue un score pour cette interaction spécifique. Dans notre scénario de classification, ça pourrait être un simple un pour un match et un zéro pour un miss. D'autres Evaluation Flows pourraient utiliser un language model pour juger la qualité d'un résumé sur une échelle de un à cinq. Une fois que le flow a fini de noter chaque ligne, il agrège ces scores individuels en une métrique globale finale. Tu ne te retrouves pas juste avec un log massif de uns et de zéros. Tu obtiens un nombre définitif de haut niveau, comme une accuracy globale de 92 %. Tu peux ensuite consulter ces métriques agrégées pour décider si la version actuelle de ton application est prête pour la production. Tu n'as plus besoin de deviner si un tweak de prompt a amélioré ton système ; tu as la preuve statistique d'à quel point il performe mieux ou moins bien sur tout ton dataset. Merci d'avoir écouté. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. Prompt Flow : Le guide complet, épisode 14 sur 14. Tu as construit, tracé et évalué ton flow de modèle de langage, et il fonctionne parfaitement. Mais pour l'instant, il reste dans ton environnement de développement, complètement isolé de tes vrais utilisateurs. Le sortir de ton IDE et le transformer en un service stable et accessible, c'est exactement ce qu'on va voir aujourd'hui en passant tes flows en production. Au repos, un prompt flow est simplement un dossier. Il contient un fichier de configuration YAML et tes scripts Python ou tes templates Jinja. Pour que ce dossier fasse quoi que ce soit dans le monde réel, tu as besoin d'un environnement d'exécution pour charger ces fichiers et écouter les requêtes HTTP entrantes. Pendant le développement, tu as probablement utilisé le serveur local intégré. Tu lances une simple commande, et ça démarre un endpoint local pour tester les inputs et les outputs. C'est très bien pour vérifier la logique, mais ce n'est pas conçu pour gérer du trafic de production concurrent, gérer la mémoire efficacement, ou survivre à un crash système. Pour passer en production, tu as besoin de la conteneurisation. Prompt Flow est conçu pour s'intégrer directement avec Docker. Au lieu de coder ton propre serveur web from scratch, tu utilises les outils de Prompt Flow pour exporter ton flow sous forme de conteneur Docker. Quand tu lances le processus d'export, le système génère un Dockerfile. Ce fichier définit une image de base, y copie le dossier de ton flow, installe les dépendances Python exactes listées dans ton fichier requirements, et configure un serveur web prêt pour la production pour servir le flow sous forme d'API REST. C'est ça le plus important. Une fois que ton flow est dans un conteneur Docker, il arrête d'être une expérience de machine learning spéciale et devient un artefact logiciel standard. Tu peux le traiter comme n'importe quel autre microservice. Prends un scénario concret. Tu as un chat flow de support client validé. Tu construis l'image Docker et tu la pousses sur ton container registry privé. Ensuite, tu déploies cette image sur un cluster Kubernetes. Tu écris une configuration de déploiement standard qui dit à Kubernetes de lancer trois réplicas de ton conteneur de chat flow, et tu places un load balancer devant. Maintenant, ton application frontend envoie des requêtes HTTP standards au load balancer, qui distribue le trafic sur tes conteneurs. Si ton chat flow est bombardé de requêtes utilisateurs, Kubernetes scale up simplement plus d'instances de ton flow. Si tu ne veux pas gérer un cluster Kubernetes, cette même image Docker marche parfaitement sur des services de plateforme managés. Tu peux la déployer directement sur Azure App Service ou n'importe quel autre cloud provider qui héberge des conteneurs. Le flow se fiche de l'endroit où il tourne, tant qu'il a un container runtime. Il y a un autre pattern de déploiement alternatif. Si tu ne construis pas un service web, tu peux distribuer un flow sous forme d'application exécutable. Ça package le flow et ses dépendances de runtime dans un fichier exécutable autonome. C'est super utile si tu as besoin de faire tourner la logique directement sur une machine cliente ou un edge device, en contournant complètement le besoin d'installer Python ou de configurer un serveur. Passer un prompt flow en production ne nécessite pas d'hébergement propriétaire ou d'infrastructure de machine learning spécialisée. En exportant vers Docker, tes flows de modèle de langage s'intègrent parfaitement dans les mêmes pipelines de continuous delivery et orchestrateurs de conteneurs que tu utilises déjà pour tes services backend traditionnels. Si tu veux aller plus loin, je t'encourage à lire la documentation officielle de Prompt Flow, à essayer de déployer un conteneur toi-même, ou à visiter devstories dot eu pour suggérer des sujets que tu aimerais voir dans de futures séries. J'aimerais prendre un moment pour te remercier de ton écoute — ça nous aide beaucoup. Passe une excellente journée !