Prototypage, suivi, évaluation, tests de type red teaming : un flux de travail pour un agent IA dans Microsoft Foundry.

Obtenir quelques bonnes réponses d’un agent IA ne prend que quelques minutes. Décider s’il est apte à être mis en production prend beaucoup plus de temps, car l’équipe doit d’abord déterminer si le modèle choisi justifie son coût, si l’agent s’appuie sur les données appropriées, quels outils il utilise, comment se classent ses réponses et comment il résiste à des tentatives actives de le compromettre.

Microsoft Foundry regroupe une grande partie de ce processus dans un seul espace de travail en navigateur couvrant la comparaison des modèles, les instructions, les outils et les connaissances, le suivi, l’évaluation, les données de test générées et les tests automatisés de type « red teaming ». Sa véritable valeur réside non pas dans la possibilité de reporter indéfiniment l’écriture du code, mais plutôt dans le fait qu’il permet de prendre des décisions de conception coûteuses tant que le projet est encore facile à modifier, avant que le code de production ne les fixe définitivement.

Ce qui suit suit un agent depuis un projet vierge jusqu’à un prototype basé sur des données, suivi, évalué et mis à l’épreuve, puis indique le moment où le travail passe du portail vers le SDK. L’environnement est celui de Microsoft Build retail-agent au sein de la nouvelle expérience Foundry, hébergée dans la région Sweden Central. Le portail sert de surface pour des itérations rapides, et le chemin menant à la production reste intégré au même projet Foundry, de sorte que rien n’est reconstruit à partir de zéro.

Commencez par quelque chose qui fonctionne

Un projet Foundry vierge est un espace de travail contenant des agents, des modèles, des outils, des connaissances, des mécanismes d’évaluation et des fonctionnalités d’observabilité. Les étapes exactes de provisionnement, les paramètres par défaut et les fonctionnalités disponibles diffèrent selon la région et évoluent avec le temps ; par conséquent, le portail lui-même doit être considéré comme la source finale concernant les capacités d’un projet.

Lorsqu’un agent a été créé, c’est dans l’environnement de travail que commence le travail réel. C’est là que l’on définit le modèle et les instructions, que l’on ajoute des outils ou des connaissances, et que l’on teste les résultats dans la fenêtre de chat. C’est également ici que le prototype révèle pour la première fois ses faiblesses. Si l’on pose une question complexe à un agent à peine configuré, la réponse est généralement banale. Elle peut sembler assurée alors qu’il ne connaît rien du catalogue, des politiques ni du contexte commercial. Conservez cette réponse comme référence, car chaque modification ultérieure doit y être comparée.

Choix d’un modèle sur la base de preuves

Un modèle par défaut performant n’est pas nécessairement le plus adapté pour la production. Certaines tâches exigent une réflexion approfondie, tandis que d’autres privilégient la vitesse ou un coût faible ; par conséquent, le choix doit reposer sur une évaluation et non sur une intuition. Foundry propose plusieurs outils pour affiner le catalogue :

• Un classement qui évalue les modèles en fonction de la qualité, de la sécurité, des performances et des critères liés aux coûts proposés.
• Des graphiques de compromis qui représentent deux dimensions sur un même graphique, comme la qualité par rapport au prix.
• Une vue côte à côte qui réduit la liste des modèles possibles aux seuls modèles adaptés au travail à effectuer.
• Un routeur de modèles qui attribue chaque demande à un modèle approprié en fonction d’une politique coût/qualité, de sorte qu’un seul modèle n’a pas besoin de répondre à tout.

Seuls les scores de référence ne constituent pas une preuve suffisante. Exécuter le même travail sur chaque modèle candidat est plus fiable. Le routeur devient utile lorsque les demandes diffèrent fortement en termes de difficulté. Il propose actuellement des modes Équilibré, Coût et Qualité, et les versions actuelles passent automatiquement à un autre modèle disponible si celui qui a été choisi tombe en panne.

La prochaine étape consiste à envoyer les mêmes instructions aux différents scénarios de candidats et à comparer la qualité des réponses, le temps de réponse ainsi que les coûts. Les benchmarks permettent de réduire le champ des possibilités, et votre propre charge de travail choisit le gagnant. Microsoft Learn décrit à la fois le flux de travail des benchmarks et l’outil de routage dans sa documentation Foundry.

Les instructions sont l’outil le moins coûteux

Changer de modèle n’est pas toujours la première étape appropriée. Des instructions vagues peuvent transformer un modèle coûteux en un chatbot générique. L’outil Prompt Optimizer de Foundry réécrit et restructure les instructions, explique les raisons des modifications apportées à certaines sections et permet plusieurs itérations avant d’appliquer quoi que ce soit. De cette manière, les instructions deviennent des entrées versionnées destinées aux équipes techniques, au lieu d’un paragraphe flou réécrit jusqu’à ce que la réponse semble meilleure.

