Strapi, Directus, Payload : choisir un headless CMS et le déployer sur Hetzner en 2026

Choisir un headless CMS en 2026 ne se résume plus à comparer des grilles de fonctionnalités. Trois projets se partagent l’essentiel des nouveaux déploiements : Strapi 5, Directus 11 et Payload 3. Tous trois sont open source, fournissent une API REST et GraphQL prête à l’emploi, et tournent confortablement sur un VPS à moins de 20 € par mois. Mais leurs philosophies divergent fortement : Strapi accompagne le développeur avec un panneau d’administration mature, Directus expose n’importe quelle base PostgreSQL existante en quelques minutes, et Payload s’invite directement dans une application Next.js comme une extension naturelle du framework.

Cet article compare ces trois projets sur des critères concrets : rapidité de mise en route, qualité du panneau d’édition, performances en production, écosystème de plugins, intégration avec Next.js et Astro, coûts d’hébergement, modèle de licence, et chemin de migration depuis WordPress. L’objectif n’est pas de désigner un vainqueur universel, mais de fournir une grille de décision permettant de choisir le bon outil pour un projet donné, puis de le déployer sur Hetzner Cloud sans surprise. Trois tutoriels associés couvrent la mise en pratique étape par étape : installation de Payload, déploiement de Strapi sur Hetzner, et migration d’un blog WordPress vers Strapi.

Pourquoi un headless CMS plutôt que WordPress en 2026 ?

WordPress reste, et restera longtemps, le moteur le plus déployé du web. Sa courbe d’apprentissage minimale, son écosystème de thèmes et de plugins, et la profusion d’hébergeurs qui le proposent en un clic en font un choix par défaut parfaitement défendable pour un site éditorial classique ou une vitrine de PME. Le débat n’est donc pas de remplacer WordPress partout, mais d’identifier les cas où une architecture découplée — un back-office côté serveur, un front-end indépendant côté navigateur ou côté builder statique — apporte un gain réel.

Trois situations rendent un headless CMS pertinent. La première est le besoin de servir plusieurs canaux à partir d’un même stock de contenu : un site web, une application mobile, un afficheur dynamique en boutique, un assistant vocal. Une API JSON consommable depuis n’importe quel client devient alors la colonne vertébrale, là où WordPress impose une couche thème PHP centrale. La deuxième est la recherche de performance : un site statique généré depuis Next.js ou Astro, alimenté par un CMS découplé, encaisse des pics de trafic sans broncher et obtient des scores Lighthouse difficilement atteignables avec WordPress sans empilement de plugins de cache. La troisième est le besoin de modèles de données complexes — relations, versions, multilingue natif, permissions par rôle — où l’écosystème ACF de WordPress montre rapidement ses limites.

À l’inverse, un headless CMS coûte plus cher en compétences. Il faut un développeur capable de gérer un build front-end, de configurer un VPS, de maintenir une base PostgreSQL, et d’assurer les sauvegardes. Pour un blog tenu par un rédacteur seul qui n’envisage pas plus de cinq pages par mois, l’investissement n’est pas rentable. La règle empirique tient en une phrase : si l’équipe technique compte au moins une personne et que le contenu doit alimenter autre chose qu’un thème WordPress, l’arbitrage penche vers le headless.

Les trois candidats en bref

Les trois projets retenus dominent le marché open source francophone et anglophone. Aucun des trois ne nécessite de licence payante pour un usage standard, chacun offre une API REST et GraphQL, chacun expose un panneau d’administration web, et chacun se laisse déployer sur un VPS modeste. Leurs différences tiennent à leur stack technique et à leur public cible.

Strapi 5 est écrit en Node.js et tourne sur n’importe quelle base SQL — PostgreSQL en production, SQLite pour le développement local. Il s’installe avec une seule commande : npx create-strapi@latest. Sa version 5, sortie en 2024 puis stabilisée tout au long de 2025 et 2026, a réécrit le panneau d’administration en React 18 et adopté le Document Service API qui simplifie la gestion des versions et du multilingue. Au moment d’écrire ces lignes, la branche stable est en 5.39.x.

