Le mot de passe seul n'est plus une frontière sûre. Les identifiants sont volés par phishing, réutilisés sur différents services, vendus dans des listes de fuites et essayés automatiquement sur les écrans de connexion exposés. C'est pourquoi le deuxième facteur est devenu une exigence fondamentale de l'architecture de sécurité moderne.
Mais ajouter de la MFA ne doit pas signifier placer un service de vérification distinct devant chaque application ni transférer entièrement l'instant le plus critique de l'authentification vers un cloud tiers. Un coût de licence permanent par utilisateur, une dépendance à un service externe, des panneaux d'administration différents et une structure de politique fragmentée finissent avec le temps par complexifier la sécurité au lieu de la simplifier.
Le problème plus important est l'approche MFA uniforme. Chaque application ne porte pas le même risque, chaque utilisateur n'accède pas depuis le même contexte, chaque session ne démarre pas au même niveau de confiance. Pour un wiki d'entreprise, le TOTP peut suffire ; les serveurs de production et l'accès au domain controller doivent demander le TOTP à chaque connexion et ne pas autoriser le raccourci d'appareil de confiance. Une application intranet à faible risque, elle, ne doit pas ralentir l'utilisateur à chaque connexion avec des écrans de code inutiles.
Le rôle de la MFA n'est pas de dresser sans cesse des obstacles devant l'utilisateur, mais d'élever le niveau de confiance lorsque le risque augmente. Pour cela, les décisions de vérification doivent être prises en fonction de l'application, du groupe d'utilisateurs, de l'état de l'appareil, de la localisation, du risque de session et de la sensibilité de la ressource accédée.
La MFA ne doit pas être une dépendance cloud distincte ; elle doit être une partie locale, graduée et auditable de la propre politique d'accès de l'organisation.
Trois types de facteurs sous un seul moteur de politique — tous fonctionnant sur la plateforme que vous possédez déjà.
TOTP, SMS et e-mail OTP fonctionnent tous avec le même modèle de configuration MFA. Les administrateurs déterminent depuis un seul endroit quelles méthodes seront généralement disponibles, lesquelles sont obligatoires pour un service et lesquelles l'utilisateur peut choisir — sans entrer dans des consoles de fournisseurs distinctes et sans payer de frais MFA par utilisateur.
Chaque service ou groupe de services déclare sa propre exigence MFA : pas de MFA, n'importe quel facteur, un facteur spécifique ou une combinaison de facteurs chaînés. Les applications intranet à faible risque restent sans friction ; les interfaces d'administration à haut risque imposent des exigences plus fortes ; celles du milieu ne sont pas contraintes à une protection excessive pour être en sécurité.
Lorsque la politique le permet, l'utilisateur peut marquer son appareil comme de confiance au moment de la MFA et sauter le deuxième facteur pendant une durée configurable — 30 jours par défaut. La confiance est liée à l'appareil, pas au réseau ; et elle peut être révoquée à la fois depuis la console d'administration et depuis la page de profil propre de l'utilisateur.
L'évaluation continue de la confiance surveille chaque session active. Si l'IP de l'opérateur change de pays, si le score de confiance du point de terminaison baisse ou si le comportement devient anormal, la passerelle peut imposer un nouveau challenge MFA sans relancer l'utilisateur depuis la page de connexion.
Trois canaux de livraison de facteurs, plus la politique et les outils de récupération qui les entourent.
Mots de passe à usage unique standard basés sur le temps, compatibles avec Google Authenticator, Microsoft Authenticator, Authy, 1Password, Bitwarden, Yubico Authenticator, FreeOTP et toute autre application RFC 6238. L'enregistrement fonctionne via un code QR rendu côté serveur ; le secret partagé est stocké de manière chiffrée, n'apparaît pas dans les journaux et n'est jamais affiché dans la console d'administration. L'algorithme, le nombre de chiffres et la fenêtre de validité sont configurés par profil.
Codes OTP livrés par SMS via le fournisseur SMS compatible HTTP que vous utilisez déjà — Twilio, Vonage, Infobip, MessageBird, l'API d'un opérateur local ou votre propre passerelle interne. La plateforme compose le message, appelle l'endpoint HTTP configuré et suit la livraison ; aucun revendeur SMS ne se place entre vos utilisateurs et les codes dont ils ont besoin.
Codes OTP livrés à l'adresse e-mail vérifiée de l'utilisateur. La page de connexion n'affiche l'adresse que sous forme masquée (par exemple y***@example.com) ; ainsi un attaquant qui a volé le mot de passe ne peut pas découvrir l'e-mail cible. Utile pour le canal de récupération et les flux de vérification à faible risque.
Lors de l'enregistrement, des codes de secours à usage unique sont remis aux utilisateurs TOTP — stockés de manière chiffrée, affichés une seule fois et consommés lorsque l'utilisateur perd l'accès à son téléphone. Chaque code consommé est marqué comme « utilisé » et n'est plus accepté ; les codes restants peuvent être régénérés par l'utilisateur ou l'administrateur.
Les administrateurs cartographient les exigences MFA par service, groupe de services ou résultat (outcome). Un service donné peut demander n'importe quel facteur, un facteur spécifique ou une chaîne — par exemple, le TOTP à la connexion plus une vérification SMS fraîche pour les opérations de transfert d'argent. La matrice est versionnée, auditable, et un changement à un seul endroit se propage partout où il s'applique.
Lorsqu'un seul facteur ne suffit pas, les services peuvent demander deux facteurs ou plus dans un ordre défini — par exemple le TOTP au début de session plus un code e-mail ou SMS frais lorsqu'une opération sensible est invoquée. La chaîne est pilotée par la politique et configurable ; les utilisateurs ne voient l'étape supplémentaire que lorsque le risque l'exige.
Un utilisateur qui a déjà complété le TOTP pour une session de routine peut être re-challengé en cours de session lorsqu'il atteint une ressource plus sensible. L'élévation est pilotée par la politique, ce n'est pas une reconnexion ; la session continue et l'utilisateur complète seulement le challenge supplémentaire sans perdre son contexte, ses fenêtres ouvertes ou son travail en cours.
Les utilisateurs enregistrent le TOTP, régénèrent les codes de secours, gèrent les appareils de confiance et vérifient leur adresse e-mail ou leur numéro de téléphone — sans ouvrir de ticket de support, depuis une seule page de profil. Les administrateurs conservent le pouvoir de forcer un réenregistrement lorsque l'authentification l'exige, de révoquer un appareil de confiance ou de réinitialiser un facteur.
L'infrastructure qui fait passer la MFA d'une case à cocher à une couche d'authentification défendable.
Les secrets TOTP, les codes de secours et les jetons d'appareil de confiance sont stockés chiffrés avec des clés gérées par la plateforme ; ils sont tenus à l'écart des données de session et de politique. Les opérateurs administrateurs voient les métadonnées (état d'enregistrement, dernière utilisation, nombre d'appareils de confiance) mais jamais le secret lui-même.
Chaque canal OTP tient son propre compteur de tentatives — saisies TOTP erronées, saisies de code SMS erronées, saisies de code e-mail erronées — et le canal est verrouillé lorsque les seuils configurables sont dépassés. Le verrouillage se coordonne avec la couche plus large de protection contre les attaques de connexion de la plateforme ; ainsi un même utilisateur ne peut pas brute-forcer simultanément un facteur tout en essayant le deuxième.
Les adresses e-mail, les numéros de téléphone et les noms d'authentificateur sont toujours affichés sous forme masquée à l'utilisateur final dans l'interface de vérification. Un attaquant qui connaît le mot de passe mais ne possède pas le deuxième facteur ne peut pas lire la cible et la rediriger — et quelqu'un qui regarde par-dessus l'épaule d'un autre ne peut pas collecter les détails d'enregistrement.
La longueur du code (6, 8 ou plus), les séparateurs de groupement (123-456 ou 123456), la fenêtre de validité en secondes et le délai d'attente de renvoi sont configurés par profil MFA. Les flux soumis à la conformité peuvent demander des codes plus longs et des fenêtres plus courtes ; les flux de routine restent conviviaux avec des codes standard de 6 chiffres et de 60 secondes.
Les utilisateurs peuvent demander un renvoi lorsque le code original n'arrive pas — soumis à un délai d'attente configurable qui empêche d'utiliser le mécanisme de renvoi comme outil de bombardement SMS. Les limites de débit sont suivies conjointement avec les compteurs de tentatives par canal et apparaissent dans les journaux d'audit.
Chaque tentative MFA — réussie, échouée, renvoyée, verrouillée — est journalisée avec l'horodatage, l'IP source, le user agent, le canal et la décision prise par le moteur de politique. Le flux d'audit est alimenté vers la cible de streaming SIEM de la plateforme ; ainsi les équipes sécurité peuvent corréler les anomalies MFA avec le reste de la télémétrie.
Domain controllers, bases de données de production, console d'administration propre de la plateforme — ceux-ci imposent la chaîne la plus forte disponible. Un modèle courant est le TOTP au début de session plus une vérification SMS fraîche lorsqu'une opération destructrice est invoquée ; pour les systèmes au plus fort impact, le raccourci d'appareil de confiance n'est pas activé.
Les systèmes de transfert d'argent et de rapprochement peuvent demander une MFA chaînée — TOTP à la connexion plus OTP frais au moment de la transaction — afin qu'un seul facteur volé ne puisse pas générer de mouvement d'argent. La politique step-up maintient la friction à la limite de la transaction, pas à chaque chargement de page.
Les utilisateurs sans bureau fixe ni ordinateur portable de confiance s'authentifient par SMS OTP via la passerelle SMS de l'organisation, et par e-mail OTP lorsque la fiabilité du SMS est faible. Le masquage du destinataire et le verrouillage par canal maintiennent le flux en sécurité même lorsqu'un même téléphone sert toute une équipe.
Les auditeurs recherchent la MFA sur chaque chemin d'accès privilégié menant aux systèmes dans le périmètre. L'exigence de politique par service l'exprime clairement pour l'auditeur — sans dresser le même mur devant les services internes à faible risque.
Trois méthodes, un seul moteur de politique, aucun cloud MFA tiers — configuré par service et par risque. Laissez-nous vous guider dans une installation en direct sur vos propres applications.