Microsoft Copilot Studio est l’atelier de Microsoft 365 qui permet de créer, publier et gouverner des agents IA connectés aux données de l’entreprise, sans construire de moteur. Microsoft Foundry, anciennement Azure AI Foundry, est la plateforme Azure qui permet de construire des agents à moteur personnalisé, avec choix du modèle, indexation sur mesure et orchestration explicite.
Le verdict tient en trois phrases. Copilot Studio quand le besoin vit dans Microsoft 365 et que la valeur vient de vos données et de vos processus. Microsoft Foundry quand le scénario dépasse l’atelier : moteur, modèle ou orchestration spécifiques. Dans beaucoup de projets, les deux cohabitent, Copilot Studio en façade dans Microsoft Teams et Foundry derrière.
Cet article compare les deux plateformes sur dix critères, arbitre trois scénarios courants et décrit l’architecture mixte que nous rencontrons le plus souvent en grand compte. Si la notion d’agent reste floue dans votre organisation, commencez par notre définition de ce qu’est un agent IA. Le choix se décide cas d’usage par cas d’usage, pas une fois pour toutes.
Microsoft Copilot Studio : l'atelier d'agents intégré à Microsoft 365
Copilot Studio est un atelier graphique. Vous décrivez un agent par ses sujets, ses actions et ses instructions, vous lui désignez ses sources de connaissances, et la plateforme prend en charge la compréhension de la demande, la recherche dans les sources et la formulation de la réponse. C’est le principe de l’agent déclaratif : aucun moteur à écrire, aucune chaîne d’orchestration à coder, aucun index à maintenir. Un profil métier ou un maker Power Platform, accompagné d’un architecte Microsoft 365, produit un premier agent utilisable. Pour la définition de l’objet lui-même, voir qu’est-ce qu’un agent Copilot.
Les agents vivent là où vos collaborateurs travaillent déjà. La publication se fait dans Microsoft Teams, dans Microsoft 365 Copilot Chat, sur un canal web ou dans un site SharePoint. Cette proximité pèse lourd sur l’usage réel : l’agent est à un clic de la conversation en cours, pas derrière une adresse de plus à retenir.
Côté données, l’agent se branche sur des sources de connaissances SharePoint et des sites web, sur des tables Dataverse, et sur les connecteurs Power Platform qui ouvrent l’accès à Dynamics 365 et aux applications métier. Microsoft Graph apporte le contexte de l’utilisateur. Point déterminant pour une DSI : les requêtes s’exécutent avec l’identité de l’utilisateur, donc les permissions SharePoint s’appliquent nativement, sans rien reconstruire.
- Construction : sujets, actions, instructions et sources de connaissances, dans une interface graphique.
- Publication : Microsoft Teams, Microsoft 365 Copilot Chat, canal web, site SharePoint.
- Données : SharePoint, Dataverse, connecteurs Power Platform, Dynamics 365, Microsoft Graph.
- Consommation : l’usage des agents est facturé en crédits Copilot Studio, en paiement à l’usage ou en packs de capacité ; le périmètre couvert par une licence Microsoft 365 Copilot dépend du canal de publication, vérifiez-le avec votre contrat Microsoft et sur la page de tarification Microsoft Copilot Studio.
- Gouvernance : les agents Copilot Studio sont provisionnés dans un environnement Power Platform, qui s’appuie sur Dataverse, et se pilotent depuis le centre d’administration, avec un inventaire des agents.
Microsoft Foundry, anciennement Azure AI Foundry : la plateforme des agents sur mesure
Microsoft Foundry, anciennement Azure AI Foundry, est l’environnement Azure dans lequel une équipe technique conçoit un agent de bout en bout. Ici, rien n’est déclaratif : vous choisissez le modèle, vous écrivez l’orchestration, vous décidez de la façon dont les documents sont découpés, indexés et restitués. C’est la plateforme des agents à moteur personnalisé, les custom engine agents, et la documentation Microsoft Foundry en décrit le périmètre complet.
Le premier apport est le catalogue de modèles : vous comparez des modèles OpenAI, Mistral et des modèles ouverts sur vos propres jeux de test, et vous basculez de l’un à l’autre par cas d’usage plutôt que pour toute l’organisation. Le second est le contrôle du moteur documentaire : découpage, enrichissement des métadonnées, indexation dans Azure AI Search, garde-fous et évaluation systématique des réponses.
L’outillage suit la même logique de code : l’Agent SDK et Semantic Kernel, la bibliothèque d’orchestration open source de Microsoft, le protocole MCP pour exposer des outils à un agent, et le service d’agents de Microsoft Foundry pour héberger l’exécution. Le modèle économique change lui aussi de nature : vous payez de la consommation Azure, tokens, indexation, calcul et stockage, dans vos abonnements et vos régions.
- Catalogue de modèles : comparaison et bascule modèle par modèle selon le cas d’usage.
- Moteur documentaire : découpage, enrichissement et indexation maîtrisés, Azure AI Search.
- Orchestration : Agent SDK, Semantic Kernel, MCP, service d’agents de Microsoft Foundry.
- Exécution : vos abonnements Azure, vos régions, votre réseau et vos clés.
- Coût : consommation Azure, tokens, indexation, calcul, stockage.
La contrepartie mérite d’être dite franchement. Tout ce qui est natif dans Copilot Studio devient une charge de conception dans Foundry : la propagation de l’identité de l’utilisateur, le respect des permissions SharePoint, la publication dans Microsoft Teams et la gouvernance fonctionnelle des agents. Ce n’est pas une faiblesse de la plateforme, c’est le prix du contrôle.
Copilot Studio vs Microsoft Foundry : le comparatif en 10 critères
Le tableau ci-dessous reprend les dix critères sur lesquels se joue l’arbitrage dans nos cadrages. Il se lit critère par critère, sans colonne gagnante.
Sur mobile, faites glisser le tableau vers la gauche pour afficher la colonne Microsoft Foundry.
| Critère | Microsoft Copilot Studio | Microsoft Foundry |
|---|---|---|
| 1. Modèle de construction | Atelier graphique, sujets, actions et instructions, agents déclaratifs, publication en quelques clics | Développement d'un moteur, code et SDK, orchestration écrite et versionnée |
| 2. Compétences requises | Équipe métier ou maker Power Platform, accompagnée d'un architecte M365 | Développeurs .NET ou Python, architecte IA, pratiques de déploiement continu |
| 3. Modèles disponibles | Modèles Microsoft intégrés, peu de réglages | Catalogue de modèles Azure, dont Mistral via Azure AI Foundry, et Claude via l'API Anthropic, comparables par cas d'usage |
| 4. Connexion aux données et RAG | Sources de connaissances SharePoint et sites web, Dataverse, connecteurs Power Platform, Microsoft Graph | Indexation sur mesure, Azure AI Search, découpage et enrichissement des documents maîtrisés de bout en bout |
| 5. Permissions et identité | Requêtes exécutées avec l'identité de l'utilisateur, permissions SharePoint respectées nativement, étiquettes Microsoft Purview | À concevoir : propagation de l'identité Microsoft Entra ID et filtrage des index par habilitation, à la charge du projet |
| 6. Hébergement et résidence des données | Environnement Power Platform de votre tenant Microsoft 365, région choisie à la création | Vos abonnements Azure, vos régions, réseau et clés maîtrisés |
| 7. Modèle de coût | Crédits Copilot Studio, paiement à l'usage ou packs de capacité, en plus des licences Microsoft 365 | Consommation Azure : tokens, indexation, calcul, stockage |
| 8. Gouvernance et supervision | Centre d'administration Power Platform, politiques de données, inventaire des agents, pilotage transverse avec Agent 365 | Vos outils Azure pour la supervision technique, la gouvernance fonctionnelle des agents reste à construire |
| 9. Délai jusqu'au premier agent en production | 6 à 12 semaines, cadrage 2 à 4 puis build 4 à 8 | Selon le périmètre, à cadrer |
| 10. Quand le choisir | Le besoin vit dans Microsoft 365 et la valeur vient de vos données et de vos processus | Le besoin dépasse l'atelier : moteur, modèle ou orchestration spécifiques |
Aucune des deux plateformes n’est meilleure que l’autre. Elles répondent à deux questions différentes : où vit l’agent, et qui écrit son moteur. Sur le critère 6, le cadre de conformité se traite de la même manière dans les deux cas et se documente avec vous, hébergement en Europe et en Suisse, certification ISO/IEC 27001:2022 : voir la sécurité et conformité de vos agents.
La version courte, avec AI Desk Pro en troisième option, est sur notre page partenaire Copilot Studio et Microsoft Foundry.
Vous hésitez sur un cas d’usage précis ? Nous arbitrons en une séance de cadrage.
Trois scénarios et la plateforme que nous recommandons
Un agent de questions-réponses RH ou IT sur SharePoint
Les collaborateurs posent toujours les mêmes questions sur les congés, la mutuelle, la réinitialisation d’un accès ou le catalogue logiciel. Les réponses existent déjà, dispersées dans des documents SharePoint que personne n’ouvre.
Notre recommandation : Copilot Studio. La source de vérité est déjà dans SharePoint, les permissions s’appliquent avec l’identité de l’utilisateur, et la publication dans Microsoft Teams est immédiate. Rien à construire côté moteur, donc rien à maintenir. Ce type d’agent RH, comme celui déployé chez France Télévisions, atteint 95 % d’adoption et a permis d’économiser 7 mois de travail RH.
Si vous n’avez pas d’équipe interne pour maintenir l’agent et que le besoin est un support IT ou RH standard, un produit prêt à déployer comme AI Desk Pro répond au même besoin sans projet de développement.
À surveiller : la fraîcheur des sources. Un agent branché sur une bibliothèque SharePoint jamais nettoyée restitue des réponses périmées avec la même assurance que des réponses justes.
Un agent commercial connecté à Dynamics 365 et Dataverse
Les commerciaux passent leurs journées entre le CRM et Microsoft Teams. Ils veulent préparer un rendez-vous, retrouver l’historique d’un compte et rédiger une proposition sans changer d’outil.
Notre recommandation : Copilot Studio, avec un moteur Foundry seulement si vous devez maîtriser le modèle ou une logique de scoring propriétaire. Les connecteurs vers Dynamics 365 et Dataverse sont natifs, les actions écrivent dans le CRM, et l’agent se publie là où la force de vente travaille. Chez GroupeActive, la rédaction d’une proposition commerciale est passée d’une journée à deux heures, soit 75 % de temps gagné, comme le décrit l’étude de cas publiée par Microsoft.
À surveiller : la consommation de crédits quand l’agent sert quotidiennement à toute la force de vente. Le modèle de coût se vérifie avant le déploiement général, pas après.
Un moteur multi-étapes avec traitement documentaire et plusieurs modèles
Vous devez extraire des données de contrats ou de dossiers, les classer, enchaîner plusieurs traitements et comparer le comportement de plusieurs modèles avant d’arrêter votre choix.
Notre recommandation : Microsoft Foundry. L’extraction et la classification de documents, l’enchaînement d’étapes, l’évaluation comparative des modèles et le contrôle de l’index dépassent ce qu’un atelier déclaratif sait faire. Vous avez besoin d’écrire l’orchestration, pas de la paramétrer.
À surveiller : la propagation des habilitations Microsoft Entra ID et la supervision, qui ne sont pas fournies par défaut et doivent entrer au périmètre du projet dès le cadrage.
Quand combiner les deux : Copilot Studio devant, Microsoft Foundry derrière
C’est le schéma le plus fréquent dans les grands comptes que nous accompagnons. L’utilisateur s’adresse à un agent Copilot Studio publié dans Microsoft Teams ou dans Microsoft 365 Copilot Chat. Cet agent appelle un moteur Microsoft Foundry via un connecteur personnalisé ou un serveur MCP exposant le moteur. L’expérience, l’identité et les permissions restent du côté Microsoft 365 ; la complexité, les modèles et l’orchestration restent du côté Azure.
Ce découpage a trois conséquences pratiques. L’orchestration multi-agents s’écrit une fois, avec l’Agent SDK et Semantic Kernel, puis se réutilise derrière plusieurs façades. Chaque agent reçoit une identité dans Microsoft Entra ID : on lui accorde des droits, on trace ses actions, on le révoque comme un compte de service. Les étiquettes Microsoft Purview continuent de s’appliquer aux contenus manipulés. Enfin, le pilotage du parc, inventaire, propriétaires, accès et coûts, se traite avec Agent 365.
Aucune plateforme supplémentaire n’est à acheter : tout reste dans le périmètre Microsoft que vos équipes administrent déjà. Le cadrage de ce type d’architecture entre dans le périmètre du Microsoft Copilot Frontier Program, qui peut financer jusqu’à 50 jours de service.
Cinq erreurs que nous voyons dans les projets d'agents
- Choisir la plateforme avant d’avoir écrit le cas d’usage et identifié la source de vérité. Conséquence : l’architecture est arrêtée avant la question métier, et se paie en reprise.
- Partir sur Foundry pour un besoin de questions-réponses sur SharePoint. Conséquence : l’équipe reconstruit à la main les permissions et la propagation d’identité que Copilot Studio fournit nativement.
- Rester sur Copilot Studio pour un traitement documentaire lourd et multi-étapes. Conséquence : dérive des temps de réponse et des crédits, constatée en production plutôt qu’en cadrage.
- Oublier le coût d’exploitation. Conséquence : personne ne supervise la qualité des réponses, les sources vieillissent, aucun propriétaire n’est identifié.
- Laisser chaque équipe publier ses agents sans inventaire ni règle de nommage. Conséquence : des agents sans propriétaire dans le tenant, que la DSI découvre en audit.
Ces arbitrages se traitent en cadrage. C’est l’objet de notre offre Copilot Factory : cas d’usage, plateforme, gouvernance et transfert de compétences.
Questions fréquentes sur Copilot Studio et Microsoft Foundry
Non, Copilot Studio se souscrit indépendamment de Microsoft 365 Copilot. L'usage des agents est facturé en crédits Copilot Studio, en paiement à l'usage ou en packs de capacité. Le périmètre couvert par une licence Microsoft 365 Copilot dépend du canal de publication : vérifiez-le sur votre contrat Microsoft. Witivio cadre cet arbitrage avec votre DSI avant le build.
Oui, mais pas de la même manière. Un agent Foundry s'expose par API et se place derrière une façade : un agent Copilot Studio publié dans Teams, ou une application Teams dédiée. C'est le schéma que Witivio met en place le plus souvent, l'expérience et les permissions côté Microsoft 365, le moteur côté Azure.
Les deux modèles ne se comparent pas ligne à ligne. Copilot Studio facture des crédits par interaction, en plus de vos licences Microsoft 365. Foundry facture la consommation Azure : tokens, indexation, calcul, stockage. À usage modéré et cas d'usage standard, Copilot Studio revient généralement moins cher ; à fort volume ou traitement lourd, l'arbitrage se fait au cas d'usage. Witivio chiffre les deux pendant le cadrage.
Le choix du modèle n'est pas l'objet de Copilot Studio, qui s'appuie sur les modèles Microsoft intégrés. Pour arbitrer entre modèles, il faut passer par Microsoft Foundry : Mistral via Azure AI Foundry, Claude via l'API Anthropic, avec votre consentement explicite. Witivio retient cette voie quand le cas d'usage justifie un contrôle réel sur le modèle.
Un agent Copilot Studio est provisionné dans un environnement Power Platform, qui s'appuie sur Dataverse. Vos équipes n'ont pas besoin d'être des développeurs Power Platform pour l'utiliser, mais votre DSI doit décider des environnements, des politiques de données et des droits de publication. Witivio pose ce cadre pendant le cadrage, avant le premier agent.
Agent 365 ne remplace ni Copilot Studio ni Microsoft Foundry : c'est la couche de pilotage des agents, quelle que soit la plateforme qui les a produits. Inventaire, propriétaires, accès, coûts et conformité. C'est ce qui évite le foisonnement d'agents sans propriétaire dans le tenant. Witivio met en place ce cadre avec Agent 365.