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 !
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 quatre heures,
ça risque d'être un petit peu long. Là on va essayer d'être assez exhaustif, on va dire.
Mais ouais, sujet assez vaste, en tout cas on s'en est rendu compte en le préparant,
qui est voilà, il y a beaucoup d'offres, beaucoup de différents types de CMS, donc 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 avoir, être clair et être lucide sur quels 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 Git Bays, donc c'est les CMS qui sont basés 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, et tous les warnings qui nous faut en fait se concentrer sur éviter,
justement pour éviter de tomber dans ces pièges-là. Évidemment, les CMS SASS, donc As a Service,
où là en fait on vient utiliser toutes les sur le cloud, toutes les payants ou celles fostées,
et c'est la dernière, c'est la dernière, on va dire, catégorie. C'est tous les CMS qui
sont, 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.
Évidemment, on va commencer par des 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 à de l'est dépend aussi
beaucoup du client et du projet. Il n'y a pas de CMS qui est idéal pour tous les projets,
en fait. À chaque fois, ça dépend.
C'est sûr. Après, 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.
Et 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 techniques, 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, clairement. Oui, toujours.
Ok, on y va. C'est parti. Première fonctionnalité quand même importante.
Ç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. Est-ce que ton contenu va être dans une seule
langue ou ton contenu doit être dans multilangue ? Parce que parfois, en fait, tu vas avoir des
clients qui sont que 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 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, 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 parle de gérer le multilingue
facilement. 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 du
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 et que la rédactionnelle soit que juste dans le réactionnel.
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 l'interface. Quand quelqu'un arrive sur le CMS,
que l'interface soit plus simple et qu'il y ait des accès aux choses qui la concernent.
Carrément. 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 en fait on a un système d'éditeurs, un peu avec des champs classiques qui vont être
interprétés. Ou en fait à l'ancienne, un peu à la doc avec les Whizzy Whigs, où en fait on
voit directement une sorte de preview, où on voit en fait en instantané les modifications.
Parce qu'une équipe marketing ne va pas avoir la même appétence et ne va pas avoir le même
niveau d'abstraction, 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 un 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, qui est carrément un système avec des blocs que tu glisses, etc.
En fait ça dépend déjà de la capacité technique de la personne qui va éditer,
enfin 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. C'est pour eux,
c'est plus simple. Voilà, ç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évues. Oui, voilà, c'est ce que j'allais dire.
Le système des prévues qui est super important, notamment quand on fait tout ce qui est site statique.
Voilà, parce que quand tu fais au niveau des sites statiques, alors 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 qui ne comprennent pas qu'il y ait 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 performances, c'est un impact non négligeable. Donc est-ce que le CMS, lui,
a une gestion des médias internes ou on doit l'externaliser ? Donc 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 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 est en PLS. Oui complètement, ça c'est souvent un service
qui est offert par les SASS comme je prends prismique par exemple, ils ont un système de
redimensionnement, tout ça, puisque toujours prendre en compte que première règle c'est de
pas faire confiance à l'utilisateur. On sait très bien que même si tu lui dis de pas mettre une
image plus de 800 KO, il va te mettre une image de 3 méga. Donc si tu automatises pas les choses
au niveau des images, tout ça, des médias, ça va être vite de devenir problématique. Donc voilà,
soit les SASS, ils le permettent, ils ont déjà des sites internes qui sont pas du coup parce qu'on
paye, donc on a tous les services qui sont dispos, soit il y a des CMS, celles fosterd,
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, 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 copier-writer ou par je sais pas qui. Et donc en
fait il y a tout un système de flow, en fait, de validation du contenu. 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 ne permettent pas d'avoir
un système de flow, de review. Souvent c'est corrélé avec la gestion des rôles 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. De un dernier point sur tout ce qui est ergonomie.
Alors je me suis rendu compte avec l'expérience. Je suis tombé sur des clients où il y a des
personnes dans des entreprises qui passent énormément de temps dans le CMS à rédiger des
articles, toute la journée. Et il y a deux choses. L'ergonomie du CMS, c'est ce qui est bien
ergonomique, ce qui est simple d'utilisation et surtout une chose primordiale aussi,
c'est la vitesse. C'est-à-dire qu'une personne qui va passer plusieurs heures par jour dans le CMS,
s'il y a chaque fois que tu dois recharger une page, c'est long, ç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 important.
On n'y pense pas forcément, mais c'est des retours utilisateurs que j'ai eu,
des personnes qui se plaignaient parce que c'était long, on a tout fait pour que ça aille plus vite.
Mais voilà, c'est des choses, ergonomie, vitesse, etc. À ne pas négliger quand on a un choix. Surtout
quand la personne paye en fait. Après, normalement, sur les CMS qu'on paye,
normalement on devrait pas avoir ce problème-là. S'il est bien fait, ouais.
Mais après tu peux avoir des CMS aussi qui sont assez complexes comme builder.io,
que tu es à l'heure. La interface est super complexe, il y a 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. Ce 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.
Bien sûr. Pour avoir joué avec, c'est quand même intéressant. Parfois, notre CMS,
il est écrit que quand on a une identité, qui est inscrite, on 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,
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 Melly Search, par exemple. Et donc en fait, dans le système de flow,
en fait, quand la personne est venue enregistrer ou updater le produit, en fait, 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éveloppeur. Parce qu'on va pouvoir injecter des bout de code à des moments
clés, 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 webbooks, ça rejoint ce que tu viens de dire avec les hooks, mais c'est des choses plus simples
qui vont lancer le déploiement quand tu vas changer le contenu, etc. Pareil pour les
statistiques super importants parce que sinon, si tu devais le faire à la main, ça n'a pas de
pratique pour le client. Par contre, tu vois, mais tu vas, pour revenir sur les webbooks et sur les
hooks de customisation, en fait, avec ton webbook, 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 serveur less function, très bien, mais là, ce n'est pas au sein du CMS. Je pense,
par exemple, j'ai plus le nom en tête, merde, mais pocket base, par exemple, il te permet,
en fait, de 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 external, contrairement au webbook, où en fait,
là, c'est à toi de fournir le webbook 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 webbooks, c'est des informations que tu envoies à l'extérieur. Donc, pour
synchroniser un CRM ou des choses comme ça, à chaque fois que tu es différente,
voilà, différentes infos. Donc, ç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, 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 importer le contenu et il y a aussi le système de hub,
c'est important, ça aussi, je sais que ça existe sur Prismic, il y en a d'autres qui
ont, ç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,
donc ça, c'est des choses, voilà, ça peut être nécessaire, ce n'est pas tout le temps nécessaire,
ça peut être nécessaire. Après, même sur l'import export,
juste sur la simple refonte aussi où ils avaient un système actuel qui était X,
il passe 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 agriger 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 de 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 si il y a ce système de hub clairement.
Ouais, avec des liens qui vont envoyer sur e-commerce pour t'acheter des fouets pour
le battre les oeufs. Exactement. Donc voilà, donc vous prenez cette liste, ça dépend des
clients, il y a des points qui sont importants, des points qui 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
quitter bon nombre de services parce qu'il y a tellement, il y a plein tord 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 marquetteux qui a réussi à mieux vous
marquetter 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 va, 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 guide-bays. Parce que c'est la base et alors je
sais que t'es fan, on est tous les deux fans de guide-bays et pour information, le site de
Double Slash du podcast est fait avec, est orchestré uniquement avec guide 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.
Tout est stocké sur guide, dans le code source tout est open source, tout est visible.
Alors c'est quoi le fonctionnement vraiment d'un CMS guide-base ?
Guide-base, alors guide-base en fait c'est tout simplement on est on dit guide-base 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 là, 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, de l'application et donc c'est sauvé sur guide 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 guide-base 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, c'est super adapté au site statique,
la plupart des sites statiques, après ça peut aussi être du USSR mais parce que Nox Content
normalement il lit le USSR, il est capable de le gérer aussi. Mais c'est souvent adapté
vraiment aussi de statique puisque 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 tout est statique.
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
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 10 minutes,
clairement ce n'est pas du tout 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 il y a énormément de contenus et qu'on rajoute du contenu plusieurs fois par jour,
ce n'est pas forcément le adapté. Après on ne va pas refaire la jam stack,
les avantages etc. Mais c'est quand même, 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.
Ouais mais surtout c'est que 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, donc 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 Geedbase qui fait que 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 ces données et nous on ne se fade
pas une stack toute complexe parce que plus on rajoute de l'aieur à la stack, plus on vient
complexifier la chose et surtout introduire des sources d'erreurs. Ouais de façon, oui oui,
de façon, on est d'accord, la jam stack. 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 ils changent jamais donc ils sont posés un endroit
et ça ne bouge pas. Les avantages, on l'a dit, un stockage super simple, c'est tout sur Geed.
C'est gratos quoi. Ouais c'est gratos. Les inconvénients, c'est souvent un peu plus technique,
enfin encore aujourd'hui les CMS on m'en parlait 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.
Donc de ce côté là ça beaucoup est brûlé. Et juste moi je suis intimement convaincu que,
alors oui ça nécessite une formation pour ton client mais tu lui montres un exemple,
tu vois, 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 points 2 points 2 points d'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. Bon bah voilà
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 NUXTudio. Oui évidemment NUXTudio est un des CMS
guidebase. Donc pour ceux qui font du NUXT vous regardez ce que fait NUXTudio, ç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 réact comme ça quoi. Oui oui, c'est plus simple avec le...
quoi que avec des 2 points. Oui après c'est la syntaxe. Si t'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 cesse débrouiller qu'un fishy markdown c'est super adapté, ça sera plus simple pour lui.
Et puis voilà, et puis après effectivement avec un NUXTudio des choses comme ça, il s'en sortira
largement. Pour une somme vraiment très réduite. C'est pas cher quoi, c'est pas cher. Beaucoup
sont gratuits, tous ne sont pas gratuits et parce qu'il y en a qui sont plus ou moins open
source et code propriétaire où on va en parler sur justement l'open source et gratuit, ça
veut pas dire la même chose et en mode self-hosted ou en mode SAS ou ECU qui gère 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
a listé quelques-uns. Donc Statamix, il est un peu à part. C'est un CMS qui est hyper complet,
basé sur les fichiers Markdown mais qui peut faire aussi bien des sites classiques que des API.
Enfin le truc est assez fou. Ça c'est pas open source mais il fait du reste, il fait du GraphQL,
il fait de la preview, il fait des revisions, il fait du multi-site. Le truc est hyper complet. Je
sais pas ce qui fait pas en fait. C'est assez impressionnant le nombre de fonctionnalités qui
sont disposées. Alors il n'est pas gratuit. Enfin il y a une version gratuite et limitée évidemment.
Et après il faut payer je crois si je ne me trompe pas ou alors c'est payant direct.
Oui il y a une version solo en free et une version pro.
Et par contre là je viens de voir un mot la Ravel je sais pas quoi. C'est basé sur la Ravel ?
Il est basé sur la Ravel tout le code et c'est du la Ravel donc tu peux l'étendre en faisant
le code tu peux l'étendre avec du la Ravel, du PHP. Mais il n'y a pas de base de données.
C'est vraiment du fichier Markdown tout dans fichier Markdown.
Ok excellent. Il est pas mal, c'est pas mal. Regardez parce que c'est pas mal. Par contre c'est pas
un Lux Studio tu en as déjà parlé. Alors adapter uniquement à Lux. C'est déjà pas mal.
Par contre interface c'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.
D'autocomplétion, il y a la gestion des images ou ça. C'est assez intéressant comme tel preview
en direct. 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'avais dit. On va aller voir la vidéo de Patrick sur Next Studio.
On avait DECAP CMS. Alors DECAP CMS c'est l'ancien Netlify CMS qui a été repris.
Il se changeait non tout ça mais c'est la même base. Il a été repris puisque Netlify
n'investissait plus dedans. DECAP CMS ça vous rajoute une interface admine dans votre site.
Dans votre site statique ou web app n'importe. Là on peut diter le contenu. Il y a un système
de validation, drafts. C'est pas mal. On a Spheltia CMS. Alors celui-là j'ai trouvé.
Le mec dit que c'est comme DECAP CMS en plus léger. Après je ne sais pas, tester. On a
qui statique ? 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. Il habite en Australie. Exactement. Qui habite en Australie. Qui
bossait pour qui a créé toutes les vidéos de Taywin. Il s'est mis dans ce projet là.
C'est assez récent. On se rapproche en fait de forestry à l'ancienne comme quand forestry
était encore viable et utilisable. Mais on se rapproche de l'idée. Pour l'instant c'est
fri. 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 statique CMS. Je
ne connais pas du tout. Je n'ai trouvé aucune idée. Allez voir. On a TINA CMS. TINA CMS
de la société qui édité forestry. Fermé forestry. Voilà. Forestry a fermé. Ils ont
lancé TINA CMS. Alors à la base il n'était pas open source. TINA CMS a 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. Ça met à jour en même temps.
Ça c'est pas mal comme interface pour les clients.
Oui parce qu'ils ont le contexte de « je tape quelque chose à gauche et à droite,
je vois que sur mon site ça bouge. Je vois tout de suite ce que ça fait.
Donc celui-là est top. Il est devenu open source. Le CMS. Et du coup la société offre
un service cloud. Ils vont l'héberger. Il y a des trucs en plus que Barbara Basique.
Ils sont revenus à la même solution. Forestry j'ai l'impression.
Mais maintenant c'est TINA quoi.
Oui mais l'interface ça n'a rien à voir avec le code.
Je veux dire le même business model. Normalement à la base ils étaient partis là-dessus pour changer
le business model de Forestry. J'ai l'impression que c'est revenu à peu près dans le même truc.
Maintenant dollar, la version team.
Petit dernier, Yama CMS. C'est français, ça vient de Chambierie.
Exactement. Et en fait on se devait de promouvoir le petit poulain local.
Et donc ils se mettent sur ce créneau là.
De justement du CMS statique pour pouvoir administrer tout son contenu pour les sites statiques.
Et c'est fait en sa voix. Petit clin d'œil, sa voyard de double slash.
Normal. Voilà pour les guides base. On passe à la suite.
Allez on passe à la suite. Il y a un autre type de CMS qu'on va facilement trouver.
Avant de partir sur les CMS qui sont en SAS ou en Selvosti, on voudrait faire un petit warning.
Faire attention où on voit de plus en plus de projets et de mis en place de CMS qui sont basés sur les bases.
Alors les bases c'est les back-end as a service. On avait déjà fait un épisode là-dessus.
Mais un back-end as a service, c'est clairement une solution cloud qui va nous permettre de simplifier et de créer une infrastructure back-end très très rapidement.
Donc ça c'est super bien parce qu'on va avoir la base de données, la pays, la couche de sécurité, tout, tout, on va dire le login password.
Donc ça ça va être super pratique. Sauf que c'est pas du tout, du tout optimisé pour le client final.
Donc si on utilise ça pour administrer du contenu, on va au-devant de graves déconvenues.
Tout à fait.
Et en fait il faut bien comprendre que c'est pas du tout la même chose.
Parce que je pense, on entend beaucoup parler de Asura ou de Firebase, de Supaba, 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 donnez directement accès aux sources, à la source.
Et donc votre client a accès admin. Il a un accès admin et il est sur l'accès admin de Supaba base et il injecte tout dedans.
Ça me paraît très très dangereux et très risqué.
Oui, c'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, 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 accès direct à la base, c'est hyper dangereux.
C'est super dangereux.
Et 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 fait automatiquement. On vient en trois clics, on a mis est-ce que lui il a le droit, est-ce que lui il a pas le droit, tout.
Super. Sauf que clairement le client, il n'a pas d'interface.
Donc il voit strictement rien. Et donc ça, c'est pas de taffé la même chose.
Donc attention à ça. 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.
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 sympa. 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 fait soit en go, soit en JavaScript, ce qui est plutôt sympa.
Je pense à Asura. Pareil, on avait déjà fait un épisode dessus
où on va vraiment injecter la base de données.
Ça va nous créer une interface.
On l'a dit, SoupaBase avec la panel de fonctionnalités
qui ont développé tout autour de la base de données, du storage et tout ça.
Historiquement, l'un des premiers backend as a service qui existait, c'était Firebase.
Firebase qui a été racheté par Google et donc clairement, c'est lui historiquement
le maître du backend as a service.
On va passer au SaaS.
Maintenant, les offres SaaS.
Ça, c'est un peu différent.
Alors, 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 connectez avec un navigator web.
Vous accédez à l'interface.
Ensuite, il y a des API, il y a des librairies qui sont disponibles.
Vous vous connectez, vous vous récupérez des data, 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 et tout.
Tout est vraiment accessible que par l'interface.
Par contre, l'avantage, c'est que vous n'avez pas à gérer d'évergement,
vous n'avez pas à gérer de serveur, etc.
Tout ça, c'est géré par le service.
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, ce n'est pas gratuit.
Il y a souvent des offres gratuites, mais suivant le besoin,
on se retrouve vite à passer sur une offre payante.
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, etc., 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és et on est obligé de suivre l'augmentation.
Alors, pour le coup, là, je peux faire un retour là-dessus.
Moi, j'ai implémenté, implanté ou implémenté, je ne sais pas d'ailleurs.
Dato 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.
Aujourd'hui, 5 ans plus tard, ils ont revu leur pricing, ils ont changé de politique.
Le premier niveau d'entrée est à 99 euros.
C'est super difficile parce que après, ça s'explique aux clients.
On explique que le système qu'on a choisi a changé les tarifs.
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.
Donc, le dev, il va falloir le payer.
Donc, ça passe plutôt mal.
C'est difficilement acceptable pour le client.
Il le comprend, mais ça le fait chier.
Il a juste du titre.
Je pense que sur des SASS CMS, un peu récents, qui ont des tarifs très avantageux, attention.
Attention parce que clairement, ils vont grossir, ils vont faire des levets 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 taros.
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 contenus sur ce service-là,
ça va être dur de bouger.
Donc, on est complètement captifs et on est à la merci d'une augmentation de tarif.
C'est un point qui est vraiment à garder en tête sur ce type de CMS en SASS, clairement.
Oui, tout à fait.
De toute façon, pour une société qui se lance avec un CMS SASS, leur premier objectif, c'est de gagner des utilisateurs.
Ils vont faire un tarif attractif pour que les utilisateurs viennent.
Et que le CMS devient important.
Et c'est sûr qu'à un moment donné, quand ils auront assez d'utilisateurs, effectivement, quand ils seront cramés toutes les levets de fonds,
il va falloir qu'ils gagnent de l'argent.
Et donc là, les tarifs obligatoirement, ils vont augmenter.
Donc, comme tu dis, c'est vraiment attention à ça.
Quand l'offre est trop attractif, c'est peut-être qu'à un moment donné, ça va coincer.
Oui, oui.
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 SASS, en fait.
C'est surtout ça.
La boîte, à quel niveau de maturité elle est ?
Est-ce qu'elle en est encore au bel buciment ?
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 grite tarifaire va beaucoup moins bouger.
Mais souvent, en fait, on se rend compte que les SASS, qui sont déjà très bien établies,
ont des pricing assez forts, assez élevés, avec des tickets d'entrée qui sont difficilement à moins de 100 balles.
Oui, carrément.
Alors, les avantages, ça, c'est vraiment l'inconvénient.
Voilà, le prix, attention à ça.
Les avantages, par contre, le service, il est utilisable en quelques clics, en quelques heures.
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, pour connecter les API, tout ça.
Il n'y a pas de gestion de service, il n'y a pas de mise à jour à faire, tout ça.
Tout est géré par le SASS, en fait.
Il n'y a pas de gestion de serveur.
Ça, c'est un grand avantage.
Mais par définition, si on paie le service, on ne doit pas l'héberger.
Et donc, on n'a pas à gérer ça.
Voilà.
Ce qu'il faut bien comprendre, c'est que pour une entreprise,
souvent, même si nous, 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, un développeur en interne dans l'entreprise au TITAR.
Donc, ça peut être très intéressant, au niveau du coût, de plutôt prendre un CMS,
et ça, c'est ce qu'il faut 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, je décrivais, ils ne veulent pas gérer les serveurs.
Ils n'ont plus envie de s'embêter avec ça.
Ah, c'est plutôt dans l'air du temps,
où en mode, nous, on met la carte bleue, mais on veut que ça marche.
Voilà.
Et ce qui rejoint aussi un autre point, un gros avantage aussi, c'est l'autoscaling.
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 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, ç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 automa...
C'est eux qui sont garants de cette montée en charge, de ce autoscaling,
aussi bien la montée qu'à la descente.
Donc nous, on n'a pas à gérer ça.
Oui, carrément.
Ça, c'était pas mal.
Parce que souvent, on églige, on a souvent une web-app en front, on se dit,
c'est bon, c'est du nod et tout ça, ça tourne nickel.
Mais attention, n'oubliez pas la pays.
Il faut que la pays réponde quand il y a beaucoup de visites.
Donc ça, il faut faire attention à ça.
Bon, un convenant, j'avais marqué quelques inconvénients aussi en autre chose que le prix.
C'est oui, c'est un coup de certain très exclusif.
On se fait penser à Contente Fool 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, en fait, des SASS.
On a parfois certains SASS, enfin 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.
Ce qui peut faire que...
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.
Et oui, parce que plus le couplage est élevé, plus tu restes un peu captifs 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 veux 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, tu es un SDK dans tout, si tu as envie de faire ton petit site en go,
tu peux le faire.
Si tu veux l'intégrer sur du Rubian Rails, c'est pas gênant.
Si tu commences à unbriquer un peu les deux, à avoir leur propre SDK pour lire les données de chez eux,
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, c'est un CMS, un API graphQL, où tu vas te taper dedans,
tu récupères les infos, tu les affiches.
Quand tu commences à avoir le code mélangé,
tu les prises au moment où tu veux partir du CMS,
en plus, il faut réécrire toute l'application.
C'est compliqué.
Après, je ne sais pas si les data,
si il y a une notion où les data appartiennent à la société,
ou les data t'appartiennent.
Tu vois ?
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 y aller.
Les petites lignes.
Après, je pense que les données, tout.
Vu que je ne sais pas si les bases de données sont partitionnées,
segmentées, on va dire, tenantes,
si il y a du multi-tenante,
pour être sûr que la base de données,
si la base de données, par exemple, de prismique
ou de contentful, se fait corrompre,
est-ce que c'est tous les utilisateurs,
ou c'est qu'un site,
tu vois, ce serait intéressant d'aller voir aussi
comment ils structurent tout ça.
Souvent, c'est de l'Amazon derrière,
de la WBS.
Enfin, je pense.
A la fin, ça va toucher l'Amazon, d'une façon.
A la fin, c'est touché l'Amazon.
On le sait, c'est toujours chez l'Amazon.
Donc, non, mais 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 SAS,
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, oui.
La plupart du temps, tout est disponible.
Après, c'est payant,
plus ou moins payant.
Enfin, voilà, c'est absolument de telle ou telle fonctionnalité.
C'est souvent de plus en plus par utilisateur.
Et plus par...
Donc, ça, du coup, ça peut vite venir
faire confler la note.
Oui, très cher si tu as beaucoup d'utilisateurs
dans ta entreprise, etc.
Ils sont tous passés sur ce modèle-là
par site ou par utilisateur, tu vois.
Donc, voilà.
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.
Enfin, voilà, combien ça m'a le coûté, quoi.
Clairement.
En garde vite fait la liste.
Tu as déjà évoqué Prismic,
acteur français.
Donc, tarifs raisonnables.
Enfin, ils ont augmenté il n'y a pas longtemps,
mais tarifs quand même assez raisonnables pour l'offre.
Ils ont tout un système de slice, etc.
qui permet de faire des blocs,
d'afficher des blocs, etc.
Donc, c'est assez poussé, l'interface, c'est pas mal.
Donc, c'est vraiment bon CMS, j'ai envie de dire.
Il existe depuis quelques années maintenant, donc,
valeur sûre.
Yes.
Pas mal.
Contente full, le plus connu.
Tu as déjà utilisé toi ?
Non, j'avais fait un test dessus.
Et en fait, 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.
En fait, c'était beaucoup trop gros
pour mon projet.
Donc, j'étais passé sur Forestry
pour te dire le gap, tu vois.
Mais c'était...
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 qu'il y a l'offre free,
en fait, offre déjà 5 utilisateurs de local.
Donc, il y a déjà beaucoup de choses
à prendre en compte.
Il y a de quoi faire.
Donc, ça peut être intéressant.
Dato CMS, tu connais ton celui-là ?
Ah ouais, moi je connais.
En fait, je me suis confronté au pricing...
Ils ont baissé, je crois, non ?
Il me semble, non ?
Il y a un offre free, maintenant ?
Non, ils ont passé à 149 dollars.
Ils n'ont pas baissé.
Par contre, moi, j'ai l'avantage,
c'est que j'ai un historic chez eux.
Et donc, en fait, j'ai un compte qui s'appelle
Legacy V, je ne sais pas combien,
V2, V3, V4, je n'en sais rien du tout.
Mais sur les...
Pour les deux petits projets...
T'es toujours un 9 euros, toi.
Exactement.
Et donc, en fait, pour les deux petits projets que j'utilise,
en fait, 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, tout.
Donc, ç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 SAS, 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 t'as codé ton site
pour éviter d'avoir 20 000 requêtes
qui ne servent à rien, quoi?
Est-ce que ça a mis du cash?
Voilà.
En tout cas, c'est des contraintes qu'on découvre.
Nous, on a découvert un peu en mode hardware,
enfin, vraiment de la manière un peu violente.
Mais, voilà, on a découvert qu'il y avait
une API avec un rate limite, quoi.
Intéressant à connaître.
Builder IO.
Celui-là, c'est donc le CMS qui offre
une interface hyper visuelle,
un peu à la Webflow,
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 supers framework à côté.
Donc Quick, 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, je n'adhère pas des masses
sur ce type de chose là, de drag-and-drop.
OK.
Après, c'est peut-être mon côté d'Ev.
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 Codinari,
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
pour administrer
de manière très visuelle
tout le contenu.
C'est quand même assez intéressant.
Par contre...
Il est vraiment pas mal.
Comme ils disent, c'est un mix
entre le code et le no-code.
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é.
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.
C'est une fonctionnalité
qui fait son chemin.
Yes.
Et toujours dans le même délire
de visuel.
On a Storyblocks.
Ce qui fait beaucoup
de marketing en ce moment.
Ils ont embauché
des vrais, etc.
Il faut beaucoup de conférences
très actifs depuis quelques mois.
CMS,
pareil visuel, avec des blocs,
tout ça, où tu peux...
Les tarifs s'appliquent un peu.
Ils ont augmenté les tarifs aussi.
Ils ont un système de communauté
qui, pour le coup, est gratuit
avec un utilisateur.
Et 9€,
le deuxième utilisateur.
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€.
C'est correct, c'est très correct.
C'est très correct.
Oui, ça va, c'est correct.
Après, il faut qu'il y ait de l'argent.
Complé, complet.
On va passer vite fait
à les autres.
Plasmic.
Je ne fais pas du tout.
Moi non plus.
J'ai trouvé ce truc.
ButtersMS.
Il est vieux aussi, celui-là.
Il est expié un moment.
Je ne l'ai jamais entendu.
Il y en a vraiment beaucoup
sur le marché. Agility,
Content.ai,
Apito,
celui-là aussi.
Il est assez récent. Il a une version
Community, un Beta encore,
mais qui n'est pas encore disponible.
Sanity Studio.
Celui-là, c'est assez particulier.
Sanity Studio est open source.
Par contre, c'est que eux qui peuvent l'héberger
d'après ce que je l'ai compris.
Je ne sais pas si on peut l'héberger.
Non, pardon, je suis d'inconnérée.
J'ai vu la doc, on peut l'auto-héberger.
Sanity, il a l'air pas mal.
Il y a pas mal de gens qui en sont contents.
Moi, j'avais regardé.
Ils avaient une méthode
de requétage
pour aller requetter leur données.
En fait,
c'est une
sorte de graffes-ql,
mais un peu
spécifique à eux.
C'est un query language
qui s'appelle croc.
Croc.
Query language,
je ne sais pas quoi.
J'avoue,
je n'avais pas réussi à crocher tout de suite.
C'était super frustrant
parce que je ne pouvais pas
récupérer la donnée tout de suite.
J'étais obligé
d'apprendre leur langage de requétage
des données.
Ça m'avait saoulé.
J'étais passé à autre chose.
Je viens de voir que je vois
graffes-ql.
Peut-être qu'ils ont ouvert
le côté graffes-ql.
Tout de suite, c'est beaucoup plus simple.
Parce que
pour ceux qui ne savent pas,
j'aime beaucoup graffes-ql.
Mais c'est pour ceux
qui ne savent pas.
Sanity,
c'est
plutôt l'infrastructure
qui vende plutôt
que l'interface CMS.
Il faut aller fouiller un peu dans la doc.
C'est un business model.
C'est un truc composable, content,
cloud.
C'est leur modèle
qui vende.
Ce n'est pas le CMS qui est forcément mis en avant.
C'est tout ce système de content cloud.