Directus 11 retourne le problème : au lieu de générer ses propres tables, il se branche sur une base de données SQL existante et expose chaque table comme une collection éditable. Cette approche en fait un choix idéal pour donner une interface admin à une base PostgreSQL déjà peuplée, ou pour intégrer un CMS dans une stack métier où la base est la source de vérité. Sa version 11.17.2 publiée en avril 2026 ajoute un système de versions avec brouillon global et une assistance d’IA capable de traiter images et PDF. Attention au point de licence : Directus est passé sous BSL 1.1 — gratuit pour les organisations dont le chiffre d’affaires reste sous 5 millions de dollars, commercial au-dessus.

Payload 3 est l’outsider qui monte. Sa version 3.x s’installe directement dans une application Next.js existante, sous le dossier /app, ce qui supprime la frontière classique entre back-office et front-end. La base supportée peut être MongoDB, PostgreSQL ou SQLite, via l’ORM Drizzle. Les développeurs Next.js trouvent Payload immédiatement familier puisqu’il partage la même topologie de fichiers, le même runtime et la même approche TypeScript-first. Sa version 3.84+ tourne sur Next.js 15, et sur Next.js 16.2.2 ou supérieur depuis Payload 3.73. Licence MIT, sans seuil de chiffre d’affaires.

Strapi 5 — forces, limites, à qui s’adresse-t-il ?

Strapi se distingue par la maturité de son panneau d’administration. Le Content-Type Builder permet de définir des schémas — articles, auteurs, catégories, médias, relations un-à-plusieurs ou plusieurs-à-plusieurs — sans écrire une ligne de SQL ni de migration. À chaque modification du modèle, Strapi régénère les routes REST et le schéma GraphQL, applique la migration sur la base, et met à jour les types TypeScript exposés au front-end. Pour une équipe qui démarre un projet content-heavy avec un calendrier serré, ce gain de temps est tangible : une preuve de concept fonctionnelle prend une demi-journée plutôt qu’une semaine.

L’écosystème de plugins est le deuxième atout. Strapi Marketplace propose des extensions officielles pour Algolia, Cloudinary, Stripe, Meilisearch, plus une communauté active qui maintient des connecteurs vers Sendgrid, Mailjet, ou des fournisseurs de stockage S3-compatibles. Le système d’internationalisation natif gère une dizaine de locales sans bibliothèque tierce, avec un mode brouillon par locale qui simplifie le travail des traducteurs. Les rôles et permissions disposent d’un panneau granulaire : on peut autoriser un rédacteur à créer un brouillon mais lui interdire de publier, et confier la publication à un éditeur en chef.

Les limites tiennent à la nature monolithique du serveur Node.js. Strapi consomme entre 350 et 700 Mo de RAM au repos sur un projet typique, davantage en charge. Sur un VPS à 4 Go (Hetzner CX22 ou équivalent), il cohabite mal avec une base PostgreSQL et un proxy Nginx : l’OOM killer finit par sacrifier l’un des trois. Le seuil confortable se situe autour de 8 Go de mémoire, soit le CCX13. La seconde limite concerne la migration de données complexe : importer un blog WordPress de 5 000 articles nécessite d’écrire un script qui parcourt l’API REST WordPress, transforme les blocs Gutenberg en blocs Strapi, et envoie via l’API Document Service. Le tutoriel associé « migration WordPress vers Strapi » couvre l’ensemble.

Public cible idéal : équipes qui veulent un CMS clé en main, un panneau d’admin agréable pour des rédacteurs non-techniques, un écosystème mature, et qui acceptent de provisionner un VPS de 8 Go ou plus. Stack frontend recommandée : Next.js, Nuxt ou Astro.

Directus 11 — quand la base SQL est déjà là

Directus inverse le rapport entre CMS et base de données. Au lieu d’imposer son propre schéma, il introspecte une base SQL fournie par l’utilisateur et expose chaque table comme une collection. Si vous avez déjà une base PostgreSQL avec des tables products, orders, customers, Directus se branche dessus en quelques minutes et fournit un panneau d’administration ainsi qu’une API REST, GraphQL et un SDK JavaScript pour ces tables. Aucune migration n’est nécessaire, aucun mapping ORM à écrire. Ce positionnement le rend incontournable pour les équipes qui doivent ajouter une couche d’édition sur un système existant : ERP léger, base de produits e-commerce, catalogue documentaire interne.

