Le junk dans le développement — ce que c’est, pourquoi le code poubelle est nocif et comment le supprimer

Qu’est-ce que le code poubelle ?

Le junk (code poubelle) est un terme collectif pour le code, les configurations et les dépendances qui existent dans un projet mais n’apportent aucune valeur fonctionnelle. Le junk n’est pas nécessairement cassé ou inutilisé — le problème est que sa présence aggrave les métriques du projet sans justification adéquate.

Le junk se divise en quatre catégories. Première — dépendances redondantes : bibliothèques ajoutées pour une seule fonction qui aurait pu être implémentée avec des outils standards. Deuxième — poids mort : blocs commentés, TODO sans tickets, méthodes vides et classes stub. Troisième — solutions dupliquées : deux bibliothèques faisant la même chose (par exemple, Gson et Kotlin Serialization dans un même projet). Quatrième — sur-ingénierie : couches architecturales qui ne sont pas utilisées mais maintenues « au cas où ».

Selon une étude de Stripe Engineering Productivity (2025), supprimer 10 pour cent de junk d’un projet typique réduit le temps de construction complet en moyenne de 22 pour cent. La raison : chaque dépendance supplémentaire augmente le graphe de construction, chaque abstraction vide nécessite du temps pour être comprise, chaque bloc commenté distrait l’attention.

La principale difficulté dans la lutte contre le junk est l’absence de conséquences immédiates. Un projet avec du code poubelle compile et fonctionne. Les problèmes s’accumulent progressivement : la construction ralentit, le nombre de dépendances transitives augmente, et après un an, ajouter une nouvelle fonctionnalité prend deux fois plus de temps que nécessaire.

Dépendances junk et comment les identifier

Les dépendances junk sont des bibliothèques et des paquets ajoutés à un projet qui ne sont pas utilisés directement dans le code, ou ne sont utilisés que pour une seule fonction qu’il serait plus simple d’implémenter avec des API standards.

Exemples typiques : une bibliothèque de traitement JSON alors que le projet utilise déjà Kotlin Serialization (deux analyseurs, c’est du junk) ; la bibliothèque Apache Commons Lang pour un seul appel StringUtils.isEmpty qui pourrait être remplacé par l’extension Kotlin isNullOrBlank ; une bibliothèque d’injection de dépendances utilisée dans un module sur dix alors que les autres reçoivent leurs dépendances manuellement via le constructeur.

Chaque dépendance supplémentaire n’est pas seulement du code supplémentaire dans le binaire. Elle augmente la surface d’attaque pour les vulnérabilités : selon GitHub Advisory Database (2025), 40 pour cent des CVE critiques dans les projets mobiles proviennent de dépendances transitives que les développeurs ne contrôlent pas. Moins il y a de dépendances, plus la surface d’attaque est réduite.

Analyse des dépendances d’un projet Android

// View Gradle dependency tree
./gradlew app:dependencies --configuration releaseRuntimeClasspath

// Find unused dependencies (Gradle plugin)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// Generate unused library report
./gradlew buildHealth

Pour iOS, utilisez la commande swift package show-dependencies, qui affiche l’arbre complet des dépendances. L’outil Xcode Build Timeline montre combien de temps de construction chaque bibliothèque ajoute. Si une bibliothèque occupe 30 pour cent du temps de compilation mais n’est utilisée que sur un seul écran, c’est un candidat à la suppression ou au remplacement.

Pour Node.js (React Native), utilisez depcheck — un utilitaire qui trouve les dépendances inutilisées dans package.json, et npm-check, qui montre en plus les versions obsolètes. Introduisez une règle : chaque nouvelle dépendance doit passer une revue de code avec une justification de « pourquoi les outils standards ne peuvent pas être utilisés ».

Importations mortes et code commenté

Les importations mortes sont le type de junk le plus courant. Elles n’affectent pas l’exécution mais augmentent le temps de compilation : le compilateur traite chaque importation, même celles inutilisées. Dans les grands projets, la suppression des importations inutilisées réduit le temps de construction de 5 à 10 pour cent.

Les IDE modernes mettent automatiquement en évidence les importations inutilisées en gris. Configurez le nettoyage automatique à l’enregistrement : dans IntelliJ IDEA — Optimize Imports on the fly, dans Xcode — Editor > Remove Unused Imports. Ajoutez une vérification dans le CI : le linter doit bloquer les commits avec des importations inutilisées.

