Copypaste dans le développement d'applications — ce que c'est, pourquoi c'est dangereux et comment l'éviter

Qu'est-ce que le copypaste ?

Copypaste (programmation par copier-coller) consiste à déplacer du code existant vers un nouvel endroit avec peu ou pas de modifications. Le terme est utilisé de manière péjorative : il implique que le développeur ne conçoit pas une solution, mais copie mécaniquement un bloc tout fait, souvent sans comprendre complètement son fonctionnement.

Le copypaste est de deux types : intentionnel et accidentel. Intentionnel — quand un développeur copie délibérément du code avec l'intention de le refactoriser plus tard (mais le plan est souvent abandonné). Accidentel — quand la duplication survient sans être remarquée, par exemple, deux développeurs écrivent indépendamment la même logique pour des écrans différents.

Selon le rapport SonarQube State of Clean Code (2025), le code dupliqué représente en moyenne 12 à 18 pour cent du volume total de code dans les projets commerciaux. Parallèlement, le coût de correction d'un bogue dans du code dupliqué est 2,5 fois plus élevé que dans du code à implémentation unique, car le développeur doit trouver et corriger toutes les copies.

L'outil principal contre le copypaste est le principe DRY (Don't Repeat Yourself). Cependant, absolutiser le DRY est aussi dangereux : parfois copier est justifié lorsque deux copies doivent évoluer indépendamment l'une de l'autre. Il est important de distinguer la « duplication accidentelle » (qui doit être éliminée) de la « duplication nécessaire » (qui doit être documentée).

Pourquoi le copypaste est dangereux

Le premier danger, le plus critique, est la propagation des bogues. Si le code d'origine a un défaut, il est copié partout avec le code. Lorsque le défaut est découvert et corrigé dans le module d'origine, les copies restent non corrigées. Le développeur peut même ignorer que le bogue existe dans cinq fichiers différents.

Le deuxième danger est l'évolution inégale. Deux copies du même algorithme accumulent des modifications différentes au fil du temps. Une copie ajoute une validation des valeurs limites, une autre modifie le format de sortie. Après quelques mois, il devient impossible de savoir quelle version est la « bonne », et le projet perd sa cohérence comportementale.

Le troisième danger est l'augmentation du volume de tests. Chaque instance de copypaste nécessite ses propres tests. Si la logique commune est extraite dans une seule fonction, elle peut être couverte par un ensemble de tests et réutilisée. Avec la duplication, chaque copie doit être testée séparément — cela multiplie le temps d'exécution de l'IC et la taille de la base de tests à maintenir.

Le quatrième danger est l'illusion de productivité. Le copypaste crée une fausse impression de vitesse : le développeur colle rapidement le code et voit que l'écran fonctionne. Mais cette « vitesse » se transforme en dette technique qui devra être remboursée avec intérêts lorsqu'un bogue sera trouvé dans le bloc dupliqué ou qu'un changement de logique métier sera nécessaire.

Pourquoi les développeurs copient du code

Comprendre les raisons du copypaste aide à établir une prévention appropriée. La plupart du temps, les développeurs copient du code non par paresse, mais à cause de la pression des délais, du manque de connaissances ou d'une architecture inadaptée.

La première raison est les délais serrés. Lorsqu'un écran doit être créé en deux jours et qu'un écran similaire existe déjà, le développeur le copie entièrement et ne modifie que ce que l'utilisateur voit. Il n'y a pas de temps pour refactoriser et extraire un composant partagé — le client exige des résultats. En conséquence, un deuxième écran apparaît avec 80 pour cent de code partagé mais un historique de modifications indépendant.

La deuxième raison est l'absence d'abstraction unifiée. Si le projet ne dispose pas d'un composant partagé pour une tâche typique (par exemple, un écran de liste avec pull-to-refresh), chaque développeur écrira sa propre implémentation ou copiera celle du voisin. Les décisions architecturales prises au début du projet influencent directement la quantité de copypaste futur.

La troisième raison est la peur de casser du code qui fonctionne. Le développeur sait que le module existant fonctionne. Refactoriser pour extraire du code partagé peut affecter les fonctionnalités existantes. Si la couverture de tests est faible, le risque de casse dépasse le bénéfice perçu de la refactorisation, et le développeur choisit la voie sûre — copier.

Traitez les causes, pas les symptômes. Réduire les délais et introduire la revue de code ne résoudra pas le problème si le projet manque d'une base architecturale solide. Investissez du temps dans la création de composants réutilisables dès les premières étapes — c'est le seul moyen de réduire la tentation du copypaste à l'avenir.

Outils de détection des doublons

La détection du copypaste est effectuée par des analyseurs automatiques qui comparent des fragments de code et identifient les correspondances au-dessus d'un seuil donné. Les meilleurs outils fonctionnent au niveau AST (Arbre de Syntaxe Abstraite) et ignorent le formatage, les noms de variables et les commentaires.

