Les nouvelles applications mobiles Proton Mail : il y a plus que ce que l’on voit

En septembre de l’année dernière, nous avons lancé une mise à jour majeure de Proton Mail pour iOS et Android.

En surface, les nouvelles applications offrent un design moderne, de meilleures performances et des capacités hors ligne — mais il y a beaucoup plus que ce que l’on voit. En coulisses, les applications sont une réécriture complète de Proton Mail sur une nouvelle pile technologique, un projet qui porte le nom interne de Transformation de l’ingénierie. Le terme nouvelle est délibéré, car — à notre connaissance — c’est la première fois que la technologie choisie a été utilisée dans le contexte d’une application de production établie.

Cet article vise à faire la lumière sur le voyage fascinant que notre équipe a traversé lors de la réalisation de cette révolution, et à répondre à certaines des questions que notre communauté nous a posées en cours de route. D’abord et avant tout, la raison d’être est la nécessité de changer le statu quo.

Comment tout a commencé

La prise de conscience que les choses devaient changer a frappé un vendredi soir en octobre 2023. Elle s’est matérialisée avec une clarté surprenante, mais pas de nulle part : c’était l’aboutissement de mois passés à essayer de trouver un dénominateur commun aux problèmes apparemment sans rapport affectant l’expérience de nos utilisateurs avec les produits mobiles Mail et Calendrier.

Au risque de simplifier à l’excès, nous pouvons résumer les points douloureux en trois domaines :

• Qualité : Mail iOS et Mail Android, pris isolément, n’étaient pas à la hauteur des attentes en termes de qualité et de performance.
• Écart de fonctionnalités entre iOS et Android : Certaines fonctionnalités n’étaient disponibles que sur une seule plateforme, sans clarté sur le moment où l’autre rattraperait son retard.
• Vélocité de l’ingénierie : Les mises à jour clés et les fonctionnalités attendues depuis longtemps n’étaient pas livrées en temps opportun sur les deux plateformes.

Certains des problèmes s’étendaient au-delà du mobile, et y répondre nécessiterait une digression du domaine technologique vers l’espace de problèmes fascinant de la mise à l’échelle organisationnelle, et en particulier des startups technologiques à croissance rapide. Mais la fragilité de l’écosystème mobile était très ancrée dans la technologie et l’architecture.

Mise à l’échelle de l’ingénierie mobile

La mise à l’échelle de l’ingénierie mobile s’accompagne d’un ensemble unique de défis qui sont significativement différents de la mise à l’échelle des équipes backend et web. Ces différences découlent de la fragmentation des plateformes et des réalités opérationnelles de l’écosystème mobile. Les équipes mobiles doivent généralement prendre en charge plusieurs plateformes sur une variété de systèmes d’exploitation et d’appareils (téléphones, tablettes, parfois wearables). iOS et Android viennent avec leurs propres langages de programmation, frameworks et outils, ce qui conduit à de grandes quantités d’efforts dupliqués : plusieurs équipes, des bases de code dupliquées et des compromis constants entre le travail spécifique à la plateforme et celui lié au produit. Garder l’offre de produits synchronisée nécessite une énorme quantité de coordination.

Ce qui est un défi à l’échelle de l’industrie était particulièrement aigu pour Proton. Les applications de fonctionnalité telles que Mail et Calendrier sont intrinsèquement plus complexes que la plupart des applications mobiles sur le marché. Lorsque vous ajoutez par-dessus la couche supplémentaire de logique client requise pour gérer le chiffrement de bout en bout, vous vous retrouvez avec des clients particulièrement « lourds ». À l’époque, l’équipe Android était occupée à réécrire Mail pour de meilleurs standards de qualité — un investissement qui a pris la majeure partie de 18 mois. iOS avait également un grand besoin de ré-architecture, sans parler de Calendrier. Le coût de la duplication consommait toutes nos ressources d’ingénierie, et il est devenu clair que nous n’allions pas réussir en faisant plus de la même chose.

La meilleure chose à propos de la reconnaissance que vous êtes coincé est que cela agit comme un facteur forçant pour penser en dehors des contraintes de votre statu quo actuel. Que ferions-nous si nous pouvions recommencer à zéro, libérés du fardeau des choix et des engagements qui nous ont menés ici ? Lorsque vous regardez de plus près comment les entreprises prospères ont traité ce problème au cours de la décennie précédente, vous réalisez qu’elles ont suivi l’une des deux seules stratégies possibles :

1. Elles ont jeté de l’argent par les fenêtres, construisant des équipes toujours plus grandes car les coûts opérationnels élevés étaient compensés par une combinaison d’investissements sans fond et/ou de retours somptueux. Ce n’était pas une option pour le modèle commercial sans capital-risque de Proton : nous ne pouvons pas rivaliser avec les dépenses des concurrents soutenus par la publicité et les investisseurs.
2. Elles ont réingénieré leurs applications pour se débarrasser du gaspillage, ce qui signifie construire des applications en utilisant (autant que possible) une base de code partagée.

