Azure AI Foundry Threads

Quand vous déployez une IA dans Azure AI Foundry, vous ne lancez pas simplement un gros modèle dans la nature. Vous le placez dans un environnement d'exécution géré, où les messages, les appels d'outils et les étapes d'exécution pertinents sont consignés et tracés. L'IA cesse d'être un électron libre : elle devient un système discipliné, que l'on peut gouverner.

Cet article présente les briques qui rendent cela possible : l'agent et sa triade modèle-instructions-outils, les threads, les exécutions (runs), les étapes d'exécution (run steps) et enfin les outils qui permettent à l'agent d'agir. Ensemble, elles rendent vos agents IA auditables, reproductibles et prêts pour l'entreprise.

Agent Azure AI : une triade modèle, instructions et outils

Un agent Azure AI n'est pas une simple fenêtre de discussion. On peut le voir comme un chef d'escouade, un capitaine de terrain conçu pour accomplir des missions selon un cadre clair. Ce cadre repose sur trois éléments fondamentaux.

• Le modèle est le cerveau. Il gère le raisonnement et le langage : analyser les demandes, planifier les étapes, rédiger les réponses.
• Les instructions sont les ordres de mission. Elles empêchent le modèle de dériver et l'ancrent dans les résultats réellement attendus.
• Les outils sont l'équipement : exécution de code, connecteurs de recherche, API de reporting ou tout système tiers que vous connectez.

Sans cette triade, vous n'obtenez ni reproductibilité ni auditabilité, juste de la génération de texte sans reçu.

Une image pour comprendre

Le modèle correspond à l'entraînement du capitaine. Les instructions sont le briefing : protéger le convoi, extraire des données d'un ensemble de contrats, rendre compte dans un format précis. Les outils apportent la spécialisation, par exemple un interpréteur de code pour exécuter des analyses, ou un connecteur SharePoint ou MCP personnalisé qui alimente l'agent en données en direct. Réunis, ces trois éléments font que l'agent n'improvise pas : il exécute une mission, avec des journaux et des points de contrôle.

Pourquoi ces trois couches changent tout en entreprise

Dans la plupart des API de chat, on obtient uniquement un modèle et une invite. Une fois que le modèle commence à répondre, il n'existe aucune notion formelle d'ordres ni d'orchestration d'outils. Le service d'agents de Foundry, lui, garantit que les trois couches sont présentes.

Vous n'êtes pas non plus enfermé dans un seul cerveau. Vous pouvez choisir parmi les modèles du catalogue Foundry : GPT-4 pour une stratégie complexe, un modèle plus léger pour les tâches simples, ou encore Mistral. Vous retenez ce qui convient à la mission, et c'est cette souplesse qui distingue un stagiaire universel d'un commandant capable de s'adapter.

Ce qui se passe quand les couches manquent

• Des résultats incohérents : un résumé de contrat dit une chose, le suivant le contredit subtilement.
• Une perte de traçabilité : aucun journal structuré ne montre comment la réponse a été obtenue.
• Un débogage au jugé : les développeurs ne peuvent pas retracer la chaîne de raisonnement.

En entreprise, ce n'est pas un simple désagrément. C'est un risque réel qui freine la confiance et l'adoption.

Foundry y répond par des garde-fous intégrés. Les instructions jouent le rôle d'un règlement à suivre. L'ensemble d'outils peut être défini de façon stricte ou étendue selon le cas d'usage. Le modèle peut être remplacé librement, mais toujours dans une structure qui impose la responsabilité.

Les threads Azure AI Foundry : le journal persistant des conversations

Dans Azure AI Foundry, un thread n'est pas une fenêtre de discussion qui disparaît à la fermeture. C'est une session de conversation persistante. Chaque échange y est stocké, qu'il vienne de l'utilisateur, de l'agent ou d'un autre agent dans une configuration multi-agent. Cet historique durable peut être consulté longtemps après la fin de la discussion.

Un thread n'est pas une transcription statique : c'est un conteneur structuré. Il gère automatiquement la troncature pour garder le contexte actif dans les limites du modèle, tout en préservant une piste d'audit complète. L'agent continue donc de comprendre la conversation en cours, tandis que l'entreprise conserve un enregistrement permanent et consultable. Vous obtenez de la continuité pour l'agent et de la gouvernance pour l'organisation.

Des messages riches et horodatés

