Comment Mindvalley a réduit de 50% le temps de développement de ses sites web multilingues?

• Headquarters: Kuala Lumpur, Malaysia
• Technology Stack: GraphQL

Mindvalley est une plateforme par abonnement destinée au développement personnel, où les utilisateurs peuvent suivre des cours, des masterclass et du contenu pour développer leurs compétences. Avec plus de 20 millions de membres dans le monde, Mindvalley s'adresse à toute personne intéressée par le développement de soi et la croissance personnelle. La plupart de ses clients sont basés aux États-Unis et sont de tous âges (adolescents, adultes et seniors).

L'équipe d'acquisition de Mindvalley est à la tête de la maintenance du site web de l'entreprise et a participé à la mise en œuvre du nouveau site avec Storyblok. L'équipe est composée de Prosper Chiduku (Software Engineer), Fann Saw (Senior Product Designer), M.Saad Siddiqui (Engineering Lead), et des initiateurs du projet, Aaron Myatt (User Acquisition Technical Lead), Saquieb Ansari (Senior Dev) et Ali Azwad (Senior Dev).

Le projet et son histoire

Le parcours de Mindvalley avant le passage à Storyblok peut être décomposé en trois phases :

1. L'ère monolithique
2. La construction de son propre CMS
3. La tentative de construire son propre CMS headless.

Lors de la première phase, Mindvalley a utilisé plusieurs CMS traditionnels différents, tels que WordPress et Drupal, et a constaté un manque de personnalisation des composants. Cela a donc amené la marque à tenter de construire son propre système appelé Ignite. Le problème avec Ignite était qu'il n'y avait pas d'interface, ce qui rendait difficile la compréhension de son code et entravait l'avancement et la croissance de l'entreprise. Il y avait une courbe d'apprentissage lourde pour tous les nouveaux employés, qui devaient apprendre le code à partir de zéro, et entraînait une maintenance compliquée du système.

En plus de cela, tout utilisateur devait se plonger dans chaque détail et apporter des modifications aux pages de code, ligne par ligne. Ignite n'était pas basé sur des composants comme Mindvalley l'aurait souhaité, intégré dans des Git Repos, ce qui rendait difficile toute mise à jour. Pour les utilisateurs non techniques, chaque mise à jour ou changement signifiait qu'ils devaient apprendre à coder pour suivre le rythme et apporter ces modifications, et qu'ils devaient parcourir tout un code de démarquage pour trouver l'élément à modifier. Dans ces conditions, les développeurs craignaient que les modifications apportées par les marketeurs ne soient pas correctement mises en œuvre dans le code, avec par exemple l'oubli de crochets fermant dans le code, qui peut avoir des effets néfastes sur une page. Lorsqu'un tel problème survenait, un développeur devait intervenir sur le champ pour trouver et corriger le problème.

Au cours de cette période difficile, Mindvalley a alors décidé d'essayer de construire quelque chose de semblable à un CMS headless appelé Site Builder. Mais alors que l'équipe continuait à utiliser Site Builder, elle s'est aperçue qu'il y avait toujours trop de maintenance à effectuer en permanence, ce qui détournait l'attention des développeurs lorsqu'ils travaillaient sur des projets cruciaux.

Mindvalley a continué à utiliser Site Builder, mais avec le temps, elle s'est rendue compte qu'un changement s'imposait pour résoudre le problème à la source. Site Builder était également fortement basé sur le langage PHP, sans compter que personne à l'époque ne connaissait PHP et qu'en cas d'erreur, les développeurs auraient dû se démener pour trouver une solution.

Cela signifiait qu'il fallait trouver un CMS headless qui pourrait supporter toutes les lourdeurs et la maintenance pour eux et, en retour, redonner la liberté aux développeurs de se consacrer à leurs propres projets.

Les impératifs étaient les suivants:

• Trouver un système basé sur des composants qui permette la réutilisation des éléments pour garantir la cohérence des pages selon les lignes directrices de la marque.
• Une courbe d'apprentissage facile pour les développeurs, adaptée au langage avec lequel ils sont familiers (dans ce cas, Javascript et Vue.JS), permettant aux développeurs de passer plus de temps à personnaliser et à créer des composants plutôt qu'à essayer de maintenir le CMS.
• Un système permettant aux concepteurs et aux marketeurs d'être indépendants et d'apporter facilement des modifications au contenu, sans avoir besoin de coder ou de faire appel aux développeurs.
• Des déploiements faciles à travers une configuration de pages multilingues, pour différents produits et verticaux.

Pourquoi Mindvalley a choisi Storyblok comme CMS?

Mindvalley a commencé sa recherche d'une solution headless à la fin de 2017, au moment même où ils essayaient de migrer davantage de projets vers Site Builder. Cela avait été retardé car il n'y avait pas assez de collaborateurs prêts à intervenir pour une migration aussi importante.

