Pourquoi j'ai refait mon propre site en dernier
Le cordonnier est toujours le plus mal chaussé — pendant que je soignais les sites de mes clients, le mien attendait en dernier de la liste.
Le cordonnier et ses chaussures. Je l'ai vécu.
Sassify.fr — le site qui présente tous mes projets — est resté longtemps dans un état que je n'aurais pas accepté pour un client. Pas cassé, pas honteux, mais pas à la hauteur de ce que je voulais montrer. Pendant ce temps, je sortais des landing pages pour FlySmart, Skinalyze, Tifo, Plotline. Je passais des soirées sur la qualité de la prose de csvtoppt. Et mon propre site ? Dernier de la liste, systématiquement.
La vraie raison, elle est simple
Quand tu travailles en solo sur plusieurs projets en parallèle, chaque heure a un coût d'opportunité. Refaire mon site ne génère pas de signal produit. Ça ne valide pas une hypothèse. Ça ne fait pas tourner un pipeline de collecte. Aucun utilisateur n'attend cette mise à jour.
Alors à chaque fois que je rouvrais le sujet, je le refermais. Pas par procrastination — enfin, pas seulement — mais parce qu'il y avait toujours quelque chose de plus utile à faire sur un vrai produit.
Le problème, c'est que cette logique est correcte à court terme et bancale à long terme. Un site qui présente mal ce que tu fais, ça freine des conversations qui n'ont jamais lieu. Difficile à mesurer, facile à ignorer.
Ce qui a tout débloqué
Ce n'est pas une révélation. C'est juste que j'ai atteint un seuil où le portefeuille avait assez de substance pour mériter une présentation digne de ce nom. FlySmart en collecte de données. Skinalyze en production B2B. Tifo avec ses premiers contacts. Plotline qui tourne pour mes propres comptes. Il y avait enfin quelque chose à raconter.
Refaire le site sans matière, c'est une page blanche déguisée en vitrine. Refaire le site avec six projets à documenter, c'est un travail éditorial concret.
J'ai donc abordé la refonte comme n'importe quel autre projet Sassify : contexte → décision → résultat. Qu'est-ce que le site doit faire ? Montrer que je construis des choses réelles, que je documente le processus, et que je suis quelqu'un avec qui on peut travailler. Pas une liste de technologies maîtrisées. Pas un portfolio figé.
Ce que ça a changé dans ma manière de travailler
Travailler sur son propre site quand on est développeur solo, c'est un exercice bizarre. Tu es à la fois client et prestataire, avec tous les défauts des deux. Le client est trop exigeant sur les détails. Le prestataire bâcle les décisions stratégiques parce qu'il n'y a personne pour les challenger.
Ce que j'ai appris à faire sur les autres projets — coucher par écrit le pourquoi avant de toucher au code, documenter les décisions pendant qu'elles sont fraîches — m'a aidé ici aussi. Avoir une STORY.md pour chaque projet avant de rédiger quoi que ce soit sur le site m'a forcé à articuler ce qui comptait vraiment dans chacun d'eux.
Le résultat est un site qui reflète mieux où j'en suis : quelqu'un qui construit en public, qui documente ses arbitrages, et qui préfère montrer l'état réel d'un projet plutôt qu'une version polie de ce qu'il voudrait qu'il soit.
Pas parfait. Mais honnête. Ce qui, pour moi, compte plus.