Lorsque Proton a commencé en 2014, notre seul service était Proton Mail. Proton VPN(new window), notre deuxième service, a été lancé en 2017, et nous avons récemment sorti Proton Calendar et Proton Drive(new window).
Au fur et à mesure que nous grandissions et lancions de nouveaux services, nous avons réalisé la nécessité d’unifier la marque Proton et nos sites internet publics. C’est là que commence l’histoire du nouveau site internet Proton.
Les débuts de Proton
Notre parcours commence avec Proton Mail.
Lorsque Proton Mail était notre seul service, il pouvait sembler aux yeux non avertis que nous avions un seul site internet public, que nous utilisions pour promouvoir notre service et partager notre vision de l’entreprise. Mais en réalité, ce site internet unique était en fait composé de trois sites distincts :
- Nos principales pages web étaient des pages statiques.
- Le blog de Proton Mail, qui utilisait WordPress.
- Le blog d’assistance de Proton Mail, qui utilisait également WordPress.
En 2017, lors du lancement de Proton VPN, nous avons décidé de créer un site internet Proton VPN dédié en utilisant le même modèle. Cela signifiait que nous gérions six sites internet entre Proton Mail et Proton VPN.
Outre leur nombre, il y avait d’autres aspects de ces sites qui rendaient leur gestion quotidienne quelque peu complexe :
- De nombreuses parties des sites de Proton Mail et Proton VPN ont été conçues artisanalement au fil du temps, rendant difficile la mise à jour de certaines de ces pages.
- Nous utilisions différentes piles technologiques sur nos pages statiques et nos sites WordPress, ce qui rendait la mise à jour d’éléments communs sur tous les sites, tels que les en-têtes ou les pieds de page, assez complexe.
- Seuls les développeurs pouvaient mettre à jour le contenu de nos pages statiques. Cela rendait difficile la mise à jour rapide de notre site internet, surtout lorsque les équipes d’ingénierie étaient occupées.
- Nos produits sont destinés à tous, c’est pourquoi nous avons des versions localisées du site internet Proton Mail en 26 langues. Mais cela introduit de nombreux défis d’un point de vue technique.
Voici comment fonctionnaient nos sites internet lorsque nous étions concentrés uniquement sur Proton Mail et Proton VPN. Mais même au moment du lancement de Proton VPN, nous savions que nous introduirions éventuellement d’autres services à l’avenir.
Les problématiques liées à la croissance
Proton a connu une croissance explosive depuis ses débuts, et nos premiers sites internet ont été de véritables moteurs de croissance pour nous. Cependant, nous savions qu’au fur et à mesure de notre croissance, nous devrions changer notre approche. Nous pouvions voir plusieurs problèmes se profiler à l’horizon qui nécessiteraient un changement radical dans notre façon d’aborder le développement et la maintenance de notre site internet.
Plus de services
Plus évidemment, nous commencions à travailler sur Proton Calendar et Proton Drive. Ces services auraient leurs propres utilisateurs qui nécessiteraient leurs propres informations spécifiques au service, articles de blog et articles d’assistance. Selon notre modèle initial, nous devrions créer des sites internet dédiés pour les deux.
Compte tenu de toutes les complexités quotidiennes rencontrées dans la gestion de six sites internet, nous ne voulions pas gérer 12 sites. Il était évident que nous aurions besoin d’un nouveau modèle, ce qui nous a d’abord amenés à envisager un site internet unique.
Piles technologiques
Les différentes sections de nos sites Proton Mail et Proton VPN utilisaient différentes piles technologiques. Les pages statiques utilisent principalement une pile JavaScript, et nos blogs et blogs d’assistance utilisaient des sites WordPress basés sur PHP et MySQL. Pour compliquer encore les choses, nos applications web utilisent React(new window), une autre pile à maintenir.
Le soutien de tant de piles différentes nécessitait un large éventail de compétences en ingénierie et signifiait que certains ingénieurs étaient plus ou moins dédiés à des projets spécifiques. Cela créait souvent des goulots d’étranglement quand un ingénieur spécifique n’était pas disponible.
En regardant vers l’avenir, nous voulions réduire le nombre de piles technologiques utilisées pour nos sites internet. Si tout le monde travaille sur la même pile, nous aurons tous les connaissances requises et pourrons aider sur n’importe quel projet.
Il était également difficile de maintenir un haut niveau de qualité tout en soutenant autant de piles. Garder la communauté Proton et leurs données en sécurité est notre priorité absolue, c’est pourquoi nous mettons tant l’accent sur la qualité et la sécurité de nos services.
Le soutien et la gestion d’une si grande variété de langages de programmation et d’outils rendaient cela plus difficile. Par exemple, chaque fois qu’un ingénieur modifiait l’en-tête ou le pied de page du site Proton Mail, cette modification devait être appliquée trois fois sur chaque site séparé (site statique, blog et blog d’assistance). Si cet ingénieur voulait effectuer ce changement lui-même, il devait être capable de travailler en JavaScript, PHP et MySQL. Nous voulions limiter cela autant que possible à l’avenir.
Mises à jour de contenu
Enfin et surtout, l’un de nos plus grands défis était de réaliser des mises à jour opportunes du contenu de nos sites internet. Si nous allions concevoir un nouveau site internet, nous voulions que n’importe qui puisse ajouter du texte ou faire des modifications simples, pas seulement les ingénieurs. Alors que nous lançons de plus en plus de services, le nombre de pages web et la quantité de contenu que nous devons gérer augmentent de manière exponentielle, et il était déjà difficile de compter uniquement sur des développeurs occupés pour appliquer rapidement des changements de contenu.
Ce n’était que le début. Nous devons également gérer le contenu localisé. Auparavant, tous les textes étaient fournis par les développeurs en anglais dans la base de code. Ce texte anglais était utilisé pour créer une chaîne de traduction. Ensuite, notre équipe de localisation le traduisait avec l’aide de notre formidable communauté de localisation.
Ce système avait un défaut majeur. Chaque fois que nous devions changer le texte existant sur une page web, même s’il s’agissait simplement d’ajouter une virgule, les développeurs devaient mettre à jour le texte dans la base de code. Cette mise à jour modifiait la chaîne de traduction, ce qui signifiait que l’équipe de localisation devait traiter la chaîne comme si elle était entièrement nouvelle.
Améliorer la gestion globale du contenu était un autre défi que nous voulions relever avec notre nouveau site internet.
Comment et pourquoi nous avons construit le site internet Proton de cette manière
Une fois que nous avons identifié tous les défis que notre système actuel présentait, nous voulions trouver une solution qui les résoudrait tous. Cela nécessitait une solution technique mais également des pratiques améliorées d’un point de vue technique et organisationnel. Voici ce que nous avons fait jusqu’à présent et sur quoi nous travaillons encore.
Gatsby
L’une de nos premières décisions a été de choisir un cadre technique pour gérer notre site internet statique qui simplifierait notre pile technologique.
Ce n’était pas difficile. Nos applications web utilisent le cadre React, et la plupart des ingénieurs de notre équipe le connaissent déjà et sont à l’aise pour l’utiliser, ce qui nous a amenés à chercher une solution également basée sur React. C’est la principale raison pour laquelle nous avons choisi Gatsby(new window) pour gérer nos pages web statiques. C’est aussi un cadre largement utilisé avec une grande communauté, ce qui offre l’assurance qu’il ne disparaîtra pas de sitôt.
Nous avons choisi Gatsby dès le début, ce qui nous a permis de vérifier qu’il fonctionnerait pour nous en le testant. D’abord, nous avons utilisé Gatsby pour construire certaines pages pour le site internet statique Proton VPN. Comme le site était déjà statique, nous pouvions simplement construire de nouvelles pages avec Gatsby et les intégrer parmi les existantes. Il y avait évidemment quelques défis techniques à résoudre lorsque nous avons intégré Gatsby au site statique, mais ils sont essentiellement invisibles du point de vue de l’utilisateur final.
Nous voulions également systématiser autant que possible la manière dont nous construisons les pages pour améliorer notre agilité lors de l’édition du contenu des pages web. Beaucoup de nos anciennes pages web statiques ont été construites morceau par morceau au fil du temps tandis que d’autres ont été copiées et collées, ce qui signifie qu’il n’y avait aucune uniformité d’une page à l’autre. Cela rendait la maintenance laborieuse. Nous avons pensé que le passage à un nouveau cadre technique serait le bon moment pour abandonner cette approche morcelée.
Nous avons décidé d’adopter une stratégie de composants dès le début avec Gatsby. Nos équipes Produit et Design ont travaillé dur pour définir et créer un ensemble de composants que nous pouvons réutiliser pour construire de nouvelles pages à l’avenir. De cette façon, nous pouvons appliquer tout changement à un composant partout au lieu de devoir appliquer le même changement plusieurs fois à différents endroits comme nous le faisions sur nos anciens sites internet.
Ces premières expériences ont confirmé que Gatsby serait une solution efficace pour construire et maintenir notre nouveau site internet statique.
Cependant, ces pages statiques n’étaient qu’une partie de nos sites internet publics. Nous devions également trouver une solution pour gérer notre blog et le blog de Support.
WordPress
La question de savoir si nous devions continuer avec WordPress(new window) était délicate pour nous. Pour simplifier notre pile technologique, il aurait été logique de l’abandonner et de trouver une autre manière de gérer nos blogs et blogs de Support. D’autre part, l’équipe Proton connaît WordPress, tout comme la plupart des rédacteurs de contenu web en général.
Nous avions aussi de nombreux articles existants à importer sur le nouveau site internet depuis les blogs Proton Mail et Proton VPN et leurs blogs de Support correspondants. Par exemple, si nous regardons uniquement le site internet Proton Mail, nous avons fait plus de 700 publications en juillet 2021 ! La migration de tout ce contenu aurait été un véritable défi.
En y réfléchissant davantage, ce qui nous a le plus posé problème était la gestion séparée des pages d’accueil pour chaque site internet. Dans notre configuration initiale, nous gérions en fait quatre sites WordPress différents : un blog et un blog d’assistance pour Proton Mail et Proton VPN. De plus, chacune de ces instances de WordPress disposait de son propre ensemble de plugins et de thèmes dédiés.
Finalement, nous avons décidé de garder WordPress et de simplifier la manière dont nous gérons les pages d’accueil.
WordPress Multisite
Une fois la décision prise de conserver WordPress, le choix logique suivant a été de sélectionner une version multisite. Si vous n’avez jamais entendu parler de WordPress Multisite, c’est essentiellement une instance WordPress standard configurée pour vous permettre de gérer plusieurs sous-sites sur un seul site WordPress. Cela nous intéressait car une instance multisite vous permet de partager les utilisateurs, plugins, thèmes et paramètres de configuration entre tous les sous-sites. Cette fonctionnalité à elle seule a grandement facilité la gestion de nos sites WordPress. Par exemple, avec une instance multisite, nous avons juste besoin de cliquer sur un seul bouton pour mettre à jour WordPress ou un plugin pour tous ses sous-sites. Auparavant, nous devions mettre à jour chaque site individuellement.
Cela nous fait évidemment gagner beaucoup de temps par rapport à notre configuration précédente, mais nous pensions pouvoir aller encore plus loin. Notre rêve était d’utiliser WordPress comme un CMS sans tête.
WordPress en tant que headless
Nous savions déjà début 2020 que nous devrions trouver une meilleure solution pour nos sites internet, et nous avons construit quelques pages de blog avec Gatsby en utilisant l’API REST de WordPress comme test. Malheureusement, les options techniques de l’époque n’étaient pas optimales. Le processus de construction, en particulier, était trop lent pour nos besoins.
Nous avons décidé de réessayer début 2021. Nous avons enquêté et découvert qu’il y avait eu plusieurs mises à jour prometteuses. L’équipe de Gatsby avait beaucoup travaillé pour permettre à Gatsby de récupérer le contenu depuis WordPress. Crucialement, des plugins(new window) ont été développés pour Gatsby et WordPress, leur permettant de travailler ensemble. Ces plugins optimisent la construction avec la gestion du cache et offrent un moyen de prévisualiser les articles depuis WordPress.
Nous avons donc créé une preuve de concept avec des articles du blog Proton Mail pour vérifier comment un CMS WordPress sans tête fonctionnerait. À notre grande satisfaction, cela a très bien fonctionné. Pour résumer notre configuration, nous exposons essentiellement une API GraphQL du contenu WordPress que nous pouvons interroger avec Gatsby pour obtenir le contenu et construire la page comme nous le souhaitons. Finalement, nous avons réussi à obtenir tous nos articles de blog et d’assistance dans WordPress pour générer des pages statiques en utilisant Gatsby.
À ce stade, nous n’avons besoin que d’un outil pour construire les pages front-end, et nous pouvons implémenter les changements une fois et les appliquer sur plusieurs sites au lieu de les mettre en œuvre individuellement sur chaque site. C’est un progrès !
Nous étions déjà satisfaits de la simplification de notre processus de développement, mais nous pensions qu’il y avait encore plus à faire.
Prismic
Nous avons continué à chercher des moyens de simplifier la gestion du contenu sur nos sites internet. Idéalement, nous voulions éliminer complètement les ingénieurs du processus de mise à jour du contenu.
Avec notre ancien système, les ingénieurs devaient implémenter chaque mise à jour de contenu sur nos pages statiques. D’autres équipes internes, telles que Croissance, Contenu et Design, envoyaient leurs modifications à un ingénieur qui mettait à jour la base de code. Ce système aidait à maintenir la qualité du code mais rendait difficile la mise à jour du contenu existant ou la publication rapide de nouveau contenu.
Nous avons commencé à examiner des moyens de permettre à l’équipe de Contenu de gérer elle-même le texte de nos sites statiques sans risquer la qualité de notre code. Nous avons évalué plusieurs solutions, mais au final, nous avons décidé d’opter pour Prismic(new window). Prismic est un CMS sans tête qui vous permet de créer des composants que les éditeurs peuvent utiliser pour construire des pages complètes. Nous avons économisé encore plus d’efforts en utilisant les composants que nous avions d’abord définis et construits en utilisant Gatsby. Une fois ces composants configurés, nous pouvions rapidement construire toutes les pages web dont nous avions besoin et confier la maintenance du contenu aux éditeurs de contenu.
La dernière chose à gérer était l’intégration de ce contenu dans Gatsby. Heureusement, Prismic expose une API GraphQL de la même manière que WordPress, ce qui rend cela simple. Tout ce que nous avions à faire était de mapper le contenu interrogé sur nos composants existants.
Où en sommes-nous
Actuellement, le site internet de Proton utilise la configuration décrite ci-dessus pour servir Proton Calendar, Proton Drive et Proton Mail. Nous avons migré nos sites internet Proton Mail vers proton.me et construit de nouvelles pages web pour Proton Calendar et Proton Drive. Notre site internet Proton VPN doit encore être migré.
La nouvelle configuration du site internet de Proton représente un grand pas en avant par rapport à notre point de départ, même sans la migration de Proton VPN. En regroupant Proton Mail, Proton Calendar et Proton Drive sur un seul site, nous avons créé un écosystème unifié où les interactions entre nos services contribuent à mieux protéger la vie privée de notre communauté.
D’un point de vue technique, nous avons encore du travail devant nous. Par exemple, à l’heure actuelle, nous avons un seul processus de construction pour tout le site internet, et nous le déployons quotidiennement dans un créneau fixe pour gérer les mises à jour ou publier des articles de blog.
Cela fonctionne bien, mais nous pourrions être plus efficaces si nous avions des constructions et des déploiements plus granulaires. Il y a certains défis techniques que nous devrons surmonter pour y parvenir, car nous gérons tout en interne. C’est l’un des nombreux problèmes que nous prévoyons d’examiner dans les semaines et mois à venir.
Nous espérons que vous avez apprécié cette explication de la manière dont nous avons construit le site internet de Proton. Cela nous aidera à protéger les données et la vie privée de notre communauté et nous prépare à gérer une croissance future.
