La première réunion d'un audit ressemble souvent à la précédente. On nous montre un schéma des applications, avec des flèches entre les briques. Le schéma est juste. Il n'a pas grand-chose à voir avec le travail réel.
Ce qui circule dans une organisation, ce sont des fichiers. Un export hebdomadaire envoyé par courrier, un classeur partagé que plusieurs personnes modifient en même temps, une extraction faite à la main parce que l'écran officiel ne sort pas la bonne colonne. Ces fichiers sont l'architecture réelle, et ils ne figurent sur aucun schéma.
Ce qu'un fichier raconte
Un export récupéré tel quel se lit vite. Sa fréquence indique à quel rythme la décision a vraiment besoin d'être prise. Ses colonnes ajoutées à la main montrent ce que le système ne fournit pas. Ses doublons désignent l'endroit où deux services ont arrêté de se parler.
Voilà pourquoi nous réclamons les fichiers avant les accès. Pas des spécifications, pas des captures d'écran : les fichiers eux-mêmes, dans l'état où quelqu'un les ouvre le lundi matin.
Ce que ça donne pour la suite
Cette entrée en matière produit trois choses tout de suite : un inventaire des données réellement disponibles, par opposition à celles que le système est censé produire ; une liste de tâches refaites à la main chaque semaine, que l'on peut chiffrer en heures ; et les endroits où la même information existe en deux versions qui ont divergé.
Ces éléments suffisent à écrire un rapport utile, même si la mission s'arrête là. C'est le test que nous nous imposons à chaque étape : rendre quelque chose d'exploitable, y compris si la suite n'a jamais lieu.
La limite de l'exercice
Les fichiers ne disent pas tout. Ils ne disent pas pourquoi une règle existe, ni qui l'a décidée, ni si elle a encore un sens aujourd'hui. Cette partie se récupère en parlant aux gens qui font le travail, pas à ceux qui le décrivent. Les écarts entre ce qui est décrit et ce qui est fait indiquent où regarder.
Tous les articles