Le panneau d’édition de Directus est moins polished que celui de Strapi sur les cas content-heavy classiques (un article de blog avec des blocs riches), mais il rattrape largement sur les cas data-heavy : filtres avancés, tri multi-colonnes, vues personnalisables (kanban, calendrier, carte géographique pour les données spatiales), exports CSV et Excel natifs. Le système de Flows permet d’automatiser des workflows sans code : dès qu’un article passe en publié, déclencher une notification Slack, mettre à jour Algolia, envoyer un mail. Pour un usage de back-office métier où la donnée prime sur la mise en page, Directus est souvent un meilleur choix que Strapi.

Le point d’attention principal en 2026 reste la licence. Directus est passé en BSL 1.1 (Business Source License) en avril 2023 avec la version 10.0.0. Le code source reste public, on peut le forker, le modifier, le déployer en production. Mais une organisation dont les revenus annuels dépassent 5 millions de dollars doit prendre une licence commerciale auprès de Monospace, l’éditeur de Directus. Pour la quasi-totalité des PME africaines, cette clause n’a aucun impact pratique. Pour une grande administration ou un groupe industriel, le sujet se traite avec le service juridique avant d’engager le projet.

Sur le plan technique, Directus consomme moins de RAM que Strapi — environ 250 à 400 Mo au repos — et tourne confortablement sur un Hetzner CX22 à 4 Go. La base supportée nativement est PostgreSQL (recommandée), MySQL/MariaDB, SQLite et SQL Server. La version 11.17.2 d’avril 2026 améliore le système de versions avec un brouillon global automatique, et intègre un assistant IA capable de traiter images et PDF via OpenAI, Anthropic ou Google Gemini. Public cible idéal : équipes data, projets internes avec base SQL existante, applications métier où Directus joue le rôle d’admin panel par-dessus un schéma maîtrisé.

Payload 3 — le CMS qui s’installe dans Next.js

Payload prend une troisième voie. Au lieu d’être un service séparé qui expose une API que le front-end consomme, Payload 3 s’installe à l’intérieur d’une application Next.js existante. Le panneau d’administration vit sous une route /admin, les API REST et GraphQL vivent sous /api, et le rendu public reste sous les routes Next.js classiques. Le tout partage le même processus, le même runtime, la même configuration TypeScript. Pour une équipe qui maîtrise déjà Next.js, l’apprentissage de Payload se réduit à comprendre la structure des collections — qui ressemble fortement à du Mongoose ou du Drizzle.

Cette intégration native produit deux bénéfices opérationnels. Le premier est l’absence d’aller-retour réseau entre back et front lorsqu’on génère des pages statiques : Next.js peut interroger Payload via l’API local au moment du build, sans même passer par HTTP. Cela divise les temps de build par deux ou trois sur de gros sites. Le second est la simplicité du déploiement : une seule application à conteneuriser, une seule pipeline CI/CD, un seul domaine. Sur un VPS Hetzner CCX13, on déploie Payload + Next.js + PostgreSQL avec un fichier docker-compose.yml qui tient sur trente lignes.

Les contreparties sont à peser. Payload est plus jeune que Strapi et Directus — la version 3 stable date de fin 2024 — donc l’écosystème de plugins reste plus mince. La documentation, en pleine expansion, ne couvre pas encore tous les cas d’usage avancés en français. Le couplage à Next.js est une force pour les équipes Next.js, mais une contrainte pour celles qui voudraient consommer Payload depuis Nuxt, SvelteKit ou Remix : c’est techniquement possible (l’API REST/GraphQL reste exposée) mais on perd le bénéfice principal de l’architecture intégrée. Les bases de données supportées sont MongoDB, PostgreSQL et SQLite, via les adaptateurs @payloadcms/db-mongodb, @payloadcms/db-postgres et @payloadcms/db-sqlite.