Les entrées du thread sont des messages. Un message ne se limite pas à du texte : il peut contenir une image, un fichier tableur ou un bloc de code généré. Chacun est horodaté et associé à un rôle, utilisateur ou assistant. En inspectant un thread, on voit non seulement ce qui a été dit, mais aussi par qui, quand, et de quel type de contenu il s'agissait.

Un responsable de la conformité peut ainsi retrouver la demande exacte soumise la veille, le graphique produit en réponse et le moment où chaque événement s'est produit. C'est un véritable registre, plus qu'une simple mémoire. L'image du carnet de notes d'une campagne de jeu de rôle est parlante : en documentant les événements, il évite les disputes sur ce qui s'est réellement passé.

Audit, conformité et débogage

Les régulateurs ou les équipes d'audit interne peuvent ouvrir un thread et voir immédiatement la séquence complète : demande de l'utilisateur, réponse de l'agent, outils impliqués, chronologie. Pour les développeurs, le même enregistrement sert de mode débogage : si l'agent a produit un mauvais extrait de code, on remonte jusqu'à la demande d'origine. Sans threads, on en est réduit aux captures d'écran et aux souvenirs approximatifs, ce qui ne suffit pas quand la conformité réclame des preuves ou que le support doit reproduire un bug. Si plusieurs agents se répartissent les tâches, leurs échanges sont eux aussi consignés.

Exécutions (runs) : le moment où l'agent passe à l'action

Le thread conserve le contexte : l'historique, les ordres, les éléments de travail. Une exécution est le déclencheur qui active l'agent pour qu'il prenne ce contexte et le traite réellement. Les threads se souviennent, les exécutions agissent.

Concrètement, votre thread peut contenir la demande d'analyser un fichier CSV ou de dessiner un graphique linéaire. L'exécution est le moment où l'agent traite cette demande à travers son modèle, ses instructions et ses outils : il peut chercher des données supplémentaires, traiter des chiffres ou appeler l'interpréteur de code pour générer un artefact.

Des exécutions suivies par statut

Une exécution n'est pas une boîte noire. Elle est surveillée et suivie par état. On rencontre généralement des statuts comme mis en file d'attente, en cours, action requise, terminée ou échouée. Les exemples du SDK interrogent souvent ces états en boucle. On sait ainsi non seulement ce qui se fait, mais aussi quand.

Étapes d'exécution (run steps) : la notation d'échecs de l'IA

Une réponse peut sembler correcte sans que l'on sache si l'agent a appelé une API externe, écrit du code ou simplement improvisé du texte. Dans un contexte d'entreprise, cette opacité est dangereuse. Les étapes d'exécution lèvent le doute : chaque exécution est enregistrée pas à pas, avec les sorties du modèle, les outils invoqués, les calculs effectués et les messages produits.

C'est l'équivalent de la notation aux échecs. Chaque action est écrite dans l'ordre, et on peut donc la rejouer plus tard.

Ce que cela apporte aux équipes

