//. 081 Dans la jungle des CMS Headless

#cms #headless #strapi #directus #contentfull #prismic #javascript #graphql

00:00:00 Introduction/Sommaire
00:03:30 Les fonctionnalités qui permettent de choisir
00:20:45 Les CMS Headless Git Based
00:35:20 Les BAAS (Backend As A Service)
00:40:30 Les CMS Headless SAAS (Software As A Service)
01:02:50 Les CMS Headless Cloud
01:03:35 Les CMS Headless Self Hosted
01:23:30 Conclusion

Le sujet des CMS Headless est très vaste. Les solutions disponibles sont impressionnantes. Il y a une quantité d’acteurs importants. Et surtout, les offres sont toutes différentes. En mode Saas, auto-hébergé, Git based ! Comment faire son choix.

Sans parler des fonctionnalités, multilingue, gestion des accès, preview…
Nous allons essayer de vous aider à faire un choix dans la jungle de CMS Headless. Vous expliquez les choses à vérifier. Nous allons tenter de vous faire comprendre qu’en fonction du client et du projet, il y a des CMS plus adaptés que d’autres.

LES ATTENTES OU FONCTIONNALITÉS À NE PAS NÉGLIGER

Multilingue
Gestions accès/rôles (très utile pour les entreprises avec différents services. Marketing, rédaction,…)
Éditeurs (WYSIWIG ou champs classiques)
Preview (vue des changements avant mise en ligne) Très important pour les sites statiques.
Gestion des médias (interne, externe, redimensionnement…) Souvent oublié mais primordial !
Process de validation (draft, review, validation etc… ) Certaines entreprises ont des relectures avant publication.
La simplicité d’utilisation et l’ergonomie. En tant que dev, on ne pense jamais à ça mais c’est aussi très important.
La vitesse (pour un éditeur qui passe du temps dans l’admin, c’est vite frustrant d’attendre)
Les librairies disponibles pour l’intégration. Fort couplage ou pas dans le code.
La customisation (le code est-il hookable pour exécuter des tâches spécifiques)
Webhook pour lancer les déploiements
Système d’import ou d’export. Le client ne va pas recréer tout le contenu.
Système de hub (import d’autres services pour intégration dans le contenu) e-commerce par exemple.

Les types de CMS

## GIT based CMS

FONCTIONNEMENT
Le CMS ajoute une couche au-dessus de l’application et rend les éléments éditables ou le CMS propose un dashboard pour éditer les fichiers de contenu.
Dans tous les cas, ce sont les fichiers de contenu qui sont édités (MD, JSON, CSV).
On parle de Git parce que toutes les data sont stockées au même endroit que le code source du projet.
Quels types de projet :
Très adapté aux sites statiques de par le fonctionnement. Mais il est possible de faire aussi du dynamique SSR. Avec Nuxt content par exemple.

QUELS TYPE DE CLIENT
En fonction du CMS utilisé ça peut être plus ou moins simple. Un CMS visuel peut être agréable pour les clients. A contrario, un système plus basique conviendrait plus à des personnes techniques. Le retour régulier des clients est la compréhension du déploiement par rapport à Git et l’automatisation qui va derrière. Généralement, les utilisateurs aiment voir les modifications rapidement et ne comprennent pas qu’il faille attendre.

AVANTAGES
Stockage simple
Certains frameworks gèrent bien les fichiers md.

INCONVÉNIENTS
Design limité sauf si on utilise du mdx/mdc mais ça complique les choses
A quels éléments prêter attention :
Mélange code CMS/front (Tina CMS).
Gestion des images
Gestion des accès

OFFRES
Statamic (basé sur Laravel) Rest, GraphQL, Live Preview, Revisions, Multisite,…) https://statamic.com/features (propriétaire)
Nuxt Studio (seulement Nuxt) https://nuxt.studio/ (Preview) Non open-source
Decap CMS https://decapcms.org/ (Workflow, preview) (open-source)
Sveltia CMS https://github.com/sveltia/sveltia-cms (Comme Decap CMS en plus light) (open-source)
KeyStatic https://keystatic.com/ (open-source)
Static CMS https://www.staticcms.org/ (open-source)
Tina CMS https://tina.io/ (open-source et cloud) Media (S3, cloudinary,..)
Yama CMS https://yama-cms.com/ (propriétaire)

## Warning ! BAAS (Backend As A Service)

FONCTIONNEMENT
Les services Backend as a Service (BAAS) sont des solutions cloud qui simplifient le développement d’applications en fournissant une infrastructure backend prête à l’emploi.
Ces services gèrent les aspects tels que les serveurs, les bases de données, les APIs et la sécurité, permettant aux développeurs de se concentrer sur la création de fonctionnalités frontales.
Avec des fonctionnalités telles que la mise à l’échelle automatique, la gestion des utilisateurs, et des coûts basés sur l’utilisation, les BAAS offrent une approche efficace et rentable pour le développement d’applications, en éliminant la nécessité de gérer directement l’infrastructure backend.

QUELS TYPES DE PROJET
……
La suite sur https://double-slash.dev/podcasts/cmsheadless/

Bonne écoute !

Bonjour à tous, bienvenue sur ce nouvel épisode de Double Slash, épisode spécial CMS Headless qu’on avait promis à tout le monde, donc on a bossé un petit peu dessus. Comme d’habitude, nous sommes avec Alex. Salut Alex ! Salut Patrick ! Salut tout le monde !

Ecoute, donc sujet assez vaste, donc je ne sais pas combien de temps va durer l’épisode. Alors j’espère que vous avez du temps devant vous, que vous êtes dans un train pour un voyage de 4 heures à peu près.

Ça risque d’être un petit peu long, mais on va essayer d’être assez exhaustif on va dire. Mais sujet assez vaste, en tout cas on s’en est rendu compte en le préparant, qu’il y a beaucoup d’offres, beaucoup de différents types de CMS. Donc est-ce qu’on fait un petit sommaire Alex ? Ouais carrément, carrément.

Ce qu’il faut comprendre sur les CMS et ce qu’on va essayer de parler dans cet épisode, c’est justement de voir tous les points, toutes les fonctionnalités qu’on doit bien regarder avant de bien choisir son CMS par rapport à son projet.

Il y a plein de fonctionnalités qui ne servent à rien ou peut-être qui vont être super utiles pour nous. Donc faut-il encore être au clair, être lucide sur quelles sont toutes ces fonctionnalités qu’on peut attendre d’un CMS. Et après en fait il y a différents types de CMS.

On va trouver toutes les GitBase, donc c’est les CMS qui sont basées sur Git. On va avoir aussi des faux amis qui ne sont pas tout à fait des CMS, mais c’est les Backend as a Service où justement on verra comment, attention, tous les warnings qu’il nous faut

En fait se concentrer sur éviter justement, pour éviter de tomber dans ces pièges-là. Évidemment les CMS SaaS, donc as a Service, où là en fait on vient utiliser tout est sur le cloud, tout est payant ou self-hosté. Et c’est la dernière, on va dire catégorie, c’est tous les CMS qu’on vient héberger nous-mêmes.

Et où là en fait il faudra gérer l’infra, tout ça. Mais on va dire c’est toutes les catégories et toutes les fonctionnalités qu’on va développer dans cet épisode qui peut-être va durer longtemps, on ne sait pas encore. C’est bon, j’ai pris de l’eau, donc c’est bon.

Oui, alors évidemment on va commencer par les fonctionnalités à ne pas négliger quand on fait un choix de CMS parce qu’évidemment comme tous les projets, le choix d’un CMS Headless dépend aussi beaucoup du client et du projet en fait.

Il n’y a pas de CMS qui est idéal pour tous les projets en fait. A chaque fois, ça dépend. C’est sûr. Après moi, même si je suis normand, je ne vais pas faire une réponse de normand, mais en mode ça dépend. Parfois oui, parfois non. Mais en fait là, c’est vraiment ça.

C’est là où il faut comprendre que mettre le même outil partout pour tous les clients, pour tous les projets et pour toutes les équipes, peut-être que ce n’est pas du tout pertinent. Mais d’un autre côté, quand on est en agence aussi, si on est dans un process d’industrialiser

Tout ça, si on doit gérer plusieurs technos, plusieurs outils, c’est plus compliqué à mettre en place. Il nous faut plus d’expertise. Donc, ça se négocie. Donc, le choix, en tout cas si on doit implémenter un process dans une agence, le choix du CMS va être crucial. Crucial, clairement. Oui, toujours.

Ok, on y va. C’est parti. Première fonctionnalité quand même importante. Enfin, ça dépend en fait. Déjà, ça dépend si tu fais un site que pour la France ou si tu fais un site multilangue. Exactement. C’est est-ce que ton contenu va être dans une seule langue ou ton contenu doit être

Dans multilingue ? Parce que parfois, en fait, tu vas avoir des clients qui ne sont qu’espagnols. Bon, tout ton contenu sera en une seule langue et c’est plutôt simple. Donc, quand il n’y a qu’une seule langue à gérer, là, on ne parle bien pas de l’interface,

On parle bien du contenu qui doit être multilingue. Et ça, c’est un gros, gros point. C’est clair. Oui, le contenu multilingue qui soit facile à gérer, que tu peux dupliquer pour écrire dans une autre langue, etc. Donc, voilà, une interface qui soit bien faite et qui permet de gérer le multilingue

Facilement en fait. Deuxième chose, c’est la gestion. Alors, ce n’est pas forcément nécessaire pour tous les projets parce qu’il ne peut y avoir qu’une seule personne qui gère le site. Donc, voilà, la gestion des rôles n’est pas forcément primordiale dans ce cas-là.

Mais souvent, il y a besoin de gestion des accès et des rôles en fait dans le système pour que les différentes personnes… Parce que vous pouvez avoir par exemple dans une entreprise un service marketing, un service rédactionnel, etc. Donc, ils n’ont pas accès aux mêmes choses.

Donc, voilà, on peut avoir la possibilité de différencier les accès pour que le marketing ait accès au système de marketing, toutes les bannières, tout ça, et que la rédactionnelle ne soit que juste dans le rédactionnel. Et ce n’est pas en fait l’idée de la gestion des accès.

