Microsoft Copilot CLI : déployer une app avec Managed Runtime

Copilot Managed Runtime, concrètement

Copilot Managed Runtime est un environnement géré pour les applications métier internes. Le code reste modifiable, le contrôle de version s’appuie toujours sur un vrai dépôt Git, et Microsoft fournit le runtime hébergé, la connexion Microsoft Entra, des connexions aux données sous gouvernance, les mécanismes de prévisualisation et de déploiement, ainsi qu’un inventaire pour les administrateurs.

Imaginez un immeuble de bureaux avec services pour votre code. Vous décidez toujours de ce qui se passe dans chaque pièce ; l’immeuble fournit l’accueil avec badges, les réseaux, les règles de sécurité, le registre de maintenance et l’équipe technique. Nous sommes donc loin d’une simple interface de programmation assistée par IA qui se contenterait de dessiner le plan des pièces.

Microsoft présente le SDK comme la couche de développement destinée aux applications métier internes. Il intègre l’authentification Entra sans code d’identité personnalisé et donne accès à plus de 1,500 connecteurs depuis JavaScript et TypeScript. Toutefois, la politique du tenant décide quels connecteurs et quelles actions votre app peut réellement utiliser. La présentation du SDK en préversion publique et l’annonce de lancement en fixent utilement le périmètre.

Ce guide suit le SDK et le CLI disponibles aujourd’hui. Il ne présente pas Copilot Code ou Autopilot comme des noms interchangeables pour cette chaîne d’outils.

Où l’application est-elle réellement hébergée ?

La réponse évolue au fil de son cycle de vie :

Cette séparation est essentielle. La prévisualisation peut avancer tandis que la production reste stable, et l’échec d’un build de prévisualisation ne remplace pas la dernière version réussie.

Vérifier les prérequis avant de toucher au code

Le meilleur moyen de perdre une journée est de découvrir une restriction de tenant ou de licence une fois l’app terminée. Commencez par ces cinq contrôles.

Les options de facturation et les politiques d’administration méritent une décision budgétaire à part entière. Consultez l’analyse tarifaire de Copilot Managed Runtime avant d’ouvrir l’accès à un groupe pilote. Un détail opérationnel a toute sa place ici : l’exécution locale n’est pas une échappatoire gratuite. Elle requiert la même couverture du runtime que pour un utilisateur final.

Ce qui a réellement été vérifié pour ce guide

Le package a bien été testé. Pas l’exécution dans un tenant.

Cet article ne prétend donc avoir mesuré ni le délai d’affichage de la première page locale, ni celui de la prévisualisation hébergée. Il ne rapporte pas non plus d’échec de build observé, d’identité Entra inspectée, d’appel de connecteur exécuté, de déploiement réalisé ou de facture de runtime reçue. Les étapes ci-dessous décrivent le parcours documenté par Microsoft, pas un essai en laboratoire déguisé.

Déployer une petite app métier avec Microsoft Copilot CLI

Prenons une application fictive appelée Ops Intake. Sa première mission reste volontairement simple : afficher, dans une file en lecture seule, les enregistrements provenant d’une source approuvée par le tenant. Commencer par une opération de lecture rend le premier examen des politiques beaucoup plus lisible. N’ajoutez des écritures qu’après avoir validé l’identité, les autorisations de la source, la politique des connecteurs et la couverture du runtime.

Pour que la procédure soit reproductible, cette séquence épingle la version du CLI vérifiée le 27 septembre 2026. Consignez dans le dépôt la version que vous avez retenue afin qu’une mise à jour du package en préversion ne modifie pas silencieusement le pilote.

npm install -g @microsoft/managed-apps-cli@0.25.1
ms --version

ms auth login
ms app create ops-intake --display-name "Ops Intake"
cd ops-intake

npm install
ms app dev

ms connector list --search SharePoint
ms connector list-actions --connector <allowed-connector-id> --search list
ms app add data-source --connector <allowed-connector-id>

git add .
git commit -m "first ops intake flow"
git push

ms app play --mode preview
ms app build-status
ms app deploy

Voici ce que signifie chaque transition.

1. Se connecter et créer le socle gouverné

ms auth login ouvre l’authentification Microsoft Entra. Sur une machine sans interface graphique, le CLI propose également --device-code. ms app create crée la fiche de l’app, génère la structure du projet et utilise par défaut un dépôt Git géré par la plateforme. La première création ou initialisation provisionne aussi l’environnement de développement personnel associé à l’identité du créateur, à condition que le routage l’autorise.

