Dans la démonstration, l’agent lit le sinistre, retrouve le contrat, corrige l’adresse du client et clôt le ticket. Un champ de votre système de référence a changé. Personne dans la salle ne pose la question qui compte dans une organisation régulée : qui a validé cette modification ?
Lire, c’est répondre ; écrire, c’est agir
Un agent qui lit vos systèmes et répond produit des énoncés. Un énoncé n’engage rien.[1] Si la réponse est fausse, l’enregistrement reste intact.
Dès que l’agent détient des identifiants qui lui permettent d’écrire dans le système de référence, la situation change. Une écriture est un acte. Elle se propage : le traitement de nuit la lit, la facture la reprend, les systèmes en aval s’y fient. Elle engage l’organisation, et fermer la fenêtre ne l’annule pas.
C’est la question centrale des agents en production, et elle arrive généralement trop tard, lors de la revue de sécurité qui suit un pilote déclaré réussi.
Un log enregistre le passé
La réponse habituelle est un log : l’agent écrit, chaque écriture est enregistrée, un auditeur peut relire. L’enregistrement est exact, mais ce n’est pas un contrôle. Un log décrit ce qui s’est passé ; un contrôle gouverne ce qui va se passer. Quand quelqu’un lit l’entrée, le champ a déjà changé et la modification s’est propagée.
Ce qui distingue un brouillon d’une erreur, c’est la réversibilité.[2] Décider coûte peu et se révise ; exécuter, non. La séquence est : prévisualiser, engager, annuler. Une erreur repérée avant le commit est un brouillon qu’on jette. Une erreur trouvée dans un log est un incident qu’on explique au régulateur.
L’undo est une seconde écriture
Les éditeurs le savent et proposent un undo. Mais un undo est une seconde écriture qui restaure l’ancienne valeur, émise après que la première s’est propagée. Entre les deux, des choses ont eu lieu : le client a reçu le courrier, la position a été déclarée, le lot est parti. La seconde écriture corrige l’enregistrement. Elle ne rappelle pas le courrier.
La seule erreur réellement réversible est celle qui n’a jamais atteint l’enregistrement.
Valider trois cents propositions par jour
L’autre réponse est l’humain dans la boucle. Mais une personne qui valide plusieurs centaines de propositions de la machine par jour n’en examine aucune. Le dispositif existe pour les auditeurs.[3] Le contrôle humain n’est réel que si la proposition est présentée dans des termes que la personne comprend, peut être refusée sans coût professionnel, et peut être annulée. La validation en masse échoue sur les trois : les propositions arrivent en liste, en refuser une crée un retard qu’il faudra justifier, et le lot est engagé d’un bloc.
Une décision sans nom n’est la décision de personne.[2:1] Un nom obtenu en cliquant sur « tout valider » ne vaut guère mieux.
Notre position
Le schéma habituel du secteur garde la décision dans la plateforme et envoie une instruction au système source. L’ERP ou le CRM reçoit un appel, et les règles qui gouvernent cet appel vivent ailleurs.
Galahad refuse trois choses. L’accès en écriture avec un log pour seul contrôle, parce que le log arrive après l’acte. La validation en masse, parce que cent propositions validées d’un clic sont une seule décision prise par personne. Un undo qui est une seconde écriture, parce que la réversibilité s’arrête au commit, et que l’examen doit donc avoir lieu avant.
Monarch propose et n’exécute jamais seul. Une erreur reste un brouillon non engagé.[4] Chaque étape est auditable et chaque décision rattachée à une personne. C’est ce que l’autorité a toujours signifié, pas une concession faite aux régulateurs.[2:2]
Les questions à poser à un éditeur
Posez-les par écrit, avant que l’agent ne reçoive le moindre identifiant.
- Dans lesquels de mes systèmes l’agent peut-il écrire, et sous quel compte ?
- Que voit la personne qui valide avant l’écriture : la modification exacte de l’enregistrement, ou un résumé rédigé par le modèle ?
- Combien de propositions une même personne reçoit-elle par jour, et peut-elle les valider en masse ?
- Que lui coûte un refus ?
- Que signifie « undo » : jeter un brouillon qui n’a jamais atteint l’enregistrement, ou une seconde écriture après propagation de la première ?
- Quel nom figure sur l’écriture, et peut-il être retiré après coup ?
Un éditeur qui répond aux six questions par des éléments vérifiables depuis votre propre réseau a construit un système qu’une organisation régulée peut exploiter.
Monarch présente chaque action à une personne nommée avant qu’elle n’ait lieu, dans votre infrastructure, sur les systèmes que vous exploitez déjà. Voyez-le sur vos données.