Le code commenté est un autre type de junk. Les développeurs commentent des blocs pour « ne pas perdre » de fonctionnalité lors du refactoring. Cependant, git conserve l’historique complet des modifications : tout code supprimé peut être restauré avec une seule commande git revert ou git log -S . Du code commenté dans master est un manque de respect envers l’équipe : chaque développeur dépense de l’énergie mentale sur la question « pourquoi ceci est commenté et quand faut-il le décommenter ? »

La règle : il n’y a pas de code commenté dans le dépôt. Si le code n’est pas nécessaire, supprimez-le définitivement. Si le code est nécessaire mais temporairement désactivé, utilisez un feature toggle avec un ticket et une date d’expiration. Les commentaires comme // TODO: remove after migration — ne les laissez pas sans échéance. Fixez une date et rappelez-vous avec un calendrier.

Abstractions redondantes et sur-ingénierie

La sur-ingénierie est la création de couches architecturales qui ne résolvent pas les problèmes actuels mais nécessitent de la maintenance. C’est l’un des types de junk les plus difficiles car formellement le code est « correct » : il suit SOLID, est couvert par des tests et est conforme à l’architecture. Le problème est qu’il n’est pas nécessaire.

Un exemple classique est une classe abstraite UseCase avec une seule méthode invoke qui appelle simplement un dépôt. Si le UseCase n’ajoute pas de logique (mise en cache, réessai, transformation) et ne fait que transmettre l’appel, c’est une entité supplémentaire. Elle augmente la navigation dans le projet : un développeur ouvre le UseCase, voit invoke → dépôt, et le ferme. Temps perdu, bénéfice nul.

Un autre exemple est la paramétrisation excessive. Une interface générique avec six paramètres de type utilisée à un seul endroit. Chaque paramètre de type ajoute une charge cognitive : en lisant le code, il faut garder six types en tête alors que seuls deux sont réellement utilisés. Si une abstraction n’est pas réutilisée, elle est redondante.

Le critère de coupure : si une abstraction n’est pas réutilisée dans trois contextes différents, supprimez-la. Une abstraction est justifiée lorsqu’elle résout réellement un problème de duplication, pas lorsqu’elle prédit des scénarios hypothétiques futurs. YAGNI (You Ain’t Gonna Need It) est le meilleur principe pour prévenir la sur-ingénierie.

Outils d’audit de junk

L’audit de junk nécessite une combinaison d’analyse statique, d’analyse des dépendances et de révision manuelle. Il est impossible d’automatiser complètement la détection des abstractions redondantes, mais le junk technique (importations mortes, bibliothèques inutilisées, code commenté) peut être trouvé avec des outils.

Pour un audit complet, exécutez buildHealth (Android) ou depcheck (Node.js) une fois par sprint. Créez un tableau de bord dans le CI qui montre la tendance du nombre de dépendances au fil des sprints. Si le nombre augmente mais que la fonctionnalité n’augmente pas proportionnellement, l’équipe accumule du junk.

Faites attention aux classes dupliquées — une erreur qui se produit lorsque deux bibliothèques contiennent la même classe. Ce n’est pas seulement du junk, mais aussi une source directe de conflits de construction. Dans Gradle, ces conflits sont résolus via force ou exclude, mais chaque résolution est un signal qu’une des bibliothèques est superflue.

Processus de nettoyage régulier du projet

Le nettoyage du junk n’est pas une action ponctuelle mais un processus régulier. Sans procédure, le junk revient en deux ou trois sprints. La meilleure pratique est d’allouer 10 à 15 pour cent de la capacité de chaque sprint au nettoyage technique, y compris l’audit de junk.

Le processus comprend quatre étapes. Première — diagnostic : exécuter les outils, obtenir un rapport, prioriser. Priorité élevée : dépendances avec des CVE connus et bibliothèques dupliquées. Priorité moyenne : importations mortes et code commenté. Priorité faible : abstractions redondantes (nécessitent une analyse manuelle).

Deuxième — nettoyage : supprimer les dépendances mortes, remplacer les bibliothèques dupliquées par une seule, effacer le code commenté. Chaque modification doit être un commit séparé avec un message clair : « remove unused dependency: gson (replaced by kotlinx.serialization) », « delete commented code in LoginViewModel ».

Troisième — vérification : compiler le projet, exécuter les tests, vérifier l’interface. Si les tests passent après la suppression d’une dépendance, la dépendance était vraiment inutile. Si les tests échouent, il reste une référence cachée que l’analyseur statique n’a pas détectée.

Quatrième — prévention : mettre à jour la liste de vérification de la revue de code, ajouter une règle « pas de nouvelle dépendance sans justification » à la Définition de Fini, configurer des vérifications automatiques dans le CI. La prévention est le seul moyen d’éviter une nouvelle accumulation de junk.