Ce n’est pas uniquement pour empêcher les gens d’arriver à… C’est pour simplifier en fait l’interface. Quand quelqu’un arrive sur le CMS, que l’interface soit plus simple et qu’il y ait accès aux choses qui la concernent. Carrément. Un autre point aussi qui est intéressant, c’est les éditeurs.

Mais en fait, ça rejoint sur la gestion des rôles. Si un développeur, on lui donne un fichier markdown, il va s’en sortir. Par contre, un client ou quelqu’un qui fait du copyright, peut-être, elle est moins familiarisée avec le markdown.

Et donc, en fait, il va falloir savoir si on a un système d’éditeur, un peu avec des champs classiques qui vont être interprétés, ou en fait, à l’ancienne, un peu à la doc avec les WYSIWYG, où en fait, on voit directement une sorte de preview, où on voit

En fait en instantané les modifications. Parce qu’une équipe marketing, en fait, ne va pas avoir la même appétence et ne va pas avoir le même niveau d’abstraction, ou en tout cas de capacité d’abstraction de prendre un espèce de bout de markdown et hop, ça va faire l’article.

Quand on est développeur, on y arrive assez bien, parce qu’on fait ça toute la journée avec “ok, on a notre éditeur de code et notre rendu”, sauf que ce n’est pas un mécanisme qui est facile pour le marketing, pas toujours.

D’où l’intérêt, en fait, d’avoir la possibilité d’avoir des éditeurs où en fait, on voit directement ce qu’on modifie, ou en tout cas, la personne qui est en charge de rédiger va directement rédiger dans le contexte et voit directement le rendu. Ça, c’est très propre.

Alors déjà, c’est assez variable dans les CMS, ça va du markdown, comme tu dis, où tu vas éditer le markdown, jusqu’au système où tu as une interface, où tu vas glisser des blocs dedans, comme je ne sais plus comment il s’appelle. Builder.io ?

Oui, Builder.io, où carrément tu as un système avec des blocs, tu glisses, etc. Storyblock ? Ça dépend déjà de la capacité technique de la personne qui va éditer, des personnes qui vont éditer. Et puis après, il y a aussi une préférence.

Il y a des gens qui n’aiment pas forcément le système de blocs que tu vas glisser, déposer. Ils préfèrent plutôt des champs classiques parce qu’ils savent où remplir le texte. Pour eux, c’est plus simple. Ça dépend vraiment. Ça, c’est vraiment un point hyper important.

C’est un des points les plus importants, j’ai envie de dire presque. C’est l’interface d’édition. Et aussi avec ce système de prévu. Oui, voilà, c’est ce que j’allais dire. Le système de prévu qui est super important, notamment quand on fait tout ce qui est site statique.

Il y a une chose qu’il faut vraiment prendre en compte, c’est qu’il y a des personnes qui ne comprennent pas qu’il y a un délai de déploiement quand on fait un site statique. Donc, ils ne comprennent pas qu’il y a une attente entre une modification et que ce soit en ligne.

Donc, le mode prévu permet à ces personnes-là de voir les changements instantanément, bien avant le déploiement et de valider, corriger, etc. Ça, c’est vraiment très important. Yes, carrément. Jamstack, la Jamstack. On en a assez parlé sur ce podcast, on ne va pas revenir dessus.

Mais en tout cas, sur le statique, c’est vrai que c’est un point qui est assez important. En parlant de fichiers statiques et d’assets statiques, il y a un autre point sur lequel on doit se pencher et apporter une vigilance, c’est la gestion justement de tous ces assets,

C’est-à-dire les images, si on a des logos, des choses spécifiques au sein de l’entreprise ou après au sein de l’article. En fait, on va pouvoir glisser des images et on sait que les images, c’est un gros problème en termes de poids, de performance, c’est un impact non négligeable.

Donc, est-ce que le CMS, lui, a une gestion des médias internes où on doit l’externaliser, par exemple sur un S3, où on doit le répliquer sur différents CDN pour avoir une performance, est-ce que c’est sur un serveur ou sur un CDN d’ailleurs ? Est-ce que la gestion des

Images, on revient redimensionner les images à la volée ou c’est à nous de le faire en tant que développeur ? Voilà, toute la partie de, on va dire toute la gestion des médias est un critère aussi à prendre en compte parce que très vite, si on ne gère

Pas ça, on peut vite se retrouver avec des fichiers PSD de 200 MO injectés par le client et là, le site, il est en PLS. Oui, complètement. Ça, c’est souvent un service qui est offert par les SASS, comme je prends Prismic par

Exemple, ils ont un système de redimensionnement, tout ça, puisque, toujours prendre en compte que la première règle, c’est de ne pas faire confiance à l’utilisateur. On sait très bien que même si tu lui dis de ne pas mettre une image de plus de 800

KO, il va te mettre une image de 3 MO. Donc, si tu ne automatises pas les choses au niveau des images, des médias, ça va vite devenir problématique. Donc, soit les SASS, ils le permettent, ils ont déjà des systèmes internes qui sont

Du coup, parce qu’on paye, donc on a tous les services qui sont dispo, soit il y a des CMS self-hosted ou des trucs comme ça, ou des GitBase qu’on va voir après, qui ont des connexions avec des S3, tout ça, qui permettent de gérer tout ça. Excellent.

Et on déroule toujours sur les points de vigilance, le process de validation. En fait, ce qu’il faut comprendre par là, c’est que parfois, il y a des personnes qui vont écrire un brouillon, mais ce brouillon doit être validé par l’équipe marketing ou par un copywriter ou par je ne sais pas qui.

Et donc, en fait, il y a tout un système de flow, en fait, de validation du contenu. Sauf que, alors peut-être que ça peut être sur des postes, mais pareil, sur une recette de cuisine, par exemple, c’est pareil. Il faut que ça soit validé potentiellement.

Et donc, tous les CMS, en fait, ne permettent pas d’avoir un système de flow, de review. Souvent, c’est corrélé avec la gestion des rôles, en fait, qu’on a parlé précédemment. Souvent, c’est des fonctionnalités qui sont couplées. Et donc, c’est assez intéressant.

Et en tout cas, c’est vraiment à mettre en place pour éviter justement de se faire déborder par une tonne d’informations et surtout de bien respecter toute la chaîne de hiérarchie, de validation de données, clairement. Tout à fait. Un dernier point sur tout ce qui est ergonomie.

En fait, il y a une chose qui est… alors je me suis rendu compte avec l’expérience, en fait, je suis tombé sur des clients où tu as des personnes, en fait, dans des entreprises qui passent énormément de temps, en fait, dans le CMS à rédiger des articles, etc. toute la journée.

Et il y a deux choses. C’est l’ergonomie du CMS, est-ce qu’il est bien ergonomique, est-ce qu’il est simple d’utilisation ? Et surtout, une chose primordiale aussi, c’est la vitesse, en fait. C’est-à-dire qu’une personne qui va passer plusieurs heures par jour dans le CMS, si

À chaque fois que tu dois recharger une page, etc., c’est long, en fait, ça devient problématique parce qu’elle perd du temps toute la journée. Donc ça, c’est quelque chose qui est vraiment très, très important. On n’y pense pas forcément, mais c’est des retours utilisateurs que j’ai eus, moi,

Des personnes qui se plaignaient parce que c’était long, etc. Donc, on a tout fait pour que ça aille plus vite. Mais voilà, c’est des choses, voilà, ergonomie, vitesse, etc. C’est à ne pas négliger quand même quand on a un choix de CMS, surtout quand la personne paye, en fait.

Après, sur les CMS qu’on paye, normalement, on ne devrait pas avoir ce problème-là. S’il est bien fait, oui. Mais après, tu peux avoir des CMS qui sont assez complexes, comme Builder.io, que tu disais tout à l’heure. L’interface est super complexe. Il n’y a pas forcément, enfin, limite besoin d’une formation pour l’utiliser.

Quand tu as un CMS où il faut être formé pour l’utiliser, c’est que déjà, à ce moment-là, il y a un problème. Le truc n’est pas super intuitif. Et les derniers points, on va aborder les derniers points, mais là, ça concerne plus le côté dev, etc.

Donc, je te laisse faire pour la customisation, tout ce qui est hook, etc. Que tu connais bien. En fait, pour avoir joué avec, c’est quand même intéressant. Parfois, notre CMS, il est écrit que quand on a une entité qui est inscrite, on ne peut rien faire. C’est comme ça.

Par contre, il y a des CMS qui nous permettent de dire, après la création d’une entité, tu vas exécuter ce bout de code. Et ça, ça nous permet de faire beaucoup de choses. Parce que, par exemple, on rajoute un article dans notre e-commerce et ce produit-là, on

Va pouvoir l’injecter directement sur un moteur de recherche dédié. Par exemple, un Algolia ou un MailSearch. Et donc, en fait, dans le système de Flow, quand la personne est venue enregistrer ou updater le produit, automatiquement, on n’a pas besoin de déclencher quelque chose.

Ça va se faire automatiquement parce qu’on a un hook qui nous dit, exécute ce bout de code à la création, à l’update, au delete, au n’importe quoi. Et donc, en fait, ça, c’est un niveau de précision qui est vachement intéressant

Pour nous en tant que développeurs parce qu’on va pouvoir injecter des bouts de code à des moments clés de, on va dire, le cycle de vie du contenu. Et donc, ça, c’est hyper riche. Oui, très important. C’est des choses aussi qu’il faut regarder quand c’est nécessaire.

Pareil, les webhooks, ça rejoint ce que tu viens de dire avec les hooks, mais c’est des choses plus simples qui vont appeler ou lancer le déploiement quand tu vas faire un changement de contenu, etc. Pareil pour les sites statiques, super important parce que sinon, si tu dois le faire à la

Main, ça ne va pas être pratique. Par contre, tu vois, pour revenir sur les webhooks et sur les hooks de customisation, en fait, avec ton webhook, potentiellement, tu pourrais tout faire, sauf que tu vas être obligé d’externaliser ton code. Et donc, c’est une autre code base, c’est autre chose.

Par exemple, une serverless function, très bien, mais là, ce n’est pas au sein du CMS. Je pense, par exemple, à… je n’ai plus le nom en tête, merde, mais PocketBase, par exemple, il te permet d’écrire au sein de ton code.

