J’ai enfin lancé Lubinik.dev.

Cette phrase paraît beaucoup plus nette que l’histoire réelle derrière le projet.

Lubinik n’a pas commencé comme un framework bien poli, avec un nom, une roadmap et un site public déjà imaginé à la fin du parcours. Il a commencé plus discrètement, avec des projets WordPress qui demandaient sans cesse les mêmes fondations, la même structure, les mêmes outils d’administration et la même séparation entre ce qui appartient à un seul site et ce qui devrait être réutilisable.

À un moment, ce que je construisais pour mes projets clients est devenu un système à part entière. Lubinik.dev est l’endroit où je peux enfin documenter ce système correctement.

Et comme tout framework a apparemment besoin d’un petit mythe privé derrière son nom : Lubinik vient de ma recherche d’un nom unique, mélangé aux noms de mes deux chiens, Blu et Niki. Le résultat sonnait assez étrange pour appartenir au projet, alors il est resté.

Pas vraiment un lancement produit

Je ne vois pas Lubinik comme un produit que j’essaie de vendre.

C’est plus personnel que ça. C’est mon framework WordPress, ma mémoire de travail, et l’architecture que j’utilise pour arrêter de reconstruire les mêmes fondations à la main à chaque nouveau projet.

Le site public n’est pas là pour faire croire que le framework est apparu parfaitement formé. Il est construit comme un journal, parce que c’est la forme la plus honnête du projet. Lubinik a grandi à travers de vrais sites, des refactorisations, des premières versions un peu brouillonnes, des répétitions agaçantes et des petites décisions qui ne sont devenues évidentes qu’après que la mauvaise version m’a appris quelque chose.

Le lancement de Lubinik.dev est donc moins un “voici une chose terminée” qu’un “voici l’histoire de la manière dont cette chose est devenue assez utile pour mériter sa propre maison”.

Ce qu’est Lubinik

Lubinik est un framework WordPress sur mesure composé de plusieurs couches, chacune avec un rôle précis.

• Le thème parent gère la mécanique commune du site : structure des mises en page, menus, headers, footers, sections réutilisables, templates et outils côté thème.
• Le plugin core fournit la couche backend commune aux addons : systèmes d’administration, enregistrement des shortcodes, chargement des templates, composants réutilisables, assets, galeries, calendriers, filtres, onglets et shortcodes utilitaires.
• Les addons portent la logique métier de types de sites spécifiques, comme les sites BnB, les refuges animaliers, les comics, les CV, les portfolios freelance et les contenus showcase.
• Les thèmes enfants gardent l’identité visuelle, les templates propres au projet, les design packs et la configuration spécifique du site.
• Les plugins de support gèrent la traduction, le SEO, les données structurées, les sorties API, les mises à jour et les systèmes qui doivent se connecter proprement sans devenir obligatoires dans chaque projet.
• Le scaffolder transforme les structures répétées d’addons et de thèmes enfants en configuration, pour qu’un nouveau projet ne dépende pas d’un copier-coller fragile.

Le but n’est pas de tout rendre abstrait. Le but est de mettre les bonnes choses au bon endroit.

Pourquoi il avait besoin de son propre site

Pendant longtemps, Lubinik a surtout existé dans des dépôts, des installations WordPress locales, des notes privées et les sites construits avec lui.

Cela suffisait tant que le système restait petit. Mais une fois que le framework a commencé à inclure un thème parent, un plugin core, plusieurs addons, des thèmes enfants, des plugins de support, un updater privé, des outils de synchronisation locale et un scaffolder, il est devenu plus difficile d’expliquer le projet de l’extérieur.

Le site donne au framework une forme lisible. Il peut présenter les composants, documenter les case studies et rassembler les articles chronologiques du blog pour que l’évolution du système ne disparaisse pas simplement dans l’historique des commits.

C’est important, parce que Lubinik n’est pas seulement du code. C’est aussi une trace de décisions.

Le journal compte

Le blog de Lubinik.dev est volontairement écrit comme un journal.

Il commence avec la première frustration : essayer de faire la paix avec WordPress, créer un thème BnB, et comprendre que certaines parties du travail étaient reconstruites trop souvent. Ensuite, il suit le projet à travers les premiers refactors, la séparation entre thème et plugin, l’addon BnB, l’addon refuge, les templates dynamiques, les thèmes enfants, les design packs, les plugins de support, le développement assisté par IA, le scaffolder, les mises à jour privées et le moment où le système est devenu assez maintenable pour être utilisé sur de vrais sites.

Je voulais que cette histoire reste visible, parce que c’est la manière la plus honnête d’expliquer le framework. Lubinik n’est pas né de la théorie. Il est né en construisant des choses réelles et en écoutant quand les mêmes problèmes revenaient sous des formes différentes.

Un framework n’est pas seulement un ensemble de fichiers réutilisables. C’est aussi la mémoire de ce qui est devenu assez pénible pour mériter un meilleur système.

Construit avec le système qu’il documente

Il y a une petite satisfaction dans le fait que Lubinik.dev soit lui aussi un site Lubinik.

Le site n’est pas seulement une brochure à propos du framework. Il utilise sa propre logique : un thème enfant pour la couche visuelle, du contenu showcase pour présenter les composants et les outils, des articles de blog pour documenter le journal, et la même discipline architecturale que Lubinik est censé apporter aux autres projets.

Cela fait du site une forme de preuve. Pas une preuve parfaite, parce qu’un framework personnel n’est jamais vraiment terminé, mais une preuve vivante. Si le système est censé m’aider à construire et maintenir des sites WordPress personnalisés, alors son propre site doit pouvoir tenir sur cette même fondation.

Ce que le lancement change

Lancer Lubinik.dev ne signifie pas que le framework est complet.

Cela signifie que le projet est maintenant assez visible pour être documenté publiquement. Cela signifie que l’architecture a un endroit où être expliquée. Cela signifie que les futurs changements peuvent rejoindre une chronologie au lieu de disparaître dans des notes privées. Cela veut aussi dire que je peux montrer le système derrière mon travail client sans transformer chaque explication en petite histoire orale de mes décisions WordPress.

Et, honnêtement, cela donne aussi un peu plus de responsabilité au projet. Quand quelque chose a une maison publique, il devient plus difficile de le traiter comme un tas de dossiers que je suis la seule à comprendre à moitié.

Pour la suite

La prochaine étape de Lubinik ne consiste pas à le rendre plus grand juste pour le rendre plus grand.

Il s’agit de rendre les éléments existants plus calmes, plus clairs et plus faciles à réutiliser : meilleur scaffolding, génération plus propre des thèmes enfants, mises à jour plus fiables, surfaces API plus solides, meilleur support SEO et données structurées, et addons pratiques qui continuent à naître de vrais projets plutôt que de listes de fonctionnalités abstraites.

Lubinik.dev donne un endroit à ce travail.

Pas comme une annonce finale, mais comme le journal continu d’un framework qui a commencé par accident et qui est lentement devenu l’une des choses les plus utiles que j’aie construites.