« Ça tourne bien » n'est pas une mesure (l'économie annoncée dans la propale non plus)
Il y a une conversation qui se répète dans toutes les entreprises qui ont automatisé quelque chose il y a plus de six mois. Quelqu'un demande si ça rapporte. Court silence. Et celui qui l'a monté répond : « ça marche, ça ne pose pas de problème ». C'est une réponse sur l'état du système, pas sur sa performance. Un flux peut passer six mois sans tomber tout en traitant la moitié des dossiers qu'avant, avec deux personnes qui relisent chaque sortie au cas où, et continuer de répondre « ça tourne bien » à la seule question qu'on lui pose.
Le deuxième joker est pire, parce qu'il ressemble à un chiffre : l'« économie estimée » de la propale. Vingt heures par mois, disait la diapo. Ce chiffre a été calculé en multipliant un volume supposé par un temps unitaire supposé, avant d'avoir la moindre donnée réelle, et sans déduire le travail neuf que l'automatisation allait créer —traiter les exceptions, réparer l'intégration du mardi, expliquer le cas bizarre au système—. C'est une hypothèse d'achat : sa place est dans la décision d'investir, pas dans l'évaluation de ce qui a été investi. Une prévision ne devient pas une mesure parce que huit mois ont passé.
La ligne de base : le seul chiffre qu'on ne peut pas relever après coup
Voici l'erreur qui ruine la mesure de la plupart des automatisations, et elle se commet avant d'écrire la première ligne du flux : personne n'a noté comment tournait le processus avant. Sans cet « avant », tout ce que tu mesures ensuite est une série de valeurs absolues orphelines. Tu traites huit cents dossiers par mois : c'est bien ? On n'en sait rien. Tu mets quatre heures par dossier : mieux ou moins bien qu'en janvier ? Personne ne s'en souvient précisément, et la mémoire d'une équipe arrondit toujours en faveur du nouveau, parce que le nouveau a été monté par quelqu'un qui est dans la salle.
La ligne de base se relève avec le processus encore à la main, pendant deux ou trois semaines, et elle ne demande aucune instrumentation : un tableur et l'engagement de le remplir. Cinq colonnes :
- Volume. Combien de dossiers entrent par semaine. Avec la saisonnalité notée s'il y en a une : août ne compte pas comme octobre.
- Temps de bout en bout. Depuis l'arrivée du dossier jusqu'à sa clôture, pas le temps pendant lequel quelqu'un tape sur un clavier. L'écart entre les deux chiffres —le temps que le dossier passe à attendre dans la bannette de quelqu'un— fait souvent la moitié du total, et c'est là que se gagnent les vraies minutes.
- Mains qui le touchent. Combien de personnes différentes interviennent. Chaque passage de relais est un endroit où le dossier s'arrête.
- Erreurs et reprises. Combien de dossiers sont à refaire. C'est la métrique que presque personne ne note et celle qui trompe le plus ensuite : si tu automatises un processus qu'on refaisait 15 % du temps et qu'on le refait toujours 15 % du temps, tu n'as pas amélioré la qualité, seulement la vitesse.
- Dossiers hors norme. Combien sortent du chemin habituel et pourquoi. C'est la colonne qui te dira, des mois plus tard, si les exceptions de ton automatisation sont celles d'avant ou de nouvelles que tu as créées toi-même.
Si tu as déjà déployé sans ligne de base —le plus probable, parce que presque personne ne la relève—, n'invente pas l'« avant ». Le reconstituer de mémoire est pire que de ne pas l'avoir, parce que ça produit un chiffre qui a l'air d'une donnée et que plus personne ne remettra en cause. L'honnêteté, c'est d'écrire « pas de ligne de base » dans le rapport, de commencer à mesurer dès aujourd'hui et de prendre le mois en cours comme point de départ : dans un trimestre, tu auras une comparaison. Et si tu es encore à temps, le bon ordre est l'inverse de celui que tout le monde suit : d'abord on mesure le processus, ensuite on décide quels processus automatiser, et seulement après on monte.
Les quatre métriques qui comptent
Quatre suffisent. Ce n'est pas du minimalisme esthétique : un tableau de bord à douze indicateurs, personne ne le regarde, et ce qu'on ne regarde pas n'existe pas. Ces quatre-là couvrent les quatre questions différentes qu'on peut poser à un système en production —combien il fait tout seul, combien il coince, combien il libère vraiment et combien il coûte— et chacune bouche un trou que les trois autres laissent ouvert.
| Métrique | Ce à quoi elle répond | À quelle fréquence on la regarde |
|---|---|---|
| Pourcentage qui passe tout seul | Sur cent dossiers qui entrent, combien ressortent clos sans que personne n'y touche. C'est la seule qui mesure quelle part du processus est vraiment automatisée. | Hebdomadaire |
| Exceptions par semaine | Combien de dossiers sortent du flux et, surtout, de quel type. Elle distingue le système qui apprend de celui qui encaisse. | Hebdomadaire |
| Temps réellement économisé vs. promis | Les heures qu'on ne fait plus, moins les heures neuves de relecture et d'entretien, face à ce que disait la propale. C'est le seul endroit où la promesse affronte la donnée. | Mensuelle |
| Coût par dossier | Tout ce que coûte le système —licences, jetons, entretien, temps humain restant— divisé par les dossiers traités. | Mensuelle |
L'ordre a son importance : les deux premières sont opérationnelles et se lisent en réunion hebdo ; les deux dernières sont métier et se portent au comité. Les mélanger produit l'effet habituel —le comité qui débat d'exceptions ponctuelles et l'équipe technique qui se bat avec un chiffre de coût qu'elle ne peut pas bouger—.
Comment compter le « passe tout seul » sans se mentir
La métrique des dossiers qui vont de bout en bout sans intervention, ce n'est pas nous qui l'avons inventée : elle vient de la finance, où l'on mesure depuis des décennies le straight-through processing —l'opération qui se dénoue sans intervention manuelle— et où ce n'est pas un indicateur de vanité, mais quelque chose qui se facture : les banques facturent des commissions sur les paiements qui ne passent pas tout seuls ou refacturent le coût de la réparation manuelle à qui leur envoie des instructions de mauvaise qualité. L'exception a un prix, et c'est pour ça que là-bas personne ne la cache.
Le piège de cette métrique, c'est le numérateur, et presque tout le monde tombe dedans : ne compte comme « passe tout seul » que le dossier qui se termine entièrement sans aucune intervention humaine. Un processus dont la saisie est automatisée mais la validation manuelle ne passe pas tout seul : il passe à moitié. Si le flux extrait les données de la facture mais que quelqu'un doit cliquer sur valider, c'est un dossier assisté, pas automatique. Et si tu calcules le pourcentage en comptant la part automatisée du parcours au lieu des dossiers clos, tu obtiens un joli 90 % qui ne correspond au ressenti de personne travaillant là —et cette dissonance entre la métrique et ce que voit l'équipe est exactement ce qui tue la crédibilité de toute la mesure—.
Les exceptions : la métrique qui dit si le système progresse ou tient juste le coup
Si tu ne pouvais regarder qu'un chiffre par semaine, regarde celui-là. Le pourcentage qui passe tout seul te dit où tu en es ; les exceptions te disent où tu vas. Et l'astuce, c'est de ne pas s'arrêter au total : vingt exceptions cette semaine et vingt la semaine dernière peuvent décrire deux situations opposées selon leur type.
Range-les dans trois paniers, qui sont aussi les trois raisons pour lesquelles un dossier sort du chemin automatique —il manque une information, l'information arrive dans un format que la machine ne comprend pas, ou le dossier tombe hors des règles qu'on avait décidé d'automatiser— :
- Donnée incomplète ou sale. Le dossier arrive sans ce qu'il faut. Ça ne se répare presque jamais dans l'automatisation : ça se répare en amont, dans le formulaire, dans le modèle de document ou chez le fournisseur qui envoie mal son fichier. Si ce panier grossit, tu as un problème d'entrée déguisé en problème d'IA.
- Dossier légitime hors des règles. Le système a raison de ne pas y toucher : c'est un retour hors délai, un montant au-dessus du plafond, un client avec des conditions particulières. Ces exceptions-là ne devraient pas tomber à zéro. C'est la conception qui fonctionne.
- Défaillance du système. L'intégration est tombée, le modèle a renvoyé quelque chose d'inutilisable, le flux s'est arrêté au milieu. Ce sont les seules qui comptent comme dette : chacune devrait avoir un nom, une cause et un correctif, et ne devrait pas apparaître deux fois. Les repérer à temps est un autre sujet, avec sa propre mécanique dans détecter les pannes des automatisations IA.
La lecture est directe. Si le panier trois baisse et que le deux se maintient, le système mûrit : tu as refermé des défaillances et ce qui reste, c'est la frontière que tu as choisi de ne pas franchir. Si le panier trois reste plat mois après mois, le système ne s'améliore pas —il encaisse, et quelqu'un paie cet encaissement en heures—. Et si le panier un grossit, le problème n'est pas dans ton automatisation : il est chez celui qui t'envoie les données.
C'est ici qu'apparaît la dépense que personne ne budgète jamais : le temps passé à gérer les exceptions. C'est du travail neuf, créé par l'automatisation, fait par quelqu'un qui ne le faisait pas avant. Si tu ne le comptes pas, ton économie est une fiction ; et si tu le comptes, tu découvres souvent que la moitié de l'économie promise est mangée par la file des dossiers hors norme. C'est ce comptage-là qui transforme une mesure en mesure.
Affiner, refaire ou retirer : le critère pour décider
Mesurer sans critère de décision écrit à l'avance, c'est collectionner des chiffres. Le critère s'écrit avant de regarder les nombres —sinon, le nombre s'interprète dans le sens de ce qui était déjà décidé— et il n'a que trois sorties.
| Ce que tu vois | Ce que ça veut dire | Ce que tu fais |
|---|---|---|
| Le pourcentage qui passe tout seul est raisonnable et les exceptions sont presque toutes du panier 2 (hors règles). | Le système fait son travail et la frontière est bien placée. | Affiner. Élargir les règles au cas par cas, uniquement si le volume de ce type justifie le travail. Des changements petits et testés. |
| Le panier 3 (défaillances) ne baisse pas en trois mois, et toujours au même endroit. | Ce n'est pas un bug : c'est un problème de conception du flux. Continuer à rustiner va durer encore un trimestre. | Refaire cette partie. Une refonte cadrée revient moins cher que douze rustines, et elle se fait avec un filet : voir tester des changements sans casser l'automatisation. |
| Le volume du processus a chuté, ou l'entretien coûte plus d'heures qu'il n'en fait gagner, ou les exceptions dépassent les dossiers automatiques plusieurs semaines d'affilée. | Ce que tu as, c'est un processus manuel avec une étape automatique qui gêne et qui continue de consommer des licences, des alertes et de l'attention. | Retirer. L'éteindre et documenter pourquoi. C'est la sortie la moins utilisée et celle qui récupère le plus d'argent. |
La troisième ligne est celle qui dérange. Éteindre une automatisation se vit comme l'aveu qu'elle ne valait rien, alors le flux reste allumé « au cas où » et vient grossir le recensement des automatisations zombies : celles qui tournent, qui coûtent et qui ne servent plus à personne. Retirer à temps n'est pas un échec du projet —c'est la seule preuve que la mesure sert à quelque chose, parce qu'une mesure qui ne peut que confirmer des décisions déjà prises n'est pas une mesure, c'est une cérémonie—.
Comment monter la mesure cette semaine
Rien de ce qui précède ne demande un nouvel outil. En un après-midi, et dans cet ordre : définis ce qui compte comme « dossier clos sans intervention » et écris-le, parce que cette définition fait 80 % de la fiabilité de tout le reste ; sors de l'historique d'exécution les dossiers des quatre dernières semaines et classe-les en passé tout seul / exception, l'exception étant étiquetée dans les trois paniers ; note pendant un mois le temps que l'équipe consacre aux exceptions et à l'entretien, même à la louche, parce que c'est le côté que personne n'a ; et construis le coût par dossier avec la facture réelle, pas avec l'estimation. Quatre chiffres, un tableur, quinze minutes chaque lundi.
Et un avertissement sur le rythme : la mesure hebdomadaire sert à opérer, pas à juger. Une mauvaise semaine ne veut rien dire —un lot bizarre est entré, il y a eu une panne, la personne qui traitait était en congés—. La décision d'affiner, de refaire ou de retirer se prend avec trois mois de données devant soi, jamais avec une courbe de sept jours. Cette discipline —regarder souvent, décider lentement— c'est d'ailleurs la moitié de l'entretien d'une automatisation : l'autre moitié, c'est de faire quelque chose de ce que la mesure te dit.
La frontière honnête : tout ceci est écrit pour qui a quelques flux et un tableur. Quand ce qu'il y a en dessous, ce sont des agents qui décident en direct, avec un coût par jeton qui s'envole sans prévenir et une qualité qui se dégrade en silence, la mesure cesse d'être une feuille hebdomadaire et devient de l'instrumentation avec traces et alertes : c'est superviser l'IA en production. Et si ce que tu veux, c'est que la ligne de base, les quatre métriques et la revue trimestrielle soient montées sur tes flux actuels et tenues par quelqu'un qui n'est pas toi, c'est l'automatisation des opérations : le chiffre, chaque mois, sans que tu aies à penser à le demander.