Avec l’option 1 étant exclue, la voie à suivre était tracée.

Un moyen pour parvenir à une fin : choisir la bonne pile technologique

L’étape suivante était de choisir une pile technologique qui pourrait réellement faire le travail.

Au cours des 15 dernières années, le développement mobile multiplateforme a été inondé de solutions « universelles » : HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform, et bien d’autres. Chacune est arrivée avec la même promesse — remplacer le développement natif purement et simplement. En pratique, la plupart ont soit échoué purement et simplement, soit réussi uniquement dans des espaces de problèmes strictement contraints. Il n’existe pas d’abstraction universelle qui fasse disparaître les différences de plateforme : quiconque a livré et maintenu de grandes applications mobiles le sait. La seule voie fiable est de travailler à rebours à partir d’exigences concrètes plutôt qu’en avant à partir des tendances d’outillage.

Nous avons traduit cet objectif final en un ensemble d’exigences non négociables (1) que toute solution choisie devait satisfaire, et les avons utilisées comme notre cadre directeur tout au long du processus d’évaluation :

1. Coûts et délais : La pile devait réduire matériellement le coût et le temps requis pour livrer, maintenir et faire évoluer Proton Mail sur iOS et Android.
2. Expérience utilisateur : Elle devait préserver des performances et une qualité d’interaction proches du natif — tout le reste était exclu.
3. Pérennité stratégique : La solution devait être durable. Nous étions intentionnels sur le fait d’éviter des frameworks tiers qui rendraient notre feuille de route dépendante du support continu d’un autre fournisseur.

La tension entre les deux premières contraintes est la version industrielle du Saint Graal : « Une solution multiplateforme qui offre les performances et l’expérience utilisateur des applications natives. »

Nous étions sceptiques dès le départ quant au fait que React Native ou Flutter — les deux frameworks multiplateformes dominants à l’époque — puissent atteindre ce niveau. Pourtant, nous avons validé ce scepticisme en construisant des implémentations de preuve de concept de la vue de liste des messages de Mail.

React Native a rapidement révélé ses limites. Le défilement à travers un grand jeu de données a rendu le coût de son modèle d’exécution interprété douloureusement évident. Flutter a mieux performé, mais l’interface utilisateur restait visiblement non native, surtout sur iOS. Plus important encore, Flutter est un framework propriétaire contrôlé par Google, qui a un historique(nouvelle fenêtre) d’abandon de technologies internes et avait récemment licencié une grande partie de l’équipe Flutter. Pour un produit avec des garanties de sécurité et de fiabilité à long terme, ce niveau de dépendance externe était inacceptable.

Kotlin Multiplatform était le candidat suivant. C’est une option convaincante — particulièrement pour les organisations ayant une expertise approfondie d’Android — mais elle a finalement échoué pour notre cas d’utilisation. L’absence d’une couche d’interface utilisateur partagée, des questions autour de la maturité et la surcharge supplémentaire introduite par son modèle d’exécution l’emportaient sur ses avantages.

À ce stade, la conclusion était claire et alignée avec notre intuition initiale : la seule architecture qui s’approche constamment du résultat souhaité est une pile délibérément mixte. Une interface utilisateur native sur chaque plateforme — Jetpack Compose sur Android, SwiftUI sur iOS — soutenue par une couche de logique métier partagée écrite dans un langage de bas niveau à haute performance. Cette approche a fait ses preuves : Dropbox a notoirement utilisé C++ pour partager la logique métier entre les plateformes mobiles avant de l’abandonner en 2019 en raison du coût opérationnel et cognitif du langage.

À la fin de 2023, Rust avait clairement émergé comme le successeur dans la lignée des langages de programmation système.

Rust occupe la même enveloppe de performance que C++, mais sans bon nombre de ses inconvénients historiques. Il offre de fortes garanties de sécurité mémoire sans garbage collection, impose une concurrence thread-safe au moment de la compilation, et est soutenu par un vaste écosystème open source hautement compétent. Tout aussi important, Rust s’intègre proprement aux langages mobiles natifs — Swift et SwiftUI sur iOS, Kotlin et Jetpack Compose sur Android — ce qui en fait un choix pragmatique pour partager la logique centrale sans compromettre la couche d’interface utilisateur.

Ce n’était pas une décision sans risque. À l’époque, il y avait peu d’exemples d’applications mobiles grand public à grande échelle construites sur une architecture centrée sur Rust, et l’expérience de Rust au sein de l’équipe était limitée.

