Sur mon mandat, j’ai dû bâtir des rapports. Pis j’ai compris une affaire décourageante: le reporting promet beaucoup pis livre moyen. Pas parce que les outils sont mauvais, mais parce que le vrai problème est ailleurs que dans la technique.

Le scénario classique: je sors un beau rapport avec un chiffre. Deux gestionnaires le regardent, pis chacun le lit différemment. « Le total des ventes » — ça inclut-tu les taxes? les retours? les commandes pas encore facturées? La réunion vire sur la définition du chiffre au lieu de la décision à prendre.

Le vrai nœud, c’est la définition

flowchart TD
    A[Données sources] --> B[Requête SQL]
    B --> C[Chiffre dans le rapport]
    C --> D{Tout le monde<br/>lit pareil?}
    D -->|Non| E[Débat sur la définition]
    D -->|Oui| F[Décision]
    E -.-> A

La boucle « débat sur la définition » qui revient aux données, c’est là que le temps se perd. Un rapport, c’est juste aussi bon que l’entente sur ce que les chiffres veulent dire. Pas de définition claire, pas de confiance.

Ma petite parade de dev

J’ai pris l’habitude d’écrire, à côté de chaque chiffre important, sa définition exacte: la source, le calcul, ce qui est inclus ou exclu, pis qui en est responsable. Ça a l’air bébélà, mais ça coupe court à 80 % des chicanes. La fiche de définition vaut souvent plus que le rapport lui-même.

Ce que j’en retiens

Le reporting livre moyen parce qu’on pense que c’est un problème technique alors que c’est un problème d’entente. La requête SQL, je la réussis. C’est l’accord humain sur le sens des chiffres qui manque. Comme dev, j’ai appris à livrer pas juste le rapport, mais aussi la définition qui va avec. C’est ça qui transforme un beau tableau en outil de décision.