Public cible idéal : équipes Next.js qui veulent un back-office riche sans se taper l’architecture client/serveur séparée, projets nouveaux où la décision technique ne traîne pas un héritage, développeurs qui aiment écrire leur configuration en TypeScript pur plutôt que de cliquer dans un panneau.

Comparatif détaillé

Critère	Strapi 5	Directus 11	Payload 3
Stack technique	Node.js, Koa	Node.js, Express	Node.js, Next.js
Bases de données	PostgreSQL, MySQL, SQLite	PostgreSQL, MySQL, SQLite, SQL Server	MongoDB, PostgreSQL, SQLite
API exposées	REST + GraphQL + Document Service	REST + GraphQL + SDK	REST + GraphQL + Local API
RAM minimale	~700 Mo	~400 Mo	~500 Mo
VPS recommandé	CCX13 (8 Go)	CX22 (4 Go)	CCX13 (8 Go)
Licence	MIT (Community)	BSL 1.1 — gratuit < 5 M$ CA	MIT
Marketplace	Mature	Modeste	Émergente
Multilingue natif	Oui (10+ locales)	Oui (illimité)	Oui (illimité)
Cas d’usage idéal	Site éditorial, multi-canal	Admin sur base SQL existante	App Next.js full-stack

Stacks frontend recommandées

Le choix du frontend conditionne autant l’expérience finale que le choix du CMS. Quatre frameworks dominent les déploiements headless en 2026, chacun avec ses affinités.

Next.js 15 reste le choix le plus polyvalent. Il s’intègre sans friction avec Strapi via le SDK officiel, avec Directus via le SDK @directus/sdk et avec Payload nativement puisque Payload vit dans Next.js. Les fonctionnalités d’Incremental Static Regeneration (ISR) et de revalidation à la demande permettent de servir un site quasi-statique tout en autorisant des mises à jour de contenu sans rebuild complet. Le mode App Router avec Server Components réduit le bundle JavaScript envoyé au client, ce qui compte sur des connexions 3G ou 4G dégradées.

Astro 5 est l’option idéale pour les sites éditoriaux où chaque kilooctet économisé compte. Son principe — zéro JavaScript par défaut, hydratation sélective des îlots interactifs — produit des pages dont le poids tient sous 50 Ko. Astro consomme parfaitement les API REST de Strapi et Directus en mode Static Site Generation. Le combo « Directus + Astro + Cloudflare Pages » est devenu un standard pour les blogs techniques exigeants.

Nuxt 3 joue le même rôle que Next.js dans l’écosystème Vue. Strapi et Directus disposent tous deux de modules Nuxt officiels qui simplifient la configuration. Pour Payload, l’intégration est moins naturelle puisqu’il faut consommer l’API REST plutôt que d’utiliser l’API locale réservée à Next.js. SvelteKit reste plus marginal mais connait une adoption croissante : il consomme parfaitement les API REST des trois CMS.

Déploiement sur Hetzner — les options qui marchent

Hetzner Cloud s’est imposé comme l’hébergeur de référence pour les projets headless en Europe et en Afrique francophone. Trois raisons à cela : des prix très inférieurs à AWS et DigitalOcean (à mémoire et CPU équivalents, le rapport est de 1 à 3 environ), un datacenter en Allemagne qui réduit la latence vers Dakar, Abidjan, Bamako à 80-120 ms, et un panneau de contrôle simple à comprendre.

Trois plans Hetzner Cloud couvrent l’essentiel des besoins en 2026. Le CX22 (2 vCPU x86 partagés, 4 Go RAM, 40 Go SSD) tourne autour de 4 € HT par mois. Il convient à Directus seul, ou à un projet Strapi minimaliste de moins de 1 000 contenus. Le CCX13 (2 vCPU AMD dédiés, 8 Go RAM, 80 Go NVMe) coûte autour de 17 € HT par mois post-hausse d’avril 2026. C’est le sweet spot pour Strapi en production, ou pour Payload + Next.js + PostgreSQL sur la même machine. Le CCX23 (4 vCPU AMD, 16 Go RAM, 160 Go) double les ressources autour de 24,49 € HT par mois et permet de séparer base et application sur des conteneurs distincts confortables. Vérifiez les tarifs en vigueur sur la page officielle Hetzner avant achat : les prix bougent.

