La démonstration est un scénario. L’agent lit la réclamation, retrouve la police, corrige l’adresse du client, ferme le ticket. Quelque part dans la deuxième minute, un champ de votre système de référence a changé. La salle l’a regardé faire et personne n’a posé la seule question qui compte dans une organisation régulée : qui a signé cela.
Lire, c’est dire ; écrire, c’est faire
Un agent qui lit vos systèmes et répond produit des énoncés, et un énoncé, si fluide soit-il, n’est pas un engagement.[1] Rien ne lie. Si la réponse est fausse, quelqu’un la lit, et l’enregistrement est tel qu’il était. À l’instant où l’agent détient des identifiants qui peuvent écrire dans le système de référence, la catégorie change. L’écriture est un acte. Elle se propage : le batch de nuit la lit, la facture la porte, le système aval lui fait confiance. Elle engage l’organisation et on ne la retire pas en fermant l’onglet.
C’est toute la question des agents en production, et on la pose bien trop tard, en général lors de la revue sécurité, après que le pilote a été déclaré un succès.
Un log raconte ce qui a déjà eu lieu
La réponse habituelle à cette question est un log. L’agent écrit ; chaque écriture est enregistrée ; un auditeur peut lire l’enregistrement. L’enregistrement est honnête. Il est aussi inutile comme contrôle, parce qu’un log décrit le passé et qu’un contrôle gouverne l’avenir. Le temps que quelqu’un lise la ligne, le champ a changé et le changement a voyagé.
La réversibilité est la condition qui sépare un brouillon d’une erreur.[2] Le risque vit dans l’exécution, qui n’est ni bon marché ni révisable ; la décision qui la précède est les deux. Preview, commit, revert. Une erreur attrapée avant le commit est un brouillon, et un brouillon se jette. Une erreur attrapée dans un log est un incident, et un incident s’explique à un régulateur.
L’undo est une seconde écriture
Les fournisseurs le savent et proposent un undo. Regardez ce qu’est cet undo. C’est une seconde écriture qui rétablit la valeur précédente, émise après que la première s’est déjà propagée. Entre les deux, le monde a bougé. Le client a reçu le courrier, la position a été déclarée, le lot a été libéré. La seconde écriture corrige l’enregistrement ; elle ne rappelle pas le courrier.
La seule erreur qu’on peut réellement annuler est celle qui n’a jamais atteint l’enregistrement. Tout le reste est de la remédiation sous un nom plus aimable.
Le valideur qui en valide trois cents par jour
L’autre réponse est un humain dans la boucle. Regardez ce qu’il fait de sa journée. Une personne qui valide plusieurs centaines de propositions de machine dans une journée de travail ne valide rien. C’est un appareil à signature attaché à un processus qu’elle ne peut pas examiner, et le dispositif existe au bénéfice des auditeurs.[3] L’autorité humaine sur un système n’est réelle que là où la proposition est rendue dans des termes que l’humain comprend, refusable sans coût professionnel, et réversible après coup. La validation en masse échoue aux trois : les propositions arrivent en liste, le refus est un retard dont on demandera des comptes, et le lot part en un seul commit.
Une décision sans nom au bas de la page, c’est de la météo.[2:1] Une décision dont le nom a été obtenu en cliquant « tout valider », c’est de la météo avec une signature.
Ce que Galahad refuse
Le pattern de l’industrie place la décision dans la plateforme et remet au système source une instruction. Une action appliquée dans la plateforme envoie une requête à l’ERP ou au CRM, avant la modification propre à la plateforme ou après elle. Le pattern est cohérent. Il signifie aussi que le système de référence reçoit un appel, et que ce qui gouverne cet appel vit ailleurs.
Galahad refuse trois choses. Un agent avec un accès en écriture et un log pour seul contrôle : le log arrive après l’acte. La validation en masse : cent propositions en un clic, c’est une décision, prise par personne. Un undo qui est une seconde écriture : la réversibilité s’arrête au commit, donc l’examen doit avoir lieu avant.
Reste la ligne du fondateur : chaque agent sur un harnais, chaque étape auditable, chaque décision traçable. Monarch propose, il n’exécute jamais seul. Une erreur reste un brouillon non commité.[4] C’est ce que l’autorité a toujours voulu dire. Un fournisseur qui le présente comme une concession arrachée par les régulateurs a rendu l’argument pour rien.[2:2]
Les questions à poser à un fournisseur
Posez-les par écrit, avant que l’agent reçoive un identifiant.
- Dans lesquels de mes systèmes l’agent peut-il écrire, et sous quel compte ?
- Que voit le valideur avant l’écriture : la modification exacte de l’enregistrement, ou un résumé composé par le modèle ?
- Combien de propositions un valideur reçoit-il par jour, et peut-on les valider par lot ?
- Que coûte au valideur d’en refuser une ?
- Qu’est-ce que l’undo : l’abandon d’un brouillon qui n’a jamais atteint l’enregistrement, ou une seconde écriture après que la première s’est propagée ?
- Quel nom figure sur l’écriture, et peut-on le retirer ensuite ?
Un fournisseur qui répond aux six par quelque chose que vous pouvez vérifier depuis votre propre réseau a construit un système qu’une organisation régulée peut exploiter. Un fournisseur qui répond par un log a écrit le rapport d’incident à l’avance.
Monarch met chaque action devant une personne nommée avant qu’elle ait lieu, dans votre infrastructure, sur les systèmes que vous exploitez déjà. Voyez-le sur vos données.