Observabilité du processus : ce que vous devez voir un mois après le lancement

Dans notre générateur de propositions commerciales, nous avons dès le départ suivi deux types de statistiques : la performance de chaque commercial, et les types de propositions qui suscitaient le plus de demande. C'était la partie la plus simple à mettre en œuvre du service — et la seule qui permettait de répondre à la question « est-ce que ça marche ? » par des chiffres plutôt que par des impressions.

Un mois après le lancement d'un processus, quel qu'il soit, un dirigeant pose toujours la même question. Si la réponse tient en « l'équipe est contente » et « c'est plus confortable », ce n'est pas un processus qui a été lancé, mais une démonstration. L'observabilité du processus (la propriété d'un système qui permet de reconstituer son état interne à partir de données externes) se construit avant le lancement — elle ne s'ajoute presque jamais après coup.

Les trois chiffres dont vous ne pouvez pas vous passer

Ce socle reste volontairement restreint, non par économie, mais par expérience : chaque indicateur supplémentaire exige un responsable et engendre des discussions qui ne débouchent sur aucune décision. Les trois indicateurs ci-dessous répondent chacun à une question différente et ne se substituent pas l'un à l'autre.

Le nombre de scénarios aboutis. Ni le nombre d'utilisateurs, ni le nombre de connexions, mais le nombre de cas où le processus a été mené du début à la fin. C'est le seul indicateur qui distingue le travail réel de la simple activité : un utilisateur peut se connecter chaque jour sans jamais mener un seul scénario à son terme.

Le taux de défaillance. Une défaillance survient lorsque le travail est formellement accompli, mais que le résultat ne progresse pas plus loin : le document n'est pas envoyé, la demande n'est pas attribuée, la réponse n'est pas enregistrée. Ce taux baisse quand on corrige le processus et augmente sous la charge — il indique si le processus tient réellement, ou s'il ne fonctionne que grâce aux efforts des équipes.

Le temps médian entre le début et le résultat. Le médian, pas la moyenne : la distribution comporte presque toujours une longue traîne, et la moyenne ne décrit alors plus aucun cas réel. Le temps médian répond à la question « combien de temps cela prend-il habituellement ? », la traîne répond à la question « qu'est-ce qui dysfonctionne ? ».

La troisième colonne est essentielle : l'indicateur de substitution paraît presque toujours plausible, et il embellit toujours la réalité. Le nombre d'utilisateurs actifs augmente par simple curiosité, les sollicitations du support diminuent dès que les gens cessent d'attendre de l'aide, et le temps moyen s'améliore dès qu'on écarte les valeurs extrêmes.

Pourquoi le modèle du processus s'écarte de son exécution réelle

L'observabilité s'impose pour une autre raison : le processus tel qu'il est décrit et le processus tel qu'il se déroule réellement sont deux choses différentes, et l'écart entre les deux est mesurable. La méthode de vérification de conformité, qui confronte les journaux d'événements au modèle formel, existe depuis longtemps et révèle des écarts étonnamment importants.

Cette étude a près de vingt ans et porte sur le secteur public néerlandais — c'est sa limite. La méthode, elle, demeure une base de l'analyse des processus, et le résultat se reproduit dans toute organisation où quelqu'un prend la peine de confronter la procédure décrite aux journaux réels. La conclusion pratique : un écart pouvant atteindre la moitié des cas n'a rien d'une anomalie — c'est la norme pour un processus dont personne ne surveille l'exécution.

L'écart de résultats entre ceux qui mesurent et les autres

Le lien entre la capacité à mesurer et les résultats obtenus est le mieux documenté dans les pratiques d'ingénierie logicielle, là où les indicateurs sont standardisés et collectés depuis des années.

Je nomme la limite sans détour : ce rapport ne prouve pas que l'observabilité, à elle seule, produit ce résultat — il montre que des groupes de maturité différente se distinguent aussi par leur capacité à comptabiliser leurs propres défaillances. La causalité n'est pas établie ici, et j'utilise ces chiffres pour illustrer l'ampleur des écarts, pas comme la preuve d'un lien de cause à effet.

L'observabilité des scénarios IA : un cas particulier

Pour les scénarios reposant sur des modèles de langage, un quatrième chiffre s'ajoute aux trois indicateurs de base : la part des résultats corrigés par un humain. Sans lui, toute amélioration du prompt ou tout changement de modèle reste une question de foi.

Une précision s'impose ici, souvent perdue dans les résumés : le rapport mesure le simple fait d'avoir déployé un monitoring des systèmes d'IA, pas spécifiquement le suivi de la qualité des réponses. Il ne fournit aucun chiffre distinct sur le contrôle de la précision ni sur la part de réponses erronées. Et il s'agit d'une enquête menée par un éditeur d'outils d'observabilité — l'intérêt commercial est évident. Ce qui reste utile, c'est la tendance : près de la moitié des entreprises mettent des scénarios d'IA en production sans disposer d'un contrôle intégré sur leur comportement réel.

Pourquoi le socle d'indicateurs doit rester restreint

La tentation de tout mesurer apparaît immédiatement et l'emporte presque toujours. Un argument plus ancien que n'importe quel tableau de bord s'y oppose : un indicateur qui devient un objectif cesse d'être un indicateur — un mécanisme aujourd'hui connu sous le nom de loi de Goodhart.

Précision utile : le texte intégral de l'article est payant, et je n'ai eu accès qu'au résumé — la formule célèbre elle-même n'apparaît pas dans la partie en accès libre, bien qu'elle soit attribuée à ce travail précis. Je l'utilise comme argument conceptuel, pas comme citation littérale. La conséquence pratique est directe : tout indicateur sur lequel des personnes sont évaluées commence à orienter leur comportement — c'est pourquoi un socle de trois chiffres est plus sûr qu'un socle de quinze.

Comment construire l'observabilité avant le lancement

La quatrième décision est la seule qu'il est impossible de rattraper après coup. La mesure de référence prend une demi-journée et se réalise manuellement sur les vingt derniers résultats avant le lancement. Les entreprises qui sautent cette étape se retrouvent, un mois plus tard, à débattre non pas d'un effet réel, mais de souvenirs de la situation antérieure. C'est aussi le sujet de cette analyse sur la façon de décomposer un effet en ses composantes : sans mesure de référence, une telle décomposition est tout simplement impossible.

Les trois premières décisions paraissent techniques, mais c'est le responsable du processus qui les prend. Définir ce qui constitue une défaillance n'est pas une question d'architecture, mais une question de savoir où l'entreprise place la frontière entre un travail accompli et un travail qui ne l'est pas.

Quatre étapes à suivre avant le lancement

Les questions les plus fréquentes sur l'observabilité du processus