Ce qu’on ne délègue jamais à un modèle

Ce qu’on délègue à un modèle d’IA se décide sur la responsabilité, pas sur la capacité : la question utile est de savoir qui répond de la décision devant la personne qu’elle affecte.

La question posée est presque toujours : est-ce que le modèle en est capable. C’est la mauvaise entrée.

La bonne question est : qui répond de cette décision devant la personne qu’elle affecte. Si la réponse est « personne », la décision ne se délègue pas, quelle que soit la qualité du système.

Un modèle peut avoir raison dans la quasi-totalité des cas ; il ne peut pas être interrogé, contredit ou tenu pour responsable par un salarié, un client ou un juge. Cette asymétrie ne dépend d’aucun progrès technique.

Je garde sous responsabilité humaine les décisions qui affectent durablement une personne, engagent l’organisation, produisent des effets difficiles à annuler ou arbitrent entre des intérêts légitimes.

• Ce qui affecte durablement une personne : un recrutement, un licenciement, un refus de crédit, une orientation scolaire. La proposition européenne de 2021, encore en négociation, vise notamment certains usages de recrutement et de gestion des travailleurs à son annexe III. Une sanction disciplinaire ne figure pas comme catégorie autonome formulée ainsi.
• Ce qui engage l’organisation vis-à-vis d’un tiers : un envoi, une signature, un engagement contractuel, une communication publique.
• Ce dont les effets sont difficiles à annuler : un paiement, une suppression, une publication. Une restauration technique ne retire pas nécessairement les effets déjà produits.
• Ce qui relève d’un arbitrage de valeurs : choisir entre deux intérêts légitimes, c’est le travail de quelqu’un qui en répond.

Pour savoir si une décision peut être confiée à un modèle, on vérifie si elle affecte durablement une personne, engage l’organisation envers un tiers, est irréversible ou tranche entre des valeurs. Une seule réponse positive suffit à la garder humaine.

Refuser de déléguer la décision ne revient pas à écarter l’outil : un système d’IA peut préparer entièrement le dossier, rassembler les éléments et proposer une recommandation motivée et sourcée.

C’est le point que je tiens à rétablir.

Il peut préparer entièrement le dossier, rassembler les éléments, signaler les incohérences, proposer une recommandation motivée et sourcée. Le temps gagné est réel et souvent supérieur à celui que gagnerait une automatisation complète : parce qu’une automatisation complète exige une relecture si lourde qu’elle annule le bénéfice.

La personne qui décide arrive avec tout sous la main. Elle décide en quelques minutes au lieu de quelques heures. Pour que la recommandation soit vérifiable, elle doit citer ses sources, ce qui suppose une architecture de récupération documentaire comme celle décrite dans le RAG, la seule architecture qui tienne.

Pour vérifier la responsabilité d’une décision, je demande qui pourra expliquer et assumer ses conséquences en cas de contestation, avec les éléments disponibles au moment de décider.

« Si cette décision est contestée dans six mois, qui l’explique, et avec quoi ? » Si la réponse est « on regardera les journaux », la décision est déjà déléguée à un système et personne ne l’a voulu.

La frontière de délégation se déplace toute seule par petits pas : un humain valide, le taux de justesse monte, la validation devient une formalité, et la décision est déléguée sans que personne l’ait voulu.

Elle se déplace par petits pas, et c’est ce qui la rend dangereuse. Un système propose, un humain valide. Le taux de justesse monte. La validation devient une formalité. Six mois plus tard, personne ne relit plus vraiment.

C’est le biais d’automatisation, et il ne se corrige pas par une note de service. Il se corrige par la conception : dimensionner le débit sur la capacité de relecture, mesurer le temps passé par décision, et examiner les refus comme les validations. Un taux de refus nul appelle une vérification ; il ne démontre pas, à lui seul, une supervision absente.

Le classement des actions doit être validé par la personne qui répondra de leurs conséquences, jamais par l’équipe technique seule. C’est la validation qui manque le plus souvent, et son absence se paie à la mise en service.

Le schéma d’échec est constant. L’équipe technique construit un système capable d’agir, le présente, et découvre au déploiement qu’un responsable métier refuse : à juste titre, puisqu’il n’a pas participé à la définition du périmètre. C’est l’un des mécanismes décrits dans l’anatomie d’un PoC qui ne passe jamais.

