Votre équipe veut transformer les résultats d’un dépôt de démonstration en rapport. L’agent peut lire les tests, préparer un document et, désormais, interagir avec une application de bureau. Mais qui décide que le document est prêt à être partagé ? Le passage d’un fichier local à une action dans un autre logiciel oblige à définir ce que vous déléguez réellement.
Prenons un scénario fictif : préparer un rapport de tests dans un espace sans compte personnel, puis s’arrêter avant tout partage. Ce parcours proposé n’a pas été exécuté. Il sert à distinguer trois décisions : accéder à une application, préparer une opération et autoriser son effet.
Deux annonces, deux questions différentes
Le 1er octobre 2026, GitHub annonce en préversion publique les interactions de Copilot avec des applications de bureau, dans Copilot CLI et Copilot app sur macOS et Windows. L’accès s’appuie sur des autorisations applicatives et des contrôles administrateur. Cette annonce ne couvre pas le contrôle du bureau sous Linux.
Le même jour, les workflows dynamiques passent en préversion publique. Ils permettent de décrire l’orchestration en code : étapes, parallélisme et points de revue. Le périmètre comprend la CLI, l’app et le SDK, l’ensemble d’outils destiné à intégrer Copilot dans un programme. Dans la CLI, l’annonce demande d’activer les fonctionnalités expérimentales.
| Objet annoncé | Question à poser avant le pilote |
|---|---|
| Interaction avec le bureau | Quelles applications et quelles opérations sont accessibles ? |
| Workflow dynamique | Dans quel ordre les étapes s’exécutent-elles et où s’arrêtent-elles ? |
| Autorisation applicative | Quel périmètre technique ouvre-t-elle exactement ? |
| Revue du résultat | Qui valide le document et l’effet métier prévu ? |
Ces questions restent distinctes. Une orchestration programmée peut organiser une analyse qui se trompe. Une permission d’application peut ouvrir plusieurs actions dont une seule est souhaitée. L’ordre du processus et la justesse du résultat se vérifient séparément.
Décrire l’action avant d’ouvrir l’accès
Dans notre exemple, « produire le rapport » paraît simple. Pourtant, cela peut désigner lire un fichier, créer un document, écraser un document existant ou transmettre des informations. Votre consigne doit nommer l’entrée, la sortie, l’emplacement autorisé et la condition d’arrêt.
Une première mission pourrait être : lire uniquement les résultats synthétiques du dépôt de test, rédiger un document dans le dossier de démonstration et afficher un aperçu. Le partage externe reste une étape distincte. Le périmètre devient compréhensible pour la personne qui relit, même si elle ne connaît pas l’outil d’agent.
La matrice suivante est une proposition Partitech pour ce pilote. Elle ne décrit pas des réglages automatiques de Copilot.
| Opération | Autorisation proposée | Preuve à relire |
|---|---|---|
| Lire les résultats synthétiques | Dans le dossier du pilote | Liste des fichiers utilisés |
| Préparer un rapport | Dans un nouvel emplacement local | Document et sources correspondantes |
| Modifier un rapport existant | Après comparaison explicite | Différence avant/après |
| Partager le document | Nouvelle décision humaine | Destinataire, contenu et canal |
| Supprimer les données de travail | Procédure séparée | Liste exacte des éléments concernés |
Pour chaque opération, examinez son coût d’erreur et sa réversibilité. Corriger un titre local demande peu d’effort. Retirer un document transmis à un tiers peut devenir impossible. Cette différence doit se traduire par une frontière visible dans le parcours, plutôt que par une phrase générale sur la prudence.
Rendre l’orchestration lisible par l’équipe
Un workflow est le parcours que suit la tâche. En le décrivant dans un programme, vous pouvez rendre certaines étapes explicites : collecter les entrées, demander une analyse, contrôler sa structure puis présenter un résultat à une personne.
Voici un pseudocode conceptuel, sans syntaxe de SDK et sans appel exécutable. Il illustre notre processus proposé ; ce n’est pas un exemple testé de l’interface GitHub.
identifier les fichiers autorisés
vérifier que les entrées sont présentes
produire une proposition de rapport
contrôler les références et les sections attendues
présenter le rapport et les changements prévus
attendre une décision explicite
si la décision autorise une action précise : exécuter cette action
sinon : arrêter en conservant le brouillon
Le programme peut imposer une étape de revue. Il ne remplace pas la revue elle-même. Une structure correcte peut contenir une conclusion erronée ; une référence peut pointer vers le mauvais test. Demandez donc que chaque affirmation utile renvoie à une entrée vérifiable, et qu’une absence de résultat soit signalée plutôt que complétée par une supposition.
Un résultat structuré signifie ici que la sortie distingue constat, source et limite. Ce contrat facilite un contrôle indépendant : un autre outil ou un autre lecteur peut comparer les sections aux fichiers d’entrée. Il ne transforme pas les phrases en preuves.
La documentation des workflows dynamiques reste la référence pour une implémentation. Vérifiez sa version au moment de coder. Un prototype d’orchestration ne doit pas reprendre une signature supposée d’un SDK à partir d’un simple schéma pédagogique.
Placer la revue avant l’effet
La bonne frontière se situe juste avant le changement qui engage l’équipe. Dans le pilote, le brouillon peut être préparé automatiquement, puis la revue doit montrer le document complet, les sources utilisées et l’action envisagée. Afficher seulement « continuer ? » ne permet pas de décider correctement.
Une approbation doit porter sur un objet défini. Si le contenu, le destinataire ou l’emplacement change après la revue, la décision précédente ne couvre plus exactement l’opération. Prévoyez alors une nouvelle présentation. Ce principe relève de notre méthode de qualification ; il ne présume pas que toutes les interfaces Copilot l’appliquent automatiquement.
Organisez aussi l’arrêt. Que reste-t-il lorsque vous annulez une session ? Où retrouver le brouillon ? Comment savoir si une opération a déjà été réalisée ? Une reprise aveugle risque de reproduire une action. Avant de relancer, vérifiez l’état réel de la sortie et l’étape atteinte.
L’environnement de démonstration doit rendre les erreurs observables sans engager vos comptes habituels. Utilisez des fichiers fictifs et une application de test, retirez les accès inutiles et confiez la révocation à une personne identifiée. Le pilote ne nécessite ni achat, ni courrier électronique, ni publication réelle.
Tester les refus autant que le parcours attendu
Notre protocole de qualification commence par le cas autorisé : les entrées sont présentes, le document est préparé et le processus s’arrête au point prévu. Consignez le résultat observé sans le qualifier de succès global. Ce premier essai vérifie un seul chemin.
Ajoutez ensuite une entrée absente, un fichier hors périmètre et une demande de partage non autorisée. L’objectif est de voir si le système s’arrête en indiquant ce qui manque, plutôt que d’élargir sa mission. Examinez aussi un document externe contenant une instruction trompeuse, par exemple demandant de changer le destinataire. Le document doit rester une donnée à analyser ; il ne devient pas une nouvelle autorisation.
La trace minimale doit permettre de reconstituer les entrées, les décisions et les effets. Évitez de collecter indistinctement le contenu de tous les documents. Définissez les personnes qui peuvent consulter ces traces et leur durée de conservation dans votre processus existant.
Notre article sur la sandbox et les traces Copilot app explique les annonces de septembre. Il fournit un contexte utile, mais ses mécanismes ne prouvent pas automatiquement la couverture des interactions de bureau annoncées le 1er octobre.
Décidez de poursuivre lorsque l’équipe sait expliquer le périmètre autorisé, vérifier le brouillon, arrêter le parcours et retrouver un état de reprise fiable. Si un de ces éléments manque, ajustez le pilote avant d’ajouter des applications. La nouvelle capacité devient utile lorsque la frontière de délégation reste visible.
Sources et date de vérification
Sources GitHub rouvertes le 6 octobre 2026 : interaction avec le bureau, workflows dynamiques et documentation conceptuelle. Les préversions peuvent évoluer. Matrice, scénario et pseudocode sont des propositions originales Partitech, sans résultat d’exécution revendiqué.