Le gabarit : ne mets jamais ta vie dans ton code

Une leçon d'ingénierie, payée en trois jours. On la partage pour qu'elle vous coûte moins cher.

En bref : quand on construit un outil pour soi, ses propres données finissent par se glisser dans le code. Le jour où on veut le montrer à quelqu'un d'autre, on ne peut plus : montrer l'outil, c'est montrer sa vie. Le gabarit règle ça — et pour de bon.

Le piège de l'outil qu'on aime

On commence un projet pour soi. Alors on le remplit avec ce qu'on a sous la main : ses vrais projets, ses vrais contacts, son vrai parcours. C'est normal, c'est même ce qui le rend utile tout de suite. Sauf qu'à force, ces données ne sont plus dans l'outil : elles sont collées au code. On installe le module, et il repose ses données — les vôtres — comme au premier jour.

Tant que l'outil reste pour vous, tout va bien. Le problème arrive le jour où vous voulez le montrer. Une démo, un client, un ami curieux. Là, chaque écran affiche votre vie : vos projets en cours, votre à-faire, vos notes. Impossible de montrer sans se déshabiller.

Le piège qui se cache derrière

On se dit : facile, j'enlève mes données. On les retire… et la moitié de l'outil s'éteint. Parce que d'autres morceaux — des écrans, des assistants, des raccourcis — dépendaient de ce module qui portait vos données. En arrachant vos données, on a arraché les fonctions avec.

C'est le vrai coût de mélanger deux choses qui n'ont rien à faire ensemble : le code, qui est réutilisable, et les données, qui n'appartiennent qu'à vous. Collés, ils tombent ensemble.

Le gabarit : séparer ce qui se réutilise de ce qui vous appartient

Un gabarit, c'est un moule vide. Le module fournit la forme — les écrans, la logique, les fonctions — et rien d'autre. Les données, elles, arrivent à côté : ou bien génériques (des exemples neutres, « Site vitrine client », « Application mobile »), ou bien celles que la personne saisira elle-même.

Concrètement : à l'installation, l'outil doit rendre une coquille propre. Pas vos projets. Pas votre nom. Des exemples si on veut montrer à quoi ça sert, ou rien du tout. Vos vraies données, elles, se posent après, dans votre instance à vous — jamais dans le code que tout le monde installe.

La règle, en une phrase : un module doit pouvoir être installé par n'importe qui et donner une page vide et neutre — jamais votre vie.

Le bonus qu'on n'avait pas vu venir

En rendant le module générique, on ne répare pas seulement la démo. On répare aussi tous les futurs : le prochain qui installera l'outil n'héritera pas de vos projets non plus. Ce qui semblait une corvée de nettoyage était en fait la bonne façon de construire depuis le début.

Ce que ça nous a appris

Trois jours à tourner autour d'une démo qu'on n'arrivait pas à rendre montrable, sans comprendre pourquoi. La cause tenait en une phrase : on avait mis notre vie dans notre code. La leçon, elle, est simple, et maintenant elle est gratuite pour vous :

À retenir : ne mélangez jamais du code réutilisable et des données personnelles. Le code se partage, les données non. Séparez-les dès le premier jour — et votre outil sera montrable, vendable, et prêt pour le prochain, sans jamais trahir personne.