- Primo v3.2 représente un site à la fois sous forme de fichiers locaux et de lignes dans une base de données côté serveur, afin que des agents puissent modifier le code tandis que des éditeurs non techniques modifient le même site depuis le navigateur
- Les développeurs gèrent les pages, contenus, paramètres et routes avec des composants Svelte et des fichiers YAML, puis les synchronisent avec la base de données relationnelle du serveur via
primo push
- L’éditeur dans le navigateur permet l’édition de texte directement sur la page rendue, le glisser-déposer de blocs, ainsi que des types de pages et champs personnalisés, ce qui réduit la dépendance aux interfaces CMS centrées sur les formulaires
- La cible principale est constituée des développeurs, freelances et agences qui doivent livrer des sites sur mesure à des éditeurs non techniques, avec 12 starters et plus de 40 blocs fournis
- Le contenu est stocké dans SQLite via PocketBase, le code reste dans le dépôt de l’utilisateur, et la licence MIT ainsi que l’export statique avec
primo pull permettent de réduire la dépendance au service
Un modèle de CMS qui combine fichiers et base de données
- Primo v3.2 est un CMS open source en développement depuis 2019, qui représente l’intégralité d’un site simultanément comme des fichiers et des lignes de base de données
- Les fichiers locaux sont modifiés directement par les agents, tandis que la base de données serveur sert de support à l’édition visuelle par des humains dans le navigateur
- Le flux de base consiste à créer le site avec un agent, puis à transmettre les droits d’édition dans le navigateur au client ou à des proches
- Dans l’exemple,
claude crée un type de page de tarification, rédige pages/pricing.yaml et blocks/pricing-tiers/component.svelte, puis déploie 3 fichiers avec primo push
- Après le déploiement, l’utilisateur peut modifier directement dans le navigateur le texte des paliers tarifaires et les prix
La structure des fichiers locaux manipulée par les agents
primo pull récupère l’ensemble du site sous forme de fichiers ordinaires
- Cela inclut les composants, pages, contenus, paramètres et routes
- Les blocs sont des composants Svelte et le contenu ainsi que les paramètres sont en YAML
- Il est possible de scaffolder un nouveau site ou de récupérer un site existant
- Les agents CLI comme Claude Code, Cursor et Codex modifient l’ensemble du dépôt
- Le flux consiste à éditer toute la base de code comme on le ferait avec un codebase Next.js ou SvelteKit
- La commande d’exemple est
$ claude "redesign the pricing page"
primo push synchronise les fichiers modifiés avec la base de données relationnelle du serveur
- Le client peut éditer le même site dans le navigateur directement sur la page rendue
- Les champs déclarés par les blocs sont exposés comme champs modifiables
Un CMS qui s’édite directement sur la page rendue
- L’éditeur fonctionne sur la page rendue et n’impose pas, comme expérience d’édition principale, un onglet CMS séparé ou une vue en formulaire
- Tous les champs déclarés par les blocs sont affichés comme des surfaces cliquables avec des libellés
- Il utilise le même modèle que celui lu par le moteur de rendu, sans couche de transformation séparée
- L’édition on-page consiste à cliquer sur le texte de la page rendue pour le saisir immédiatement
- Des puces de champ indiquent l’élément en cours d’édition
- Les blocs en glisser-déposer permettent de réordonner, ajouter et supprimer des blocs dans l’arborescence de la page, avec écriture immédiate des changements dans la source
- Les types de pages personnalisés permettent de définir une structure une fois, puis d’autoriser le client à créer autant de pages que nécessaire sans casser ce modèle
- Les champs personnalisés prennent en charge le texte, le texte enrichi, les images, les liens, les nombres, les groupes et les répétiteurs
- L’interface d’édition est générée à partir du schéma
- La collaboration en temps réel permet à plusieurs personnes d’éditer la même page simultanément, avec indicateurs de présence en direct et édition sans conflit
- Une vue en formulaire structurée est utilisée pour les champs qui n’apparaissent pas sur la page, comme le SEO, les métadonnées, les répétiteurs ou les paramètres masqués
Des starters et blocs pour les créateurs de sites sur mesure
- Primo cible les développeurs, freelances et agences qui créent des sites sur mesure pour des éditeurs non techniques
- La marketplace propose des starters par type de client ainsi que des blocs de section courants
- Parmi les exemples figurent des starters pour restaurants, coachs, portfolios et services locaux
- L’offre comprend 12 starters et plus de 40 blocs
- Chaque starter est un site autonome complet
- Il inclut des composants Svelte et des champs typés
- Il est scaffoldé dans un dépôt
- Il n’y a ni verrouillage au framework ni runtime caché
- Les utilisateurs peuvent forker un starter, le modifier et le déployer, ou encore sélectionner leurs propres starters et blocs
Différences avec WordPress, les headless CMS et les site builders
- WordPress permet de livrer au client un site modifiable, mais est ici comparé comme une structure où contenu et thèmes PHP sont entremêlés
- Un headless CMS peut garder une structure de code propre, mais le schéma se trouve dans une interface d’administration séparée
- Les site builders proposent du glisser-déposer, mais le résultat est présenté comme dépendant de la plateforme
- Primo met en avant une différence centrale : une source unique est éditée conjointement par l’équipe et les agents
- Le code se trouve dans des fichiers Svelte et dans le dépôt de l’utilisateur
- L’édition côté client se fait sur la page rendue
- Le schéma est placé dans
fields.yaml à côté du .svelte
- Les agents peuvent éditer l’ensemble du site sous forme de fichiers
- L’hébergement et la licence sont présentés comme self-host et MIT
Propriété des données et état opérationnel
- Le contenu est stocké dans SQLite via PocketBase, et le code reste dans le dépôt de l’utilisateur
primo pull fournit à tout moment un export statique du code et du contenu- Primo est sous licence MIT et affirme que, même si le projet disparaît, le code en fonctionnement et les sites créés continueront de fonctionner
- Son état opérationnel est v3.2 après 7 ans, avec comme cas de sites en production des travaux clients d’agences, de petites boutiques e-commerce, des sites de documentation et ses propres pages marketing
- Les agents ne sont pas présentés comme un nouveau produit, mais comme un nouveau client du même modèle maintenu depuis 2019
Payload, TinaCMS, Sanity Studio et support de React
- Payload est présenté comme un headless CMS, avec un schéma dans l’interface d’administration et du contenu récupéré via API
- TinaCMS est comparé à une approche qui place un éditeur basé sur Git devant des fichiers Markdown
- Sanity Studio est une interface d’administration basée sur React au-dessus d’un content lake hébergé
- Primo fait lire à l’éditeur et au moteur de rendu les mêmes fichiers Svelte et les mêmes lignes de base de données, sans couche de transformation API entre les deux
- React n’est actuellement pas pris en charge dans les blocs Primo
- Primo a été conçu autour de l’approche en compilation de Svelte, et cette structure transforme les blocs en fichiers lisibles directement par l’éditeur et le moteur de rendu
- Le support de React à l’intérieur des blocs Primo ne figure pas sur la roadmap
- La roadmap inclut
primo integrate <framework>
- L’idée est d’abord de superposer Primo à une application SvelteKit existante
- Astro est ensuite mentionné, et Next.js reste un souhait
- Dans cette direction, les composants de production restent dans le framework concerné, tandis que Primo ne gère que le contenu et l’éditeur
Structure des blocs et authentification CLI
- Un bloc se compose de deux fichiers placés côte à côte
- Le composant gère le rendu
- Le schéma indique à l’éditeur quels champs existent
- L’exemple
blocks/hero/fields.yaml déclare les champs headline, subheadline et cta
headline et subheadline sont de type textcta est de type link
- L’authentification CLI lit la variable d’environnement
PRIMO_TOKEN
- Le token est généré site par site depuis l’interface d’administration
primo pull <host> clone le projetprimo push n’envoie que les fichiers modifiés
- L’authentification est la même que celle utilisée par les éditeurs, sans nécessité d’apprendre une API séparée
- Cela fonctionne sur toutes les instances Primo via HTTPS, y compris les instances self-hosted
Commande de démarrage
- Un nouvel espace de travail se crée avec la commande suivante
npx primo-cli init my-workspace
- Après création, les états
workspace ready et server.yaml written s’affichent
- Les mentions de licence et de tarification sont présentées comme MIT, open source et gratuit à vie
1 commentaires
Commentaires sur Hacker News
Les éditeurs CMS en glisser-déposer ont l’air impressionnants en démo, mais pour avoir exploité un éditeur similaire en interne, c’était un enfer de mises à jour sans fin
Les demandes du type « Est-ce qu’on peut aligner le texte à droite et le mettre en bleu ? » n’arrêtent jamais, et au final on ajoute toujours plus de propriétés à chaque bloc
Les vrais créateurs de contenu ont du mal à les utiliser efficacement, et le résultat est généralement peu satisfaisant
Avec davantage de formation, ça peut s’améliorer, mais le compromis entre liberté et respect de l’identité de marque reste entier
Dans notre cas, un CMS headless semble être une meilleure approche. Il fournit seulement le contenu, puis quelques experts l’implémentent en code en respectant le design, mais tout le monde n’a pas ce luxe, donc ce type de CMS a clairement sa place
Il y a quelques mois, en refondant le site e-commerce d’un client, nous avons créé avec Maglev des sections/blocs éditables, et l’expérience d’édition elle-même était bonne
Mais après le lancement, le client a embauché une responsable marketing avec des connaissances très basiques en HTML/CSS, et on a eu du mal à lui faire comprendre qu’au lieu d’écrire elle-même du HTML/CSS, il valait mieux laisser les développeurs créer les sections nécessaires
On pourrait adopter une approche à la Primo avec un éditeur pour développeurs, mais avec l’expérience je préfère éviter que les clients touchent directement au HTML/CSS de leur site
Je ne veux pas non plus d’une relation du type « si vous cassez quelque chose, vous payez »
Plus largement, n’importe quel CMS rencontre le même problème. J’ai aussi aidé une entreprise dont le site Webflow avait été cassé : cas classique où le designer avait créé le site, puis le marketing a voulu « améliorer » l’UI et tout a explosé
Le nombre de composants qu’on peut créer a forcément une limite
Dans l’idéal, il faudrait un CMS où le client peut modifier facilement le HTML sans code. Comme ça, ça se charge vite, le SEO est bon, et les développeurs n’ont pas à réinventer la roue
C’est pour ça que j’ai créé Versoly (https://versoly.com/). Pourquoi faudrait-il contacter un développeur à chaque fois juste pour changer une couleur de fond ou ajouter une nouvelle section ?
Cela dit, quel que soit le CMS utilisé, on aura toujours le problème des éditeurs de contenu qui veulent aligner le texte à droite et le mettre en bleu, non ?
Il n’y a presque pas encore de documentation officielle, mais si ça vous intéresse, j’aimerais bien que vous regardiez la page d’accueil pour me dire si ça vaut la peine d’essayer
Je serais aussi ravi d’avoir des retours généraux ou des leçons tirées de votre propre expérience
https://brick-cms.com/
GitHub :
https://github.com/primocms/primo
Discussions précédentes :
https://news.ycombinator.com/item?id=23820201
https://news.ycombinator.com/item?id=25301040
Un Show HN avec du texte provenant de ce qui semble être un autre compte de l’auteur original :
https://news.ycombinator.com/item?id=36801101
SSG semble vouloir dire générateur de site statique (Static Site Generator), mais il faudrait peut-être faire un effort pour écrire de façon plus claire pour les lecteurs, dès qu’on sort un peu d’un domaine précis
Même en faisant du développement web, j’ai dû réfléchir un instant pour décoder cet acronyme
Cela dit, pour les utilisateurs qui ne le savent pas encore, l’écrire en toutes lettres peut être plus utile
J’aimerais bien avoir un outil de ce genre pour gérer du contenu dynamique continu, comme des billets de blog ou des critiques
Beaucoup de gens restent sur WordPress, mais la personnalisation et les thèmes y sont proches du cauchemar
À l’époque, c’était l’un des seuls moyens de créer facilement un blog
Le problème, c’est qu’au moment où on sort du cadre standard, il faut soudain une connaissance approfondie de la structure interne de WordPress
Il y a environ 3 ans, HN a mis le CMS open source Primo en une (https://news.ycombinator.com/item?id=23820201), et grâce à ça, j’ai quitté un poste confortable en télétravail en pleine pandémie pour m’y consacrer à temps plein
Depuis, j’ai épuisé toutes mes économies, perdu le domaine primo.af au profit des Taliban, et j’ai même convaincu ma femme de devenir développeuse/designeuse pour m’aider
Malgré tout, je suis fier de ce qui a été construit jusque-là, et en voyant que cela aide des gens à apprendre le développement web, à publier leur site personnel et à gérer des sites clients, je suis encore plus convaincu de la puissance et de la simplicité de cette approche
Primo 2, lancé aujourd’hui en bêta publique, propose l’édition de contenu directement sur la page, la construction de pages, etc.
J’ai commencé à créer Primo par lassitude face à la création de sites web et à la difficulté qu’ont les utilisateurs non techniques à les gérer
Sur des projets freelance, j’en avais assez des thèmes WordPress fragiles, de la navigation dans les tableaux de bord et des combinaisons de plugins, et comme développeur en agence, je trouvais les CMS monolithiques et les meta-frameworks/CMS headless excessifs pour des landing pages ou des sites vitrines
En tant que formateur au code, j’ai vu des étudiants être intimidés par les CLI, API, gestionnaires de paquets, bundlers, frameworks et meta-frameworks au point d’avoir peur d’utiliser le web
Il n’existait pas de voie simple et accessible pour créer, gérer, développer et héberger des sites courants comme des blogs, landing pages et sites vitrines
Primo est fondamentalement un CMS qui facilite la gestion du contenu, mais il regroupe aussi la construction de pages, l’édition de code, la génération de sites statiques, ainsi que le déploiement/l’hébergement sur GitHub dans une seule interface
Les blocs sont écrits en Svelte, c’est-à-dire en HTML/CSS/JS, donc ils sont responsives et leurs styles sont encapsulés
Comme il s’agit d’un site statique, on bénéficie aussi des avantages du serverless en matière de coût, sécurité, scalabilité et vitesse
Primo s’adresse moins aux personnes qui préfèrent des contrôles de design WYSIWYG à la SquareWixFlow qu’à celles qui veulent garder un contrôle total sur leur site via HTML/CSS/JavaScript tout en offrant à elles-mêmes et à leurs amis/clients/collaborateurs non techniques une expérience d’édition de contenu extrêmement simple
L’outil vise ceux qui se sentent à l’étroit dans les outils no-code et les plateformes propriétaires, mais veulent quelque chose de plus simple sans perdre la puissance du code
Plus largement, Primo est une tentative de laisser le web entre les mains des individus
En rendant la publication web plus accessible, j’espère renforcer la culture technique et donner aux gens les moyens d’une expression libre, afin qu’ils ne soient pas facilement poussés vers des boîtes noires et des jardins clos
En revanche, le système de gestion de contenu posait problème. Je m’attendais à pouvoir mettre des fichiers Markdown dans des dossiers pour générer des articles ou des billets de blog à partir de templates, comme avec un générateur de site statique classique
À une époque, j’avais forké le dépôt Primo pour implémenter une approche personnalisée convertissant les entrées de la base de données en structure fichiers/dossiers, mais l’opération inverse semblait délicate, donc j’ai choisi une autre voie et, inspiré par ce guide, j’ai créé mon propre générateur de site statique Markdown : https://joshcollinsworth.com/blog/build-static-sveltekit-mar...
Mon cas d’usage n’est peut-être pas la cible visée, mais ce serait un excellent produit si les projets étaient stockés dans une structure dynamique de fichiers/dossiers au lieu d’être écrits en base de données, et pouvaient être édités et versionnés comme un projet SvelteKit classique
Cela en ferait essentiellement un framework de génération de sites statiques basé sur Svelte avec une bibliothèque de composants et une UI dédiée
Le forum est aussi très bien, et plusieurs questions que je me posais avaient déjà une réponse
J’utilise WordPress depuis longtemps et je découvre récemment Svelte, et c’est vraiment très proche de ce que je cherchais
Un grand respect pour tout le travail investi pour en arriver là
Beau projet, mais c’est un peu décevant de devoir avoir un compte Supabase pour faire de l’« auto-hébergement »
On dirait que cela ne fonctionne qu’avec certains services d’hébergement capables de se connecter à Supabase, et qu’on est incité à récupérer le contenu des pages depuis GitHub
Du coup, cela ressemble moins à un CMS réellement auto-hébergeable qu’à un CMS fonctionnant avec certains fournisseurs de services spécifiques
L’objectif était de permettre aux gens de mettre leur propre serveur en ligne aussi facilement que possible, d’où la connexion à ces services
Cela dit, on est en train de séparer le backend pour permettre un véritable hébergement autonome
Le seul service externe vraiment nécessaire est GitHub, et d’autres fournisseurs comme GitLab pourront sans doute être ajoutés plus tard
Beau projet, mais honnêtement, j’ai l’impression qu’on en est arrivé à un point où moins de JavaScript, voire pas de JavaScript du tout, est préférable à la fois pour les développeurs et les utilisateurs
Je suis en train de migrer mon ancien blog vers un nouveau blog généré avec Zola (https://www.getzola.org), et je refais aussi mon site portfolio initialement reconstruit avec React/Gatsby en Zola tant l’écart de performance est énorme
Il m’arrive aussi de naviguer sur le web avec JavaScript désactivé, et si dans cet état un site ne fonctionne pas du tout, ou ne se charge même pas, c’est un gros défaut
Mon ancien site utilisait jQuery, ce qui m’agaçait déjà un peu, et essayer des choses comme React a été un cauchemar
En interne, il utilise le compilateur Svelte
Il est presque difficile de croire que cela fait déjà plus de dix ans que j’ai créé un générateur de sites appelé Stiqr en 2010
Le site n’est plus en ligne, mais on peut en voir des traces dans une vidéo YouTube
https://www.youtube.com/watch?v=B-ff53t8TuU&t=224s
À l’époque, en 2010, avec l’essor du design responsive, j’ai abandonné le projet, mais je continue de penser que la manière de créer des sites web dans un futur proche ira dans cette direction
La combinaison du glisser-déposer / des blocs et de Svelte est vraiment chouette, mais pour moi cela ressemble à un outil placé du mauvais côté du spectre
C’est un constructeur de sites web visuel qui permet de personnaliser des blocs avec un éditeur en ligne
Ce que je veux, c’est une interface en ligne permettant à un client d’ajouter ou de modifier du texte, ou d’effectuer de petits ajustements, sur un site Svelte que j’ai créé hors ligne avec mes propres outils
Ce serait bien si l’on pouvait créer un site selon un certain standard d’interface que Primo pourrait lire, et que le client pourrait ensuite modifier via une interface visuelle
Les grosses modifications reviendraient ensuite vers moi, et je pourrais conserver la rapidité et la liberté de mon workflow hors ligne
On pourrait dire qu’il me faut un CMS headless, mais tous ceux que j’ai essayés étaient excessivement complexes et ne m’ont apporté que de gros maux de tête en configuration et en maintenance
À moins de créer des champs spécifiques, il ne peut pas modifier les aspects visuels, par exemple rendre une image ronde ou carrée
Si le problème est de ne pas pouvoir utiliser un IDE local, il est actuellement possible de bundler des composants Svelte en JavaScript vanilla, de les importer dans des blocs Primo et de leur passer des données via des champs
Cela dit, tant que ce n’est pas stabilisé, il vaudrait mieux attendre quelques semaines avant de l’utiliser en production
La méthode que tu décris correspond en fait pratiquement à ma façon de travailler sur des projets clients. J’écris tout le code, je réutilise généralement des blocs d’autres projets, puis je livre au client un site qu’il peut éditer dès le premier jour avec un minimum de formation
Je me demande si, par « personnalisation des blocs », tu veux dire que cela n’inclut pas les modifications de texte, ou bien que les actions possibles ne sont pas suffisamment limitées pour être confiées à un client
On peut insérer, dans le markup d’une page classique, des sections gérées en glisser-déposer, et cela semble prendre en charge la plupart des frameworks, y compris Svelte
La configuration peut se faire en FTP