Les décisions que nous ne confions pas à un modèle

La question qui revient en cadrage n’est pas « est-ce que l’IA sait le faire ». Techniquement, elle sait faire beaucoup. La question utile est : est-ce qu’on veut qu’elle le fasse seule ?

Ce sont deux questions différentes, et confondre les deux produit des systèmes qui fonctionnent en démonstration et qu’on débranche au premier incident.

Voici les trois critères que j’applique, et la distinction qui les précède.

Préparer n’est pas décider

La distinction la plus utile de tout ce billet.

Préparer, c’est réduire le travail de celui qui décidera : extraire les informations d’un document, trier une file par urgence, rédiger un premier jet, signaler les incohérences. La personne garde la main, et son travail passe de produire à vérifier.

Décider, c’est produire un effet sans qu’un humain intervienne : accepter un dossier, envoyer un message, déclencher un remboursement, refuser une demande.

L’écrasante majorité de la valeur que nous livrons est dans la préparation. C’est moins spectaculaire, ça ne se raconte pas bien en réunion, et c’est ce qui tient dans le temps.

Quand un client demande une automatisation complète, ma première question est donc : que gagne-t-on exactement à retirer l’humain, par rapport à lui présenter le travail déjà fait ? La réponse est parfois solide — un volume ingérable, une réponse attendue la nuit. Souvent, elle révèle que le gain réel était dans la préparation, et que l’automatisation complète n’ajoutait que du risque.

Critère 1 — l’erreur est-elle rattrapable ?

Le critère le plus opérationnel.

Une erreur rattrapable, c’est une erreur qu’on peut détecter et corriger avant qu’elle produise un dommage. Un dossier mal classé qu’on reclasse. Un brouillon relu avant envoi.

Une erreur non rattrapable, c’est celle qui a déjà produit son effet quand on la découvre : un message parti chez le mauvais destinataire, un paiement exécuté, une donnée écrasée, une demande refusée à quelqu’un qui ne reviendra pas.

La règle : plus l’erreur est irréversible, plus l’humain doit être dans la boucle. Et le point de vigilance, c’est que l’irréversibilité ne dépend pas de la technique mais du contexte. Supprimer une ligne est réversible si on a une corbeille ; envoyer un e-mail ne l’est jamais.

Critère 2 — faut-il pouvoir justifier ?

Deuxième filtre, et celui qui élimine le plus de cas dans les métiers réglementés.

Certaines décisions doivent pouvoir être expliquées à quelqu’un : un client qui conteste, un auditeur, un juge, une autorité de contrôle. « Le modèle a estimé que » n’est pas une justification recevable.

Il ne s’agit pas d’exiger qu’un modèle soit transparent — aucun ne l’est vraiment. Il s’agit de savoir si la décision doit reposer sur une règle énonçable. Si oui, la règle doit être implémentée comme une règle, et le modèle peut au mieux préparer les éléments qu’elle utilise.

C’est une distinction très concrète. Extraire d’un document la date de fin d’un contrat : tâche pour un modèle. Décider qu’un dossier est hors délai : règle, écrite en code, à partir de la date extraite. On garde la souplesse du modèle sur la lecture, et la rigueur d’une règle sur la conséquence.

Photo : domaine public (CC0).

Critère 3 — la décision engage-t-elle ?

Troisième filtre, plus rare mais dirimant.

Certaines décisions créent une obligation : accepter une commande à un prix, confirmer une disponibilité, prendre un engagement de délai. Ce qu’un système automatisé annonce à un client engage l’entreprise, indépendamment de la façon dont l’annonce a été produite.

Sur ces cas, nous mettons systématiquement une validation, ou nous contraignons la sortie à un ensemble fini de possibilités validées en amont. Un modèle qui choisit parmi trois réponses approuvées est très différent d’un modèle qui rédige librement.

Photo : Travel Adventures — licence CC0.

Ce que ça donne en pratique

Dans les applications que nous construisons, le partage est presque toujours le même :

Le modèle fait	L’humain ou la règle fait
Lire, extraire, classer	Valider ce qui est douteux
Trier par urgence	Décider de l’ordre de traitement
Rédiger un premier jet	Envoyer
Signaler une incohérence	Trancher
Proposer une réponse	Engager l’entreprise

Et une exigence de conception qui découle des trois critères : le système doit savoir dire qu’il ne sait pas. Un modèle qui répond toujours ne permet aucun des trois filtres, parce qu’on ne peut pas router vers un humain les cas qu’il ne signale pas.

Le glissement qu’il faut surveiller

Un point de vigilance qui relève de l’organisation plus que de la technique.

Une validation humaine qui existe sur le papier peut disparaître en pratique. Quand le système propose la bonne réponse quatre-vingt-quinze fois sur cent, la personne chargée de valider finit par valider sans lire — c’est un comportement rationnel, pas de la négligence. On se retrouve alors avec une automatisation complète que personne n’a décidée.

Deux parades qui fonctionnent : faire porter la validation sur les cas signalés comme douteux plutôt que sur tous, ce qui rend l’attention soutenable ; et mesurer le temps passé sur les écrans de validation. Quand il tombe sous quelques secondes, la validation n’existe plus, et il faut soit revoir le parcours, soit assumer l’automatisation et ses conséquences.

Photo : Travel Adventures — licence CC0.

Ce que je demande avant d’accepter une automatisation

Trois questions, posées au métier plutôt qu’à la technique, avant toute mise en service.

Qui répond si le résultat est faux ? Une personne nommée, pas un service. Si personne ne veut endosser la réponse, c’est que la décision n’est pas prête à être automatisée.

Comment le saura-t-on ? Une erreur qui ne remonte jamais n’est pas une erreur rattrapable, c’est une erreur invisible. Il faut un chemin de retour — une réclamation, un contrôle, un rapprochement — et quelqu’un qui le regarde.

Combien de temps avant de s’en apercevoir ? C’est la question la plus utile. Une erreur détectée en une heure se corrige ; la même erreur détectée en trois mois a déjà produit des factures, des courriers et parfois des décisions en aval.

Ces trois réponses déterminent le niveau d’automatisation acceptable bien mieux que la performance du modèle.

Le coût de la supervision, à provisionner

Un point rarement chiffré : faire relire par un humain ce qu’une machine propose n’est pas gratuit, et ce coût ne disparaît pas avec le temps.

Il faut compter le temps de relecture lui-même, mais aussi l’attention nécessaire pour relire quelque chose qui est presque toujours juste. C’est le piège de la supervision : plus le système est fiable, moins le relecteur est vigilant, et plus l’erreur rare passe.

Deux mesures qui aident. Ne faire relire que ce qui mérite de l’être — un score de confiance qui isole les cas douteux vaut mieux qu’une relecture uniforme et distraite. Et mesurer le taux de correction : s’il tombe à zéro pendant des semaines, la relecture est devenue un tampon, et il faut soit l’alléger officiellement, soit la rendre à nouveau utile.

Le seul cas où j’accepte l’automatisation complète

Il existe, et il vaut la peine d’être nommé pour ne pas donner l’impression que la réponse est toujours « mettez un humain ».

Quand les trois conditions sont réunies — l’erreur est rattrapable, aucune justification n’est due à un tiers, et rien n’est engagé — l’automatisation complète est le bon choix, et hésiter coûte de l’argent pour rien.

Le tri d’une file de demandes entrantes coche les trois : un mauvais classement se rattrape au traitement, personne n’a à justifier l’ordre d’une file, et aucun engagement n’est pris. C’est exactement là qu’il faut automatiser sans réserve — et c’est souvent là que les entreprises mettent le plus de validations, par prudence mal placée.