Copilot Autopilot : qui contrôle un agent qui continue sans vous ?

Un agent persistant ne pose pas seulement une question de qualité de réponse. Il pose une question d’autorité : qui peut l’autoriser à agir, pendant combien de temps et sur quelles ressources ? Avec Copilot Autopilot, je regarderais d’abord cette frontière. Une mission compréhensible par le modèle n’est pas encore une délégation exploitable par l’entreprise.

Microsoft présente Autopilot le 25 septembre 2026 comme un agent proactif, persistant et doté de son propre environnement de travail. Son extension en préversion privée est annoncée pour la fin du mois. Il ne faut pas confondre cette annonce avec Windows Autopilot, consacré au déploiement de postes. L’analyse qui suit propose une méthode de contrôle ; elle ne prétend pas rapporter des tests de cette préversion.

Dans une conversation, l’utilisateur voit généralement la réponse avant de poursuivre. Une mission qui se prolonge comporte des attentes, des reprises et des actions espacées dans le temps. Entre deux étapes, le monde peut changer : une autorisation est retirée, une source est corrigée ou le besoin disparaît.

Le système doit donc distinguer l’objectif initial de l’autorisation actuelle. « Préparer la revue fournisseur » décrit un résultat. Cette phrase ne dit pas si l’agent peut contacter un tiers, modifier un planning partagé ou accéder à un nouveau dossier. Ces décisions demandent un cadre indépendant de la formulation du prompt.

Le nouveau Copilot réunit plusieurs formes de travail. La lecture du déploiement Home, Code et Autopilot par Noolya présente leurs implications organisationnelles. Ici, je me concentre sur un point : comment vérifier qu’un agent reste dans son périmètre lorsqu’il n’est plus surveillé à chaque étape.

Il faut pouvoir attribuer une action à un principal identifiable : utilisateur, application ou agent. Sans cette distinction, une trace indiquant seulement « Copilot a modifié le fichier » ne suffit pas à comprendre les droits exercés ni la personne responsable de la mission.

La documentation Microsoft Foundry décrit aussi des autopilots créés à partir de blueprints, avec une identité d’agent et un compte propre. Elle distingue l’approbation administrative du blueprint de la création d’une instance. Ce modèle documenté éclaire la séparation entre définition, identité et exploitation ; il ne décrit pas tous les réglages de la nouvelle préversion Copilot Autopilot.

Pour votre recette, identifiez donc le mécanisme réellement proposé. Qui possède l’instance ? Qui peut lui attribuer une mission ? Quels droits agit-elle en son nom, et lesquels dépendent d’un utilisateur ? Où retrouve-t-on cette distinction dans les journaux ? Ces questions doivent recevoir des réponses observables, pas seulement une description commerciale.

Ajoutez le départ du responsable. Une instance qui continue de travailler ne doit pas devenir orpheline lorsqu’une personne quitte l’organisation. Définissez la reprise de responsabilité, la suspension et la suppression selon les possibilités du produit. Une identité technique n’est pas, à elle seule, une gouvernance.

Je propose une fiche de délégation courte : résultat attendu, ressources consultables, outils autorisés, destinataires permis, durée et conditions d’arrêt. Ajoutez les actions qui demandent une validation. La fiche sert à préparer le paramétrage et les tests ; elle ne remplace pas un mécanisme technique d’autorisation.

Dans un exemple fictif de revue fournisseur, l’agent peut lire des documents de test et rédiger un dossier. L’envoi à un interlocuteur externe demande une confirmation. La modification d’un montant contractuel reste interdite. Ces trois règles sont plus faciles à vérifier qu’une consigne générale comme « prends les bonnes décisions ».

Les droits doivent être contrôlés au moment de l’action. Un accès accordé au lancement de la mission ne doit pas être considéré comme valable indéfiniment. Le test consiste à retirer une permission avant une étape ultérieure et à observer le résultat. Si le mécanisme disponible ne permet pas ce contrôle, cette limite doit restreindre le périmètre du pilote.

Les principes exposés dans RAG et droits d’accès restent utiles pour la lecture documentaire. L’agent ajoute cependant une autre frontière : il peut transformer une information en action. Il faut donc tester la consultation et l’exécution séparément.

La persistance rend possible la reprise d’une mission. Elle peut aussi prolonger une erreur. Un agent qui conserve un ancien interlocuteur ou une décision remplacée risque de repartir d’un état devenu faux. Il faut savoir quelles informations sont mémorisées et comment elles sont corrigées.

Utilisez un dossier synthétique avec un marqueur reconnaissable. Faites évoluer une donnée, puis reprenez la mission dans un autre contexte. Observez si l’agent utilise la version actuelle, signale une contradiction ou réemploie l’ancienne valeur. La bonne réponse peut être une demande de clarification plutôt qu’un choix silencieux.

