Strapi est le CMS headless open source le plus utilisé dans l'écosystème JavaScript. Quand l'équipe a annoncé la version 5, la communauté a retenu son souffle : les migrations majeures de CMS sont rarement des parties de plaisir. Après plusieurs mois d'utilisation en production sur des projets clients, on a suffisamment de recul pour dresser un bilan honnête. Ce qui a changé, ce qui s'est amélioré, ce qui a posé problème, et surtout : faut-il migrer ?
Ce que Strapi v5 change en profondeur
Strapi v5 n'est pas une mise à jour cosmétique. C'est une refonte architecturale qui touche le coeur du système. Le changement le plus structurant est le passage du Entity Service API au Document Service API. Dans Strapi v4, chaque entrée de contenu était une "entity" avec un identifiant numérique unique. En v5, chaque entrée devient un "document" identifié par un documentId (une chaîne alphanumérique), et chaque document peut exister en plusieurs versions (brouillon, publié) et en plusieurs langues, de manière native.
Ce changement a des implications profondes. Dans Strapi v4, gérer l'internationalisation (i18n) et le système draft/publish nécessitait de jongler avec des entrées multiples et des relations parfois obscures. En v5, un article de blog est un seul document, qui contient ses versions française et anglaise, chacune avec son brouillon et sa version publiée. La logique est plus intuitive, le modèle de données plus propre, et les requêtes API plus prévisibles.
L'autre changement majeur, c'est l'adoption de TypeScript comme langage principal du projet. Strapi v4 était écrit en JavaScript avec des types ajoutés progressivement. Strapi v5 est écrit en TypeScript de bout en bout, et les projets générés sont en TypeScript par défaut. Les content types, les middlewares, les policies, les services : tout est typé. Pour les développeurs qui travaillent déjà en TypeScript, c'est une amélioration considérable de l'expérience de développement.
L'interface d'administration repensée
L'admin panel de Strapi v5 a subi un lifting significatif. Le design system a été revu avec une charte graphique plus moderne, des composants plus cohérents et une navigation simplifiée. Mais au-delà de l'esthétique, c'est l'architecture sous-jacente qui a changé.
L'admin est désormais construit sur une base plus modulaire. Le système de plugins a été repensé pour permettre des personnalisations plus profondes sans patcher le code source. Les zones d'injection (injection zones) permettent d'ajouter des composants React personnalisés à des endroits précis de l'interface, ce qui facilite l'adaptation du CMS aux besoins spécifiques de chaque client.
Pour les rédacteurs et les gestionnaires de contenu -- ceux qui utilisent Strapi au quotidien sans toucher au code -- l'interface est plus fluide. La navigation entre les content types est plus rapide, la recherche fonctionne mieux, et le système de permissions (RBAC) est plus lisible. Sur les projets où le CMS est utilisé par des non-techniques (c'est-à-dire la majorité), ces améliorations d'ergonomie ont un impact direct sur l'adoption de l'outil.
La migration v4 vers v5 : retour de terrain
Soyons francs : la migration de Strapi v4 vers v5 n'est pas triviale. Le changement d'Entity Service vers Document Service touche potentiellement l'ensemble du code personnalisé d'un projet. Les routes custom, les services, les middlewares, les lifecycle hooks : tout ce qui interagit avec l'API de données doit être adapté.
Sur un projet client (un site vitrine avec blog et système de réservation), la migration nous a pris environ trois jours de travail. Le plus gros du temps a été consacré à la réécriture des services custom qui utilisaient l'ancien Entity Service. Les content types eux-mêmes ont migré sans difficulté grâce à l'outil de migration fourni par Strapi (codemods). Les relations entre content types ont nécessité une attention particulière, notamment celles qui utilisaient des identifiants numériques en dur.
La migration de la base de données s'est déroulée correctement avec l'outil officiel, mais nous avons rencontré un problème sur les champs de type "media" avec des relations polymorphiques. Un correctif a été publié depuis, mais au moment de notre migration, il a fallu intervenir manuellement. Ce genre de détail rappelle pourquoi il est important de tester la migration sur un environnement de staging avant de toucher à la production.
Conseil pratique : avant de migrer, faites l'inventaire de tout le code custom de votre projet Strapi. Si vous n'avez que des content types standards sans personnalisation de l'API, la migration sera rapide. Si vous avez des dizaines de routes, services et middlewares personnalisés, prévoyez du temps.
Strapi v5 et l'écosystème : API headless et front-end
L'un des intérêts majeurs d'un CMS headless est sa capacité à alimenter n'importe quel front-end. Strapi v5 améliore cette dimension avec une API REST remaniée et un support GraphQL stabilisé.
L'API REST de Strapi v5 est plus cohérente que celle de la v4. Les réponses sont mieux structurées, la pagination est standardisée, et le système de filtrage est plus puissant. Le populate (la capacité à inclure des relations dans une seule requête) a été optimisé pour éviter les requêtes N+1 qui plombaient les performances sur les projets complexes en v4.
Côté GraphQL, le plugin a été réécrit pour tirer parti de la nouvelle architecture. Les types sont générés automatiquement à partir des content types, et le playground intégré facilite l'exploration de l'API. Pour les projets Astro ou Next.js qui consomment l'API Strapi, le passage en v5 se traduit par des requêtes plus rapides et des réponses plus prévisibles.
Un point qui mérite attention : le système de webhooks a été amélioré. Strapi v5 peut notifier un service externe (un pipeline de build, par exemple) dès qu'un contenu est publié, modifié ou supprimé. Combiné avec le build incrémental d'Astro ou le revalidate de Next.js, cela permet de mettre à jour un site statique en quelques secondes après une modification de contenu, sans reconstruire l'ensemble du site.
Hébergement et déploiement de Strapi v5
Strapi v5 tourne sur Node.js 18+ et supporte les bases de données PostgreSQL, MySQL, MariaDB et SQLite. En production, PostgreSQL est recommandé pour sa robustesse et ses performances, mais MySQL 8 fonctionne parfaitement -- c'est d'ailleurs la base que nous utilisons sur les projets WebSentinel, conteneurisée avec Docker.
Les exigences mémoire ont légèrement augmenté par rapport à la v4. Un serveur avec 2 Go de RAM est un minimum confortable pour Strapi v5 en production avec un trafic modéré. Pour les projets plus ambitieux ou avec du media processing (redimensionnement d'images, génération de thumbnails), 4 Go sont recommandés.
Le déploiement en conteneur Docker reste la méthode la plus fiable et reproductible. Strapi fournit un Dockerfile officiel pour la v5, et la communauté maintient des configurations docker-compose incluant la base de données et un reverse proxy. Pour ceux qui préfèrent les solutions managées, Strapi Cloud propose un hébergement clé en main, mais à un coût significativement plus élevé qu'un VPS auto-géré.
La question de la sécurité du serveur est cruciale pour un CMS headless. Contrairement à un site statique, Strapi expose une API et un panneau d'administration. Il faut donc sécuriser l'accès (HTTPS obligatoire, politique de mots de passe, limitation de débit), maintenir les mises à jour, et idéalement placer l'instance Strapi derrière un reverse proxy (Traefik ou Nginx) qui gère les certificats SSL et le filtrage.
Strapi v5 face à la concurrence
Le marché des CMS headless s'est densifié ces dernières années. Contentful, Sanity, Payload CMS, Directus, Keystatic : les alternatives ne manquent pas. Où se situe Strapi v5 dans ce paysage ?
Son avantage principal reste l'open source et l'auto-hébergement. Contrairement à Contentful ou Sanity, qui sont des SaaS propriétaires avec des grilles tarifaires qui grimpent vite, Strapi peut être hébergé sur votre propre serveur sans coût de licence. Pour une TPE ou une agence qui gère plusieurs sites, c'est un argument financier majeur.
Payload CMS, devenu un concurrent sérieux après son rachat par Vercel, propose une approche "code-first" séduisante et un typage TypeScript exemplaire. Mais son écosystème de plugins est encore jeune comparé à celui de Strapi, et sa communauté est plus petite. Directus, de son côté, excelle sur les projets qui partent d'une base de données existante, mais son interface d'administration est moins intuitive pour les non-techniques.
Strapi v5, avec sa refonte TypeScript, son Document Service API et son admin repensé, a comblé une partie du retard qu'il avait accumulé sur certains concurrents. Il reste le choix le plus équilibré entre flexibilité, facilité d'utilisation et maturité de l'écosystème.
Faut-il migrer maintenant ?
Si vous démarrez un nouveau projet, utilisez Strapi v5 sans hésiter. La v4 n'est plus recommandée pour les nouveaux projets, et la v5 est suffisamment stable pour la production après plusieurs mois de correctifs.
Si vous avez un projet Strapi v4 en production qui fonctionne, la migration n'est pas urgente. Strapi maintient la v4 avec des correctifs de sécurité pour encore plusieurs mois. Mais planifiez la migration : la v4 finira par être abandonnée, et plus vous attendez, plus le décalage technique sera important.
Si vous avez un projet Strapi v4 lourdement personnalisé, avec des dizaines de plugins custom et des intégrations complexes, prévoyez une migration méthodique. Testez sur un environnement de staging, migrez les content types d'abord, puis adaptez le code custom progressivement. Et si vous n'êtes pas sûr de la marche à suivre, faites appel à une équipe qui connaît le terrain.
Strapi v5 est un pas en avant significatif pour l'écosystème des CMS headless open source. La migration demande un effort réel, mais le résultat est un outil plus moderne, plus typé et plus performant. Pour les projets qui misent sur une architecture Jamstack avec un front-end en Astro ou Next.js, c'est un back-end de contenu qui fait le travail sans se mettre en travers du chemin.