Ce qui casse réellement, une fois le système en production
Les risques discutés en comité et les défaillances observées en production ne se recoupent presque pas. On débat de biais, d’inventions et de scénarios extrêmes ; ce qui casse vraiment, ce sont des choses plus ternes. Un système qui se dégrade lentement sans que rien ne le signale, parce qu’un fournisseur a changé une version de modèle sans prévenir. Une source de données dont le format évolue, et dont personne ne surveille le contenu. Une réponse fausse mais parfaitement plausible, dans le bon format, sur un cas que personne ne vérifie, qui se propage ensuite dans les décisions prises en aval. Aucune de ces défaillances ne produit d’alerte, et c’est exactement ce qui les rend coûteuses : elles ne sont pas détectées par un incident mais par une plainte d’utilisateur, plusieurs semaines après qu’elles ont commencé. Les traiter ne demande pas un dispositif lourd. Cela demande de savoir, à tout moment, si le système d’aujourd’hui répond aussi bien que celui d’il y a un mois, ce qui est une question mesurable et rarement mesurée.
La dérive silencieuse
C’est le risque numéro un en volume. Le système ne tombe pas en panne, il répond moins bien. Trois causes dominent, et aucune n’est de votre fait.
Le fournisseur change de version. Une mise à jour de modèle améliore la moyenne et dégrade une catégorie précise de cas, qui se trouve être la vôtre. Vous ne l’apprendrez pas par une note d’information.
Une source d’entrée évolue. Un champ change de signification, une convention de nommage se modifie, un système amont commence à envoyer des valeurs vides là où il en envoyait. Le système continue de traiter, en produisant des sorties fausses.
Le contexte réel change. Un nouveau type de dossier apparaît, une réglementation modifie une pratique, une saison différente présente d’autres cas. Le système a été validé sur le monde d’avant.
Le remède est unique et connu : un jeu d’évaluation contenant vos dossiers, étiquetés par vos experts, rejoué automatiquement, avec une alerte sur toute baisse. Sans lui, aucune des trois causes n’est détectable autrement que par les utilisateurs.
L’erreur plausible
Une réponse visiblement absurde est un incident mineur : quelqu’un la voit et la signale. La réponse dangereuse est celle qui a la bonne forme, le bon ton, le bon format, et qui est fausse sur un point que le lecteur n’est pas en position de vérifier.
Ce risque ne se traite pas par une relecture générale, qui devient formelle en trois semaines. Il se traite en identifiant les quelques cas où une erreur non détectée coûte cher, et en n’imposant une vérification que sur ceux-là. Un montant au-delà d’un seuil, un client dans une catégorie donnée, un type de décision réglementé.
Cette approche ciblée a un avantage qui dépasse le risque lui-même : elle reste appliquée. Une règle qui porte sur cinq pour cent des cas est encore respectée un an plus tard, ce qu’aucune obligation générale n’obtient.
Les risques dont on parle davantage qu’ils ne coûtent
Les inventions pures sont réelles et largement visibles, donc largement rattrapées. Elles méritent une vigilance et pas la place qu’elles occupent dans les discussions.
Les biais méritent une distinction que les débats font rarement : un biais sur une décision qui affecte des personnes est un problème sérieux et encadré, un biais sur un classement de tickets internes est une imprécision. Confondre les deux conduit à imposer aux seconds des contraintes calibrées pour les premiers, et à ne rien déployer.
Quant aux scénarios extrêmes, ils absorbent une attention considérable pendant que la dérive silencieuse, elle, se produit effectivement dans l’organisation qui en débat.
Comparer au bon point de référence
La question posée en comité est presque toujours de savoir si le système peut se tromper. La réponse est oui, toujours, et elle ne permet aucune décision.
La question utile est de savoir comment son taux d’erreur se compare à celui du processus actuel, sur les mêmes cas. Ce taux existe, il est rarement nul, et il est presque toujours inconnu parce que personne ne l’a mesuré. Le mesurer prend une journée et change souvent la conclusion d’un projet.
Exiger d’un système une perfection qu’on n’a jamais demandée aux personnes est une position confortable et coûteuse : elle conduit à refuser des projets qui amélioreraient la situation, au nom d’un point de référence imaginaire.
Une nuance compte cependant, et elle justifie une part de la prudence observée. Les erreurs humaines et les erreurs machine ne se répartissent pas de la même façon. Une personne se trompe de manière dispersée, sur des cas variés, et ses erreurs se compensent statistiquement. Un système se trompe de manière systématique, toujours sur la même classe de cas, et ses erreurs s’additionnent. À taux égal, la seconde situation est la plus dangereuse, parce qu’une catégorie entière de dossiers peut être mal traitée pendant des mois sans qu’aucun signal ne remonte.
La conséquence pratique est qu’il faut comparer les taux d’erreur, mais surtout regarder leur forme. Un système dont les échecs se concentrent sur un type de dossier identifiable est acceptable dès lors que ce type est reconnu et écarté vers une personne. Un système dont les échecs sont dispersés et rares est plus difficile à encadrer, malgré un taux global plus flatteur, parce qu’aucune règle simple ne permet de les intercepter.
Un problème, trente minutes
Décrivez une tâche qui prend trop de temps aujourd’hui, exceptions comprises. Nous vous dirons si elle vaut la peine d’être construite, et nous le dirons franchement quand ce n’est pas le cas.
A first conversation is thirty minutes and is not a sales call. If the answer is that you do not need us, that is a useful outcome and we will say so.
