DRY en développement web - Répéter ou abstraire ?

En développement logiciel, la duplication n’est pas qu’un défaut esthétique : elle multiplie les endroits à corriger, les règles qui dérivent et les incohérences entre l’interface, l’API et la base de données. Le principe DRY sert justement à réduire ce bruit de fond pour garder un code plus lisible, plus stable et plus simple à faire évoluer. Je vais clarifier ce qu’il signifie vraiment, où il apporte le plus de valeur dans une stack web moderne et quand il vaut mieux accepter une répétition locale plutôt que fabriquer une abstraction trop tôt.

Ce que le principe DRY cherche vraiment à éviter

Le DRY, pour Don’t Repeat Yourself, n’est pas une injonction à bannir chaque ligne répétée. Ce qu’il combat, c’est la répétition d’une même connaissance dans plusieurs endroits d’un système. En pratique, cela veut dire qu’une règle métier, une formule, un format de données ou une dépendance de configuration ne devrait pas exister sous trois formes différentes si elle doit rester cohérente dans le temps.

Je fais souvent la distinction entre le code répété et l’idée répétée. Deux blocs peuvent se ressembler visuellement sans porter la même responsabilité métier. Par exemple, une règle d’âge pour un accès légal, une autre pour une inscription contractuelle et une troisième pour une recommandation produit peuvent utiliser des seuils proches aujourd’hui, mais elles ne racontent pas la même chose. Les fusionner trop vite crée une abstraction qui semble élégante le premier jour et pénible au premier changement.

Dans la pratique, DRY revient à chercher une seule source de vérité pour ce qui doit rester uniforme. C’est ce qui permet à une modification d’être appliquée une seule fois et de se propager correctement là où elle compte. Je garde cette idée en tête parce qu’elle évite le piège classique : croire qu’on a gagné en propreté alors qu’on a seulement déplacé la complexité. C’est justement ce point de vue qui permet ensuite de mesurer les vrais bénéfices du principe.

Et une fois cette nuance posée, on voit plus clairement pourquoi DRY améliore autant la maintenance qu’un refactoring futur.

Pourquoi il change vraiment la vie d’un projet web sur le long terme

Le premier gain, c’est la vitesse de changement. Quand une règle existe à un seul endroit, je n’ai pas à courir après cinq variantes légèrement différentes. Une correction devient plus rapide, plus fiable et plus facile à tester. Dans un projet web, c’est loin d’être un détail : une modification de validation, d’URL, de format de date ou de calcul de prix peut toucher le front, l’API, les tests et parfois la documentation.

Le deuxième gain, c’est la cohérence. Dès qu’une même logique est recopiée dans plusieurs couches, les écarts finissent par apparaître. Une même erreur de validation, un libellé différent, un arrondi calculé différemment ou un champ renommé à moitié provoquent des bugs qui ressemblent à des problèmes de synchronisation. Je préfère largement une règle claire et centralisée à trois versions “presque identiques”, parce que ce “presque” finit presque toujours par coûter cher.

Le troisième gain, plus discret, concerne la lisibilité collective. Un nouveau développeur comprend plus vite un système qui a peu de points de vérité qu’un projet rempli de doublons implicites. Cela réduit la charge mentale, rend les revues de code plus utiles et limite les mauvaises surprises pendant les refontes. À l’échelle d’une équipe, ce n’est pas seulement une question de style : c’est un multiplicateur de qualité.

Effet concret	Ce que ça change	Pourquoi c’est utile
Moins d’endroits à modifier	Une règle vit dans un seul module ou schéma	Je réduis le risque d’oubli lors d’une évolution
Moins de divergences	Le front, le backend et la base suivent la même logique	Je limite les bugs de désalignement
Refactoring plus simple	La logique utile est concentrée	Je peux faire évoluer le code sans tout réécrire
Tests plus fiables	La règle testée correspond à la règle réellement utilisée	Je gagne en confiance à chaque déploiement

