Comment auditer une architecture logicielle

Comment auditer une architecture logicielle : méthode terrain pour évaluer code, données, sécurité et exploitation sans perdre des semaines en production.

Un audit devient nécessaire quand personne ne sait répondre simplement à une question pourtant basique : « Que se passe-t-il si ce service tombe vendredi soir ? » Si la réponse dépend d’un ancien prestataire, d’un développeur parti depuis deux ans ou d’une lecture anxieuse du code, le problème n’est plus théorique. Il faut savoir comment auditer une architecture logicielle sans produire un rapport décoratif de cinquante pages.

Le but n’est pas de juger les choix passés avec le recul. Une architecture est toujours le résultat d’un contexte : budget, délai, équipe, produit encore incertain, intégrations imposées. L’audit sert à établir ce qui est vrai maintenant, à mesurer le risque de production et à décider quoi traiter dans le bon ordre.

Commencer par le risque métier, pas par le framework

Une revue qui commence par « quelle version de Node, PHP ou Python utilisez-vous ? » rate souvent l’essentiel. La première question est plutôt : quelles activités de l’entreprise dépendent de ce système ? Prise de commande, facturation, accès client, logistique, reporting, opérations internes : les conséquences d’une panne ne sont pas les mêmes.

Un e-commerce peut accepter qu’un outil de reporting soit indisponible une demi-journée. Il ne peut pas accepter de perdre des commandes ni d’envoyer deux fois le même paiement. Un SaaS B2B peut survivre à une interface un peu lente, mais pas à une fuite de données clients ou à une incapacité à restaurer son environnement.

Cette étape permet de définir les exigences réelles : disponibilité attendue, délai de reprise acceptable, perte de données tolérable, contraintes réglementaires, fenêtres de maintenance et dépendances externes. Sans ce cadre, l’audit se transforme en inventaire technique sans hiérarchie.

Cartographier ce qui existe réellement

Les diagrammes existants sont utiles, à condition de les considérer comme des hypothèses. Dans les PME, ils décrivent souvent une version antérieure du système. La réalité se trouve dans les dépôts de code, les variables d’environnement, les pipelines de déploiement, les comptes cloud, les bases de données et les outils SaaS connectés au produit.

La cartographie doit identifier les composants qui exécutent du code, stockent des données ou constituent un point de passage critique. Elle couvre généralement l’application web, les API, les workers asynchrones, les bases de données, les stockages de fichiers, les files de messages, les services d’authentification, les services de paiement, l’email transactionnel et les outils d’observabilité.

Le point important est le sens des flux. Qui appelle quoi ? Quelles données sortent du système ? Quels appels sont synchrones ? Quelle dépendance peut bloquer une transaction client ? Une application monolithique n’est pas nécessairement un problème. Un monolithe bien compris, testable et déployable vaut souvent mieux qu’une collection de microservices fragiles, sans supervision ni propriétaire clair.

Les accès sont une partie de l’architecture

L’inventaire doit aussi inclure les accès. Qui possède le domaine, le compte cloud, les certificats, la base de données de production, le registre d’images et les clés des services externes ? Une société peut avoir un code correct tout en restant exposée si un seul ancien collaborateur détient les identifiants critiques.

C’est un risque opérationnel, pas une formalité administrative. La propriété des comptes, la gestion des secrets et la révocation des accès doivent être vérifiables. Si les secrets circulent dans Slack, dans des fichiers \.env\ non chiffrés ou dans le code source, le problème mérite un traitement rapide.

Lire le code avant de recommander une réécriture

Un audit sérieux ne se limite pas aux outils de scan ni à une réunion d’architecture. Il faut lire le code qui porte les règles métier sensibles : création de commande, droits d’accès, calcul de prix, facturation, synchronisation avec un ERP, import de données ou traitements planifiés.

L’objectif est d’identifier les zones où une modification simple peut produire un effet imprévisible. Les signaux classiques sont les suivants : logique métier dupliquée dans plusieurs endpoints, accès directs à la base sans règle commune, exceptions absorbées silencieusement, traitements longs dans une requête HTTP, absence de transactions et dépendances externes appelées sans délai d’expiration ni stratégie de reprise.

Il faut aussi distinguer dette technique et risque immédiat. Un code ancien, peu élégant ou sans les conventions du moment n’exige pas automatiquement une migration. En revanche, une zone de code que personne n’ose modifier, sans tests et sans possibilité de retour arrière, ralentit directement l’entreprise. C’est celle-là qu’il faut isoler et sécuriser.

