Copilot et la transformation du travail par les agents IA

Microsoft fait évoluer Copilot vers une plateforme de travail agentique, transformant la création logicielle, la délégation des tâches, la gouvernance et la maîtrise des coûts.

Microsoft veut faire de Copilot la plateforme centrale du travail

L’annonce du 25 septembre 2026 rapproche dans Copilot la conversation, la création de logiciels et l’activité d’agents persistants. Pour les entreprises, cette ambition déplace le débat : au-delà de l’adoption d’un assistant, il faut organiser la délégation, contrôler les actions et mesurer les résultats.

Pendant les premières années de l’IA générative en entreprise, la question dominante était celle de l’assistance : comment rédiger plus vite, retrouver une information ou préparer une présentation ? Avec la nouvelle évolution de Copilot, Microsoft vise une place plus centrale dans la conduite du travail. Home réunit Chat et Cowork, Code permet de construire des solutions par langage naturel, et Autopilot est présenté comme un agent capable de poursuivre une activité dans la durée.

Mon analyse est que Microsoft cherche à occuper le point où l’intention devient un travail exécuté. Ce positionnement peut modifier la façon dont les collaborateurs accèdent aux applications, mais aussi la manière dont l’entreprise définit les responsabilités, autorise les opérations et contrôle les coûts. La valeur de cette plateforme dépendra autant de ces choix que de la puissance des modèles.

Une plateforme qui orchestre les applications

L’expression "OS du travail" est une métaphore stratégique. Copilot ne devient pas, au sens technique, le système qui gère les ressources d’un ordinateur. L’ambition est de devenir une couche d’interaction et d’orchestration au-dessus des outils professionnels.

Dans un environnement classique, un salarié traduit son objectif en une succession d’opérations : chercher un document, ouvrir un tableur, consulter un outil métier, préparer une synthèse, solliciter un collègue. Une interface agentique peut prendre en charge une partie de cette traduction. Le collaborateur formule un résultat attendu ; le système recherche le contexte et mobilise les capacités disponibles pour avancer.

Cette évolution peut réduire les transferts manuels entre outils. Elle peut aussi rendre moins visible le chemin suivi pour produire une réponse ou réaliser une opération. L’entreprise devra donc pouvoir revenir de l’interface unifiée aux sources, aux permissions et aux systèmes effectivement utilisés. Une expérience simple pour l’utilisateur exige une architecture explicite pour ceux qui l’exploitent.

Trois modes de travail aux disponibilités distinctes

La nouvelle expérience organise plusieurs formes d’interaction. Home sert de point de départ et rapproche l’échange immédiat de la délégation à Cowork. L’intégration de Word, Excel et PowerPoint doit permettre de travailler sur des fichiers éditables et synchronisés avec les applications Office. Code ajoute la création de solutions applicatives. Autopilot introduit une activité persistante. 

Les statuts annoncés le 25 septembre doivent être lus séparément. Home et Code commencent leur déploiement dans Frontier au cours des semaines suivantes. Autopilot doit étendre sa préversion privée à la fin septembre. Copilot Managed Runtime est en préversion publique. La future expérience Today est annoncée pour une préversion privée en octobre. Ces annonces ne constituent pas une disponibilité générale uniforme.

La documentation de Cowork indique, de son côté, une disponibilité générale depuis juin 2026, avec une facturation à l’usage. Il faut donc distinguer l’existence de Cowork du déploiement de la nouvelle interface Home et des autres fonctions annoncées en septembre. 

Pour une DSI, cette distinction commande le rythme d’adoption. Tester une nouvelle interface sur un petit groupe et confier un processus récurrent à un agent sont deux décisions différentes. Elles ne demandent ni les mêmes preuves ni le même dispositif de support.

Le contexte métier devient une composante de la plateforme

Un modèle peut rédiger un texte convaincant sans connaître les règles d’une entreprise. Pour produire un travail utile, il doit aussi comprendre quel document fait autorité, quelle relation relie un contrat à un client et quelle donnée est accessible à la personne qui l’interroge.

