Comptoir est une boutique en ligne open source d’environ 270 000 lignes de code et près de 9 000 commits. J’ai effectué un audit de ce dépôt et l’ai anonymisé, afin que ses chiffres puissent faire exemple dans ce billet.
Par quelle partie commencer ?
Je commencerais par la partie qu’on modifie le plus souvent, pas par celle qu’on a honte de montrer.
En effet, devant une application lourde à maintenir, on peut avoir le réflexe de vouloir retravailler le module le plus laid. Celui que les métriques montrent du doigt : des avertissements à la compilation, une architecture rendue illisible par les évolutions successives… Et pourtant, ce dernier est robuste, vous n’avez pas eu à le modifier depuis plusieurs années, il n’a pas généré de bugs depuis un certain temps. Ce n’est pas lui qui coûte cher au quotidien.
Meir Manny Lehman, père des lois de l’évolution logicielle, l’a formulé dès 1974 :
Loi I, Continuing Change
« Un programme en service doit être adapté en continu, sinon il devient de moins en moins satisfaisant. »
« An E-type program that is used must be continually adapted else it becomes progressively less satisfactory. »
Loi II, Increasing Complexity
« À mesure qu’un programme évolue, sa complexité augmente, sauf si l’on travaille à la maintenir ou à la réduire. »
« As a program is evolved its complexity increases unless work is done to maintain or reduce it. »
Qu’est-ce qui coûte vraiment ?
Ce qui coûte réellement sur la durée, ce sont les modules compliqués sur lesquels on revient régulièrement. CodeScene nomme ça des points chauds.
Deux mesures permettent d’établir les points chauds d’un dépôt : le nombre de modifications d’un fichier, et sa complexité. L’audit multiplie les deux afin de déterminer quels sont les fichiers à prioriser.
Pour connaître la complexité des fichiers du dépôt :
packages.config(ASP.NET MVC 5, .NET Framework) : dans la Console du Gestionnaire de packageInstall-Package Microsoft.CodeAnalysis.MetricsProjet SDK : depuis le dossier du projet
dotnet add package Microsoft.CodeAnalysis.MetricsDans les deux cas : depuis le dossier du projet, dans l’invite de commandes développeur
msbuild /t:Metrics /p:MetricsOutputFile=metriques.xml
Pour lister les fichiers les plus modifiés sur les 12 derniers mois :
git log --since="12 months ago" --format= --name-only |
sort | uniq -c | sort -rn | head -20
Il est possible que des fichiers générés ou les migrations ressortent en première position, ils sont à ignorer.
Sur Comptoir, les plus gros points chauds révélés sont dans le module de vente : fiches produit, panier, commandes, prise de commandes et paiement. En tête arrive le contrôleur des fiches produit du back office : 338 modifications et une complexité de 433.
On y trouve deux fichiers avec des scores de maintenabilité (métrique Visual Studio) à 0 sur 100 :
- l’aide au catalogue, modifiée 220 fois, arrive 5e ;
- le service de recherche, modifié 51 fois, n’arrive que 66e.
La note est la même, l’urgence ne l’est pas.
Attention : les points chauds montrent où l’équipe passe du temps, pas forcément ce qui coûte le plus cher. Cela peut avoir un lien avec des bugs, ou des besoins répétitifs d’évolutions.
Et ce qui ne pèse pas au quotidien ?
Une deuxième liste de fichiers peut être priorisée. Elle peut ne rien coûter au quotidien, mais expose l’application : les composants à vulnérabilités connues, et ce qui traîne dans l’historique.
Les composants
Voici comment les lister en .NET :
PackageReference (projet SDK) : la liste des packages vulnérables, dépendances indirectes comprises
dotnet list package --vulnerable --include-transitivepackages.config(ASP.NET MVC 5, .NET Framework) : l’audit passe pendant la restauration (NuGet 6.10 ou plus)nuget.exe restore App.sln
Sur Comptoir, les outils remontent 195 alertes, dont 11 critiques. Il convient de vérifier l’arbre de dépendances et de monter en version les packages qui ont un patch sur leur vulnérabilité.
L’historique
Il est important de sonder l’historique Git à la recherche de secrets exposés. Tout développeur a déjà fait l’erreur : un commit un peu trop rapide, et c’est une clé d’API qui part dans le dépôt Git. Dans ce cas-là, commiter un fichier corrigé ne permet pas d’effacer la trace de la clé compromise.
C’est pour cela qu’il faut analyser le dépôt et son historique avec un utilitaire qui retrouve ces secrets. Personnellement, j’utilise Gitleaks :
winget install Gitleaks.Gitleaks
gitleaks git -v --redact
Dans quel ordre ?
Nos outils nous permettent d’évaluer deux axes techniques. Cependant, un troisième axe doit être pris en compte pour arbitrer l’ordre des chantiers : la criticité métier.
Pour quelqu’un qui doit faire cet arbitrage, il convient alors de se poser les questions suivantes :
| Axe | Question | Ce que le dépôt dit | Limite |
|---|---|---|---|
| Ce qui pèse | Où l’équipe passe-t-elle son temps ? | Modifications et complexité | Montre l’effort, pas forcément le coût |
| Ce qui expose | Qu’est-ce qui est connu et atteignable ? | Alertes, secrets dans l’historique | Une alerte n’est pas un risque |
| Ce qui compte | Que perd-on en une heure d’arrêt ? | Rien | À demander aux personnes du métier |
Par exemple, sur Comptoir, si le chantier le plus important est le tunnel de vente, ce sont les failles qui sont les plus urgentes. On réalise d’abord l’urgent, puis l’important. Dans l’ordre, ça donnerait :
- Faire révoquer les secrets trouvés dans l’historique
- Chantier des vulnérabilités, c’est-à-dire les gains rapides du rapport : la révocation ci-dessus et la mise à jour des trois bibliothèques dont la faille critique se corrige sans changer de version majeure
- Chantier sur le tunnel de vente
- Chantiers « secondaires »
Les outils nommés ci-dessus permettent d’avoir les cartes en main pour évaluer dans quel ordre il faut refondre les modules.
Pages consultées le 27 octobre 2026.