Donc, en fait, c’est au sein du code du CMS où on va pouvoir exécuter notre propre code. Et donc, ce n’est pas externel, contrairement aux webhooks où, en fait, là, c’est à toi de fournir le webhook externe et c’est extérieur au CMS.

Vraiment, la customisation et l’injection de code, au moment, à des hooks bien spécifiques, c’est au sein du CMS. Tu fais bien de préciser, les hooks, c’est vraiment du code que tu exécutes, alors que les webhooks, c’est des informations que tu envoies à l’extérieur pour synchroniser

Un CRM ou des choses comme ça, à chaque fois que tu… différentes infos. Donc, du coup, ça rejoint aussi les deux derniers points, c’est le système d’import et d’export parce que, bon, parfois, c’est un site neuf, donc, du coup, tu n’as pas

De contenu, mais parfois, tu dois transférer du contenu d’un autre site sur le nouveau CMS et aussi l’exporter. Donc, ça, c’est important de pouvoir réimporter le contenu et il y a aussi le système. Alors, système de hub, c’est important, ça aussi. Je sais que ça existe sur Prismic.

Enfin, il y en a d’autres où ça existe, c’est-à-dire qu’à un moment donné, tu auras peut-être besoin d’importer du contenu e-commerce. Si tu as un e-commerce à côté, que dans ton contenu, tu veux montrer des produits, tout ça, tu vas importer ces produits-là automatiquement pour pouvoir les présenter dans le contenu.

Donc, d’avoir le système d’import automatique d’autres systèmes e-commerce, etc. Donc, ça, c’est des choses, voilà, ça peut être nécessaire. Ce n’est pas tout le temps nécessaire, mais ça peut être nécessaire. Après, même sur de l’import-export, juste sur la simple refonte aussi où ils avaient

Un système actuel qui était X, ils passent sur un système Y, comment on fait pour migrer toute la donnée, tout simplement ? Et ça, en fait, c’est un d’un service à un autre ou aussi un système de backup, des choses comme ça.

Et sur les hubs, ça rejoint sur tout ce qui est un peu dans l’air du temps en ce moment, c’est la data fédération. On vient agréger toutes les sources de données pour en fait avoir qu’un seul endpoint.

En tout cas, pour nous, en tout cas, développeurs, on n’a qu’un seul outil sur lequel on va se connecter et on va connecter en fait différentes bases, différents services qui vont nous faciliter la vie, nous, en tant que dev parce qu’on va se connecter qu’à un seul service

Et non pas à 7, 8 ou 10 services. Et c’est pareil pour les utilisateurs. Faire l’association entre la recette de cuisine et l’article sera d’autant plus facile s’il y a ce système de hub, clairement. Avec des liens qui vont t’envoyer sur l’e-commerce pour t’acheter des fouets pour battre les

Œufs ou des trucs comme ça. Exactement, exactement. Donc voilà, on a fait cette liste là, ça dépend. Donc vous prenez cette liste, ça dépend des clients. Il y a des points qui sont importants, des points qui ne sont pas nécessaires. En fonction de ça, ça fait déjà une base pour choisir un CMS.

Exactement, et en fait, vous allez pouvoir cuter bon nombre de services parce qu’il y a tellement, il y a pléthore en fait de CMS. Il y en a tellement que justement si on n’a pas une grille de lecture, si on n’a pas

Des informations pour faire son choix, on peut vite être perdu et on rentre vite dans la hype. Dans la hype, c’est le mec qui a crié le plus fort. En clair, le meilleur marketeur qui a réussi à mieux vous marketer et qui va vous utiliser

Pour refourguer son produit qui peut-être n’est pas le plus adapté pour votre client, pour votre projet. Carrément. Ok, donc maintenant, on va passer au type de CMS. Donc, on a, je crois que j’ai mis, il y a quatre types de CMS, quatre catégories, on va dire. Donc, le premier.

On commence par les GitBase, par les GitBase. Parce que c’est la base et alors, je sais que tu es fan, on est tous les deux fans de GitBase et pour information, le site de double slash du podcast est fait avec, est orchestré

Uniquement avec Git et donc on n’a pas de CMS, on fait tout en markdown, on injecte tous nos fichiers là-dedans et on administre notre site comme ça. Ça marche. Tout est stocké sur Git, dans le code source, tout est open source, tout est visible.

Alors, c’est quoi le fonctionnement vraiment d’un CMS GitBase ? GitBase, alors GitBase, en fait, c’est tout simplement, on dit GitBase parce que c’est basé sur les fichiers. Donc, tout le contenu est stocké dans des fichiers, que ce soit markdown, ça peut être

Du Json ou du CSV, enfin moins CSV, mais plutôt Json et markdown principalement. Et donc, en fait, comme c’est dans des fichiers, c’est souvent stocké au même endroit que le code source du site ou de l’application et donc c’est sauvé sur Git, tout simplement.

Donc, tout est sur le même répertoire, en fait, le contenu et le code source de l’application et donc on dit GitBase parce que tout est sauvé sur le site. Donc, il n’y a pas de base de données, il n’y a pas de… tout est au même endroit, en fait, la plupart du temps.

C’est ça le fonctionnement. Ok. Et pour le coup, c’est pour quel type de projet ? Toi, tu verrais ça plutôt pour qui ? Pour quel type de projet ? Alors, c’est super. Pourquoi ? C’est super adapté aux sites statiques, la plupart des sites statiques.

Après, ça peut aussi être du SSR parce que NextContent, normalement, il lit le SSR, il me semble. Enfin, il est capable de le gérer aussi. Mais c’est souvent adapté vraiment aux sites statiques puisqu’on a un déploiement, c’est stocké au même endroit, on a un déploiement automatique et puis c’est assez simple, en

Fait, à gérer. Mais oui, non, c’est surtout… enfin, je ne sais pas si tu es d’accord avec moi, mais c’est surtout les sites statiques en général. Moi, je suis complètement d’accord. Ce n’est pas du tout adapté si, par exemple, on a de la fraîcheur, on a un article qui

Est publié toutes les deux heures. Clairement, ce n’est pas du tout adapté parce que ce qu’il faut bien se rappeler, c’est que le site n’existe pas et il est uniquement dans le code source. Donc, si le code source n’est pas construit et déployé, l’article n’existe pas, n’est pas visible.

Donc, par définition, en fait, chaque mise à jour veut dire un déploiement. Donc, si on doit déployer toutes les dix minutes, clairement, ce n’est pas du tout adapté. Non, ce n’est pas adapté. Après, ça dépend. Il y a des systèmes qui déploient hyper rapidement.

Ça peut déployer en 15 secondes, 30 secondes, enfin, ça dépend. Mais c’est sûr que si tu as un contenu qui est… enfin, s’il y a énormément de contenu et qu’on rajoute du contenu plusieurs fois par jour, ce n’est pas forcément le jeu adapté.

Après, on ne va pas refaire la JAMstack, les avantages, etc. Mais c’est quand même… on n’a pas de base. Déjà, c’est des statiques, c’est super rapide, c’est sécurisé, il n’y a pas de base de données, etc. Donc, il y a plein d’avantages. Donc… Oui, mais surtout, c’est que tu ne te fades pas.

Oui, tu ne te fades pas. En fait, toute une base de données, par exemple, tu vois, si tu n’as pas de base de données, ça veut dire que tu n’as pas d’ORM. Si tu n’as pas d’ORM, enfin, tu vois, on vient simplifier au maximum l’utilisation.

Et moi, je considère qu’aujourd’hui, il y a beaucoup de sites qui sont faits… Alors, les rageux vont encore s’énerver, mais il y a beaucoup de WordPress où en fait, ça ne bouge pas. Le site n’a aucune évolution. Donc, pourquoi utiliser un CMS qui est en plus en rendu serveur, c’est-à-dire à

Chaque requête, à chaque page, on reconstruit la page si c’est pour, en plus, ne pas mettre à jour ces données-là, quoi ? Ça pourrait être mille fois mieux géré et aussi bien géré par des sites statiques avec un CMS GitBase qui fait que l’interface, le client

Lui, il a son interface, il modifie une fois l’année parce que la réalité, c’est ça, il modifie deux fois dans l’année à tout péter et on déploie et tout le monde est content. Le client peut administrer ses données et nous, on ne se fâte pas une stack toute complexe

Parce que plus on rajoute de layers à la stack, plus on vient complexifier la chose et surtout introduire des sources d’erreurs. Oui, de toute façon, on est d’accord, la JAMstack, il y a plein de sites qui pourraient être faits comme ça, c’est clair et net, des sites qui ne changent quasiment jamais,

Ça coûterait moins cher à héberger, c’est beaucoup plus sécure, les sites ne changent jamais, donc ils sont posés à un endroit et ça ne bouge pas. Les avantages, comme on l’a dit, le stockage est super simple, c’est tout sur Git. C’est gratos, quoi. Oui, c’est gratos. On ne paye pas.

Les inconvénients, c’est souvent un peu plus technique. Encore aujourd’hui, les CMS, on va en parler après, mais ils ont vachement évolué. Avant le markdown, on était un peu limité pour faire des colonnes, tout ça, mais maintenant,

Tu as deux types de markdown, tu as le MDX ou le MDC pour vue, qui permet d’intégrer des components dans le markdown et donc de pouvoir faire du contenu un peu plus avancé avec des colonnes, des blocs, etc. De ce côté-là, ça a beaucoup évolué.

Moi, je suis intimement convaincu que, oui, ça nécessite une formation pour ton client, mais tu lui montres un exemple. L’exemple, c’est ça. Là, tu veux mettre ton capture d’email. Toi, tu as codé ton composant capture d’email. Tu mets 2.2.2.2.email et tu lui as expliqué une fois, il a compris que quand

Il fait ça, derrière, ça va injecter le capture d’email. Et ça, c’est quand même monstre top parce que tu vas pouvoir injecter tes propres composants dans ton markdown. Là, tu nous parles déjà de NUC Studio. Oui, alors évidemment, NUC Studio est un des CMS GitBase.

Donc, pour ceux qui font du NUXT, vous regardez ce que fait NUC Studio. Ça marche plutôt bien, mais le MDC ou le MDX, c’est quand même très, très proche. Donc, tu vas pouvoir aussi injecter ton composant React comme ça. Oui, c’est plus simple avec les deux points. Après, c’est la syntaxe.

