Uber est la plus grande entreprise de covoiturage au monde. Elle transporte des millions de personnes d'un point A à un point B, tout en proposant des services de livraison de repas, de transport médical et de logistique de fret. La simplicité d'accès est essentielle à son succès. Lorsque les utilisateurs passent à un nouvel appareil, ils s'attendent à une transition fluide, sans avoir à se reconnecter à l'application Uber ni à s'authentifier à l'aide d'un mot de passe à usage unique par SMS. Ce renouvellement fréquent des appareils représente un défi, mais aussi une opportunité de fidéliser les utilisateurs. 

Pour assurer la continuité de l'expérience utilisateur, les ingénieurs d'Uber ont opté pour la fonctionnalité Restore Credentials, un outil essentiel à une époque où 40 % des Américains remplacent leur smartphone chaque année. Après avoir évalué la demande des utilisateurs et créé un prototype de code, ils ont intégré la prise en charge de Restore Credentials dans l'application Uber pour les passagers. Pour vérifier que la restauration des identifiants permet de réduire les frictions lors des reconnexions, l'équipe Uber a mené une expérience A/B concluante sur une période de cinq semaines. L'intégration a permis de réduire les connexions manuelles. Si l'on projette cette réduction sur l'immense base d'utilisateurs d'Uber, on estime qu'elle éliminera 4 millions de connexions manuelles par an.

Éliminer les frictions lors de la connexion avec Restore Credentials

Des tentatives de restauration de compte sur de nouveaux appareils avaient déjà été effectuées à l'aide de solutions telles que la sauvegarde régulière des données et BlockStore. Toutefois, ces deux solutions nécessitaient le partage direct de jetons d'authentification entre l'appareil source et l'appareil de destination. Comme les informations sur les jetons sont très sensibles, ces solutions ne sont utilisées que dans une certaine mesure, pour préremplir les champs de connexion sur l'appareil de destination et réduire certaines frictions lors des flux de connexion. Les clés d'accès sont également utilisées pour fournir une méthode de connexion sécurisée et rapide, mais leur nature initiée par l'utilisateur limite leur impact sur les transitions d'appareils fluides.

"Certains utilisateurs n'utilisent pas l'application Uber tous les jours, mais ils s'attendent à ce qu'elle fonctionne simplement quand ils en ont besoin", explique Thomás Oliveira Horta, ingénieur Android chez Uber. "Découvrir que vous êtes déconnecté au moment où vous ouvrez l'application pour demander une course sur votre nouveau téléphone Android peut être une expérience désagréable et dissuasive."

Avec Restore Credentials, les ingénieurs ont pu combler cette lacune. L'API génère un jeton unique sur l'ancien appareil, qui est transféré de manière transparente et silencieuse vers le nouvel appareil lorsque l'utilisateur restaure les données de son application lors du processus d'intégration standard. Ce processus exploite le mécanisme natif de sauvegarde et de restauration du système d'exploitation Android, ce qui garantit le transfert sécurisé de la clé de restauration avec les données de l'application. Cette approche simplifiée garantit un transfert de compte simple et sécurisé, qui répond aux exigences de sécurité d'Uber sans nécessiter d'intervention supplémentaire de l'utilisateur ni de frais de développement.

Remarque : Les clés de restauration et les clés d'accès utilisent la même implémentation de serveur sous-jacente. Toutefois, lorsque vous les enregistrez dans votre base de données, vous devez les différencier. Cette distinction est essentielle, car les clés d'accès créées par l'utilisateur peuvent être gérées directement par celui-ci, tandis que les clés de restauration sont gérées par le système et masquées dans l'interface utilisateur.

"Avec l'adoption de Restore Credentials dans l'application Uber pour les passagers, nous avons commencé à constater une utilisation cohérente", explique Thomás. "En moyenne, 10 000 utilisateurs uniques par jour se sont connectés avec Restore Credentials lors de la phase de déploiement actuelle. Ils ont bénéficié d'une expérience fluide lors de l'ouverture de l'application pour la première fois sur un nouvel appareil. Nous prévoyons que ce nombre doublera une fois que nous aurons étendu le déploiement à l'ensemble de notre base d'utilisateurs."

Observations concernant la mise en œuvre

"L'intégration a été assez simple, avec quelques ajustements mineurs côté Android en suivant l'exemple de code et la documentation", explique Thomás. "Notre application utilisait déjà Credential Manager pour les clés d'accès, et le backend n'a nécessité que quelques petites modifications. Par conséquent, il nous a suffi de mettre à jour la dépendance Credential Manager vers sa dernière version pour accéder à la nouvelle API Restore Credentials. Nous avons créé une clé de restauration via le même flux de création de clé d'accès. Lorsque notre application est lancée sur un nouvel appareil, elle recherche de manière proactive cette clé en tentant de récupérer silencieusement la clé d'accès. Si la clé de restauration est trouvée, elle est immédiatement utilisée pour connecter automatiquement l'utilisateur, en contournant toute connexion manuelle."

Tout au long du processus de développement, les ingénieurs d'Uber ont rencontré quelques difficultés lors de l'implémentation, depuis le choix du bon point d'entrée jusqu'à la gestion du cycle de vie des identifiants sur le backend.

Choisir le point d'entrée de Restore Credentials

Les ingénieurs ont soigneusement pesé les avantages et les inconvénients entre une expérience utilisateur parfaitement fluide et la simplicité de l'implémentation lors de la sélection du point d'entrée de Restore Credentials à utiliser pour la récupération. En fin de compte, ils ont privilégié une solution offrant un équilibre idéal.