Autrement dit, DRY ne sert pas à produire un code plus “joli” sur le moment. Il sert à rendre le changement moins fragile, ce qui est beaucoup plus précieux dans un projet web qui évolue par petites couches successives. C’est cette logique qui m’amène à regarder ensuite où l’appliquer concrètement.

Où l’appliquer dans JavaScript, le backend et les données

Le DRY prend des formes différentes selon la couche technique. J’aime bien le voir comme un principe transversal : il ne dit pas “fais des fonctions partout”, il dit “centralise ce qui doit rester identique”. Dans une stack web moderne, cela touche souvent le JavaScript, les services backend, les schémas de données, les tests et même les fichiers de configuration.

Dans JavaScript et le front-end

Sur le front, la répétition la plus coûteuse concerne souvent les validations, les formats et les libellés. Si le même mot-clé, la même regex ou la même logique de formatage revient dans plusieurs composants, je la sors dans une fonction, un hook, un helper ou une constante partagée. L’idée n’est pas de rendre le composant plus abstrait pour le plaisir, mais d’éviter que trois écrans affichent la même règle avec trois interprétations différentes.

C’est particulièrement vrai pour tout ce qui concerne les formulaires : longueur minimale d’un mot de passe, normalisation d’un numéro de téléphone, format de date, contraintes de saisie. Une règle dupliquée dans l’UI finit souvent recopiée côté API, puis modifiée à un seul endroit. Le DRY aide justement à empêcher cette dérive silencieuse.

Dans les API et le backend

Côté backend, je cible en priorité la logique métier, les conversions de données et les règles d’accès. Une fonction qui calcule une remise, un statut de commande ou une autorisation ne devrait pas vivre sous trois formes différentes dans trois contrôleurs. Je préfère la mettre dans un service, un module de domaine ou une policy bien nommée, puis faire appel à elle depuis les points d’entrée.

Le même réflexe vaut pour les mappers et les DTO, ces objets de transfert qui servent à faire circuler une donnée sans exposer tout le modèle interne. Si le mapping est recopié à la main partout, la dette arrive vite. Quand je le centralise, je garde une structure plus robuste et je simplifie les changements d’API sans polluer toute la base de code.

Dans SQL et NoSQL

En SQL, le principe prend souvent la forme de la normalisation : une donnée stable doit être stockée une seule fois, puis référencée correctement. Cela évite les incohérences entre tables, les mises à jour partielles et les corrections en cascade. Pour les requêtes répétitives, je préfère parfois une vue, une requête paramétrée ou un modèle partagé plutôt qu’une copie collée dans plusieurs services.

En NoSQL, la situation est un peu différente. On accepte parfois une certaine duplication de données pour gagner en vitesse de lecture ou simplifier un document. Là, je ne cherche pas à supprimer toute répétition, mais à centraliser les règles qui fabriquent ou valident ces données. Autrement dit, je peux dupliquer un champ pour des raisons de performance, mais je ne duplique pas la logique qui explique sa valeur.

Lire aussi : Templates Go - Maîtrisez `text/template` et `html/template`

Dans les tests, la configuration et la documentation

Les tests sont un excellent terrain pour DRY, à condition de ne pas tomber dans l’usine à abstractions. Les factories, les fixtures et les générateurs de données servent justement à éviter de répéter les mêmes objets de test avec des variantes mineures. Je préfère une factory claire à dix copies d’un même payload légèrement modifié à la main.

La configuration suit la même logique. Variables d’environnement, clés d’API, URL de service, niveaux de log : si une valeur doit être utilisée partout, elle doit être déclarée une fois et consommée partout. Même chose pour les contrats d’API et la documentation technique. Quand un schéma change, je veux limiter le nombre de fichiers à réaligner. Cette cartographie des usages fait ressortir une question plus délicate : tout ce qui se répète mérite-t-il vraiment d’être centralisé ?

Quand répéter reste plus sain que sur-abstractiser

Je vois souvent le principe DRY mal appliqué parce qu’on le confond avec une interdiction absolue de la répétition. En réalité, certaines répétitions sont saines, voire préférables. La bonne abstraction doit simplifier le changement, pas compliquer la lecture. Quand l’extraction oblige à sauter entre cinq fichiers pour comprendre une action banale, j’ai probablement trop abstrait trop tôt.