PMD CPD (Copy-Paste Detector) est l'outil le plus courant pour Java, Kotlin, Swift, JavaScript, Python et C++. CPD analyse les tokens du code source et trouve les doublons plus longs qu'un nombre minimum de tokens spécifié (par défaut 100). Configurer le seuil est essentiel pour des résultats de qualité : un seuil trop bas génère de nombreux faux positifs (schémas courants comme les imports), un seuil trop haut laisse passer de vrais doublons.

Exécuter PMD CPD via Gradle

plugins {
    id 'pmd'
}

pmd {
    toolVersion = '7.0.0'
    ruleSetFiles = files("pmd-rules.xml")
}

tasks.register('cpd') {
    doLast {
        exec {
            workingDir = projectDir
            commandLine 'cpd',
                '--minimum-tokens', '75',
                '--language', 'kotlin',
                '--files', 'src/main/kotlin',
                '--format', 'xml',
                '--failOnViolation', 'true'
        }
    }
}

SonarQube intègre un détecteur de doublons directement dans le Quality Gate. La règle Duplicated Blocks (%) affiche le pourcentage de code dupliqué. Un seuil de 5 pour cent est considéré comme sain pour les projets commerciaux. Le dépasser bloque la promotion vers la branche de release. SonarQube regroupe également les doublons par type : correspondances exactes et copies structurelles (avec des identifiants renommés).

Pour JavaScript et TypeScript, les doublons sont détectés avec ESLint utilisant le plugin eslint-plugin-sonarjs (règle no-duplicate-string) et l'utilitaire jscpd, qui prend en charge plus de 150 langages. jscpd est particulièrement pratique pour les monorepos : il trouve des doublons entre les paquets, pas seulement à l'intérieur d'un seul module.

Stratégies de refactorisation du code dupliqué

La refactorisation du copypaste se résume à un principe : extraire la partie commune et paramétrer les différences. La technique spécifique dépend de l'étendue de la duplication et du contexte.

Le cas le plus simple est la duplication au sein d'une même classe (par exemple, deux méthodes avec la même logique mais des types différents). La solution est de généraliser avec des génériques ou de réutiliser une méthode avec un paramètre de type. Si la duplication couvre plusieurs classes — extrayez le code commun dans une classe utilitaire ou une fonction d'extension.

Un cas plus complexe est la duplication au niveau de l'écran ou du module. Ici, le simple fait d'extraire une fonction n'aide pas, car la structure de l'interface utilisateur, la logique du cycle de vie et la liaison de données sont toutes dupliquées. La solution est de créer une classe de base d'écran commune ou un composant de vue composite, et de passer les différences via des paramètres ou un protocole.

// before - two copies of the same UITableViewController
class UserListController: UITableViewController {
    private let viewModel = UserListViewModel()
    // 40 lines of code
}

class ProductListController: UITableViewController {
    private let viewModel = ProductListViewModel()
    // same 40 lines but with Product instead of User
}

// after - generic base class shared
class ListViewController<T: ListViewModel>: UITableViewController {
    let viewModel: T
    // 40 lines of code - once only

    init(viewModel: T) {
        self.viewModel = viewModel
        super.init(style: .plain)
    }
}

Le cas le plus complexe est la duplication entre microservices ou bibliothèques. Extraire du code partagé peut entraîner des dépendances circulaires ou un couplage injustifié. Dans de tels cas, le copypaste peut être une décision consciente : deux équipes maintiennent des services indépendants, et une bibliothèque partagée crée plus de problèmes qu'elle n'en résout. L'essentiel est de documenter cette décision et de vérifier régulièrement si les copies ont suffisamment divergé pour justifier une unification.

Prévention du copypaste au niveau de l'équipe

Prévenir le copypaste est plus efficace que refactoriser du code déjà dupliqué. Les principales mesures préventives résident dans l'organisation du processus de développement, pas dans la technologie.

La première mesure est la revue de code axée sur la duplication. La liste de contrôle de la revue doit inclure l'élément : « Ce PR contient-il du code qui existe déjà dans le projet ? » Si le relecteur voit du copypaste — il bloque la fusion jusqu'à ce que le composant partagé soit extrait. Cette exigence doit faire partie de la Définition de Fini de l'équipe.

La deuxième mesure est une bibliothèque de composants partagée. Chaque motif d'interface utilisateur qui apparaît sur deux écrans ou plus doit être extrait dans un module commun. Créez un module partagé dans le projet et faites-en le point d'entrée obligatoire pour tous les composants d'interface. Si un composant n'existe pas — il est d'abord créé, puis utilisé sur l'écran.

La troisième mesure est l'automatisation dans CI/CD. Ajoutez une étape de vérification de code dupliqué au pipeline (PMD CPD, jscpd, SonarQube). Le dépassement du seuil entraîne un échec de construction. Le développeur ne peut pas fusionner un PR qui augmente le ratio de copypaste au-dessus du niveau autorisé. Cela déplace la responsabilité de la revue de code vers l'automatisation et garantit qu'aucun doublon ne passe inaperçu.

Favorisez une culture de « une implémentation — un endroit. » Si vous voyez une opportunité de réutilisation — ne remettez pas la refactorisation à plus tard. Chaque copypaste laissé « pour plus tard » se multiplie et se transforme en dette technique ingérable.