Ce qu’un audit doit vous laisser

Un audit d’architecture se termine trop souvent par un document épais que personne ne relit. Le système, lui, n’a pas changé. Voici ce que je remets à la fin d’un audit, et pourquoi.

Une carte de l’existant, juste assez précise

Un schéma des composants et de leurs flux, avec pour chacun : qui l’exploite, où sont ses données, ce qui casse quand il tombe. Pas l’exhaustivité : de quoi raisonner ensemble.

Des constats mesurés

« L’application est lente » n’est pas un constat. « L’écran de recherche fait 47 requêtes SQL par affichage, dont 44 identiques » en est un. Chaque constat vient avec sa mesure et la façon de la reproduire, pour qu’on puisse vérifier qu’il a disparu.

Un ordre de correction

Je classe chaque point selon deux axes : l’effet sur le métier (incidents, coût, délais de livraison) et l’effort pour le corriger. Ce qui coûte peu et rapporte beaucoup passe en premier, même si ce n’est pas le plus intéressant techniquement.

Les décisions, écrites

Pour chaque changement de fond, un court enregistrement de décision : le contexte, les options étudiées, celle retenue et ce qu’elle implique. Dans six mois, quelqu’un demandera « pourquoi a-t-on fait ça ? ». La réponse sera là.

Une cible, et le premier pas vers elle

La cible dit où aller ; le premier pas dit quoi faire lundi. Sans ce premier pas, la cible reste un dessin.

Ce que je ne remets pas

Un classement des développeurs, une liste de reproches, ou une réécriture complète comme seule issue. Un audit sert à décider, pas à juger.