Ne choisissez pas le mode de dépôt à la légère. Le dépôt Git géré par la plateforme est le chemin le plus direct pour démarrer. Un dépôt externe peut être hébergé sur GitHub.com ou GitHub Enterprise Cloud. GitHub Enterprise Server, Azure DevOps et les autres fournisseurs ne sont pas pris en charge dans ce parcours. Comme le mode de dépôt est figé pour toute la durée de vie de l’app, en changer impose d’en créer une autre.

2. Lancer l’app en local et chronométrer le premier résultat utile

Installez une fois les dépendances générées avec le projet, puis exécutez ms app dev. La commande lit ms.config.json, lance le processus de développement du projet et affiche une URL Local Play. Ouvrez-la dans le même profil de navigateur que celui utilisé pour le tenant.

Démarrez un chronomètre juste avant ms app dev, puis arrêtez-le dès que la première page utilisable s’affiche. Notez séparément les demandes d’autorisation du navigateur. Chrome et Microsoft Edge peuvent empêcher une origine publique d’accéder à localhost tant que l’accès au réseau local n’a pas été accordé : il s’agit alors d’un verrou du navigateur, pas d’un échec de build de l’application.

3. Valider une lecture sous gouvernance

ms connector list affiche les identifiants des connecteurs, leur type d’authentification, leur compatibilité avec les données tabulaires, ainsi que leur statut au regard de la prévention contre la perte de données et de l’Advanced Connector Policy. Pour cet environnement, considérez cette sortie comme la source de référence. La présence d’un connecteur dans le catalogue Microsoft ne signifie pas qu’il est automatiquement autorisé dans votre tenant.

Pour Ops Intake, sélectionnez une connexion SharePoint autorisée, un jeu de données et une liste, puis choisissez une opération de lecture ou de listage. Le workflow interactif ms app add data-source génère des modèles et des services TypeScript typés dans generated/. Appelez la méthode de lecture générée depuis l’app au lieu d’improviser un flux de jetons Graph brut.

Vérifiez trois points dans le navigateur :

1. L’utilisateur connecté correspond bien à l’identité Entra attendue.
2. Cet utilisateur ne voit que les enregistrements déjà autorisés par le système source.
3. L’app échoue proprement si ce même utilisateur perd son accès à la source.

Partager l’app par la suite ne donne pas accès aux données sous-jacentes. Chaque destinataire doit toujours disposer des bonnes autorisations et de la bonne connexion à la source. C’est une garantie de sécurité, pas une complication du déploiement.

4. Commiter et pousser le véritable code source

Utilisez les commandes Git habituelles. Le CLI du runtime ne remplace pas la gestion de versions. Votre commit doit inclure la modification fonctionnelle de l’application ainsi que les liaisons de connecteurs générées qui ont leur place dans le projet.

Le piège tient en une phrase : git push ne compile pas l’app. Il ne fait que mettre à jour le code source de référence sur le dépôt distant.

5. Ouvrir la prévisualisation hébergée et contrôler le build

ms app play --mode preview ouvre le point de terminaison stable de prévisualisation. Si le dernier commit poussé n’a pas encore de build, l’ouverture de cette prévisualisation en déclenche la mise en file d’attente. Mesurez le délai entre son ouverture et la disponibilité de la nouvelle version.

En cas d’échec, lancez ms app build-status, éventuellement avec --commit <sha>, puis enregistrez le motif complet à côté du commit. Tant qu’une version plus récente est en cours de compilation ou a échoué, la prévisualisation continue de servir le build réussi précédent. Son URL est réservée aux développeurs disposant d’un accès en écriture au dépôt, pas à n’importe quel relecteur.

Vous pouvez exécuter ms app build pour lancer un build avant d’ouvrir la prévisualisation. La plupart des équipes gagneront toutefois à maîtriser d’abord le comportement par défaut : pousser le code, puis ouvrir la prévisualisation.

6. Ne déployer que la version que vous avez contrôlée

ms app deploy promeut un build réussi vers l’app en production. La version de production est un instantané fixe : elle ne suit pas chaque push ou build de prévisualisation.

Pour une mise en production maîtrisée, consignez le SHA du commit, vérifiez l’état de son build, ouvrez sa prévisualisation, puis déployez précisément ce SHA avec ms app deploy --commit <sha>. Cette même option permet de revenir proprement à un ancien build réussi, sans réécrire l’historique Git.

L’équation économique se joue au niveau de la plateforme