Au début de 2018, l'opinion générale au sein de l'entreprise penchait pour le passage à un nouveau système - pourtant, 90% du chiffre d'affaires de Mindvalley était toujours généré sur Ignite. Parmi les cadres supérieurs, il y avait une crainte profonde qu'un changement de système aussi important puisse mettre en péril les revenus de l'entreprise. C'est à ce moment-là qu'Aaron a découvert et recommandé Storyblok.

Après avoir vu les tensions s'accumuler au sein des équipes, il a progressivement pris la tête du déploiement du contenu de Mindvalley depuis Ignite et Site Builder, produit par produit, vers Storyblok. C'est à la mi-2019 que Mindvalley a commencé à migrer plusieurs pages vers Storyblok.

Le passage vers Storyblok était un choix de l'ensemble de l'entreprise, car il fallait que les choses changent. Leurs développeurs et marketeurs avaient cruellement besoin d'un nouveau système, d'un outil qui facilite leurs tâches et dont ils pourraient tirer des enseignements, ce qui pourrait être bénéfique pour l'évolution de leur carrière à l'avenir.

Mise en place de Storyblok dans les nombreuses pages produits de Mindvalley

Prosper Chiduku (développeur), Fann Saw (concepteur de produits senior) qui fait le lien entre les équipes de conception et celles techniques, ainsi que Saad Siddiqui (Team Lead qui travaille sur Storyblok) font partie de l'équipe d'acquisition qui s'est trouvée en première ligne de la migration de Mindvalley vers Storyblok.

Une grande partie de Storyblok est utilisée pour créer le contenu et les pages produits de Mindvalley, divisés en segments de pré-connexion et de connexion. L'équipe d'acquisition intervient sur le processus de pré-connexion (hébergé sur mindvalley.com ). En suivant le parcours du client, tout nouveau visiteur qui passe par les pages de pré-connexion (leur vitrine) voit apparaître les produits, les cours, les ateliers spécialisés, les descriptions, etc. disponibles. Ceci peut être vu à travers l'une des configurations personnalisées de l'équipe d'acquisition. Un plug-in a été écrit pour consolider certains autres plug-ins afin de gérer facilement les différentes pages et sites de produits. Le plug-in est capable d'extraire des données de leur API GraphQL, ce qui permet de filtrer facilement toutes les données du backend à l'aide d'un menu déroulant facile à utiliser sur le frontend. Une fois qu'un utilisateur décide de s'inscrire à Mindvalley, il passe au segment post-login qui lui permet d'accéder à ces éléments.

Storyblok intervient ici pour simplifier le parcours client et le développement de pages qui agissent comme l'ADN de la marque pour les utilisateurs sans connaissances techniques afin qu'ils puissent gérer facilement le contenu. Les utilisateurs non techniques, tels que les marketeurs et les designers, sont en mesure de dupliquer facilement différents cours ou produits et de modifier les éléments de contenu en cours de route sur les différents sites multilingues de Mindvalley. Les capacités de glisser-déposer de l'éditeur visuel étaient exactement ce dont Mindvalley avait le plus besoin.

Speaking the audience's language: simple multilingual management

Internationalization is a key to many long-term business strategies today, but to tap into any new market successfully, you have to speak the audience’s language, quite literally. For Mindvalley, their international reach currently covers 8 language sites, which pre-Storyblok required separate content repositories for each. An approach that wasn’t exactly scalable; after all, no one wants to be updating multiple individual repositories whenever they need to make a content change.

But nowadays, their multilingual content workflow looks pretty different as the Mindvalley team can update every language site simultaneously from one location—get the technical details here. Marketers can head over to the page they want to edit in Storyblok, then, using the drop-down field type feature in our Visual Editor, they can easily edit the content on every language version of that page.

They can even leverage our AI translator feature and allow Storyblok to do the hard translation work for them, while they focus on making sure the content narrative is on point. Building a world-class digital experience for their personal development courses has never been easier; the whole Mindvalley team is able to contribute efficiently and confidently with a newly refurbished content workflow that allows people to actually do their jobs. Even new hires are able to get to work in no time with plenty of documentation and how-to guides to show them the ropes of Storyblok. How’s that for scalable multilingual content?

Storyblok a également aidé Mindvalley à faciliter le déploiement. Alors qu'auparavant, les équipes devaient passer par un service appelé "Mission Control" au sein d'Ignite pour procéder au lancement, elles peuvent désormais cliquer sur "Publier" et lancer le déploiement en toute simplicité. Lorsqu'il s'agit de construire de nouveaux composants à l'intérieur de leur installation Storyblok, le processus part d'une conception de page venant directement des concepteurs et des marketeurs pour arriver à l'équipe d'acquisition. Là, ils détectent les éléments de contenu qui peuvent devenir un bloc de configuration afin que de nouveaux composants puissent être construits sur cette base.