Changer de téléphone est une routine jusqu’au moment où l’on arrive à l’application d’authentification. Les contacts, les photos et les messages ont leurs propres chemins de migration, et la plupart des gens les ont déjà empruntés. Les codes à six chiffres qui se tiennent entre vous et une douzaine de comptes suivent d’autres règles, et le moment de le découvrir n’est pas après avoir effacé et cédé l’ancien appareil. Si ce que vous voulez est une application de messagerie sur un second téléphone plutôt qu’un remplaçant de celui-ci, lier un appareil est une décision distincte — une décision qui ne déplace pas les entrées d’authentification et ne supprime pas le besoin de cette migration.
TL;DR : Il n’existe pas une procédure unique de migration d’une application d’authentification. Google Authenticator peut synchroniser les entrées avec votre compte Google ou les déplacer par un export effectué sur l’appareil, et supprimer une entrée synchronisée la retire de tous les appareils synchronisés. Microsoft Authenticator sauvegarde et restaure uniquement au sein d’un même type d’appareil, et pour les comptes professionnels, scolaires et sans mot de passe, la restauration ramène le nom du compte tout en exigeant une nouvelle connexion. Gardez l’ancien appareil en état de marche et connecté jusqu’à avoir confirmé à la fois que le nouvel appareil vous connecte et qu’une voie de récupération indépendante existe.
Trois mécanismes, pas une seule procédure
L’expression « déplacer mon application d’authentification » recouvre plusieurs choses différentes, et c’est dans ces différences que les gens se retrouvent bloqués.
Certaines entrées sont synchronisées, tenues à jour entre vos appareils et un compte plutôt que d’exister sur un seul téléphone. Certaines sont exportées puis importées, déplacées délibérément d’un appareil à un autre. Certaines sont sauvegardées puis restaurées, ce qui semble équivalent à une synchronisation mais comporte des restrictions que la synchronisation n’a pas. Et certaines entrées ne se déplacent pas du tout sous une forme exploitable — ce qui arrive sur le nouveau téléphone est un nom dans une liste, l’authentification elle-même restant à rétablir.
Deux éditeurs, deux conceptions, et à l’intérieur de chacune plusieurs cas. Déterminer dans quel cas se trouve chacune de vos entrées, c’est toute la tâche.
Google Authenticator : synchronisation et export manuel
Google documente les deux voies sur sa page consacrée à l’obtention de codes de validation avec Google Authenticator.
La synchronisation. Lorsque vous vous connectez à votre compte Google depuis Google Authenticator sur un nouvel appareil, vos codes sont automatiquement synchronisés vers cet appareil. Cela suppose que ces entrées aient été synchronisées avec ce même compte au départ : la synchronisation tient à jour des copies sur vos appareils en phase avec le compte, donc une entrée qui n’a jamais été synchronisée ne vous y attend pas.
Le transfert manuel. Là où les entrées ne sont pas synchronisées, c’est l’ancien appareil qui les exporte : depuis son menu, Transférer des comptes, puis Exporter des comptes, en sélectionnant celles à déplacer, ce qui produit des codes QR. Le nouvel appareil utilise Transférer des comptes puis Importer des comptes pour les scanner. Cette voie exige que l’ancien appareil fonctionne et soit entre vos mains, ce qui est une raison de ne pas s’en séparer trop tôt.
La conséquence qui piège. Google indique que si vos codes sont synchronisés, les supprimer les retire de tous les appareils où ils sont synchronisés. Cela compte parce que le réflexe naturel, au moment d’en finir avec un ancien téléphone, est de faire le ménage en retirant les comptes de l’application avant de laisser partir l’appareil. Pour des entrées synchronisées, ce n’est pas un ménage ; c’est une suppression partout, y compris sur le téléphone que vous venez de configurer. Se séparer d’un appareil et supprimer des entrées d’authentification sont deux actions distinctes et doivent le rester.
Microsoft Authenticator : sauvegarde, restauration et le mur entre plateformes
La conception de Microsoft est une sauvegarde plutôt qu’une synchronisation, et elle comporte une restriction qu’il vaut mieux connaître avant de choisir votre nouveau téléphone.
Où réside la sauvegarde. Les indications de Microsoft sur la sauvegarde de vos comptes décrivent une sauvegarde vers un compte personnel Microsoft sur Android, et sur iOS l’utilisation d’iCloud avec iCloud Drive, le trousseau iCloud et la sauvegarde iCloud activés. Les entrées tierces qui génèrent un code à usage unique toutes les trente secondes sont incluses. Restaurer exige donc une sauvegarde réellement effectuée, vers un espace que vous pouvez encore atteindre, depuis une plateforme compatible — et atteindre cet espace peut lui-même demander de se connecter, ce qu’il faut remarquer si le second facteur de ce compte est le téléphone que vous remplacez.
Le mur du même type d’appareil. La page de Microsoft sur la restauration des identifiants de compte est explicite : la sauvegarde et la restauration ne fonctionnent qu’au sein d’un même type d’appareil, et des comptes sauvegardés sur un appareil iOS ne peuvent pas être restaurés sur un appareil Android. Si vous changez de plateforme, cette voie ne fait pas passer vos entrées, et il faut prévoir de reconfigurer la méthode d’authentification sur chacun de vos comptes existants plutôt que de restaurer.
Un nom restauré n’est pas une méthode qui fonctionne. C’est la subtilité la plus utile à intégrer. Pour les comptes professionnels ou scolaires, Microsoft indique que seul le nom du compte est restauré et que vous devrez vous reconnecter. Cela vaut aussi pour les comptes personnels configurés pour une connexion sans mot de passe. Les entrées qui utilisent un code à usage unique se restaurent en générateurs de codes fonctionnels ; les autres arrivent sous forme d’une ligne dans une liste, rassurante à voir et qui n’authentifie encore rien. Voir le nom du compte sur le nouveau téléphone n’est pas la confirmation qu’il fonctionne.
Ce que chaque situation vous donne
| Votre entrée | Ce qui arrive sur le nouveau téléphone | Ce qu’il reste à faire | À confirmer d’abord |
|---|---|---|---|
| Google, entrées réellement synchronisées avec le compte auquel vous vous connectez | Les codes, à la connexion à ce même compte | Rien, si la connexion les a fait apparaître | Que ces entrées y étaient bien synchronisées, et que les codes sont acceptés |
| Google, non synchronisées | Rien tant que vous n’exportez pas depuis l’ancien appareil | Exporter et importer pendant que l’ancien téléphone fonctionne encore | Que l’ancien appareil est disponible et en état de marche |
| Microsoft, même plateforme, entrée à code à usage unique, sauvegarde atteignable | Un générateur de codes fonctionnel | Rien, si les codes sont acceptés | Que la sauvegarde est accessible, et qu’un code est accepté et pas seulement affiché |
| Microsoft, compte professionnel ou scolaire, ou sans mot de passe | Le nom du compte seulement | Une nouvelle connexion pour rétablir la méthode | Que vous pouvez mener cette connexion à bien avant de vous séparer de l’ancien téléphone |
| Microsoft, changement de plateforme | Rien n’est restauré d’un type d’appareil à l’autre | Reconfigurer la méthode d’authentification directement sur chaque compte existant | Sur quels comptes existants il faudra reconfigurer la méthode |
| Tout service où l’application d’authentification est l’unique facteur | Ce que donnent les lignes ci-dessus | Établir une seconde voie avant de changer quoi que ce soit | Que la voie de récupération en est une que vous pouvez réellement emprunter — une page d’aide publiée n’est pas un facteur que vous détenez |
À confirmer avant de vous séparer de l’ancien appareil
L’ordre compte plus que les étapes prises une à une, et le principe est unique : rien d’irréversible n’arrive à l’ancien téléphone tant que le nouveau n’est pas prouvé.
Gardez l’ancien appareil en état de marche et connecté. Pas simplement non effacé — encore fonctionnel et détenant encore ses sessions. C’est votre recours pendant tout le processus, et son utilité ne prend fin qu’une fois confirmé à la fois que chaque méthode authentifie sur le nouvel appareil et que vous détenez une voie de récupération indépendante.
Connectez-vous sur le nouvel appareil, pour de vrai. Pas « l’entrée est apparue dans la liste » mais une authentification réelle avec chaque compte qui compte. C’est l’étape qui distingue un nom restauré d’une méthode qui fonctionne, et c’est le seul moyen de les différencier.
Confirmez une voie de récupération indépendante pour chaque compte. Quelque chose que vous détenez réellement — des codes de secours, un second facteur encore utilisable, ou une voie de récupération dont vous avez confirmé qu’elle s’applique à vous. Une page d’aide publiée n’est pas un facteur en votre possession. Si ce second facteur est un code SMS envoyé vers un numéro loué, vérifiez ce que ce numéro peut encore faire avant de compter dessus. Guettez le cas circulaire : si la seule entrée vers le compte cloud qui héberge votre sauvegarde est un code venant du téléphone dont vous vous séparez, cette voie se referme en même temps que le téléphone. Cela mérite d’être vérifié même quand la migration paraît s’être parfaitement déroulée.
C’est seulement ensuite que vous vous séparez de l’ancien appareil, en suivant les indications du fabricant pour ce que vous comptez en faire — le garder, le céder ou le renvoyer. Quelle que soit cette voie, n’y arrivez pas en supprimant les entrées d’authentification une à une depuis l’application, pour la raison donnée plus haut. L’ancien téléphone détient aussi d’autres données et d’autres comptes : s’en défaire est donc une décision plus large que cette migration.
Une chose qui n’a sa place nulle part dans cette séquence : changer de SIM, porter un numéro ou acheter une nouvelle ligne ne déplace pas les entrées d’authentification. Ces secrets résident dans l’application et sa sauvegarde, pas sur la SIM. Si un compte utilise aussi le SMS comme second facteur, cette partie-là suit bien le numéro, et les deux sont faciles à confondre — mais ce sont des systèmes distincts avec des modes de défaillance distincts. Ce volet SMS a ses propres conditions : il faut qu’une ligne puisse recevoir des messages, ce qu’un forfait data uniquement ne peut pas, et un code qui arrive doit encore atteindre le champ, ce qui est un problème distinct de plus.
Deux situations à dérouler
Les deux sont hypothétiques, écrites pour montrer le raisonnement plutôt que pour rapporter un cas réel.
Le ménage qui a supprimé les codes. Quelqu’un configure un nouveau téléphone, se connecte à Google Authenticator et voit ses entrées arriver. Satisfait, il prend l’ancien appareil et y supprime les comptes depuis l’application avant de le laisser partir. Parce que ces entrées étaient synchronisées, la suppression n’est pas locale à l’ancien appareil. L’erreur de raisonnement consiste à traiter l’ancienne application comme une copie séparée alors que la synchronisation en fait une vue du même ensemble. La séquence sûre est de confirmer que chaque méthode authentifie sur le nouveau téléphone et qu’une voie de récupération indépendante est en main, et seulement ensuite de traiter l’ancien appareil selon les indications de l’éditeur ou du fabricant, plutôt qu’en vidant les entrées depuis l’application d’authentification.
Le nom de compte qui n’authentifiait rien. Quelqu’un d’autre remplace un iPhone par un autre iPhone, restaure Microsoft Authenticator depuis la sauvegarde iCloud et voit son compte professionnel dans la liste. Il efface l’ancien téléphone. À la demande de connexion suivante, il trouve l’entrée présente mais inutilisable, parce que pour les comptes professionnels et scolaires la restauration ramène le nom et exige encore une nouvelle connexion — une connexion qu’il ne peut plus mener facilement à bien, puisque la voie qu’il aurait empruntée passait par l’appareil qu’il vient d’effacer. Rien n’a dysfonctionné ; la restauration a fait exactement ce qu’elle documente. Ce qui manquait, c’était l’étape consistant à se connecter réellement sur le nouveau téléphone pendant que l’ancien fonctionnait encore.
Limites de ce guide
Ce texte décrit ce que Google et Microsoft publient à propos de leurs propres applications. Il ne couvre pas les autres applications d’authentification, qui utilisent d’autres conceptions de sauvegarde et de transfert, et il ne doit pas leur être généralisé.
Il ne propose pas d’étapes de réinitialisation, de réinstallation ou d’effacement des données, et il ne vous dit pas comment vous défaire de l’ancien téléphone. Ces opérations interagissent avec exactement les entrées que vous cherchez à préserver, et avec tout le reste de cet appareil : la documentation à jour de l’éditeur ou du fabricant est le bon endroit pour cela.
La récupération d’un compte est régie par chaque service de destination, pas par l’application d’authentification. Si un compte devient inaccessible, la voie de retour passe par le processus de récupération propre à ce service et non par quoi que ce soit décrit ici.
Les codes QR d’export, les clés de configuration et les codes de secours équivalent aux secrets eux-mêmes. Ce ne sont pas des pièces à joindre à une demande de support, ni quelque chose à photographier pour qui que ce soit, ni quelque chose à nous envoyer ou à envoyer à qui prétend représenter un service. Si on vous en demande un, c’est une raison de vous arrêter. La forme générale de ce conseil se trouve dans que faire d’un code de vérification que vous n’avez pas demandé.
Nos réponses d’aide couvrent le volet commande, et un ticket de support est la voie pour tout ce qui concerne spécifiquement une commande passée chez nous.
FAQ
Mes codes d’authentification passeront-ils automatiquement sur un nouveau téléphone ?
Cela dépend de l’application et de la façon dont chaque entrée a été configurée. Les entrées Google Authenticator synchronisées avec votre compte Google arrivent quand vous vous connectez sur le nouvel appareil ; celles qui ne sont pas synchronisées exigent un export depuis l’ancien téléphone. Microsoft Authenticator restaure depuis une sauvegarde, mais uniquement sur le même type d’appareil et, pour certains types de comptes, uniquement le nom du compte. Traitez « ça va passer tout seul » comme quelque chose à vérifier plutôt qu’à supposer.
Je passe d’iPhone à Android. Microsoft Authenticator va-t-il se restaurer ?
Pas par cette voie. Microsoft indique que la sauvegarde et la restauration ne fonctionnent qu’au sein d’un même type d’appareil et que des comptes sauvegardés sur iOS ne peuvent pas être restaurés sur Android. Prévoyez de reconfigurer la méthode d’authentification directement sur chacun de vos comptes existants, et faites-le pendant que l’ancien téléphone fonctionne encore.
Puis-je supprimer les comptes de mon ancien téléphone une fois le nouveau configuré ?
Pas comme étape de ménage, si les entrées sont synchronisées. Google indique que supprimer des codes synchronisés les retire de tous les appareils où ils sont synchronisés, ce qui inclut le téléphone que vous venez de configurer. Confirmez que le nouvel appareil fonctionne et que vous détenez une voie de récupération indépendante, puis séparez-vous de l’ancien téléphone selon les indications du fabricant plutôt qu’en retirant les entrées depuis l’application.
Le compte apparaît sur mon nouveau téléphone. Cela veut-il dire qu’il fonctionne ?
Pas nécessairement. Pour les entrées professionnelles, scolaires et sans mot de passe, Microsoft restaure le nom du compte et exige encore une nouvelle connexion. Le seul moyen de distinguer une méthode qui fonctionne d’un nom affiché est de s’en servir pour se connecter pendant que vous avez encore l’ancien appareil comme recours.
Changer de SIM ou de numéro de téléphone déplace-t-il mon application d’authentification ?
Non. Les entrées d’authentification résident dans l’application et sa sauvegarde, pas sur la SIM : changer de numéro ou de ligne ne les déplace donc pas. Si un compte utilise aussi le SMS comme second facteur, cette partie-là suit bien le numéro — d’où la facilité de confondre les deux, même s’ils échouent de façons différentes.
Et si j’ai déjà effacé l’ancien téléphone et que les codes n’ont pas été transférés ?
La récupération service par service n’est pas nécessairement la première étape. Vérifiez d’abord les voies des éditeurs : si des entrées Google Authenticator étaient synchronisées avec votre compte Google et que vous pouvez encore vous y connecter, la connexion sur le nouvel appareil peut les ramener ; si une sauvegarde Microsoft Authenticator existe, est atteignable et a été faite sur le même type d’appareil, la restaurer peut ramener certaines entrées — sous les mêmes limites que ci-dessus, puisque les entrées professionnelles, scolaires et sans mot de passe se restaurent sous forme de nom et exigent encore une nouvelle connexion, et que la restauration ne rétablit pas toutes les méthodes d’authentification. Faites cela sans détruire des sessions que vous détenez encore. Ce n’est que là où aucune synchronisation ni sauvegarde applicable n’aide, et où aucune méthode indépendante que vous auriez enregistrée n’est disponible, que cela devient une affaire de récupération propre à chaque service ou de voie administrateur, un compte à la fois.