Bruno:
Il y a 25 ans, le développeur web était un peu malgré lui le correcteur orthographique de l'entreprise. Quand le marketing voulait changer le mot du titre d'une page, par exemple, ticket. Fallait modifier un prix, ticket. Mettre une majuscule à bienvenue parce que d'un coup on avait décidé d'être un peu plus poli, ticket. Et puis un jour, quelqu'un a eu l'idée d'inventer ce truc qu'on a appelé le CMS. Tout d'un coup, le marketing pouvait éditer ses propres pages et le développeur pouvait se remettre à faire ce qu'il préférait, du code. Tout allait pour le mieux dans le meilleur des mondes, sauf qu'aujourd'hui, on n'a plus vraiment besoin de CMS pour créer un site puisqu'on peut demander à Claude de créer le site de A à Z. Mais alors, comment on choisissait le bon CMS dans cette jungle qui voyait pousser plus de frameworks que JavaScript chaque semaine ? Maintenant qu'on peut générer un site en entier sur une simple commande, a-t-on encore besoin de se poser la question ? Et surtout, si Claude peut tout faire, est-ce que le marketing peut générer le site directement ? Pour répondre à ces questions de contenu, je ne reçois pas Don Draper, mais il s'y connaît en équipe marketing qui veulent modifier leur copie à minuit. Pierre, bonjour.
Pierre:
Bonjour Bruno, excellent intro. Merci.
Bruno:
Alors Pierre, est-ce que tu peux te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Pierre:
Bien sûr, donc mon prénom c'est Pierre, mon nom de famille c'est Burgi, et je suis le cofondateur et CEO de Strapi.
Bruno:
Ok, alors justement, Strapi est un framework qui est quand même un CMS qui est quand même plutôt très connu dans la communauté Java. L'idée, c'est justement de comprendre, un peu comment ce framework s'est construit, quelles sont ses spécificités techniques, où est-ce qu'on en est en 2026. Donc avant de plonger sur tout ça, est-ce que tu peux nous faire déjà un premier historique de Strapi ?
Pierre:
Avec grand plaisir, je vais venir en complément de la très belle histoire du CMS que tu nous as proposé en intro. Donc nous dans cette timeline on arrive en 2015, on arrive en 2015 puisque à ce moment là Aurélien, Jim et moi mes deux cofondateurs on est étudiants donc on fait beaucoup de projets web dans ce contexte là, on est étudié à Ethic HETIC qui est une école du numérique donc on faisait du, webdev, du webdesign et du webmarketing mais nous on était un peu des geeks donc on faisait surtout du dev et donc on a créé énormément de sites, applications mobiles web app etc avec, les outils d'époque et quand on faisait un site on utilisait les sms traditionnels wordpress parfois de repas etc, et il ya plusieurs changements à cette époque là le premier c'est que le contenu il devait plus seulement être géré sur des sites web mais aussi sur des applications mobiles donc. Ça c'est un premier problème le deuxième sujet c'est que en tant que développeur Front, on n'avait aucunement envie de faire du jQuery puisque c'était l'émergence des frameworks Front, Backbone, AngularJS, et c'est seulement en 2015 que sont arrivés React et Vue. Ça part loin. Et le troisième point, c'est qu'en tant que développeur Front, on sait du JavaScript toute la journée, et quand on devait utiliser un SMS traditionnel, open source, on devait faire du PHP. Et c'est pas un débat de quel est le meilleur des langages de programmation, c'est un sujet de fainéantise. On faisait du javascript toute la journée.
Bruno:
C'est un point commun de beaucoup de développeurs et développeurs.
Pierre:
Et oui, assumons-le. Donc, on faisait du javascript toute la journée. Donc, quand on faisait du bac, on n'avait pas envie de changer de langage. Je pense que pour devenir excellent dans une langue, qu'elle soit parlée ou que ce soit un langage de programmation, on préfère être ultra spécialisé. Et donc, on voulait faire du javascript toute la journée, peut-être même toute la nuit. Mais ce n'était pas possible. Sauf qu'il y avait quelque chose quand même d'assez récent à ce moment-là. C'était Node.js. Alors la version 1 je ne sais pas si c'était en 2015 ou en 2014 qu'on en faisait de manière si intense quand on a créé Strapi mais en tout cas on était au tout début de Node.js et donc pour ces trois raisons on s'est dit il nous faut un CMS qui est basé sur Node.js, que du javascript et qui a une API puisque de cette manière là on va pouvoir exposer le contenu à une application mobile et surtout à ces framework front-end qu'on adore utiliser.
Bruno:
Il n'y avait pas Next déjà à.
Pierre:
L'époque ? Non, puisque Next est venu en surcouche de React. Et d'ailleurs le premier panel d'admin de Strapi a été fait sur AngularJS puisque le projet a plutôt commencé en 2013-2014 je parle de 2015 puisque c'est en octobre 2015 qu'on a publié le projet sur GitHub et, donc quand on a fait la première version de Strapi, React n'existait pas et donc AngularJS avec ses ng-repeat etc était absolument fantastique bien qu'ayant beaucoup de problèmes de performance, donc non non Next.js n'existait pas encore et même la première admin de Strapi qui a été faite sur React, qu'on a sorti via Strapi 3 Alpha, était faite sur React Boiler Plate, qui est un template qui a été créé par Max Teuber, le créateur de State Components, et Next.js est venu vraiment en remplaçant de React Boiler Plate. Rack Boilerplate étant vraiment un boilerplate, Next.js arrivant vraiment comme un framework avec toute la logique qui était vraiment cachée dans le package.
Bruno:
Donc vous créez ça quand même dans un contexte d'explosion de l'écosystème JavaScript avec effectivement l'arrivée de Node. On avait effectivement trois frameworks qui sortaient chaque jour. Il y avait limite plus d'actualité dans les frameworks JavaScript que ce qu'on a aujourd'hui dans l'IA.
Pierre:
Je te rône un peu.
Bruno:
Mais tu vois un peu l'idée.
Pierre:
Mais en effet, oui.
Bruno:
Comment on fait pour... Parce qu'en plus, vous à l'époque, vous étiez jeune. Donc, certes, vous avez déjà l'expérience, mais vous étiez quand même jeune. Comment tu fais pour essayer de maintenir un cap ? Parce que du coup, tu es aussi en train de créer un CMS dans un contexte où ça bouge de tous les côtés. Tu as des frameworks qui arrivent et compagnie. Comment tu fais pour maintenir ton cap quand tu as des tas de choix de paradigmes qui sortent, qui arrivent, qui arrivent et qui partent ? Comment tu fais pour maintenir ton cap sur tes choix techniques ?
Pierre:
Pour être transparent, on a tourné en rond. Et on a bien tourné en rond. Et ça a été dur. Ça a été dur. On s'est dit, on fait un CMS. Puis finalement, on ne met pas le front dedans puisqu'on va le laisser au front-end framework. Et puis finalement, on va peut-être faire un framework. Comme ça, on apporte aussi l'ententication, le plot de fichiers. Puis on va peut-être descendre plus bas dans la stack vraiment un framework minimaliste et puis du coup on fait telle architecture puis finalement on fait celle-ci et ça a été super dur je crois qu'on s'est un peu burn-out du projet avant même de le lancer et, ça se comprend, en tant que dev on voulait avoir la bonne architecture mais à un moment il faut aussi se lancer et ça a été dur, au tout début, on a même été plusieurs sur le projet à travailler ensemble il y avait des choses sur lesquelles on était d'accord des choses sur lesquelles on était moins des moments on a voulu arrêter et puis on s'y remis et puis, ce qui nous a forcé vraiment à y aller c'est qu'on s'est dit ok à telle date on met le projet sur GitHub. Peu importe comment il est en fait et on fout qu'on ait des utilisateurs et finalement c'est pas propre à l'open source, c'est pas propre au dev mais c'est dans la création de n'importe quel produit c'est qu'est-ce qui fait si on sort un produit dont on est fier c'est qu'on l'a sorti trop tard, j'aime beaucoup cette phrase et alors ça veut pas dire que quand on dit sortir c'est crier sur tous les toits on a fait la meilleure chose du monde, on est en train de bosser là dessus on aimerait bien avoir du feedback d'utilisateur est-ce que ça vous dit d'essayer et c'est dispo vous pouvez y aller donnez nous du feedback et je pense qu'on a mis longtemps avant d'arriver, À cette phase-là, on était très perfectionnistes, on connaissait pas trop aussi ces principes-là. Et donc voilà, on a beaucoup tourné en rond, et puis finalement à un moment on s'est dit, allez, on y va. Et d'ailleurs on a sorti Strapi sur GitHub en octobre 2015, et on l'a maintenu, autant qu'on pouvait puisqu'on était encore étudiant à ce moment-là. Et on s'est dit, ouais, mais en fait AngularJS, non, il faut que ce soit sur React. Il y a des utilisateurs qui nous ont dit moi je veux étendre ce rapide donc en fait il leur fallait un système de plugin et donc en fait on a tout réécrit, from scratch et on a sorti une nouvelle version en octobre 2015 qui était la version 3 alpha et c'est vraiment là que le projet a décollé d'un point de vue usage mais c'est parce que. On avait lancé une première version, on avait collecté du feedback et on a itéré dessus mais au moins la version qu'on a sortie en 2017 on savait pourquoi on le faisait puisque ce sont les retours des utilisateurs qui nous ont guidés dans cette direction-là.
Bruno:
Oui, donc ce qui a permis aussi le succès, c'est le fait qu'à partir du moment où on pouvait commencer à étendre le CMS et ajouter des plugins, c'est là où, du coup, la communauté a commencé à s'emparer du projet. Techniquement, c'est quand même un challenge assez complexe de concevoir un système dans lequel les gens peuvent coder, au final, un peu comme ils veulent, potentiellement, du coup, faire de la merde, sans que ça te pète à la gueule derrière.
Pierre:
Ah là là, c'est l'histoire de ma vie. C'est notre plus grande force. Strapi est sûrement le SMS le plus personnalisable. C'est énormément de boulot aussi. il y a énormément de plugins dans l'écosystème on a une marketplace donc il faut refuser plugins, s'assurer qu'ils sont de bonne qualité, qu'ils sont mis à jour, et on a des gens qui font tout et n'importe quoi avec Strapi, c'est sa plus grande force mais c'est aussi beaucoup de maintenance, des githubisues sur des choses où les gens ont fait des trucs tordus, en fait c'est pas de la faute de Strapi mais ils ont fait les choses d'une certaine manière donc voilà, c'est un parti pris de dire ok, vous allez pouvoir faire tourner le site de adidas.com sur Strapi, même si vous avez des besoins ultra particuliers. Par contre, voilà, c'est-à-dire qu'il faut qu'on ouvre certaines portes. Et d'ailleurs, c'est pas forcément le CMS qui a le plus de fonctionnalités, et on l'assume totalement. Par contre, vous allez pouvoir l'étendre selon vos propres besoins, le connecter à tel ou tel outil. Et ça, c'est là que Strapi se distingue.
Bruno:
Tu disais au départ que vous aviez commencé avec WordPress.
Pierre:
Oui.
Bruno:
Effectivement, c'est du PHP, mais peut-être que vous l'aviez déjà bien torturé, manipulé, dans tous les sens. Bien sûr. Est-ce que du coup, il y avait une volonté de se dire, ok, on va reprendre tout WordPress, mais on va juste le traduire en JS ? Ou est-ce que d'emblée, il y avait un côté de se dire, ok, on prend ça de WordPress, mais tout le reste, on bazarne ? Enfin, tu vois, comment vous avez décidé de vous positionner, entre guillemets, vis-à-vis de WordPress ?
Pierre:
La première vision, c'était en clone WordPress en Node.js, puisque JavaScript, c'est cool. Et donc, il y avait un système de thème au sein de Strapi, un voie même qui s'appelle Strapi d'ailleurs. Donc, c'était vraiment ça l'idée. Donc, c'était JavaScript, c'est cool, on va faire ça. Et puis, on a fait un meet-up, et puis les gens nous ont dit, bon, OK, so what, c'est juste un langage de programmation différent. C'était déjà pas mal en réalité, je pense que la suite l'a prouvé, mais c'est vraiment aussi ce changement de paradigme sur la manière de créer le front avec l'émergence des frameworks front qui a vraiment fait qu'on ait découplé, le CMS du front avant que le headless CMS soit quelque chose. Le terme headless CMS, je crois qu'il arrive en 2018. Donc nous, c'était plutôt un framework CMS API first. Et donc ça, c'était quand même un des points très importants en termes de différenciation. Et puis, il y a quand même un grand sujet dans la communauté WordPress au niveau des plugins qui sont les failles de sécurité. Un des points principaux, c'est le fait que les plugins WordPress ne font pas seulement du back, mais font aussi du front. Et donc, ils sont intégrés au niveau du thème, et donc les visiteurs du site voient directement le thème. Là où un plugin Strapi, il va surtout étendre l'admin de Strapi, et puis il va éventuellement exposer des API endpoints additionnels. Donc, ces API endpoints, il faut qu'ils soient bien protégés, c'est clair. Par défaut un API endpoint il n'est pas ouvert, même si tu l'écris en code, il va falloir que tu ailles mettre ta configuration sur comment est-ce qu'il est accessible. Est-ce qu'il est accessible à tout le monde, est-ce qu'il est accessible sur certaines conditions etc. Mais par défaut il est fermé. Donc, ça force vraiment au moment où tu vas l'ouvrir à se poser les bonnes questions. Donc, c'est ce genre de contraintes quand même qu'on a mis de manière additionnelle.
Bruno:
C'est-à-dire que ce n'est pas le développeur du plugin qui va décider comment est-ce que les endpoints sont exposés, c'est la personne qui installe le plugin sur son site ?
Pierre:
Non, c'est quand même le développeur du plugin. Mais le plugin, puisqu'il n'a pas la partie frontaine du site, puisque celle-ci va être fait en React ou autre, eh bien, il n'y a que les endpoints qui sont définie, et un API endpoint c'est quand même plus protégé qu'une fonction en PHP parce qu'il y a des paramètres, etc.
Bruno:
Et du coup, tu n'as pas de plugins qui peuvent injecter quelque chose en front qui va aspirer des choses ?
Pierre:
Par contre, il pourrait y avoir des plugins malveillants qui vont aller chercher, jusqu'au niveau de la database puisqu'ils ont accès. C'est une couche additionnelle qu'on aurait pu mettre et qu'on pourrait toujours mettre d'ailleurs, c'est que comme on installe une app sur iPhone on lui donne des droits, et donc au sein du projet Barrand, on pourrait dire tel plugin, je m'assure que je lui donne bien accès à ça, ça, ça. En réalité, les plugins qui sont sur la marketplace, on les review tous. Et s'il y a le moindre souci, on stoppe un plugin. On a des règles très claires sur la sécurité.
Bruno:
Est-ce que vous avez fait des choix techniques fondamentaux que vous portez encore aujourd'hui ? Est-ce qu'il y a eu peut-être même des choix de paradigme qui sont imposés à tous les fabricants, enfin tous les éditeurs pardon de plug-in pour rentrer dans cet écosystème est-ce qu'il y a une empreinte tech Strapi aujourd'hui ?
Pierre:
Créer un plug-in oui il y a clairement une manière de faire un plug-in il y a une documentation très claire, il y a des outils on a notre design system par exemple qui est utilisé c'est un des plug-ins qui sont développés donc il y a, une cohérence en termes du high avec l'admin panel plus global donc oui c'est un petit framework à part entière.
Bruno:
Et du coup sur des notions d'architecture pour aller un peu dans le cœur du sujet, dans le vif du sujet, côté Strapi, est-ce qu'il y a des paradigmes techniques que vous avez implémentés dans votre CMS qui étaient soit innovants, soit qui sont aujourd'hui des philosophies fortes que vous avez encore aujourd'hui chez Strapi par rapport à d'autres CMS du marché ?
Pierre:
Oui, alors déjà il est open source comparé à toutes les solutions SaaS propriétaires, il s'installe en local et ça veut dire que les développeurs peuvent vraiment étendre le CMS énormément pour ajouter des API endpoints, par exemple en se connectant directement à la database donc à l'accès direct à la Postgres, donc ça veut dire qu'on peut vraiment aller travailler la performance créer des API endpoints supplémentaires donc ça c'est vraiment quelque chose qui est ultra propre à Strapi. Ça veut aussi dire qu'il y a aussi un système d'authentification qui vient dedans, donc c'est là que Strapi est quand même plus qu'un CMS, on est toujours un petit peu entre un CMS et un backend framework, on se considère comme un CMS mais en réalité de par les possibilités de personnalisation de Strapi, on se rapproche du framework il y a aussi tout un système d'authentification. D'authentification donc d'authentification en français des utilisateurs donc ça permet de créer aussi plus qu'un site web mais carrément un back-end pour un produit SaaS il y a tout un système d'upload aussi avec des connecteurs pour que les fichiers, quand tu les uploades dans ton Strapi ils partent soit sur ton S3 mais ça peut peut-être être un Cloudinary enfin n'importe quel storage provider donc il y a vraiment toute cette flexibilité par, ce qu'on appelle les providers qui sont un certain type de plugin pour se connecter à des services et configurer le Strapi en fonction. Et après, au niveau de l'architecture, on a une architecture beaucoup par fichier, folder. Donc, c'est vraiment la nature même du framework Strapi de fonctionner comme ça. Et à l'heure de l'AI, on continue de travailler dessus, puisqu'on a une architecture qui a notamment été inspirée de SalesJS en 2015, qui était un framework un peu l'équivalent de Rails pour Node.js, c'est d'ailleurs qu'une seule lettre qui change. Et on s'est inspiré de beaucoup de patterns au niveau de l'architecture, qui était une très bonne architecture il y a 10 ans. Et là à l'heure des LLM pour que d'ailleurs dans les 10 ans on a ajouté TypeScript qui est devenu absolument un essentiel mais qui n'existait pas dans les débuts de ce travail tout simplement on en a vu les prémices. On a évidemment ajouté TypeScript partout mais même dans le framework c'est lui qui va chercher les fichiers et là on est en train de retravailler pour que ce soit vraiment des systèmes d'import à base de SM autant que possible pour que, les LLM s'y retrouvent d'autant plus. La deuxième moitié de cette année est dédiée à ça, c'est vraiment de faire Strapi AI ready et c'est évidemment ajouter des skills, d'être encore meilleur sur le CLI, on vient de sortir notre MCP, mais surtout au niveau du code puisque Strapi est installé en local, il faut que les coding agents soient extrêmement bons à, faire du Strapi et là on se pose même la question de le faire renner au sein que l'application front-end, puisque quand tu crées un site avec React, NXJS et autres, si tu y ajoutes un CMS le LLM s'il doit, avoir le CMS dans un autre dossier en structure monoripo, il saura faire mais ça lui demande quand même un petit peu plus d'effort et donc là on continue en train de travailler sur ça en fait notre nouveau persona n'est même plus le développeur, mais le coding agent, donc on vise les développeurs, clairement le meilleur CMS pour les développeurs mais on a aussi très conscience que derrière les coding agents, il va falloir faciliter la vie, entre guillemets on peut utiliser le mot vie pour des agents, Et c'est aussi qu'ils sont aussi très bons pour recommander telle ou telle solution. Donc on doit faire quelque chose qui est excellent pour...
Bruno:
Alors avant de partir effectivement sur les changements du métier et toute cette partie de AI, j'ai une dernière question du coup sur Strapi, parce que tu as évoqué effectivement le cas de TypeScript qui est arrivé un peu plus tardivement, je crois que TypeScript c'est 2017 ou 2018 je crois.
Pierre:
Dans ce zone-là de venir. Oui, c'est ça.
Bruno:
Parce qu'effectivement vous êtes arrivé à un moment où l'écosystème JavaScript était en train d'exploser.
Pierre:
Oui.
Bruno:
Il y a effectivement beaucoup de choses qui sont arrivées après oui vous vous avez quand même du succès depuis assez longtemps oui, mais tu vois comment est-ce que tu gères pour que notamment le passage à Tabscript, ce qui est quand même un changement fondamental ne soit pas non plus trop un break in change pour pas que toute ta communauté se retrouve à devoir, tout réécrire parce qu'en fait le GeraStript a quand même beaucoup changé en un peu plus de 10 ans oui il a fallu suivre ça sans non plus casser tout ce qui avait été fait avant.
Pierre:
Exactement et c'est très dur de maintenir un projet open source au fur et à mesure des années, encore plus quand il s'adresse aux développeurs, c'est-à-dire que si tu fais un CRM open source au final ce qu'il y a dans le code c'est peut-être un petit peu moins important Strapi, il est fait pour les développeurs donc vraiment on a toujours fait en sorte d'être autant à la page que possible sur tous ces éléments-là. Il y a des exemples plus faciles que d'autres, GraphQL par exemple est arrivé au milieu de toutes ces années-là, GraphQL, trop cool, ça a plein d'inconvénients, l'usage je pense qu'il a quand même pas mal diminué récemment mais quand il est sorti dans un usage CMS il faisait assez sens c'est à dire que je veux tous mes articles et pour chaque article dans ma vue liste je veux le titre, la description mais pas tout le contenu il n'y a pas de raison de récupérer tout le contenu par contre je veux l'auteur je veux juste son nom puis son ID pour faire le système de routing par exemple donc, ça GraphQL par exemple on l'a ajouté en plugin et on a été super tôt sur le sujet vraiment on a vu GraphQL arriver on s'est dit ok c'est cool on va faire un truc pour les devs on y va, génial TypeScript plus compliqué puisqu'on parlait vraiment de l'intégralité du corps de Strapin, des milliers et des milliers de lignes de code fait en javascript et TypeScript arrive et donc en fait on a dû, aller très très vite dessus quand même puisque c'est un élément essentiel et c'était de plus en plus demandé par la communauté et. Je ne sais plus si c'est précisément pour cette raison ou pas qu'on a amené Strapi 4. Le temps passe mais je ne sais plus exactement mais en tout cas typiquement on a dû faire des breaking changes, donc on est maintenant à Strapi 5 donc il y a quand même plusieurs versions majeures et donc qui dit version majeure dit breaking changes donc que ce soit pour Tripscript ou d'autres sujets les breaking changes, c'est douloureux C'est douloureux puisque en tant que dev, ça veut dire qu'on va devoir passer du temps à changer quelque chose pour quelque chose qui peut-être dans le très très court terme n'ajoute pas forcément de valeur. Si je te dis en fait si tu veux utiliser la nouvelle version de Strapi, il faut que tu réécrives ton projet en TypeScript, tu vas peut-être me dire non c'est un projet qui est plus tant maintenu que ça etc. Donc ce projet là si un jour il est refait potentiellement tu donnes l'opportunité aux gens de prendre une autre technologie c'est un risque, c'est pas un upgrade qui est simple, et par exemple quand on a sorti Strapi 4 après Strapi 3 on l'a fait un peu dans la précipitation et je suis pas pour rien, on voulait lever notre CRIB à ce moment là et on s'est dit faut qu'on fasse du bruit, faut qu'on montre que Strapi 4 c'est révolutionnaire pour aller lever, ça a marché on a sorti Strapi 4 vite, Et trop vite. Et après on a réussi à lever une super série B. Génial. Le problème c'est qu'on a un peu frustré la communauté à ce moment là. Et on le sent encore. On le sent encore parfois. Les gens se sont dit ah non mon upgrade de Strapi 3 à Strapi 4 c'était pas prêt, c'était pas stable, il n'y avait pas la documentation, il n'y avait pas les codes modes, il n'y avait pas tous ces éléments là. Et donc, on a payé le prix cher. Et donc, on s'est dit, OK, plus jamais. On sait que maintenant, quand on fait une nouvelle version majeure, on fait extrêmement attention à ce qu'on fait. Les gens s'assurent qu'on fait des breaking changes pour des raisons qui sont extrêmement valides et qu'on ne peut vraiment pas passer autour quitte à ne pas savoir quelque chose. Mais typiquement, TypeScript, c'est hors de question de passer à côté. Ce n'est juste pas le choix. Et encore plus à l'heure des LLM, parce qu'ils font du JavaScript. Ils sont à l'aveugle, comme on l'était en tant que dev. et c'est pour ça que TypeScript est trop bien. Donc quand on a sorti Strapi 5, on s'est dit, ok, on va pas faire la même erreur. On va prendre le temps qu'il faudra et on a aussi une boîte derrière le projet open source, donc on a aussi une volonté de faire croire notre revenu, de sortir les choses vite, etc. Mais il faut vraiment que ce soit pour les users first et pas retomber dans le schéma dans lequel on était allé en 2021-2022 quand on a sorti Strapi 4. Et donc on a énormément travaillé sur cette version-là, on a laissé beaucoup plus de temps aux ingénieurs on a, fait toute la documentation on a fait des guides de migration on a aussi toute une phase de bêta où la communauté a progressivement à leur risque commencé à upgrader sur la bêta donc on a, fixé énormément de choses dans cette transition là et au moment où on s'est dit ok c'est bon, là on sent qu'on est prêt on a fait le lancement de Strapi 5 et ça a été beaucoup plus fluide et, là ça s'est beaucoup mieux passé et si bien que là, on est dans une phase où Strapi 5, on va le passer en LTS donc en Long Term Support on consolide vraiment pour rassurer créer une très forte confiance avec la communauté, on peut le faire aussi parce qu'on a créé des bringing changes dans le passé qui font qu'on ait une fondation méga solide au niveau du produit.
Bruno:
Tu as évoqué tout à l'heure l'arrivée des Coding Agents, je l'évoque un petit peu en intro, comment est-ce qu'on fait pour garder la notion de CMS encore valide en 2026, quand effectivement avec CloudCode, j'exagère, mais dans deux lignes de prompt, je peux lui demander de me générer un site complet avec, tout ce que je veux, aussi bien côté front que côté back ?
Pierre:
Bien sûr, j'espère que c'est bien comme ça que tu vas générer tes prochains sites. Donc oui, ça change. Et comme je le disais tout à l'heure, il y a dix ans, c'était que le contenu soit géré sur du mobile et AppMobile, pas juste une version responsive d'un site. Il y a l'arrivée des frameworks fontaines et il y a l'arrivée de Node.js. Révolution. Et c'est là qu'on est arrivé. Et là, dix ans après, révolution. La manière de créer un site, elle a complètement changé. En tant que dev, on passe par du coding agent et même les personnes non techniques, elles vont faire du vibe coding. Elles vont pas aller faire du clic-clic-clic sur des website builder. C'est vraiment cet effet waouh de se dire je prompte et j'obtiens quelque chose qui est avec le design que j'ai demandé et avec un contenu qui est complètement cohérent avec le site que je suis en train de faire. Je suis en train de faire un site pour le club de tennis du coin, je vais avoir un truc qui fait complètement sens. Evidemment, s'il y a des choses que l'LM ne va pas savoir et je vais le guider, mais c'est comme si je vais voir une agence et je lui dis, crée-moi un site pour mon club de tennis. Ok. Il y a 10 ans, l'agence, elle aura mis quelques semaines. Voilà, ça manque d'informations. En fait, tu peux t'en prendre qu'à toi-même. Donc, les coding agents sont beaucoup mieux que les website builders pour ça. Commencer avec un template ça fait beaucoup moins de sens qu'avant puisque le prompt devient le template donc oui, c'est la bonne manière de faire et n'importe qui qui n'utilise pas ces outils-là je vous conseillerais de le faire, voilà donc maintenant on se pose la question du contenu ces coding agents quand ils vont créer un site que ce soit avec de l'AI coding donc cloud code, codex, etc ou du vibe coding donc les plateformes qui sont plutôt en ligne et bien, le coding agent va écrire tout le contenu soit dans des fichiers markdown, soit dans des composants React. En gros, ce sont les deux emplacements pour gérer ce contenu-là. Au sein d'un composant React, tu auras peut-être un petit objet ou arrêt JavaScript, TypeScript, c'est ce qu'on a dit avant. Mais vraiment, c'est là que ça va se passer. Et donc, c'est génial. Le LLM, il a tout le contexte à porter de main. On arrête de personnifier ces agents. Mais vraiment, ils savent très bien gérer ça. Il y a eu pas mal de postes sur X, sur LinkedIn, le CMS est mort, etc. Et comme on l'a connu, je pense qu'il est mort, je pense qu'il doit changer et il est en train de changer et évidemment on y travaille.
Bruno:
Alors du coup vous y travaillez comment ? C'est quoi la réponse de Strapi à ce changement de paradigme ?
Pierre:
Alors il y a deux choses, la première c'est Strapi, donc Strapi on est en train de faire trois choses différentes dedans, on le fait AI ready, AI recommended et AI native. Donc AI ready c'est ce que je disais c'est vraiment pour les coding agents, c'est notamment parce que Strapi est vraiment inclus dans cette phase de code en local, En fait, on fait tout pour que les lames puissent l'installer super facilement, puissent configurer la structure de contenu, qui est déjà basée sur des fichiers dans Strapi, donc ça facilite beaucoup les choses, et puissent connecter les composants front avec les composants back. Enfin, dans Strapi, il y a un système de composants pour refléter les composants front. Donc, il faut qu'on facilite la vie des agents pour qu'ils puissent installer, configurer, manipuler Strapi super facilement. Donc c'est des skills TypeScript encore plus solide des changements vraiment, au sein du corps de Strapini alors.
Bruno:
Attends parce que du coup là tu as évoqué un truc que je trouve hyper intéressant parce que j'en ai parlé il y a je crois quelques mois où j'ai eu quelques contributeurs aussi du monde Java open source où j'ai posé cette question là de est-ce qu'on va commencer à faire des projets open source qui embarquent leurs propres skills, et ils me disaient oui effectivement ça va commencer à popper mais c'est pas encore partout et toi, tu t'entends dire chez Strapi, c'est que maintenant vous avez des skills dans le projet pour les LLM.
Pierre:
Et à plusieurs niveaux, mais les skills sont indispensables, donc elles sont à plusieurs niveaux, quand tu génères un projet Strapi, Les skills, elles vont être du coup au niveau de ton projet. Donc, le LLM va savoir, ok, je viens de mettre Strapi, c'est comme ça que je l'utilise. Trop bien. Donc, les skills sont vraiment essentiels. Et on va pouvoir expliquer comment déployer Strapi, comment le connecter si le projet Frontier est un XJS ou un Astro ou quoi que ce soit. Donc, clairement, les skills, elles sont absolument indispensables. Et donc, on les fait pour les end-users. C'est la priorité. Mais on le fait aussi pour les contributeurs. Strapi, c'est un projet open source. Et donc on reçoit plus de contributions que jamais à l'heure des coding agents, c'est un gros problème enfin une force et un problème de projet open source à l'heure actuelle c'est qu'on est floudé par énormément de pull requests énormément de security vulnerabilities reports aussi, parce que il y a des gens qui disent j'ai trouvé telle faille et les coding agents permettent de le faire, il y a aussi beaucoup de fausses positives sur ces sujets là donc nous ça nous prend beaucoup de bandes passantes il y a des projets par exemple comme cal.com qui est un projet, de scheduling, donc c'est un peu comme un calendrier où tu choisis un slot dans un calendrier, et bien ils ont décidé d'aller en closed source parce qu'ils n'en pouvaient plus de, gérer ces failles de sécurité dont certaines étaient vraies, ils ont le produit en SaaS, donc il y a des vrais sujets sur ça. Mais nous ça nous permet de sécuriser d'autant plus le projet ce que les projets en SaaS n'ont pas. Et donc ce que je voulais dire c'est qu'au niveau des skills donc pour tous les contributeurs qui incluent notre équipe d'engineers en interne puisqu'on se considère nous même comme les contributeurs enfin des contributeurs et donc, pour améliorer la qualité des pull requests qu'on reçoit et bien il n'y a rien de tel que de donner les bonnes skills aux coding agents des contributeurs et on va s'assurer que, ces coding agents ils suivent les guidelines dont on rêve et que, Tous les contributeurs historiques ne suivez pas nécessairement. Parce que là, on peut donner à l'intelligence les règles et s'assurer, entre guillemets, que ça va être suivi. Ce ne sera pas toujours suivi, il est l'élément à la limite. Voilà. Donc, non, les skills sont absolument essentiels. Et pour rester à peine sur le sujet des contributions. On va continuer à itérer sur notre agent qui review les pull requests, les pull requests qu'on reçoit de la communauté. On en a tellement qu'il faut qu'il y ait un agent qui passe avant qui review, on a tout fait avec l'Aude mais maintenant il y a des solutions qui sont vraiment dédiées, à ça, donc voilà, clairement, ça c'est tout le sujet AI ready, ensuite il y a le sujet AI recommended, donc c'est s'assurer que les, tu dis que tu es dans un projet React, tu vois un CMS que ce soit Strapi qui sorte de la liste à ce moment là, puisque c'est beaucoup comme ça que les décisions sont prises, et je pense qu'en tant que dev, ben, ah tiens il me faut une libre pour ça ça, tu vas pas aller sur NPM ou autre, tu vas potentiellement prendre la libre qu'il te dit, et potentiellement il en aura déjà pris une, et tu t'auras même pas dit il sera pas au courant, mais. C'est pour ça qu'il y a des librairies comme Tailwind ChatCN, etc dans l'écosystème front en tout cas qui décolle très fort et le troisième point c'est AI native, donc Strapi est un CMS donc il y a toute la partie API, toute la partie user interface où les gens vont aller mettre un nouvel article de blog etc, et donc on a déjà ajouté des fonctionnalités AI par exemple l'AI content builder pour définir la structure du contenu même si ça a vocation à être fait par les coding agents, mais on a surtout l'AI Media Library donc si tu peux donner un asset on va te donner la description par exemple de l'image d'un point de vue SEO c'est cette petite balise alt qu'on a tous un peu la flemme de remplir, et puis on a ajouté aussi l'AI Translation donc si tu écris un article de blog en français on va être le traduire dans autant de langues que tu veux voilà donc l'AI est absolument excellente au sein du CMS elle ajoute énormément de valeur, et puis last but not least on a sorti notre MCP récemment et, ça fait que le CMS finalement tu ne vas peut-être pas passer tant de temps que ça dans l'interface d'admin mais le CMS devient complètement agentique et tu vas l'utiliser depuis Cloud ou autre donc pour reprendre un peu un step back sur. L'avenir des CMS, Ils sont morts sur les petits projets. Il n'y en a pas besoin. Si tu es dev et que tu fais ton site pour ton podcast, il n'y en a pas besoin. Retourne dans Cloud Code quand on a besoin. Tu versionnes, tu pousses, tu déploies, c'est fini. Et franchement, quand on a fait le premier site de Strapi, qu'on était trois devs dans l'équipe, notre blog, c'était un fichier JSON. Pas cool pour les blog posts, d'ailleurs. C'est pas séparé. On faisait même pas d'import au début comme on importerait des fichiers Markdown. Mais tu vois, on est passé par là. Et quand tu as fait l'histoire au tout début, t'as parlé fin des années 90 où le contenu il était dans des fichiers et donc le même problème est en train de se recréer c'est à dire que si tu fais un site sérieux important et que tu dis à quelqu'un, enfin tu fais un site pour une équipe marketing pour une grosse boîte pour une vraie équipe marketing qui est pas dans une tech startup où les gens sont méga méga tech mais pour vraiment, une équipe marketing normale et ben ils vont pas forcément passer leur temps dans cloud code à gérer les déploiements à gérer des branches etc, Enfin, nous, il y a plein de choses qui nous paraissent logiques. Les LLM facilitent énormément de choses. Il y a quand même des concepts qu'il faut un peu absorber. Et donc, c'est quand même un petit peu compliqué. Donc, un CMS, il y en a toujours besoin. C'est juste que la définition d'un CMS est un peu en train de changer. Donc, déjà, avec Strapi, avec les trois piliers que j'ai évoqués, à Eredi, à Erecommanded, mais surtout à E-Native, finalement, tu vas déployer ton site. Et donc, tu donnes les clés du site, donc les clés du CMS à l'équipe marketing. Et finalement, ce n'est pas forcément dans l'interface d'admin qu'elle va passer de temps en temps que ça, mais c'est peut-être dans le LLM qui va interagir avec le MCP de Strapi et pour créer du content at scale, c'est créez-moi 10 articles sur le club de tennis, même si on pourrait parler d'une boîte plus sérieuse. Je n'ai rien cru de le tennis, mais pour prendre des exemples plus critiques, créez-moi 10 articles sur les derniers championnats de tennis dans la région ou dans le monde, et ça va pousser tout ça dans Strapi sans que tu aies ouvert l'interface d'admin de Strapi. Et c'est ok, parce qu'en fait, sinon il faut quoi ? Il faut que la personne du club de tennis, qui a autre chose à faire de ces journées que d'installer Claude Côte et compagnie, il faut qu'elle clone le site, qu'elle fasse ses prendres, qu'elle redéploye, un peu compliqué. Donc voilà donc strappy est en train de devenir le premier utilisateur de son mcp alors le premier j'espère pas dans un sens puisque j'ai plus temps que ce soit utilisé à l'extérieur des cloud code extra il devienne un peu ce content agent donc voilà voilà, Donc ça, c'est le premier point. Pour des projets, il y en a toujours besoin, et ça va faciliter énormément la publication de contenu et il y en a besoin encore plus qu'avant du contenu. Le trafic est en train de shifter du SEO au GEO, c'est tout nouveau, on ne sait pas trop comment les LLM font remonter les marques, etc. Tout le monde est en train de perdre en trafic parce que le trafic, ce n'est plus du trafic, mais ce ne sont pas essentiellement des impressions dans des mentions, donc ça devient d'autant plus critique. Là, il y a des budgets qui se débloquent de tous les côtés pour comment est-ce que notre marque a survie à l'âge du LLM.
Bruno:
Et puis surtout après avec votre base côté l'approche très API first, le MCP il expose que des méthodes liées à l'administration du contenu ou est-ce que du coup il peut être aussi consommé, par, si on prend le cas d'Adidas par exemple, par un client d'Adidas qui du coup sur son LLM peut du coup aller choper les infos qui sont sur le site d'Adidas.
Pierre:
Ça c'est une des étapes qu'on va explorer d'ailleurs on a organisé notre Happy Meetup la semaine dernière et il y a une boîte qui a fait précisément ce use case là en fait tout le contenu est géré dans Strapi et ils gèrent les embeddings avec un modèle d'OpenAI et les stores dans Pinecoin. Et après ils ont fait un chat avec un framework, mais en fait toute cette notion d'embedding, nous on a déjà tout le contenu on stocke tout dans du Postgres, donc on va ajouter un PG Vector et automatiquement tu peux sortir un chat parce que ça devient ta, base de données vectorielle et du coup tu peux tout créer dedans donc tu vois c'est jusque là que ça va et je pense que les sites ils doivent devenir beaucoup plus conversationnels qu'ils l'ont été jusqu'à maintenant puisque, le site c'est le cerveau un peu de la boîte d'un point de vue externe, t'as envie d'y mettre tout ce que fait ta boîte, les dernières actualités etc, donc le CMS c'est le cerveau en tout cas qui est customer facing on parle beaucoup de company brain à l'heure actuelle il y a tout ce qui est en interne, nos process en interne, comment on travaille ça c'est l'interne, mais pour l'externe en fait c'est quand on a envie de dire quelque chose au client on le met sur notre site, on veut qu'il trouve une FAQ etc, donc l'agent il a accès à toute cette information là Donc je crois beaucoup aux websites beaucoup plus conversationnels. Et donc ça, c'est côté Strapi et aussi côté Fimo, qui est notre nouveau produit qu'on a sorti en janvier, donc Fimo d'OTI. Donc l'histoire, c'est qu'il y a à peu près un an, on s'est dit la manière de créer un site, c'est clair et net, elle est en train de complètement changer. Ça va être code, ça va être code. Nos devs écrivent de moins en moins de code et encore, on n'en était pas à tout ce qu'il y a en 2026. Ça passe vite. Donc on s'est dit, il faut qu'on se réinvente, il faut qu'on explore des choses. Soit on s'intègre avec ces outils de AI Vibe Culling soit on se dit, ok jusqu'à maintenant on a permis aux devs de créer des sites, quid si on permet à n'importe qui de créer son site. C'est totalement aligné avec la mission de la boîte et donc ce qu'on a fait c'est qu'on a alloué 5 personnes dans notre équipe donc. 3 devs 1 designer et mon cofondateur qui est Chief Product Officer, et donc il y a aussi notre CTO dedans dans les trois devs donc vraiment équipe ultra stratégique et on leur a dit en gros t'as un outil vibe coding, c'est ce marché là qu'on va chercher, il y a un énorme besoin, on va pouvoir permettre à n'importe qui de créer un site et on sait qu'il y a plein d'outils de vibe coding, qui sont disponibles mais il n'y en a aucun qui est spécialisé dans la création de site, c'est à dire qu'il n'y a pas de CMS dedans donc aller gérer des articles de blog à grand coup de prompt c'est quand même pas top à un moment on a aussi envie un peu de pouvoir, édité à la main, mais avec le pouvoir de l'agentic avant, il n'y a pas de librairie de médias pour réutiliser des assets qui ont une cohérence avec la brand, qui peuvent générer des images eux-mêmes, etc. Donc on s'est dit ok, on va shipper ça, et c'est justement ce qu'on a sorti en janvier, et donc Fimo, tel qu'on l'a sorti, c'est un AI et un website builder où tu arrives, tu prends ton site de club de tennis, tu vas pouvoir le faire en deux secondes, et, tu vas donner accès, et ils ont la main dessus automatiquement donc on résout le problème qu'on a évoqué tout à l'heure qui est de ils vont pas installer cloud code etc tout est en ligne les ans le cms s'ils veulent gérer manuellement, les articles de blog mais ils ont aussi le chat pour faire des itérations sur le site si vous de créer une nouvelle section et bien ils vont peut-être pas, revenir à toi pour ajouter une partie faq etc.
Bruno:
C'est un clou de code pour les moldus.
Pierre:
Voilà en ligne en effet mais avec toute la partie cms ce qu'il y a derrière. Et donc on a lancé ça et on a eu des resours incroyables, des gens qui disent j'aurais dépensé je sais pas combien dans une agence, je peux faire ça super facilement. Et puis en fait les agences elles veulent pas de ces projets là parce que c'est des petits projets. Donc c'est pour ça qu'on se considère même pas comme des conférences avec les agences parce qu'en fait les agences elles vont plutôt utiliser notre outil pour shipper ces petits projets facilement. Donc, il y en a eu des super retours et énormément, enfin, des milliers et des milliers d'utilisateurs de sites créés. Et ce dont tu as rendu compte, c'est que pour des projets comme le club de tennis, j'y reviens à nouveau, la personne qui est dans le club de tennis, elle ne sait pas forcément très bien guider ces outils-là. Nous, en tant que dev, on sait ce qui se passe derrière et c'est pour ça que je pense que les devs, ils ont encore un très bel avenir. Donc, ces gens, ils ne sont pas très bons à guider les LLM. Leur site, il n'est pas si critique que ça. bon le club s'il n'a pas son site, tant pis ils feront peut-être une page Facebook, et voilà et surtout il y a peu de budget derrière et à l'inverse on s'est dit, ça fait 10 ans qu'on bosse pour les devs on les connait super bien ils sont en train de tout se passer sur cloud code codex et en fait c'est eux qui se prennent de ce mur là ils ont créé leur truc, ils n'utiliseront jamais un Fimo dans un premier temps en tout cas tel que Fimo a été jusque maintenant puisqu'ils veulent pouvoir. Utiliser leur workflow habituel. Ils veulent utiliser leur coding agent, que ce soit CloudCode, CodeX, OpenCode ou autre. Ils veulent utiliser leur propre front-end framework si tu as envie de faire du Next, du Astro, du Tan, du TanStackTart, etc. Et puis. Voilà, ils ont envie d'utiliser leurs outils habituels. Et donc, on s'est dit, comment est-ce que ces projets-là, qui ont été développés en local, Au moment où ils se prennent le mur de « Oh, il faut que je donne accès au club de tennis ou à ma super grande équipe marketing », on va rendre ce projet complètement éditable. Et donc FIMO, c'est pour ça qu'on vient de complètement le transformer. FIMO, c'est vraiment le Website Operating System. C'est-à-dire que tu crées un projet avec Cloud Code, tu ajoutes FIMO au sein du projet. Et en fait, FIMO va absorber tout le contenu qui est dans des fichiers Markdown, des React Components. Et il va le rendre complètement éditable. C'est-à-dire que tout le contenu qui est en local dans le projet, il remonte au niveau de l'API FIMO. Donc il est accessible, que ça run en local ou que ça run au sein de FIMO. Et donc il y a toute une partie, enfin CMS, librairie de médias, inline editing, pour que les personnes non techniques ensuite prennent la main une fois que c'est déployé au sein de FIMO. Tout est versionné via Git, donc on a un système de sandbox au sein de FIMO. donc ça veut dire que. Les personnes non techniques vont faire l'édit et vont prendre la main sur le projet, je pourrais parler un peu des détails techniques un peu comme on a construit ça et puis il y a un chat aussi donc ça veut dire que la personne du club de tennis va dire ajoute moi la liste des personnes du club et donc ça va ajouter des photos dans le CMS ça va configurer, team player et il va y avoir la liste des team players donc ils vont pouvoir aussi ajouter à la main le contenu qui a été généré initialement par les high sans faire appel au dev. Donc ce qui est super fort aussi c'est que toute la partie chat elle utilise toutes les skills qui ont été générées par les développeurs en local. Donc si t'étais le développeur freelance du projet et bien t'aurais mis toutes les skills, t'aurais mis, aussi un design MD par exemple pour que le LLM que ce soit le tien ou celui de Fimo et bien crée du design de manière très homogène et cohérente. C'est à dire que quand même le client du coup va continuer d'itérer avec un design qui est cohérent alors ça veut aussi dire qu'on lui permet de tout faire au client, on va aussi ajouter un petit peu des règles puisqu'on sait aussi qu'en tant que dev on ne veut pas forcément que le client puisse faire tout et n'importe quoi, et c'est pour ça que la CMS d'ailleurs était très bien, c'est que ils permettent de gérer uniquement le contenu et pas le design, donc tout ça ça va être réglable au fur et à mesure qu'on avance mais on a préféré ouvrir les portes très larges pour montrer tout le potentiel qu'il y a derrière, et donc voilà on rend tout ça éditable. Mais ça, c'est que le début.
Bruno:
Je me permets juste parce que au début quand tu commençais à décrire Fimo, moi je me suis dit bon ok a priori c'est une offre en SaaS, c'est à dire que du coup on va sur le site et en fait on crée notre site et il est hébergé dans votre SaaS et compagnie mais là du coup tout ce que tu viens de nous dire, en fait ça te génère un vrai site en tapstreet que du coup tu peux déployer où tu veux, comme tu veux et que du coup tu peux versionner et que tu peux donc sortir après entre guillemets de Fimo et recommencer à bosser à la main à l'ancienne.
Pierre:
Tout à fait donc avec Fimo on propose l'hébergement c'est inclus comme ça par défaut il n'y a pas à prendre une autre solution mais si tu as envie d'utiliser un cloud provider en particulier c'est possible, le code il reste versionné donc.
Bruno:
Nous on.
Pierre:
Se connecte avec le repo GitHub et on s'acquenise tout.
Bruno:
Et toute cette partie du coup de génération automatique la génération de contenu bon je peux imaginer mais du coup la génération de code qu'on peut faire dans Fimo, tu passes par un LLM qui est dans FIMO ou du coup c'est des abonnés où tu peux mettre ton LLM à toi ? Enfin comment ça se...
Pierre:
À l'heure actuelle c'est nous qui avons le LLM donc on a un système de crédit et là aussi enfin ce qu'on a aussi voulu faire en permettant cette phase de local c'est que, tu gères la plus grosse partie de la consumption de tokens elle est dans ton cloud code dans ton codex etc donc tu gardes aussi le contrôle le contrôle sur cette partie là sachant que c'est souvent les premiers promptes qui sont les plus, les plus gourmands clairement ensuite une fois que, ça tourne dans FIMO les promptes qui vont être faites au sein de FIMO ils sont faits via les modèles qu'on utilise auxquels on a souscrit, pour les clients FIMO donc il y a un système de crédit etc, mais on assume aussi qu'avec cette approche là on va vendre beaucoup moins de crédit et c'est ok parce qu'on laisse les développeurs utiliser des tokens en local maintenant est-ce que plus tard il y aura la possibilité de bring your own LLM et tu mets, tes propres API tokens d'un modèle cloud, open AI ou autre, on y viendra sûrement.
Bruno:
Si j'ai bien compris le concept de Fimo, c'est que ça va me permettre, notamment à moi en tant que développeur, de mettre à disposition de mon client, au final un équivalent d'un cloud code, où du coup il va pouvoir gérer son site comme il veut. Mais je peux du coup aussi y mettre mes propres skills et mes propres instructions pour que mon client fasse pas n'importe quoi et tu rajoutes à ça toute une sécurité que vous vous faites pour s'assurer que le client n'aille pas non plus péter tout le site d'authentification ou ce genre de choses Exactement.
Pierre:
Tout à fait et ça c'est qu'une partie du sujet le vrai parti du sujet c'est l'autonomie des sites et les agents, ma grande croyance c'est qu'on a commencé en 2022 avec JGPT 3, avec du chat donc c'est du read only, tu poses une question on te donne une réponse, génial, incroyable je continue d'être absolument impressionné par cette technologie, mais c'est vraiment cette question de je donne un prompt, j'obtiens une information je remets un prompt, j'obtiens une autre information, je pose des questions, la deuxième étape dans laquelle on est plus qu'entré, c'est que l'EI fait des choses et donc on a vu des OpenClo, Hermès. Cloud Cowork etc. Faire des choses donc on leur donne on crée des agents on leur donne des tools, on leur donne des skills on leur donne des MCPs et ça fait que un agent on peut lui dire je veux que, tu ailles lire mes derniers emails dans Gmail tu supprimes ceux qui ne sont pas pertinents tu trafes une réponse pour les nouveaux etc. Ça, c'est le deuxième stade, qui est énorme, incroyable. Gains de productivité phénoménaux. Et le troisième point, c'est l'autonomie. Les agents vont travailler pour nous, en permanence, soit des fréquences très régulières, ou déclenchées par rapport à certains événements. Et donc, ce principe d'autonomie, il va aller non seulement que l'agent se déclenche lui-même, mais surtout, il prend des décisions. Peut-être pas toutes, il faut lui dire ce qu'il peut prendre, ce qu'il ne peut pas prendre. Et donc en fait la vraie vision de Fimo au-delà du côté éditable qu'on a évoqué c'est l'autonomous website. Donc quand t'as un local en tant que dev tu vas sûrement créer un agent, une skill ou un agent SEO et ton SEO agent il va vérifier tout ton site que niveau lighthouse score etc c'est parfait. A chaque fois que tu fais une modif ou un pré-commit ou whatever ton agent il va vérifier tout ça génial. Il va générer un report et puis il va dire ah ça c'est bien, c'est pas bien est-ce que tu veux que je le fixe etc Tu vas peut-être aussi créer un agent, un content agent, quand tu vas lui dire en cloud code, en local, quand tu crées un article de blog, je veux que la structure soit ça, je veux que tu mentionnes bien l'auteur, je veux que tu crées des links. Des liens avec les autres entrées parce que c'est bien pour mon maillage interne sur mon site. Donc tu vas aller loin en tant que dev dans tes skills, mais une fois que tu as déployé. Tes personnes au marketing, elles ne peuvent pas s'en servir. Il faut qu'elles reviennent à toi et qu'elles te disent « Bruno, tu peux écrire un nouvel article ? Comme ça, tu vas utiliser la structure que tu avais fait avant. » Et donc, c'est vraiment cette idée-là avec les agents. Je suis désolé. Vas-y, vas-y.
Bruno:
J'ai un problème de caméra qui s'est éteinte en plein live. C'est bon, c'est revenu. Excuse-moi, je suis désolé.
Pierre:
Pas de souci.
Bruno:
Tu nous parlais du coup du fait que les équipes marketing peuvent pas utiliser ces agents qu'on a créés Exactement.
Pierre:
Et donc en fait, une fois que tu as déployé ton projet sur Fimo, tous les agents que tu as créés en local, ils se mettent à runner au sein de Fimo que tu leur as donné une fréquence ou que tu peux les trigger de manière manuelle et ils vont acter sur ton site. Et donc par exemple, si tu runnes l'agent SEO toutes les semaines, il va te sortir un report il va dire là en fait il te manque un metatitle et puis là je trouve que tu aurais pu utiliser un wording qui était un peu mieux à ce niveau là et d'ailleurs je t'ai fait toutes les suggestions, que ce soit au niveau de ton contenu que ce soit au niveau du code je t'ai amélioré les perfs là je t'ai changé ton contenu ici et donc tu as une sorte de méga pull request qui arrive tu peux l'accepter, Et donc, l'objectif aussi, c'est qu'on donne plus ou moins d'autonomie à ces agents-là. Sur des sujets où il y a un risque au niveau de la sécurité, c'est « no ». Je veux un « human in the loop » et que ce soit validé. Mais à l'inverse, sur un sujet SEO où il va y avoir des modifications relativement mineures sur le code, où on ne change pas le sens du contenu. Le but d'un site c'est d'avoir de la visibilité. Donc laissons les agents aller chercher les optimisations, découvrir que la France a gagné tel match de la coupe du monde. Et donc peut-être que si on a un site, c'est peut-être pas le club de tennis mais c'est peut-être le club de foot, l'agent va dire, c'est bon, j'ai déjà publié un article et le lendemain, ton site il a ranqué, grâce à ça et à certains endroits il y aura des Humanity Loops, à d'autres non mais on pense vraiment que c'est cette version d'autonomie des websites qui va faire toute la différence.
Bruno:
Donc en fait, t'es en train de rendre, Parce qu'on commence de plus en plus à parler du harness engineering. Le fait d'avoir effectivement des agents qui codent tout ça des trucs. Tu rends tout ce truc-là, qui est en train d'émerger, accessible au final à des équipes marketing et communication.
Pierre:
Exactement. On a un temps d'avance, on a la chance d'avoir un temps d'avance en tant qu'enginéristique. Parce que du coup, toutes ces notions, elles arrivent. Mais pense à toutes les verticales. Les avocats, les marketeux.
Bruno:
Je peux me permettre, je vais poser une question. alors du coup on est sur la fin mais, je sais pas si vous avez une tendance pathologique chez Strapi parce que tu crées un CMS dans un contexte javascript qui est en train d'exploser, donc avec tout un tas de frameworks qui sont en train d'apparaître, des paradigmes qui sont pas encore là donc tu crées un truc dans un contexte qui est en pleine mouvance, attends il y a eu un autre truc que vous avez fait, le passage sur TypeScript vous l'avez fait alors que TypeScript était encore un peu frais, et là le harness engineering qui est un truc qui est en train d'émerger où la peinture est pas encore sèche la poussière est pas encore retombée, on sait pas encore trop vraiment ce que c'est, il y a encore plein de gens qui se posent la question de est-ce que c'est quelque chose de réel ou pas que vous, vous l'appliquez déjà pour le donner aux gens, est-ce que vous avez une pathologie, à essayer de prendre des paris techniques bien sûr mais il faut.
Pierre:
On est un peu désénervé, il faut prendre des risques je pense que dans un monde où tout va si vite il faut oser, il faut se dire ok, il y a des paris qui fonctionneront, il y en a qui ne fonctionneront pas. On a été à jour sur GraphQL, on l'a sorti super tôt. Bon, il se trouve que c'est moins populaire que ça l'a été, et c'est OK. Et demain, ce sera autre chose.
Bruno:
D'ailleurs, ça, je suis étonné. Pourquoi tu dis que le GraphQL est moins populaire qu'avant ? Parce que moi, en tout cas, je n'ai pas perçu cette baisse de...
Pierre:
OK. Pour les sites, en tout cas, c'est peut-être aussi qu'on a développé un query language dans le SDK qui est super poussé, qui permet de faire beaucoup de choses. J'ai l'impression qu'on le voit un petit peu moins. Mais peut-être que c'est un biais.
Bruno:
Après, tu as peut-être un peu plus le doigt sur ces sujets-là que moi.
Pierre:
Ou l'inverse, mais il faudrait regarder. Je serais curieux de savoir. On se recontactera après.
Bruno:
Canon, merci beaucoup, Pierre, pour tout ça. C'était passionnant. J'ai deux dernières questions pour toi, qui sont les questions rituelles du podcast la première c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditeuristes.
Pierre:
Ouais je vais partager un contenu que j'ai pas regardé.
Bruno:
J'ai le droit ou pas ?
Pierre:
Vas-y ok la semaine dernière j'étais à React Meet Amsterdam et il y a le créateur de la chaîne YouTube Javascript Mastery, qui a publié une vidéo qui doit durer 4 heures sur le AI coding in 2026 et vraiment c'est comment, en tant que développeur enfin on s'assure qu'on prend les bons workflows Parce que je pense qu'il y en a beaucoup d'entre nous qui sont un peu perdus, il y a à boire et à manger, il y a énormément de contenu de tous les côtés. Et je pense que justement il faut réussir à prendre ce temps pour se former mais on ne veut pas non plus avoir trop de bruit un petit peu dans ce qu'on apprend. Et j'ai l'impression, j'admets que je ne l'ai pas encore regardé mais j'ai prévu de le faire, que cette vidéo synthétise ça extrêmement bien. En tout cas vu son talk, il synthétise vraiment les différents éléments qui sont en train de se passer dans l'écosystème. Et donc, c'est une vidéo que je recommande et que je vais regarder moi-même. Je suis vraiment désolé de recommander quelque chose que je n'ai pas vu.
Bruno:
Non mais canon, on mettra les liens en description, bien évidemment, pour que tout le monde puisse en profiter. Merci beaucoup pour ça. Et la dernière question, qui est la question la plus importante de ce podcast. Pierre, est-ce que tu es plutôt espace ou tabulation ?
Pierre:
Espace, carrément. Et si bien que j'ai prompté à LLM tout à l'heure pour dire c'est quoi qui est utilisé sur le Strapi Strapi repository, j'aurais pu ouvrir la page GitHub, j'ai un peu honte d'avoir fait une requête.
Bruno:
Mais.
Pierre:
Donc oui espace espace.
Bruno:
Merci beaucoup Pierre.
Pierre:
Merci à toi.
Bruno:
Et merci à tous d'avoir suivi cet épisode pari encore fascinant de la part de Strapi, d'offrir le Harness Engineering à tout le monde j'ai même pas encore eu le temps de faire un épisode sur le Harness Engineering et pourtant c'est prévu donc ça devrait arriver prochainement, donc n'hésitez pas à aller checker Strapi si vous voulez tester ou Fimo si vous voulez aussi offrir toute cette puissance là à vos différents clients ou demandeurs, moi comme toujours je vous remercie de partager ce podcast autour de vous, on approche de la fin d'année, très bientôt. La semaine prochaine ce sera le dernier épisode de cette saison avant une série d'épisodes spéciaux je vous en révèle quelques éléments, vous savez l'été j'aime bien faire des. Séquences un peu spéciales, donc là je vous propose 6 épisodes pour parler d'intelligence pas l'intelligence artificielle mais de l'intelligence naturelle l'intelligence originelle, la nôtre on a un épisode, on va parler du test de QI on va parler de l'intelligence créative, de l'intelligence émotionnelle de l'intelligence sociale, de l'intelligence collective et de comment est-ce que le cerveau apprend et mémorise les choses donc vraiment très orienté sur la biologie et la neuropsychologie. Humaine ça va être passionnant, on se retrouvera bien évidemment à la rentrée pour de nouveaux épisodes sur plein de sujets et aussi sur le Harness Engineering parce que j'ai des choses aussi en stock, sur le débat, je vous remercie beaucoup, je vous souhaite une très bonne fin de semaine je vous dis à la semaine prochaine et d'ici là, codez bien.
