Microsoft veut faire de Copilot un point d’entrée commun pour chercher une information, produire un document, construire une application et déléguer du travail. Pour l’entreprise, le changement dépasse l’ajout d’un assistant dans Office : il rapproche des activités qui avaient jusqu’ici des outils, des budgets et des responsables différents. Le premier chantier consiste donc à décider ce que l’on délègue, avec quelles données et sous quel contrôle.
L’annonce du 25 septembre 2026 distingue Home, qui réunit Chat et Cowork avec Office intégré ; Code, pour créer des solutions ; et Autopilot, agent persistant et proactif. Today prépare une expérience de priorisation, tandis que l’invocation dans Teams vise le travail collectif. Cette ambition de « système d’exploitation du travail » reste un positionnement produit : elle ne démontre ni une disponibilité uniforme, ni une autonomie sans risque.
Qu’est-ce qui est disponible, et à quel moment ?
Le calendrier annoncé est progressif : Home et Code arrivent via Frontier dans les prochaines semaines ; Autopilot et l’invocation dans Teams passent par une préversion privée à la fin du mois ; Today entre en préversion privée en octobre. Il faut vérifier l’éligibilité de son tenant, l’activation administrative et les conditions de licence avant de promettre un usage aux équipes.
Le Copilot Managed Runtime fait l’objet d’une annonce séparée, en préversion publique. Microsoft le présente comme une infrastructure d’hébergement et d’exécution administrée, avec identité Entra, politiques d’accès aux données et gestion du cycle de vie. L’éditeur opère la plateforme ; l’organisation garde la responsabilité de définir ses règles d’usage et de vérifier les applications qu’elle autorise.
Notre lecture distingue trois niveaux : une annonce de capacité, sa présence effective dans l’environnement de l’entreprise et sa validation pour une tâche. Le premier ne prouve pas les deux autres. Un pilote doit enregistrer la version, les options activées, les utilisateurs autorisés et les limites connues au moment du test.
Pourquoi réunir conversation, documents et applications ?
Le parcours de travail est souvent fragmenté. Une personne lit des échanges, prépare un document, consolide un tableau puis diffuse une synthèse. La continuité proposée par Copilot peut réduire les transferts entre outils. Elle peut aussi propager plus vite une erreur si chaque étape reprend la précédente sans contrôle.
Prenons un exemple fictif : une équipe prépare une revue fournisseur. Elle doit rapprocher des contrats, des incidents et des échanges récents. Une synthèse correcte doit conserver les réserves, distinguer les informations manquantes et citer les documents pertinents. Un dossier bien présenté mais fondé sur un contrat périmé reste inutilisable.
Le bon indicateur n’est donc pas le nombre d’écrans évités. Mesurez le temps jusqu’au dossier validé, les corrections nécessaires et les décisions que le résultat permet réellement de prendre. Le cadre Copilot en entreprise doit relier l’expérience utilisateur aux sources, aux permissions et aux actions possibles.
Un même dossier, plusieurs modes de travail
Pour cette revue fournisseur fictive, une question ponctuelle relève de la conversation : retrouver une échéance ou expliquer un écart. Préparer un dossier complet constitue une délégation : réunir les pièces, comparer les informations et remettre un résultat à relire. La différence porte sur l’unité de travail confiée, pas seulement sur la longueur du prompt.
Office conserve un rôle précis dans ce parcours : le livrable doit rester un document, un classeur ou une présentation que l’équipe peut reprendre. Si le besoin devient récurrent, une petite application de suivi peut être plus adaptée qu’une succession de fichiers. Il faut alors décider quelles données elle conserve et qui la maintient.
La persistance ajoute encore un autre besoin : suivre le dossier entre deux réunions, détecter qu’une pièce manque et préparer la prochaine étape. Enfin, la priorisation aide la personne à choisir ce qui mérite son attention. Prioriser, préparer et exécuter ne sont pas des permissions équivalentes. Cette distinction permet de discuter concrètement des places de Today et d’Autopilot sans confondre suggestion utile et action déjà autorisée.
Ce parcours est une proposition d’usage à tester, pas une démonstration réalisée sur les nouvelles préversions. Il montre pourquoi la convergence peut compter : une même activité traverse plusieurs formats, mais doit conserver un propriétaire et une règle d’acceptation à chaque étape.
Que faut-il contrôler lorsque le fichier devient une application ?
Une application interne ne se traite pas comme un document terminé. Elle peut conserver des données, recevoir de nouvelles entrées et être partagée avec plusieurs profils. Même créée rapidement, elle a besoin d’un propriétaire, d’une procédure de mise à jour et d’une personne capable de comprendre une panne.
Le Managed Runtime apporte un cadre commun à cette exploitation. Sa documentation présente notamment le SDK, le déploiement, le versionnement et les politiques portant sur les connecteurs et les destinations autorisées. Cela évite de reconstruire toute l’infrastructure pour chaque petite solution. Cela ne prouve pas que le code produit respecte la règle métier ou que son partage est pertinent.
Pour un premier essai, choisissez une application peu engageante et des données synthétiques. Faites tester deux profils dont les droits diffèrent. Vérifiez la lecture, la modification et l’export. Identifiez aussi ce qui se passe lorsque le propriétaire quitte l’équipe : l’application ne doit pas devenir un service essentiel sans responsable.
Une démonstration qui fonctionne avec le compte du créateur n’est pas une recette de production. L’expérience d’un utilisateur ordinaire, la disponibilité des sources et la restauration après une mauvaise modification doivent faire partie du dossier. Les équipes techniques restent utiles précisément sur ces frontières, même lorsque la création devient accessible à davantage de métiers.
Pourquoi les droits deviennent-ils le premier prérequis ?
Un assistant peut rendre visibles des informations déjà trop largement partagées. Une expérience plus simple ne corrige pas cette situation. Avant d’élargir l’accès, examinez les bibliothèques, les groupes, les liens de partage et les informations qui ne devraient pas être découvertes par certains profils.
L’audit des droits SharePoint pour Copilot doit rester distinct du test de qualité rédactionnelle. Un texte peut être exact et pourtant révéler une information au mauvais destinataire. Cette violation ne doit pas être noyée dans un score moyen de satisfaction.
Ajoutez un retrait d’accès au pilote. Une personne autorisée hier peut ne plus l’être aujourd’hui. Vérifiez ce qui arrive aux nouvelles recherches, aux résultats déjà produits et aux applications partagées. Documentez les limites observables ; ne présentez pas un test réussi sur une interface comme la preuve de suppression de toutes les copies existantes.
Grille de préparation proposée par Noolya. Elle décrit le travail de l’entreprise, pas un écran ou une garantie de Microsoft.
Quel budget prévoir au-delà des licences ?
Microsoft distingue l’abonnement par utilisateur, ou USL, de la facturation à l’usage, ou UBB. Son texte du 23 septembre explique que les travaux agentiques consomment des Copilot Credits. L’annonce du 25 septembre rattache notamment Cowork, Code et Autopilot à cette logique d’usage. Une licence ne doit donc pas être interprétée comme un budget illimité pour toutes les tâches.
La documentation de Cowork décrit des contrôles de dépense et une mesure de l’usage. Pour le pilotage interne, associez chaque consommation à un résultat métier. Le coût d’une tâche doit inclure la relecture, les reprises et les opérations qui n’aboutissent pas. Comparer uniquement le prix d’une requête masque ces différences.
Définissez un responsable du budget, une enveloppe de pilote et la marche à suivre lorsqu’elle est atteinte. Vérifiez dans l’offre effectivement disponible quels plafonds interrompent l’exécution et quelles alertes servent seulement à informer. Cette distinction doit être testée, car une notification n’est pas nécessairement un mécanisme d’arrêt.
L’article sur la facturation de Copilot Cowork développe ce changement de lecture. Pour le nouveau Copilot, nous recommandons de conserver la même discipline : coût par résultat accepté, consommation par famille de tâches et motifs de reprise. Aucun montant universel ne remplace cette mesure dans votre contexte.
Que change un agent qui reprend le travail plus tard ?
La délégation longue introduit une difficulté supplémentaire : le contexte peut évoluer pendant l’exécution. Le document de référence change, une réunion est annulée ou le responsable retire son accord. Une mission initialement légitime ne doit pas conserver indéfiniment la même autorisation.
Pour le pilote, séparez les actions réversibles des actions engageantes. Préparer un brouillon, modifier un dossier partagé et envoyer un engagement à un tiers n’appellent pas le même contrôle. Une validation doit porter sur le contenu et les destinataires réellement prévus, pas sur une intention générale formulée plusieurs jours auparavant.
L’analyse d’Anand Candassamy sur le contrôle de Copilot Autopilot détaille une recette d’identité, de reprise et d’arrêt. Elle complète la lecture organisationnelle : le résultat à obtenir doit rester distinct des permissions accordées pour l’obtenir.
Comment organiser un pilote qui permette de décider ?
Choisissez une tâche et un groupe limité. Décrivez la situation actuelle avant l’introduction de l’outil : durée, sources utilisées, erreurs connues et personne qui accepte le livrable. Sans ce point de départ, une impression de fluidité peut être confondue avec un gain démontré.
Constituez ensuite un lot de cas réalistes et de cas construits. Prévoyez une donnée absente, un document contradictoire, un droit retiré et un résultat qui demande une validation. Les scénarios synthétiques servent à provoquer ces situations sans exposer des dossiers réels. Leur nombre dépend de la variété et du risque de la tâche.
Réservez des cas à la vérification finale, afin de ne pas ajuster les consignes sur tous les exemples. Faites relire les résultats par le métier et l’équipe technique. Une mauvaise réponse, une violation de droit et une dérive de coût appellent des décisions différentes. Gardez ces catégories séparées dans le rapport.
Terminez par une décision explicite : ouvrir le périmètre, poursuivre sous conditions ou suspendre. Nommez les anomalies acceptées, leurs conséquences et leur responsable. La décision doit pouvoir être revue après un changement de source, de fonctionnalité ou d’autonomie. Le déploiement d’un agent reste un processus d’exploitation, même si son interface ressemble à une conversation.
Quelle place donner à la formation ?
La formation doit suivre les usages retenus. Les collaborateurs ont besoin de savoir ce qu’ils peuvent déléguer, comment vérifier un livrable et quand demander une intervention. Les responsables ont besoin de comprendre les limites du pilote, les budgets et les décisions qui leur reviennent.
Une formation Copilot adaptée aux rôles peut utiliser les scénarios du pilote comme exercices. Les erreurs deviennent alors des situations compréhensibles, plutôt qu’une liste abstraite de précautions. Les retours servent aussi à corriger les processus et les interfaces : tout problème d’usage n’est pas un manque de formation.
La priorité n’est pas d’activer toutes les nouveautés ensemble. Elle est de choisir une activité dont le résultat, les frontières et la valeur peuvent être observés. Cette base permet ensuite de décider quelles capacités méritent d’être étendues.
Questions fréquentes
Le nouveau Copilot remplace-t-il Office ?
Microsoft annonce une intégration plus étroite d’Office dans Copilot. Cela ne signifie pas que les applications et leurs règles de travail disparaissent. Les usages existants doivent être vérifiés lors du pilote.
Toutes les nouveautés sont-elles déjà accessibles ?
Non. Les modalités annoncées comprennent Frontier et des préversions privées ou publiques. Vérifiez les conditions proposées à votre environnement avant de fixer un calendrier interne.
Une application hébergée dans le tenant est-elle automatiquement prête pour la production ?
Non. L’hébergement et les contrôles de plateforme ne valident pas la logique métier, les droits de chaque profil ou la capacité de l’équipe à maintenir l’application.
Sources
- Microsoft, présentation de Home, Code et Autopilot, 25 septembre 2026.
- Microsoft, Copilot Managed Runtime et son cadre d’exécution.
- Microsoft, modèle économique de l’IA au travail, 23 septembre 2026.
- Microsoft, disponibilité et gestion de Copilot Cowork, 16 juin 2026.
Analyse au 25 septembre 2026. Le protocole de pilote est une proposition Noolya ; aucun résultat de test des nouvelles préversions n’est revendiqué.
