Le SMS est-il un second facteur acceptable ?

C'est mieux que rien, mais c'est le plus faible : interception, échange de carte SIM et dépendance à l'opérateur. Une application d'authentification ou une clé physique est nettement préférable sur les comptes à privilèges.

Faut-il imposer le changement de mot de passe régulier ?

Non. Les recommandations actuelles privilégient des mots de passe longs, uniques et vérifiés contre les fuites connues, avec un second facteur. Le changement forcé produit surtout des variantes prévisibles.

SSO ou comptes locaux ?

Le SSO d'entreprise simplifie l'arrivée et le départ des collaborateurs et centralise la politique de sécurité. Pour une application destinée à des clients externes, des comptes locaux avec second facteur restent souvent plus simples et plus robustes.

Comment tester la sécurité des accès ?

En tentant explicitement d'accéder aux données d'un autre utilisateur, d'appeler des points d'API réservés à un rôle supérieur et de réutiliser un jeton révoqué. Ces trois tests révèlent la majorité des failles d'autorisation.

/ Guide technique · révisé le 2026-08-06

Système d'authentification : concevoir un accès sûr et utilisable

/ Réponse directe

L'authentification forte combine au moins deux facteurs indépendants : quelque chose que l'utilisateur connaît, possède ou est. Sur une application métier, elle doit s'accompagner d'une gestion rigoureuse des sessions, de rôles vérifiés côté serveur et d'une journalisation des accès — sans quoi le second facteur ne protège rien.

De quoi parle-t-on

Un système d'authentification répond à deux questions distinctes, souvent confondues : qui est l'utilisateur (authentification) et ce qu'il a le droit de faire (autorisation). La grande majorité des incidents que nous rencontrons proviennent de la seconde, pas de la première.

L'authentification forte, ou multifacteur, exige au moins deux facteurs de nature différente : un mot de passe, un code temporaire généré par une application ou une clé physique, une empreinte. Un mot de passe suivi d'une question secrète ne constitue pas une authentification forte : les deux relèvent du même facteur.

Le sujet critique reste ensuite la session : durée de validité, renouvellement, révocation immédiate en cas de départ, et vérification systématique des droits à chaque appel serveur. Une interface qui masque un bouton n'est pas un contrôle d'accès.

Obligations

Deux facteurs de nature différente

Mot de passe plus code temporaire, clé de sécurité ou biométrie. Le SMS reste préférable à l'absence de second facteur mais demeure le plus vulnérable.

Contrôle d'accès côté serveur

Chaque requête vérifie les droits de l'utilisateur au niveau du serveur ou de la base de données. Aucune autorisation ne doit reposer sur l'interface.

Gestion des sessions

Durée limitée, rotation des jetons, révocation immédiate, et déconnexion effective de tous les appareils lors d'un départ ou d'une compromission.

Journalisation des accès

Connexions, échecs, changements de droits et consultations de données sensibles horodatés et conservés.

Récupération de compte maîtrisée

La procédure de récupération est souvent le maillon le plus faible : elle doit être aussi exigeante que la connexion elle-même.

Calendrier de mise en œuvre

ConceptionDéfinir les rôles, les données sensibles et le niveau d'exigence par population d'utilisateurs.
DéveloppementImplémenter le contrôle d'accès au niveau de la base de données, pas seulement dans l'application.
Avant productionTester l'élévation de privilèges, l'accès direct aux ressources d'autrui et la révocation de session.
ExploitationRevoir les habilitations à intervalle régulier et surveiller les échecs de connexion anormaux.

Checklist

☐Second facteur disponible et imposé aux comptes à privilèges
☐Politique de mot de passe fondée sur la longueur, pas sur la complexité cosmétique
☐Limitation du nombre de tentatives et temporisation
☐Contrôle d'accès vérifié côté serveur pour chaque requête
☐Isolation des données par utilisateur au niveau de la base
☐Sessions à durée limitée avec rotation des jetons
☐Révocation immédiate lors d'un départ
☐Procédure de récupération de compte sécurisée
☐Journalisation des accès sensibles
☐Revue périodique des habilitations

Erreurs fréquentes

Contrôler les droits uniquement dans l'interface

Masquer un bouton n'empêche personne d'appeler directement l'API. L'autorisation se vérifie côté serveur, systématiquement.

Stocker les rôles au mauvais endroit

Un rôle conservé dans le profil utilisateur modifiable par ce même utilisateur ouvre la porte à l'élévation de privilèges. Les rôles se stockent dans une table dédiée, non modifiable par l'utilisateur.

Sessions éternelles

Un jeton sans expiration reste valide après le départ d'un collaborateur ou le vol d'un appareil.

Récupération plus faible que la connexion

Un second facteur soigneusement conçu ne sert à rien si la procédure de mot de passe oublié permet de le contourner.

Questions fréquentes

Sources officielles

Pour aller plus loin

Faire auditer votre conformité WhatsApp

Ce guide est une synthèse opérationnelle destinée aux équipes techniques et dirigeantes. Il ne constitue pas un avis juridique : pour un dossier engageant, faites valider votre analyse par un conseil qualifié.