Ok, intéressant.
Ça marche.
Dans ces sas,
il y a des
petits
offres qui sont un 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.
Donc,
qu'on peut auto-héberger.
Par contre,
les sociétés qui édite ces logiciels open source
ont besoin
de trouver des business models.
Le business model, c'est d'offrir un hébergement
pour leur solution open source.
Strapi, c'est lancé là-dedans, Directus,
que tu connais bien,
offres cloud.
Qu'est-ce que ça apporte ?
C'est qu'on utilise
le CMS open source,
mais qui est hébergé chez eux.
Il s'occupe de l'hébergement,
de l'autoscaling, etc.
Tout ce qu'on retrouve dans le sas,
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é.
Strapi dit ça.
Strapi dit que c'est un très bon hébergement
avec toute la gestion des images, etc.
Donc voilà.
C'est un petit peu différent.
C'est entre le sas et le self-hosted.
Un outil open source qui est hébergé
par un tiers.
Excellent.
Ce qui nous amène
à la troisième type
de CMS
pure, qui sont
les CMS
self-hosted.
Donc, on va héberger
nous-mêmes.
Donc là, on doit gérer le serveur.
Par contre,
souvent, on a beaucoup plus de largesses
dans ces solutions-là.
Et donc, clairement,
quel est le fonctionnement
de ces systèmes-là
qui sont
de ces CMS self-hosted ?
Voilà, tu fais tout toi-même.
Voilà. Donc, déjà, il faut être dev.
Déjà, il faut avoir des compétences techniques
pour 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 as vraiment
tes seuls en gros,
tu as un CMS et tu es seul à le gérer.
Donc, tu dois gérer ton hébergement en tes images,
le connecter à OS3, etc.
Donc, voilà. Donc, c'est pas réservé
à tout le monde, c'est réservé surtout à des personnes techniques
ou à des entreprises qui ont des personnes en interne
qui sont techniques, des développeurs, tout ça.
Donc, voilà, 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
que tous ces CMS
self-hosted, en fait, on va
prendre du code
mais on va pas recoder
nous-mêmes ce CMS
là. On va utiliser
des CMS qui sont soit open source,
soit propriétaire,
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, 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
minimum 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 t'as pas codé tout un CMS
puisque c'est un CMS qui est déjà disponible.
Donc la mise en place, c'est super rapide
parce que, enfin, pour ceux qui ont déjà fait
un CMS pour un site
d'un client, c'est hyper long, faut tout refaire
les utilisateurs, etc. Là, c'est tout disponible.
En fait, si tu prends cette API, par exemple,
tu peux l'installer
en gros, en une demi-heure, une heure,
tu l'instales sur un hébergement
et puis tu te connectes et puis direct.
Tu peux commencer à créer du contenu, etc.
Donc c'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
ou on va dire
dans l'agence
ou 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, c'est
déjà, le CMS, tu peux le faire évoluer
parce que souvent, alors je prends
Strapi parce que je le connais bien, tu connais bien Directus.
Mais Strapi, tu as tout un système
de hook, etc. Donc, tu peux coder
directement des hooks
quand tu as un article écrit,
il fait ça, etc.
Tu peux le faire évoluer.
Avantage, par rapport au SASS, il n'y a pas de changement de prix.
À part si ton débergement
il augmente en tarif, mais ton CMS
il ne changera pas de prix. Il est chez toi,
tu fais ce que tu veux.
Les data, elles sont chez toi aussi.
Comme on en parlait de tout à l'heure dans le SASS,
les data à qui elles sont, là, au moins, c'est chez toi.
C'est à 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, en fait,
il y a quand même deux possibilités.
C'est soit
du code où là, tu vas
on fait
un fork, on va
faire un guide 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, voilà,
d'une image déjà construite.
Où là, en fait, on va
instantier la machine
avec directement la version
de
du CMS.
Par contre, si on fait, si on déploie
avec une image docker, on va
perdre tout le côté
custom qu'on pourrait
venir sur du
code que nous-mêmes, on vient
celle-là, celle-là, faut-ce-être quoi.
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'instantier, soit de
récupérer l'image
préconstruite via un docker, quoi.
Ouais, ouais, ouais, souvent
c'est... ça dépend en fait,
ça dépend si tu as besoin de personnaliser ou pas, en fait.
Exactement. Voilà, si tu as juste besoin
de l'utiliser tel quel,
pas besoin de s'embêter.
C'est souvent plus simple.
Après, tu dois... enfin, avec une image docker,
je pense que tu peux aussi modifier
et garder juste le docker file, tout ça, mais...
Ouais, après,
ça dépend de le besoin, quoi.
Ça dépend. Donc,
Strapi, alors Strapi, c'est...
celui-là, je connais bien parce que je l'ai utilisé pour des clients,
donc il est... c'est français, ça a été lancé par des français.
On l'en a reçu, Jim, il y a
quelques temps dans le podcast,
où il nous a parlé de l'or. Voilà.
Et à l'époque, c'est marrant parce que...
juste avant, je parlais de l'off-re-cloud,
et au moment où on l'avait reçu dans le podcast, en fait,
ils avaient pas encore d'off-re-cloud et j'avais évoqué cette possibilité.
Enfin, je lui ai demandé pourquoi ils faisaient pas d'off-re-cloud
et alors je sais pas si c'est moi qui les inspirait.
Je sais pas, je me jetez des fleurs, mais...
entre temps, quelques mois après, ils ont lancé l'off-re-cloud.
Alors je sais pas trop...
d'où ça vient, l'idée, mais en tout cas,
moi, je trouve, c'est pas mal
cette offre de dé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,
mais voilà, comme on voit les vidéos,
tu crées tes champs, tu crées des posts, par exemple,
tu vas mettre un titre, un contenu, etc.
Lui, au fur et à mesure, il va sauver dans le code,
en fait, il va générer le code.
Il va... c'est pas sauvé en bas,
c'est vraiment sauvé dans le code.
Et après, voilà, tu remplis ton contenu, etc.
Donc, il est pas mal, il y a des plugins qu'on peut rajouter,
il fait du GraphQL, il fait du reste, enfin, voilà.
Super CMS,
open-source.
Quoi de dire de plus ?
Français, français, français.
Et français en plus ? Ouais.
Yes.
Autre solution directus, tu peux en parler ?
Autre solution directus,
oui, moi, je peux en parler.
Alors, je trouve que c'est bien plus
que un CMS, en fait.
Les versions antérieures
étaient vraiment cantonnées au CMS.
Là, en fait, 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
des appels spécifiques,
en fait, à telle update,
à telle... on va avoir de l'automatisation,
on va avoir du data reporting,
on va pouvoir créer
des propres dashboards.
Un exemple typique,
j'ai créé un dashboard pour que la cliente
puisse voir directement
son compte stripe,
toutes les interactions
stripes
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.
Donc, tu vas pouvoir vraiment créer
des dashboards
en plus de gérer ton contenu.
Et ça, c'est au sein
du même outil.
Donc ça, c'est hyper
confortable.
Autre point que j'aime beaucoup
chez Directus, c'est que leur base de données
est hyper clean.
Mais c'est vraiment super clean.
Ou en fait, quand tu exportes la
donnée et donc t'as accès
à la base de données, donc tu vois
et l'information est
stockée la plus pure possible.
En tout cas, c'est vraiment
ça m'avait choqué.
Justement, tu peux récupérer
ces données et en faire autre chose.

