5.4Actions : faire agir Copilot dans vos systèmes
L'essentiel en 30 secondes
- Le saut : avec les actions (connecteurs, flux), l'agent passe de répondre à agir — ticket, e-mail, écriture système.
- Lire vs écrire : lire est bénin, écrire/envoyer est risqué et irréversible — chaque action d'écriture se cadre.
- L'autonomie se mérite : confirmation humaine, permissions minimales, logs et bouton d'arrêt avant de déléguer.
Mini-cas filé — Hicham fait créer des tickets par son agent
L'agent de Hicham répond bien sur les politiques — mais quand un collègue signale une panne de matériel, il ne fait que conseiller. Hicham, assistant administratif à Alger, lui ajoute une première action via connecteur : créer un ticket au support avec description et priorité — avec récapitulatif affiché et confirmation humaine avant chaque écriture, journalisation et possibilité d'arrêter l'agent. Suite du cas 5.3 — Hicham passe du conseil à l'exécution, sans perdre le contrôle.
Suite du cas 5.3 — Hicham ajoute une action d'écriture unique, confirmée et journalisée.
1. Le saut : de répondre à agir
Jusqu'ici l'agent répond. Avec les actions, il agit : créer un ticket, envoyer un e-mail, écrire dans un CRM, lancer un flux Power Automate. C'est le saut le plus puissant… et le plus délicat. L'agent passe du conseil à l'exécution. Hicham choisit le cas le plus utile : transformer un signalement de panne en ticket, sans ressaisie.
Techniquement, les actions s'appuient sur des connecteurs : on relie l'agent à un système et on décrit quand et comment il peut agir dessus. « Si l'utilisateur signale une panne, crée un ticket dans le système support ».
2. Chaque action est un risque cadré
Principe cardinal : une action qui écrit dans un système est irréversible ou coûteuse à annuler. Chaque action doit être cadrée : conditions de déclenchement claires, périmètre limité, et idéalement une confirmation humaine avant les actions sensibles. Hicham impose : l'agent affiche le récapitulatif du ticket et attend le « oui » du collègue avant de créer.
Bonne pratique : distinguer lire (peu risqué) et écrire/envoyer (risqué). Un agent qui consulte un statut est bénin ; un agent qui envoie des e-mails ou modifie des données doit être conçu avec une prudence maximale et des garde-fous.
3. Superviser à l'échelle
Garde-fou d'échelle : un agent qui agit le fait vite et en nombre. Une erreur d'assistant reste locale ; une erreur d'agent autonome se répète à chaque déclenchement. D'où la nécessité de tester intensément, de journaliser les actions et de pouvoir arrêter l'agent. Hicham vérifie le journal des tickets créés chaque semaine.
Le principe qui résume tout : l'autonomie se mérite par la supervision. Plus on délègue d'actions à un agent, plus on investit dans son contrôle — permissions minimales, confirmations, logs, capacité de coupure. La puissance sans supervision est un danger.
🔎 Exemple concret — Hicham automatise la création de tickets support
Une action d'écriture unique, confirmée et journalisée.
Action (connecteur support) : « Si l'utilisateur décrit une panne matérielle, crée un ticket avec description et priorité. »
Garde-fou : afficher un récapitulatif et demander « Confirmer la création du ticket ? » avant d'écrire.Lecture : l'agent passe du conseil à l'exécution — il agit dans le système support.
Leçon : confirmation humaine avant l'écriture, journalisation, et bouton d'arrêt disponible.
Vocabulaire de la section
- Actions
- La capacité de l'agent à exécuter : créer un ticket, envoyer un e-mail, écrire dans un système.
Exemple simple : L'agent de Hicham crée un ticket support après confirmation.
Ce que ce n'est pas : une réponse qui conseille sans rien exécuter.
Réflexe : cette exécution est-elle vraiment nécessaire ?
- Connecteurs
- Les liens qui relient l'agent à un système, avec les règles d'usage.
Exemple simple : Hicham relie son agent au système support du service.
Ce que ce n'est pas : un accès total sans règle ni périmètre.
Réflexe : le quand et le comment sont-ils écrits ?
- Lire vs écrire
- Lire un statut est bénin ; écrire ou envoyer est risqué et souvent irréversible.
Exemple simple : Hicham laisse lire librement, fait confirmer chaque écriture.
Ce que ce n'est pas : traiter un envoi d'e-mail comme une simple lecture.
Réflexe : cette action écrit-elle quelque part ?
- Confirmation humaine
- Le « oui » explicite demandé avant toute action sensible.
Exemple simple : Le collègue valide le récapitulatif avant création du ticket.
Ce que ce n'est pas : une écriture automatique sans validation.
Réflexe : qui a dit oui avant l'écriture ?
- Supervision
- Tests, journal des actions et capacité d'arrêt d'un agent qui agit.
Exemple simple : Hicham relit le journal des tickets chaque semaine.
Ce que ce n'est pas : un agent qui agit sans trace ni coupure.
Réflexe : puis-je voir — et stopper — ce qu'il a fait ?
En pratique — Cadrer une première action à risque maîtrisé
- Choisissez une action simple et utile (créer un ticket, envoyer une notification interne).
- Distinguez lire et écrire : commencez par une action d'écriture unique, bien délimitée.
- Ajoutez une confirmation humaine avant l'exécution et limitez le périmètre au strict nécessaire.
- Prévoyez la supervision : journalisation des actions, tests intensifs, et un moyen d'arrêter l'agent.
Script prêt à dire — proposer une action encadrée
« Notre agent répond bien ; je propose une première action : créer un ticket support quand un collègue signale une panne. L'agent affichera un récapitulatif et attendra la confirmation avant d'écrire, avec permissions minimales et journal relu chaque semaine. Avant de brancher quoi que ce soit d'autre, je fais valider le périmètre et les habilitations par la DSI. »
À dire au responsable pour faire valider une première écriture confirmée et journalisée.
Modèle copier-coller — fiche de cadrage d'une action
FICHE ACTION — une par action d'écriture
ACTION : ___ (ex. créer un ticket support)
DECLENCHEUR : quand exactement ? ___ · PERIMETRE : ___ (système, champs)
LECTURE / ECRITURE : ___ · CONFIRMATION humaine ? OUI / NON (texte : ___)
PERMISSIONS : minimales = ___ · JOURNAL : relu par ___ chaque ___
ARRET : comment couper l'agent ? ___ · VALIDATION DSI le ___ : OK / KOSolo / petit budget
Hicham seul : une seule action d'écriture confirmée à la main — le journal relu chaque semaine suffit comme supervision.
TPE / équipe réduite
Confirmation systématique affichée à l'utilisateur : chacun valide ce que l'agent écrit en son nom.
PME à Alger
Hicham fait valider à Alger connecteur, permissions et journal par la DSI avant d'activer l'action.
Équipe qui démarre
Binôme : l'un conçoit l'action, l'autre tente de la piéger (cas limites, doublons) avant activation.
✓ Bonnes pratiques
- Commencez par les actions qui lisent, puis introduisez l'écriture avec une confirmation humaine.
- Accordez à l'agent les permissions minimales nécessaires : jamais plus que ce qu'exige l'action.
- Journalisez toutes les actions et gardez un bouton d'arrêt : à l'échelle, une erreur se répète vite.
✗ Pièges fréquents
- Laisser un agent écrire ou envoyer sans confirmation ni garde-fou : les erreurs se propagent à chaque déclenchement.
- Confondre le risque de lire et celui d'écrire : l'écriture est irréversible ou coûteuse à annuler.
- Déléguer des actions sans journalisation ni capacité d'arrêt : la puissance sans supervision est un danger.
Points clés à retenir
- Les actions font passer l'agent de répondre à agir : ticket, e-mail, CRM, flux — le saut le plus puissant et délicat.
- Distinguez lire (bénin) et écrire/envoyer (risqué, irréversible) : cadrez chaque action.
- Confirmation humaine avant les actions sensibles, permissions minimales, périmètre limité.
- L'autonomie se mérite par la supervision : tests, journalisation, bouton d'arrêt.
Défi 48h — appliquez demain
Remplissez la fiche action pour 1 écriture réelle (modèle ci-dessus) : la confirmation et l'arrêt y figurent-ils ?
- Je peux expliquer lire vs écrire en une phrase.
- Ma fiche action cadre déclencheur, confirmation et arrêt.
- Je sais pourquoi l'écriture exige un journal relu.
Questions fréquentes
Un agent peut-il vraiment agir tout seul dans nos systèmes ?
Oui, via des connecteurs. Mais chaque action d'écriture doit être cadrée : conditions claires, confirmation humaine sur le sensible, et supervision.
Comment limiter le risque d'un agent qui agit ?
Permissions minimales, distinction lire/écrire, confirmation avant l'écriture, journalisation des actions et un bouton d'arrêt. L'autonomie se mérite par la supervision.
Quel principe encadre un agent capable d'agir dans vos systèmes ?