Uber est la plus grande entreprise de covoiturage au monde. Elle transporte des millions de personnes, mais propose également 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 unique basé sur un 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é Restaurer les identifiants, 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 prototypé le code, l'équipe a introduit la prise en charge de la restauration des identifiants dans l'application Uber Rider. Pour vérifier que la restauration des identifiants permet de réduire les frictions lors des reconnexions, l'équipe Uber a mené un test A/B concluant pendant cinq semaines. L'intégration a permis de réduire le nombre de connexions manuelles, ce qui, projeté sur l'énorme base d'utilisateurs d'Uber, devrait éliminer environ quatre millions de connexions manuelles par an.

Éliminer les frictions de connexion avec la restauration des identifiants

Des tentatives de restauration de compte sur de nouveaux appareils ont 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, de l'appareil source vers l'appareil de destination. Étant donné que 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 les frictions lors des processus 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 appareils.

"Certains utilisateurs n'utilisent pas l'application Uber tous les jours, mais ils s'attendent à ce qu'elle fonctionne 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 décourageante."

Grâce à la fonctionnalité Restaurer les identifiants, les ingénieurs ont pu combler ce fossé. 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 de la procédure d'intégration standard. Ce processus s'appuie sur 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 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 charge 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 celui-ci, tandis que les clés de récupération sont gérées par le système et masquées dans l'interface utilisateur.

"Avec l'adoption de la fonctionnalité Restaurer les identifiants dans l'application Uber pour les passagers, nous avons constaté une utilisation régulière", a déclaré Thomás. "En moyenne, 10 000 utilisateurs uniques par jour se sont connectés avec la fonctionnalité Restaurer les identifiants lors de la phase de déploiement actuelle. Ils ont bénéficié d'une expérience fluide lors de la première ouverture de l'application sur un nouvel appareil. Nous prévoyons que ce nombre doublera une fois que nous aurons déployé la fonctionnalité auprès de l'ensemble de nos utilisateurs."

Points à observer avant de configurer des événements

"L'intégration a été assez facile, avec quelques 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 petites modifications. Par conséquent, il nous suffisait 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 la clé d'accès en mode silencieux. 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 rencontré plusieurs difficultés lors de l'implémentation, qu'il s'agisse de choisir le bon point d'entrée ou de gérer le cycle de vie des identifiants sur le backend.

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

Les ingénieurs ont soigneusement pesé les avantages et les inconvénients d'une expérience utilisateur parfaitement fluide et d'une implémentation simple lors de la sélection du point d'entrée Restore Credentials à utiliser pour la récupération. En fin de compte, ils ont opté pour une solution qui offrait 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", a déclaré Thomás. "Le point d'entrée de connexion en arrière-plan est plus fluide 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 vaste 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.

Relever les défis côté serveur

Quelques difficultés côté serveur sont apparues lors de l'intégration aux API WebAuthn de 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 de compte d'un utilisateur. Aucune de ces hypothèses ne fonctionnait pour les clés de restauration des identifiants 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 des identifiants de restauration

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'est pas signalée au backend, une clé inutilisée reste 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 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.
• Prise en charge de plusieurs appareils : un utilisateur pouvant disposer de plusieurs appareils (et pouvant 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 relevé ces défis en établissant des règles pour la suppression des clés côté serveur en fonction de l'enregistrement et de l'utilisation de 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, un test A/B de cinq semaines (temps nécessaire pour 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 avec la fonctionnalité Restaurer les identifiants

En éliminant les connexions manuelles sur les nouveaux appareils, Uber a conservé des utilisateurs qui auraient pu abandonner le processus 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 :

• Une diminution de 3,4 % des connexions manuelles (OTP par SMS, mots de passe, connexion via les réseaux sociaux).
• Réduction de 1,2 % des dépenses pour les connexions nécessitant un OTP par SMS.
• Le taux d'accès d'Uber a augmenté de 0,575 % (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 trajets. 

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

Lors de la configuration d'un nouvel appareil, les utilisateurs peuvent restaurer les données et les identifiants des applications à 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'utilisateur est automatiquement connecté à l'application lors de son premier lancement sur le nouvel appareil.

L'impact invisible, mais considérable, de la fonctionnalité Restaurer les identifiants

Au cours des prochains mois, Uber prévoit d'étendre l'intégration de la fonctionnalité Restaurer les identifiants. En se basant sur les résultats du test, 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, ils s'efforcent de fidéliser leur clientèle et de la satisfaire davantage, trajet après trajet.

"L'intégration de RestoreCredentials de Google nous a permis d'offrir l'expérience fluide et intuitive que nos utilisateurs attendent sur un nouvel appareil", a déclaré 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 de connexion est essentielle pour l'engagement et la fidélisation des utilisateurs."

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

Découvrez comment faciliter la connexion lors du changement d'appareil avec Restaurer les identifiants et consultez l'article de blog pour en savoir plus. Dans la dernière version Canary d'Android Studio Otter, vous pouvez valider votre intégration, car de nouvelles fonctionnalités vous aident à simuler les mécanismes de sauvegarde et de restauration. 

Si vous débutez avec Credential Manager, vous pouvez consulter notre documentation, notre atelier de programmation et nos exemples officiels pour vous aider à l'intégrer.