Une supervision écrite dans un document de gouvernance est une déclaration d’intention. Une supervision écrite dans un système est une contrainte. Les deux ne sont pas la même chose, et une seule survit au contact d’un mardi chargé.
Une organisation peut arriver à une conversation sur l’automatisation en tenant déjà un principe : un être humain restera responsable de tout ce qui compte. C’est un bon principe. Énoncé ainsi, il est aussi inapplicable — parce qu’il ne dit pas quelles décisions comptent, à quel moment la personne intervient, ni ce qu’on lui montre quand elle intervient.
Ces trois questions sont de l’architecture. Elles se règlent à la conception du système, avant que rien ne soit construit, et les réponses deviennent de la structure dans le logiciel plutôt que des consignes dans un manuel. Si on les laisse à un document de politique, il s’ensuit que le système fait ce qui est le plus facile à construire, et que la politique le décrit après coup.
Trois places pour une décision
Il n’y en a que trois, et être explicite sur celle qui s’applique à chaque décision ôte l’ambiguïté d’un programme d’automatisation.
Le système agit, et ne le dit à personne. Juste pour le travail réversible, à faibles conséquences et à fort volume : faire passer un enregistrement d’un état à un autre, joindre un document au bon dossier, envoyer un rappel interne. Si une personne devait approuver chacun, l’automatisation ne vaudrait pas la peine d’être commandée.
Le système agit, et le dit à quelqu’un. Juste là où l’action est presque toujours la bonne et où le coût de la rare erreur est une excuse plutôt qu’une perte. La notification n’est pas une décoration ; c’est le mécanisme par lequel l’organisation découvre que le système dérive.
Le système prépare, et une personne engage. Juste partout où de l’argent bouge, où un engagement est pris envers un tiers, ou où un jugement de sécurité est en cause. Le travail — la lecture, l’extraction, le recoupement, la rédaction — est toujours fait par le système. Ce que le système ne fait pas, c’est le dernier clic.
La trace est le but, pas l’audit
Un régulateur ou un auditeur peut vouloir de la traçabilité. C’est une raison, mais pas la plus importante. La plus importante est qu’une personne ne peut pas approuver de manière sérieuse ce qu’elle ne peut pas examiner.
Une décision présentée comme une recommandation sans raisonnement montré met le relecteur dans une position impossible : la tamponner, ou refaire l’analyse lui-même. La première fait de la supervision du théâtre. La seconde rend l’automatisation inutile. La trace — quel document source, quelle clause, quelle règle, quelle décision antérieure — n’est donc pas un artefact de conformité boulonné à la fin. C’est ce qui rend l’étape d’approbation réelle.
C’est la forme autour de laquelle Contraxis est conçu, et c’est pourquoi il est décrit en cinq étapes plutôt qu’une : le document est lu, les constats remontent, les actions sont proposées, chaque étape est enregistrée, et une personne décide. La cinquième étape existe parce que les quatre premières ne valent rien sans elle.
Ce que cela coûte, et pourquoi cela en vaut la peine
Concevoir la supervision dans le système est plus lent que ne pas le faire. Cela exige une discussion, tôt, sur les décisions qui ont des conséquences — et cette discussion fait remonter des désaccords dans l’organisation qui étaient confortables tant qu’ils restaient implicites. Deux directeurs qui croient tous deux qu’une personne reste dans la boucle peuvent se révéler penser à des personnes différentes, à des moments différents, avec une autorité différente.
Avoir cette discussion pendant la conception du système coûte quelques séances dans une salle. L’avoir après que quelque chose est sorti au nom de l’organisation coûte considérablement plus. C’est l’un des rares endroits d’un programme de livraison où prendre la difficulté en premier est sans ambiguïté le chemin le moins cher.
Recalibre · Contraxis est en développement.