Selon une étude APQC, les équipes finance des organisations matures passent en moyenne 50 % de leur temps à collecter et à fiabiliser la donnée, et seulement 17 % à l'analyser[1]. Le reste, c'est de la coordination, de la mise en forme, de la diffusion. Autrement dit : la moitié du coût d'une équipe de pilotage sert à entretenir l'existant, pas à éclairer la décision.
Ce chiffre m'a frappé quand je l'ai vu, mais il ne m'a pas surpris. J'ai passé 17 ans au CHU de Reims à hériter d'outils, à empiler des indicateurs, à maintenir des fichiers que plus personne ne comprenait vraiment. Ce que je décris ici n'est pas une bizarrerie hospitalière : c'est un phénomène universel des organisations qui pilotent depuis plus de 10 ans. Les développeurs ont un nom pour ça : la dette technique. Et cette analogie, transposée au pilotage, éclaire beaucoup de choses.
L'analogie : du code logiciel aux outils de pilotage
Le concept de dette technique a été formalisé par Ward Cunningham en 1992[2]. L'idée : quand on développe un logiciel sous contrainte de temps, on prend des raccourcis. Ces raccourcis fonctionnent à court terme, mais ils créent une « dette » qu'il faudra rembourser plus tard, sous forme de complexité accrue, de bugs, de difficulté à faire évoluer le code. Comme une dette financière, elle génère des intérêts : plus on attend pour la rembourser, plus elle coûte cher.
La même mécanique dans les outils de pilotage
Transposez ce raisonnement au pilotage et vous obtenez un diagnostic redoutablement précis de ce qui se passe dans la plupart des directions financières et contrôle de gestion. Un dirigeant demande un nouvel indicateur en urgence : on ajoute une colonne au reporting. Une réorganisation crée un nouveau périmètre : on duplique le fichier. Un éditeur sort une nouvelle fonctionnalité : on l'active sans nettoyer l'ancienne. Chaque décision est rationnelle prise isolément. Cumulées sur 5 ans, elles produisent un système incompréhensible.
Le fichier Excel à 47 onglets que personne n'ose toucher
J'ai vu, dans plusieurs organisations, ce même artefact : un fichier Excel devenu le système d'information de fait d'une fonction (RH, finance, qualité). 30, 47, parfois 60 onglets. Des formules qui pointent vers des cellules masquées. Des macros écrites par un prédécesseur parti depuis 5 ans. Des règles de gestion encodées dans des SI() imbriqués sur 8 niveaux. Personne ne peut expliquer le tout. Tout le monde a peur de modifier quoi que ce soit.
C'est l'équivalent métier d'un fichier de code de 10 000 lignes que personne n'ose toucher. Et comme en développement, ce n'est pas un problème d'incompétence des équipes — c'est un problème structurel d'accumulation.
Comment cette dette s'accumule (et pourquoi elle reste invisible)
La particularité de la dette technique du pilotage, c'est qu'elle s'accumule de manière silencieuse, par couches successives, sans qu'aucun acteur n'en soit individuellement responsable.
Le scénario classique de l'empilement
Le scénario est presque toujours le même. On hérite d'un outil existant. Un responsable demande un nouvel indicateur. Une entité a besoin d'un suivi spécifique. Une ligne s'ajoute, puis une autre. Un retraitement manuel comble une donnée manquante. Une exception devient une règle. Et au bout de quelques années, le tableau de bord ressemble davantage à un reporting exhaustif qu'à un instrument de pilotage.
Le phénomène est documenté. Une enquête PwC sur l'efficacité des fonctions finance montre que la majorité des organisations produisent plus de 100 reportings récurrents, dont une fraction significative n'est jamais consultée[3]. Mais personne ne le sait, parce que personne ne mesure.
Pourquoi personne n'ose nettoyer
Trois raisons reviennent systématiquement quand j'observe ce phénomène en mission :
- La peur de casser quelque chose : « si on supprime cet indicateur, peut-être que quelqu'un quelque part en a besoin ». Sans cartographie des usages, le doute paralyse.
- L'attachement émotionnel : ce reporting a été construit par un prédécesseur, parfois apprécié. Le supprimer ressemble à un manque de respect pour le travail accumulé.
- L'asymétrie politique : créer un indicateur, c'est valorisant. Le supprimer, c'est risqué. Personne ne se fait remarquer en réduisant le périmètre d'un reporting.
Le résultat : les couches s'empilent indéfiniment. Et la connaissance du système se concentre sur quelques personnes — souvent une seule — qui finissent par devenir un point de défaillance unique.
Le piège du « il faut demander à Pierre »
Quand un système devient trop complexe pour être documenté, sa connaissance migre vers les têtes. « Comment ça marche ? — Il faut demander à Pierre. » Pierre est le seul qui sait pourquoi telle formule existe, pourquoi tel chiffre est retraité, pourquoi cette donnée est exclue. Quand Pierre part en vacances, le reporting prend 3 jours de plus. Quand Pierre quitte l'organisation, le système devient une boîte noire que personne n'ose plus modifier.
C'est exactement le pattern qu'on retrouve en développement logiciel quand un seul développeur connaît une partie du code. Sauf qu'en pilotage, ce point de défaillance unique est rarement nommé comme un risque.
Le coût caché : ce que la dette vous coûte vraiment
La dette technique du pilotage a un coût direct, mais qui n'apparaît jamais dans le compte de résultat. Il est diffus, fragmenté, invisible, et c'est précisément ce qui le rend dangereux.
Le temps consommé par la production vs l'analyse
Reprenons le chiffre APQC évoqué en intro : 50 % du temps des équipes finance consacré à la collecte et à la fiabilisation, 17 % à l'analyse[1]. Sur une équipe de 5 ETP à 60 000 € chargés, c'est 150 000 € par an de production qui ne sert qu'à entretenir l'existant. Et ce ratio se dégrade dans les organisations qui empilent sans nettoyer : j'ai vu des situations où la production absorbait 70 % du temps disponible.
- Coût direct : temps des équipes pour produire des reportings sans usage. 30 à 50 % du budget d'une équipe de pilotage typique.
- Coût d'opportunité : analyses qui ne sont jamais faites parce que le temps est mangé par la production. C'est souvent le coût le plus élevé.
- Coût de risque : erreurs qui passent inaperçues dans la masse, décisions prises sur des chiffres faux, perte de confiance progressive dans le pilotage.
La perte de confiance dans les chiffres
Quand un système est devenu opaque, ses utilisateurs cessent de lui faire confiance. Le directeur reçoit le tableau de bord du mois et regarde d'abord si le chiffre « lui semble juste ». S'il a un doute, il appelle son équipe pour vérifier. Cette défiance, même silencieuse, ronge la valeur du pilotage. Un indicateur même élégant construit sur des données fragiles ne sera qu'un (joli) mirage.
La paralysie décisionnelle
C'est peut-être l'effet le plus pervers. Face à un système complexe et partiellement défiant, les décideurs développent deux types de comportements : soit ils décident à l'instinct et ignorent les chiffres (ce qui annule l'intérêt du pilotage), soit ils demandent toujours plus de chiffres pour se rassurer (ce qui aggrave la dette). Dans les deux cas, le pilotage perd sa fonction première : éclairer la décision sans la remplacer.
On passe plus de temps à fabriquer le thermomètre qu'à lire la température. C'est exactement le symptôme que je rencontre dans 8 missions sur 10.
Les signaux d'alerte : votre dette est-elle devenue critique ?
Comme toute dette, celle du pilotage suit une courbe : tolérable au début, insupportable à la fin. Quelques signaux permettent de positionner votre situation sur cette courbe.
- Le délai de production de votre clôture mensuelle a augmenté de plus de 30 % en 3 ans, sans changement de périmètre.
- Personne ne sait expliquer en moins de 5 minutes ce que produit le reporting X et à quoi il sert.
- La modification d'un indicateur prend plus de 2 jours de travail, contre quelques heures auparavant.
- Plus de 3 sources contiennent des chiffres légèrement différents pour la même métrique.
- Le départ d'une seule personne menacerait la continuité de la production de reportings.
- Au moins un fichier critique dépasse 30 onglets ou 50 000 lignes, et ne peut plus être ouvert sans freeze.
- Les utilisateurs commencent à reconstruire leurs propres tableaux à côté du système officiel.
- Vous n'osez plus toucher à un fichier de peur de casser quelque chose dont vous ne mesurez pas l'usage.
Le signal le plus parlant : le shadow IT du pilotage
Quand les utilisateurs commencent à reconstruire leurs propres tableaux à côté du système officiel, c'est le signal le plus inquiétant. Ce « shadow IT du pilotage » signifie que les utilisateurs ont perdu confiance dans les outils centraux et préfèrent ré-extraire les données brutes pour reconstituer leurs propres analyses. C'est le moment où la dette devient ingérable, parce qu'elle se duplique : à la dette du système central s'ajoute celle de tous les fichiers parallèles.
Comment rembourser cette dette sans tout casser
La tentation est grande, face à un système devenu illisible, de tout supprimer et de repartir de zéro. C'est presque toujours une mauvaise idée. Le coût de transition est trop élevé, le risque organisationnel important, et l'expérience montre qu'un système entièrement neuf accumule sa propre dette en quelques années si on ne change pas les pratiques.
L'approche du refactoring progressif
En développement logiciel, on appelle ça le refactoring : on améliore le code par couches successives, sans casser ce qui fonctionne. La même logique s'applique au pilotage. On garde le système en marche, on le simplifie progressivement, on supprime les couches mortes, on fusionne les redondances. Cela demande de la méthode et de la discipline, pas un grand soir.
- Inventaire : lister tous les reportings, tableaux de bord et fichiers critiques. Pour chacun, 4 colonnes : qui le produit, qui le lit, quelle décision il déclenche, combien de temps il prend à produire. Cet inventaire seul révèle généralement 30 à 50 % de reportings sans usage clair.
- Triage : classer en 4 catégories : indispensable, utile, à fusionner, à supprimer. Faire valider la classification par les utilisateurs réels (pas par les producteurs).
- Suppression contrôlée : pour les reportings classés « à supprimer », arrêter pendant 2 mois et observer. Si personne ne réclame, supprimer définitivement. Si quelqu'un réclame, comprendre l'usage réel et reclasser.
- Fusion et simplification : pour les reportings « à fusionner », identifier le plus complet et y intégrer ce qui manque dans les autres. Supprimer les sources redondantes.
- Documentation et transmission : pour les reportings restants, écrire une fiche par outil (objectif, source, règle de gestion, décision attendue). C'est ce qui empêche la dette de se reformer immédiatement.
Le piège à éviter : remplacer une dette par une autre
J'ai vu plusieurs organisations remplacer un système Excel devenu illisible par une plateforme BI moderne. Trois ans plus tard, la nouvelle plateforme contenait 200 dashboards, dont 40 utilisés. La dette s'était simplement déplacée. Le problème n'était pas l'outil ; c'était l'absence de discipline collective sur l'ajout d'indicateurs.
Le remboursement de la dette technique du pilotage est moins un projet outil qu'un changement de pratique. C'est pourquoi un diagnostic préalable est souvent indispensable : il permet de dimensionner le chantier, mais surtout de poser les règles qui éviteront que la dette se reforme.
Le rôle de la technologie : levier ou amplificateur de la dette ?
La question revient systématiquement : « Est-ce qu'un nouvel outil va régler le problème ? » La réponse honnête est : ça dépend de comment on s'en sert.
L'outil ne crée pas la méthode
Une plateforme BI moderne, un ERP intégré, un cube OLAP : ces outils sont puissants. Mais ils n'imposent pas de discipline. Si vous y déversez votre désordre actuel, vous obtenez un désordre rapide et joliment graphique. L'automatisation d'un mauvais processus produit un mauvais processus rapide. C'est une règle qui s'applique à tous les chantiers de digitalisation que j'ai accompagnés.
L'IA comme accélérateur du diagnostic
En revanche, l'intelligence artificielle est un excellent outil pour la phase d'inventaire et de cartographie. Cartographier automatiquement les dépendances entre fichiers, détecter les doublons sémantiques entre indicateurs, analyser les formules d'un classeur de 47 onglets pour en extraire les règles de gestion réelles : ce sont des tâches qui prenaient des semaines à un humain et qui se font en quelques heures avec un assistant IA bien instruit.
Mais l'IA ne tranche pas à votre place quel indicateur supprimer. Cette décision reste politique : elle suppose de comprendre les usages réels, les enjeux des utilisateurs, l'histoire des outils. La technologie est un amplificateur, pas un correcteur. Elle accélère le diagnostic ; elle n'arbitre pas.
Le cas effectivo : refus assumé d'empiler
Quand j'ai conçu effectivo, j'ai pris une décision dès le départ : ne pas chercher à couvrir tous les cas d'usage, ne pas multiplier les options paramétrables, ne pas accepter chaque demande de personnalisation. L'idée : partir avec un périmètre étroit et discipliné, et l'élargir uniquement quand un usage est validé par plusieurs utilisateurs et qu'il ne peut pas être couvert par les fonctions existantes.
C'est une décision contraignante côté produit, mais c'est ce qui permet de garder un outil compréhensible dans la durée. Et c'est aussi la raison pour laquelle un cadrage stratégique data commence souvent par identifier ce qu'on choisit de ne PAS couvrir, avant de décider ce qu'on va construire.
Questions fréquentes
Combien de temps faut-il pour rembourser la dette technique d'un pilotage ?
Comptez entre 6 et 18 mois pour une PME ou ETI, en mode itératif. La première vague (audit du portefeuille de reportings, suppression des doublons, fusion des indicateurs redondants) prend 2 à 3 mois et libère déjà 20 à 30 % de temps. Les vagues suivantes sont plus longues car elles touchent à des outils plus profondément ancrés dans les processus, et nécessitent un dialogue avec les utilisateurs pour ne pas casser ce qui fonctionne.
Faut-il tout supprimer et repartir de zéro ?
Très rarement. Repartir de zéro a un coût de transition élevé et un risque organisationnel important. La méthode du remboursement progressif (refactoring par couches successives) est plus sûre. On supprime les couches mortes, on fusionne les redondances, on reconstruit ce qui mérite de l'être. Repartir de zéro n'a de sens que si l'outil existant est devenu intransmissible et que personne ne sait plus comment il fonctionne — c'est plus rare qu'on ne le pense.
Comment convaincre la direction de prioriser ce chantier ?
En chiffrant le coût caché. Comptez 30 à 50 % du temps des équipes finance et contrôle de gestion consacré à la production de reportings (vs analyse). Sur une équipe de 5 ETP à 60 000 € chargés, c'est 90 000 à 150 000 € par an de production qui ne sert qu'à entretenir la dette. Présentez ce chiffre à côté du coût d'un chantier de simplification : l'arbitrage devient évident. Le piège est de présenter le chantier comme « du nettoyage » : c'est un investissement à ROI mesurable.
Quel est le premier outil à utiliser pour démarrer ?
Un simple tableur, partagé avec les équipes, qui liste tous les reportings produits avec 4 colonnes : qui le produit, qui le lit, quelle décision il déclenche, combien de temps il prend à produire. Cet inventaire seul révèle généralement 30 à 50 % de reportings sans usage clair. Pas besoin d'outil sophistiqué pour démarrer ; juste de la rigueur et un peu d'honnêteté collective.
Est-ce que l'IA peut accélérer le remboursement de cette dette ?
Oui pour le diagnostic (cartographie automatique des dépendances entre fichiers, détection des doublons, analyse des formules), non pour la décision. L'IA accélère l'inventaire et la classification ; elle ne tranche pas à votre place quel indicateur supprimer. Et attention : automatiser un processus défaillant ne fait que produire un processus défaillant rapide. La technologie amplifie ce qui est déjà bon ; elle ne corrige pas ce qui est mauvais.
- APQC, Open Standards Benchmarking — Finance Function Effectiveness, 2024. Étude de référence sur la répartition du temps des équipes finance entre collecte, contrôle et analyse.
- Cunningham W., The WyCash Portfolio Management System, OOPSLA 1992. Texte fondateur de la métaphore de la dette technique en développement logiciel.
- PwC, Finance Effectiveness Benchmark Report, 2024. Comparaison des fonctions finance sur leur productivité, leur outillage et la maturité de leurs processus.
- Hackett Group, The CFO Agenda — Building a Digital Finance Function, 2024. Sur les leviers de productivité des fonctions finance et l'impact de la dette des outils.
- Jerry Z. Muller, The Tyranny of Metrics, Princeton University Press, 2018. Lecture indispensable sur le danger de l'accumulation d'indicateurs déconnectés des décisions.
- Gartner, Future of Finance — From Reporting to Insight, 2024. Sur l'évolution des fonctions finance vers l'analyse et la simplification du portefeuille de reportings.
- McKinsey & Company, The new finance organization, 2023. Sur l'industrialisation de la production financière et la maîtrise de la complexité accumulée.
Et si on évaluait la dette technique de votre pilotage ?
Identifions ensemble les reportings qui méritent d'être conservés, ceux à fusionner et ceux à supprimer. Un diagnostic structuré pour libérer 20 à 30 % du temps de votre équipe de pilotage.
Échanger sur mon projet