Aller au contenu

Journal · Mise en œuvre

Ce que six semaines de mode ombre révèlent vraiment

Le mode ombre consiste à laisser une règle proposer une décision sans qu'elle s'applique, puis à comparer avec ce que les humains décident réellement. Sa fonction officielle est de mesurer un taux d'accord avant d'automatiser. Sa fonction réelle, observée à chaque déploiement, est de faire apparaître l'écart entre le processus décrit et le processus pratiqué.

Mise à jour le

Publiée le · Frédéric Fontenit, Concepteur d'EchoBrain

Ce qu'il faut retenir

  • Le mode ombre mesure un taux d'accord sur des cas frais, jamais sur l'historique qui a servi à apprendre.
  • Un désaccord en mode ombre est plus souvent une règle métier non écrite qu'une erreur du système.
  • Six semaines est la durée minimale pour voir passer les cas rares qui font vraiment la décision.
  • Un taux d'accord de 95 % ne dit rien tant qu'on n'a pas regardé ce que contiennent les 5 % restants.

À quoi sert le mode ombre, officiellement#

Une étape reste bloquante : un humain décide, comme avant. En parallèle, la règle candidate écrit ce qu'elle aurait décidé. On compare, on compte, on obtient un taux d'accord sur des cas frais — c'est-à-dire des cas qui n'ont pas servi à construire la règle.

C'est la seule mesure honnête. Un taux calculé sur l'historique d'apprentissage mesure la mémoire, pas la généralisation.

Ce qu'on découvre en réalité dès la deuxième semaine#

Les premiers désaccords ne sont presque jamais des erreurs de la règle. Ce sont des règles métier que personne n'avait écrites.

Un exemple récurrent : la règle classe un message comme demande de pièce et propose la relance standard. L'humain, lui, ne relance pas — parce que ce client est en litige, information qui n'est écrite nulle part dans le système, seulement dans la tête de deux personnes.

Le mode ombre n'a pas révélé une faiblesse de l'automatisation. Il a révélé une dépendance de l'entreprise à une connaissance non documentée.

Pourquoi six semaines, et pas deux#

Deux semaines montrent le régime courant. Ce n'est pas là que se joue la décision d'automatiser : le régime courant est facile pour tout le monde, humains compris.

Ce qui compte, ce sont les cas rares — la réclamation, le dossier en litige, le client qui écrit en dehors des formes habituelles. Ils arrivent à une fréquence de quelques pour cent, ce qui veut dire qu'il faut du volume, donc du temps, pour en voir un nombre significatif.

Six semaines est un ordre de grandeur, pas une règle : sur un flux de deux cents messages par jour, quatre suffisent ; sur vingt messages par jour, il en faut douze.

D'où viennent ces observations#

Elles proviennent de deux systèmes que nous exploitons nous-mêmes : le tri de notre messagerie partagée, en usage interne, et le bot de réunion en production depuis le 14 août 2026. Nous n'affichons pas de taux d'accord chiffré ici, pour une raison simple : un chiffre issu de nos propres flux ne prédit rien des vôtres, et nous ne saurions pas le sourcer honnêtement.

Comment lire un taux d'accord#

Un taux global est presque inutilisable seul. Trois lectures le rendent exploitable :

  • Par catégorie. 95 % en moyenne peut cacher 99 % sur les demandes de pièce et 60 % sur les réclamations. La conclusion n'est pas « automatisons », c'est « automatisons les demandes de pièce ».
  • Par direction de l'écart. Une règle qui bloque à tort coûte du temps. Une règle qui laisse passer à tort coûte un client. Ce ne sont pas les mêmes 5 %.
  • Par stabilité dans le temps. Un taux qui progresse indique un apprentissage ; un taux qui oscille indique que le processus lui-même n'est pas stable.

Ce que ça implique sur le calendrier#

Le mode ombre ne s'ajoute pas à la fin d'un projet, comme une recette. Il est la phase qui produit la décision d'automatiser, étape par étape — et il commence dès que la première étape tourne en validation systématique. Le calendrier complet, avec ses jalons, est sur la page mise en œuvre.

Le résultat qu'on n'attendait pas#

Plusieurs déploiements se sont arrêtés à ce stade — non pas parce que l'automatisation échouait, mais parce que l'entreprise a découvert qu'elle voulait d'abord réécrire son processus. C'est un succès, même s'il ne ressemble pas à celui qui était prévu.

Le sujet en entier : mise en œuvre