Strapi VS Directus VS Payload

Les CMS headless sont des outils très puissants et adaptables à beaucoup de besoins. Ils font partie de l’avenir du web. Strapi, Directus, Payload, Contentful… il en existe de très nombreux, mais comment être sûr de choisir celui qui nous convient ?

Contexte

Dans le cadre de la refonte de nos sites chez i-Run, nous souhaitons mettre en place un CMS Headless pour la gestion du contenus des équipes marketing. Nous avons établi une liste de critères d’acceptations qui nous a permis d'étudier plusieurs CMS en profondeur.

Si vous n'êtes pas à l’aise avec le principe de CMS Headless, voici quelques articles qui en parlent ici et là.

L’un de nos principaux critères est de pouvoir heberger nous même ce CMS.

Nous avons établi une shortlist de CMS à analyser et tester : Strapi (v5), Directus (v11) et Payload (v2).

C’est parti pour le match !

Fonctionnalités métier

Traduction

Strapi, Payload et Directus permettent tous les trois de gérer la traduction des contenus (et de l’interface d’administration).
L’UX de Directus est plus claire et mieux aboutie en ce qui concerne la gestion des traductions, mais semble demander plus de configuration en amont.
Il est possible d’ajouter un “attribut” aux modèles pour définir leur site/langue d’appartenance et pouvoir ensuite filtrer les pages/éléments pour le site que l’on souhaite.

CRUD

Concernant la création, l'édition et la suppression des contenus, les 3 CMS le proposent très simplement. L’UX de Directus est, de mon point de vu, la plus agréable.

Rôles et permission

Strapi et Directus proposent nativement un système de gestion des rôles avec une gestion très fine des permissions, jusqu’aux champs, et il est même possible d’utiliser des conditions sur leur contenu.
Pour Payload il est possible de faire tout ce que l’on veut, à condition de le coder.

Infra

Swarn/Docker

Directus est le seul des 3 CMS à proposer une image docker officielle. Strapi et Payload proposent tout de même des exemples de configuration.
Cela n’est pas un frein pour le déploiement et la scalabilité, mais demande un peu plus de travail de l'équipe infra.

S3/Minio

Directus est le seul à proposer nativement l’utilisation d’un conteneur S3 : il faut juste remplir des variables d’environnement pour que cela fonctionne.

Payload et Strapi permettent aussi d’implémenter un conteneur S3, mais cela passe par le code, ou l’installation d’un plugin tout fait.

Respect du workflow staging-preprod-prod

Concernant Strapi, la configuration des modèles de données (entre autre) est stockée dans les fichiers de code, et chaque modification de modèle nécessite de rebuilder le code (c’est automatique en mode dev). Cela signifie qu’en production, il n’est absolument pas possible de modifier les modèles de données, et ça implique donc une très forte dépendance aux developpeurs tout au long de la vie du CMS.
Pour la synchronisation des données en elles-mêmes, Strapi met à disposition une CLI qui permet de faire des exports, imports et transferts entre les instances.

Directus stocke l’intégralité des modèles et des données en base. De plus, il a mis en place un système de migration interne, basé sur Knex, qui semble être le pendant en JS de Flyway.

Le fonctionnement de Payload se rapproche fortement de celui de Strapi : toute la configuration des modèles se fait dans le code, avec la même contrainte concernant l’impossibilité de modifier la configuration en production.
Comme directus, Payload a mis en place un systeme de migration interne.

Gestion des BDD

Strapi supporte SQLite, PostgreSQL, MariaDB et MySQL.

Directus supporte SQLite, PostgreSQL, MariaDB, MySQL, MS SQL Server, CockroachDB, et OracleDB.

Payload supporte MongoDB et PostgreSQL.

Gestion de l’authentification

Directus propose nativement l’implémentation du SSO, toujours à travers l’usage de variables d’environnement.

Strapi semble premettre de gérer le SSO avec Auth0 ou Keycloak, via l’implémentation d’un provider. Mais cela n’est pas très clair car le SSO est l’une des fonctionnalité normalement proposée avec la licence entreprise.

Pour Payload, ce qui est possible de faire ne semble pas très évident, mais vu que nous avons la main sur le code, cela doit être possible d’implementer un provider pour gérer le SSO.

API modulaire

Les 3 CMS implémentent GraphQL et des API Rest qui permettent une grande modularité lors de la récupération des données.

Performances

Temps de latences

Voilà le seul benchmark trouvé, peut être biaisé car effectué par Payload, mais qui semble assez complet et complexe : https://payloadcms.com/blog/performance-benchmarks.

En résumé : Payload est 3x plus rapide que Directus et presque 7x plus rapide que Strapi en temps de réponse.

Cache applicatif

Directus est le seul des 3 CMS à embarquer nativement un systeme de cache.
Strapi et Payload permettent cependant d’en implémenter un, toujours via du code.

Facilité d’utilisation

UI intuituve

Les UIs des 3 CMS sont globalement assez intuitives. Celle de Strapi reste cependant en dessous de Directus et Payload : il m’est arrivée plusieurs fois de me perdre dans les menus, et certains inputs ne sont pas optimaux.

