L'approche overlay consiste à ajouter un facteur d'authentification devant un dispositif existant plutôt qu'à le remplacer. Le fournisseur d'identité en place continue de gérer les identités, les habilitations et les sessions ; le nouveau facteur s'insère sur les parcours qui le justifient. Cela change la nature du projet : de refonte pluriannuelle, il devient déploiement ciblé et réversible.
Pourquoi le remplacement est rarement le bon plan
Remplacer un fournisseur d'identité, c'est toucher au point le plus central du système d'information : chaque application raccordée, chaque parcours de secours, chaque intégration technique. Trois conséquences bien documentées par l'expérience des projets :
- Le calendrier est dicté par l'application la plus lente, souvent une application métier ancienne dont personne ne maîtrise plus l'intégration.
- Le risque d'exploitation est maximal : une erreur sur l'authentification centrale bloque l'entreprise entière, ce qui pousse à des fenêtres de bascule courtes et stressantes.
- Le bénéfice arrive à la fin. Tant que la bascule n'est pas achevée, la sécurité réelle reste celle de l'ancien dispositif — alors que le budget, lui, est déjà consommé.
L'overlay inverse cette séquence : le bénéfice arrive dès le premier parcours traité.
Où insérer le facteur, et quand le déclencher
Les quatre points d'insertion possibles
| Point d'insertion | Ce qu'il couvre | Effort d'intégration | Limite principale |
|---|---|---|---|
| Devant le fournisseur d'identité | tous les parcours fédérés d'un coup | faible à modéré | ne couvre pas les accès locaux hors fédération |
| Au niveau du reverse proxy | applications web publiées, y compris non modifiables | modéré | ne voit pas le contexte métier de l'action |
| Dans l'application | actions précises, avec tout le contexte | fort, unitaire | coût par application, dépend des équipes produit |
| Au niveau de la transaction | opérations financières ou juridiques | fort mais ciblé | suppose une intégration avec le moteur métier |
Le choix ne se fait pas entre ces quatre points, mais dans leur combinaison. Le schéma le plus courant associe une insertion devant le fournisseur d'identité, qui couvre le volume, et une insertion transactionnelle sur les quelques opérations à fort impact, qui couvre la valeur.
Le déclenchement conditionnel : le vrai sujet
Superposer un facteur ne signifie pas l'imposer à chaque connexion. L'intérêt de l'overlay tient largement à sa capacité à ne se déclencher que lorsque c'est justifié.
Les conditions les plus utiles, par ordre de valeur :
- La sensibilité de l'action demandée : virement, changement d'IBAN, modification d'une politique de sécurité, export massif de données. C'est le déclencheur le plus pertinent, parce qu'il est lié à l'impact.
- Le niveau de privilège du compte : élévation vers un rôle d'administration.
- L'écart contextuel : appareil inconnu, localisation inhabituelle, horaire atypique, séquence anormale d'actions. Un score de risque contextuel permet de moduler plutôt que d'appliquer une règle unique.
- L'ancienneté de la session : une action majeure dans une session ouverte depuis plusieurs heures mérite une preuve fraîche, conformément au principe Zero Trust du NIST SP 800-207.
- Le parcours périphérique : inscription d'un nouveau facteur, récupération de compte, modification des coordonnées de contact. Ces parcours sont ceux que les attaquants visent en priorité.
Ce dernier point est souvent le premier à mettre en œuvre : il apporte un gain immédiat sur le maillon le plus faible, pour un effort d'intégration limité à quelques écrans.
Ce que l'overlay ne règle pas
L'honnêteté impose de poser les limites.
- Les parcours hors fédération restent découverts. Une application avec authentification locale n'est pas concernée par une insertion devant le fournisseur d'identité. L'inventaire reste donc un préalable.
- Les faiblesses de l'existant subsistent. Si le fournisseur d'identité accepte toujours un code SMS en récupération, l'overlay n'y change rien. Superposer n'exonère pas de retirer les replis faibles.
- La complexité augmente. Deux dispositifs, deux journaux, deux contrats, deux interlocuteurs en cas d'incident. Cette complexité se gère, mais elle doit être assumée et outillée.
- Le vol de session reste ouvert si aucune revalidation n'est demandée en cours de session.
Les questions à poser à un fournisseur
| Question | Ce qu'elle révèle |
|---|---|
| Quels protocoles standards sont pris en charge en entrée et en sortie ? | mesure la dépendance à des développements spécifiques |
| Le déclenchement conditionnel se pilote-t-il par politique, sans développement ? | conditionne l'agilité d'exploitation |
| Que se passe-t-il si votre service est indisponible ? | échec ouvert ou fermé : décision de risque majeure |
| Les journaux sont-ils exportables vers notre SIEM, et sous quel format ? | exigence de traçabilité NIS2 et DORA |
| Quel délai pour retirer la surcouche si nous décidons d'arrêter ? | mesure la réversibilité réelle |
| Quelles données transitent, et où sont-elles hébergées ? | RGPD, souveraineté, analyse d'exposition |
| Comment se comporte la surcouche sur les parcours mobiles ? | angle mort fréquent des démonstrations |
La troisième ligne mérite d'être traitée en atelier dédié. Un overlay en échec ouvert dégrade silencieusement la sécurité au moment le plus critique ; un overlay en échec fermé peut bloquer l'entreprise. La réponse dépend du parcours : échec fermé sur les opérations sensibles, échec ouvert éventuellement toléré sur les accès de faible enjeu, avec journalisation et alerte dans les deux cas.
Le cas du facteur cognitif en superposition
L'ajout d'un 4ᵉ facteur « je sais faire » se prête particulièrement à ce mode de déploiement : il ne remplace ni l'annuaire, ni les habilitations, ni la gestion des sessions. Il s'insère là où la question posée cesse d'être « qui se connecte ? » pour devenir « cette action est-elle réellement voulue ? » — validation de virement, élévation de privilèges, récupération de compte.
Le continuum 2FA vers 4FA décrit exactement cette progression : conserver l'existant, ajouter une preuve d'intention sur les parcours à enjeu, puis étendre selon les résultats mesurés.
FAQ
L'overlay dégrade-t-il l'expérience utilisateur ?
Pas s'il est conditionnel. Un facteur supplémentaire demandé à chaque connexion produit du rejet ; un facteur demandé uniquement sur une opération à enjeu est généralement bien accepté, parce que l'utilisateur en comprend la raison.
Peut-on superposer un facteur sans modifier les applications ?
Oui pour tous les parcours fédérés ou publiés derrière un reverse proxy. Non pour une validation portant sur une action métier précise, qui suppose que l'application transmette le contexte de l'opération.
Que devient l'overlay si nous changeons de fournisseur d'identité ?
S'il repose sur des protocoles standards, il se raccroche au nouveau fournisseur sans réenrôler les utilisateurs. C'est un point à vérifier contractuellement, car il conditionne votre liberté de manœuvre future.
Deux dispositifs, n'est-ce pas deux fois plus de risque fournisseur ?
C'est un risque de dépendance supplémentaire, mais aussi une réduction de la dépendance à un acteur unique. L'arbitrage se traite par les clauses de réversibilité et par la définition claire du comportement en cas d'indisponibilité.
Aller plus loin : pilier : authentification cognitive · migrer vers le passwordless · step-up authentication · choisir une solution d'authentification