Le protocole de test du rappel, de la correction et de l’oubli détaille ces opérations. Pour un agent persistant, ajoutez une règle : un souvenir ne doit jamais devenir une permission. Une instruction extraite d’un document ne gagne pas d’autorité parce qu’elle est conservée plusieurs jours.

Une exécution peut perdre la réponse d’un outil après que l’action a été réalisée. L’agent ne sait alors pas nécessairement s’il doit recommencer. Pour un calcul, cette ambiguïté peut être peu coûteuse. Pour un envoi, une création de commande ou une modification externe, elle peut produire un doublon.

Lorsque vous contrôlez l’intégration, prévoyez un identifiant d’opération et un moyen de vérifier l’état avant de rejouer une action. Selon l’outil, une clé d’idempotence ou une recherche de l’objet créé peut aider. Ces protections appartiennent au système complet ; elles ne doivent pas être supposées présentes dans chaque connecteur.

Le scénario de recette est simple : simulez une réponse incertaine après une action sur un environnement de test. Vérifiez que la reprise consulte l’état ou demande une intervention au lieu de répéter aveuglément. Conservez aussi un cas témoin où l’action a réellement échoué. Le système doit distinguer ces situations sans bloquer toutes les reprises.

Un arrêt utile doit avoir une portée définie. Suspend-il la mission en cours ? Empêche-t-il un déclenchement planifié ? Révoque-t-il des accès ? Laisse-t-il une action déjà envoyée se terminer ? Les réponses dépendent de l’architecture et des fonctionnalités effectivement accessibles.

Testez l’interruption à plusieurs moments : avant un appel d’outil, pendant une attente et avant une reprise programmée. Vérifiez ensuite qu’aucune nouvelle action non autorisée ne se produit. Un message « arrêté » dans l’interface est un signal à examiner, pas une preuve suffisante sur tous les composants.

Une action irréversible déjà accomplie ne disparaît pas lorsqu’on arrête la mission. Préparez donc une procédure d’incident : identifier ce qui a été exécuté, empêcher les suites possibles et informer le responsable. Cette procédure doit exister avant de confier une tâche sensible à l’agent.

Le Copilot Managed Runtime annoncé séparément fournit un cadre d’hébergement administré, avec identité, politiques et cycle de vie. Cette couche peut réduire le travail nécessaire pour exploiter une application. Elle ne dispense pas de vérifier les entrées, les sorties et les dépendances du code produit.

Une petite application générée peut devenir un outil quotidien. Dès lors, la recette doit couvrir son partage, ses changements de version et son accès aux sources. « Dans le tenant » ne signifie pas automatiquement « visible uniquement par les bonnes personnes », ni « localisé dans le pays souhaité ». Les politiques, contrats et configurations concernés doivent être examinés.

Je séparerais donc la validation de la plateforme et celle de l’application. La première examine les mécanismes proposés par le fournisseur. La seconde vérifie que la solution particulière traite correctement la tâche. Cette distinction évite d’attribuer à l’hébergement des garanties qu’il n’apporte pas sur la logique métier.

Un score moyen de réponses correctes ne suffit pas. Conservez au moins trois lectures : réussite de la mission légitime, violations de périmètre et coût de réalisation. Une évolution peut améliorer la première tout en dégradant les deux autres. La décision doit rendre cet arbitrage visible.

Microsoft distingue abonnement utilisateur et facturation à l’usage pour les travaux agentiques. Dans votre recette, mesurez la consommation jusqu’au résultat accepté, y compris les reprises. Ajoutez le temps de vérification humaine. Un résultat produit vite mais long à réparer peut déplacer le travail plutôt que le réduire.

Les tests d’injection indirecte doivent également faire partie du lot lorsque l’agent consulte des contenus externes. Utilisez des documents fictifs et des outils simulés. Vérifiez à la fois le respect des frontières et la poursuite de la tâche autorisée, sans exposer de vrais secrets pour démontrer un risque.

Choisissez une mission réversible, des sources maîtrisées et un groupe limité. Décrivez les actions autorisées avant de lancer la démonstration. Préparez les cas de retrait de droit, de contexte périmé, de reprise ambiguë et d’arrêt. Réservez une partie des scénarios pour vérifier les modifications sans les avoir utilisés pour régler les consignes.

À la fin, produisez une décision courte : périmètre accepté, limites, budget et responsable. Les résultats négatifs sont utiles s’ils conduisent à restreindre ou corriger le système. L’objectif n’est pas de prouver que l’agent peut tout faire. Il est de savoir quelles missions l’organisation peut lui confier avec un contrôle vérifiable.

Un audit IA du système et de ses usages doit pouvoir répondre à cette question avant l’ouverture générale. La qualité d’une délégation se mesure aussi à la capacité de la reprendre, de la corriger et de l’arrêter.

Analyse et méthode proposées par Anand Candassamy au 25 septembre 2026. Les scénarios sont synthétiques ; ils ne constituent pas un benchmark ni une certification de Copilot Autopilot.