Si tu as un client qui est plutôt à l’aise techniquement, sans être un développeur ou quoi que ce soit, mais qui est plutôt à l’aise, qui sait se débrouiller avec un fichier markdown, c’est super adapté. Ça sera plus simple pour lui. Et puis voilà.

Après, effectivement, avec un NUC Studio ou des choses comme ça, il s’en sortira largement pour une somme vraiment très réduite. Ce n’est pas cher. Beaucoup sont gratuits. Tous ne sont pas gratuits parce qu’il y en a qui sont plus ou moins open source et code propriétaire.

On va en parler sur l’open source et gratuit. Ça ne veut pas dire la même chose. Et en mode self-hosted ou en mode SaaS, où c’est eux qui gèrent l’hébergement. Mais en tout cas, il y a possibilité de trouver des CMS vraiment pas cher sur ce système-là. On les liste vite fait ?

Oui, carrément. Alors, on n’a pas toute la liste du monde entier, mais on en a listé quelques-uns. Statamix, il est un peu à part. C’est un CMS qui est hyper complet, qui est basé sur des fichiers markdown, mais qui peut faire aussi bien des sites classiques que des API.

Le truc est assez fou. Ça, ce n’est pas open source, mais il fait du reste. Il fait du GraphQL, il fait des live preview, il fait des révisions, il fait du multi-sites. Le truc est hyper complet. Je ne sais pas ce qu’il ne fait pas, en fait.

C’est assez impressionnant le nombre de fonctionnalités qui sont dispo. Alors, il n’est pas gratuit. Enfin, il y a une version gratuite, limitée évidemment. Et après, il faut payer, je crois, si je ne me trompe pas. Ou alors, c’est payé en direct.

Non, oui, mais il y a une version solo en free et une version pro. Par contre, là, je viens de voir un mot, Laravel, je ne sais pas quoi. C’est basé sur Laravel ? Oui, il est basé sur Laravel. Tout le code, c’est du Laravel.

Donc, tu peux l’étendre en faisant des… le code, tu peux l’étendre avec du Laravel, du PHP. Excellent. Et il n’y a pas de base de données. C’est vraiment du fichier markdown. Tout est dans le fichier markdown. Ok, excellent. Il n’est pas mal. C’est pas mal. Alors, regardez parce que c’est pas mal.

Par contre, ce n’est pas open source. C’est propriétaire. D’accord. Nuxt Studio, tu en as déjà parlé. Alors, adapté uniquement à Nuxt. C’est déjà pas mal. Par contre, l’interface est assez magique. Il y a beaucoup de choses pratiques. C’est un mi-chemin entre le CMS et l’éditeur de markdown. C’est un peu étrange.

Tu as d’autres complétions. Il y a la gestion des images. C’est assez intéressant quand même. Tu as le preview en direct, etc. On l’utilise un petit peu pour le site du podcast. C’est un CMS super intéressant à tester. D’ailleurs, on avait fait une vidéo. Je crois que j’avais fait une vidéo là-dessus. Absolument.

C’est ce que j’allais dire. On va aller voir la vidéo de Patrick sur Nuxt Studio. On avait DECAP CMS. Alors, DECAP CMS, c’est l’ancien Netlify CMS qui a été repris. Ok. D’accord. Il s’est changé de nom, mais c’est la même base. Donc, il a été repris puisque Netlify n’investissait plus dedans.

DECAP CMS, ça vous rajoute une interface admin dans votre site statique ou web app. Donc là, on peut éditer le contenu. Il y a un système de validation, draft, etc. C’est pas mal. On a Asfaltia CMS. Alors, celui-là, je l’ai trouvé. Le mec dit que c’est comme DECAP CMS en plus léger.

Après, je ne sais pas tester. Mais voilà. On a Keystatic. Je ne sais pas si tu le connais, celui-là. Il est très jeune. Oui, exactement. En fait, c’est un projet qui est porté par Simon, je ne sais plus comment, le Suisse. Oui, le Suisse qui habite en Australie. Exactement.

Qui habite en Australie, qui a créé toutes les vidéos de Taewin. Et en fait, il s’est mis dans ce projet-là. C’est assez récent. On se rapproche de Forestry à l’ancienne, comme quand Forestry était encore viable et utilisable. Mais voilà, on se rapproche de l’idée. Pour l’instant, c’est free. Pour l’instant, on peut l’utiliser.

Comment ça va évoluer ? Je n’en sais rien du tout. C’est un projet qui est assez jeune quand même. Oui, carrément. On a Statik CMS. Celui-là, je ne le connais pas du tout. Je n’ai trouvé aucune idée. Pas du tout. Allez voir. On a Tina CMS.

Tina CMS, c’est la société qui éditait Forestry. Qui a fermé Forestry. Voilà, Forestry a fermé. Ils ont lancé Tina CMS. A la base, il n’était pas open source. Tina CMS, sa particularité, c’est de se mettre sur votre code et de rajouter l’édition du code en live.

Vous avez votre preview et les champs à côté. Je ne sais pas si on voit une vidéo. Et en fait, ça met à jour en même temps. Ça, ce n’est pas mal comme interface pour les clients. Oui, parce qu’ils voient directement. Exactement.

Ils ont vraiment le contexte de « je tape quelque chose à gauche et à droite, je vois que sur mon site, ça bouge. » Donc, je vois tout de suite ce que ça fait. Celui-là est top. Il est devenu open source, le CMS. Ah oui. Du coup, la société offre un service cloud.

Ils vont te l’héberger, etc. Il y a des trucs en plus par rapport au basique. Ils sont revenus à la même solution que Forestry, j’ai l’impression. Ok. Bon. Mais maintenant, ça s’appelle Tina. Oui, Tina. L’interface, le code, tout ça, ça n’a rien à voir. Je veux dire le même business model.

Normalement, à la base, ils étaient partis là-dessus pour changer le business model de Forestry. Puis finalement, j’ai l’impression que c’est revenu à peu près dans le même truc. C’est à peu près le même dollar la version Tina. Ok. Celui-là, pas mal. Ça, c’est bien. Et petit dernier, il y a ma CMS.

Alors, celui-là, moi, perso, je ne sais pas trop. Je n’ai jamais vu l’interface, quoi que ce soit. Donc, juste on en parle parce que c’est français, que ça vient de Chambéry. Exactement. Et en fait, on se devait, étant tous les deux Savoyards, on se devait de promouvoir le petit poulain local.

Et donc, ils se mettent sur ce créneau-là justement du CMS statique pour pouvoir administrer tout son contenu pour les sites statiques. Et c’est fait en Savoie. Donc, petit clin d’œil Savoyards de double slash normal. Yes. Voilà pour les GitBase. Donc, on passe à la suite ? Allez, on passe à la suite.

Il y a un autre type de CMS qu’on va facilement trouver. Est-ce qu’on… Alors, avant de partir sur les CMS qui sont en SaaS ou en self-hosted, on voudrait faire un petit warning, faire attention, on voit de plus en plus de projets et de mise en place de CMS

Qui sont basés sur les BaaS. Alors, les BaaS, c’est les Backend as a Service. On avait déjà fait un épisode là-dessus. Mais un Backend as a Service, c’est clairement une solution cloud qui va nous permettre de simplifier et de créer une infrastructure backend très, très rapidement.

Donc, ça, c’est super bien parce qu’on va avoir la base de données, l’API, la couche de sécurité, tout… On va dire le login, password. Donc, ça, ça va être super pratique. Sauf que ce n’est pas du tout, du tout optimisé pour le client final.

Donc, si on utilise ça, en fait, pour administrer du contenu, on va au-devant de grave déconvenu. Tout à fait. Et en fait, il faut bien comprendre que ce n’est pas du tout la même chose parce qu’en fait, je pense, on entend beaucoup parler de Asura ou de Firebase, de Supabase, tout ça.

OK, très bien. Ce sont des super outils. Par contre, ce n’est pas fait pour administrer du contenu parce que ça veut dire que là, vous allez être obligé, en fait, de développer une interface pour administrer ce contenu par vos clients ou alors vous donner directement accès aux sources, à la source.

Et donc, votre client, il a accès admin. Il a un accès admin et il est sur l’accès admin de Supabase et il injecte tout dedans. Ça me paraît très dangereux et très risqué. Oui, non, ce n’est pas du tout adapté pour des entreprises, pour des clients, etc.

À la limite, le dev, tu vois, tu as un dev, il va aller dessus, il va changer son contenu, tout ça, c’est son site à lui. À la limite, il sait ce qu’il fait, mais ne jamais donner ça à un client. Vas-y, tu te connectes, tu changes le contenu.

C’est un accès direct à la base et c’est hyper dangereux. C’est super, super dangereux. Par contre, oui, ça vient nous faciliter la vie grandement parce que clairement, on crée nos tables, on crée nos champs, on a l’API qui est faite automatiquement, on vient en trois clics,

On a mis est-ce que lui, il a le droit, est-ce que lui, il n’a pas le droit, tout. Super, sauf que clairement, le client, il n’a pas d’interface. Donc, il ne voit strictement rien. Et donc, ça, ce n’est pas tout à fait la même chose. Oui, donc attention à ça.

Oui, gros warning, les basses ne sont pas des CMS. Non, ce ne sont pas des CMS. Néanmoins, on peut juste en lister très vite, très rapidement. Je pense à PocketBase qui est tout petit, qui est fait en Go. Alors, vous n’avez pas besoin d’être développeur Go pour utiliser ça.

On met le binaire sur le fichier, on lance et ça fait tout tout seul. Ça fait beaucoup de choses. C’est vraiment hyper rapide et il y a plein de hooks sympas. C’est full customisable et on peut même injecter du code custom Javascript alors que PocketBase est écrit en Go.

Donc, les hooks sont faits soit en Go, soit en Javascript, ce qui est plutôt sympa. Je pense à Asura. Pareil, on avait déjà fait un épisode là-dessus où on va vraiment injecter la base de données. Ça va nous créer une interface. On l’a dit, Soupabase avec, on va dire,

Toute la panelle de fonctionnalités qu’ils ont développé tout autour de la base de données, du storage et tout ça. Et on va dire, historiquement, un des premiers back-end à the service qui existait, c’était Firebase. Firebase qui a été racheté par Google. Et donc, clairement, c’est lui, historiquement,

