La recette d’un plugin Copilot doit vérifier ce qu’il permet et ce qu’il refuse, avec des comptes, des connexions et une version identifiés. Une démonstration réussie sur un compte administrateur ne suffit pas pour ouvrir l’usage à une équipe.
Le bilan Microsoft de septembre 2026 annonce un registre commun de plugins. La documentation actualisée le 30 septembre distingue distribution et administration des composants. Je propose ici une méthode de test pour cette nouvelle couche d’outils. Elle complète mon analyse de Copilot Autopilot et des identités, avec un périmètre plus précis.
Quelle différence entre publier un plugin et pouvoir l’utiliser ?
Publier un plugin rend un paquet disponible par une route donnée ; son utilisation dépend ensuite des affectations, des connexions et des droits applicables. Microsoft indique qu’un plugin peut réunir plusieurs capacités et référencer un service distant qui s’exécute séparément.
Je commence la recette par un inventaire court : paquet et version, expérience Copilot utilisée, composants, services distants, comptes et données. Le résultat attendu est écrit avant le premier essai. Sans cet inventaire, un succès peut dépendre d’une connexion personnelle ou d’un droit administrateur absent chez les futurs utilisateurs.
Le guide d’administration Microsoft distingue plusieurs objets et surfaces de contrôle. Je ne suppose donc pas qu’un seul réglage décrit tous les droits. Chaque composant doit être relié à la personne et au système capables de l’administrer.
Exemple fictif : un plugin recherche un contrat puis prépare une tâche dans un outil métier. L’accès au contrat et l’autorisation de créer la tâche sont deux questions. La recette les vérifie séparément avant d’examiner le parcours complet.
Comment construire un cas autorisé et un cas refusé ?
Un cas autorisé utilise un compte qui dispose du droit nécessaire ; un cas refusé reprend la tâche avec un compte ou une ressource hors du périmètre. Les deux essais doivent partager un contexte suffisamment comparable pour rendre la différence interprétable.
Je prépare des données de test sans information personnelle réelle. Une ressource contient un repère fictif connu de l’évaluateur. Le compte autorisé peut l’utiliser. Le compte restreint ne doit ni révéler ce repère ni exécuter l’action interdite. L’évaluateur examine le contenu de la réponse et l’état du système cible.
Une formulation de refus ne suffit pas si une action a tout de même été exécutée en arrière-plan. Inversement, une réponse peu élégante peut accompagner une restriction correctement appliquée. Je consigne ces deux dimensions pour ne pas confondre qualité rédactionnelle et respect du droit.
Chaque observation porte le compte, la ressource, la version, la demande et le résultat. Le test concerne ce périmètre ; il n’établit pas que toutes les attaques ou toutes les formulations possibles ont été couvertes.
Que vérifier lorsqu’une connexion ne fonctionne plus ?
Une connexion périmée ou indisponible doit produire un comportement observable qui ne simule pas une action réussie. Je teste cette situation sur le service réellement utilisé par le plugin, dans un environnement adapté à la recette.
La demande peut rester compréhensible alors que le composant ne peut plus joindre ses données. Le test vérifie si la réponse explique cette limite et si une opération partielle a eu lieu. Pour un outil qui modifie un état, je consulte le système cible plutôt que de me fier uniquement au message du chat.
Je note les modalités de reprise : nouvelle authentification, correction de configuration ou intervention du support. Lorsque la tâche est relancée, il faut vérifier le traitement d’un éventuel doublon. Le scénario peut être simple, mais il doit être explicite : une indisponibilité ne doit pas devenir une double action silencieuse après reconnexion.
La recette distingue ce qui a été constaté et ce qui n’est pas visible avec les outils disponibles. Une absence de trace n’est pas présentée comme une preuve que rien n’a eu lieu.
Pourquoi rejouer la recette après une nouvelle version ?
Une nouvelle version peut modifier les instructions, les outils, les connexions ou le comportement du plugin. Je compare donc le périmètre accepté au périmètre proposé, puis rejoue les cas concernés par le changement.
Le dossier conserve un jeu de demandes de référence : une tâche normale, une demande ambiguë, un droit absent et une connexion indisponible. Ces cas ne remplacent pas tous les tests ; ils servent de points de comparaison. Les observations incluent la version et la date pour rendre une régression retrouvable.
La documentation de suivi Microsoft décrit la gestion du cycle opérationnel. Ma proposition est d’associer chaque changement à son responsable, à son motif et à une décision de mise en service. Un nouvel outil d’écriture reçoit une revue différente d’une correction de formulation.
La méthode rejoint mon dossier de preuve d’une réponse IA : conserver suffisamment d’éléments pour expliquer une décision sans enregistrer des données sensibles inutiles.
Comment prouver que le retrait est effectif ?
Le retrait est vérifié en rejouant une tâche dans une nouvelle session après la restriction des accès et des dépendances prévues. Le dossier décrit les opérations réalisées et le comportement observé ; il ne s’arrête pas à une capture de configuration.
Je sépare la fermeture de la distribution, l’affectation des utilisateurs et les connexions ou autorisations distantes. Les contrôles exacts dépendent du composant et de la route utilisée. Le propriétaire technique identifie lesquels doivent être modifiés pour le périmètre testé.
Après le retrait, le compte ne doit plus réaliser l’opération visée dans le scénario. Je vérifie aussi les éventuelles sessions ou tâches déjà engagées lorsque le produit permet ce contrôle. Si leur état ne peut pas être observé, cette limite figure dans le dossier au lieu d’être remplacée par une garantie générale.
Quel dossier suffit pour décider d’une ouverture limitée ?
Un dossier de pilote doit permettre de retrouver le périmètre, les essais et les limites. Je propose une fiche d’usage, un inventaire des dépendances, les cas de recette, les observations et la décision d’ouverture ou de correction.
La décision précise les utilisateurs concernés et ce qui reste interdit. Un incident découvert pendant la recette peut justifier de limiter le plugin à la lecture, de changer une connexion ou de suspendre l’ouverture. Le document indique la prochaine revue et le responsable du support.
Cette approche complète les tests d’injection de prompt indirecte et de filtrage des droits avant une réponse RAG. Les essais se combinent lorsque le plugin consulte des contenus externes puis exécute une action. Ils gardent chacun un résultat attendu, afin de comprendre la cause d’un échec.
Questions fréquentes
Un compte administrateur peut-il servir à toute la recette ?
Il peut servir aux contrôles d’administration, mais ne représente pas les utilisateurs ordinaires. La recette doit inclure les profils qui utiliseront le plugin et des profils restreints. Le compte, les droits et les connexions sont conservés avec chaque observation pour expliquer les différences de résultat.
Peut-on conclure à la sécurité après quatre tests réussis ?
Non. Les essais décrivent un périmètre et des cas précis. Ils permettent de décider d’un pilote limité et d’identifier des problèmes, sans prouver l’absence de toute vulnérabilité. Les tests supplémentaires sont choisis selon les capacités, les données et les conséquences de l’usage.
Faut-il refaire tous les tests à chaque modification ?
La reprise dépend du changement. Les cas touchés doivent être rejoués, avec un socle de comparaison conservé. Un élargissement des outils ou des droits nécessite une revue plus importante qu’une correction rédactionnelle. La décision et son périmètre sont documentés, plutôt que supposés.
Préparer la recette de votre plugin
Choisissez une tâche, un compte autorisé, un compte restreint et un résultat observable. Mon accompagnement d’audit IA peut aider à construire ce dossier avec votre équipe. Pour cadrer la mission avec Anand Candassamy et Noolya : contact@noolya.fr.