Automatiser le travail sans abandonner la décision.
Séparer la réponse, le conseil, la préparation et l’exécution pour offrir un vrai point de contrôle et une reprise fiable.
Réponse courte
L’automatisation est plus sûre quand le système prépare avant d’agir. Distinguez quatre niveaux : répondre, guider, préparer et exécuter. Une proposition doit montrer le changement prévu, les éléments qui le justifient, les champs modifiables et l’effet attendu. Lors de la confirmation, l’application vérifie de nouveau les droits et l’état du dossier. Les actions simples et réversibles peuvent être déléguées selon une règle explicite. Une décision ambiguë, difficile à annuler ou lourde de conséquences garde un point de contrôle humain.
À retenir
- 01
Une proposition générée n’est pas une action exécutée.
- 02
La confirmation doit montrer le changement exact et déclencher une nouvelle vérification côté serveur.
- 03
La trace et la reprise font partie du produit, pas seulement de l’exploitation.
01 / SITUATION
La meilleure automatisation se situe souvent avant l’exécution
Les équipes perdent du temps à rassembler des informations, vérifier des règles, recopier des valeurs et préparer les mêmes transmissions. Ces étapes peuvent être assistées sans retirer la décision finale à la personne compétente.
Le risque apparaît quand une réponse bien formulée est prise pour une autorité. Le modèle peut choisir le mauvais outil, manquer une exception ou s’appuyer sur un état dépassé. L’interface et le serveur doivent donc rendre la frontière entre préparation et exécution impossible à confondre.
02 / MECHANISM
Un contrat d’action maîtrisé
Chaque parcours d’action suit des états explicites que le modèle ne peut pas court-circuiter.
- 01Établir la situation
Réunir l’utilisateur, le dossier, la règle applicable et les preuves. S’arrêter si une information indispensable manque.
- 02Proposer
Créer une action en attente avec une cible, des paramètres, une justification et un effet attendu. Ne jamais la présenter comme déjà réalisée.
- 03Prévisualiser
Afficher les valeurs modifiables, les preuves et les conséquences dans le produit. L’annulation et le retour arrière doivent rester visibles.
- 04Confirmer
Recueillir une décision explicite pour les opérations qui comptent. Ce point de contrôle appartient au logiciel hôte, pas seulement à la conversation.
- 05Revérifier puis exécuter
Contrôler à nouveau l’identité, les droits, l’état actuel et les règles invariantes. Refuser une proposition devenue périmée ou invalide.
- 06Tracer et reprendre
Distinguer les états proposé, confirmé, refusé, terminé et échoué. Après un échec, indiquer la prochaine étape sûre.
03 / Dans le travail réel
Préparer un ticket de support
L’assistant rassemble le contexte et propose le ticket. L’utilisateur le corrige puis l’envoie. Rien n’est créé à l’extérieur avant sa confirmation.
Corriger une fiche
L’assistant repère un champ absent et prépare la correction. Au clic de l’opérateur, le produit relit la fiche et vérifie le droit d’écriture.
Valider une demande
L’assistant réunit les éléments et ouvre l’écran de validation. La personne habilitée reste responsable de la décision.
Pièges fréquents
- Afficher un bouton de confirmation sans montrer précisément ce qui va changer.
- Exécuter une proposition ancienne sans relire l’état actuel.
- Enregistrer une proposition comme terminée avant le retour positif de l’outil.
- Fournir au modèle un accès large qui dépasse les droits de l’utilisateur.
- Concevoir uniquement le cas idéal sans prévoir l’annulation, la relance ou l’escalade.
Checklist d’implémentation
- Les niveaux d’action sont nommés et documentés.
- Les actions en attente suivent un schéma typé.
- La prévisualisation montre la cible, les valeurs, les preuves et l’effet attendu.
- Les opérations importantes exigent une confirmation explicite.
- Le serveur revérifie l’identité, les droits et l’état.
- Une protection contre les doublons existe lorsque c’est nécessaire.
- Les refus, échecs et résultats partiels ont un chemin de reprise.
Ce que cette approche ne promet pas
- La confirmation humaine ne rend pas sûre une opération mal conçue.
- Une action réversible peut tout de même avoir des conséquences opérationnelles, contractuelles ou sur la vie privée.
- Les benchmarks ne remplacent pas les tests menés avec les outils et les règles de l’organisation.
Sources et nature des références
- 01Artificial Intelligence Risk Management Framework 1.0NIST · 2023Référentiel
- 02τ-bench: Tool-Agent-User Interaction in Real-World DomainsYao et al. · 2025Recherche
- 03Model Context Protocol specificationMCP maintainers · 2025-11-25Référentiel
- 04AgentDojo: A Dynamic Environment to Evaluate Prompt Injection AttacksDebenedetti et al. · 2025Recherche
Questions fréquentes
Toutes les actions doivent-elles être confirmées ?
Non. Une équipe peut déléguer des actions peu risquées et réversibles après les avoir évaluées. Le classement des risques et le niveau d’autorité restent des choix du produit.
La confirmation peut-elle avoir lieu dans le chat ?
Elle peut y être présentée, mais l’action finale et la vérification des droits doivent rester sous le contrôle de l’application.
Que faut-il tracer ?
Assez d’éléments pour distinguer la demande, les preuves, la proposition, la confirmation, l’exécution et le résultat, sans recopier de données sensibles inutiles.