Une réécriture esthétique ne prouve pas grand-chose. Une vérification plus fiable consiste à comparer un ensemble de données d’évaluation aux versions ancienne et nouvelle. Toute personnalité, disposition des réponses, comportement de secours ou limite concernant les demandes hors sujet que l’agent doit respecter doit figurer à la fois dans ses instructions et dans les outils d’évaluation utilisés pour noter ses réponses.

Relier les réponses aux données approuvées

Les instructions déterminent le comportement de l’agent, tandis que les connaissances déterminent ce à quoi il peut répondre. Dans les cas simples, l’attachement de fichiers et leur mise à disposition via des outils de recherche permet aux réponses de citer des sources matérielles.

Les grandes structures d’entreprise peuvent utiliser Foundry IQ, une couche de connaissances partagée provenant de multiples sources. Une base de connaissances peut être liée à Azure Blob Storage, SharePoint, OneLake, des index de recherche existants ainsi qu’à du contenu web public ; les systèmes de recherche automatisés planifient les requêtes, choisissent les sources, les recherchent et retournent des résultats cités et fondés.

Une mise en garde concerne le contrôle d’accès. Les permissions au niveau du document ne sont prises en compte que pour les sources et les configurations qui les supportent ; par conséquent, personne ne devrait décrire une base de connaissances comme étant sensible aux permissions avant que les permissions de la source ainsi que le flux d’identité ne soient réellement configurés.

Pour observer l’effet, posez une question deux fois, avant et après l’activation. La première réponse révèle les connaissances générales du modèle, tandis que la seconde doit montrer l’impact de vos données.

Activer le suivi tôt

L’observabilité est particulièrement utile tant que l’agent continue de rencontrer des problèmes. Le suivi de Foundry suit les conventions d’OpenTelemetry et s’intègre à Azure Monitor Application Insights, enregistrant le parcours d’un agent ou d’une application afin que les appels au modèle, l’utilisation des outils, les entrées, les sorties et les temps de réponse puissent être examinés par la suite.

Trois niveaux s’appuient sur cette représentation opérationnelle commune, chacun répondant à sa propre question :

• Le suivi vous indique ce qui s’est produit lors d’une exécution particulière.
• L’évaluation vous permet de savoir si le comportement répond aux critères requis.
• La surveillance vous montre l’évolution des exécutions dans le temps.

N’oubliez pas que la télémétrie d’Application Insights est facturée en fonction du volume et de la durée de conservation des données. Prévoyez des ressources pour l’observabilité en tant que composante de l’architecture de production, et non comme un avantage gratuit pour le débogage.

Mesurez le comportement, pas les intuitions

Les tests pratiques sont utiles pour explorer, mais ils ne permettent pas de déterminer avec certitude si une modification a amélioré l’agent. Foundry propose des évaluateurs prêts à l’emploi couvrant plusieurs dimensions du comportement : qualité, risque et sécurité, ainsi que des indicateurs spécifiques à l’agent, tels que le respect des tâches, leur achèvement, la compréhension des intentions et l’efficacité avec laquelle les outils sont utilisés.

Les évaluateurs personnalisés prennent généralement l’une de deux formes. Ceux basés sur des grilles d’évaluation ou des prompts utilisent un modèle comme juge pour les critères subjectifs ou dépendants du contexte. Ceux de type déterministe sont des fonctions simples pour des critères que l’on peut calculer directement. Le degré d’amabilité d’une réponse peut nécessiter une grille d’évaluation, tandis qu’un plafond de longueur ne l’exige jamais. L’évaluation ajoute ses propres coûts et sources d’erreur ; donc, lorsque une fonction peut prendre cette décision de manière fiable, une nouvelle invocation d’un modèle représente un gaspillage d’argent.

Les ensembles de données rendent l’itération rigoureuse

Un seul prompt montre que une fonctionnalité fonctionne, mais un ensemble de données révèle des schémas. Foundry peut évaluer un fichier JSONL ou CSV que vous avez préparé, des traces que vous possédez déjà, ou des données de test synthétiques. Les données synthétiques sont utiles avant le lancement et lorsque le trafic réel est trop faible pour couvrir les cas limites pertinents.

Le résultat est un cycle que l’on peut répéter :

1. Fixer un ensemble de test représentatif afin qu’il reste constant.
2. Exécuter la version actuelle de l’agent sur cet ensemble.
3. Modifier exactement une variable, que ce soit le modèle, les instructions, la configuration de l’outil ou les paramètres de référence.
4. Évaluer à nouveau sur le même ensemble.
5. Comparer les scores, les temps de réponse et les ressources utilisées.
6. Accepter ou rejeter la modification.

Ici, le travail cesse de ressembler à de simples ajustements sur les prompts pour devenir similaire à des tests de régression pour du logiciel.

Les attaques de type red teaming détectent ce que les évaluations normales manquent

Les contrôles de qualité ordinaires vérifient si l’agent accomplit bien la tâche qui lui a été assignée. Le red teaming, quant à lui, examine ce que fait le système lorsque quelqu’un y fournit délibérément des données hostiles. L’agent AI Red Teaming intégré à Foundry combine le projet open source PyRIT avec l’évaluation des risques et de la sécurité de Foundry. Il teste les modèles et agents pris en charge à l’aide de méthodes d’attaque conçues pour contourner les mesures de sécurité standard, et il indique un taux de réussite des attaques (ASR).