Les tests doivent être évalués pour ce qu’ils protègent réellement. Un taux de couverture élevé ne garantit pas qu’un paiement soit correct ou qu’une migration de schéma soit réversible. On cherche surtout des tests sur les parcours critiques, des contrôles d’intégration avec les dépendances majeures et une capacité à détecter une régression avant la production.

Auditer les données et les intégrations

Les données constituent souvent le passif le plus coûteux du système. L’audit vérifie où elles résident, qui peut les lire, combien de temps elles sont conservées et comment elles sont restaurées. Une sauvegarde n’est pas une stratégie de reprise tant qu’une restauration n’a pas été testée dans un environnement séparé.

Il faut examiner les migrations de base de données, la cohérence des contraintes, les suppressions, les exports et les synchronisations. Lorsqu’un système échange des données avec Stripe, QuickBooks, Shopify, HubSpot, un ERP ou une plateforme logistique, la question centrale est l’idempotence : que se passe-t-il si le même événement est reçu deux fois ?

Les intégrations doivent également pouvoir échouer proprement. Une API externe finit toujours par ralentir, retourner une erreur ou modifier un comportement. Une architecture saine pose des délais d’attente, journalise les erreurs avec un identifiant exploitable, évite les doublons et fournit un mécanisme de reprise contrôlé.

Évaluer les composants IA avec la même discipline

Ajouter un modèle de langage à un produit ne réduit pas les exigences d’architecture. Cela ajoute des variables : coût par requête, confidentialité des prompts, qualité des sorties, dépendance à un fournisseur, délai de réponse et traçabilité des décisions.

Un audit doit vérifier quelles données sont envoyées au modèle, si des informations sensibles peuvent y apparaître et si une réponse erronée peut déclencher une action métier. Pour un assistant interne, une réponse approximative est parfois acceptable. Pour une extraction comptable ou une décision automatisée qui affecte un client, il faut des garde-fous, une validation humaine ou des règles déterministes autour du modèle.

Vérifier l’exploitation, là où les incidents se produisent

Beaucoup d’architectures paraissent cohérentes sur un schéma et deviennent fragiles en production. L’audit doit donc couvrir le chemin complet du déploiement : création d’un changement, revue, tests, livraison, migration de données, surveillance et retour arrière.

Les éléments suivants méritent une vérification explicite :

la séparation des environnements de développement, test et production ;
la reproductibilité des déploiements et de l’infrastructure ;
les sauvegardes, leur rétention et une restauration déjà exercée ;
la supervision des erreurs, de la disponibilité et des ressources ;
les procédures d’incident et les responsabilités de décision.

L’absence de Kubernetes n’est pas un défaut. L’absence de logs consultables, d’alertes utiles et de procédure de restauration en est un. Pour une TPE ou PME, la bonne architecture est rarement la plus sophistiquée. C’est celle que l’équipe peut comprendre, opérer et réparer sous pression.

Les coûts font aussi partie du diagnostic. Une facture cloud qui augmente sans métrique, un worker surdimensionné ou des requêtes coûteuses sur une base mal indexée peuvent dégrader la marge avant même de provoquer une panne. L’audit relie donc les ressources consommées aux usages réels, plutôt que de traiter l’infrastructure comme une dépense fixe incompréhensible.

Produire des décisions, pas seulement des constats

Le livrable doit séparer clairement les faits observés, les risques et les recommandations. Chaque recommandation utile indique un niveau de priorité, le scénario de risque, l’effort probable, les dépendances et le résultat attendu. « Moderniser la stack » n’est pas une recommandation. « Tester la restauration PostgreSQL, documenter le runbook et supprimer l’accès partagé au compte cloud » en est une.

Une priorisation simple fonctionne bien : traiter d’abord ce qui peut interrompre le chiffre d’affaires, exposer des données ou rendre le système irréparable. Viennent ensuite les goulots d’étranglement qui ralentissent les livraisons. Les améliorations de confort, de style ou de technologie peuvent attendre si elles ne changent ni le risque ni la capacité d’exécution.

Il faut enfin assumer les arbitrages. Renforcer les tests ralentira parfois une livraison à court terme. Remplacer une dépendance obsolète peut introduire un risque transitoire. Garder un composant vieillissant peut être raisonnable s’il est isolé, surveillé et peu modifié. Le rôle de l’audit est de rendre ces choix explicites, avec un coût et une conséquence connus.

Une bonne architecture ne se reconnaît pas à son vocabulaire. Elle se reconnaît au jour où une personne senior peut reprendre le système, comprendre ses flux, déployer un correctif et restaurer les données sans dépendre d’une mémoire individuelle. C’est moins spectaculaire qu’une refonte. C’est aussi ce qui permet à l’entreprise de continuer à travailler.