moi, je trouve ça super bien.
Ça c'est top. Ça vient un couplage
super léger.
Il y a très peu de couplage. Il y a très peu.
Il y a rien porté dans un autre CMS sans
trop de travail. Exactement.
Et tu peux
un très très très faible couplage
et tu peux gérer
toute la partie
utilisateur
directement
dessus avec des droits limités.
Donc en fait, tes utilisateurs
de ton API ou de ton applicatif
en fait, ont des droits
que limités, mais tu les intègres
aussi là-dedans.
Donc franchement,
c'est vraiment super.
Donc eux, ils le vendent aussi comme CMS
mais comme back-end as a service.
Donc
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.
Pareil,

REST, GraphQL,
ils ont leur petit SDK
tout.
Donc non, pour le coup,
c'est pas mal. Tu peux
faire beaucoup d'automatisation
et créer des dashboards.
Je suis assez fan.
Super fan.
C'est intéressant de directus, c'est marrant parce que je ne sais pas, on 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.
Ça n'est pas du tout ça.
Et du coup, l'évolution est super positive.
Le CMS a super évolué.
Et je ne sais pas si t'es au courant,
mais Alexandre Chopin est maintenant chez
Directus.
Il est directeur des ingénieurs.

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.
C'est les deux frères qui ont lancé
Nuxt. Et donc maintenant,
Alexandre Chopin est parti
chez le travailler chez Directus.
Excellent.
Super CMS.
On a Keystone 6.
On en a parlé
en début d'épisode de Geatbase.
Donc c'est la même agence.
Ici, je ne me trompe pas.
SinkMill, qui est australien aussi, qui avait
lancé CMS.
J'avais pas fait gaffe
sur le rapprochement.
Et oui, c'est les deux.
Donc ils ont deux CMS, l'agence
très productif.
Basé sur... Alors, ce CMS,
il est assez particulier, c'est qu'il est basé
sur les skimages,
sur les fichiers.
Tu définis
tes champs, etc. dans des fichiers, ta base de données.
Et après, il va te générer
l'admire.
Toutes, exactement.
Toutes skimages.
J'avais testé
en version 5.
Et en fait,
oui, je me rappelle.
Et en fait, quand ils sont passés à la 6,
ils avaient changé, ils ont changé plein de choses.
Et en fait, j'étais un peu dégoûté.
Je me rappelle.
Je me rappelle et j'avais pas poussé le truc.
Non, ok, je me rappelle de ça.
Je me rappelle. Pas mal.
Oui, pas mal, pas mal.
Je pense que la 6
est bien plus mature,
et bien plus propre.
Et moi, je me rappelle de ce projet,
le gros problème était
la documentation à l'époque.
Moi, je trouvais pas très clair.
Il y avait plein d'infos que je trouvais pas.
Et je pense qu'aujourd'hui,
comme bon
nombre de projets
encore plus open source,
la doc est complètement clé.
Donc, voilà.
Elle est bien pu, complète, elle est bien faite,
elle est claire.
C'est primordial de façon.
Ok.
CrapCMS, CrapCMS, c'est un CMS
que je connais très très bien,
qui est peu connu, très très peu connu.
C'est du PHP.
Par contre,
il n'est pas open source,
il est propriétaire, il est payant
pour avoir GraphQL tout ça, mais par contre,
d'origine, en fait, quand vous avez la version payante pro,
il y a un système, il y a du GraphQL.
Tu crées tes champs, etc.
Comme tu veux, en fait, c'est totalement modulaire.
Au niveau des champs,
des images, etc. Il y a une très bonne gestion
des images, etc.
Ça resserre les images, etc.
Donc, le CMS est très avancé pour le contenu.
Donc, comme je l'ai dit GraphQL,
gestion des utilisateurs, il y a un mode
preview qui marche avec
tout ce qui est web app, NUX, etc.
J'en ai déjà fait.
Donc, CMS super intéressant
qu'on peut étendre aussi
avec un système de module et tout.
Alors, tu dois le self-hoster
mais combien il est payant ?
Est-ce qu'il est payant ?
La version pro,
donc 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é.
Voilà. 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 voilà.
Ça marche très très bien.
J'en ai pas mal qui marche.
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.
Oui, j'étais obligé de le mettre.
On parle de WordPress, évidemment.
Voilà.