La parade tient en une demi-journée d’atelier au cadrage :

1. Lister les actions candidates. Tout ce que le système pourrait lire, produire, envoyer, modifier ou supprimer.
2. Les classer par réversibilité. Ce qui se corrige sans conséquence, ce qui se corrige avec un coût, ce qui ne se corrige pas.
3. Appliquer les quatre catégories. Chaque action qui coche une catégorie reste soumise à une décision humaine explicite.
4. Faire signer le classement. Par le responsable métier concerné, avec une date.

Ce document rend la décision explicite et datée ; il ne constitue ni une qualification juridique complète ni une autorisation générale d’automatiser. J’ajoute une relecture trimestrielle de ce classement, parce que les usages dérivent et que le périmètre doit suivre. C’est le mécanisme décrit dans écrire la fiche d’un système d’IA.

Les erreurs qui rendent la délégation involontaire ont un point commun : elles laissent la validation humaine exister sur le papier tout en lui retirant le temps, l’information ou le pouvoir de dire non.

• Une validation sans information. La personne voit la conclusion du système mais pas les éléments qui la fondent. Elle ne peut qu’approuver.
• Un débit supérieur à la capacité de relecture. Si cent propositions arrivent pour une heure de travail disponible, la relecture devient un clic.
• Un refus coûteux. Quand rejeter une proposition demande de tout refaire à la main, on finit par accepter.
• Une décision prise par défaut. Le système agit si personne ne répond dans un délai donné : l’absence devient un accord.
• Un périmètre fixé par l’équipe technique. Sans le responsable métier, le classement reflète ce qui est faisable, pas ce qui est assumable.

Ces points se vérifient lors d’un audit IA, et se travaillent avec les équipes concernées dans une formation IA orientée sur les usages réels plutôt que sur l’outil.

Un système rapide doit laisser une possibilité réelle de vérifier, de refuser et de reprendre la décision, car un débit élevé peut transformer la validation en simple geste.

Le temps gagné par la génération n’est pas automatiquement un temps gagné pour une décision correctement relue. Il faut mesurer la charge de vérification et donner au responsable accès aux éléments utiles.

Je dimensionne le flux sur cette capacité de contrôle. Une interface qui enchaîne les propositions sans montrer les sources invite à approuver sans comprendre. La rapidité n’impose pas cette dérive : le parcours peut prévoir une pause, un refus simple et une reprise manuelle.

Ce raisonnement ne dépend pas d’une génération future de modèles. Il découle de la tâche et des conséquences de la décision, avec les moyens disponibles au 17 octobre 2023.

Dès qu’un système peut déclencher une action, la question cesse d’être « la réponse est-elle bonne » pour devenir « qu’est-ce qu’il a le droit de faire seul ». Les catégories restent les mêmes, l’enjeu change d’échelle.

Une réponse fausse peut être corrigée avant usage. Une action peut déjà produire des conséquences : envoyer un message, modifier une base ou communiquer à un tiers. Le classement par réversibilité devient alors le seul cadre opérant, et il doit être validé par celui qui répondra des actions. C’est le basculement amorcé dès que les modèles ont reçu des extensions capables d’agir, décrit dans quand un modèle commence à agir.

Ce cadre est développé dans le périmètre avant l’autonomie, et son absence explique une bonne part des projets d’agents arrêtés avant la mise en service.

Ma règle de conception garde certaines décisions sous responsabilité humaine, tandis qu’une interdiction légale ou une condition d’automatisation demande l’examen du texte applicable à l’usage.

Le RGPD encadre déjà certaines décisions fondées exclusivement sur un traitement automatisé et produisant des effets juridiques ou comparables. Son article 22 prévoit des conditions et des exceptions : il ne se résume pas à une interdiction de toute assistance.

La proposition de règlement sur l’IA reste en discussion à cette date. Elle n’est pas un règlement déjà applicable. Je distingue donc ce qu’un texte exige, ce que l’organisation choisit par prudence et ce que le système permet techniquement.

Lectures complémentaires : la latence devient un critère de conception, le périmètre avant l’autonomie, écrire la fiche d’un système d’IA.