L'IA fait le travail. L'humain valide.

L'asymétrie qui casse les conceptions naïves.

Quand un client déploie un agent IA dans un processus assuré jusque-là par une personne, c'est le gain de vitesse qui fait passer le déploiement. Une réponse qui prenait vingt minutes prend désormais vingt secondes. Le dossier d'investissement s'écrit tout seul en comité de pilotage, et le projet avance. Le problème que nous rencontrons à la mission suivante est la version de cette histoire où le gain de vitesse était réel mais où la dérive qualité a été découverte plusieurs mois plus tard par un client ou un régulateur.

La cause racine est presque toujours la même. Le système a été conçu pour maximiser la vitesse de sortie et l'étape de revue humaine a été traitée comme une case à cocher à ajouter à la fin. Le modèle produit plus vite que n'importe quel humain ne peut lire, la file de revue grandit, le relecteur prend du retard, et en quelques semaines la réalité pratique est que plus rien n'est relu correctement. Soit la file est contournée sous la pression de livraison, soit elle devient un théâtre.

La conversation que nous avons alors avec nos clients est inconfortable parce qu'elle implique que le dossier d'origine était faux. Il ne l'était pas. Le dossier tient. Ce qui était faux, c'était l'hypothèse selon laquelle on peut conserver le gain de vitesse et ajouter la revue par-dessus sans redessiner ni l'un ni l'autre. D'après notre expérience, vous pouvez garder le gain de vitesse, mais seulement si le côté revue est conçu avec autant de soin que le côté génération.

Trois schémas de validation que nous utilisons avec nos clients.

Revue avant publication pour les contenus et communications externes.

Quand l'IA produit du matériel qui sera vu par un client, un régulateur ou le marché, le schéma de revue qui fonctionne est séquentiel. Le modèle rédige, un relecteur humain accepte, édite ou rejette, et seule la version acceptée sort du système. La tentation ici est de retirer l'humain dès que la précision a l'air bonne. Le schéma qui tient dans notre travail avec nos clients consiste à garder la porte et à réduire le temps nécessaire pour la franchir. Un relecteur équipé d'une interface bien conçue peut traiter une file plusieurs fois plus vite que l'analyste d'origine ne produisait. Le gain est réel, la porte est toujours là, et la piste d'audit est propre.

Échantillonnage de contrôle pour la production à fort volume.

Quand l'IA traite des milliers de transactions par jour, la revue avant publication n'est pas réaliste. Le schéma que nous utilisons est l'échantillonnage pondéré par le risque. Chaque sortie au-dessus d'un seuil de risque défini est relue. Un échantillon statistique du reste est relu régulièrement, et l'échantillon tourne pour que le modèle ne puisse pas apprendre quels cas seront contrôlés. L'équipe surveille un taux de rejet et un signal de dérive, pas les sorties individuelles. Bien fait, cela donne aux opérations assez de visibilité pour détecter une dégradation sans étrangler le débit. Mal fait, cela devient un tableau de bord que personne ne lit.

Portes human-in-the-loop pour les actions irréversibles.

Quand l'IA prend une action qui ne peut pas être facilement défaite, la règle que nous appliquons est ferme. Dépenser de l'argent, changer le statut d'un client, envoyer une communication réglementée, supprimer des données. Ces actions s'arrêtent et demandent confirmation. L'interface doit rendre la confirmation peu coûteuse pour que l'opérateur ne développe pas de fatigue de confirmation. Le coût d'une mauvaise action autonome dans ces catégories est presque toujours supérieur au coût d'un clic supplémentaire, et nous n'avons pas encore rencontré de client qui ait regretté d'avoir mis ces portes en place.

Concevoir l'interface de validation.

La raison la plus fréquente pour laquelle la validation échoue en production n'est pas la politique. C'est l'interface. On donne aux relecteurs un outil qui demande trois clics pour approuver, expose plus d'informations que l'œil ne peut balayer, et rend l'édition de la sortie pénible. En une semaine, le relecteur approuve par réflexe et la porte est devenue décorative.

La version qui fonctionne partage quelques traits. La sortie est présentée avec la source sous-jacente visible, pour que le relecteur puisse vérifier plutôt que deviner. Accepter ne prend qu'une touche. Rejeter ne prend qu'une touche et fait remonter une courte raison, qui retombe dans la suite d'évaluation. L'édition se fait sur place plutôt que dans un écran séparé. La file est cadencée pour qu'on ne demande pas au relecteur de traiter cent éléments en cinq minutes, moment où la fatigue prend le dessus.

Les équipes avec qui nous travaillons qui conçoivent l'interface avec le relecteur dans la salle obtiennent une porte utilisable dès le premier sprint. Celles qui la conçoivent sans le relecteur la reconstruisent souvent deux fois avant le déploiement, et nous avons rarement vu un projet récupérer ce temps.

Mesurer le coût de la validation pour qu'il ne soit pas coupé.

La validation a un coût. Temps de relecture, latence de file, infrastructure, formation. Si ce coût n'est pas mesuré, il est coupé à la première pointe de pression de livraison, généralement en silence, souvent par une équipe qui n'avait pas compris pourquoi la porte était là. La discipline que nous recommandons est d'instrumenter la validation dès le début.

Trois chiffres suffisent généralement. Temps moyen par revue, ventilé par type de sortie. Taux de rejet, surveillé pour détecter la dérive. Latence de file, surveillée par rapport au service level agreement. Quand ces trois chiffres sont visibles pour le responsable des opérations, la validation cesse d'être une taxe cachée et devient un coût piloté. Quand ils sont invisibles, la porte est à une frayeur de livraison d'être retirée.

Les clients qui mesurent ces chiffres sont ceux qui peuvent avoir une conversation sensée sur le retrait de parties de la boucle plus tard. Ceux qui ne les mesurent pas prennent la décision de retrait à l'intuition, et la regrettent en un trimestre.

Pourquoi c'est un problème de conception, pas seulement de processus.

L'instinct dans un environnement régulé est d'écrire une politique et de supposer qu'elle tiendra. D'après notre expérience, elle ne tient pas. Les gens travaillent avec le système qu'ils ont sous les yeux, pas avec le document sur l'intranet. Si le système rend la revue facile, la revue se fait. Si le système rend la revue pénible, la revue se dégrade en théâtre, quoi que dise la politique.

Quand nous discutons de cela avec des équipes dirigeantes, le cadrage qui passe est le plus simple. Les portes de validation font partie du produit, et non d'une couche par-dessus. Elles doivent être conçues, instrumentées et opérées comme n'importe quelle autre partie du produit. Les équipes qui les traitent ainsi conservent le gain de vitesse et la qualité. Celles qui les traitent comme un coût de conformité perdent l'un ou l'autre en moins d'un an.

Si un de vos déploiements produit plus vite qu'il n'est relu, la conversation utile ne porte pas sur l'ajout de relecteurs. Elle porte sur la question de savoir si l'interface de validation, la stratégie d'échantillonnage et l'instrumentation des coûts font bien leur travail. Les équipes Consulting et Tech Factory de nos bureaux de Paris, Dubaï, Singapour et Bali sont joignables depuis le formulaire ci-dessous. Nous répondons sous un jour ouvré.