J’ai réfléchi à ce blog pendant deux ans
Dire que j'y « pensais » n'est pas tout à fait exact, c'était plutôt une obsession. Elle était déjà là à l'époque où je ne savais écrire ni frontend ni backend, ni le moindre code embarqué. Je bricolais encore de l'électronique quand je suis tombé par hasard sur les vidéos de @ushio sur et sur son site, et me suis dit que c'était génial et que j'en voulais un aussi. J'y ai passé ensuite près de six mois : j'ai appris le C en partant de zéro, un peu de JS et de CSS, et j'ai monté un blog statique avec Hexo déployé sur Github Pages. J'avais enfin mon petit coin à moi.


Plus tard, je suis tombé sur le site personnel de @Innei. Son design était très soigné et ses fonctionnalités complètes ; il m’a suffi d’un regard pour le vouloir, au point que j’ai même soutenu financièrement le projet. Bien que je n’aie finalement pas pu m’en servir, je ne regrette pas cet argent, car cela m’a permis de mettre la main sur le code source de React. Comme lorsque j’avais découvert C pour la première fois, je me suis dit : ce n’est jamais que du code, après tout, rien d’insurmontable. Un jour, j’en écrirai un moi-même.

C’était en 2024, puis il y a eu 24, 25 et 26, jusqu’à aujourd’hui
Depuis, plus rien ne peut l’arrêter.
Hors de contrôle
Au départ, je voulais seulement ajouter une bascule clair/sombre au thème Hexo Nlvi de @colmugx. J'en ai bricolé une avec le JS de Dark Reader : moche, ça ne me convenait pas. Ensuite j'ai appris @media en CSS, puis la bascule en JS côté SPA, puis la .dark class de TailwindCSS, puis next-theme en SSR, et pour finir j'ai un Cookie plus un script inline de Head Sync pour supprimer le scintillement du FOUC. Quatre ou cinq approches en tout.

Mais ce n’était que la partie émergée de l’iceberg. Après avoir découvert React, je suis passé de l’âge de pierre avec Hexo et du JavaScript natif au routeur de pages de Next.js 13, avant de faire un détour par Vue, d’étudier le routage des applications monopages, de comprendre le mécanisme de repli vers index.html et de recréer le projet un nombre incalculable de fois. J’ai acheté un serveur et bricolé avec Docker, Nginx et un système de stockage en réseau ; trouvant 1Panel laid, j’ai écrit moi-même le panneau Canopy, puis j’ai étudié les grappes de stockage et créé RFS. Enfin, les caprices d’acme.sh dans l’environnement chinois m’ont tellement fait souffrir lors de la configuration des certificats SSL que j’ai fini par écrire en Rust un serveur mandataire inverse : Vane & Lazyacme. Au départ, ce n’étaient que huit cents lignes de code poubelle écrites en trois heures un soir, mais des amis d’un groupe de discussion m’ayant poussé à continuer, j’y ai travaillé quatre mois et y ai entassé HTTP/3, la copie zéro, un modèle en couches et un moteur de flux. Il y a ensuite Seam, un framework full-stack qui constitue lui aussi un gouffre sans fond, mais ce sera pour une autre fois.
Suringénierie
Puis l’ère de l’IA est arrivée, et mon anxiété a de nouveau doublé.
Le plus ironique, c'est que tout cela aurait dû se faire après le blog, en le documentant au fur et à mesure. Au lieu de quoi le blog a été , les idées se sont accumulées, et il n'existait aucun endroit où les consigner. D'un côté, ma conscience m'accusait sans relâche : tu as dit que Vane serait fini, donc tu ne peux pas t'arrêter. De l'autre, un sentiment d'impuissance qui grandissait à mesure que je m'éloignais. J'ai toujours su ce que je devais faire, je n'arrivais simplement pas à le faire. À bien y réfléchir, cela fait très longtemps que je ne me suis pas assis pour écrire quoi que ce soit. Avec le recul, tout cela pointe vers la même chose -- la suringénierie.
À l’époque, ce n’est pas que je ne me rendais pas compte que je m’égarais. Vane ? De toute façon, il faudrait bien déployer le blog un jour, donc il me faudrait forcément un serveur mandataire inverse. Seam ? Puisque je devrais tôt ou tard développer toute la pile, autant commencer par créer le framework idéal à mes yeux. Chaque étape avait sa raison d’être, et tout allait « servir plus tard ». Mais le problème, c’est que ce « plus tard » n’arriverait jamais, puisque je n’avais même jamais commencé...
Échec
En réalité, créer un blog ne nécessite ni proxy inverse ni framework maison. Pourtant, à l’époque, j’en avais fait des prérequis et une justification qui semblait raisonnable tout en m’empêchant indéfiniment d’avancer. Mais ils n’en avaient jamais été. Il n’existait qu’un seul véritable prérequis : m’asseoir et écrire le premier article.
En réalité, ce n’est pas que je n’avais jamais travaillé sur le blog. Bien au contraire, je m’y suis essayé trois fois.