Les méthodes prises en charge incluent des transformations telles que Flip et Tense, ainsi que des jailbreaks et d’autres astuces adversariales. Les scénarios de risque actuels couvrent le contenu nocif, la fuite de données sensibles, les actions interdites et l’injection indirecte de prompts. Cet exercice est utile lorsque son tableau de scores stimule une nouvelle vague d’améliorations techniques, et non lorsqu’il se limite à un simple screenshot pour la conformité. Considérez-le comme un cycle :

1. Effectuez un scan dans un environnement qui n’est pas en production.
2. Étudiez quelle catégorie de risque et quel type d’attaque ont réussi à passer.
3. Réparez la cause, qu’il s’agisse d’une instruction, d’une limite liée à l’outil, d’un contrôle de contenu ou d’une autorisation.
4. Effectuez un autre scan.
5. Vérifiez si le taux de réussite des attaques diminue progressivement.

Surveillez l’ensemble du parc

Lorsque les agents sont en service, la question n’est plus de savoir si une instruction a fonctionné, mais plutôt de comprendre le comportement du système sur plusieurs semaines. Les vues de surveillance et d’exploitation affichent des indicateurs pour l’ensemble de la charge de travail, tels que le nombre d’appels, l’utilisation des tokens, les échecs et des métriques liées aux coûts, avec la possibilité de se concentrer sur des agents ou des modèles spécifiques lorsque c’est possible.

Penser en termes de microservices est utile ici, dans certaines limites. Un agent peut être considéré comme une unité de comportement disposant de sa propre version, composée d’instructions, d’outils, de connaissances, d’une politique de modèle ainsi que de résultats observables. Chaque agent n’a pas nécessairement besoin de devenir un service déployé séparément. L’objectif est de définir des limites afin qu’un agent puisse être modifié, évalué et promu sans devoir réécrire tout ce qui l’entoure.

Le cycle sous le portail

Dans la pratique, ce cycle se déroule en phases de construction, de mesure, d’optimisation, de gouvernance, avant de revenir au point de départ chaque fois que des éléments indiquent que l’agent n’est pas prêt. On progresse lorsque les traces et les scores atteignent un seuil fixé à l’avance, et jamais simplement parce qu’une démonstration a été réussie. Les interfaces du produit changent, mais la routine reste identique : prototype, suivi, évaluation, renforcement, surveillance et répétition.

Une précaution à prendre pour l’instant : Microsoft compte mettre fin au support des Foundry Workflows le 1er décembre 2026 et oriente les nouveaux workflows vers le Microsoft Agent Framework. Une nouvelle conception ne devrait pas être basée sur une technologie qui disparaîtra bientôt.

De prototype navigateur à code en production

Le portail doit accélérer l’accès au code et ne pas en être un substitut. Des besoins tels que l’orchestration personnalisée, les processus CI/CD, une intégration plus poussée ou des codes d’agent hébergés exigent l’utilisation du Foundry SDK et de ses outils, actuellement disponibles pour Python, C#, JavaScript et Java. Sur le plan architectural, les ressources et les points d’entrée du projet restent centraux. Le portail, le SDK et les outils ne sont que différentes façons d’accéder au même projet Foundry et à ses ressources ; imaginez donc un projet doté d’un point d’entrée unique, sans plateforme de prototype ni plateforme de production distinctes. La démarche de démarrage rapide du SDK sur Microsoft Learn marque le début de cette transition.

Prochains essais

Deux sujets suivent. Le premier concerne l’orchestration multi-agents, où des agents testables de manière indépendante, chacun disposant d’un contrat clair et d’une base d’évaluation définie, sont combinés au moyen d’un cadre d’orchestration moderne plutôt que regroupés dans une seule instruction complexe. Le second concerne la personnalisation des modèles, qui ne mérite d’être évaluée que lorsque les méthodes de génération d’instructions, de contextualisation, de routage et de conception d’outils se sont révélées insuffisantes. Chacun de ces sujets s’inscrit après la discipline d’évaluation décrite ici.

Pensée finale

La première réponse fonctionnelle fournie par un agent lance le processus sans pour autant l’achever. Un candidat à la mise en production nécessite des preuves sur plusieurs fronts : un choix de modèle qui se révèle fiable lors d’une comparaison avec d’autres charges de travail, des éléments permettant de justifier les changements visibles dans les réponses, des appels d’outils que l’on peut observer, une évaluation reproductible, ainsi qu’un indicateur de risque pour l’équipe rouge qui diminue avec le temps. Le portail permet ce cycle rapide, tandis que le projet et le SDK transforment ces travaux en une véritable ingénierie de production. Construisez rapidement, intégrez des outils d’instrumentation dès le début, testez chaque modification sur la même charge de travail, examinez votre propre système avant que des tiers ne le fassent, et passez au code une fois que le navigateur a trouvé comment répondre efficacement aux demandes.