Le nom a changé ; la question opérationnelle demeure
Microsoft appelle désormais la plateforme Microsoft Foundry. Les noms précédents — Azure AI Studio et Azure AI Foundry notamment — restent présents dans les documents d’architecture, le code, les résultats de recherche et le vocabulaire des organisations. La plateforme actuelle réunit agents, modèles, outils, évaluations, traçage, supervision, identité, réseau et politiques dans un modèle de gestion Azure plus unifié.
Cette consolidation est utile. Elle ne remplace pas une stratégie.
La première question de l’entreprise ne devrait pas être « Comment adopter Foundry ? », mais : Quel résultat métier mérite un système IA délimité, et quelles preuves justifieraient sa mise en exploitation ?
Ce que Foundry peut standardiser
Une plateforme mérite sa place lorsqu’elle élimine du travail d’ingénierie répétitif sans masquer les décisions importantes. Foundry peut fournir un projet et un plan de contrôle communs pour plusieurs étapes du cycle de vie :
- accès à des modèles pris en charge via des points de terminaison gérés ;
- runtimes d’agents déclaratifs ou hébergés ;
- outils, recherche documentaire et connexions aux connaissances ;
- évaluations avant déploiement ;
- traçage, supervision et signaux de qualité en production ;
- identité Microsoft Entra, contrôle d’accès par rôle, isolation réseau et Azure Policy.
Cette cohérence peut réduire le nombre de portails, d’identifiants, de SDK et de modèles opérationnels que l’équipe plateforme doit gouverner. Elle peut aussi clarifier le passage d’une expérimentation à un service pris en charge.
Ce que la plateforme ne décide pas
Foundry ne sait pas si un processus mérite d’être automatisé. La plateforme ne peut pas définir les erreurs tolérables, la personne qui accepte le risque résiduel ou le moment où un humain doit intervenir. La présence d’un service d’évaluation ne crée pas, à elle seule, un jeu de tests représentatif.
Ces décisions restent organisationnelles :
- Nommer le résultat et son responsable métier.
- Documenter la situation initiale en matière de délai, qualité, coût ou risque.
- Définir la frontière des données et des actions.
- Construire les tests d’acceptation à partir de cas représentatifs.
- Attribuer la responsabilité de production et la voie d’incident.
Sans ces conditions, une plateforme sophistiquée peut accélérer une mission mal définie.
Construire une architecture de mission
Traitez chaque premier déploiement comme une mission aux limites explicites. Séparez le processus métier, le point de terminaison du modèle, la recherche documentaire, les outils et l’interface. Gardez le jeu d’évaluation suffisamment portable pour comparer les changements de modèle ou d’orchestration. Préservez l’identité de l’utilisateur lorsque le système atteint des données ou des actions métier.
Décidez ensuite quelles capacités Foundry sont utiles. Un assistant interne simple peut nécessiter un modèle, une recherche documentaire, de la télémétrie applicative et une chaîne d’évaluation ciblée. Un agent utilisant des outils peut aussi exiger une identité gérée, un déploiement versionné, des traces distribuées, des limites d’action et des points d’approbation humaine. Toutes les missions n’ont pas besoin de toutes les fonctions.
Une séquence d’adoption raisonnable
Premièrement, prouver la tâche. Utilisez des exemples réels, difficiles et adverses. Établissez si le système améliore réellement le processus.
Deuxièmement, prouver les contrôles. Testez les permissions, l’ancrage dans les sources, les outils, le refus, l’escalade, la latence et le coût — pas uniquement la qualité des réponses.
Troisièmement, prouver l’exploitation. Versionnez l’application, observez-la en production, examinez les traces en échec et vérifiez que la responsabilité survit à l’équipe pilote.
Ce n’est qu’ensuite que l’organisation devrait créer des modèles de plateforme réutilisables pour d’autres missions.
La décision de direction
Choisissez Foundry parce que ses contrôles et services gérés correspondent à votre environnement Azure et réduisent le coût d’exploitation des charges sélectionnées. Ne le choisissez pas parce que l’organisation a besoin d’une initiative « plateforme IA » visible.
L’actif durable n’est pas la configuration du portail. C’est l’association d’une mission utile, de preuves représentatives, de limites appliquées et d’une équipe capable d’exploiter le système quand les modèles et les exigences changent.
Référence officielle
Microsoft décrit le modèle actuel et la transition depuis Azure AI Foundry dans Qu’est-ce que Microsoft Foundry ?.