Le maître du back-end à the service. Yes, yes, yes. Ok, on va passer au SaaS maintenant, les offres SaaS. Ça, c’est un peu différent. C’est l’avantage des offres SaaS. Comment ça fonctionne déjà ? On va commencer par le fonctionnement. En fait, c’est un CMS qui est disponible la plupart du temps en ligne.

Vous vous connectez avec un navigateur web, vous accédez à l’interface, et ensuite, il y a des API, il y a des librairies qui sont disponibles. Vous vous connectez, votre web app, vous la connectez au SaaS, vous récupérez les datas, vous les affichez, etc.

Par contre, vous n’avez pas du tout accès au code, la plupart du temps. Vous n’avez accès même pas à la base de données, rien du tout. Tout est vraiment accessible que par l’interface. Par contre, l’avantage, c’est que vous n’avez pas à gérer d’hébergement, vous n’avez pas à gérer de serveur, etc.

Tout ça, c’est géré par le service. Voilà. Et pour le coup, ça, ça pourrait convenir plutôt à quel type de projet ? Alors, ça convient à tous les types de projets, évidemment, du plus petit au plus gros. Par contre, l’inconvénient, c’est que la plupart du temps, c’est pas gratuit.

Il y a souvent des offres gratuites, mais suivant le besoin, on se retrouve vite à passer sur une offre payante. Donc après, on se retrouve un petit peu… L’inconvénient de ce système-là, c’est qu’on se retrouve un petit peu bloqué par le CMS.

Une fois qu’on a commencé à rentrer le contenu, qu’on a tout connecté, etc., c’est vrai qu’on est quand même dépendant du CMS. Si jamais le CMS augmente les tarifs, on est un peu coincé, on est obligé de suivre l’augmentation. Alors, pour le coup, là, je peux faire un retour là-dessus,

Où moi, j’ai implanté ou implémenté, je ne sais pas d’ailleurs, d’Ato CMS il y a 4-5 ans sur des projets où le ticket d’entrée était à 9 euros. Donc, un seul utilisateur, 9 euros, très bien, ça passe. Et aujourd’hui, en fait, 5 ans plus tard, ils ont revu leur pricing,

Ils ont changé de politique et tout, et le premier niveau d’entrée est à 99 euros. Et donc, c’est super difficile, parce qu’en fait, après, ça s’explique aux clients. On leur explique que le système qu’on a choisi a changé les tarifs,

Et donc, il va prendre, soit il paye les 99 euros, mais on ne fait rien, soit on fait une migration, mais qui dit migration, dit du dev. Et donc, le dev, il va falloir le payer. Et donc, ça passe plutôt mal, en fait. C’est difficilement acceptable pour le client.

Il le comprend, mais ça le fait chier. Mais il y a juste le titre. Donc, je pense que sur des SaaS CMS un peu récents, qui ont des tarifs très avantageux, attention, attention. Parce que, clairement, ils vont grossir, ils vont faire des levées de fonds,

Et le board va dire, ok, maintenant, ça marche. Le client est captif, ils le savent bien, donc ils peuvent monter facilement les tarots, et ils savent très bien qu’une migration de CMS, une fois que la boîte a mis, je ne sais pas combien d’heures, de temps, d’énergie, de contenu sur ce service-là,

Ben, ça va être dur de bouger, quoi. Donc, on est complètement captif, et on est à la merci d’une augmentation de tarif. Et donc, c’est un point qui est vraiment à garder en tête sur ce type de CMS en SaaS, clairement. Oui, tout à fait.

De toute façon, pour une société qui se lance avec un CMS SaaS, leur premier objectif, c’est de gagner des utilisateurs. Donc, ils vont faire un tarif attractif pour que les utilisateurs viennent, et que le CMS devienne important. Et c’est sûr qu’à un moment donné, quand ils auront assez d’utilisateurs,

Et effectivement, quand ils auront cramé toutes les levées de fonds, il va falloir qu’ils gagnent de l’argent, et donc là, les tarifs, obligatoirement, vont augmenter. Donc, comme tu dis, c’est vraiment attention à ça. Quand l’offre est trop attractive, c’est peut-être qu’à un moment donné, ça va coincer.

Ou alors, en fait, ils ont peut-être des offres attractives sur des fonctionnalités, mais en fait, bien comprendre le niveau de maturité du SaaS, en fait. C’est surtout ça. C’est la boîte, à quel niveau de maturité elle est ? Est-ce qu’elle en est encore au balbutiement ?

Est-ce qu’elle est en train d’acquérir un maximum d’utilisateurs ? Ou c’est une boîte qui est super établie, et donc, dans ce cas-là, la grille tarifaire va beaucoup moins bouger, quoi. Mais souvent, en fait, on se rend compte que les SaaS qui sont déjà très, très bien établis ont des pricing assez forts,

Assez élevés avec des tickets d’entrée qui sont difficilement à moins de 100 balles, quoi. Oui, carrément. Alors, les avantages, ça, c’est vraiment l’inconvénient, le prix, attention à ça. Les avantages, par contre, le service est utilisable en quelques clics, en quelques heures, en fait. Vous créez votre espace, en gros, dans le CMS,

Puisque c’est souvent comme ça, dashboard, etc. Et vous pouvez de suite travailler, en fait, connecter les API, tout ça. Il n’y a pas de mise à jour à faire, tout ça. Tout est géré par le SaaS, en fait. Il n’y a pas de gestion de serveur. Ça, c’est un grand avantage.

Oui, mais par définition, si on paye le service, on ne doit pas l’héberger. Et donc, on n’a pas à gérer ça. Et ce qu’il faut bien comprendre, en fait, c’est que pour une entreprise, en fait, souvent, même si on peut trouver en tant que dev que 100 dollars par mois, c’est élevé,

Ce n’est pas si élevé que ça, contrairement à un salaire d’un employé qui va devoir avoir un développeur en interne dans l’entreprise, etc. Donc, ça peut être très intéressant, en fait, au niveau du coût, de plutôt prendre un CMS SaaS que d’avoir des développeurs en interne.

Et puis, il y a aussi des sociétés qui ne veulent pas gérer les serveurs. Moi, j’ai des clients qui ne veulent pas gérer les serveurs. Ils n’ont plus envie de s’embêter avec ça. C’est plutôt dans l’ère du temps où, en mode, nous, on met la carte bleue, mais on veut que ça marche.

Et ce qui rejoint aussi un autre point, un gros avantage aussi, c’est l’auto scaling, c’est-à-dire que je n’ai pas à gérer ma montée en charge. On connaît tous l’effet télé, où, justement, le bon site qui est hébergé sur un mutualisé, info télé, tout le monde se connecte sur le site.

Le site, le serveur étant complètement en PLS, bon, ben, ça n’a pas tenu la charge. On a transformé un buzz en bad buzz, donc c’est bête. Avec ces services-là, justement, ça vient automatiser. C’est eux qui sont garants de cette montée en charge,

De ce auto scaling, aussi bien à la montée que à la descente. Donc, nous, on n’a pas à gérer ça. Oui, carrément. Oui, ça, c’est pas mal. Parce que souvent, on a souvent une web app en front, on se dit, c’est bon, c’est du Node, ça tourne nickel. Mais attention, n’oubliez pas l’API.

Il faut que l’API réponde quand il y a beaucoup de visites. Donc, il faut faire attention à ça. Bon, inconvénients, j’ai marqué quelques inconvénients aussi, en autre chose que le prix. C’est vrai que ça coûte certain très exclusif. Ça me fait penser à Contentful, qui a des tarifs assez élevés.

C’est un des exemples. Mais c’est aussi celui qui est le plus présent, et le plus, je pense, la valeur sûre des SaaS. On a parfois certains SaaS, après, ça peut être aussi avec les solutions Self Hosted, mais on a des couplages assez forts au niveau du code entre le CMS et l’application.

C’est-à-dire qu’ils ont des librairies disponibles pour se connecter au CMS, où il y a un gros mélange de codes un peu spécifiques dans votre application. Ils ont fait leur propre SDK. Oui, comme les slides, par exemple, pour Prismic, je pense à ça aussi. C’est très, très couplé avec le CMS.

Et du coup, attention, parce que ça sera difficile d’en sortir. Eh oui, parce que plus le couplage est élevé, plus tu restes un peu captif du CMS. Parce qu’une fois de plus, on revient, plus tu as investi sur la boîte et tu as mis des fonctionnalités qui sont spécifiques que à ce CMS-là.

Oui, mais parce que tu utilises leur SDK, leur librairie. Après, je ne sais pas, je vais sans doute me faire insulter quand je vais dire ça, mais pour moi, un CMS headless, c’est une API, point. Ce qui fait que tu n’as pas un couplage très fort avec ton SDK.

Ou alors, il faut que tu aies un SDK dans tout. Si toi, tu as envie de faire ton petit site en Go, tu peux le faire. Si tu veux l’intégrer sur du Ruby on Rails, en fait, ce n’est pas gênant. Si tu commences à imbriquer un peu les deux,

Avoir leur propre SDK pour lire les données de chez eux, là, tu as un couplage qui est très fort et on revient sur ce que tu disais tout à l’heure. Dangereux. Difficile de sortir. Pour moi, je suis un peu comme toi. Pour moi, un CMS, c’est une API GraphQL

Ou un truc comme ça où tu vas taper dedans, tu récupères les infos et tu les affiches. Après, quand tu commences à avoir le code mélangé, ça devient… Disons que la question, au moment, si jamais les prix augmentent très fortement et que tu veux partir du CMS,

Si en plus il faut réécrire toute l’application, ça devient compliqué. Non, c’est compliqué. Après, je ne sais pas si les datas, s’il y a une notion où les datas appartiennent à la société ou les datas t’appartiennent. Je ne sais pas en termes de législation, comment ça s’organise.

Je ne sais pas, il faudrait voir les petites lignes. Oui, il faut lire les petites lignes. Après, je pense que les données, tout. Et vu aussi, je ne sais pas si les bases de données sont partitionnées et segmentées, on va dire tenantes. Si il y a du multi-tenantes,

Pour être sûr que la base de données, si la base de données, par exemple de Prismic ou de Contentful se fait corrompre, est-ce que c’est tous les utilisateurs ou c’est qu’un site ? Ce serait intéressant d’aller voir aussi comment ils structurent tout ça. Souvent, c’est de l’Amazon derrière, de l’AWS. Enfin, je pense.