Microsoft présente Work IQ comme une couche d’intelligence qui donne aux agents accès aux données, au contexte et aux outils de l’organisation, avec une gouvernance tenant compte des permissions. La documentation décrit des interfaces A2A, MCP et REST, permettant d’intégrer ces capacités dans plusieurs architectures d’agents.

Fabric IQ apporte un contexte sur les entités et les données métier. Il s’appuie notamment sur les modèles sémantiques Power BI et sur des ontologies, encore en préversion, pour représenter des concepts, des propriétés et des relations. Son rôle est de rapprocher les données du vocabulaire utilisé pour conduire l’activité.

L’extension de Work IQ aux applications métier de Dynamics 365 et Power Platform est annoncée en préversion à partir du 30 septembre, avec un déploiement au cours d’octobre. Microsoft y associe modèles sémantiques, compétences métier réutilisables et actions gouvernées.

L’implication architecturale est importante : connecter une source ne suffit pas à rendre son contenu intelligible. Si les équipes utilisent des définitions différentes du chiffre d’affaires ou de la rentabilité, l’agent peut rapprocher des données incompatibles. La DSI et les métiers doivent travailler ensemble sur les définitions, la fraîcheur des données et les responsabilités éditoriales. La préparation à l’IA devient aussi un chantier de connaissance métier.

Code élargit la création logicielle et le besoin de maintenance

Microsoft indique que Code repose sur la même technologie sous-jacente que GitHub Copilot. L’outil doit permettre de décrire une application, un suivi ou une automatisation en langage naturel, dans un environnement isolé et avec un hébergement possible dans le tenant. Les développeurs professionnels conservent GitHub Copilot pour leur activité quotidienne.

L’expression "sans code" peut induire une mauvaise compréhension. L’utilisateur peut créer sans écrire lui-même chaque ligne ; le résultat reste un logiciel. Il possède des dépendances, une logique, des accès et un cycle de vie. Un outil de suivi initialement personnel peut devenir indispensable à plusieurs équipes et porter des décisions importantes.

Prenons un exemple hypothétique : un responsable commercial génère une application de suivi des renouvellements. Tant qu’elle affiche quelques informations en lecture seule, son impact reste limité. Lorsqu’elle classe les clients à risque, suggère des concessions et met à jour le CRM, elle engage des règles commerciales et la qualité des données. Le changement de périmètre doit déclencher une réévaluation.

La démocratisation de la création appelle donc une organisation de la reprise. Qui devient propriétaire de l’application ? Qui corrige une erreur ? Comment transférer le code à une équipe de développement ? Quand retirer une solution devenue obsolète ? Ces questions déterminent si la création rapide produit un patrimoine utile ou une dette dispersée.

Managed Runtime rapproche la création du fonctionnement en production

Copilot Managed Runtime est l’une des annonces les plus structurantes. Microsoft le présente comme un socle d’exécution pour des applications créées dans Cowork, Code et Copilot Studio, également ouvert à des outils tiers et aux développeurs professionnels. La préversion publique réunit hébergement, identité Entra, politiques de connexion, inventaire et gestion du cycle de vie. 

Le SDK et la CLI annoncés doivent permettre de développer, prévisualiser, déployer et versionner les applications. Le code reste éditable et suivi dans Git. Microsoft fournit ainsi un chemin commun entre la génération d’un logiciel et son exploitation dans l’environnement Microsoft 365. 

Ce socle ne garantit pas l’exactitude d’une règle métier. Une application peut utiliser une identité valide et accéder à une source autorisée tout en calculant un indicateur erroné. Il faut conserver une validation proportionnée à l’usage : vérification fonctionnelle, essais avec des données représentatives et contrôle des conséquences d’une erreur.

