Cette semaine, j'ai rédigé un document de transfert. Rien d'exceptionnel sur le papier : je pars pour une absence prolongée, quelqu'un va reprendre le pilotage pendant ce temps, il faut lui laisser de quoi tenir. Je pensais que ce serait un exercice de rangement : lister les process, pointer vers les bons dashboards, expliquer où sont les fichiers. Une formalité.

Ça n'en a pas été une.

Ce que je pensais transmettre

Sur le papier, j'ai des KPI, un planning, des priorités. Des tableaux de bord que je regarde chaque semaine, des chiffres que je cite en réunion, des seuils que je surveille, un calendrier des échéances à venir, une idée claire de ce qui compte le plus. Je me disais que le document de transfert allait surtout consister à donner les accès et à dérouler tout ça : "regarde ce tableau, voici le planning, voici l'ordre des priorités, tu sauras où on en est."

Ce que j'ai vraiment dû expliciter

Sauf qu'au moment d'écrire noir sur blanc "voici comment interpréter ce chiffre", je me suis heurtée à un mur. Pas parce que le chiffre était mal calculé. Parce qu'il me manquait, à côté du chiffre, tout ce que je savais sans l'avoir jamais écrit : ce qui est normal, ce qui doit alerter, ce qu'il faut croiser avec quoi avant de tirer une conclusion, quelle décision prendre selon la variation observée. Rien de tout ça n'était dans le tableau de bord. C'était dans ma tête, sous forme d'habitude, de contexte accumulé, de réflexe.

Et le même mur est réapparu partout ailleurs dans le document. Sur le planning, écrire les échéances ne suffisait pas : il fallait aussi dire lesquelles peuvent glisser sans dommage et lesquelles ne peuvent pas, ce que je sais sans y réfléchir mais que je n'avais jamais eu besoin d'écrire. Sur les priorités, ce n'était pas la liste des tâches qui manquait, c'était l'arbitrage entre elles : pourquoi telle chose passe avant telle autre, un raisonnement que je fais instinctivement mais que personne d'autre ne peut deviner à ma place. Même chose pour qui contacter selon le type de situation rencontrée, une information que je n'avais jamais eu besoin d'écrire parce que je savais instinctivement vers qui me tourner. C'est la même logique tacite non écrite partout : les chiffres, le planning, les priorités, les contacts, chacun affichait une apparence de clarté qui cachait en réalité un mode d'emploi resté uniquement dans ma tête.

Un dashboard qui affiche un chiffre sans le mode d'emploi qui va avec n'est pas un outil de pilotage. C'est une photo. Et une photo, seule, ne dit à personne quoi faire.

Ce n'est pas propre à mon cas. En ingénierie logicielle, on donne un nom à ce risque : le "bus factor", le nombre minimum de personnes dont l'indisponibilité soudaine suffirait à mettre un projet à l'arrêt, parce que la connaissance critique n'a jamais été partagée ailleurs que dans leur tête. Une étude interne citée par Atlassian montre que les équipes qui documentent activement subissent 60% de perturbations en moins au départ d'un collaborateur que celles qui reposent sur la connaissance tribale. Le pilotage par KPI n'échappe pas à cette logique : un chiffre sans documentation attachée, c'est une dépendance en attente de se révéler.

Le vrai test d'un KPI : est-ce qu'il tient sans moi dans la pièce

C'est là que la définition a basculé pour moi. Un indicateur n'est un KPI que si une autre personne, sans mon contexte tacite, peut le lire et en tirer une décision correcte. Pas "je consulte ce chiffre chaque semaine", n'importe qui peut consulter un chiffre. Le vrai test, c'est : est-ce que quelqu'un d'autre peut agir avec, sans moi pour le traduire.