Ma première tentative remontait encore à l’époque du Page Router de Next.js 13. À ce moment-là, je comprenais à peine ce qu’était une application monopage et ne maîtrisais aucun des concepts comme le SSR, le SSG ou l’ISR. Mais puisque les autres disaient que le SSR était une bonne chose, je voulais moi aussi l’utiliser. À mesure que j’avançais, j’ai fini par constater que je ne comprenais absolument pas quels problèmes ces architectures étaient censées résoudre, et je n’ai pas pu continuer. Plus tard, je suis passé à une application monopage pure sous Vue 2. Pourquoi Vue ? J’ai honte de l’avouer, mais j’aimais bien le nom et, puisque c’était de toute façon nouveau pour moi, je me suis dit que je pouvais essayer. Cela n’a pas duré longtemps non plus. Pour ma troisième tentative, je suis revenu à React en commençant par du JSX simple. J’ai appris TypeScript et maîtrisé TSX, compris la différence entre CJS et ESM, découvert une passion pour la programmation réactive et adopté des bibliothèques comme Lucide, Framer Motion et Radix UI, dont je ne pourrais plus me passer par la suite — cette fois, le résultat commençait enfin à ressembler à quelque chose. Pourtant, j’ai encore échoué, car au fond je ne faisais qu’imiter les autres : j’utilisais tout ce qu’ils utilisaient. Cela semblait convaincant, mais en réalité je ne comprenais absolument pas pourquoi il fallait procéder ainsi. En y ajoutant les hallucinations de l’IA, je pouvais faire fonctionner beaucoup de choses sous la forme d’un produit minimum viable, mais dès qu’il fallait passer à l’échelle, les pièges étaient partout.

Plus tard, j’ai aussi appris à utiliser les loaders de React (Remix) Router, l’App Router de Next.js 15 et les RSC, mais mon quotidien était alors devenu si chargé que je n’avais presque plus le temps de coder — et donc aucune occasion d’échouer une quatrième fois. Avec le recul, j’ai développé mon site de Next.js 13 jusqu’à Next.js 15 ; je venais à peine d’achever la migration et ne l’avais même pas encore mis en ligne que Next.js 16 beta 1 est sorti.
Lâcher prise
Dire que j’avais « lâché prise » n’est pas tout à fait exact : j’étais simplement fatigué.

Le rythme de l'ère de l'IA est trop rapide. Les modèles s'enchaînent, itération après itération, les nouvelles techniques surgissent vague après vague, et je devenais de plus en plus anxieux, comme si m'arrêter suffisait à me faire dépasser. Au plus fou, j'écrivais du code seize heures par jour et je pouvais brûler $1.9k USD de Token en une journée (vers février, je crois) ; j'étais presque foutu. Mais ce qui a tout arrêté n'était pas une illumination, seulement de la fatigue. Sous un rythme qui se resserrait toujours, la dernière goutte est tombée, et au contraire je me suis apaisé, j'ai lâché prise, j'ai ; et comme ça, c'est très bien aussi.
J’ai commencé à lâcher prise. J’ai renoncé à ce qui m’obsédait autrefois, appris à m’arrêter quand c’était suffisant et décidé que les problèmes de demain attendraient demain. Vane n’est pas terminé ? Je le laisse de côté pour l’instant. Seam est encore loin du compte ? J’y reviendrai plus tard. Le blog n’est pas parfait ? Je le mets d’abord en ligne. Je me suis mis entièrement au Vibe Coding : tant qu’il n’y a pas de problème, je n’y touche pas ; s’il y en a un, je m’en occuperai le moment venu.
Le plus étrange, c'est que la qualité n'a pas baissé une fois que j'ai lâché prise. Je crois que c'est parce que ces journées de programmation n'ont pas été perdues. J'utilisais déjà l'IA à l'époque de GPT-2, mais j'écrivais encore consciencieusement chaque ligne de code et je comprenais chaque concept. Cette période m'a donné mes bases. Ce qui a suivi tenait moins du Vibe Coding que du Context Coding : le discernement nécessaire était toujours là, et lâcher prise ne m'a valu ni erreur grossière ni accident.
Ce sont toutes mes expérimentations passées qui me permettent aujourd’hui de lâcher prise.
Point de départ
La solution finale s’est révélée étonnamment simple : tout sur Cloudflare. R2 pour le stockage d’objets, D1 comme base de données en périphérie, KV pour la mise en cache et Worker pour le rendu côté serveur ; le tout sans serveur, avec zéro serveur.