"Cela peut se produire lors du lancement de l'application ou en arrière-plan lors de la restauration et de la configuration de l'appareil, à l'aide de BackupAgent", explique Thomás. "Le point d'entrée de connexion en arrière-plan est plus transparent pour l'utilisateur, mais il a posé des problèmes avec les opérations en arrière-plan et a nécessité l'utilisation de l'API BackupAgent, ce qui aurait entraîné une complexité accrue dans une base de code aussi volumineuse que celle d'Uber." Ils ont décidé d'implémenter la fonctionnalité lors du premier lancement de l'application, ce qui était beaucoup plus rapide que la connexion manuelle.

Résoudre les problèmes côté serveur

Quelques problèmes côté serveur sont survenus lors de l'intégration aux API WebAuthn du backend, car leur conception supposait que la validation de l'utilisateur serait toujours requise et que tous les identifiants seraient répertoriés dans les paramètres du compte d'un utilisateur. Aucune de ces hypothèses ne fonctionnait pour les clés Restore Credentials non gérées par l'utilisateur.

L'équipe Uber a résolu ce problème en apportant des modifications mineures aux services WebAuthn, en créant de nouveaux types d'identifiants pour distinguer les clés d'accès des clés Restore Credentials et en les traitant de manière appropriée.

Gérer le cycle de vie de Restore Credentials

Les ingénieurs d'Uber ont rencontré plusieurs difficultés dans la gestion des clés d'identifiants sur le backend, avec l'aide spécialisée de Ryan O'Laughlin, ingénieur backend :

• Empêcher les clés orphelines : un défi majeur consistait à définir une stratégie de suppression des clés publiques enregistrées pour éviter qu'elles ne deviennent "orphelines". Par exemple, la désinstallation de l'application supprime l'identifiant local, mais comme cette action ne signale pas le backend, elle laisse une clé inutilisée sur le serveur.
• Équilibrer la durée de vie des clés : les clés devaient avoir une durée de vie suffisamment longue pour gérer les cas extrêmes. Par exemple, si un utilisateur effectue une sauvegarde et une restauration, puis se déconnecte manuellement de l'ancien appareil, la clé est supprimée de cet ancien appareil. Toutefois, la clé doit rester valide sur le serveur pour que le nouvel appareil puisse toujours l'utiliser.
• Prendre en charge plusieurs appareils : comme un utilisateur peut disposer de plusieurs appareils (et peut lancer une sauvegarde et une restauration à partir de n'importe lequel d'entre eux), le backend devait prendre en charge plusieurs clés Restore Credentials par utilisateur (une pour chaque appareil).

Les ingénieurs d'Uber ont résolu ces problèmes en établissant des règles de suppression des clés côté serveur en fonction de l'enregistrement et de l'utilisation des nouveaux identifiants.

La fonctionnalité est passée de la conception à la livraison en deux mois seulement, grâce à un processus de développement et de test rapide. Ensuite, une expérience A/B de cinq semaines (temps nécessaire pour valider la fonctionnalité auprès des utilisateurs) s'est déroulée sans problème et a donné des résultats indéniables.  

Éviter l'abandon des utilisateurs avec Restore Credentials

En éliminant les connexions manuelles sur les nouveaux appareils, Uber a fidélisé les utilisateurs qui auraient pu abandonner le flux de connexion sur un nouvel appareil. Cette amélioration de la facilité d'utilisation pour les clients s'est traduite par un large éventail d'améliorations. Bien qu'elles puissent sembler minimes à première vue, leur impact est énorme à l'échelle de la base d'utilisateurs d'Uber :

• Réduction de 3,4 % des connexions manuelles (OTP par SMS, mots de passe, connexion via un réseau social)
• Réduction de 1,2 % des dépenses pour les connexions nécessitant un OTP par SMS
• Augmentation de 0,575 % du taux d'accès d'Uber (pourcentage d'appareils ayant réussi à accéder à l'écran d'accueil de l'application)
• Augmentation de 0,614 % du nombre d'appareils ayant effectué des courses 

Aujourd'hui, Restore Credentials est en passe de devenir une fonctionnalité standard de l'application Uber pour les passagers, avec plus de 95 % des utilisateurs du groupe test inscrits. 

Lors de la configuration d'un nouvel appareil, les utilisateurs peuvent restaurer les données et les identifiants de l'application à partir d'une sauvegarde. Une fois qu'Uber est sélectionné pour la restauration et que le processus en arrière-plan est terminé, l'application connecte automatiquement l'utilisateur lors du premier lancement sur le nouvel appareil.

L'impact invisible, mais massif, de Restore Credentials

Dans les mois à venir, Uber prévoit d'étendre l'intégration de Restore Credentials. En se basant sur les résultats de l'essai, l'entreprise estime que cette modification éliminera 4 millions de connexions manuelles par an. En simplifiant l'accès à l'application et en éliminant un point de friction majeur, elle fidélise activement sa base de clients, une course à la fois.

"L'intégration de RestoreCredentials de Google nous a permis d'offrir l'expérience transparente et intuitive que nos utilisateurs attendent sur un nouvel appareil", explique Matt Mueller, responsable produit (identité principale) chez Uber. "Cela s'est directement traduit par une augmentation mesurable des revenus, ce qui prouve que la réduction des frictions lors de la connexion est essentielle pour l'engagement et la fidélisation des utilisateurs."

Prêt à améliorer l'expérience de connexion de votre application ?

Découvrez comment faciliter une expérience de connexion fluide lors du changement d'appareil avec Restore Credentials et consultez cet article de blog pour en savoir plus. Dans la dernière version Canary de Android Studio Otter, vous pouvez valider votre intégration, car de nouvelles fonctionnalités permettent de simuler les mécanismes de sauvegarde et de restauration. 

Si vous ne connaissez pas Credential Manager, vous pouvez consulter notre documentation, notre atelier de programmation et nos exemples pour obtenir de l'aide sur l'intégration.