Principe DRY en vibe coding : éviter que l'IA duplique votre code partout

Quand on code avec l’IA, le même problème revient souvent : elle reproduit la même logique dans plusieurs fichiers. Au début, tout semble aller vite. Puis la dette arrive : chaque changement simple devient une chasse au copier-coller.

TL;DR

Le principe DRY (Don’t Repeat Yourself) est indispensable en vibe coding. Si une règle métier existe déjà, elle doit vivre à un seul endroit.

Ordre d’exécution recommandé :

1. Guardrail : imposer “réutiliser avant de créer”.
2. Audit DRY : lister les duplications après chaque lot de code IA.
3. Refactorisation : extraire utilitaires/composants communs.

Pourquoi DRY est-il critique quand on code avec l’IA ?

Le risque n’est pas juste “code moins élégant”. Le risque est opérationnel :

• Un paramètre API change → correction dans 8 fichiers.
• Une faille est corrigée à un endroit → oubliée ailleurs.
• Les tests explosent car la même logique existe sous 5 variantes.

Résultat : tu ralentis alors que l’objectif de l’IA était d’accélérer.

Ce constat est aligné avec le principe original de DRY formulé par Hunt et Thomas dans The Pragmatic Programmer : chaque connaissance doit avoir une représentation unique et non ambiguë dans un système.

Quels sont les bénéfices directs de DRY en vibe coding ?

1) Modularité

Une logique unique dans un module unique est plus facile à tester, debugger et versionner.

2) Scalabilité

Une base compacte évolue mieux. Tu ajoutes des features sans faire grossir la dette.

3) Économie de tokens

Moins de duplication = prompts plus courts = moins de contexte inutile à relire pour l’IA.

Comment piloter l’IA pour respecter DRY ? (Playbook)

Étape 1 : Guardrail avant génération

Objectif : empêcher l’IA de créer un nouveau bloc si un bloc équivalent existe déjà.

Prompt type :

Je veux ajouter [Feature X].
Règle stricte : avant d'écrire du nouveau code,
cherche dans le repo une logique réutilisable.
Si elle existe, propose une extension du code existant.
Si elle n'existe pas, crée un module dédié réutilisable.
Interdit : copier-coller la même logique dans plusieurs fichiers.

Étape 2 : Audit DRY après génération

Objectif : détecter les répétitions immédiatement.

Prompt type :

Analyse le code que tu viens de produire.
Liste toutes les fonctions/composants avec structures similaires
déjà présentes ailleurs dans le repo.
Ne modifie rien.
Donne seulement :
1) fichiers concernés
2) logique dupliquée
3) proposition de point unique de vérité

Étape 3 : Refactorisation contrôlée

Objectif : consolider sans casser le comportement métier.

Prompt type :

Refactorise pour appliquer strictement DRY.
Contraintes :
- pas de changement fonctionnel
- pas de breaking changes API
- source unique de vérité pour la logique dupliquée
- ajoute ou adapte les tests nécessaires
Rends un récap "avant/après" par fichier modifié.

Exemple concret : comment refactoriser un API client dupliqué ?

Problème : appel API dupliqué dans plusieurs services.

Avant :

// services/a.js
export async function fetchUsers() {
  return fetch(process.env.API_URL + '/users', {
    headers: { Authorization: `Bearer ${process.env.API_KEY}` }
  });
}

// services/b.js
export async function fetchProjects() {
  return fetch(process.env.API_URL + '/projects', {
    headers: { Authorization: `Bearer ${process.env.API_KEY}` }
  });
}

Après DRY :

// lib/apiClient.js
export async function apiGet(path) {
  return fetch(`${process.env.API_URL}${path}`, {
    headers: { Authorization: `Bearer ${process.env.API_KEY}` }
  });
}

// services/a.js
import { apiGet } from '../lib/apiClient.js';
export const fetchUsers = () => apiGet('/users');

// services/b.js
import { apiGet } from '../lib/apiClient.js';
export const fetchProjects = () => apiGet('/projects');

Gain : quand l’auth change, tu modifies lib/apiClient.js une seule fois.

Checklist DRY avant merge

• Chaque logique métier clé existe-t-elle dans un seul module ?
• Les nouvelles fonctions ressemblent-elles fortement à des fonctions existantes ?
• Les constantes/configs sont-elles centralisées ?
• Les tests couvrent-ils le point unique de vérité extrait ?
• Le diff réduit-il la duplication ou l’augmente-t-il ?

Si un point est rouge : pas de merge.

Quelles erreurs éviter en vibe coding avec DRY ?

1. Accepter un patch “qui marche” sans audit de duplication.
2. Laisser des variations minimes de la même fonction dans plusieurs fichiers.
3. Reporter la refacto “à plus tard” (elle n’arrive jamais).
4. Ne pas formaliser DRY dans les prompts standards d’équipe.

FAQ

DRY ralentit-il le développement quand on utilise l’IA ?

À court terme, tu ajoutes un peu de discipline dans ton workflow. Mais à moyen terme, tu vas nettement plus vite parce que chaque changement ne touche qu’un seul endroit. Moins de bugs de régression, moins de temps perdu à chercher “où est l’autre copie”. Le ROI est mesurable dès la deuxième itération.

Faut-il être architecte senior pour appliquer DRY ?

Non. Avec de bons guardrails dans tes prompts et un audit systématique après chaque lot de génération IA, une équipe junior peut garder une base propre. L’important est d’avoir le réflexe de chercher avant de créer, et de formaliser ce réflexe dans les instructions données à l’IA.

DRY suffit-il pour une bonne architecture ?

Non. DRY est un pilier fondamental mais il ne couvre pas tout. Il faut aussi la séparation des responsabilités (SRP), des tests solides, des conventions de code partagées et une gestion claire des dépendances. DRY élimine la duplication, les autres principes structurent le reste.

À quelle fréquence faire l’audit DRY ?

À chaque lot de génération IA important (plus de 3 fichiers modifiés), et obligatoirement avant merge. En pratique, intégrer l’audit DRY dans la pull request review est le moyen le plus fiable de ne jamais l’oublier.

Conclusion

L’IA est excellente pour produire vite. Mais sans direction, elle peut reproduire vite… les mêmes erreurs.

Si tu appliques ce rituel Guardrail → Audit → Refactor, tu gardes la vitesse du vibe coding sans sacrifier la qualité du code.

Tu veux sécuriser aussi les bases de ton backend ? Lis notre guide Sécurité API en vibe coding : les 4 fondamentaux à verrouiller avant de ship.