Mais l’innovation significative se produit rarement en territoire à faible risque. Le véritable défi n’était pas Rust lui-même, mais l’inertie organisationnelle — passer d’approches éprouvées et conservatrices à une expérimentation délibérée, guidée par des contraintes claires et un jugement technique.

Le nouveau Proton Mail : résultat et apprentissages

Avançons rapidement jusqu’à aujourd’hui et voyons comment le pari s’est déroulé.

Le diagramme ci-dessous représente l’architecture de Mail mobile. Le cœur Rust est responsable de l’intégralité de la logique métier de l’application. Nous avons poussé l’utilisation de Rust au-delà de ses applications habituelles (réseau, espace de stockage, calcul algorithmique) jusqu’à la gestion de la logique de navigation complexe. Un cas d’espèce est la logique régissant le défilement infini de la liste des messages. Bien que peu orthodoxe, cela s’est avéré clé pour atteindre notre objectif de maximiser la réutilisation du code. En conséquence, près de 80 % de la base de code est maintenant partagée entre iOS et Android.

Cela s’est-il traduit par une mise sur le marché plus rapide et de meilleure qualité ? Bien qu’il soit encore trop tôt pour un verdict final, les premiers signes ont été très encourageants :

• Au cours des deux mois suivant la sortie, l’équipe a réussi à maintenir une cadence hebdomadaire de mises à jour de fonctionnalités sur les deux plateformes (un total de 12 sorties de fonctionnalités).
• Nous avons comblé les écarts de fonctionnalités entre les plateformes, apportant des fonctionnalités attendues depuis longtemps sur Android telles que la mise en attente, le RSVP de calendrier et le glissement vers le message suivant.
• Même à ce stade précoce, la nouvelle base de code s’est avérée plus stable que les générations précédentes sur les deux plateformes : le taux de crash iOS est de 0,05 % (en baisse par rapport à 0,12 %), tandis que celui d’Android est revenu à une référence historique (0,19 %). C’est une forte validation de la stabilité d’exécution de Rust.

Le support s’adapte également plus efficacement avec cette approche. Il est souvent plus rapide d’identifier et de résoudre une cause racine unique et partagée que de poursuivre des problèmes superficiellement similaires découlant de défauts logiques légèrement différents répartis sur deux bases de code indépendantes. Nous avons trouvé une confirmation empirique de ce qui était auparavant une hypothèse de travail lors de la correction d’une classe de problèmes de synchronisation de catégorie affectant la logique qui sous-tend les capacités hors ligne de l’application : une cause racine, une solution — représentée dans le diagramme ci-dessus par le module de rebasage livré avec la version 7.6.2.

L’autre revers de la médaille ?

• Les bugs et régressions sont susceptibles d’avoir un impact plus large et d’affecter les utilisateurs sur les deux plateformes. Vous ne pouvez pas vraiment tout avoir — mais vous pouvez certainement atténuer le risque en sur-indexant les tests de bout en bout (E2E).
• Comme pour tout découpage d’une solution orientée utilisateur le long d’une fracture technologique horizontale, il y a un risque de créer des silos de connaissances et de perdre une partie de la concentration technique sur les expériences utilisateur de bout en bout. Vous devez en être conscient et atténuer intentionnellement le risque. Parmi les mesures les plus efficaces :
  • Aligner les sous-équipes pour livrer des fonctionnalités plutôt que des couches technologiques.
  • Former les ingénieurs mobiles pour devenir « full stack », c’est-à-dire capables de déboguer, supporter et ingénier à travers la base de code Rust et les plateformes natives.

Et ensuite pour la Transformation de l’ingénierie

Dès le tout début de ce projet, il était clair que les enjeux s’étendaient bien au-delà de Proton Mail seul. Appliquer avec succès cette pile technologique à l’application phare de Proton a toujours été prévu comme la première étape d’un voyage plus long — un voyage qui verrait finalement cette approche déployée sur le reste de notre écosystème mobile.

Ce scénario est en train de se dérouler. Au moment où j’écris cet article, nos SDKs de Compte et de Paiement, ainsi que la prochaine génération d’applications mobiles Proton Calendar, sont en cours de réécriture conformément à cette nouvelle direction technique.

Cela marque le début d’une deuxième vague de transformation de l’ingénierie — une évolution qui élargit le plan technologique avec un cadre architectural conçu pour rendre la réutilisation des composants plus facile, non seulement entre les plateformes mais aussi entre les produits. Bien que cette transition ne se produise pas du jour au lendemain, elle est fondamentale pour construire l’écosystème parfaitement intégré et axé sur la confidentialité que nos clients attendent de Proton.

(1) : Simon Lewis,« A strategy for application implementation on multiple platforms », 2023.