Pourquoi un manifeste, pas un portfolio
Un portfolio classique répond à une demande implicite : montre-moi ce que tu sais faire, puis je déciderai si tu m’intéresses. Ce site part d’un autre endroit. Il cherche à rendre lisible une posture : comment je pense le design leadership, comment je formalise des méthodes, comment j’apprends en travaillant avec des agents IA.
La différence change la fabrique. Un portfolio peut vivre sur quelques cas bien polis. Un manifeste doit tenir une voix, une architecture, des preuves et une capacité de mise à jour. Il ne suffit pas d’avoir de belles pages. Il faut que le système permette de continuer à penser publiquement sans tout reprendre à chaque fois.
Claude Code est entré par cette porte-là. Pas comme un outil magique pour générer un site, mais comme un binôme d’exécution capable d’aller vite si la direction était claire. Codex a pris le relais ensuite, avec un autre environnement et d’autres contraintes. Le vrai sujet est arrivé très vite : quand l’agent peut produire beaucoup, la qualité de ce qu’on lui donne devient le travail principal.
Le code-first comme apprentissage public
Le premier choc n’a pas été technique. Astro, Tailwind, MDX, GitHub, Vercel : chaque brique s’apprend. Le choc était ailleurs, dans le fait de construire en public, sur un vrai repo, avec des commits visibles, des hooks qui bloquent, des erreurs qui restent dans l’historique.
Pour quelqu’un qui ne vient pas du développement, le premier push Git n’est pas un détail. Il rend visible une posture : apprendre en faisant, accepter que l’apprentissage laisse des traces, ne pas attendre d’être experte pour tester. La phrase qui est restée de ce moment est simple : j’avais peur, c’était magnifique.
Cette vulnérabilité n’a pas été décorative. Elle a donné sa cohérence au site. On ne peut pas défendre la curiosité comme doctrine et cacher les endroits où l’on apprend encore. Le site devait donc montrer une compétence, mais aussi une façon de devenir plus compétente.
Les garde-fous avant le volume
Les premières semaines ont surtout servi à installer des limites. Pas parce que le projet était complexe techniquement, mais parce qu’un agent qui va vite amplifie aussi les flous. Sans garde-fous, chaque session redéfinit les conventions, la voix, la structure, la manière de publier.
Le système a pris forme par couches : une voix documentée, des règles de rédaction, un scanner qui signale les débuts de paragraphe interdits et les marqueurs trop automatiques, des hooks Git, commitlint, Prettier, ESLint, Astro check, des contrôles de parité entre les langues, puis une CI qui rejoue les mêmes barrières.
Ces outils ne remplacent pas le jugement. Ils libèrent de l’attention. Quand le linter surveille la syntaxe, quand le scanner de voix rappelle les écarts, quand le build refuse une page cassée, l’énergie peut revenir là où elle compte : l’angle, la preuve, la décision, la phrase qui porte vraiment quelque chose.
Une passe de craft, puis un retrait
La phase de craft visuel a produit plusieurs ajustements qui sont restés : typographie, rythme, dark mode, transitions, playground interne. Elle a aussi produit une expérimentation qui n’est pas restée. L’idée était de soutenir une lecture active : quand quelqu’un sélectionnait une phrase, le site gardait une trace locale et la faisait réapparaître à la visite suivante.
L’intention était bonne. Elle correspondait au contrat du site : lire, revenir, retrouver ce qui avait accroché. Mais l’implémentation touchait trop profondément au texte rendu. Pour surligner une sélection, il fallait découper le DOM, injecter des balises, gérer les espaces, les titres, les retours entre pages. Deux cycles de correction ont suffi à montrer le risque : résidus visuels, mise en page fragilisée, perte de stabilité sur des pages longues.
Le composant a été retiré. Pas parce que l’idée était mauvaise, parce que son coût de maintenance dépassait sa valeur. Cette décision compte autant que les composants gardés. Le craft n’est pas l’accumulation de gestes visibles. C’est aussi savoir retirer un effet quand il met en danger la qualité première d’un site éditorial : rester lisible.
Traduire, mettre en ligne, vérifier le réel
Début août, le projet a changé de nature. Tant que le site vivait en local, il restait un atelier. Une fois les contenus traduits en espagnol et en anglais, le domaine branché sur Vercel et la V1 en ligne, il est devenu une surface publique. Ce changement oblige à regarder autrement les détails.
La mise en production a révélé une leçon simple : le build de production fait foi. En développement, les brouillons restent visibles pour permettre la relecture. En production, seuls les contenus publiés sortent. Le playground existe en local, mais il est retiré du build public. Ce que l’on voit dans le navigateur pendant qu’on travaille n’est donc pas automatiquement ce que les autres verront en ligne.
La couche SEO est arrivée dans cette logique : canonical, hreflang, Open Graph, sitemap, robots.txt, llms.txt, données structurées. Pas comme une couche marketing ajoutée à la fin, mais comme une façon de dire correctement aux moteurs ce que le site est, dans quelles langues les pages existent, et quelles versions ne doivent pas être inventées.
Le bug que les checks verts n’ont pas vu
Un incident a rendu le système plus solide. Les versions espagnoles et anglaises de certains gabarits étaient restées plus pauvres que la version française après une refonte. Les traductions étaient en parité, le build passait, les checks étaient verts. Pourtant, les pages ne racontaient pas la même chose visuellement.
Le problème n’était pas l’absence de contrôle. C’était le mauvais contrôle pour ce risque précis. La parité i18n vérifiait les clés de traduction, pas la forme des pages. Le correctif a donc ajouté deux garde-fous : un contrôle qui compare les gabarits [slug].astro entre langues, et un contrôle qui compare la structure des pages générées dans dist/.
Cette partie résume une grande part de l’apprentissage. Un garde-fou ne prouve que ce qu’on lui demande de mesurer. Si la direction doit survivre à plusieurs semaines de travail, à plusieurs langues, à plusieurs agents et à plusieurs sessions, elle doit devenir vérifiable.
Ce que ce site prouve maintenant
Quelques semaines après la mise en ligne, le site n’est plus seulement un récit d’apprentissage. Il est devenu la preuve de sa propre méthode. Les contenus vivent dans des collections MDX. Les pages publiques se construisent depuis une source claire. Les traductions peuvent arriver sans casser les slugs. La production se vérifie avec une procédure documentée. Les erreurs découvertes deviennent des tests.
Claude Code a accéléré les premières semaines. Codex porte maintenant la suite. Cette bascule n’est pas un détail d’outillage, elle dit quelque chose du système : si la méthode ne tient qu’avec un agent précis, ce n’est pas encore une méthode. Le sujet reste la direction : savoir quoi demander, quoi refuser, quoi documenter, quoi tester, quoi retirer. Un agent peut produire du code. Il ne sait pas, seul, ce qui doit rester vrai dans six mois.
C’est là que le projet devient intéressant pour le design leadership. Le design-to-code n’est pas seulement une nouvelle vitesse de production. C’est une nouvelle responsabilité de cadrage. Plus l’outil exécute vite, plus la qualité du système autour de lui devient visible.