WordPress est utilisable en Netless,
évidemment, via quelques modifications
puisque de base, il est pas forcément disponible.
Enfin, WordPress fonctionne avec
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 Netless 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 Netless avec du WordPress.
Et du coup, là,
quand tu l'utilises en Netless,
il n'y a pas de problème de sécurité, puisqu'il est plus atteignable
directement.
Oui, tu viens supprimer
toute cette couche de
de cq, quoi.
Ghost, yes.
Ghost, tu le connais, toi ?
Alors, moi, j'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 c'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 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.
Oui, oui, oui.
Ça marche plutôt pas mal. On a un système
pour mettre des
des abonnements
payants, en fait,
si on veut faire un blog privé
qui est accessible
derrière
un...
contenu, 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.
Donc, mais pour...
Apportement, un API, tu veux dire.
Oui, voilà. Ça va
perdre beaucoup, beaucoup, de fonctionnalité
si on l'utilise
en mode headless.
Mais, on peut le faire.
On peut faire, oui, oui.
Exactement.
Oui, 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
qui est basé sur un fichier
qui va générer. Donc, si tu descends un petit peu
tu verras, c'est expliqué. Tu crées ton fichier
t'es qui mérate ça.
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,
boom, tu as CMS.
Et boom, 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
ton admin, ton interface
administrateur, quoi.
Donc, ouais, top.
Et moi, je suis assez
fan du design quand même.
Il classe, ouais.
C'est complètement, or pas du tout,
subjectif.
Même
l'admin, là,
c'est clean, assez pure, tu vois.
Quand on voit l'exemple de
l'admin, 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
CMS Webini, qui, voilà,
petit acteur, un peu moins connu que les autres.
Mais 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...
Ouais, il y a frime,
en même temps payant, mais en fonction de...
Je n'ai pas vraiment du trafic. Donc, c'est un peu bizarre leur tarif.
J'ai rien compris.
C'est en mode beta.
Ouais.

