note · 31 août 2026 · 7 min de lecture
Exemple concret d’audit de code avant évolution
Un exemple d’audit de code avant évolution pour décider quoi stabiliser, corriger ou refondre avant de financer une nouvelle fonctionnalité en production.
Publié initialement sur https://www.rocket-services.com/exemple-audit-code-avant-evolution
Une demande d’évolution paraît souvent simple sur un ticket : ajouter un espace client, connecter un outil métier, intégrer une brique IA, modifier un tunnel de commande. Pourtant, lorsqu’une application existe déjà en production, la vraie question n’est pas « combien de jours pour développer ? ». Un exemple d’audit de code avant évolution montre pourquoi : il faut d’abord savoir ce que l’on va toucher, ce qui peut casser, et quelle dette technique mérite réellement d’être traitée.
Le but n’est pas de transformer chaque évolution en chantier de réécriture. Ce serait coûteux et rarement justifié. Le but est de prendre une décision technique qui tient face à la production, aux délais et au budget. Je lis votre code avant d’en écrire.
Pourquoi auditer avant de faire évoluer un logiciel
Une application qui tourne depuis plusieurs années accumule des décisions prises dans des contextes différents. Une dépendance a été ajoutée pour livrer vite. Un traitement métier a été dupliqué dans deux contrôleurs. Les droits utilisateurs reposent sur une convention implicite. Les sauvegardes existent, mais personne n’a vérifié une restauration récente. Rien de cela n’empêche forcément le système de fonctionner aujourd’hui.
Le problème apparaît lorsqu’une nouvelle fonctionnalité traverse ces zones fragiles. Le développement semble avancer jusqu’au moment où une modification mineure provoque des erreurs de facturation, des doublons de données ou une indisponibilité. Le coût ne vient alors pas de la fonctionnalité demandée, mais de l’incertitude qui entourait le système existant.
Un audit préalable réduit cette incertitude. Il ne promet pas qu’aucun incident n’arrivera. Il rend visibles les risques, les dépendances et les choix nécessaires avant d’engager une équipe ou de valider un budget. Pour une TPE ou une PME, c’est souvent plus utile qu’un devis construit sur des hypothèses optimistes.
Exemple d’audit de code avant évolution : le cas d’un portail B2B
Prenons le cas d’un portail B2B utilisé par des clients et des équipes commerciales. La direction veut ajouter un module permettant aux clients de préparer des commandes récurrentes, avec une suggestion de produits fondée sur leur historique. La demande implique l’interface, le catalogue, les prix négociés, les comptes clients et, potentiellement, un service d’IA.
L’application fonctionne. Elle a été développée par plusieurs prestataires sur cinq ans. Le dernier développeur n’est plus disponible. Il existe un dépôt Git, un accès au serveur de production et une base de données active, mais la documentation est limitée à quelques fichiers anciens.
Ce que l’examen initial révèle
La première étape consiste à reproduire l’application localement ou dans un environnement de travail contrôlé. Si cela échoue, ce n’est pas un détail administratif. C’est déjà un constat : le déploiement dépend peut-être d’éléments non versionnés, d’une configuration manuelle ou de secrets stockés au mauvais endroit.
Dans cet exemple, l’audit révèle que les prix clients sont calculés à trois endroits différents : dans un contrôleur web, dans une tâche planifiée et dans une classe de synchronisation ERP. Les règles ne sont pas strictement identiques. Ajouter des commandes récurrentes sans corriger ce point créerait un quatrième calcul, donc une quatrième source de divergence.
L’analyse montre aussi que les rôles utilisateurs sont contrôlés dans l’interface mais peu vérifiés côté serveur sur certaines routes. Un utilisateur ne peut normalement pas voir les données d’un autre client parce que le menu ne lui présente pas cette option. Ce n’est pas une règle de sécurité. C’est un comportement d’interface, et il suffit d’un appel direct ou d’une future API pour le contourner.
Enfin, l’historique de commandes est chargé de manière trop large pour certains écrans. Sur une petite base, le problème passe inaperçu. Avec plusieurs années de commandes et un nouveau module de recommandations, les temps de réponse risquent de dégrader le portail complet. La fonctionnalité IA n’est donc pas le premier sujet. La lecture et la structuration des données le sont.
Dans ce cas, une réécriture complète serait disproportionnée. Le portail génère du chiffre d’affaires, les utilisateurs le connaissent et une partie importante du code reste compréhensible. En revanche, livrer la nouvelle demande directement serait irresponsable.
La recommandation peut être de créer un service unique de calcul des prix, de déplacer les contrôles d’accès côté serveur, d’ajouter les index nécessaires en base et d’encadrer les appels aux données d’historique. Ensuite seulement, le module de commande récurrente peut être construit sur des règles cohérentes.
C’est le résultat attendu d’un audit : non pas un jugement esthétique sur le code, mais une séquence de travail. Ce qui doit être corrigé avant l’évolution, ce qui peut être traité pendant, et ce qui peut attendre sans mettre l’activité en danger.
Ce qu’un audit doit vérifier concrètement
Un audit sérieux ne se limite pas à lancer un outil d’analyse statique ou à relever des bibliothèques obsolètes. Ces outils sont utiles, mais ils ne connaissent ni le métier ni les contraintes de l’entreprise. Le travail consiste à relier le code, les données, l’infrastructure et l’usage réel.
Comprendre les flux métier avant les fichiers
La lecture commence par les parcours qui comptent : création de compte, paiement, synchronisation, génération de documents, import de données, droits d’accès ou calcul de prix. On remonte ensuite vers les contrôleurs, services, tâches asynchrones, tables et services externes concernés.
Cette approche évite un piège fréquent : produire une longue liste de défauts techniques sans savoir lesquels menacent l’évolution demandée. Un framework ancien peut être acceptable pendant quelques mois. En revanche, une erreur dans le calcul de TVA ou dans l’isolation des comptes clients ne l’est pas.
Vérifier la chaîne de livraison
Le code ne vit pas seul dans un dépôt. Il faut examiner comment il est livré et exploité : environnements disponibles, procédure de déploiement, variables de configuration, logs, alertes, sauvegardes, restauration, accès serveur et dépendances à des services tiers.
Un projet peut être propre sur le poste d’un développeur tout en restant risqué en production. Si une mise en ligne se fait par copie manuelle de fichiers, si aucune alerte ne remonte sur les erreurs applicatives ou si la restauration de base n’a jamais été testée, une évolution amplifie ce risque. L’infrastructure est une partie du produit. La traiter comme un détail finit généralement par coûter plus cher.
Tester les zones qui seront modifiées
Les tests existants doivent être évalués pour ce qu’ils couvrent réellement. Un taux de couverture élevé ne garantit rien si les scénarios métier critiques ne sont pas testés. À l’inverse, une application avec peu de tests peut parfois évoluer de façon maîtrisée si les parcours sensibles sont clairement isolés et vérifiés manuellement dans un environnement proche de la production.
Il faut décider avec pragmatisme. Ajouter une suite complète de tests avant une petite modification urgente peut ne pas être rentable. Ajouter des tests ciblés autour du paiement, des droits ou de la synchronisation est souvent un investissement défendable.
Le livrable : des décisions, pas un rapport décoratif
À la fin de l’intervention, le décideur doit pouvoir arbitrer. Un bon rapport d’audit indique ce qui a été observé, mais surtout ce que cela implique pour le projet. Il distingue les faits des hypothèses et classe les actions selon leur urgence et leur valeur.
Les éléments utiles sont généralement les suivants :
- une cartographie concise de l’application, de ses flux critiques et de ses dépendances ;
- les risques constatés, avec leur impact métier probable ;
- les corrections préalables nécessaires avant l’évolution ;
- un plan de réalisation découpé en étapes vérifiables, avec les points de décision ;
- les sujets différables, afin de ne pas gonfler artificiellement le périmètre.
Le niveau de détail dépend du contexte. Pour une application interne peu exposée, un rapport court et une feuille de route peuvent suffire. Pour une plateforme qui traite des commandes, des données personnelles ou des flux financiers, l’analyse doit être plus approfondie. Il n’existe pas de format unique. Il existe un niveau de rigueur proportionné au risque.
Ce qu’un audit ne doit pas devenir
L’audit ne doit pas servir à repousser indéfiniment la décision. Si chaque constat devient une raison de suspendre l’évolution, le rapport ne rend pas service à l’entreprise. Une dette technique se gère, elle ne disparaît pas par incantation.
Il ne doit pas non plus servir à imposer une technologie par préférence personnelle. Remplacer un langage, un hébergeur ou un framework parce qu’il est moins à la mode n’est pas une stratégie. Une migration se justifie lorsqu’elle résout un risque concret : sécurité non maintenue, coûts d’exploitation excessifs, blocage de recrutement, performances insuffisantes ou impossibilité de livrer correctement.
Le bon audit accepte les compromis explicites. Il peut recommander de conserver une partie ancienne du système, de la mettre sous surveillance et de construire la nouvelle fonction autour d’une frontière claire. C’est souvent plus sûr qu’une refonte ambitieuse, mal cadrée et impossible à finir.
Avant de financer la prochaine évolution, demandez une réponse simple : quelles parties du système vont être touchées, quels risques cela crée, et quelle action minimale les réduit à un niveau acceptable ? Si personne ne peut répondre clairement, le développement n’a pas encore commencé.