Authentification d'une application mobile, ce que chaque méthode vous engage à construire
Dans les cahiers des charges que nous recevons, la connexion tient en une ligne : « l'utilisateur se crée un compte ». C'est pourtant une décision qui touche le coût d'exploitation, le référentiel d'Apple et le RGPD. Quatre méthodes existent, et celle que nous rencontrons le plus souvent repose sur un canal que les autorités de sécurité déconseillent.
Quatre façons d'entrer, et ce que chacune suppose
Le couple identifiant et mot de passe reste le plus simple à construire. Il suppose tout ce qui vient avec : un écran de réinitialisation, un envoi d'e-mail transactionnel, une politique de longueur, et un support qui recevra des déblocages. Rien d'insurmontable. Mais cela fait un parcours, et un parcours se recette.
Le code à usage unique envoyé par SMS supprime le mot de passe, donc l'oubli du mot de passe. Il déplace la difficulté sur le numéro de téléphone, qui devient à la fois l'identifiant et le canal. Le fournisseur d'identité tiers, compte Apple ou compte Google, supprime l'un et l'autre, en échange d'une dépendance et d'une obligation de revue. La clé d'accès, enfin, s'appuie sur le déverrouillage du téléphone lui-même.
Aucune des quatre n'est meilleure dans l'absolu. Elles se choisissent selon qui se connecte, et depuis où. AquaPro Manager l'illustre bien : l'application Flutter équipe les techniciens de terrain, le back-office Next.js est tenu par les gérants et les managers, et la fiche du projet décrit une authentification par code à usage unique via Firebase Auth, avec App Check et une gestion des rôles gérant et technicien. Deux populations, un seul mécanisme d'entrée.
Le code par SMS est-il une authentification sûre ?
Non, et la réponse est écrite par le régulateur français. La CNIL classe le code à usage unique par SMS comme un facteur de possession dont le niveau de confiance doit être évalué au cas par cas, et elle juge le canal lui-même insuffisant. Seul, c'est un facteur unique. Associé à un autre facteur, il améliore la situation.
Sa recommandation sur l'authentification multifacteur, adoptée par la délibération du 20 mars 2025, lui consacre une section dont le titre résume la position : « L'OTP par SMS, un facteur de possession dont le niveau de confiance reste à évaluer ». Le constat qui suit est net : « La transmission d'un code OTP par SMS est une méthode d'authentification reposant sur la réception d'une valeur au moyen d'un canal qu'il est difficile de considérer comme apportant une sécurité satisfaisante, c'est pourquoi il est déconseillé par les autorités compétentes » (recommandation de la CNIL relative à l'authentification multifacteur). Les deux autorités citées en note sont l'ANSSI et le NIST.
La même page refuse pourtant de le condamner : « Malgré ces limites, l'authentification multifacteur mobilisant l'OTP par SMS et un autre facteur (d'une catégorie distincte) permet d'assurer un niveau de sécurité supérieur à l'authentification simple. » Autrement dit, le SMS n'est pas disqualifié comme second facteur. Il est disqualifié comme seule barrière devant des données qui méritent mieux.
La même recommandation désamorce une idée reçue que nous entendons souvent. Un code envoyé par courrier électronique ne vaut pas un code envoyé par SMS : il « ne peut être considéré comme un facteur de possession dans la mesure où il ne permet pas de prouver avec un niveau de confiance suffisamment élevé au vérifieur la possession d'un objet physique unique ». Un mot de passe suivi d'un code par e-mail est donc une vérification en deux étapes, et l'annoncer comme du multifacteur vous expose. Numéro de téléphone et adresse électronique restent par ailleurs des données personnelles, avec les obligations que détaille notre article sur le RGPD appliqué à une application mobile.
Ce qu'un code par SMS coûte à envoyer
C'est le poste que personne ne provisionne, parce que l'authentification passe pour un service gratuit. Chez Firebase, elle l'est presque entièrement : la page de tarifs marque toutes les méthodes comme incluses sur les deux plans, sauf une. La ligne « Phone Auth - All regions » porte la mention « Billed per SMS sent » (tarifs de Firebase).
La documentation technique est plus explicite encore. L'envoi des codes de vérification y est marqué « Pay as you go (Blaze) plan only », avec un plafond de « 3000 sent SMS/day » pour Firebase Authentication, et des limites par adresse IP de « 50 sent/minute, 500 sent/hour » (limites de Firebase Authentication). Trois conséquences pour un budget.
- le coût suit le nombre de connexions, et non le nombre d'utilisateurs : une application ouverte chaque matin envoie bien plus de SMS qu'une application ouverte une fois par mois ;
- une tentative échouée coûte autant qu'une réussie, puisque le SMS est parti ;
- le plan gratuit ne permet pas de tester la vraie méthode, ce qui avance la facturation au début du projet.
Ce plafond journalier compte d'ailleurs moins, sur une application de terrain, que les limites par minute et par heure. La journée commence pour tout le monde à la même heure, et les demandes de code arrivent toutes ensemble. C'est ce pic du matin, et non le volume de la journée, qui décide du dimensionnement.
Le code à usage unique a aussi un défaut d'exploitation que nous avons payé : il arrive par le réseau. Un utilisateur déconnecté sans réseau ne peut plus entrer du tout. C'est l'un des cinq points de notre article sur le fonctionnement hors ligne d'une application mobile, et c'est une variante de ce que la CNIL range sous le risque d'accès empêché.
Si vous proposez « se connecter avec Google », Apple impose une alternative
La règle 4.8 des App Review Guidelines est courte, méconnue, et elle change un périmètre. Elle dispose que toute application utilisant « a third-party or social login service (such as Facebook Login, Google Sign-In, Log in with X, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user's primary account with the app must also offer as an equivalent option another login service » présentant trois caractéristiques : collecte limitée au nom et à l'adresse électronique, possibilité de garder cette adresse privée, et pas de collecte des interactions à des fins publicitaires sans consentement (App Review Guidelines d'Apple, règles 4.8 et 5.1.1(v)).
Elle ne vise que le service tiers qui crée ou authentifie le compte principal : un OAuth qui sert seulement à relier un service externe n'est pas concerné. Mais dès qu'un tiers porte ce compte principal, il en faut un second qui remplit les trois conditions, et l'option disponible partout est le compte Apple. Ajouter un bouton Google en fin de projet, parce que l'intégration prend une heure, ajoute donc un second parcours, un écran de réconciliation de comptes et une recette.
La règle prévoit cinq dispenses, dont deux couvrent la plupart de nos projets. La première : « Your app exclusively uses your company's own account setup and sign-in systems. » Mot de passe ou code à usage unique maison, la règle ne s'applique pas. La troisième de la liste vise « an education, enterprise, or business app that requires the user to sign in with an existing education or enterprise account ». Lisez celle-là de près : elle exige un compte d'éducation ou d'entreprise déjà existant, et non le seul fait que l'organisation cliente provisionne les comptes dans votre application. Nous demandons donc toujours d'où vient le compte avant de conclure.
Notre position : sur un outil professionnel, nous déconseillons les fournisseurs tiers. Le compte appartient à l'employeur, et un départ ne doit pas emporter l'accès. Sur une application grand public, nous les recommandons, et nous intégrons le compte Apple dès la première version : l'ajouter ensuite oblige à fusionner des comptes, un chantier de données.
Faut-il obliger l'utilisateur à créer un compte ?
Dans le doute, non, et Apple en a fait une règle de revue plutôt qu'un conseil d'ergonomie. La règle 5.1.1(v) s'ouvre ainsi : « If your app doesn't include significant account-based features, let people use it without a login. » Elle enchaîne sur une obligation que beaucoup découvrent au moment de la soumission.
La voici : « If your app supports account creation, you must also offer account deletion within the app ». Ni formulaire de contact, ni adresse de support. Un chemin dans l'application. Cela se traduit par un écran, une confirmation, une décision sur ce qu'on efface et sur ce qu'on conserve par obligation comptable, et une recette. Prévue, cette ligne coûte deux jours. Oubliée, elle coûte un report de publication.
La même règle ajoute que les applications « may not require users to enter personal information to function, except when directly relevant to the core functionality of the app or required by law ». La question de cadrage devient donc : que peut faire un visiteur avant de s'identifier ? Daiky est en Flutter, publiée sur l'App Store, et Firebase y porte l'authentification, Firestore, le stockage, les notifications et App Check. Plus généralement, lire une étiquette a du sens pour quelqu'un qui n'a pas encore de compte, et cela se décide à la maquette.
Ce que nous recommandons, et ce que nous avons sous-estimé
Sur un outil métier utilisé en extérieur, nous recommandons le code à usage unique, malgré la réserve de la CNIL. Des techniciens qui ne retiennent pas de mot de passe se connecteront, et une méthode plus sûre que personne n'utilise correctement ne protège rien. Nous la compensons par une session longue, par App Check, et par des rôles qui limitent ce qu'un compte compromis atteindrait.
Sur des données plus sensibles, nous déconseillons le SMS comme barrière unique : il faut deux facteurs de catégories distinctes. La clé d'accès y répond mieux, avec une réserve que la CNIL formule bien : « Ces solutions pourraient être multifacteur dans le cas où la clé d'accès logicielle est associée à un terminal spécifique et verrouillé par code PIN ».
Le choix du socle, lui, ne dépend pas du framework. MamaSafe Food est en React Native avec Expo, publiée sur Google Play, et sa fiche indique Firebase pour l'authentification et le stockage. Le framework se décide d'un côté, le fournisseur d'identité de l'autre, et pas le même jour.
Deux choses nous ont coûté plus cher que prévu. La suppression de compte, d'abord, chiffrée comme un bouton alors que c'est une décision sur les données : ce qu'on efface, ce qu'on garde, et combien de temps. Ensuite, la réconciliation des identités, quand une même personne arrive par deux chemins et se retrouve avec deux comptes. Nous avons appris à fixer la règle d'unicité avant le premier écran.
Ce que nous ne savons pas vous promettre : qu'un utilisateur reçoive son SMS. La livraison dépend de l'opérateur, du pays et du routage, et nous n'avons pas d'accusé de réception exploitable. Nous prévoyons donc toujours une seconde voie d'entrée, même quand le client la juge inutile.
Questions fréquentes
Le code à usage unique par SMS est-il une authentification sûre ?
Combien coûte l'envoi des codes de connexion par SMS ?
Un code reçu par e-mail remplace-t-il un code reçu par SMS ?
Faut-il obliger les utilisateurs à créer un compte dans une application mobile ?
À votre place, nous ne commencerions pas par choisir une méthode. Nous écririons trois phrases : qui crée les comptes, ce qu'un visiteur peut faire sans en avoir un, et ce qui se passe quand quelqu'un perd son téléphone. Les quatre méthodes se classent alors d'elles-mêmes, et la facture avec.
C'est l'une des premières questions que nous posons sur une mission de développement d'application mobile : elle décide de l'écran que tout le monde verra en premier.
