Audit du parc de modules d’une boutique

Pourquoi cet inventaire n’existe presque jamais

Personne ne tient la liste des modules d’une boutique, parce que chacun a été ajouté pour une bonne raison à un moment donné, et que cette raison n’est écrite nulle part. Deux ans plus tard, plus personne ne sait si le module de bandeau promotionnel sert encore, ni pourquoi il y a trois modules de statistiques.

Ce flou a un coût direct. Il empêche de décider ce qu’on met à jour, il rend chaque montée de version plus risquée qu’elle ne devrait l’être, et il fait porter le diagnostic de chaque panne sur l’ensemble du parc plutôt que sur un suspect identifié. L’audit ne répare rien par lui-même : il rend les décisions suivantes possibles.

Ce que je remets à la fin

Une liste, classée par décision plutôt que par ordre alphabétique : ce qui peut être retiré sans conséquence, ce qui doit être mis à jour rapidement, ce qui doit être remplacé parce que son éditeur ne suit plus, et ce qui reste tel quel. Pour chaque module concerné, j’indique ce qu’il faut vérifier avant de le toucher et ce qui risque de casser.

J’y ajoute deux choses qui n’étaient pas demandées mais qui sortent toujours d’un audit : les traces de modules déjà supprimés qui restent en base, et les modules installés en double sous des noms différents pour la même fonction. Ces deux points expliquent une part importante des lenteurs et des conflits constatés ensuite.

L’audit est un travail de lecture et de mesure, pas d’intervention. Je ne retire rien pendant l’audit : la boutique reste exactement dans l’état où elle était, et les décisions se prennent après, avec la liste sous les yeux.