Créer du code avec l'IA devient trivial. Le faire tourner en production dans un tenant Microsoft 365, avec identité, politiques de sécurité et cycle de vie applicatif maîtrisés, l'est beaucoup moins. C'est ce chantier que Microsoft attaque avec Copilot Managed Runtime, désormais en préversion publique, une réponse directe aux administrateurs qui voient les équipes métier produire des applications plus vite que l'IT ne peut les gouverner.
Un socle d'exécution géré, pas un nouvel outil isolé
Le problème n'est pas la génération de code : les applications créées dans Copilot Cowork et la nouvelle expérience Copilot Code produisent déjà du code fonctionnel. Le problème arrive après — provisionner et sécuriser des ressources cloud, configurer les modèles d'identité, respecter les politiques organisationnelles, mettre en place un processus de déploiement. Chaque plateforme de création finit par imposer son propre modèle de gouvernance, et l'IT se retrouve à gérer autant de playbooks que d'outils.
Copilot Managed Runtime propose l'inverse : une plateforme d'exécution unique, hébergée à l'intérieur de la limite du tenant Microsoft 365, qui hérite des attentes habituelles des utilisateurs (partage, connexions de données en direct, accès simplifié aux applications) tout en restant sous le contrôle de l'IT. Elle alimente déjà les applications construites dans Copilot Cowork, Copilot Code et Microsoft Copilot Studio, et s'ouvre également aux développeurs professionnels et aux outils tiers.
Au lieu de reconstruire une fondation sécurité/identité/déploiement pour chaque application créée par l'IA, les équipes s'appuient sur un socle commun opéré par Microsoft, avec des limites définies par votre organisation.
Architecture : qui gère quoi entre Microsoft et votre organisation
Le modèle de répartition des responsabilités tient en une phrase : Microsoft exploite la plateforme, votre organisation fixe les limites, vous gardez le contrôle. Concrètement, le socle Copilot Managed Runtime combine plusieurs briques :
- Identité via Microsoft Entra pour l'accès autorisé aux applications hébergées.
- Politiques organisationnelles qui gouvernent les connecteurs, les données et les points de terminaison (endpoints) que les applications peuvent atteindre.
- Contrôle de version automatique via Git, ce qui permet un vrai flux de développement collaboratif (co-dev) plutôt qu'un export figé.
- Connecteurs et Work IQ intégrés pour simplifier l'accès et l'autorisation aux données et produits nécessaires.
Cette cohérence s'applique de la même façon aux applications construites dans les expériences Microsoft (Copilot Cowork, Copilot Code, Copilot Studio) et aux outils tiers compatibles avec le SDK, avec un inventaire centralisé dans le centre d'administration Microsoft 365 pour suivre accès, usage, santé et conformité aux politiques.
Le SDK et le CLI : coder ailleurs, exécuter dans le tenant Microsoft 365
Le Copilot Managed Runtime SDK est la couche de connexion entre le code produit et l'hôte du runtime managé. Il permet aux expériences de développement Microsoft comme tierces de construire contre les services Microsoft selon un modèle commun, puis de faire passer une application du poste de développement à un environnement d'exécution géré par l'entreprise.
Le SDK et son interface en ligne de commande (CLI) couvrent l'ensemble du cycle de développement, pas seulement l'empaquetage final :
- Scaffolding et configuration de projets.
- Définition des connexions de données dont l'application a besoin.
- Génération de services typés pour manipuler les connecteurs depuis TypeScript.
- Exécution et prévisualisation de l'application pendant le développement.
- Déploiement et versioning via la même chaîne d'outils.
À l'exécution, les API du SDK offrent un pont sécurisé entre l'application et les services exposés par l'hôte : accès gouverné aux données d'entreprise, identité, et contexte de travail Copilot. Les développeurs continuent de travailler avec du code éditable, versionné sous Git, dans les technologies web qu'ils utilisent déjà — l'application obtient simplement un chemin cohérent vers Microsoft 365 pour son déploiement et son exploitation.
Avec le SDK Copilot Managed Runtime, une application créée avec Lovable peut désormais s'exécuter à l'intérieur de votre tenant Microsoft, exactement comme tout le reste : même connexion, mêmes politiques, même inventaire d'applications. — Lan Roche, Head of Global Partnerships chez Lovable
Ce que gagnent les applications déployées sur le runtime managé
Passer d'une application qui fonctionne à une application prête pour la production demande habituellement un travail de plateforme conséquent. Copilot Managed Runtime intègre cette fondation au modèle de déploiement lui-même, plutôt que d'en faire un chantier séparé de fin de projet. Les applications déployées sur l'hôte bénéficient de :
- Identité et partage via Microsoft Entra.
- Environnements d'exécution hébergés par Microsoft.
- Politiques organisationnelles pour les connecteurs, l'accès aux données, les endpoints approuvés et l'audit.
- Déploiement, versioning et contrôles de cycle de vie.
- Inventaire central, supervision et visibilité d'usage.
Les équipes peuvent prévisualiser et améliorer une nouvelle version pendant que la version en production reste disponible aux utilisateurs — un modèle de déploiement progressif qui limite l'impact d'une régression. L'identité et les politiques sont appliquées au niveau de l'hôte, pas application par application.
Gouvernance centralisée dans le centre d'administration Microsoft 365
À mesure que le nombre de personnes capables de créer des applications augmente, une question pratique se pose pour chaque organisation : que voit-on exactement tourner, qui y accède, quelles données et services sont atteints, et cela respecte-t-il toujours la politique en place ?
Les applications hébergées avec Copilot Managed Runtime apparaissent dans la nouvelle expérience Apps du centre d'administration Microsoft 365, qui offre un inventaire central et un point d'entrée unique pour revoir accès, usage, santé et conformité aux politiques. Ce modèle s'applique de la même façon quel que soit l'outil de création utilisé — l'IT n'a pas besoin d'un playbook de gouvernance différent pour chaque plateforme.
La gouvernance centralisée n'impose pas la création centralisée. Les makers et développeurs continuent de travailler dans l'expérience qui correspond à leur métier ; l'IT obtient une couche d'exploitation commune pour le déploiement, la sécurité, la supervision et le cycle de vie. C'est cette séparation entre « construction ouverte » et « exécution gérée » qui permet de faire évoluer l'innovation applicative sans faire croître le risque opérationnel au même rythme.
Un inventaire centralisé ne remplace pas une revue régulière des politiques par défaut. Avant d'ouvrir largement l'accès à un outil tiers compatible SDK, vérifiez quels connecteurs et endpoints sont autorisés par défaut pour votre tenant.
Scénarios d'usage concrets en entreprise
Le modèle Copilot Managed Runtime couvre un large éventail d'applications métier internes :
- Une équipe crée une application de gestion de lancement produit dans Copilot Cowork, la connecte à des données de planification approuvées, et la déploie via un chemin gouverné.
- Un développeur récupère le code pour continuer à construire dessus avec des technologies web familières, sans forker le projet ni monter un runtime, des ressources de plateforme et une pile de gouvernance séparés.
- Un administrateur consulte l'application dans son inventaire, supervise son usage au même endroit, et applique un ensemble de contrôles cohérent à des applications issues d'outils de création différents.
Dans chaque cas, le modèle d'exploitation d'entreprise reste identique quel que soit l'outil d'auteur utilisé. Les makers et développeurs gagnent en liberté d'itération tout au long du cycle de vie, et l'IT gagne en confiance une fois l'application entre les mains des utilisateurs.
Mise en route en préversion publique et limites à connaître
Les points d'entrée Microsoft sont déjà actifs via Copilot Cowork, Copilot Code et Copilot Studio, et les développeurs peuvent utiliser le SDK et ses plugins pour construire des applications destinées à l'hôte. Côté administration, la marche à suivre reste, pour l'instant, entièrement portail :
Accédez à la nouvelle expérience Apps du Microsoft 365 business admin center pour visualiser l'inventaire des applications hébergées sur Copilot Managed Runtime, quelle que soit leur origine (Cowork, Code, Studio, SDK tiers).
Examinez les politiques organisationnelles appliquées par défaut aux connecteurs, à l'accès aux données et aux endpoints approuvés, avant d'élargir l'accès à de nouveaux créateurs.
Les administrateurs peuvent activer ou désactiver des applications directement depuis l'expérience Apps. Testez d'abord sur un périmètre restreint avant une bascule à l'échelle du tenant.
Utilisez les indicateurs de supervision et d'usage exposés dans l'inventaire pour repérer les applications inactives, à fort usage, ou hors politique, et ajuster la gouvernance en conséquence.
Désactiver une application ou resserrer une politique de connecteur dans l'espace Apps affecte immédiatement tous les utilisateurs qui en dépendent. En préversion, documentez chaque changement de politique et communiquez avant toute modification large.
Côté limites, plusieurs points méritent d'être suivis avant un déploiement à grande échelle :
- Aucune cmdlet PowerShell ni module Microsoft Graph dédié n'est documenté à ce stade pour administrer Copilot Managed Runtime par script ; la gestion passe exclusivement par le portail en préversion.
- Le SDK cible aujourd'hui les technologies web et TypeScript ; Microsoft ne communique pas, dans cette annonce, sur un support élargi à d'autres langages.
- Aucune date de disponibilité générale (GA) ni information de tarification n'est publiée à ce stade — il s'agit d'une préversion publique.
- Le périmètre exact des politiques organisationnelles applicables aux connecteurs et endpoints reste à documenter plus finement à mesure que la préversion avance.
Pour suivre les prochaines étapes de cette annonce, consultez les annonces Copilot sur le blog officiel de Microsoft.
Points clés à retenir
Copilot Managed Runtime ne change rien à la façon dont les équipes créent des applications avec l'IA — il change ce qui se passe après. Pour un administrateur, l'enjeu du lundi matin n'est pas de déployer quoi que ce soit dans l'immédiat, mais de préparer le terrain :
- Identifiez qui, dans votre organisation, utilise déjà Copilot Cowork ou Copilot Code pour produire des applications métier.
- Anticipez l'apparition de la nouvelle expérience Apps dans votre centre d'administration Microsoft 365 et prévoyez qui en aura la charge de gouvernance.
- Si votre organisation évalue des outils tiers de type Lovable pour des makers non techniques, gardez un œil sur la compatibilité SDK Copilot Managed Runtime : c'est la condition pour que ces applications rentrent dans le même modèle de gouvernance que le reste de votre parc Copilot.
La préversion publique laisse encore plusieurs zones grises — absence de scripting natif, périmètre exact des politiques, calendrier de disponibilité générale. Elles se préciseront probablement dans les prochaines communications de Microsoft, à suivre de près si votre tenant héberge déjà des applications Copilot en production.