Mais on peut l'auto-héberger.
Donc,
et cockpit, le dernier qu'on a 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...
C'est un peu du frimium.
C'est du hybride de quoi.
Ouais.
Mais bon, après, c'est aussi...
Enfin, j'ai envie de dire, c'est un gage
de longévité sur un... 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, sont... Voilà.
Gagne un peu leur... Enfin, de quoi vivre.
Donc, peut-être que le CMS,
à long terme, est plus viable qu'un CMS
open source où, voilà,
la communauté qui travaille dessus va peut-être
laisser tomber. Ouais.
On reprend l'exemple de...
de Netlify CMS qui a changé.
Le projet était complètement mort à arrêter.
Et après, il se trouve qu'il y a des gens
qui ont repris le projet, qui l'ont porté,
qui ont rechangé de nom, tout.
Mais pendant 2 ou 3 ans,
il 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 y a personne qui a
l'open source, c'est bien, mais souvent
ça remplit pas la gamelle ou ça
remplit pas le frivot, quoi. Non.
C'est clair. 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.
C'est...
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... ces grands
familles... ces grandes familles
de CMS. Et on espère
vraiment que, à travers
cette clarification,
il va... être
beaucoup plus facile pour vous de faire
votre choix, de choisir ces... ces CMS.
Et on le diras
jamais assez, mais essayez
tester. C'est le
meilleur moyen. Passez un petit
peu de temps sur... sur tous ces services
là pour voir, en fait, bah, si
vous avez une... une appétence
avec ce service-là, comment
ça marche et... et tester,
tester, tester, tester. Ouais, et puis,
bah, n'hésitez pas à faire vos retours
dans les commentaires. Si vous avez
une expérience avec certains CMS qu'on a évoqués,
bah, faites un retour. Ça servira à tout le monde.
Voilà, c'est toujours intéressant d'avoir un retour
d'expérience. A grand merci
à tout le monde d'attester jusqu'au bout
de l'épisode. Si l'épisode vous a
plus, évidemment, dites-le. Si
vous n'a pas plus, dites-le nous aussi.
Oui. Et nous, on vous dit à bientôt
sur les prochains épisodes.
Ciao, ciao.
Yes, ciao.
Retrouvez double slash sur vos plateformes
de podcasts préférées et sur le site
internet du podcast www.slash-podcast.fr
Sur le site, vous allez retrouver
tous les liens d'épisodes, les références
évoquées durant l'émission.