Architecture Data
Le rapport qui prenait quinze jours
Dans la plupart des organisations, une équipe passe deux semaines par mois à produire un rapport que personne ne remet en question, que personne ne pourrait reconstruire de zéro, et dont personne ne se préoccupe jusqu'au départ de la personne qui le fabrique. Ce n'est pas un problème de ressources. C'est un problème d'architecture — avec un coût réel rarement calculé.
La clôture mensuelle qui mobilise trois personnes pendant quatre jours. Le reporting de pilotage hebdomadaire assemblé à la main depuis six systèmes différents dans un tableur maintenu par un analyste qui fait ça depuis trois ans. Le rapport investisseurs trimestriel construit sur des macros rédigées il y a des années que personne ne comprend vraiment, maintenu par la mémoire institutionnelle et la réticence collective à y toucher. La plupart des organisations en ont au moins un. Beaucoup en ont plusieurs.
À quoi ressemble le processus en réalité
Export du système A. Collage dans le modèle maître. Lancement de la macro. Correction des erreurs introduites par la macro. Rapprochement avec le système B. Identification des douze lignes qui ne se réconcilieront jamais correctement et traitement manuel, comme toujours. Mise en forme. Envoi à quatorze destinataires. Attente. Réception de quatre retours avec corrections. Reconstruction. Renvoi de la version corrigée. Ce n'est pas la description d'une organisation particulièrement dysfonctionnelle. C'est une description assez fidèle du fonctionnement du reporting financier et opérationnel dans la plupart des entreprises de taille intermédiaire.
Pourquoi ça persiste
La personne qui gère le processus l'a accepté comme normal — ça a toujours fonctionné ainsi. Son manager ne sait pas ce que le processus implique réellement, seulement qu'il délivre. Personne n'a calculé le coût total. Et la connaissance institutionnelle encodée dans le tableur rend le changement plus risqué que la continuité. Le résultat : un processus de reporting coûteux, fragile, structurellement non auditable, et entièrement dépendant d'une seule personne qui continue de se lever le matin.
Le coût que personne ne calcule
L'arithmétique est simple. Trois personnes, quatre jours par mois, douze mois : environ 144 jours-personne par an alloués à un processus qui pourrait être automatisé. Sans compter le coût décisionnel — direction et investisseurs recevant des informations quatorze jours après la clôture de la période, prenant des décisions sur des données structurellement périmées. Ajoutez le coût risque (une démission suffit pour un blackout de reporting) et le coût conformité dans les environnements réglementés où la réconciliation manuelle ne satisfait plus les exigences modernes de piste d'audit, et le vrai coût du rapport de quinze jours est rarement celui que quiconque a estimé en décidant de continuer à le faire tourner.
À quoi ressemble l'architecture après
L'équivalent automatisé s'alimente directement depuis les systèmes opérationnels via des extractions planifiées ou des APIs. Une couche de transformation — versionnée, documentée, testable — applique la logique métier qui était auparavant enfouie dans des macros. La couche de sortie se met à jour selon un planning défini, avec les exceptions remontées pour validation humaine. La production courante ne nécessite aucune intervention humaine. Le rapport qui prenait quinze jours prend quatre heures. Puis trente minutes. Puis il tourne la nuit et les chiffres sont disponibles à l'arrivée des équipes le matin.
La question de gouvernance que l'automatisation fait remonter
Quand on remplace un processus de reporting manuel par un processus automatisé, chaque décision implicite — la règle d'arrondi, le cas particulier des contrats résiliés, la définition de "client actif" — doit être rendue explicite. C'est inconfortable. C'est aussi tout l'intérêt. Le rapport manuel cachait des décisions de conception qui auraient dû être documentées dès le départ. L'automatisation ne crée pas ces décisions. Elle les révèle, et force l'organisation à les assumer plutôt qu'à les laisser encodées dans des formules que personne n'a relues depuis quatre ans.
La règle applicable à tout processus de reporting
Toute transformation de données qu'un humain répète sur le même calendrier, sur les mêmes données, pour produire le même format de sortie, doit être automatisée. Si elle ne peut pas l'être en l'état, l'architecture data doit évoluer jusqu'à ce que ce soit possible. Le reporting manuel est une dette technique mesurée en jours-personne plutôt qu'en lignes de code. Elle s'accumule au même rythme, avec les mêmes conséquences, et devient progressivement plus difficile à traiter plus longtemps elle est traitée comme une contrainte permanente plutôt qu'un problème de conception à résoudre.
Par où commencer
Trouvez le rapport qui prend le plus longtemps à produire. Documentez chaque étape, chaque source de données, chaque intervention manuelle. Cette liste est votre périmètre de projet. Dans la plupart des cas, une intervention ciblée de quatre à six semaines suffit à passer du rapport de quinze jours au traitement nocturne. La contrainte est presque rarement technique. C'est la volonté de rendre explicites les décisions que le tableur prenait discrètement depuis des années.