Le « copier-renommer » vous coûte plus cher que vous croyez

Mon premier contact avec la production de sites en série, c'était en stage de licence, dans une agence qui faisait des sites de campings. La méthode était simple et personne ne la cachait : on prenait le dernier site livré, on le dupliquait, on remplaçait le nom du camping à grands coups de rechercher-remplacer, on changeait les photos, et c'était parti. Un site de plus. La pratique était visible, assumée, et manifestement répandue bien au-delà de cette agence.

Ça marche. C'est même le problème : ça marche juste assez pour qu'on recommence à chaque fois. Le nouveau projet ressemble au dernier, alors on copie le dossier, on renomme, et on livre. Et soyons clairs, ce n'est pas de la paresse. Dupliquer, c'est une réponse rationnelle à un devis serré et un client qui veut son site dans dix jours. Le souci, c'est que ce n'est pas partir d'un modèle. C'est hériter d'un cas particulier avec tout ce qu'il traîne, et cet héritage se paie plus tard, quand personne ne regarde.

Les trois angles morts du clone

Quand vous copiez un projet existant pour en faire un nouveau, vous embarquez trois catégories de problèmes qui ne se voient pas au moment de la livraison.

Les faits recopiés. Un projet livré est plein de données qui lui sont propres : une adresse, des horaires, un numéro de TVA, un texte légal, une clé d'API, un pixel de tracking dans un pied de page. Le rechercher-remplacer attrape le nom du client, parce que c'est ce que vous cherchez. Il n'attrape pas le reste. Alors une partie de l'ancien projet survit dans le nouveau, correcte en apparence, fausse en réalité. On ne le découvre pas à la relecture, on le découvre quand le client appelle pour dire que ses horaires affichés sont ceux du concurrent d'à côté, ou que ses statistiques de visite remontent chez quelqu'un d'autre.

Les correctifs défaits par le renommage. Un projet mûr contient des corrections durement acquises. Un contournement pour un bug d'un plugin, une règle CSS qui répare un cas limite, une constante nommée d'une certaine façon parce qu'un outil en dépend. Un rechercher-remplacer massif ne fait pas la différence entre le nom du client et un identifiant technique qui contient par hasard la même chaîne. Il remplace les deux. Et il casse silencieusement une correction que vous aviez mis une journée à trouver six mois plus tôt. Le pire, c'est que vous ne le voyez pas : le remplacement a « réussi », il n'y a pas d'erreur, juste une réparation qui n'est plus là.

Les chemins de code dormants. L'ancien projet avait des fonctionnalités que le nouveau n'utilise pas. Un module de réservation, une intégration, une variante de gabarit. Vous les gardez, parce que les supprimer demande de comprendre ce qu'ils font, et que vous n'avez pas le temps. Alors ils dorment. Du code jamais exercé dans le nouveau contexte, qui grossit le projet, alourdit la maintenance, et se réveille un jour au plus mauvais moment, sous une forme que personne dans l'équipe ne sait plus expliquer.

Ces trois problèmes ont un point commun : ils sont invisibles à la duplication et coûteux à la découverte. C'est la définition même de la dette technique.

Le vrai modèle, c'est un squelette vide

L'alternative n'est pas de dupliquer plus proprement. C'est d'arrêter de dupliquer une instance.

Un ancien collègue, passé par une agence, avait fait le bon calcul. Au lieu de recopier le dernier site, il avait construit un squelette, plus une petite application de déploiement. Le squelette imposait la structure commune ; l'app générait un nouveau site à partir de là. Résultat : un nouveau site en un à deux jours, là où la méthode habituelle en demandait plusieurs semaines. Même famille de sites, même résultat visible pour le client, mais une base qui n'était plus un cas particulier déguisé.

La différence est conceptuelle avant d'être technique. Une instance, c'est un projet rempli : elle a un nom, un contenu, des données, une identité. Un squelette, c'est ce qui reste quand vous avez retiré tout ça. La machinerie commune, oui. Le contenu, non. Un squelette ne se clone pas et ne se renomme pas : il garde un nom neutre, définitivement, et on ne fait que le remplir. Ce qui varie d'un site à l'autre est explicitement vide, marqué comme « à remplir ». Ce qui est commun est figé et partagé. Le squelette ne s'occupe que de ce fond commun ; faire que les sites ne se ressemblent pas malgré ce socle partagé, c'est un autre métier, que j'ai raconté ailleurs.

Ce simple renversement supprime les trois angles morts d'un coup. Il n'y a plus de faits recopiés, parce qu'il n'y a aucun fait à recopier. Il n'y a plus de correctif défait par un renommage, parce qu'on ne renomme rien. Et il n'y a plus de chemin de code dormant, parce que le squelette ne contient que ce qui sert à toutes les instances.

Qui paie le squelette ?

Là, vous vous posez la vraie question d'agence : ce squelette, propre, marqué, testé, qui le paie ? Parce que c'est du temps non facturable, et qu'il faut le justifier à quelqu'un qui regarde le taux de staff en fin de mois. La question est légitime, et elle a une réponse honnête.

D'abord, l'arithmétique. Un squelette est un coût fixe que vous amortissez sur les instances suivantes. Sur un site unique que vous ne referez jamais, il ne s'amortit sur rien : le clone reste le bon choix, et construire un squelette serait de la sur-ingénierie. C'est à partir du moment où vous savez que vous allez en faire une série, campings, restaurants, cabinets d'avocats, peu importe, que le calcul bascule. Le squelette ne se justifie pas au premier projet, il se justifie quand vous voyez la série arriver. En pratique, ça donne un repère simple : vous ne l'extrayez pas au premier site, qui ne vous a rien appris de généralisable, mais au lancement du deuxième ; et il n'est vraiment remboursé qu'une fois le troisième sorti de lui, parce que c'est seulement là que le découpage cesse de bouger. Trois sites de la même famille, c'est en général le seuil où le calcul penche du bon côté.