À la fin, ça va tout chez Amazon, de toute façon. À la fin, c’est tout chez Amazon. À la fin, on le sait, c’est toujours chez Amazon. On est d’accord. Par contre, il y a quand même des trucs qui sont plutôt intéressants. C’est que souvent, tous ces systèmes de SaaS,

En fait, comme on l’a déjà dit, vont gérer les images, souvent, ils vont gérer le multilingue, ils vont gérer les rôles. En fait, ils sont quand même assez fournis en termes de fonctionnalités. Oui, la plupart du temps, tout est disponible. Après, c’est payant, plus ou moins payant.

Si tu as besoin de telle ou telle fonctionnalité, c’est souvent de plus en plus par utilisateur. Ça peut vite venir faire du fléau de la note. Très cher. Oui, très cher si tu as beaucoup d’utilisateurs dans ton entreprise qui se connaissent, etc. Ils sont tous passés sur ce modèle-là

Par site ou par utilisateur. Après, il faut décortiquer les tarifs. Oui, c’est comme tout. Mais je pense que le tarif est aussi un élément à prendre en compte dans son choix de service. Combien ça va nous coûter. Clairement. On regarde vite fait la liste. Tu as déjà évoqué Prismic, acteur français. Tarif raisonnable.

Ils ont augmenté il n’y a pas longtemps, mais tarif quand même assez raisonnable pour l’offre. Ils ont tout un système de slice, etc. qui permet de faire des blocs, d’afficher des blocs, etc. C’est assez poussé. L’interface n’est pas mal. C’est vraiment bon CMS, j’ai envie de dire. Qui existe depuis quelques années maintenant,

Donc valeur sûre. Pas mal. Contentful, le plus connu. Tu l’as déjà utilisé ? Non, j’avais fait un test dessus. Et je ne sais plus pour quelle fonctionnalité. Il fallait que je passe en payant. Et clairement, c’était surdimensionné par rapport à mon projet. C’était une usine à gaz.

C’était beaucoup trop gros pour mon projet. J’étais passé sur Forestry pour te dire le gap. Mais c’était intéressant de tester. Par contre, depuis, je n’ai pas retesté, je n’ai pas rejoué avec. Et là, je constate que l’offre free offre déjà cinq utilisateurs de local.

Donc, il y a déjà beaucoup de choses à prendre en compte. Donc, ça peut être intéressant. Dato CMS, tu connais donc celui-là. Oui, je connais. En fait, je me suis confronté au pricing. Ils ont baissé, je crois. Il y a une offre free maintenant. Non, ils sont passés à 149 dollars.

Donc non, ils n’ont pas baissé. Ils n’ont pas baissé. Non, ils n’ont pas baissé. Par contre, moi, j’ai l’avantage, c’est que j’ai un historique chez eux. Et donc, en fait, j’ai un compte qui s’appelle Legacy V2, V3, V4. Je n’en sais rien du tout. Mais pour les deux petits projets que j’utilise,

Je suis dans leur pricing Legacy. Et voilà. Bon, après, on s’est fait avoir avec les API, le nombre de requêtes API qu’on peut taper par mois et tout ça. Donc, ouais, on avait mal géré notre truc entre le site actuel et le site de développement

Qui était en fait basé sur le même CMS. Et bien, on a explosé les API et tout. Ça s’est géré, mais un point aussi intéressant et qu’on n’a pas évoqué tout à l’heure, c’est justement certains pricing sur du SaaS, en fait, vont te mettre des limites sur ton nombre d’appels API par mois.

Et donc, c’est un truc qu’il faut prendre en compte aussi. Est-ce que tu vas avoir du trafic et comment tu as codé ton site pour éviter d’avoir 20 000 requêtes qui ne servent à rien? Est-ce que tu as mis du cash? Voilà, en tout cas, c’est des contraintes qu’on découvre.

Bon, nous, on a découvert un peu en mode Hardway, vraiment de la manière un peu violente. Mais voilà, on a découvert qu’il y avait une API avec un rate limit. C’est intéressant à connaître. Builder.io, celui-là, c’est le CMS qui offre une interface hyper visuelle,

Un peu à la Webflow, un peu, où on va glisser les choses dedans, etc. Donc, c’est assez avancé, très drag and drop. Donc, on aime ou on n’aime pas. En tout cas, ils ont sorti des super frameworks à côté. Donc, le fameux Quick, le framework JavaScript, qui est pas mal.

Ils innovent beaucoup au niveau du code, tout ça. Après, moi, j’avais testé, j’avais pas super… Enfin, moi, j’adhère pas des masses sur ce type de choses de drag and drop. Mais après, c’est peut-être mon côté d’élève. Après, peut-être ça… Après, force est de constater qu’ils ont une intégration avec quasiment tous les frameworks,

Du Vue, du React, du Next, du Nuxt, du Quick, évidemment. Et de la même manière, ils vont aussi intégrer toutes les sources de données. Donc, un Shopify, un Claudinary, un BigCommerce, un Salesforce. Donc, en fait, toute la source de données va être hyper variée.

Et en fait, c’est un peu comme si on mettait une surcouche, en fait, pour administrer de manière très visuelle tout le contenu. Donc, c’est quand même assez intéressant. Par contre… Ouais, mais il est vraiment pas mal. Alors, comme ils disent, c’est un mix entre le code et le no code, en fait.

C’est assez déroutant. T’as une interface à la Webflow, mais en même temps, tu codes. C’est assez déroutant, mais… Non, mais ça a testé parce que c’est très avancé quand même, comme interface. OK. Et par contre, moi, le gros avantage que je vois, c’est le côté visuel.

C’est qu’aujourd’hui, force est de constater que les clients veulent voir en live. Et c’est une fonctionnalité qui fait son chemin. Yes. Et toujours dans le même délire de visuel, on a Storyblock qui fait beaucoup de marketing en ce moment. Ils ont embauché des vrais, etc. Enfin, ils font beaucoup de conférences.

Très actifs depuis quelques mois. OK. CMS, pareil, visuel avec des blogs, tout ça. Les tarifs, ça pique un peu. Ils ont augmenté les tarifs aussi. Ils ont un système de communauté qui, pour le coup, est gratuit avec un utilisateur. Oui. Et 9 euros le deuxième utilisateur.

Donc, ce qui veut dire un siège pour le dev et un siège pour le client. Ça fait une porte d’entrée à 9 euros. C’est correct, quoi. C’est très correct. Oui, oui, ça va. C’est correct. Non, non, après, c’est pas… C’est pas… C’est pas gagné de l’argent, de toute façon.

Ben, oui, oui, complet, complet, complet. On déroule. On va passer vite fait à les autres. Oui. On va dérouler. Plasmique, je ne connais pas du tout. Moi non plus. J’ai trouvé ce truc. Butter CMS. Butter CMS, qui est vieux aussi celui-là, il me semble. Celui-là, il existe depuis un moment, je crois. OK.

Je n’ai jamais entendu parler. Oui, après, il y en a vraiment beaucoup sur le marché. Agility, Content.ai, Apito, j’ai trouvé celui-là aussi, qui fait… Il est assez récent, celui-là. Il a une version community qui est en bêta encore, mais qui n’est pas encore disponible. Et puis, Sanity, Sanity Studio.

Alors, celui-là, c’est assez particulier. Sanity Studio, il est open source. Mais par contre, ce n’est que eux qui peuvent l’héberger, d’après ce que j’ai compris. Je ne sais pas si on peut l’héberger, nous. Ah, non, pardon. J’ai dit une connerie. J’ai vu la doc, on peut l’auto-héberger.

Donc, Sanity qui a l’air pas mal, apparemment. Il y a pas mal de gens qui en sont contents. Moi, j’avais regardé, et en fait, ils avaient une méthode de requêtage pour aller requêter leurs données. En fait, c’est une sorte de GraphQL, mais un peu spécifique à eux.

Donc, c’est un query language qu’ils appellent, ouais, croc, c’est ça, là. Croc. Et donc, query language, je ne sais pas quoi. Et j’avoue, je n’avais pas réussi à accrocher tout de suite. Et en fait, c’était super frustrant parce que je ne pouvais pas récupérer la donnée tout de suite.

Et en fait, j’étais obligé d’apprendre leur langage de requêtage des données. Et moi, ça m’avait saoulé, quoi. Et donc, j’étais passé à autre chose. Et là, je viens de voir que je vois GraphQL. Ah, oui. Donc, peut-être qu’ils ont ouvert le côté GraphQL. Et donc, tout de suite, c’est beaucoup plus simple.

Parce que pour ceux qui ne savent pas, j’aime beaucoup GraphQL et je ne fais que ça. Mais c’est pour ceux qui ne savent pas. Sanity, c’est plutôt l’infrastructure qui vend plutôt que l’interface CMS. Il faut aller fouiller un petit peu dans la doc. C’est un business model spécifique.

Oui, c’est un truc, voilà, composable content cloud. C’est leur modèle qu’ils vendent, en fait. En fait, ce n’est pas le CMS qui est forcément mis en avant, c’est tout ce système de content cloud. Yes. Ok. Voilà, intéressant. Ça marche.

Alors, après, dans ces SaaS, en fait, il y a des offres qui sont un petit peu différentes. Ça s’appelle des offres cloud. En gros, il y a des outils qui sont open source comme Strapi, Directus ou Payload, qu’on peut auto-héberger, ce qu’on verra après.

Par contre, les sociétés qui éditent ces logiciels open source avaient besoin de trouver des business models. Et donc, le business model, c’est d’offrir un hébergement pour leurs solutions open source. Donc, Strapi s’est lancé là-dedans, Directus, que tu connais bien, pareil, offre une offre cloud. Et donc, qu’est-ce que ça apporte ?

En fait, c’est qu’on utilise le CMS open source, mais qui est hébergé chez eux. Ils s’occupent de l’hébergement, ils s’occupent de l’auto-scaling, etc., tout ce qu’on retrouve dans le SaaS, mais sur un outil open source. Et du coup, on paye, par exemple, pour Strapi et Directus, c’est 99$.