Pour le Platform Engineering, j’y vois l’opportunité d’élargir les parcours de création gouvernés aux collaborateurs métier. Un parcours en lecture seule pourrait être accessible largement ; un parcours modifiant des systèmes partagés demanderait davantage de contrôle. La plateforme fournit les moyens techniques, tandis que l’organisation fixe les conditions de passage d’un niveau à l’autre.

Autopilot pose la question du mandat délégué

Autopilot, auparavant nommé Scout, est présenté comme un agent personnel, proactif et persistant. Hébergé dans le cloud, il dispose de sa propre identité, d’une mémoire et d’un espace de travail. Microsoft décrit notamment des activités de suivi et de coordination qui peuvent continuer en l’absence de l’utilisateur.

La continuité change la nature du risque. Une réponse inexacte dans un échange ponctuel peut être corrigée immédiatement. Un agent qui poursuit une mission peut réutiliser une hypothèse devenue fausse, solliciter des personnes au mauvais moment ou répéter une opération. Sa fiabilité dépend donc aussi de sa capacité à détecter quand il doit s’arrêter.

Dans un scénario hypothétique de revue fournisseurs, préparer les dossiers, rapprocher les informations et proposer un calendrier sont des activités relativement circonscrites. Modifier une qualification fournisseur ou engager une dépense demande un autre mandat. Le terme "autonomie" doit être traduit en autorisations précises : lire, proposer, créer un brouillon, modifier, transmettre ou approuver.

La documentation de Cowork offre un exemple de distinction utile, sans préjuger de tous les contrôles d’Autopilot : ses tâches automatisées agissent avec les permissions de leur créateur et demandent par défaut une approbation avant certains envois ou changements de systèmes partagés, sauf préautorisation. Des protections contre les boucles et une journalisation sont également décrites.

Pour chaque mission persistante, je recommande un responsable humain, un périmètre, une durée, des critères d’arrêt et un mécanisme de suspension. Le mandat doit pouvoir être relu lorsque le processus, les données ou les interlocuteurs changent.

La gouvernance doit couvrir les agents et leurs actions

Microsoft Agent 365 fournit un registre central et des capacités d’observation, de gouvernance et de sécurité. Sa documentation articule ces fonctions avec Microsoft Entra, Purview et Defender. Le produit est généralement disponible pour le segment commercial depuis le 1er mai 2026, avec des conditions de licence propres.

Un registre est nécessaire pour savoir ce qui existe. Son utilité dépend cependant de la qualité des informations qu’on y maintient. Pour exploiter un agent, l’organisation doit connaître sa finalité, son propriétaire, les systèmes qu’il utilise et les actions qu’il peut réaliser. Il faut aussi prévoir ce qui se passe lorsque son propriétaire quitte l’entreprise ou lorsque la mission n’a plus de raison d’être.

Je recommande de traiter le cycle de vie en continu. La création précise le besoin et le mandat. La mise en service établit les droits et les critères de réussite. L’exploitation suit les résultats, les incidents et les coûts. Le retrait supprime les accès et les automatismes devenus inutiles.

Cette gouvernance doit rester proportionnée. Une procédure lourde pour chaque aide à la rédaction encouragerait les contournements. L’exigence doit augmenter avec la sensibilité des données, la portée des actions et la difficulté de revenir en arrière.

La sécurité évolue de la protection des données vers celle des opérations

Microsoft documente le respect des permissions existantes et une défense en profondeur pour Copilot. L’éditeur souligne aussi qu’un contenu trop largement partagé peut affecter les résultats et augmenter le risque. L’IA n’a pas besoin de contourner une autorisation pour rendre plus visible une information qui était déjà accessible à tort. 

La première mesure consiste donc à corriger les droits sur les données sensibles. Une recherche plus efficace ne doit pas devenir une manière de découvrir à grande échelle des dossiers mal protégés.