Une heuristique simple m’aide beaucoup : la règle des trois occurrences. À la troisième répétition d’un motif, j’examine sérieusement l’extraction. Avant cela, je reste prudent. Deux blocs similaires peuvent être un accident temporaire ou refléter deux responsabilités différentes. Attendre un peu évite de figer une ressemblance de surface en architecture définitive.

Situation	Je fais plutôt cela	Pourquoi
Deux blocs se ressemblent, mais leurs règles métier peuvent diverger	Je laisse séparé	Je ne veux pas lier artificiellement deux évolutions indépendantes
La même logique de validation apparaît dans plusieurs couches	J’extrais une fonction ou un service commun	Je centralise la connaissance qui doit rester identique
Les contrôles de sécurité s’appliquent à plusieurs points d’entrée	Je répète volontairement les garde-fous critiques	La défense en profondeur peut justifier une répétition locale
Une abstraction rend l’appel plus lourd que le code dupliqué	Je reviens en arrière	La lisibilité immédiate vaut souvent mieux qu’un DRY trop ambitieux

Je vois donc DRY comme un filtre de décision, pas comme une idéologie. Dès que j’ai clarifié ce point, l’adoption devient plus simple et surtout moins dogmatique.

Une méthode simple pour l’adopter sans casser la lisibilité

Quand je veux appliquer DRY proprement dans un projet, je pars d’un principe : j’optimise pour le futur changement, pas pour la propreté théorique du jour. Cela m’évite de créer des couches inutiles. La méthode est assez simple et fonctionne bien dans les équipes qui veulent garder un code compréhensible.

1. Je repère ce qui change réellement et ce qui ne change presque jamais.
2. J’extrais la partie stable en un seul endroit : fonction, module, service, schéma ou configuration.
3. Je laisse la variabilité là où elle a du sens, via des paramètres, des interfaces ou des contrats clairs.
4. Je vérifie que l’extraction reste plus simple à lire que la duplication initiale.
5. Je reviens sur l’abstraction lors du prochain changement, pas avant.

Ce dernier point compte énormément. Je n’essaie pas de “deviner” l’architecture finale à partir de trois exemples. Je préfère laisser le besoin révéler la bonne forme. C’est aussi pour cela que je regarde toujours les signes d’alerte : si une abstraction commence à demander plus de contexte qu’elle n’en économise, si elle ajoute des couches d’indirection inutiles ou si elle masque les règles métier derrière des noms trop génériques, je la simplifie.

Dans un projet web, cette discipline fonctionne particulièrement bien lorsqu’on la couple à des tests clairs et à des revues de code exigeantes. Les tests protègent la source de vérité, et la revue empêche les abstractions décoratives de s’installer. C’est ce duo qui transforme DRY en pratique durable, pas seulement en bonne intention.

Au fond, je cherche moins à réduire le nombre de lignes qu’à réduire le nombre de décisions à synchroniser. C’est cette nuance qui fait la différence entre un code modulaire et un code simplement compliqué.

Le bon réflexe quand une règle commence à se répéter

Si je devais résumer DRY en une phrase utile, je dirais ceci : centraliser ce qui doit rester cohérent, et accepter la répétition quand elle protège la clarté. Dans un projet web, ce réflexe évite les écarts entre le front, le backend, la base de données et les tests, sans transformer le codebase en architecture rigide.

Je retiens aussi une règle pratique : une duplication locale et lisible vaut souvent mieux qu’une abstraction prématurée, mais une règle métier recopiée à plusieurs endroits devient vite une dette. Le bon équilibre n’est pas académique, il se juge à la vitesse des changements, à la qualité des revues et au nombre de bugs de synchronisation que l’équipe n’a plus à corriger.

Si j’observe un seul endroit qui porte la vérité, des dépendances bien nommées et des répétitions qui servent la lisibilité au lieu de la saboter, je sais que le projet va dans la bonne direction.