Trois stratégies de déploiement coexistent. La plus simple consiste à installer Docker sur un VPS fraîchement provisionné, puis à lancer un docker compose up -d qui démarre le CMS, sa base, un Redis pour le cache et un Caddy ou Traefik comme reverse-proxy avec HTTPS automatique via Let’s Encrypt. Cette approche fonctionne pour les trois CMS, demande deux à trois heures de configuration la première fois, et reste reproductible via un dépôt Git versionné.

La deuxième stratégie passe par Coolify, un outil open source qui transforme un VPS en plate-forme PaaS personnelle. On installe Coolify en une commande sur un Hetzner CCX13, on connecte un dépôt GitHub, et chaque push sur la branche principale déclenche un build et un déploiement. Coolify gère TLS, journaux, sauvegardes de base et redémarrages automatiques. Le coût supplémentaire est nul puisque Coolify est gratuit, mais il consomme environ 1 Go de RAM, ce qui réduit le budget mémoire disponible pour le CMS.

La troisième stratégie cible Payload spécifiquement : déployer l’application Next.js + Payload sur Vercel pour la partie front-end, et héberger uniquement la base PostgreSQL chez Hetzner via une image Postgres Docker classique ou un service managé comme Neon. Cette architecture hybride profite du CDN de Vercel et de son edge runtime, tout en gardant le contrôle des données chez un hébergeur européen. Le tutoriel associé « déployer Strapi sur Hetzner » détaille pas à pas la première stratégie, qui reste la plus universelle.

Migrer depuis WordPress — réalités et chemins

Quitter WordPress pour un headless CMS est rarement un week-end de travail. Trois sujets méritent une attention particulière : la conversion des contenus, la préservation du SEO, et la gestion des médias.

La conversion des contenus dépend du format dans lequel vous écrivez actuellement. Si votre WordPress utilise majoritairement Gutenberg, chaque article est une suite de blocs sérialisés en HTML annoté. La cible — Strapi, Directus ou Payload — attend généralement un champ Markdown ou un éditeur riche basé sur ProseMirror ou Lexical. Le script de migration doit donc parser le HTML, identifier les blocs (paragraphes, titres, citations, images, tableaux), et les remapper vers les blocs équivalents du CMS de destination. Pour un blog standard de moins de 500 articles, comptez deux à quatre jours d’écriture et de débogage du script.

La préservation du SEO tient à trois éléments : conserver les URLs publiques (slugs), conserver les balises canonical, et conserver les redirections existantes. La meilleure pratique consiste à exporter les slugs WordPress, à les importer comme champ slug dans le CMS cible, et à mettre en place un fichier de redirections 301 dans Caddy ou Nginx pour les patterns d’URL qui changent (par exemple /category/X/ qui devient /blog/X). Sans cette précaution, le trafic organique chute de 30 à 60 % pendant les trois mois suivant la migration, le temps que Google recrawle.

La gestion des médias est souvent sous-estimée. Une médiathèque WordPress de cinq ans contient typiquement entre 1 000 et 5 000 images, dispersées dans /wp-content/uploads/AAAA/MM/. Les rapatrier dans le nouveau CMS implique de télécharger chaque fichier, de l’uploader dans le système de stockage cible (S3, MinIO, dossier local), et de mettre à jour toutes les références dans les contenus. Un script bien écrit fait ce travail en quelques heures, mais il faut prévoir un temps de relecture humain pour vérifier que les images critiques (page d’accueil, articles populaires) sont arrivées intactes. Le tutoriel « migrer un blog WordPress vers Strapi » fournit un script de référence que vous pouvez adapter.

Coûts mensuels comparés (ordre de grandeur 2026)

Au-delà du prix d’un VPS, le coût total d’un déploiement headless inclut le stockage des médias, la sauvegarde, la bande passante et le nom de domaine. Voici trois budgets de référence pour un site éditorial de taille moyenne (10 000 visites par mois, 500 articles, médiathèque de 30 Go).

