# Deux façons de faire confirmer une action sensible par un humain avant exécution

> Confirmation synchrone qui bloque l'agent ou file d'approbation asynchrone : comparatif des deux approches pour valider une action irréversible avant exécution.

- Auteur : Clément Hadrot
- Publié le : 2026-01-02
- Mis à jour le : 2026-01-02
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/confirmation-humaine-synchrone-asynchrone-action-sensible/

## L’essentiel

- La confirmation synchrone convient aux actions rares où l'attente est acceptable
- La file d'approbation asynchrone garde l'agent disponible mais retarde l'exécution réelle
- Le choix dépend surtout de la fréquence de l'action, pas de sa seule gravité

Une action irréversible confiée à un agent pose toujours la même question avant sa mise en production : qui confirme, et à quel moment exactement ? Deux réponses distinctes coexistent dans les projets observés, avec des conséquences pratiques suffisamment différentes pour mériter d'être comparées avant de choisir l'une ou l'autre par défaut.

Ce comparatif ne traite pas des permissions techniques accordées à l'agent, déjà supposées correctement définies en amont : il porte uniquement sur le moment et la mécanique de la confirmation humaine elle-même, une fois qu'une action a été jugée suffisamment sensible pour l'exiger.

## La confirmation synchrone, qui bloque l'agent

Dans ce modèle, l'agent suspend son exécution au moment précis où l'action sensible doit être déclenchée, et attend une réponse explicite d'une personne avant de poursuivre. Concrètement, cela se traduit souvent par un message envoyé sur un canal de messagerie interne, avec deux boutons de réponse, et une reprise de l'exécution seulement après un clic.

## La file d'approbation asynchrone, qui libère l'agent

Dans ce second modèle, l'agent enregistre l'action proposée dans une file d'attente dédiée et poursuit immédiatement d'autres tâches sans attendre. Une personne consulte cette file à son propre rythme, valide ou rejette chaque entrée, et l'action ne s'exécute réellement qu'au moment de cette validation, potentiellement plusieurs heures plus tard.

> L'essentiel à retenir : La confirmation synchrone convient aux actions rares où l'attente est acceptable ; La file d'approbation asynchrone garde l'agent disponible mais retarde l'exécution réelle ; Le choix dépend surtout de la fréquence de l'action, pas de sa seule gravité

| Critère | Confirmation synchrone | File d'approbation asynchrone |
| --- | --- | --- |
| Disponibilité de l'agent pendant l'attente | Bloquée | Libre pour d'autres tâches |
| Délai avant exécution réelle | Court si la personne répond vite | Variable, parfois plusieurs heures |
| Adapté à un volume élevé d'actions sensibles | Non, sature vite la personne sollicitée | Oui, la file absorbe les pics |
| Contexte disponible au moment de la décision | Frais, la tâche vient de se dérouler | Parfois dilué si validation tardive |

## Le critère de choix qui compte le plus : la fréquence

Sur les projets suivis, le facteur le plus déterminant n'était pas la gravité de l'action en elle-même, mais sa fréquence attendue. Une action rare, comme la résiliation d'un contrat fournisseur, se prête bien à une confirmation synchrone : l'attente reste acceptable puisque l'occasion se présente rarement. Une action plus fréquente, comme la validation d'un remboursement client, sature rapidement une confirmation synchrone si le volume dépasse quelques occurrences par jour, et s'oriente naturellement vers une file asynchrone.

- Confirmation synchrone : adaptée aux actions rares, où l'attente reste acceptable pour la personne sollicitée.
- File asynchrone : adaptée aux actions fréquentes, au prix d'un délai variable avant exécution réelle.
- Les deux mécanismes peuvent coexister pour des catégories d'actions différentes sur un même agent.

### Un piège commun aux deux approches

Dans les deux cas, un contexte incomplet transmis à la personne qui confirme rend la validation purement formelle : si elle ne voit que le nom de l'action sans le détail des paramètres concernés, elle valide par habitude plutôt que par réelle vérification. Ce piège s'est révélé plus fréquent avec la file asynchrone, où la personne traite parfois plusieurs entrées d'affilée sans relire chacune en détail.

> Une confirmation qui ne montre pas exactement ce qui va se passer n'est pas une confirmation : c'est une case cochée par réflexe, et une case cochée par réflexe ne protège de rien.

## Un choix qui peut évoluer avec le volume

Sur un projet suivi depuis plus d'un an, l'approbation d'un certain type de remboursement a commencé en confirmation synchrone, le volume étant alors faible, avant de basculer en file asynchrone une fois le volume mensuel multiplié par quatre. Ce basculement n'a rien changé au niveau d'exigence de la vérification elle-même, seulement à sa mécanique d'attente.

## En résumé

Aucune des deux approches n'est supérieure dans l'absolu : la confirmation synchrone convient aux actions rares où l'attente immédiate reste acceptable, la file asynchrone aux actions plus fréquentes où bloquer l'agent deviendrait vite intenable. Le critère de choix le plus fiable observé en pratique reste la fréquence attendue de l'action, pas sa seule gravité perçue au moment de la conception.