Je sais où je veux aller, mais je ne sais pas encore où je dois m'arrêter.
Le contexte
Ce site internet, celui que vous lisez, est mon projet le plus exposé : c'est souvent la première chose qu'un prospect regarde avant de me confier la création du sien. Je voulais un site web pour être visible et montrer ce que je fais, rien de plus compliqué au départ. Mais je voulais aussi qu'il soit honnête, vrai du premier mot au dernier.
Douze pages, deux thèmes obligatoires dès le départ, aucun prix affiché nulle part, un seul canal de conversion, le formulaire de contact. Avant d'écrire une ligne de code, on a maquetté l'ensemble : palette de couleurs, composants, une cohérence pensée entre les pages plutôt que page par page.
Le problème
Maquetter en amont paraît être une étape de plus avant de vraiment commencer. C'est l'inverse : sans une vue d'ensemble, chaque page se code en réagissant à la précédente, et un perfectionniste (je le suis) passe des heures sur des détails qui ne rapportent rien, faute de savoir où s'arrêter. Le risque n'était pas de manquer d'idées, mais d'en garder trop.
Ce que le maquettage a permis de trancher
- Voir les limites avant de les coder. — Un ensemble maquetté et cohérent montre vite ce qui ne tient pas la route à l'usage, avant d'y avoir investi du code.
- Réduire un perfectionnisme trop présent en développement. — Face à une maquette déjà posée, l'arbitrage se prend une fois, en amont, plutôt qu'à chaque ligne écrite.
- Repousser le hero animé en 3D. — Je voulais à l'origine un hero animé, modélisé sous Blender. J'ai préféré une V1 plus simple, pour voir d'abord si le site attire et transforme. La scène est arrivée ensuite, une fois le site en ligne.
Ce que j'ai construit
- Un contrôle automatique qui interdit aux pages de diverger. — Douze pages, écrites à des moments différents. Un script bloque toute couleur écrite en dur et toute valeur de mise en forme improvisée, pour que chaque page reste construite sur le même jeu de règles, dans les deux thèmes.
- Un formulaire de contact protégé sans jamais renseigner un robot. — Trois filtres anti-spam successifs, tous conçus pour répondre comme un succès même quand ils rejettent un envoi, afin de ne jamais donner à un robot l'information qui lui permettrait de s'ajuster.
- Un hero en 3D qui n'alourdit pas la page. — Un feu de camp modélisé sous Blender et affiché avec Three.js. La scène ne se charge qu'après l'affichage de la page, et reste une image fixe pour qui a réduit les animations, n'a pas de WebGL ou n'a qu'un rendu logiciel. PageSpeed mobile en production, 95.
La décision dont je suis fier
Le process : maquetter avant de coder, et m'y tenir même quand une idée arrivait en cours de route.
Le hero animé en 3D en est le meilleur exemple. C'était mon idée de départ, et j'aurais pu m'y lancer directement. Je l'ai reposée pour une V1 plus simple : voir d'abord si le site attire et transforme, avant d'investir du temps dans quelque chose qui ne rapporte peut-être rien. Une fois le site en ligne, je l'ai ajoutée, en veillant à ce qu'elle ne ralentisse pas la page. Ce que je retiens de ce chantier, c'est d'avoir décidé en amont ce que je ne coderais pas encore, plutôt que de le découvrir à mi-chemin.