Pendant la plus grande partie de onze années, mon réflexe dès qu'il fallait un backend était d'en écrire un. Non pas parce que c'était le bon choix à chaque fois, mais parce que construire est la partie que j'aime et que j'étais assez bon pour me permettre cette habitude. Longtemps, cette habitude a été un impôt que je payais à mon propre ego, et je me disais que c'était de l'artisanat. Début 2025, j'ai enfin cessé de le payer, au moins pour un projet.
Mon portfolio a toujours été un projet dont je suis fier, mais ses fondations étaient devenues une capsule temporelle. Pendant des années, un petit backend PHP lisait les données depuis des fichiers INI ; plus tard, le frontend lisait simplement du JSON brut directement sur le disque. La présentation était soignée et le flux de travail était pénible. Chaque coquille, chaque mise à jour de projet impliquait d'ouvrir un éditeur, de modifier un fichier, de pousser un commit. Je me souviens d'avoir voulu corriger une seule phrase depuis mon téléphone, loin de mon bureau, et de m'être rendu compte que je ne pouvais pas le faire sans un déploiement complet. C'est à ce moment-là que l'habitude a cessé de ressembler à de l'artisanat pour ressembler à une cage que je m'étais construite moi-même.
Je ne voulais pas construire à la main une interface d'administration à partir de rien — même moi, j'entendais l'ego là-dedans — alors je suis allé voir ce qui existait déjà. La recherche m'a ramené au CMS headless : le frontend entièrement séparé du dépôt de contenu, les données servies n'importe où via une API. J'avais déjà travaillé avec cette forme à l'échelle d'une entreprise, mais je n'avais pas suivi à quel point les outils indépendants avaient progressé.
Les géants du SaaS — Contentful et ses voisins — sont réellement capables, et ils facturent aussi à l'enregistrement, avec des plafonds d'API qui se lisent comme un compte à rebours pour tout ce qui grandit. Je ne voulais pas d'une facture d'abonnement qui me pénalise d'utiliser mon propre site. Je voulais posséder le code et la base de données, purement et simplement.
Je n'ai donc regardé que ce que je pouvais héberger moi-même, et j'ai passé en revue ce que les gens utilisent vraiment :
Strapi se situait dans l'espace entre une application finie et un framework. L'interface est assez bonne pour que je fasse une modification depuis mon téléphone, et elle ne ferme jamais la porte au code : elle tourne sur Node, donc un hook de cycle de vie ou un contrôleur sur mesure sont là quand un CMS standard me laisserait coincé. Elle traitait six langues comme des objets de première classe plutôt que comme une réflexion après coup, me laissait façonner les schémas sans les écrire à la main, et transformait un article en quelque chose de modulaire : des blocs que je pouvais empiler plutôt qu'un seul pavé de balisage.
Quand j'ai lancé ce blog quelques mois plus tard, je n'ai pas recommencé. J'ai étendu les modèles que j'avais déjà et j'ai pointé un second frontend vers eux. Le lecteur de fichiers statiques était devenu un moteur au service de deux projets.
Rien de tout cela n'était une histoire de conversion. Je recours encore à une construction from-scratch plus souvent que je ne le devrais, et je pense toujours que cet instinct vaut la peine d'être gardé. Mais il a sa place sur les projets où me tromper ne coûte qu'à moi — pas sur la seule pièce d'infrastructure qui a besoin d'être ennuyeuse et fiable. Choisir l'outil ici était le choix le plus difficile, et pour une fois je l'ai fait.
Les fondations sont posées ; maintenant, il faut construire.