Le runtime ne rend pas le développement applicatif gratuit. Il change les briques que votre équipe doit acheter ou construire elle-même.

Le budget logiciel comparable n’est pas anodin. La page tarifaire officielle de Retool affiche l’offre Team à $10 par développeur et $5 par utilisateur interne et par mois, tandis que l’offre Business coûte $50 par développeur et $15 par utilisateur interne et par mois. Copilot Managed Runtime n’est pas automatiquement moins cher. Dans une organisation Microsoft 365, il peut supprimer une partie du travail de plateforme distinct, mais les licences ou crédits d’exécution, le travail sur les connecteurs et le temps d’administration restent des coûts bien réels.

Avant de conclure que ce parcours revient moins cher, appliquez cette équation au pilote :

Coût du pilote = temps de développement + configuration administrative + couverture du runtime + travail sur les connecteurs et les données.

Le poste qui a le plus de chances de diminuer est l’assemblage de la plateforme. Celui qui risque le plus de vous surprendre est la couverture du runtime pour chaque personne qui ouvre l’app.

Sept applications internes adaptées à ce runtime

Les meilleurs candidats sont les workflows internes pour lesquels l’identité, les données Microsoft 365 sous gouvernance et une mise en production contrôlée comptent davantage qu’une vitrine publique.

Chaque cas d’usage doit commencer en lecture seule. L’ajout d’une écriture, d’un point de terminaison externe, d’un connecteur tiers ou d’un partage étendu modifie les exigences de contrôle. La politique par défaut inclut 18 connecteurs fournis directement par Microsoft, pas l’intégralité du catalogue. Elle bloque également certaines actions ouvertes de type HTTP, code arbitraire, requête arbitraire ou plateforme arbitraire, y compris dans des connecteurs approuvés.

Trois produits à construire autour de Copilot Managed Runtime

Le produit le plus solide est un centre de commandement pour l’onboarding Microsoft 365. Il associe la demande mesurée la plus forte à un workflow qui couvre naturellement l’identité, les documents, les tâches, la messagerie et les relais entre équipes.

1. Un centre de commandement pour l’onboarding Microsoft 365

Construisez une app interne unique dans laquelle les RH et l’IT peuvent consulter le dossier approuvé d’une nouvelle recrue, les tâches en attente, les liens vers les documents et les responsables. Les équipes RH et support IT seraient prêtes à payer pour éviter les relais manqués et simplifier la piste d’audit.

La demande est bien visible : « employee onboarding software » génère environ 590 recherches mensuelles aux États-Unis, avec une intention commerciale et un coût par clic de $156.35. La requête plus précise « best employee onboarding software » génère 90 recherches mensuelles et affichait une progression annuelle de 180% dans les données de suggestions.

La plus petite version commercialisable dessert un seul service, lit une seule liste approuvée de salariés, affiche une checklist de tâches et relie chacune d’elles à son responsable. N’ajoutez des actions de connecteurs qu’après avoir validé le parcours de lecture au regard des politiques et des autorisations.

La difficulté est réelle. Les données RH sont sensibles, les autorisations de la source sont faciles à mal interpréter et les éditeurs spécialisés couvrent déjà des workflows RH plus larges. Le produit ne peut l’emporter que si la gouvernance Microsoft 365 et l’exploitation native dans le tenant comptent davantage qu’une longue liste de fonctionnalités génériques.

2. Un cockpit d’approbation sous gouvernance

Créez une interface d’approbation réutilisable pour les équipes finance, achats ou opérations qui disposent d’un état de décision clair, mais d’un contexte dispersé. L’acheteur paie pour accélérer l’examen et maîtriser la mise en production, pas pour obtenir un énième générateur de formulaires.

« Approval workflow software » génère environ 320 recherches mensuelles aux États-Unis, avec une intention commerciale, un coût par clic de $114.86 et une progression annuelle de 53% dans les données de suggestions. Cette combinaison révèle un besoin d’achat actif et laisse de la place à une implémentation Microsoft 365 ciblée.

Le MVP porte sur un seul type de demande et une seule source approuvée. Il comprend un écran d’examen en lecture seule, un historique des décisions et une unique action autorisée par les politiques. Gardez un modèle de décision déterministe : ne dissimulez pas les règles d’approbation dans du texte généré.

Le principal écueil est la politique des connecteurs. Un connecteur peut être autorisé alors qu’une action précise reste bloquée. Les politiques de données classiques peuvent en outre se combiner aux Advanced Connector Policies, et c’est le résultat le plus restrictif qui s’applique.

