 Bonjour, je vais commencer ma conférence. Pour la petite histoire, j'avais pas prévu cette conférence dans mon petit référentiel, mon petit listing. Ça m'a apparu suite à la publication 3 jours avant la délai de ce blog post sur un support français qui parle de WordPress. Et puis, infographie sur notre CMS préféré, assez classique. Et j'ai une tension. Alors nous, ça nous parle particulièrement à BIP, les tensions, c'est quelque chose qu'on apprend à traiter, qu'on apprend effectivement à évacuer. Et je me suis dit, encore une infographie à la gloire de WordPress. En fait, j'ai tout de suite commenté en disant, ok, c'est bien joli, on parle des points forts, mais quelles sont les points faibles. En fait, passer un temps à toujours dire tout est beau, tout est magique. Effectivement, on perd un peu en crédibilité. On peut vous parler de cette conférence. Je me présente très rapidement à Maury Belmer. Ça fait 13 ans que je fais du WordPress. Donc j'ai commencé effectivement tôt cette discipline. Et ça fait 9 ans que j'ai écrit une évance 100% WordPress. Et donc j'ai passé en définitive un temps considérable à pitié, WordPress a effectivement vendre l'agence en partie, mais surtout, vendre le CMS, valoriser le CMS. Et c'est convaincre des grands groupes que c'est effectivement un outil pertinent. Et il se trouve que pour mieux vendre ce CMS, il ne faut pas juste connaître ses forces. C'est bien de savoir que c'est 30% du web, mais ce n'est pas effectivement un argument qui sera toujours recevable. C'est en fait beaucoup plus important de savoir répondre à tous les commentaires de nos clients, de nos prospects sur c'est quoi les faiblesses. Tiens, j'identifie cette faiblesse. Qu'est-ce que vous en pensez à Gens ? Qu'est-ce que vous en pensez vous professionnels ? Donc l'idée, c'est attrait à cette conférence, on verra un petit peu les points forts et on a essayé de traiter, enfin en tout cas, on essaye de traiter chaque point fort. En fait, peut être perçu comme un point faible. Et on a fait effectivement un certain nombre de compétitions face effectivement à des prospects très sceptiques des grands groupes, des personnes qui étaient pro-warpress et c'est pour ça qu'on a été présents, mais aussi des personnes qui étaient un peu anti-warpress. Clairement, vos clients, ils ne seront pas bêtes. Ce n'est pas parce que vous leur faites un argumentaire et que vous leur faites le fameux chiffre de 30% de nombre de plugins qui vont effectivement vous croire en disant, c'est la bonne solution. Face à d'autres prospects, d'autres candidats, en tout cas compétiteurs face à un projet, il y a d'autres agences, ces agences, assez facilement, vont valoriser l'heure CMS, vont aller défendre le fait que Warpress a un certain nombre de défauts, ils vont appuyer dessus. Donc l'idée, effectivement, ce n'est pas juste se focaliser sur les points forts. Les points forts, c'est connaître effectivement fort ces faiblesses et être un peu effectivement objectifs sur les qualités réelles de l'outil. Donc je vais traiter un peu la chose sur l'angle suivant. Chaque force peut être considérée comme un point faible. La force numéro 1, celle qu'on ressort assez souvent et c'est souvent le chiffre qu'on tuit, qu'on aime tuiter, 29, mais non. Le chiffre de 30% du web, ça c'est effectivement un argument clé, on utilise un outil. Si 30% du web effectivement utilise ce CMS, c'est qu'il a des qualités. Et à cet argument là, en fait, on va souvent recevoir objecté le fait que 30% du web, finalement c'est un peu le Windows du CMS. C'est un CMS qui va être exposé en termes de sécurité. C'est un CMS qui va être la cible d'attaque de robots et ainsi de suite. Donc effectivement là où je vais choisir un CMS prépondu très populaire, je vais prendre un risque, je vais vers une surface d'exposition aux attaques qui est plus importante. Et ce chiffre de 30%, voilà, se transforme, se transforme, pardon, vite en un défaut. En l'accune, en fait, ça va être effectivement, entre guillemets, dangereux d'utiliser un CMS aussi populaire car on va effectivement rencontrer les attaques alors qu'on n'a rien demandé potentiellement. La seconde chose, c'est le nombre d'extensions. On se prête à dire effectivement dans l'écosystème, il y a un très grand nombre d'extensions. C'est le cas. Ensuite, quand on cherche et quand on gratte un peu ce nombre d'extensions, effectivement il semble important, il répond à de grands nombres de besoins. Mais la qualité des extensions, le rythme de mise à jour des extensions, tout effectivement le travail qu'on peut faire sur l'audit quand on choisit une extension rend en fait la tâche vraiment périlleuse. Pour un acteur qui veut commencer à faire du represse, ok, 60 000 extensions, lesquelles sont pertinentes, lesquelles ne sont pas pertinentes. C'est effectivement un casse-tête au quotidien. Et beaucoup d'extensions sont publiées, mis à jour pendant 6 mois. Ensuite, l'auteur change d'agence, de carrière et le plugin est abodonné. Si vous basez effectivement un projet sur un plugin qui disparaît, ou en tout cas qui n'est plus maintenu, c'est compliqué effectivement en termes de maintenance. La question aussi des éditeurs. On est souvent confrontés à, au represse, comptent des éditeurs propriétaires, des éditeurs, même open source. Et c'est rassurant, on peut se dire, d'ailleurs, d'après un projet open source, il y a quand même une société automatique qui est quand même pas très loin derrière le CMS. 500, 600 personnes, c'est plutôt rassurant qu'on trahique des grands groupes. Mais quand on trahique des petits plugins, prenant ACF, on connaît tous un petit peu Eliott, le fondateur de ce fabuleux plugin. Mais quelle est la taille de sa boîte ? Est-ce qu'elle vit bien ? Est-ce qu'il publie des indications claires sur ses résultats ? En fait, on n'en sait rien. Peut-être que du jour au lendemain, Eliott va cesser de faire ce plugin. Et il y a une vraie incertitude derrière chaque plugin sur les capacités financières, les capacités économiques de l'éditeur à maintenir sur du lendemain les extensions. Et donc c'est un vrai challenge de finalement, de retenir une extension quand on vise à des projets qui seront effectivement exploités 3, 4, 5 ans. Quand on travaille effectivement avec des grands comptes, quand on veut travailler avec des grosses acteurs, le choix l'outil, c'est un choix qui s'est effectivement sur du long terme. Donc il ne faut pas se planter et c'est effectivement une vraie difficulté à sélectionner les bons éditeurs. On parle souvent d'une couple d'apprentissage facile. Ou après, on peut faire des thèmes simplement. C'est effectivement l'argument qu'on ressort récemment. D'ailleurs, tous ces arguments, je les retrouve dans un bon nombre d'infographies qu'on peut effectivement trouver dans l'écosystème. Effectivement, on peut créer facilement des thèmes. Il y a la loupe à pays, les templates tags. Il y a un certain nombre de ressources qui existent sur le sujet. Mais on peut aussi effectivement vite être confronté au commentaire suivant. Oui, mais dans votre émoire presse, vous avez du PHP et du HTML. Comment on fait ? Est-ce qu'il n'y a pas un moteur de templateing ? Ce sont les arguments qui sont opposés. Dans beaucoup d'autres CMS, vous avez du Tui, du Smartie, un certain nombre d'autres, effectivement, de template. Il y a une vraie interrogation sur pourquoi, dans ce CMS si populaire, il n'y a pas eu cette distinction entre je fais un thème, je fais du PHP et je fais un autre métier qui est l'intégration. Et donc, ces particularités propres à ce CMS, nous, on envoie des qualités parce qu'effectivement, faire un thème, ça nous paraît facile pour un grand groupe qui a l'habitude de faire de telle ou telle façon d'un côté un thérateur HTML, de côté développeur au sein du CMS. C'est vrai que ça peut être compliqué effectivement de faire le liant. WordPress, c'est aussi une très belle interface d'admins. On se prête à dire que c'est la plus ergonomique du marché, qu'elle est ultra pratique à l'usage. C'est vrai, prenant à WordPress, sorti d'usines, de trois types de contenus, ça fonctionne bien. Methesi Yoast, vous avez déjà un peu un certain nombre de blocs en plus, ajoutez un plugin de JSON Workflow, Editflow, mettez un peu des fonctionnalités diverses. Et finalement, on va vous retrouver quand même avec un CMS qui est assez lourd. Donc ça, avec en termes de qualité d'interface, c'est intéressant, mais on peut vite être pollué par les notifications, les publicités. Donc l'interface de WordPress, elle a beaucoup de qualité, mais elle peut aussi vite être très polluée en fait avec les plugins. Et j'ai eu droit à des super contre-démonstrations, un client qui me montre un projet WordPress dans son groupe avec toutes les extensions qu'on apprécie un peu moins, du WPML, un certain nombre de choses. Et finalement, on se rend compte qu'effectivement, l'interface de WordPress est pas si simple que ça à comprendre une fois qu'on y a mis toutes les fonctionnalités attendues. Il y a la richesse d'Etem Premium, ou après c'est un projet effectivement avec un écosystème très large. Il y a plus de 5 à 10 000, enfin, un Temp Premium, pardon. Et à travers ce Temp Premium, en fait, on va partouver une expérience. Chaque Temp Premium, c'est un peu une nouvelle aventure. On va retrouver un back-office un peu différent, des fonctionnalités différentes. Et finalement, quand on veut déployer WordPress au sein d'une organisation avec plein de projets, si on fait le choix du Temp Premium et qu'on choisit 2, 3, 4 Temp Premium, en fait, il faut tout reprendre à chaque fois, il faut tout refaire à chaque fois. Les back-office, le page builder peut être différent et ainsi de suite. Alors je ne reste même pas la qualité intracec, mais effectivement, en termes d'usage, on fait du WordPress, mais on ne fait pas que du WordPress, on fait du WordPress plus un Temp Premium avec des particularités. Et c'est effectivement difficile à propager, voilà, un Temp, deux Temps, trois Temps. Au bout d'un moment, c'est difficile, effectivement, en termes de maintenabilité. La gestion des médias, effectivement, on peut envoyer tout à l'heure des mots, prendre des médias, envoyer dans l'interface, directement dans l'article, on va represse le fait déjà, il s'est encore plus joué dans le Gutenberg, mais comment on les gère après ces médias ? Parce qu'une fois que j'ai envoyé 5, 10, 500 médias de cette façon, ils ne sont pas nommés, ils ne sont pas triés, ils ne sont pas tagués, on peut difficilement les exploiter, on ne sait même pas quel média utiliser où dans WordPress. Et quand on utilise effectivement WordPress pour faire des projets sur 3, 4, 5 années, si vous avez un blog que vous tenez depuis effectivement un grand nombre d'années, la question des médias, au bout d'un moment, ok, j'ai publié, j'ai écrit mon article, j'ai envoyé le média. Maintenant, c'est à voir dans la bibliothèque ce qui utilisait, ce qui ne l'est pas, c'est vrai que c'est problématique. Il y a une vraie question de classification, finalement beaucoup de clients demandent à mettre des dossiers, donc on va venir installer une extension pour créer des dossiers qui, en lien avec un autre argument, va à l'ordinaire interface. Donc tout ça effectivement fait qu'il y a beaucoup de fonctionnalités dans le CMS qui sont effectivement très pratiques, très démo ready, un bel démo, c'est toujours l'effet wow de prendre les images sur son bureau, de les envoyer, mais après effectivement en termes d'exploit de maintenabilité, c'est un peu plus compliqué. On est presque fini des arguments. Le multilinguisme, alors c'est pas vraiment un point fort, c'est plus un point effectivement un peu neutre sur ce CMS qui ne propose pas vraiment de solutions, de multilinguisme natif, mais c'est vrai qu'on a des supers effectivement solutions, Polylang, c'est une très bonne solution, WPMS c'est des très bonnes solutions. La question c'est pas tant WordPress plus Polylang, c'est WordPress Polylang et des dizaines d'extensions, et c'est là où ça peut effectivement, ça va y beaucoup plus compliqué. Donc le fait qu'il n'y ait pas de support natif fait que chaque plugin peut supporter ou ne pas supporter en fait ses extensions, et même si ses éditeurs font un gros travail de compatibilité, ça accéde. Ça reste compliqué de garantir ou pas la bonne compatibilité. Une communauté de spécialistes, on nous fait souvent se reproche, on va voir des acteurs, ils nous disent, je vais bien faire du represse, mais le problème c'est que j'ai pas de structure auquel m'a dossé. On va le dire, moi je suis un grand comte, je suis un grand acteur français, je travaille pas avec deux groupes, une entreprise de moins de 200 personnes, ou de 50 personnes, peu importe, on peut fixer un peu le nombre qu'on veut. En France, dans l'écosystème WordPress, il y a une multitude de friands, il y a beaucoup d'agences généralistes qui ne valorisent pas CMS particulièrement, et puis il y a les agences spécialistes. Ils donnent avoir 5 à 10 en France, pour n'importe. Mais c'est vrai que ces agences font entre 5 et 30 personnes, et ça qui n'a pas eu une forte émulation finalement entre les agences d'une taille critique, 40, 50 personnes qui pourraient effectivement être en compétition sur des grands comptes. Aujourd'hui on a le problème parfois de, on veut bien faire du represse, mais il nous faut un concurrent, d'une taille critique, d'une expertise similaire. Et donc on a cette problématique d'avoir un très grand nombre de friands qui ont beaucoup de compétences, et ça n'est absolument pas là la question, mais beaucoup de groupes veulent travailler avec des structures établies, des agences, et dans ce cas-là effectivement c'est un peu plus compliqué. Et puis après avoir audité aussi un grand nombre de projets faits par d'autres agences qui font du represse, faire un projet represse, c'est pas très structurant. On peut auditer un projet où on l'a fait du represse, mais on l'a fait du ACF, on l'a fait du CMB, on l'a fait du Poyer Langue, on l'a fait du WPML. Finalement, à chaque fois qu'on vient auditer un projet represse, c'est un peu une loterie. Ça peut être très bien, puis ça peut être aussi un peu catastrophique. Et donc c'est particulièrement compliqué en fait de trouver même à l'argument de la continuité, si la boîte disparaît, vous inquiétez pas, il y en a plein d'autres qui en fond, ça reste compliqué. Il y a beaucoup effectivement de particularité et comme chaque professionnel, avec ses outils, ses habitudes, c'est compliqué de se passer un projet d'agence en agence. Alors c'est pas l'objectif, mais c'est compliqué de reprendre des projets. Et là où on sort souvent l'argument, oui, mais vous inquiétez pas, si on disparaît ou si on se fâche, il y aura d'autres acteurs. Dans la vraie vie, c'est plus compliqué. Ça, c'est plus anecdotique, mais client de visée, c'est une bonne solution, mais rien pour les marketing. Pas de moteur de personne, pas de moteur de personnalisation de contenu en fonction de ce que vous faites sur le site. C'est des visages avancés, mais très clairement, l'écosystème represse propose pas grand chose vers des éditeurs comme Akiyad, Ropal ou genre de choses. Ropresse chouchou du SO, clairement, c'est toujours le cas, mais ça suffit pas en soi parce que l'outil effectivement a des qualité intrinsèques que pour autant ça va garantir un bon référencement. Donc il y a une réelle expertise derrière. C'est pas parce qu'on a installé Yoast, mais il y a une Yoast sortie d'usine que le site va se référencer. Donc, c'est vrai que c'est toujours un raccourci un peu facile de le dire. Ropresse a bien se référencer. Il y a d'autres projets sur d'autres CMS qui vont tout aussi bien se référencer. Vraiment, l'enjeu de référencement porte assez peu sur le tiège. Je vais gagner un petit peu de temps. On parle aussi souvent de rétro-compatibilité. Ça, c'est un argument qui fait mouche auprès des clients. Vous inquiétez pas, on va bâtir le projet sur Ropresse 3.9. On pourra faire les mises à jour toute notre vie. En tout cas, c'est la promesse du CMS. Sauf que, oui, on peut effectivement choisir une version, la 4.5 par exemple, et dire je vais y rester effectivement à long terme. Sauf que dans les faits, vous n'allez pas utiliser que Rpres. Vous avez utilisé Rpres, vous avez utilisé WooCommerce. Et en fait, ces extensions de l'écosystème vont vous imposer les mises à jour. Donc là, vous auriez par exemple fait le choix de rester en Rpres 4.6. Parce que vous mettez à jour Yoast, on va vous dire, ah oui mais non, il faut une version plus récente de Rpres. Vous vous disiez WooCommerce, ah oui mais non, il faut une version plus récente de Rpres. En fait, finalement, vous n'avez pas vraiment le choix. Vous définez les mises à jour. Donc là, on met la garantie de rétro-compatibilité. Les mises à jour, les versions, effectivement, sont maintenues. Ce n'est pas tellement cas. Et la marche forcée vers les interventions est quand même tenue. Enfin, quand on travaille effectivement avec des acteurs qui souhaitent aussi monter en compétence sur du Rpres, il y a une vraie interrogation sur où trouver une doc. Il y a effectivement plein de documentations. Il y a le Codex. Mais là, il y a le concurrent officiel du Codex qui est développeur pour Rpres.org, qui en gros est le Codex, mais un peu différent. Il y a tous les blogs. Il y a des documentations de VIP aussi qui posent effectivement qui sont un peu en concurrence avec les documentations officielles. Et quand on veut apprendre à faire du Rpres, qu'on veut vraiment industrialiser du Rpres, il y a une vraie interrogation de où est-ce que je trouve la bonne façon de faire. Et ça, c'est difficile, en fait, de trouver la bonne façon de faire du Rpres. Il y a beaucoup de documentations. Il n'y a pas effectivement une façon de faire. Et là où on peut effectivement dire, c'est intéressant. Du coup, on fait un peu ce qu'on veut. On a le choix entre plus différents de solutions. Ça peut se transformer en, en fait, il n'y a pas vraiment de vision projet sur la chose. Il n'y a pas de vision projet sur les tests unitaires. Il n'y a pas de vision projet sur l'intégration continue. On peut utiliser plein de solutions, mais il n'y a rien d'officiel, de recommander. On va pouvoir effectivement gagner du temps, monter en compétence. Ces différents points peuvent freiner à l'usage de Rpres. Enfin, un sujet un peu plus anecdotique, mais tout ce qui est la scabilité. Donc la possibilité de faire des grands sites avec Rpres dans le cloud. Rpres, c'est une solution avec beaucoup de qualité, mais tous les plugins ne peuvent pas en fait fonctionner sur des infrastructures cloud. Donc là, on dit, Rpres, pas de problème. C'est compatible Amazon, c'est compatible Azure, c'est compatible n'importe quel cloud. En fait, tous les plugins ne le sont pas. Et donc quand on fait d'épreuve de cette nature, il y a une vraie complexité à trouver les ressources qui vont bien fonctionner et celles qui ne vont pas fonctionner ou qui ne vont pas permettre aussi de monter en charge. Donc il y a un vrai travail en fait de classification de qu'est-ce qui fait un moment et, disons, adapter au monde d'entreprise répondant à des critères et de contraintes de performance de scabilité et ce qui ne l'est pas. Alors bon, j'ai dépeint un tableau assez dure de ce CMS, mais c'est vrai qu'aujourd'hui, à travers les infographies, on retrouve souvent que les points forts et nos clients, eux, ils mettent juste tout ça en exergue. Et en fait, on n'est vraiment questionné que sur ces éléments-là, sur les freins pour effectivement prendre la décision du teaser de Rpres sur 2, 3, 4 années. Et donc c'est sur ces éléments-là où effectivement, la communauté doit faire un effort en table de documentation, de communication, et ça passe pour tout le monde. Et finalement, je reviens sur la question de cette infographie et sur un élément un peu constant chez Rpres depuis des années. Il y a un élément qui est constant, c'est qu'on a envie de convaincre que Rpres n'est plus un moteur de blog. On le retrouve souvent, on est en 2017, décembre 2017, et effectivement, dans cette infographie, on cherche à convaincre les gens que ce n'est plus un moteur de blog. En fait, la question, ce n'est pas de convaincre que ce n'est plus un moteur de blog. C'est de convaincre que c'est une solution qui est compatible avec les enjeux de sécurité, de performance d'entreprises en anglais général. Et donc, il n'y a pas de raison qu'on ne puisse pas changer la chose. Je ne vais pas faire l'imitation de ma nuit, mais effectivement, si on veut continuer, effectivement, à démocratiser Rpres, et pas démocratiser Rpres chez les petits groupes ou les PME, ça, ça se fait naturellement, l'outil est vraiment bien fait pour. Mais si on veut continuer à le voir apparaître et être fiers d'avoir des grands médias français sur ce CMS, d'avoir des grands groupes bancaires, industrielles qui utilisent ce CMS, parce que même si ce n'est pas nous qui l'avons fait, on est quand même content qu'un grand média utilise notre CMS préféré, il faut effectivement travailler sur ces aspects. Et donc arrêter de dire négativement, on n'est plus un moteur de blog, mais dire qu'on est un réel moteur entrefin, un CMS d'entreprise. Et en ça, les qualités du CMS, en fait, ne suffisent pas. C'est pas parce qu'on arrive effectivement à un bel outil, demain, un beau content de builder, page builder, peu importe comment on le qualifie, Gutenberg, que ça va changer la donne. Ce qui va changer la donne, c'est en fait, les clients, ils cherchent pas simplement le CMS. Ils cherchent une équipe, le bon combo entre un outil performant et une agence qui aura effectivement, ou des professionnels, peu importe, qui auront effectivement les compétences pour faire le projet. Et nous, on se fait quasiment sortir. Ça, c'est l'expérience qui, on a des succès, on a des échecs comme toutes les entreprises. Et on se fait jamais sortir parce que WordPress, c'est un mauvais outil. On se fait sortir parce qu'on n'a pas été assez créatif, parce que la conception n'était pas réussie, parce qu'on n'a peut-être pas convaincu sur la technicité d'induce, peu importe. Mais ça, c'est pas que l'outil. En fait, WordPress n'a pas à faire brancher la balance plus que ça. Et donc, il faut des expertises multiples. Si on veut effectivement que WordPress progresse en termes de taille de projet, continue à se développer chez les grands groupes, des grands médias. Et ce n'est pas effectivement par un grand nombre d'expertises sur les sujets variés comme tout ce qui est SEO, analytics, référencement, la conception, le design, et puis des sujets plus techniques. Et c'est là où effectivement, en France, c'est assez, on va dire, léger en termes d'écosystèmes, sur la question de la performance, de la montée en charge, où finalement il y a assez peu de ressources. Et également les questions de maintenabilité, de qualité, d'intégration continue de sécurité. On va pouvoir trouver des ressources, mais c'est beaucoup plus effectivement développé dans l'écosystème américain, chez Automatique, chez Human Match, chez TenUp. Effectivement, en France, ça sera effectivement plus léger. Et nous, on a effectivement un souhait. Alors, ça tombe bien. Il y a aussi une nouvelle présidence à l'association. Donc, on espère que les démarches vont se succéder, se multiplier sur la professionnalisation. On parle de certification. C'est certainement une bonne chose, mais il y a effectivement un giving back plus important à faire au niveau de la communauté. Nous compris, on a commencé effectivement à accentuer nos efforts là-dessus sur des usages en entreprise, du CMS, du rôto d'expérience, sur la sécurité, du rôto d'expérience, sur, par exemple, l'intégration continue. Et c'est vraiment des éléments sur lesquels on a besoin de progresser, il y a un vrai besoin d'avantage de ressources pour que les décideurs dans ces grands groupes puissent effectivement considérer voir presque une bonne solution. En tout cas, pour leur besoin. Je ne sais pas si vous avez des questions. Je pense à être passé sur beaucoup de points faibles. Je ne sais pas si je vous n'en ai pas mis. Vous pourrez effectivement les poser. Et voilà. Des questions. Ce n'est pas encore l'heure de la pause. Juste au final, bonjour Sandra. Juste au final, finalement, WordPress a quand même plus de qualité et de points forts que d'inconvénients et de points faibles. C'est dépendant de contexte. C'est-à-dire que là où une gestion de médias légères peut être tout à fait pertinent pour beaucoup de projets. Il y a effectivement des acteurs, des clients qui vont, qui vont crier, en fait, quand on va, ce qui est proposé relativement, on va dire, mais cet outil n'est pas adapté à mon besoin. J'ai besoin de classifier. Donc c'est vrai que la réponse, elle est très variable. Maintenant, nous, on ne fait que du represse. Donc on est convaincu que ça reste une bonne solution. Et c'est davantage l'expertise du professionnel, du freelance de l'agence qui va permettre de convaincre et c'est ses bonnes pratiques qui n'y a pas de convaincre. Mais ces problèmes-là, on les retrouve aussi sur d'autres CMA. J'imagine, il n'y a pas qu' WordPress. Mais en fait, vous l'avez moins parce que souvent, la couverture fonctionnelle est beaucoup plus poussée. C'est-à-dire que vous prenez des CMAs entreprises, en tout cas, flaguer comme CMAs entreprises, drop-out, les y publichent. Vous pensez à la problématique de l'industrialisation où vous avez une documentation de 300 pages officielle qui traite comment le faire comme le projet l'imagine. En fait, le sujet, souvent, il est beaucoup plus documenté sur un certain nombre d'enjeux qui vont assurer les décideurs. Là, WordPress, c'est beaucoup plus collaboratif, beaucoup plus ouvert. Il y a beaucoup plus de façons de faire, de projets partagés pour le faire. Mais nous, on est convaincu que ça reste une bonne solution pour de nombreux besoins. Merci. Bonjour Olivier. J'ai une question justement par rapport à ça. Notamment, l'intégration continue WordPress. Ils en sont ouches automatiques. Qu'est-ce qu'on t'a voir une documentation officielle comme pour les y publiches et Drupal pour les décideurs ? En fait, aujourd'hui, ce qui est compliqué en termes de réponse sur ces sujets, c'est qu'on a le projet WordPress open source et on a un acteur automatique. WordPress VIP qui dit commercialement sur des grands comptes, des grands projets américains et qui effectivement ont une documentation plus d'avantage, plus orientée sur la plateforme que WordPress et qui traite des bonnes pratiques, du code review, des nécessités, de faire du test unitaire. Mais ce n'est pas une doc officielle du projet WordPress.org. C'est une documentation pour effectivement un service qui se base sur WordPress. Donc, je ne sais pas s'il y a une réelle volonté de venir fermer le jeu. Ce qui est certain, c'est qu'on parle avec automatique, avec des grands acteurs français, avec ça parle de sécurité et d'induce. C'est automatique, ils nous disent qu'ils sont quand même chiant ces français. C'est plus simple, on s'est dans la main plus facilement. En tout cas, en France, les DSC à l'ancienne, ce n'est pas que ça y est frais, mais ce n'est pas leur kiff. Donc je ne suis pas sûr qu'il y ait une documentation officielle à l'entendue courte. Bon, merci à Maurice. Merci beaucoup. Merci beaucoup.