Pour Payload, c’est 35$ et 199$. Donc, ça reste des tarifs assez intéressants, 99$ pour un hébergement de haute qualité, quand même. Strapi dit ça, Strapi dit que c’est un très bon hébergement avec toute la gestion des images, etc. Donc, c’est un petit peu différent, c’est entre le SaaS et le self-hosted, en fait.

On a un outil open source qui est hébergé par un tiers. Excellent. Et ce qui nous amène à la troisième, on va dire, le troisième type de CMS pur, qui sont en fait les CMS self-hosted, donc qu’on va héberger nous-mêmes. Donc là, on doit gérer le serveur.

Par contre, souvent, on a beaucoup plus de largesse dans ces solutions-là. Et donc, clairement, quel est le fonctionnement de ces systèmes-là, de ces CMS self-hosted ? Tu fais tout toi-même. Donc déjà, il faut être dev. Il faut avoir des compétences techniques, ne serait-ce que pour l’installer sur l’hébergement, le faire fonctionner, etc.

Et puis, tu es responsable de tout ce que tu dois, de l’installation, des mises à jour, de la sécurité, de ne pas faire n’importe quoi, de la maintenance, de choisir un hébergement qui tient la charge, etc. Donc, tu es seul, en gros. Tu as un CMS et tu es seul à le gérer.

Donc, tu dois gérer ton hébergement, tes images, le connecter à Westroa, etc. Donc, ce n’est pas réservé à tout le monde. C’est réservé surtout à des personnes techniques, des entreprises qui ont des personnes en interne qui sont techniques, des développeurs, tout ça.

Donc, déjà, le point d’entrée, c’est d’avoir déjà des personnes compétentes dans le système d’hébergement, savoir héberger, développer, enfin, déployer du node, etc. Par contre, on est d’accord que tous ces CMS self-hosted, en fait, on va prendre du code, mais on ne va pas recoder nous-mêmes ce CMS-là.

On va utiliser des CMS qui sont soit open source, soit propriétaires, mais qui n’offrent pas cette capacité d’hébergement, mais le code source, en fait, on le récupère quelque part. On est bien d’accord. Oui, la plupart, ils sont open source.

Donc, ils sont la plupart disponibles sur GitHub avec la documentation qui t’explique comment héberger, qu’est-ce qu’il faut au minimum comme base de données, tout ça. Mais oui, la plupart, c’est du code que tu récupères, que tu vas installer.

Alors, l’avantage, c’est que tu n’as pas à coder tout un CMS puisque c’est un CMS qui est déjà disponible. Donc, la mise en place, c’est super rapide parce que pour ceux qui ont déjà fait un CMS pour un site d’un client, c’est hyper long. Il faut tout refaire, les utilisateurs, etc.

Là, c’est tout disponible, en fait. Si tu prends Strapi, par exemple, tu peux l’installer, aller en gros en une demi-heure, une heure, tu l’installes sur un hébergement et puis tu te connectes et puis direct, tu peux commencer à créer du contenu, etc.

Donc, ce n’est pas aussi rapide que ça, mais ça peut aller assez vite quand même. Après, si toi, tu es à l’aise avec les serveurs où tu as des ressources, on va dire dans l’agence où la boîte a des ressources et ils savent gérer ça,

Pour le coup, c’est quand même une bonne solution parce que tu ne payes pas, le code n’est pas propriétaire. Donc, le code évolue parce qu’il y a une communauté derrière, il y a une boîte derrière aussi qui porte le projet. Donc, ça peut être quand même un bon compromis.

Oui, le CMS, tu peux le faire évoluer parce que souvent, alors je vais prendre Strapi parce que je le connais bien, toi, tu connais bien DirectXus, mais Strapi, tu as tout un système de hooks, etc. Donc, tu peux coder directement des hooks.

Quand un article est créé, il fait ci, il fait ça, etc. Tu peux le faire évoluer. Avantage par rapport au SaaS, il n’y a pas de changement de prix. A part si ton hébergement augmente, ton tarif, mais ton CMS, il ne changera pas de prix.

Il est chez toi, tu fais ce que tu veux. Les datas, elles sont chez toi aussi. On en parlait tout à l’heure dans le SaaS, les datas, à qui elles sont, là au moins, c’est chez toi. C’est ta base de données, tout est chez toi, tu peux exporter, récupérer,

Faire des backups, tout ce que tu veux. Donc, tu es vraiment libre de faire ce que tu veux. L’inconvénient, c’est que tu dois tout gérer toi-même. Après, sur ce type de CMS, il y a quand même deux possibilités. C’est soit du code où là, on fait un fork,

Où on va faire un git clone du projet. Et donc, dans ce cas-là, on repart de base propre. Et donc, on peut aussi customiser le code facilement. Par contre, on a une autre solution qui est encore plus rapide à mettre en place. C’est de récupérer l’image souvent Docker ou d’une image déjà construite.

Où là, en fait, on va instancier la machine avec directement la version du CMS. Par contre, si on déploie avec une image Docker, on va perdre tout le côté custom qu’on pourrait amener sur du code que nous-mêmes, on vient self-hoster. Là, si c’est nous qui poussons notre code,

On va avoir plus de granulométrie et beaucoup plus de contrôle sur le résultat que sur une image Docker. Où là, pour le coup, on prend la version 2, la version 4, la version 10. On déploie, on passe à la version 11, on déploie la version 11 et basta.

Mais on aura moins cette granulométrie. Mais on a quand même ces deux possibilités de soit récupérer le code du projet, d’instancier, soit de récupérer l’image préconstruite via un Docker. Oui, souvent, ça dépend si tu as besoin de personnaliser ou pas. Si tu as juste besoin de l’utiliser tel quel, pas besoin de s’embêter.

C’est souvent plus simple. Avec une image Docker, je pense que tu peux aussi modifier, garder juste le Dockerfile. Après, ça dépend, le besoin. Strapi, celui-là, je le connais bien parce que je l’ai utilisé pour des clients. C’est français, ça a été lancé par des français.

On en a reçu Jim il y a quelques temps dans le podcast. Il nous avait parlé de l’offre. À l’époque, c’est marrant parce que juste avant, je parlais de l’offre cloud. Au moment où on l’avait reçu dans le podcast, ils n’avaient pas encore d’offre cloud. J’avais évoqué cette possibilité.

J’ai demandé pourquoi ils ne faisaient pas d’offre cloud. Je ne sais pas si c’est moi qui les a inspirés. Je ne vais pas me jeter des fleurs. Entre-temps, quelques mois après, ils ont lancé l’offre cloud. Je ne sais pas trop d’où ça vient l’idée.

En tout cas, je trouve que c’est pas mal cette offre d’hébergement avec un système open source. Sinon, Strapi, pour en parler vite fait, c’est un système où tu crées tes champs directement dans l’interface de Strapi. Tu peux aussi le faire au niveau du code.

Comme on voit dans les vidéos, tu crées tes champs, tu crées des posts par exemple. Tu vas mettre un titre, un contenu, etc. Au fur et à mesure, il va se sauver dans le code. Il va générer le code. Ce n’est pas sauver en bas, c’est vraiment sauver dans le code.

Après, tu remplis ton contenu, etc. Il est pas mal. Il y a des plugins qu’on peut rajouter. Il fait du GraphQL, il fait du reste. Super CMS, open source. Tu n’as pas quoi dire de plus ? Français. Et français en plus. Yes. Directus, tu peux en parler ? Autre solution, Directus.

Oui, je peux en parler. Je trouve que c’est bien plus qu’un CMS. Les versions antérieures étaient vraiment cantonnées au CMS. Là, on va avoir beaucoup plus que ça. Parce qu’on va pouvoir créer des dashboards avec des appels API. On va pouvoir déclencher des triggers ou des appels spécifiques à tel update.

On va avoir de l’automatisation, du data reporting. On va pouvoir créer nos propres dashboards. Un exemple typique, j’ai créé un dashboard pour que la cliente puisse voir directement son compte Stripe. Toutes les interactions Stripe de flux d’argent. J’ai un nouveau client.

Sur son dashboard, elle a le nombre d’utilisateurs qui se sont connectés sur la semaine. Le nombre de nouveaux utilisateurs. Tu vas pouvoir créer des dashboards en plus de gérer ton contenu. C’est au sein du même outil. C’est hyper confortable.

Autre point que j’aime beaucoup chez Directus, c’est que leur base de données est hyper clean. C’est vraiment super clean. Quand tu exportes la donnée, tu as accès à la base de données. Tu vois l’information et elle est stockée la plus pure possible. Ça m’avait choqué.

Tu peux récupérer ces données et en faire autre chose. Je trouve ça super bien. C’est un couplage super léger. Il y a très peu de couplage. Il peut être réimporté dans un autre CMS sans trop de travail. Exactement. Donc, tu as un très faible couplage.

Tu peux gérer aussi toute la partie utilisateur directement dessus avec des droits limités. Tes utilisateurs de ton API ou de ton applicatif ont des droits que limités. Mais tu les intègres aussi là-dedans. Franchement, c’est vraiment super. Donc, eux, ils le vendent aussi comme CMS, mais comme Backend as a Service.

Donc, comme possibilité aussi de gérer ça. Et pour le coup, c’est une solution bien plus puissante qu’un simple CMS. Il y a beaucoup plus de fonctionnalités tout autour. Et pareil, API, REST, GraphQL, ils ont leurs petits SDK. Donc, pour le coup, c’est pas mal. Tu peux faire beaucoup d’automatisation et créer des dashboards.

Enfin, je suis assez fan. Super fan. C’est intéressant. En directus, c’est marrant parce que je ne sais pas si on en avait déjà parlé, je crois. Mais en fait, les premières versions de directus, c’était en PHP. Et à un moment donné, ils ont fait un virage complet. Ah ouais ?

Je ne savais pas du tout ça. Et du coup, l’évolution est super positive. Le CMS a super évolué. Et je ne sais pas si tu es au courant, mais Alexandre Chopin est maintenant chez Directus. Je le sais, ouais. Il est directeur des ingénieurs.

Donc, il y aura sans doute un couplage assez fort avec Nuxt. Alexandre Chopin, pour ceux qui ne savent pas, c’est le frère de Sébastien Chopin. Et c’est les deux frères qui ont lancé Nuxt. Et donc maintenant, Alexandre Chopin est parti travailler chez Directus. Excellent. Super CMS. On a Keystone 6.