Les capacités d’action ajoutent une difficulté. La documentation d’extensibilité de Microsoft décrit le risque qu’un contenu non fiable, par exemple un courriel ou un ticket, influence le comportement d’un agent et l’amène à invoquer une action. Elle recommande le moindre privilège et une intervention humaine adaptée pour les opérations sensibles. 

Dans l’architecture que je recommande, les règles d’autorisation restent appliquées par les services qui exécutent les opérations. Le modèle peut proposer une modification ; l’API vérifie l’identité, les paramètres et les conditions métier. Un contrôle en langage naturel ne remplace pas cette vérification.

Il faut également prévoir les échecs partiels. Si un agent crée un dossier puis échoue à mettre à jour son statut, une nouvelle tentative ne doit pas créer un doublon. Les équipes devront concevoir des opérations pouvant être rejouées sans effet supplémentaire, des limites de tentative et des procédures de récupération. La qualité agentique inclut cette ingénierie transactionnelle.

Une interface commune aux frontières de traitement distinctes

La présence d’une expérience dans Copilot ne suffit pas à décrire tout le parcours des données. Les modèles, les extensions et les services externes peuvent relever de conditions distinctes.

Microsoft indique que les prompts, les réponses et les données accessibles via Microsoft Graph ne servent pas à entraîner les modèles fondamentaux de Copilot. La documentation invite cependant à examiner les conditions des agents et des fournisseurs tiers.

Pour les organisations européennes, une précision mérite une attention particulière. Au 30 septembre 2026, Microsoft indique que les modèles opérés par Anthropic dans ses offres sont exclus de l’EU Data Boundary et de certains engagements de traitement national lorsqu’ils s’appliquent. Ils sont désactivés par défaut dans l’UE, l’AELE et au Royaume-Uni. Certaines offres avec conservation de données relèvent en outre de conditions spécifiques.

Cela impose de vérifier les garanties au niveau de chaque capacité et de chaque fournisseur. L’hébergement d’une application dans le tenant, la résidence de ses données, la localisation du traitement par le modèle et les conditions d’une extension sont des questions différentes.

La souveraineté doit aussi être examinée sous l’angle opérationnel : l’entreprise peut-elle exporter son code, remplacer une connexion, reprendre ses règles métier et poursuivre un processus si une capacité devient indisponible ? Une décision de plateforme gagne à intégrer ces scénarios dès sa conception.

La consommation rend le coût du travail agentique visible

L’annonce distingue l’abonnement pour les usages courants et la consommation pour Cowork, Code, Autopilot et certaines capacités avancées. L’unification de l’application ne signifie donc pas un coût uniforme.

La documentation d’administration décrit des Copilot Credits, plusieurs modes de financement et des politiques de dépense. Les administrateurs peuvent définir des limites, configurer des alertes et suivre la consommation par utilisateur, groupe, agent ou service. Dans Cowork, une politique de dépense sert aussi à accorder l’accès : fixer une limite très faible ne revient pas à bloquer la capacité.

L’analyse économique devrait aller au-delà du volume de requêtes. Une mission comprend potentiellement des appels de modèles, des recherches, des outils, des tentatives supplémentaires et du temps de vérification humaine. Je recommande de mesurer le coût par résultat accepté, en intégrant l’exploitation et les corrections.

Par exemple, pour une préparation de dossier commercial, l’entreprise peut suivre le délai de remise, le nombre de retours du relecteur, la qualité des données reprises et le coût complet. Une production abondante de brouillons n’a pas la même valeur qu’une amélioration du délai de décision.

Le FinOps de l’IA devient ainsi un travail commun entre finance, métiers et équipes techniques. Les décisions d’optimisation doivent préserver le niveau de qualité attendu, et les missions récurrentes doivent disposer d’un budget explicite.

Les usages observés invitent à mesurer les gains processus par processus

Une prépublication de chercheurs de Microsoft, publiée en mai 2026, analyse un ensemble d’environ 5,5 millions de sessions de Copilot Chat. Elle observe une forte place de la rédaction, ainsi que des usages de recherche, d’analyse et d’aide à la décision. Elle relève une évolution relative vers les activités de contenu et de communication.