Rédiger un document de transfert avant une absence est probablement le test le plus honnête qu'on puisse faire subir à son propre pilotage. On ne peut pas tricher. On ne peut pas se dire "je clarifierai plus tard, à l'usage", parce qu'il n'y aura pas de "plus tard, avec moi à côté". Soit c'est écrit et ça tient, soit ça ne l'est pas et ça ne tient pas. Et ce test ne concerne pas que les dashboards : le même critère s'applique à un planning ou à une liste de priorités, est-ce qu'ils tiennent debout sans moi pour les commenter.

La plupart des "KPI" sont de la connaissance tacite déguisée en donnée

Ce que cet exercice révèle, plus largement, c'est à quel point on confond souvent "avoir des chiffres" et "piloter par la donnée". Alistair Croll et Ben Yoskovitz, dans Lean Analytics, distinguent les métriques de vanité (celles qui flattent mais ne guident aucune décision) des métriques actionnables (celles qui indiquent clairement quoi faire ensuite). Un chiffre affiché sur un dashboard donne l'impression de la rigueur. Mais s'il faut être la personne qui l'a construit pour savoir ce qu'il signifie vraiment, ce n'est pas de la donnée actionnable partagée, c'est de l'expertise personnelle habillée en indicateur pour se rassurer soi-même sur le sérieux du suivi.

Le problème, c'est que cette confusion ne coûte rien tant qu'on est là. Elle ne se paie qu'au moment où on part : un congé, un changement de poste, une maladie, un départ définitif. Et à ce moment-là, c'est trop tard pour la corriger tranquillement : il faut tout réexpliquer dans l'urgence, ou pire, la personne qui reprend improvise sans le savoir.

Ce que ça change dans la façon de construire un dashboard, dès le départ

La conséquence pratique, c'est qu'un KPI ne devrait jamais être conçu seul. Il devrait être conçu avec sa notice : à quoi sert-il, quel seuil déclenche quelle action, avec quel autre chiffre le croiser, qu'est-ce qui est bruit et qu'est-ce qui est signal. Pas après coup, au moment où on doit partir, en amont, au moment où on le crée. Un tableau de bord sans mode d'emploi n'est qu'à moitié construit, même s'il est visuellement parfait. La même logique vaut au-delà des seuls chiffres : un planning ou une liste de priorités mérite, lui aussi, sa notice, ce qui peut glisser, ce qui ne peut pas, pourquoi tel ordre plutôt qu'un autre.

Le résultat et la vraie leçon

Le document de transfert, une fois fini, ne ressemble plus du tout à ce que j'avais imaginé au départ. Ce n'est plus une liste d'accès et de liens. C'est, pour chaque chiffre qui compte vraiment, la traduction de ce que je faisais automatiquement dans ma tête. Un travail plus long que prévu, et un signal, pour moi, qu'une partie de mon pilotage reposait sur ma présence plus que sur mes outils.

Une chose, cependant, a confirmé la distinction plutôt qu'elle ne l'a contredite. Partout où j'avais pris l'habitude d'écrire une décision, de documenter un choix ou de classer un compte-rendu au moment où je le prenais, plutôt que de me fier à ma mémoire, le transfert a été immédiat : un lien vers le bon dossier a suffi. La différence n'était donc pas entre "donner un accès" et "tout réexpliquer", elle était entre une décision déjà rendue explicite par écrit à un moment donné et une décision restée uniquement dans ma tête. Le document de transfert n'a fait que révéler, volet par volet, laquelle de ces deux catégories dominait.

La vraie leçon n'est pas "il faut faire un bon document de transfert avant de partir". C'est plus dérangeant que ça : la qualité réelle d'un système de pilotage ne se mesure pas à combien de tableaux de bord on a construits, mais à combien d'entre eux survivraient à notre absence. Le reste, aussi propre soit-il visuellement, n'est qu'une dépendance qu'on n'a pas encore eu l'occasion de voir échouer.

Si tu partais demain sans pouvoir répondre à une seule question, combien de tes 'KPI' survivraient sans toi ?

Localisation

Le Mans, France

Contacts

ashlyne@qiveo.co

Qiveo
Je vois ce que les équipes ont normalisé. Je le questionne. J'écris ce que ça donne.

© 2026 Qiveo