Comment Uber réduit de 4 millions par an le nombre de connexions manuelles grâce à l'API Restore Credentials

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 cruciale pour son succès. Lorsque les utilisateurs changent d'appareil, ils s'attendent à une transition fluide, sans avoir à se reconnecter à l'application Uber ni à passer par une authentification par mot de passe à usage unique envoyé 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 se sont tournés vers la fonctionnalité Restore Credentials, un outil essentiel à une époque où 40% des Américains changent de smartphone chaque année. Après avoir évalué la demande des utilisateurs et créé un prototype de code, l'équipe a intégré la fonctionnalité Restaurer les identifiants dans l'application Uber Rider. Pour vérifier que la restauration des identifiants permet de simplifier la reconnexion, l'équipe Uber a mené un test A/B concluant sur une période de cinq semaines. L'intégration a permis de réduire le nombre de connexions manuelles. En projetant ce résultat sur l'ensemble de la base d'utilisateurs d'Uber, on estime que cela permettra d'éliminer quatre millions de connexions manuelles par an.

Éliminer les frictions de connexion avec la restauration des identifiants

Par le passé, des tentatives de restauration de compte sur de nouveaux appareils ont été effectuées à l'aide de solutions telles que la sauvegarde de données standard et BlockStore. Toutefois, ces deux solutions nécessitaient de partager directement les jetons d'authentification, de l'appareil source vers l'appareil de destination. Comme les informations des 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 les 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 fluides entre les appareils.

"Certains utilisateurs n'utilisent pas l'application Uber tous les jours, mais ils s'attendent à ce qu'elle fonctionne lorsqu'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 commander une course sur votre nouveau téléphone Android peut être une expérience désagréable et frustrante."

Grâce à 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 fluide et silencieuse vers le nouvel appareil lorsque l'utilisateur restaure les données de son application au cours du processus d'intégration standard. Ce processus exploite le mécanisme de sauvegarde et de restauration natif de l'OS Android, ce qui garantit le transfert sécurisé de la clé de restauration ainsi que des données de l'application. Cette approche simplifiée garantit un transfert de compte simple et sûr, 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 cruciale, car les clés d'accès créées par l'utilisateur peuvent être gérées directement par l'utilisateur, tandis que les clés de restauration sont gérées par le système et masquées dans l'interface utilisateur.

"Depuis l'adoption de la restauration des identifiants dans l'application Uber pour les passagers, nous avons constaté une utilisation constante", a déclaré Thomás. "En moyenne, 10 000 utilisateurs uniques par jour se sont connectés avec Restore Credentials au cours de la phase de déploiement actuelle. Ils ont bénéficié d'une expérience fluide lorsqu'ils ont ouvert l'application pour la première fois sur un nouvel appareil. Nous pensons que ce nombre va doubler une fois que nous aurons étendu le déploiement à l'ensemble de notre base d'utilisateurs."

Points à observer avant de configurer des événements

"L'intégration a été assez simple, avec des ajustements mineurs côté Android en suivant l'exemple de code et la documentation", a déclaré 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 petits ajustements. Il nous a donc 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 processus 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 une clé d'accès de manière silencieuse. Si la clé de restauration est trouvée, elle est immédiatement utilisée pour connecter automatiquement l'utilisateur, sans qu'il ait besoin de se connecter manuellement."

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

Choisir le point d'entrée "Restaurer les identifiants"

Les ingénieurs ont soigneusement pesé le pour et le contre entre une expérience utilisateur parfaitement fluide et la simplicité de mise en œuvre lorsqu'ils ont choisi le point d'entrée Restore Credentials à utiliser pour la récupération. En fin de compte, l'entreprise a privilégié une solution offrant un équilibre idéal.

"Cela peut se produire au 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 fluide pour l'utilisateur, mais il présentait des difficultés avec les opérations en arrière-plan et nécessitait l'utilisation de l'API BackupAgent, ce qui aurait augmenté la complexité d'un codebase aussi volumineux que celui d'Uber." Ils ont décidé d'implémenter la fonctionnalité lors du premier lancement de l'application, qui était nettement plus rapide que la connexion manuelle.

Relever les défis côté serveur 

Quelques difficultés côté serveur sont survenues 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 listés dans les paramètres du compte d'un utilisateur. Or, aucune de ces hypothèses ne s'appliquait aux clés d'identifiants de restauration 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 identifiants de restauration 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 pour gérer les clés d'identification sur le backend, avec l'aide spécialisée de Ryan O'Laughlin, ingénieur backend :

• Éviter les clés orphelines : l'un des principaux défis 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 n'envoie pas de signal au backend, elle laisse une clé inutilisée sur le serveur.
• Équilibrer la durée de vie des clés : les clés avaient besoin d'une "durée de vie" suffisamment longue pour gérer les cas particuliers. 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.
• Prise en charge de plusieurs appareils : étant donné qu'un utilisateur peut posséder plusieurs appareils (et lancer une sauvegarde et une restauration depuis n'importe lequel d'entre eux), le backend devait prendre en charge plusieurs identifiants de restauration par utilisateur (un pour chaque appareil).

Les ingénieurs d'Uber ont résolu ces problèmes en établissant des règles pour la 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 seulement deux mois de développement et de test. Ensuite, un test A/B de cinq semaines (le temps de valider la fonctionnalité auprès des utilisateurs) s'est déroulé sans problème et a donné des résultats indéniables.  

Éviter l'abandon des utilisateurs grâce à la restauration des identifiants

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

• une diminution 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 liées aux connexions nécessitant un OTP par SMS.
• Augmentation de 0,575% du taux d'accès d'Uber (% d'appareils ayant réussi à accéder à l'écran d'accueil de l'application).
• 0,614% d'augmentation du nombre d'appareils ayant effectué des trajets. 

Aujourd'hui, la fonctionnalité Restore Credentials est en passe de devenir un composant standard de l'application Uber pour les passagers, avec plus de 95% des utilisateurs du groupe expérimental enregistrés. 

Lors de la configuration d'un nouvel appareil, les utilisateurs peuvent restaurer les données et les identifiants d'une application à partir d'une sauvegarde. Une fois qu'Uber a été 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, ils estiment que ce changement permettra d'éliminer quatre millions de connexions manuelles par an. En simplifiant l'accès à l'application et en éliminant un point de friction majeur, l'entreprise développe activement une clientèle plus satisfaite et plus fidèle, un trajet à la fois.

"L'intégration de RestoreCredentials de Google nous a permis d'offrir l'expérience fluide et sans effort que nos utilisateurs attendent sur un nouvel appareil", a déclaré Matt Mueller, responsable produit (Core Identity) 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 la connexion lors d'un changement d'appareil avec Restore Credentials et lisez l'article de blog. Dans la dernière version Canary d'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 officielle, notre atelier de programmation et nos exemples pour vous aider à l'intégrer.