Boîte d'approbations
Une boîte bien tenue où chaque action que l'IA veut poser — mais n'a pas le droit de poser seule — attend le oui ou le non d'un humain, avec tout le contexte attaché.
Imaginez le plateau sur le bureau d'un gestionnaire où les papiers attendent une signature. Chaque page arrive avec l'histoire complète brochée dessus, et rien ne bouge tant que personne n'a signé. La boîte d'approbations, c'est ce plateau pour les actions de l'IA — au lieu de demandes éparpillées dans le clavardage (Slack) et les fils de courriels, où elles se perdent.
Le problème, en mots simples
L'agent a préparé un remboursement et a besoin qu'un humain dise oui. Où va cette demande ? Aujourd'hui, c'est un message dans un canal de clavardage, adressé à quiconque est en ligne. Le message défile sous les plans de dîner. Trois jours plus tard, le client réécrit, agacé, et vous fouillez l'historique pour savoir si quelqu'un a fini par approuver — ou si l'agent attend encore. Multipliez ça par chaque remboursement, chaque changement de compte et chaque message sortant de chaque workflow, et « un humain dans la boucle » devient « un humain quelque part dans l'édifice, espérons-le ».
Ce que nous mettons en place
Nous donnons aux actions en attente un chez-soi. Chaque action qui exige une signature atterrit dans une boîte dédiée, et chaque élément porte tout ce qu'il faut pour décider sans fouiller : ce qui l'a déclenchée, exactement ce que l'agent veut faire, son raisonnement, un lien vers la trace (le compte rendu enregistré de chaque étape que l'agent a suivie), et un SLA (un délai de réponse promis — une échéance sur la demande elle-même). La personne qui révise peut approuver, refuser avec une raison, ou modifier l'action avant d'approuver. Si personne ne répond à temps, la demande expire vers un comportement par défaut documenté — rien ne tombe simplement par terre. Et chaque refus ou modification est sauvegardé comme cas de test, pour que le système apprenne ce que les gens corrigent.
Comment ça fonctionne, étape par étape
- L'agent atteint un point de contrôle
Un workflow arrive à une action qu'il n'a pas le droit de poser seul — un remboursement, un changement de compte, un message qui sort de l'entreprise.
- La demande atterrit dans la boîte
Avec le déclencheur, l'action proposée, le raisonnement de l'agent, le lien vers la trace et son échéance. Pas un message dans un canal — un élément dans une file.
- Elle est routée à la bonne personne
Les demandes vont au réviseur qui possède ce genre de décision, pas à quiconque est en ligne.
- La personne décide
Approuver, refuser avec une raison, ou modifier l'action puis approuver. Un clic, tout le contexte déjà à l'écran.
- Pas de réponse à temps ? Le défaut s'applique
Chaque demande a une échéance et un repli documenté, pour que rien n'attende éternellement en silence.
- Les décisions nourrissent les tests
Les refus et les modifications deviennent des cas d'évaluation (des exemples de test sauvegardés), pour que la prochaine version du workflow propose de meilleures actions.
Ce qui change pour vous
Avant, les approbations vivaient là où on les avait demandées, et retrouver ce qui avait été décidé relevait de l'archéologie. Après, il y a un seul endroit, des délais de réponse suivis et un historique complet derrière chaque décision. Vous gagnez aussi un signal que vous n'aviez jamais eu : quels workflows ne se font presque jamais refuser — la preuve qu'ils ont mérité des barrières plus souples — et lesquels se font corriger sans arrêt et en méritent de plus serrées. Ce qu'il ne fera pas : décider à votre place. Si personne ne tient la boîte, les demandes expireront vers leurs défauts — la boîte organise la file d'attente, elle ne remplace pas le signataire.