3. Un audit de migration vers une application gérée

Commercialisez un audit standardisé qui prend une application web interne, générée par IA ou développée sur mesure, et détermine si elle peut migrer vers Copilot Managed Runtime. Le client type est une organisation Microsoft 365 qui possède un prototype utile, sans vouloir gérer une nouvelle pile indépendante d’hébergement et de gouvernance.

« Custom business app development » génère environ 90 recherches mensuelles aux États-Unis, avec une intention commerciale et un coût par clic de $84.03. Le volume est plus faible, mais la requête est proche d’un achat de services.

Le MVP inventorie le dépôt de l’app, ses hypothèses d’exécution, ses points de terminaison externes, son code d’identité, ses sources de données et les actions nécessaires. Il rend ensuite une décision — feu vert, modifications ou arrêt — puis porte une tranche en lecture seule dans un environnement de test.

Le risque tient à la concentration sur une seule plateforme. Le résultat n’est utile qu’aux tenants Microsoft 365 éligibles, le fonctionnement de la préversion publique peut évoluer et un fournisseur de code source non pris en charge ou des ressources externes bloquées peuvent transformer une migration apparemment simple en reconstruction.

Ce que Copilot Managed Runtime ne résout pas

Il s’agit d’une piste prometteuse pour les applications internes sous gouvernance, pas d’une plateforme universelle.

• La fonctionnalité est en préversion publique et sa documentation concerne une version préliminaire. Considérez que les commandes et les surfaces de politique peuvent changer.
• L’accès au runtime n’active pas automatiquement la création via le CLI. Ce parcours reste désactivé par défaut, même lorsque le tenant est éligible.
• Les plus de 1,500 connecteurs ne deviennent pas tous des sources de données autorisées. La politique du tenant, celle des actions de connecteurs, les politiques de données classiques et les autorisations de la source continuent de trancher.
• Ce runtime ne transforme pas une application métier interne en produit public destiné aux clients. La prévisualisation est limitée aux développeurs ayant un accès en écriture au dépôt ; l’accès à la production, lui, se partage délibérément dans le cadre gouverné.
• Tous les fournisseurs de dépôts ne sont pas pris en charge. Le code source externe se limite à GitHub.com et GitHub Enterprise Cloud, et le mode de dépôt ne peut pas être modifié sur place.
• Les licences d’exécution restent nécessaires. L’exécution locale et celle des utilisateurs exigent Power Apps Premium ou des Managed Application Copilot Credits financés.
• Les administrateurs n’obtiennent pas un journal d’audit exhaustif. La vue d’administration couvre l’inventaire, l’usage, l’état de santé, les connecteurs, les sources de données et les dépendances. Microsoft précise toutefois qu’elle ne restitue pas intégralement les destinations exactes, les points de terminaison dynamiques, les actions exécutées ni les autorisations effectives de chaque utilisateur sur les sources.
• Cet article ne prouve pas le déploiement réalisé par cette rédaction. L’absence de Git Credential Manager, celle d’une bibliothèque Linux de stockage des secrets et l’indisponibilité d’un tenant éligible ont interrompu l’essai avant la connexion.

La décision raisonnable reste donc ciblée : choisissez ce runtime si l’app est interne, si votre organisation travaille déjà dans Microsoft 365 et si le temps économisé sur l’identité et la gouvernance justifie une plateforme en préversion et ses contrôles de tenant. Préférez un autre hébergeur si vous avez besoin d’un SaaS public, d’un autre fournisseur de code source, de maîtriser l’infrastructure ou d’adopter un modèle de mise en production que vos administrateurs ne peuvent pas autoriser.

Questions fréquentes

L’action à mener lundi

Demandez à un administrateur Power Platform d’activer la création via le CLI pour un groupe de test, confirmez la règle de routage d’environnement de ce groupe et couvrez deux utilisateurs de test pour l’exécution. Choisissez une liste SharePoint non sensible et une seule opération en lecture seule. Demandez ensuite à un développeur d’inscrire quatre éléments dans le journal du pilote : la version du CLI, le délai jusqu’à la première page locale, le délai jusqu’à la prévisualisation hébergée et le SHA du commit déployé. Arrêtez le pilote si l’identité Entra, les autorisations de la source ou la politique des connecteurs se comportent autrement que prévu par écrit.

Si vous souhaitez concevoir et réaliser ce parcours d’application gouvernée pour votre entreprise, commencez par un audit des systèmes de production IA.