Un audit logiciel, souvent appelé audit d'architecture, peut signifier n'importe quoi, d'un coup d'œil rapide sur le code à une étude de plusieurs mois remplie de diagrammes. Le format importe moins que ce que vous en retirez. Un audit utile aide les décideurs à comprendre comment leur système fonctionne réellement, où il est fragile, ce qui limite leurs options et ce qu'il faut corriger en priorité.
Mettez-vous d'accord sur la question en premier
Chaque audit doit commencer par une raison claire. L'entreprise est-elle sur le point de croître rapidement ? Le système a-t-il été peu fiable ? Quelqu'un propose-t-il une refonte ? Avez-vous racheté une entreprise et hérité de ses logiciels ? Les projets prennent-ils beaucoup plus de temps qu'ils ne le devraient ?
Sans question claire, un audit se transforme en une liste de tout ce qui est intéressant au lieu de ce qui compte vraiment. Je m'entends également sur les limites dès le départ : quels systèmes sont inclus, à qui je parlerai et combien de temps nous avons. Un audit court ne peut pas tout vérifier, mais il peut être honnête sur ce qu'il a examiné ou non.
Suivez le travail réel à travers le système
Les diagrammes sont utiles, mais ils montrent comment un système était censé fonctionner, pas nécessairement comment il fonctionne aujourd'hui. Je suis donc quelques tâches quotidiennes importantes du début à la fin : une commande passée, une expédition scannée, une clôture de fin de mois. J'examine chaque système et chaque étape impliqués, et ce qui doit fonctionner pour que cette tâche réussisse.
Je regarde aussi au-delà du code. Comment les mises à jour sont-elles publiées ? Les sauvegardes sont-elles effectuées, et quelqu'un a-t-il déjà essayé d'en restaurer une ? Qui reçoit l'appel quand quelque chose tombe en panne à 2 heures du matin ? Ces habitudes quotidiennes déterminent souvent la fiabilité réelle d'un système. Un diagramme propre n'aide pas beaucoup si personne ne sait si les sauvegardes fonctionnent.
Séparez les faits des suppositions
Un bon audit est clair sur ce qu'il a trouvé, ce qu'il soupçonne et ce qu'il n'a pas pu confirmer. « Rien ne réessaie automatiquement lorsque la connexion est perdue » est un fait. « Les commandes pourraient être perdues si la connexion est perdue » est un risque probable. « Nous n'avons pas testé ce qui se passe lorsque la connexion est perdue » est une question ouverte. Garder ces éléments séparés empêche les suppositions d'être traitées comme des problèmes confirmés.
Là où je le peux, j'étaye mes conclusions avec des preuves : un test, un journal, un incident passé, le morceau de code pertinent. Là où je ne le peux pas, je le dis. Cela permet à l'entreprise de décider si elle doit creuser davantage, accepter le risque ou le corriger.
Mettez les choses par ordre d'importance
Une longue liste de problèmes n'est pas un plan. Je regroupe les problèmes selon ce qu'ils pourraient coûter à l'entreprise, leur probabilité, leur urgence et le coût de leur correction. La sécurité et l'exactitude des données côtoient la vitesse, la facilité de changement et la fiabilité. Un peu de code désordonné peut être un vrai problème, mais il compte beaucoup moins qu'un processus de sauvegarde que personne n'a jamais testé.
J'évite les systèmes de notation qui semblent précis mais ne le sont pas. Une description simple de ce qui pourrait arriver, de la gravité potentielle et de mon niveau de certitude est généralement plus utile qu'un chiffre. Je souligne également où une correction dépend d'une autre, afin que l'ordre du travail soit logique.
Terminez par des prochaines étapes claires
Un bon rapport final couvre le fonctionnement du système, les tâches quotidiennes clés, les points forts à conserver, les problèmes par ordre de priorité, les options et un plan étape par étape. Chaque recommandation doit indiquer ce qu'elle est censée accomplir et comment vous saurez qu'elle a fonctionné. « Améliorer la surveillance » est trop vague. « Recevoir une alerte si une commande n'a pas atteint l'entrepôt dans l'heure » est quelque chose que vous pouvez vérifier.
Le rapport doit également dire ce qu'il ne faut pas encore faire. Une grosse refonte ou un passage à une nouvelle plateforme peut être prématuré tant que vous ne comprenez pas vos données et la manière dont les choses ont tendance à échouer. Parfois, la conclusion la plus précieuse est « attendez, et faites d'abord ces trois petites choses ».
Ce à quoi cela revient
La valeur d'un audit réside dans les décisions qu'il vous aide à prendre. Vous ne cherchez pas un diagramme parfait ou une liste de tâches plus longue. Vous voulez une compréhension partagée de votre système, une vision honnête des risques et un chemin clair et sensé pour améliorer les choses.