Alors, on en a parlé en début d’épisode, le GitBase. C’est la même agence, si je ne me trompe pas, Thinkmill, qui est australien aussi, qui avait lancé CMS. Ah, je savais. Je n’avais pas fait gaffe sur le rapprochement. Eh oui, c’est les deux. D’accord.

Donc, ils ont deux CMS, l’agence quand même très productive. Alors, ce CMS, il est assez particulier. C’est qu’il est basé sur les schemas, je crois, sur les fichiers. Tu définis tes champs, etc. dans des fichiers, ta base de données. Après, il va te générer l’admin. Tout est schéma. Oui, exactement. Je m’en rappelle.

J’avais testé en version 5. Et en fait, quand ils sont passés à la 6, ils ont changé plein de choses. Et en fait, j’étais un peu dégoûté. Je m’en rappelle. Et je n’avais pas poussé le truc. Non, ok. Je m’en rappelle de ça. Pas mal. Oui, pas mal.

Et je pense que la 6 est bien plus mature et bien plus propre. Et je m’en rappelle de ce projet, le gros problème était la documentation à l’époque. Moi, je ne trouvais pas très clair. Il y avait plein d’infos que je ne trouvais pas.

Et je pense qu’aujourd’hui, comme bon nombre de projets encore plus open source, la doc est complètement clé. Donc, elle est bien plus complète. Elle est bien faite. Elle est claire. C’est primordial de toute façon. Oui. Ok. Craft CMS. Craft CMS, c’est un CMS que je connais très bien, qui est peu connu.

Très peu connu. C’est du PHP. Par contre, alors, il n’est pas open source. Il est propriétaire. Il est payant pour avoir GraphQL, tout ça. Mais par contre, d’origine, quand vous avez la version payante pro, il y a du GraphQL. Tu crées tes champs, etc. Comme tu veux, en fait.

C’est totalement modulaire au niveau des champs, tout ça, des images, etc. Il y a une très bonne gestion des images, etc. Ça resale les images, etc. Donc, le CMS est très avancé pour le contenu. Donc, comme j’ai dit, GraphQL, gestion des utilisateurs.

Il y a un mode preview qui marche avec tout ce qui est WebApp, Nuxt, etc. J’en ai déjà fait. Excellent. Donc, CMS super intéressant qu’on peut étendre aussi avec un système de modules et tout. Alors, tu dois le self-hoster, mais combien il est payant ? Est-ce qu’il est payant ?

À combien il est ? La version pro, c’est la seule qui… Enfin, si tu veux du GraphQL avec tout ça, avec tout le système de preview, etc., c’est la version pro. Et c’est 299 dollars par projet. Donc, tu payes une fois 300 dollars. Terminé. Et c’est multi-site, multi-utilisateur.

Des gestions des accès, des droits, GraphQL. Enfin, j’ai déjà dit, gestion des images, etc. Il est super avancé et il est vraiment pas mal. Et il est très peu connu, mais ça marche très bien. J’en ai pas mal qui marchent. Enfin, j’ai des clients qui tournent avec ça. Et c’est intéressant.

Facile à héberger en plus du PHP. Et c’est quoi ça ? C’est un petit… J’étais obligé de le mettre. [Rires] J’étais obligé de le mettre. On parle de WordPress, évidemment. Voilà. Evidemment. OK. WordPress est utilisable en headless, évidemment, via quelques modifications, puisque de base, il n’est pas forcément disponible.

Enfin, WordPress fonctionne principalement via les plugins. C’est son mode de fonctionnement, en fait. Toutes les fonctionnalités sont dans des plugins. Donc, en modifiant le code, etc., en utilisant les bons plugins, on arrive à avoir un WordPress headless avec du GraphQL, avec des authentifications, avec des tokens, etc.

Donc, il y a pas mal de plugins qui existent, de solutions qui existent. Et donc, on peut faire du headless avec du WordPress. Top. Du coup, là, quand tu l’utilises en headless, il n’y a pas de problème de sécurité, puisqu’il n’est plus atteignable directement.

Eh oui, tu viens supprimer toute cette couche de sécu. Ghost, yes. Ghost, tu le connais, toi ? Alors, moi, je ne l’ai jamais utilisé. J’ai déjà joué avec en mode POC, comme ça, là. Très, très bien pour faire des blogs. Très, très bien.

Maintenant, ils ont un système de pages qui est très bien aussi. Ils ont un SDK qui te permet, en fait, de brancher directement. Donc, non, ça fait le taf. Et surtout, ça change… Moi, je dirais que ce n’est pas mal, en fait, pour faire vraiment des pages classiques ou des posts. C’est bien.

Après, si on a des gestions de contenu un petit peu plus poussées, par exemple, je ne sais pas, des recettes de cuisine ou des choses comme ça, peut-être que là, ça va être plus compliqué. Donc, c’est vraiment orienté blog et on va dire page, page de vente.

Voilà, ça, ça marche plutôt pas mal. On a un système pour mettre des abonnements payants, en fait. Si on veut faire un blog privé qui est accessible derrière, on est obligé de payer pour lire le contenu. Voilà, il y a autant de systèmes qui sont mis en avant là-dessus.

Donc, c’est plutôt pas mal. Objectivement, c’est plutôt quelque chose qu’on va utiliser en full, plus en mode WordPress. Pas forcément en API, tu veux dire ? Oui, voilà, ça va perdre beaucoup de fonctionnalités si on l’utilise en mode headless. Mais on peut le faire. On peut le faire, oui. C’est disponible. Exactement.

C’est vraiment un CMS qui est orienté contenu, média, etc. Complètement. Payload. Payload, alors version open source, donc self-hosted, qui est un peu comme Keystone, en fait, qui est basé sur un fichier, en fait, qui va générer. Donc, si tu descends un petit peu, tu verras, c’est expliqué.

Tu crées ton fichier, test, et derrière, il va générer ton admin, etc. Excellent. Encore un système, tu vois, en plus, c’est TypeScript, donc tu fais ta config, et comme ils disent, boum, tu as un CMS. Et boum, tu as un CMS. Et donc, ça, c’est plutôt pas mal.

Toujours, tout est basé sur ta base de données, ton API et ton admin, ton interface administrateur, quoi. Donc, ouais, top. Ouais. Et moi, je suis assez fan du design, quand même. Il est classe, hein ? Il est classe, ouais. C’est complètement, pas du tout subjectif.

Même l’admin, là, a l’air assez clean, assez pur, tu vois. Quand on voit l’exemple de l’admin, là, c’est clean. Ouais, c’est très, très, très, très propre. Et ça, je ne connaissais pas du tout. Moi non plus. J’ai trouvé en cherchant les CMS.

Webini, qui est un petit acteur un peu moins connu que les autres. Alors, je n’ai pas trop compris le business model. La page tarif est incompréhensible. Ok. Mais il est open source, quand même, apparemment. D’accord. Donc, c’est… Donc, ouais, essayez.

Ouais, il y a free, mais en même temps payant, mais en fonction de… Je n’ai pas vraiment du trafic. Donc, c’est un peu bizarre, leur tarif. Je n’ai rien compris. C’est en mode bêta. Ouais. Ok, bon. Ok. Aucune… On peut l’auto-héberger. Donc, voilà.

Et Cockpit, le dernier qu’on avait dans la liste, qui est en version free. Et après, il y a une version payante avec des fonctionnalités supplémentaires. Mais toujours pareil, en auto-hébergement. Donc, c’est toujours un peu bizarre, en fait, d’avoir des CMS que tu vas héberger toi-même,

Mais où il faut payer pour avoir toutes les fonctionnalités. Voilà, c’est un peu du premium. C’est du hybride de hybride, quoi. Ouais. Mais bon, après, c’est aussi… Enfin, j’ai envie de dire, c’est un gage de longévité. Quand tu te dis…

Enfin, si tu te dis, j’utilise un outil où je paye un petit peu, ça veut dire que les gens qui travaillent dessus, en fait, gagnent un peu de quoi vivre. Donc, peut-être que le CMS, à long terme, est plus viable qu’un CMS open source

Où la communauté qui travaille dessus va peut-être laisser tomber. Ouais. Et on reprend l’exemple de Netlify CMS qui a changé. Le projet était complètement mort, arrêté. Et après, il se trouve qu’il y a des gens qui ont repris le projet, qui l’ont porté, qu’on a rechangé de nom, tout.

Mais pendant deux ou trois ans, il ne se passait plus rien, quoi. Donc, le projet est totalement mort. Mais c’est le projet… C’est toute la limite de l’open source qu’on évoque souvent sur les émissions. C’est que, bah, ouais, s’il n’y a personne qui a… L’open source, c’est bien,

Mais souvent, ça ne remplit pas la gamelle ou ça ne remplit pas le frigo, quoi. Non. C’est clair. Donc, il faut trouver des moyens de maintenir, de garder une viabilité dans le projet, quoi, clairement. Yes. Voilà. Voilà pour l’épisode. On était… Bon, c’était assez complet. On a essayé d’évoquer, basé sur notre expérience,

Voilà, on n’est pas des machines. On a essayé quelques services. On a eu des histoires. Basé sur notre expérience, on pense qu’il faut vraiment être vigilant sur tous les points pour bien choisir notre CMS. Et au moins, on a identifié, en fait, ces grandes familles de CMS.

Et on espère vraiment qu’à travers cette clarification, il va être beaucoup plus facile pour vous de faire votre choix, de choisir ces CMS. Et on ne le dira jamais assez, mais essayez, testez. C’est le meilleur moyen. Passez un petit peu de temps sur tous ces services-là

Pour voir, en fait, si vous avez une appétence avec ce service-là, comment ça marche, et testez, testez, testez, testez. Et puis, n’hésitez pas à faire vos retours dans les commentaires. Si vous avez une expérience avec certains CMS qu’on a évoqués, faites un retour, ça servira à tout le monde.

Voilà, c’est toujours intéressant d’avoir un retour d’expérience. Un grand merci à tout le monde d’être resté jusqu’au bout de l’épisode. Si l’épisode vous a plu, évidemment, dites-le. Si vous n’a pas plu, dites-le nous aussi. Oui. Et nous, on vous dit à bientôt sur les prochains épisodes. Ciao, ciao. Yes, ciao. Ciao. [Musique] [Musique]