• Développeurs : en faisant défiler la chronologie, on repère l'erreur exacte, qu'il s'agisse d'une mauvaise requête de recherche ou d'une erreur de calcul. Le débogage devient une analyse médico-légale plutôt qu'une devinette.
• Conformité : à la question « comment ce résumé a-t-il été généré ? », on répond avec des reçus (appel d'outil, code exécuté, réponse assemblée) plutôt qu'avec des explications abstraites sur le raisonnement du modèle.
• Opérations : si un workflow doit être relancé, on suit la même séquence. Si un résultat est contesté, on le rejoue.

Les threads fournissent le journal général, les exécutions l'action, et les étapes d'exécution le détail mouvement par mouvement. L'IA improvisée devient un coéquipier responsable, dont on peut suivre, tester et défendre les actions.

Outils et intégrations : de l'agent bavard à l'agent qui travaille

Ce sont les outils qui font passer un agent de la parole à l'action. Au lieu de décrire comment vérifier un document ou effectuer un calcul, l'agent le fait et renvoie le résultat. C'est ce qui donne de la valeur à la plateforme en entreprise, au-delà de l'effet de démonstration. Foundry propose trois grandes catégories.

1. Les outils intégrés

On y trouve l'interpréteur de code, la recherche Bing, les connecteurs SharePoint et Microsoft Fabric, ainsi qu'Azure AI Search. L'agent peut analyser des données, extraire des fichiers, rechercher du contenu d'entreprise, et produire des graphiques ou des rapports sans code sur mesure.

2. Les outils personnalisés : OpenAPI et MCP

Vous n'êtes pas limité à ce que fournit Microsoft. Foundry permet d'enregistrer des outils personnalisés via des spécifications OpenAPI ou le Model Context Protocol (MCP). Le MCP est présenté comme l'USB-C des outils d'IA : au lieu d'écrire des wrappers à la main pour chaque serveur MCP distant, le système prend en charge la découverte, la gestion des versions et l'invocation des outils. Les coûts d'intégration baissent nettement, surtout quand il faut relier des dizaines de systèmes.

3. Des appels d'outils observables

Chaque appel d'outil est consigné au niveau des étapes, avec l'identité, les entrées, les sorties et les horodatages. La vue opérationnelle n'a rien de magique : c'est un registre. On peut vérifier ce qui a été invoqué, confirmer que les autorisations ont été respectées et conserver des preuves pour la conformité.

Un exemple concret

Vous téléchargez un fichier CSV sous forme de message dans un thread. L'agent appelle l'interpréteur de code dans ses étapes d'exécution, traite le fichier et génère un graphique. Cet artefact revient sous forme d'image jointe, visible directement dans le journal du thread. Vous n'avez écrit ni analyseur ni module de visualisation. Ce comportement figure dans les exemples du SDK.

Sécurité et intégration d'entreprise

Les outils peuvent se connecter à des applications logiques, ce qui ouvre l'accès à plus de 1 400 connecteurs SaaS et sur site. Plutôt que de recoder des adaptateurs pour vos plateformes CRM, ERP ou ITSM, vous vous appuyez sur les connecteurs que l'entreprise utilise déjà, sans bâtir de ponts d'API fragiles.

Côté sécurité, lorsque les outils se connectent à des systèmes comme SharePoint ou Fabric, ils s'authentifient via Microsoft Entra. Si vous n'aviez pas le droit de lire un fichier hier, l'agent ne contournera pas cette restriction aujourd'hui : identité et autorisations restent intactes. Chaque appel reste traçable : qui l'a invoqué, ce qui a été envoyé, ce qui a été reçu. C'est à cette condition que les équipes de conformité peuvent donner leur accord.

Les pièges à éviter

• Se contenter d'un modèle et d'une invite. Sans instructions ni outils bien définis, les résultats deviennent incohérents et impossibles à auditer.
• Ne pas conserver les conversations. Sans threads, il ne reste que des captures d'écran et des souvenirs : pas d'enregistrement, pas de preuves, et donc pas de correction possible.
• Juger une exécution sur sa seule réponse finale. Sans étapes d'exécution, impossible de savoir si l'agent a appelé une API, écrit du code ou improvisé du texte.
• Confondre agent bavard et agent opérationnel. Sans outils connectés de façon responsable et bien journalisés, la session de chat parle beaucoup mais ne fait jamais le travail.

Points clés à retenir

• Construisez chaque agent sur la triade modèle, instructions et outils.
• Choisissez le modèle du catalogue Foundry adapté à la mission : le cadre reste le même quand vous en changez.
• Utilisez les threads comme journal persistant et consultable de toutes les interactions, y compris entre agents.
• Suivez les exécutions par leurs statuts (mis en file d'attente, en cours, action requise, terminée, échouée).
• Inspectez les étapes d'exécution pour rejouer, déboguer et justifier un résultat.
• Combinez outils intégrés, outils OpenAPI et serveurs MCP selon vos besoins.
• Appuyez-vous sur l'authentification Microsoft Entra pour préserver identité et autorisations.
• Passez à la pratique : lancez un projet de test, créez un agent de base, exécutez un thread, puis inspectez les étapes d'exécution dans le SDK ou le portail pour vérifier que vos journaux correspondent à ce qui s'est réellement passé.

Conclusion

Azure AI Foundry ne se contente pas d'envoyer des invites à un modèle. La plateforme offre une méthode reproductible pour créer des agents dotés d'un cerveau, d'un règlement et d'une boîte à outils, dont chaque action est consignée dans des threads, des exécutions et des étapes d'exécution. Pour les responsables du développement comme pour ceux de la conformité, le bénéfice est le même : une exécution vérifiable et rejouable, avec une visibilité complète sur le cycle de vie de l'agent. C'est ce qui transforme une IA improvisée en un système sur lequel on peut compter en production.