Comment auditer une architecture logicielle avant une refonte

Pourquoi auditer avant, et pas pendant

Une refonte engage l’équipe pour des mois, gèle la roadmap produit et reproduit, dans un cas sur deux, les problèmes qu’elle prétendait résoudre, parce que ces problèmes n’étaient pas là où on croyait.

L’audit ne sert pas à valider une décision déjà prise. Il sert à savoir quel est vraiment le problème, et il doit pouvoir conclure qu’il n’y a pas lieu de refondre. Un audit qui ne peut aboutir qu’à « oui, refondez » n’est pas un audit.

Étape 1 : cartographier le système réel

Pas le schéma de la documentation : le système tel qu’il tourne. Les deux divergent toujours, et l’écart est lui-même une information.

• Les composants déployés, et par quoi ils sont appelés en production.
• Les flux de données entre eux, y compris les intégrations oubliées : un export nocturne, un script sur un serveur que personne ne redémarre.
• Les dépendances externes et ce qui se passe quand l’une est indisponible.
• Les environnements et leur degré réel de ressemblance avec la production.
• Ce qui n’est plus utilisé mais toujours déployé, souvent une part significative du système.

Un bon indicateur de départ : demandez à trois personnes de dessiner l’architecture. Si vous obtenez trois schémas différents, le problème principal est peut-être la compréhension partagée plutôt que la technique.

Étape 2 : recenser les douleurs, puis les mesurer

On commence par écouter : développeurs, produit, support, exploitation. Chacun voit une facette différente, et le support voit souvent ce que la technique ignore.

Puis on cherche la trace factuelle de chaque douleur, car c’est elle qui hiérarchise :

• Délai entre une fonctionnalité prête et sa mise en production.
• Proportion du temps passée en correctif plutôt qu’en construction.
• Fréquence et durée des incidents, et modules concernés.
• Temps nécessaire à un nouvel arrivant pour livrer sa première modification.
• Modules que tout le monde évite de toucher, et pourquoi.

L’écart entre les douleurs citées et les douleurs mesurées est régulièrement le résultat le plus utile de l’audit.

Étape 3 : localiser le coût du changement

Une architecture ne se juge pas sur son élégance mais sur ce qu’elle coûte à faire évoluer. La question centrale est donc : « quand on doit changer quelque chose, où la difficulté apparaît-elle ? »

1. Prendre les cinq dernières évolutions significatives et retracer ce qu’elles ont réellement demandé de toucher.
2. Repérer les composants modifiés systématiquement, quelle que soit la fonctionnalité : ce sont les vrais goulots.
3. Croiser avec l’historique du dépôt : les fichiers qui changent souvent et ensemble révèlent un couplage que le schéma ne montre pas.
4. Identifier ce qui empêche de déployer une partie sans déployer le tout.

Ce croisement recentre presque toujours le diagnostic sur deux ou trois zones précises, très rarement sur « toute l’architecture ».

Étape 4 : formuler des options chiffrées

Un audit qui produit une seule recommandation n’aide pas à décider. Il en faut deux ou trois, avec leurs conséquences :

Ne rien changer

Toujours à inclure, même quand c’est visiblement mauvais. Elle donne la base de comparaison : combien coûte l’inaction sur douze mois, en vélocité et en incidents.

Corriger les points de blocage

Traiter les deux ou trois zones identifiées à l’étape 3, sans toucher au reste. C’est l’option qui offre le meilleur rapport effet/risque dans la majorité des cas.

Refondre un périmètre délimité

Réécrire un composant précis derrière une interface stable, avec bascule progressive. Coûteux, mais réversible et livrable par étapes.

Refondre entièrement

À réserver aux cas où la technologie n’est plus supportée, où plus personne ne sait faire évoluer le système, ou où le modèle métier a fondamentalement changé. Il faut alors l’assumer comme un projet à part entière, avec son budget et son gel de roadmap.

Étape 5 : produire un plan qui se livre par morceaux

Un plan utile est ordonné par rapport valeur/risque et découpé en incréments dont chacun apporte un bénéfice constatable. Si le premier bénéfice arrive au bout de six mois, le plan ne survivra pas au premier changement de priorité.

• D’abord ce qui réduit le risque immédiat : sauvegardes, observabilité, tests sur les chemins critiques.
• Ensuite ce qui débloque l’équipe : environnements fiables, déploiement automatisé, découplage du goulot principal.
• Enfin les évolutions structurelles, une par une, chacune derrière une interface stable.
• À chaque étape, un critère observable : délai de livraison, nombre d’incidents, temps de build.

Ce que l’audit doit laisser derrière lui

• Un schéma du système réel, compréhensible par un non-spécialiste.
• Une liste priorisée de problèmes, chacun avec son effet mesuré.
• Les options, leurs coûts et leurs risques, y compris l’inaction.
• Un plan découpé, avec des critères de réussite.
• Les décisions écrites, pour qu’elles ne soient pas re-débattues dans trois mois.

Si l’audit ne produit qu’un rapport que personne ne sait appliquer, il a échoué. Le test : à la lecture, une équipe doit pouvoir démarrer la première étape la semaine suivante.