Calipia : le blog

Microsoft n’a jamais caché son ambition de faire de Copilot bien plus qu’un assistant de rédaction d’e-mails ou de résumé de réunions. Avec l’arrivée, d’une nouvelle compétence de création d’applications dans Copilot Cowork, la firme de Redmond franchit une étape supplémentaire : elle propose désormais à n’importe quel collaborateur, sans compétence de développement, de concevoir, tester et publier une application métier en langage naturel. L’annonce, formalisée dans le message du centre d’administration MC1469329, s’accompagne d’une extension équivalente dans Copilot Studio, attendue dans les prochaines semaines.

Une compétence /app pensée pour la conversation

Concrètement, l’utilisateur décrit ce dont il a besoin (un tableau de suivi, un formulaire de demande interne, un petit outil de visualisation) et Copilot Cowork produit une première version fonctionnelle. Celle-ci peut ensuite être affinée par itérations successives dans la conversation, prévisualisée, testée, puis publiée et partagée avec des collègues. Microsoft insiste sur le caractère « full stack » de ces applications, construites sur des standards ouverts, avec gestion de version via Git, étapes de déploiement distinctes et isolation des versions, de quoi permettre à une équipe de continuer à faire évoluer une application sans perturber la version en production. Une fois publiées, ces applications sont également accessibles et modifiables dans Copilot Studio, qui reste l’outil de référence pour construire des expériences plus complexes associant applications, agents et flux de travail.

Fait notable pour les architectes : ces applications peuvent puiser dans les données de l’organisation, mais uniquement via les connecteurs autorisés par la politique IT du tenant. Sur le papier, la promesse est donc celle d’un no-code encadré, et non d’un outil de création sauvage déconnecté du système d’information.

Le volet gouvernance est l’argument central de Microsoft

Consciente que la création d’applications par des utilisateurs non techniques a toujours fait grincer des dents les RSSI, Microsoft met en avant plusieurs garde-fous. Par défaut, l’identité s’appuie sur Microsoft Entra et les politiques de connecteurs existantes s’appliquent automatiquement. Les créateurs sont, sauf configuration contraire de l’organisation, routés vers un environnement de développement personnel isolé plutôt que vers l’environnement partagé, avec des paramètres de sécurité par défaut que les administrateurs peuvent ensuite ajuster. Surtout, toute application publiée devient visible dans le centre d’administration Microsoft 365, sous une nouvelle rubrique Apps qui offre un inventaire complet et des leviers de gouvernance sur l’ensemble du cycle de vie. Les applications approuvées sont par ailleurs découvrables par les utilisateurs sur un portail dédié, managedapps.cloud.microsoft.com.

L’intention est claire : laisser les « power users » construire, tout en donnant aux équipes IT une visibilité centralisée. Reste que cette visibilité s’exerce essentiellement a posteriori, une fois l’application créée et éventuellement déjà utilisée, ce qui déplace le travail de gouvernance vers de la supervision continue plutôt que de la validation en amont.

Le retour d’un vieux débat, sous un nouvel habillage

Les DSI qui ont vécu la vague Access puis Power Platform reconnaîtront le scénario. Microsoft avait déjà tenté, avec Power Apps et Power Automate, de démocratiser le développement métier auprès des utilisateurs non spécialistes. Le bilan a été très contrasté : de nombreuses organisations se sont retrouvées avec des centaines, voire des milliers, d’applications et de flux orphelins, mal documentés et difficiles à auditer. En abaissant encore la barrière technique grâce au langage naturel, Copilot Cowork risque moins de résoudre ce problème que de l’amplifier. Si créer une application devient aussi simple que de décrire un besoin dans un chat, le volume de créations à surveiller, sécuriser et, le cas échéant, retirer, va mécaniquement augmenter.

Ce que l’on doit garder à l’œil

Trois points méritent une attention particulière. D’abord, la dépendance en matière de licences : cette fonctionnalité est réservée aux organisations inscrites au programme Frontier et suppose une licence Microsoft 365 Copilot éligible ainsi qu’un accès à Cowork, autant de prérequis qui renforcent la logique d’abonnement déjà dense de la gamme Copilot. Ensuite, l’alignement entre connecteurs autorisés et politiques de protection des données : le fait qu’une application respecte les politiques existantes ne dispense pas de vérifier que ces politiques couvrent correctement les nouveaux usages, en particulier sous l’angle RGPD et NIS2, dès lors que des données personnelles ou sensibles transitent par des applications construites par des utilisateurs métier. Enfin, le contexte concurrentiel : Microsoft ne fait pas cavalier seul sur ce créneau de la création d’applications par IA conversationnelle, qui voit déjà s’affronter des acteurs comme Replit, Lovable, Bolt ou Vercel v0. Son avantage tient moins à la technologie elle-même (Copilot Cowork s’appuie d’ailleurs sur plusieurs moteurs, dont des modèles OpenAI hébergés sur Azure et des modèles Anthropic utilisés en sous-traitance, une architecture multi-modèle qui ne manquera pas d’amuser les lecteurs attentifs à l’écosystème IA) qu’à son intégration directe dans un tenant Microsoft 365 déjà équipé en identité, en conformité et en outils d’administration.

Pour l’instant, cette compétence reste une préversion réservée à un cercle restreint de clients Frontier. Mais l’orientation stratégique est limpide : Microsoft veut que la création d’applications d’entreprise devienne un geste aussi banal que la rédaction d’un e-mail avec Copilot. Les DSI ont donc intérêt à ne pas attendre la disponibilité générale pour poser, dès maintenant, les règles du jeu (environnements par défaut, connecteurs autorisés, cycle de vie des applications, critères de retrait) plutôt que de les découvrir une fois que les collaborateurs auront pris l’habitude de construire eux-mêmes leurs outils.