Il existe deux architectures possibles, et elles se ressemblent sur un schéma. La première : l'IA analyse, décide, agit. La seconde : l'IA analyse, propose, un humain valide, puis l'action part. Sur un process anodin, l'écart est une question de confort. Sur un process sensible, c'est la différence entre un gain de temps et un incident.

La règle : le coût d'une erreur décide

Nous ne plaçons pas la validation humaine par principe, ni par méfiance. Nous la plaçons là où une erreur coûterait plus cher que le temps qu'elle fait perdre. Quatre questions suffisent à trancher, étape par étape :

  • Est-ce réversible ? Un classement se corrige. Un e-mail envoyé à trois mille clients ne se rattrape pas.
  • Est-ce visible de l'extérieur ? Tout ce qui sort de l'entreprise engage son image et sa parole.
  • Est-ce que ça engage juridiquement ou financièrement ? Un prix, un délai, un refus, un remboursement.
  • La règle est-elle stable ? Une règle qui change tous les mois demande un œil humain plus longtemps.

Une étape réversible, interne, sans engagement et régie par une règle stable peut tourner seule. Dès qu'une de ces conditions saute, une validation apparaît.

Ce que « valider » veut dire

Une validation n'est utile que si elle est faisable en quelques secondes. Une case à cocher au milieu d'un mur de texte n'est pas une validation, c'est une formalité que l'on finit par expédier sans lire. Nous concevons donc l'écran de validation comme un livrable à part entière : ce que la machine propose, sur quoi elle s'est fondée, ce qui va se passer si l'on accepte, et un moyen de refuser en un clic.

Nous allons plus loin sur les actions à effet externe : un refus ne se contente pas de bloquer, il défait ce qui peut l'être et il enregistre l'interdit, pour que la même proposition ne revienne pas la semaine suivante.

Une validation que personne ne lit n'est pas une sécurité. C'est une signature en blanc.

Le piège de la validation systématique

Faire valider tout par un humain semble prudent. En pratique, c'est le plus sûr moyen de tuer le projet : la file d'attente s'allonge, la personne qui valide devient le nouveau goulot d'étranglement, et au bout de trois semaines elle valide tout sans regarder. Le gain disparaît, le risque revient.

Une bonne architecture réserve donc l'attention humaine aux cas qui la méritent : les montants élevés, les clients sensibles, les situations que le modèle signale lui-même comme incertaines, et un échantillon aléatoire pour vérifier que le reste tient toujours.

Trois régimes, pas deux

  • Automatique. La machine agit, l'humain contrôle a posteriori par échantillon. Réservé aux étapes réversibles et internes.
  • Sous validation. La machine prépare, l'humain valide avant que l'action parte. Le régime par défaut sur tout ce qui sort de l'entreprise.
  • Assisté. L'humain fait le travail, la machine lui fournit la matière, le contexte et un brouillon. Le bon régime pour les situations rares, complexes ou relationnelles.

Un process complet mélange presque toujours les trois. C'est d'ailleurs un bon test : un prestataire qui applique le même régime à toutes les étapes n'a pas fait l'analyse.

Le régime évolue avec la preuve

Une étape ne reste pas figée dans son régime. Quand une étape sous validation affiche plusieurs centaines de propositions acceptées sans correction, elle peut passer en automatique avec contrôle par échantillon. À l'inverse, une étape automatique qui produit des corrections répétées redescend sous validation le jour même. Ce déplacement se décide sur des chiffres, pas sur une impression, et c'est une part importante du travail d'un orchestrateur.