Un autre point positif pour Directus : le paramétrage des listings de pages/éléments (filtres, colonnes affichées, disposition…) semble se conserver automatiquement par utilisateurs.

Documentation disponible

Directus a une documentation exhaustive, autant coté développeur qu’utilisateur, elle est lisible et claire.

La documentation de Strapi est aussi très fournie, pour développeur et utilisateur également, mais est parfois un peu lourde, répétitive et désorganisée.

Payload posséde une unique doc très complète, plutôt orientée développeur, mais la partie utilisateur étant très épurée, cela n’est pas génant.

Courbe d’appentissage faible

Globalement l’apprentissage des utilisateurs pour les 3 CMS est relativement simple.

Coté developpeur, sur Directus il n’y a pas de code à manipuler, juste de la configuration à faire sur les modèles de données. Cette configuration est très importante et peut être fastidieuse pour répondre complétement aux besoins métiers.

Sur Strapi et Payload le code est du JS/Typescript et du React pour les composants. TOUTE la configuration de Payload se fait dans le code contrairement à Strapi où c’est en partie dans le code et en partie dans l’administration. Il est du coup plus difficile d’appréhender Strapi car cela demande une certaine gymnastique de savoir où et comment faire telle ou telle configuration/personnalisation.

Support et maintenance

Notoriété

Strapi est le plus connu des 3, avec 61.9k étoiles sur Github, contre 26.6k pour Directus et 21.7k pour Payload.

Les 3 sont stables, actifs, ont très bonne réputation et un nombre important de contributeurs.

https://snyk.io/advisor/npm-package/@strapi/strapi
https://snyk.io/advisor/npm-package/directus
https://snyk.io/advisor/npm-package/payload

Mises à jour fréquentes

Les 3 CMS ont des mises à jours très régulières.
Strapi semble cependant maintenir les anciennes versions plus longtemps que les autres.

La version 5 de Strapi est actuellement en RC tout comme la version 11 de Directus. La version 3 de Payload est en Beta depuis au moins avril 2023.

Support disponible

Strapi, Directus et Payload ont tous les 3 un repo github assez actif, avec des tickets qui semblent être pris en compte rapidement.

Directus, Strapi et Payload ont en plus un Discord disponible.

Personnalisation du CMS

Chez Strapi “tout est plugin”. Il y a une grande liberté de personnalisation, mais cela nécessite du code. Il existe déjà une grande variété de plugins. Il y a deux notions chez Strapi, le back-end pour la customisation des modèles, de l’API et des webhooks, et l'admin panel pour la configuration de l’interface de gestion des contenus.
Cette délimitation, et le fonctionnement global de Strapi demandent une montée en compétence pour les developpeurs, ainsi qu’une rigueur importante au risque de compromettre la cohérence de l’application, et surtout cela implique un suivi et une maintenance non négligeable.
Strapi possède un marketplace très fournis en plugins et provider (plus de 200 au total).

Le fonctionnement de Payload se rapproche de celui de Strapi. Toutes les configurations et personalisations se font en code. Mais la structuration de celui-ci semble bien plus simple et propre que chez Strapi. Un peu moins de 100 plugins pour Payload sont référencés sur Github.

Chez Directus, une très grandes partie de la configuration peut se faire directement depuis l’interface. Il est possible de gérer l’affichage des données de plusieurs manières. Il y a également un système de flux disponible pour envoyer des mails, déclencher des actions… ce qui rend déjà Directus très personnalisable. Et si besoin d’aller encore plus loin, il y a la possibilité de créer des extensions (en VueJs) pour rajouter des composants particuliers. Un marketplace existe également, en Beta pour le moment, qui regroupe déjà plus de 120 extensions.

Licence

Payload est sous licence open source MIT, “Forever free and fully open-source”.

Directus est sous licence BSL 1.1 pour les usages commeciaux.

Strapi est sous licence open source MIT.

Cout de la licence

Payload est complétement gratuit.

Directus : une licence commerciale est requise pour les entreprise qui dépasses les 5 millions de dollards en total finances par an.

Strapi, en self-hosted, propose une version totalement gratuite, et une autre à 99$/sièges/mois (!) afin d’avoir en plus un audit des logs, le SSO, la mise en place des workflows et release pour la gestion des contenus et un accompagnement technique pour l’installation.

Conclusion

Pour notre usage, et en fonction des critères d’acceptations que nous avons défini, Directus semble être le plus adapté.
En terme d’utilisation, c’est celui que j’ai trouvé le plus simple et complet, même s’il demande un petit temps d’adaptation.

J’ai également beaucoup apprécié Payload, mais sa configuration des modèles via le code est un vrai no-go pour nous, car nous souhaitons une solution pour justement libérer les développeurs de la charge qu’entraîne la gestion d’un CMS.

Malgré sa popularité, Strapi reste complexe à mettre en place, et je crains que cela soit un poids à maintenir au fil du temps et des mises à jour.