Le budget plancher tient autour de 8 € par mois : un Hetzner CX22 à environ 4 € pour Directus + PostgreSQL + Caddy, un stockage objet Hetzner Object Storage à environ 1 € pour 100 Go, un nom de domaine .com à environ 1 €/mois amorti, et une sauvegarde Hetzner activée à 20 % du prix du VPS. C’est le minimum viable pour un projet personnel ou un blog associatif. Strapi tient à ce niveau de prix en théorie mais saturera dès qu’un éditeur charge plusieurs images simultanément.

Le budget équilibré s’installe autour de 25 € par mois : un Hetzner CCX13 à environ 17 € pour héberger CMS + base + reverse-proxy, un Object Storage à 1-2 €, des sauvegardes activées à environ 3 €, et un nom de domaine. C’est le budget recommandé pour un site professionnel sérieux. Strapi, Directus et Payload tournent tous trois confortablement sur ce gabarit.

Le budget production dépasse 50 € par mois quand on sépare base et application sur deux VPS, qu’on ajoute un Redis dédié pour le cache, qu’on prend un Object Storage avec géoréplication, et qu’on souscrit à un service de monitoring externe (UptimeRobot Pro, Better Uptime). Ce budget reste très inférieur à un équivalent AWS ou GCP, qui dépasserait facilement les 200 € pour la même configuration.

Pièges fréquents à éviter

Cinq erreurs reviennent dans les retours d’expérience des équipes qui ont déployé un de ces trois CMS en 2025-2026. Les connaître à l’avance évite des mois de friction.

Le premier piège est de sous-dimensionner le VPS. Un Strapi tournant sur 2 Go de RAM crashera sous le moindre import en lot ou batch d’images. La règle : prévoir 2 à 3 fois la consommation au repos pour absorber les pics. Pour Strapi, c’est minimum 8 Go en production. Pour Directus et Payload, 4 Go suffisent pour démarrer.

Le deuxième piège est de mélanger SQLite et production. SQLite est parfait en développement local, mais inadapté à la production dès qu’on franchit la barre du dizaine d’utilisateurs simultanés. Toujours basculer sur PostgreSQL avant la mise en ligne, et tester la migration avant le jour J. Strapi, Directus et Payload supportent tous trois cette migration via leur configuration de base.

Le troisième piège est d’oublier les sauvegardes automatisées. Hetzner propose des sauvegardes complètes du VPS pour 20 % du prix du serveur, soit environ 3 €/mois sur un CCX13. Activer cette option dès la création évite de découvrir leur absence le jour où la base est corrompue. Compléter par un dump PostgreSQL hebdomadaire envoyé sur Object Storage offre une seconde ligne de défense.

Le quatrième piège est de laisser le panneau d’admin exposé sur l’IP publique. Tous les CMS modernes proposent un blocage par IP ou un VPN-like via WireGuard. Pour un projet personnel, restreindre l’accès au /admin aux adresses IP de l’équipe technique réduit massivement la surface d’attaque. Pour un projet d’équipe, configurer une authentification SSO (Google Workspace, Authelia, Keycloak) reste la solution la plus saine.

Le cinquième piège, plus insidieux, est de traiter le CMS comme une dépendance définitive. Strapi 4 → 5 a cassé certains plugins ; Directus 9 → 10 → 11 a modifié plusieurs API ; Payload 2 → 3 a refondu l’intégration Next.js. Anticiper ces ruptures en limitant les plugins exotiques, en versionnant strictement les dépendances dans package.json, et en gardant un test end-to-end qui couvre les chemins critiques économise des semaines de débogage à chaque montée de version.

Décider en cinq questions

Si vous hésitez encore, répondez aux cinq questions suivantes. Les réponses pointent vers le bon outil dans la majorité des cas.