Ensuite, ce n'est pas un choix binaire entre le clone crasseux et le squelette parfait. Entre les deux, il y a tout un continuum : un dépôt de départ versionné avec les correctifs déjà dedans, un thème parent, un boilerplate git, un starter kit maison. Chacun de ces paliers récupère une partie du bénéfice sans exiger l'investissement complet. Vous n'êtes pas obligé de construire l'app de déploiement de mon collègue pour arrêter de recopier des horaires faux. Commencer par un dépôt de base propre, c'est déjà sortir du pire.

Et il y a un coût qu'on oublie toujours, celui-là bien réel : la transmission. Un squelette dont l'auteur est parti, mal documenté, que personne ne comprend, devient une boîte noire pire qu'un clone. Au moins un clone, vous pouvez le lire de bout en bout. Un squelette opaque, le junior qui arrive le contournera en dupliquant, parce qu'il n'ose pas toucher à une machinerie qu'il ne s'explique pas. Un squelette n'a de valeur que lisible et transmis. Ce qui doit être rempli doit sauter aux yeux, au point qu'un simple grep sur un marqueur suffise à lister ce qu'il reste à faire. Et comme le départ de celui qui l'a construit n'est pas un risque mais une quasi-certitude en agence, protégez-le tant qu'il est encore compris : une courte note d'amorçage qui dit par où commencer, et le premier remplissage fait à deux plutôt qu'en solitaire, suffisent à ce que le squelette survive à son auteur. Sinon vous n'avez pas supprimé la dette, vous l'avez déplacée dans un endroit où plus personne ne sait la lire.

Ne l'extrayez pas trop tôt

Il reste un piège, à l'autre bout : vouloir le squelette dès le premier projet.

Le problème, c'est que sur le premier cas, vous ne savez pas encore ce qui varie vraiment d'une instance à l'autre. Vous croyez le savoir, et vous vous trompez sur ce qui compte. Chez moi, sur une famille de sites, l'axe déterminant s'est révélé être le nombre de langues. Sur le premier site, bilingue, il était complètement invisible : rien ne m'indiquait qu'il fallait le traiter comme un paramètre. Ce n'est qu'au deuxième site, trilingue, que l'axe est apparu. Si j'avais figé un squelette dès le premier, j'aurais figé le mauvais découpage, et j'aurais eu à le casser ensuite.

La règle que j'en tire : n'extrayez rien au premier cas, vous n'avez aucune matière pour généraliser. C'est toute la raison d'attendre le deuxième site dont je parlais plus haut : c'est seulement là que l'axe qui compte se montre enfin. Et si le bon découpage ne se stabilise que vers le troisième, ce n'est pas de la lenteur, c'est le temps qu'il faut aux vraies différences pour se révéler. Un squelette mûrit ; il n'est pas juste au premier essai.

« Vide » ne veut dire que ce que vous avez vidé

Un dernier point, parce que c'est celui qu'on oublie et celui qui rattrape.

Un squelette est aussi bon que sa neutralité, et cette neutralité n'est jamais gratuite. Le premier squelette que j'ai distillé, je l'avais extrait d'un projet existant en retirant son contenu. J'avais vidé ce qui sautait aux yeux : les textes, les noms, les images. Mais j'avais laissé un paramètre câblé en dur, hérité du projet d'origine, sans le marquer. Résultat : le site suivant s'est retrouvé rempli dans la mauvaise langue, parce que le squelette portait encore, en silence, un réglage de son projet parent.

La leçon tient en une phrase : « vide » ne vaut que pour ce que vous avez explicitement vidé. Un paramètre resté en place est un héritage silencieux, exactement comme les faits recopiés du clone, juste mieux caché. Quand vous distillez un squelette par soustraction, vérifiez chaque axe de variation un par un, et marquez ce qui doit être rempli. Ce qui n'est pas marqué sera hérité par erreur.

Ce que ça change, en jours

Je ne vais pas vous vendre une métrique bidon. Sur une famille de sites que j'ai produite, j'ai un ordre de grandeur, pas une mesure de labo : le premier site, celui qui défrichait tout, m'a demandé un gros travail étalé sur des jours, avec un changement de technologie complet en cours de route. Le deuxième, cloné du premier, nettement moins. Le troisième, produit à partir du squelette, est passé du dossier vide à la mise en ligne dans une seule session de travail. Grosso modo, l'effort par site divisé par un ordre de grandeur entre le premier et le troisième.

Prenez le chiffre pour ce qu'il est : une tendance, rien de plus. La vraie unité qui parle à un lead, c'est celle du collègue de l'agence : des semaines devenues des jours. C'est ça que vous portez à votre patron pour défendre le temps passé sur le squelette.

Alors la prochaine fois que vous vous apprêtez à dupliquer le dernier projet pour en faire un nouveau, posez-vous la seule question qui compte : qu'est-ce qui change vraiment d'un projet à l'autre ? Si vous savez y répondre, vous savez déjà ce qu'il faut vider. Et si vous ne savez pas encore, c'est peut-être qu'il est trop tôt, et qu'il faut d'abord faire le deuxième, pour de bon.