Cette étude décrit l’usage de Chat ; elle ne mesure pas l’efficacité d’Autopilot. Elle exclut notamment les données soumises à l’isolation de l’EU Data Boundary et certains usages intégrés aux applications. Son périmètre limite les extrapolations aux nouvelles fonctions et au contexte européen. 

Une autre prépublication, fondée sur des enquêtes répétées dans un organisme de recherche, rapporte des perceptions différentes selon les populations et une valeur particulièrement visible pour les tâches textuelles structurées. Elle souligne l’importance de l’apprentissage et d’une mise en œuvre adaptée au métier. Ces perceptions ne constituent pas une mesure universelle de productivité.

Pour évaluer une adoption agentique, je recommande de partir d’un processus identifiable. On mesure son délai, ses erreurs et sa charge de vérification avant le pilote, puis on suit les mêmes dimensions. La comparaison doit aussi tenir compte d’un éventuel déplacement du travail : le temps gagné par le rédacteur peut être absorbé par le validateur.

La compétence de délégation mérite une formation propre. Elle consiste à exprimer un résultat, définir les preuves attendues, préciser les limites et reconnaître une situation qui demande une expertise humaine. Les managers devront également vérifier que l’activité produite par les agents réduit les sollicitations inutiles au lieu de multiplier messages et demandes de validation.

Une interface intégrée peut créer une dépendance plus profonde

L’intégration apporte un bénéfice potentiel : moins de raccordements à construire et un environnement d’administration plus cohérent. Elle peut aussi déplacer la dépendance vers les instructions, les compétences, les modèles sémantiques et les workflows qui structurent le travail.

Les interfaces standard de Work IQ et le code suivi dans Git du Managed Runtime constituent des ouvertures techniques documentées. Elles ne garantissent pas, à elles seules, la portabilité d’un processus complet.

Mon analyse est que la réversibilité doit devenir un critère concret de choix. Les règles métier essentielles devraient pouvoir être décrites indépendamment d’un prompt. Les API devraient conserver des contrats clairs. Les jeux d’évaluation devraient rester utilisables si l’entreprise change de modèle ou de plateforme. Pour les processus importants, un exercice de reprise permettrait de vérifier ces hypothèses.

Cela évite de réduire la décision à une alternative entre tout intégrer et tout reconstruire. Chaque organisation peut choisir les fonctions pour lesquelles l’intégration apporte une valeur démontrable, tout en conservant des moyens de reprise sur les activités stratégiques.

La DSI devient responsable des conditions de délégation

Je propose une adoption en trois étapes. D’abord, choisir des tâches circonscrites de recherche et de préparation, avec des données identifiées et une revue humaine. Ensuite, autoriser des créations ou modifications limitées, après avoir vérifié les droits, les journaux et la récupération des erreurs. Enfin, expérimenter les missions persistantes sur des périmètres dont les résultats, les coûts et les critères d’arrêt sont connus.

Cette progression doit suivre les preuves recueillies. Une fonction séduisante en démonstration peut rester trop variable pour un processus donné. À l’inverse, une automatisation modeste mais fiable peut améliorer durablement le service rendu.

La DSI a un rôle central dans ces décisions. Elle construit les accès et les parcours de création, aide les métiers à formaliser leurs règles, organise l’exploitation et rend les coûts intelligibles. Les responsables métier conservent la définition du résultat attendu et l’acceptation des conséquences. La délégation à un agent doit clarifier ces responsabilités.

Microsoft propose avec Copilot une plateforme pour rapprocher intention, contexte et exécution. Son adoption réussie dépendra de la capacité de l’entreprise à rendre ce rapprochement fiable. La question décisive sera la suivante : quel travail peut être délégué, avec quelles preuves de qualité, sous quelle autorité et pour quel coût ?