1. Avez-vous déjà une base de données SQL avec un schéma stabilisé ? Si oui, Directus est le choix par défaut.
2. Votre frontend est-il (ou sera-t-il) Next.js ? Si oui et que vous démarrez de zéro, Payload mérite un sérieux essai.
3. Avez-vous des rédacteurs non-techniques qui produisent un volume éditorial régulier ? Si oui, Strapi possède le panneau le plus accessible des trois.
4. Votre organisation prévoit-elle de dépasser 5 millions de dollars de revenus dans les trois ans ? Si oui, Directus exige une licence commerciale ; Strapi et Payload non.
5. Le projet doit-il vivre sur un VPS à 4 €/mois ? Si oui, Directus est le seul des trois qui tient cette contrainte sans grincer.

Aucun des trois CMS n’est universellement meilleur. La bonne grille de lecture est : « quel outil minimise la friction sur ce projet précis, avec ces contraintes précises ? ». Pour un journal en ligne avec dix rédacteurs, Strapi gagne. Pour un dashboard métier sur PostgreSQL existant, Directus gagne. Pour une boutique e-commerce custom en Next.js, Payload gagne.

Tutoriels associés

Pour passer du choix à la mise en pratique, trois tutoriels pas à pas accompagnent ce guide :

• Installer Payload CMS 3 dans une application Next.js — pas à pas
• Déployer Strapi 5 sur Hetzner avec PostgreSQL — pas à pas
• Migrer un blog WordPress vers Strapi — pas à pas

FAQ

Strapi, Directus ou Payload, lequel est le plus rapide en production ?

Sur des charges réelles avec cache HTTP correctement configuré, les trois CMS atteignent des performances comparables — quelques dizaines de millisecondes par requête en lecture. La différence vient de la consommation mémoire : Directus est le plus économe, Strapi le plus gourmand, Payload entre les deux.

Peut-on commencer en SQLite et migrer vers PostgreSQL plus tard ?

Oui pour les trois. La procédure consiste à exporter les données via l’outil de dump du CMS, à provisionner une base PostgreSQL, à modifier le fichier de configuration pour pointer vers la nouvelle base, et à réimporter. Compter une à deux heures pour un projet de taille moyenne. Faire ce basculement avant la mise en production publique évite les complications.

Faut-il payer Strapi Cloud ou héberger soi-même ?

Strapi Cloud commence autour de 15 €/mois pour un projet et grimpe rapidement avec le trafic. Pour un projet où l’équipe est à l’aise avec un VPS, l’auto-hébergement sur Hetzner CCX13 coûte moins cher et offre plus de contrôle. Pour une équipe sans compétence sysadmin, Strapi Cloud reste défendable malgré son prix.

Directus est-il vraiment gratuit avec sa licence BSL ?

Oui, dès lors que les revenus annuels totaux de l’organisation utilisatrice (toutes activités confondues) restent sous 5 millions de dollars. Le code source reste ouvert, on peut le forker, le modifier, le déployer en production sans rien payer. Au-delà de ce seuil, une licence commerciale doit être négociée auprès de Monospace.

Payload fonctionne-t-il sans Next.js ?

Techniquement, l’API REST et GraphQL exposée par Payload est consommable depuis n’importe quel client (Nuxt, SvelteKit, application mobile). Mais l’avantage de l’API locale et de l’intégration sous /app disparaît. Pour un usage non-Next.js, Strapi ou Directus restent des choix plus naturels.

Faut-il un développeur dédié pour maintenir un headless CMS ?

Pas nécessairement à plein temps. Une fois le déploiement initial fait et les sauvegardes automatisées configurées, la maintenance courante se résume à appliquer les mises à jour mensuelles (1 à 2 heures), surveiller les journaux (15 minutes par semaine), et traiter les bugs ponctuels. Un développeur à mi-temps couvre largement deux à trois projets headless de taille moyenne.

Ressources et références officielles

• Documentation Strapi 5 : docs.strapi.io
• Releases Strapi : github.com/strapi/strapi/releases
• Documentation Directus : directus.io/docs
• Licence Directus BSL 1.1 : directus.io/bsl
• Documentation Payload : payloadcms.com/docs
• Repository Payload : github.com/payloadcms/payload
• Tarifs Hetzner Cloud : hetzner.com/cloud
• PostgreSQL release notes : postgresql.org/docs/release
• Node.js LTS schedule : nodejs.org/en/about/previous-releases