Payload CMS et Next.js : un socle pour livrer un site vitrine en quelques jours

Pourquoi partir d’un socle ?

Repartir de zéro pour chaque client a un coût caché. Les mêmes briques sont redéveloppées, avec à chaque fois de petites différences, et une correction apportée à un site ne profite jamais aux autres. Un socle inverse la logique : les briques communes sont écrites, testées et documentées une fois, et chaque nouveau site commence là où le précédent s’est arrêté.

Le temps d’un projet se concentre alors sur ce qui le distingue, c’est-à-dire l’identité visuelle, le contenu et les quelques fonctionnalités propres au client. C’est ce qui a permis de monter Atelier 33, un site complet avec page d’accueil, transformations avant / après, blog, prise de rendez-vous et carte de la zone d’intervention, en quelques jours.

Pourquoi Payload CMS ?

Payload est un CMS headless open source, écrit en TypeScript, dont la configuration se fait dans le code. Les collections, les champs, les blocs et les droits d’accès sont des fichiers du dépôt : ils sont versionnés, typés et relus en code review comme le reste de l’application, et les types générés garantissent que le front-end lit exactement ce que le CMS stocke.

Depuis sa version 3, Payload s’installe dans l’application Next.js elle-même. L’interface d’administration et l’API vivent dans le même projet que le site public, qui lit ses données par la Local API, sans aller-retour HTTP. Il n’y a donc qu’une application à développer, à tester et à déployer.

Payload est enfin auto-hébergé, ce qui évite un abonnement par client et laisse les données sur un serveur que le client maîtrise. Ses plugins officiels couvrent une bonne partie des besoins d’un site vitrine (SEO, formulaires, redirections, recherche, aperçu en direct). Un CMS en SaaS comme Prismic reste un bon choix quand l’équipe ne veut pas gérer d’infrastructure ; ici, la maîtrise des coûts et du schéma l’emportait.

Un dépôt par client plutôt qu’une plateforme multi-tenant

Une seule application hébergeant tous les clients aurait demandé une isolation des données par tenant, des droits d’accès par tenant et une administration partagée. C’est une vraie surface de complexité et de sécurité, sans bénéfice pour des sites vitrines indépendants les uns des autres. Le socle est donc un template repo : chaque client reçoit son propre dépôt, créé à partir du socle, et son propre déploiement.

Le déploiement repose sur Docker, sur un VPS : une image construite par la CI, PostgreSQL, et Caddy en reverse proxy pour le certificat TLS. Le coût est fixe et prévisible, là où le plan gratuit de Vercel interdit l’usage commercial que représente un site client. Les sauvegardes sont prévues dès le départ, et une restauration de test fait partie de la procédure de mise en ligne.

Un page builder de 22 blocs

Le client compose ses pages lui-même, depuis une administration pensée pour des non-techniciens, en empilant des blocs : hero, texte et image, galerie, carrousel, vidéo, chiffres clés, témoignages, tarifs, FAQ, équipe, frise, onglets, carte, formulaire, prise de rendez-vous, newsletter, appel à l’action, entre autres.

Chaque bloc associe un schéma, défini côté Payload, à un seul composant de rendu côté Next.js. Quand un client exprime un besoin que les blocs existants ne couvrent pas, la réponse prend la forme d’un nouveau bloc ajouté au socle, dont profitent tous les sites suivants. Le coût d’un projet baisse ainsi à mesure que le socle s’enrichit.

Ce que chaque site contient déjà

• un blog avec catégories filtrables et article mis en avant ;
• une prise de rendez-vous synchronisée avec Google Agenda ;
• des formulaires gérés depuis l’administration, et des redirections pour les anciennes URL ;
• des rôles admin et éditeur, pour séparer la configuration du site de la saisie du contenu ;
• un bandeau de consentement aux cookies et une purge automatique des données personnelles conforme au RGPD ;
• un SEO configurable page par page, avec un aperçu en direct avant publication ;
• les pages légales, créées avec un squelette et un avertissement explicite, pour qu’aucun texte juridique générique ne soit publié par erreur.

Comment garder une structure stable d’un site à l’autre ?

Un socle n’a de valeur que si chaque site en hérite sans mauvaise surprise. Le code est donc développé en TDD sur trois niveaux : des tests unitaires avec Vitest, pour la logique pure comme pour les composants avec React Testing Library, des tests d’intégration sur une vraie base PostgreSQL, et des parcours Playwright qui vérifient les écrans clés, avec un audit d’accessibilité automatique par axe.

La CI enchaîne à chaque pull request l’audit des dépendances, le typage, le lint, les tests et le build, puis les tests de bout en bout sur le build de production. Le projet est par ailleurs développé avec Claude Code dans un cadre versionné dans le dépôt, avec des règles, des agents spécialisés et une démarche spec, plan puis tests, décrit dans le guide Claude Code au quotidien.

Créer un nouveau site client

1. créer le dépôt du client à partir du socle ;
2. adapter l’identité visuelle (couleurs, typographie) et les variables d’environnement ;
3. composer les pages dans l’administration, à partir des blocs existants ;
4. développer, si besoin, les blocs propres au client, qui pourront rejoindre le socle ;
5. mettre en ligne en suivant la procédure documentée, de la préparation du VPS à la restauration de test.

Plus le dépôt d’un client reste proche du socle, plus il est simple d’y reporter une amélioration ultérieure. Une section se rend donc activable ou désactivable, sans variante de code propre à un client.

Quelles sont les limites ?

• Un socle impose ses choix : un site très atypique, dont la structure sort du cadre des blocs, gagne peu à en partir.
• L’auto-hébergement demande un suivi régulier, entre mises à jour du serveur, des dépendances et de Payload, et surveillance des sauvegardes.
• Le socle n’est pas encore en production chez un client : Atelier 33 sert de banc d’essai, et les premiers retours d’éditeurs restent à venir.