Cette réponse est-elle ironique ? Terriblement. Car avant d’atteindre cette destination « simple », j’ai fait un immense détour. J’avais autrefois prévu de tout auto-héberger, ce qui impliquait d’administrer un serveur, de batailler avec Docker et de gérer des conteneurs. J’ai donc écrit Canopy comme panneau d’administration, Lazycert pour gérer les certificats, Vane comme proxy inverse et Twig pour instrumenter la surveillance des ressources. Tout un tas de projets, uniquement pour servir un serveur minable.
Même histoire pour le stockage. Je trouvais le stockage objet trop cher et voulais utiliser le disque dur de mon propre serveur. J’ai donc écrit RFS, un VFS qui dédupliquait les données de façon atomique et les regroupait dans un fichier unique. J’ai même ressuscité le concept de registre des années 1980 et 1990, avant de monter le tout via FUSE. Résultat ? J’ai passé encore plus de temps à réinventer une roue moins bonne, tandis que le serveur tournait à vide pendant un an : une opération totalement déficitaire.

Après un long détour, je suis finalement revenu à l’informatique sans serveur. Le concept de Vercel est bon, mais je n’aime pas Next.js ; Vercel repose aussi sur beaucoup trop de magie, et son architecture de logiciel intermédiaire, précompilé pour s’exécuter en périphérie du réseau, finit malgré tout par fragmenter le système et a même donné lieu à plusieurs CVE. Autant tout exécuter ensemble sur le serveur d’origine. Cloudflare Workers, en revanche, est excellent et pousse les choses vers un autre extrême : les artefacts de moins de 10 Mo sont compilés en WASM, ce qui permet d’exécuter une véritable logique métier en périphérie. C’est exactement ce que je veux. Son seul défaut est son coût — mais à bien y réfléchir, ce n’en est pas vraiment un, puisque le temps gagné, c’est de l’argent.
Moins, c’est plus
J’avais entendu cette phrase un nombre incalculable de fois, mais il m’a fallu deux ans pour en comprendre véritablement le sens.
Revenir à l’essence de l’ingénierie : « Make it function, make it correct, then make it exceptional. » J’ai enfin retrouvé la bonne voie et réussi à le faire fonctionner. Le blog est-il rudimentaire aujourd’hui ? Oui. Incomplet ? Assurément. Mais c’est toujours mieux que rien. Si tu n’as encore rien mis en ligne, que tu continues à fabriquer ce dont tu auras « peut-être besoin » et à poursuivre une perfection invisible, tu finiras par ne rien avoir à montrer. Ce n’est pas un compromis, mais un arbitrage d’ingénierie. Quoi qu’il en soit, j’ai appris à lâcher prise. Alors j’ai lâché prise. En cessant de m’obstiner sur un seul détail, j’ai fini par franchir la porte. Cela faisait longtemps que mon téléphone ne contenait plus aucune photo prise dehors, alors j’en ai pris une à la volée au bord de la route — cela faisait vraiment longtemps que je n’étais pas sorti (

Quand je repense aux détours que j’ai faits, est-ce que je les regrette ? Non. Il y a des choses que l’on ne comprendra peut-être jamais sans les essayer soi-même. D’autant qu’à l’ère de l’intelligence artificielle, il est désormais presque impossible de reprendre la vieille voie que j’avais suivie autrefois : trop de processus de travail ont changé. Et puis il y a ce projet, Taki, dont tout le code a été produit avec l’intelligence artificielle. Cela ne signifie pas pour autant qu’il ne puisse pas être maintenu sur le long terme ni qu’il manque d’humanité. Au fond, le recours ou non à l’intelligence artificielle importe peu. D’ailleurs, ce que j’aime, ce n’est pas écrire du code en soi, mais créer quelque chose...