J’ai réfléchi à ce blog pendant deux ans.
Dire « vouloir » n’est pas tout à fait exact, c’est plutôt une obsession. Au début, je ne savais pas écrire de code front‑end ou back‑end, ni de code embarqué, et c’est à cette époque que cela a commencé. Je bricolais encore avec l’électronique et, par hasard, j’ai découvert la vidéo B‑Station et le site de @ushio; cela m’a paru très amusant et j’ai voulu essayer moi‑même. J’ai ensuite passé environ six mois à apprendre le C et un peu de JS/CSS depuis zéro, et avec Hexet j’ai monté un blog statique hébergé sur GitHub Pages, ce qui peut être considéré comme mon petit coin de paradis.
再后来，看到了 @Innei 的小站，设计很精致、功能也很全，当时的我看了一眼我就想要，甚至还赞助支持了，虽然后面没用上但是这钱也花的不怨 因为我摸到了 React 源码，就和我最初看到 C 一样，不过就是代码嘛，有什么大不了的，总有一天我要自己写一个。
Plus tard, j’ai découvert le petit site de @Innei : son design est très soigné et ses fonctionnalités très complètes. En le voyant, j’ai tout de suite eu envie de l’obtenir, au point même de le soutenir financièrement. Même si je ne l’ai jamais réellement utilisé, je ne regrette pas cet argent dépensé, car cela m’a permis d’explorer le code source de React, ce qui m’a rappelé la première fois où j’ai découvert le langage C. Ce n’est « juste » du code, rien de plus. Un jour, je suis convaincu que j’écrirai le mien.
Forêt calme
C'était l'année 2024, puis 24, 25, 26 ans jusqu'à présent
Depuis, cela ne s’arrête plus.
Hors de contrôle
Au départ, je voulais simplement ajouter un bascule clair/sombre au thème Hexo Nlvi de @colmugx. J’ai bourré un petit script JavaScript à la Dark Reader – c’était moche et je n’étais pas satisfait. Ensuite, j’ai appris le CSS @media, je suis passé à un bascule SPA en JS, j’ai testé la classe .dark de TailwindCSS, puis le SSR avec next‑theme, et enfin j’ai bricolé un script inline Cookie + Head Sync pour éliminer le scintillement FOUC. J’ai fini par essayer quatre ou cinq solutions différentes.
Mais ce n’est que la partie visible de l’iceberg. Après avoir découvert React, je suis passé de l’époque primitive avec Hexo et Vanilla JS à Next.js 13 Page Router, puis je me suis tourné vers Vue, étudié le routage SPA, compris le fallback index.html, et créé d’innombrables projets. J’ai acheté un serveur, bricolé avec Docker, Nginx, NAS ; trouvant 1Panel inesthétique, j’ai écrit moi‑même le panneau Canopy, exploré les matrices de stockage NAS et développé RFS. En gérant le SSL, l’environnement local rendait acme.sh si pénible que j’ai fini par écrire un reverse‑proxy en Rust : Vane & Lazyacme. Ce qui était au départ un projet « junk » de 800 lignes réalisé en trois heures un soir est devenu, après les encouragements d’un ami, quatre mois de travail, y intégrant HTTP/3, Zero‑Copy, le modèle Layer et le moteur Flow. Plus tard, il y a aussi Seam, un framework full‑stack qui est également un vrai cauchemar — j’en parlerai plus tard.
Sur‑ingénierie
Puis l'ère de l'IA est arrivée, et l'anxiété a doublé.
Le plus ironique, c’est que ces choses auraient dû être réalisées en même temps que le blog, en les consignant au fur et à mesure. Mais le blog a été abandonné à plusieurs reprises, les idées se sont multipliées et il n’y avait nulle part où les enregistrer. D’un côté, mon intérieur me réprimande ; j’avais promis de terminer Vane, mais je n’ai pas pu, j’ai dû m’arrêter. De l’autre, un sentiment d’impuissance grandit à mesure que je m’éloigne. Je me souviens toujours de ce que je veux faire, mais je n’y parviens pas. En y réfléchissant, je réalise que cela fait longtemps que je ne me suis pas assis pour écrire quoi que ce soit. En y repensant maintenant, tout cela pointe vers la même chose — le sur‑ingénierie.
À l'époque, je ne pensais vraiment pas que je m'écartais. Vane ? De toute façon, le blog devra être déployé plus tard, il faut donc un reverse proxy. Seam ? Vu que je finirai par écrire du full‑stack, autant mettre en place dès maintenant le framework que j'imagine. Chaque étape a une raison, chaque étape est « utile plus tard ». Mais le problème, c’est que « plus tard » n’arrive jamais, parce que je n’ai jamais commencé…
Échec
Créer un blog ne nécessite en réalité ni proxy inverse, ni framework maison. Pourtant, à l'époque, je les considérais comme des conditions préalables, comme une excuse toujours bloquante mais apparemment raisonnable, alors qu'elles ne l'étaient jamais. La seule vraie condition préalable est simple : asseyez‑vous et écrivez votre premier article.
En réalité, le blog n'est pas resté inactif ; au contraire, je l'ai fait trois fois.
La première fois était à l'époque du Next.js 13 Page Router. À ce moment-là je ne comprenais même pas ce qu'était une SPA, et les concepts SSR, SSG, ISR me étaient totalement inconnus, mais comme les autres disaient que le SSR était bon, j’ai voulu l’utiliser aussi. Au fil de l’écriture, je me suis rendu compte que je ne comprenais pas quels problèmes ces architectures résolvaient, et je n’ai plus pu poursuivre. Ensuite, je suis passé à une SPA pure avec Vue 2. Pourquoi Vue ? Honnêtement, le nom me plaisait, il était nouveau, alors je l’ai essayé. Ça n’a pas duré longtemps. La troisième fois, je suis revenu à React, en partant du simple JSX, j’ai appris TypeScript, maîtrisé le TSX, compris la différence entre CJS et ESM, je suis tombé amoureux du paradigme réactif et j’ai commencé à utiliser Lucide, Framer Motion, Radix UI, des bibliothèques dont je ne peux plus me passer — cette fois, ça ressemblait enfin à quelque chose de cohérent. Mais j’ai quand même échoué, car en réalité je ne faisais qu’imiter : je prenais ce que les autres utilisaient, cela semblait correct en apparence, mais je ne comprenais pas pourquoi cela devait être fait ainsi. En plus, avec les hallucinations de l’IA, on pouvait faire fonctionner un MVP, mais lors du passage à l’échelle, c’était un champ de mines.
Plus tard, j’ai aussi appris React (Remix) Router Loader, le Next.js 15 App Router et RSC, mais à ce moment-là, mon quotidien était déjà très chargé, je n’avais guère de temps pour coder et je n’ai même pas eu l’occasion d’échouer une quatrième fois. En y repensant, mon site est passé de Next.js 13 à Next.js 15 ; j’avais à peine fini la migration et, avant même de le mettre en ligne, Next.js 16 beta‑1 était déjà sorti.
Lâcher prise
Dire « 想开了 » n’est pas exact ; c’est simplement que je suis fatigué·e.
Le rythme de l’ère de l’IA est trop rapide. Les modèles s’enchaînent les uns après les autres, de nouvelles technologies émergent continuellement, et je deviens de plus en plus anxieux, comme si s’arrêter signifiait être dépassé. Au plus fou, j’ai écrit 16 petits morceaux de code en un jour ; les tokens pouvaient brûler 1 900 $ USD en une journée (vers février), et j’étais sur le point de perdre la tête. Mais ce qui a tout arrêté n’était pas une illumination, simplement la fatigue pure. Dans ce rythme toujours plus pressé, la dernière paille a fini par me faire céder, et j’ai ressenti un soulagement, me suis ouvert, j’ai abandonné la lutte ; ainsi, c’est en fait assez bien.
J’ai commencé à lâcher prise. J’ai abandonné les choses auxquelles j’étais autrefois accro, appris à m’arrêter au bon moment, et à remettre à demain ce qui peut attendre. Vane n’est pas terminé ? On le laisse de côté pour l’instant. Seam est encore loin d’être fini ? On y reviendra plus tard. Le blog n’est pas parfait ? On le publie d’abord. Commencez à faire du Vibe Coding à fond ; s’il n’y a pas de problème, on ne s’en occupe pas, sinon on en parlera plus tard.
Étrangement, la qualité ne s’est pas détériorée après avoir laissé aller. Je pense que c’est probablement parce que les jours de programmation « 古法 » n’ont pas été vains ; dès l’époque GPT‑2, j’ai commencé à utiliser l’IA, mais à l’époque je rédigeais chaque ligne de code avec soin et comprenais chaque concept. Cette expérience m’a donné une base, et plutôt que d’appeler cela Vibe Coding, on pourrait parler de Context Coding ; le jugement nécessaire est toujours présent, et le fait de lâcher prise n’a pas entraîné d’erreurs basiques ni d’accidents.
Tous les tracas précédents m'ont donné le capital de pouvoir lâcher prise maintenant.
Origine
La solution finale est en fait très simple : All in Cloudflare. Stockage d’objets R2, base de données D1 Edge, KV pour le cache, Worker exécute le SSR, tout est sans serveur, il n’y a pas de serveur.
Cette réponse est‑elle sarcastique ? Très sarcastique. Parce qu’avant d’atteindre cette « simple » destination, j’ai fait tout un détour. J’avais prévu de tout héberger moi‑même, il fallait donc gérer le serveur, bidouiller Docker, gérer les conteneurs, alors j’ai écrit Canopy comme panneau d’administration, Lazycert pour la gestion des certificats, Vane comme proxy inverse, et Twig pour les points d’injection de surveillance des ressources. Une pile de projets, uniquement pour servir un serveur poubelle.
Le stockage est similaire. Je trouve le stockage d’objets trop cher, alors j’ai voulu utiliser les disques durs de mon propre serveur, et j’ai donc écrit RFS, un VFS permettant une déduplication atomique et la fusion de fichiers uniques, voire ressuscitant le concept de registre des années 80‑90, avant de le monter via FUSE. Le résultat ? J’ai passé encore plus de temps à fabriquer une roue pas très efficace, le serveur est resté inactif pendant un an, c’est devenu une affaire totalement déficitaire.
En fin de compte, après un long détour, je reviens au serverless. Le concept de Vercel est bon, mais je n’aime pas Next.js ; de plus, Vercel recourt à trop de « magie », et le design du middleware pré‑compilé pour s’exécuter sur l’Edge finit par être fragmenté, voire à l’origine de plusieurs CVE. Il vaudrait mieux tout centraliser sur l’origine. En revanche, Cloudflare Workers est excellent : il atteint un autre extrême en compilant des produits de moins de 10 Mo en WASM, capables d’exécuter la véritable logique métier sur l’Edge, exactement ce que je recherche. En dehors du coût, il n’y a vraiment aucun inconvénient – même si ce n’est pas vraiment un défaut, car le temps économisé représente de l’argent.
Moins, c’est plus
J'ai entendu cette phrase d'innombrables fois, mais il m'a fallu deux ans pour en saisir réellement le sens.
L’essence du retour à l’ingénierie est : « Make it function, make it correct, then make it exceptional. ». J’ai enfin repris le bon chemin et l’ai rendu functional. Mon blog est‑il rudimentaire ? Oui, il l’est. Incomplet ? Effectivement incomplet. Mais cela vaut mieux que rien. Si vous n’avez même pas de mise en ligne et que vous continuez à travailler sur ce qui est « peut‑être nécessaire », en poursuivant une perfection invisible, vous finirez par n’avoir rien à présenter. Ce n’est pas un compromis, c’est un compromis d’ingénierie. Quoi qu’il en soit, j’ai fini par l’accepter. Donc je l’ai accepté. Je ne suis plus obsédé par un détail, j’ai plutôt quitté la maison. Mon album photo n’a pas eu de photo en plein air depuis longtemps, alors j’ai rapidement pris une photo du bord de la route — cela fait longtemps que je ne suis pas sorti.
En repensant aux détours que j’ai pris auparavant, est‑ce que je le regrette ? Non, je ne le regrette pas. Certaines choses, si vous ne les essayez pas vous‑même, resteront peut‑être incompréhensibles pour toujours. D’autant plus qu’à l’ère de l’IA, essayer de suivre le vieux chemin que je parcourais autrefois n’est plus vraiment possible ; de nombreux flux de travail ont déjà changé. En outre, ce projet est Taki, 100 % de codage assisté par IA, mais cela ne signifie pas qu’il ne peut pas être maintenu sur le long terme, ni qu’il manque de chaleur humaine. En réalité, la présence ou non d’IA n’a pas d’importance, et de plus, ce que j’aime n’est pas tant d’écrire du code en soi, mais de construire quelque chose…