Parmi toutes les briques d'un système d'information, l'authentification occupe une position unique : elle conditionne l'accès à toutes les autres. Une interruption du fournisseur d'identité rend inaccessibles des applications qui fonctionnent parfaitement. Une compromission de ce même fournisseur ouvre l'ensemble du périmètre. Et les données qu'il détient — comptes, rattachements, appareils, journaux de connexion — décrivent l'organisation avec une précision qu'aucune autre base n'atteint. C'est ce qui en fait un sujet de souveraineté distinct des autres.
Trois propriétés qui la distinguent des autres dépendances
Elle est transverse. Une application métier indisponible affecte un service. Un fournisseur d'identité indisponible affecte tout le monde, simultanément, y compris les équipes chargées de rétablir la situation. Peu de briques ont ce profil.
Elle est descriptive. Un annuaire d'identités révèle l'organigramme réel, les rattachements, les projets à travers les groupes d'accès, les partenaires par les comptes externes. Les journaux d'authentification indiquent qui accède à quoi, quand et depuis où. C'est une cartographie de l'entreprise, pas seulement une liste de comptes.
Elle est difficilement réversible. Changer de fournisseur d'identité suppose de reconnecter chaque application, de reconstruire les politiques, de réenrôler chaque utilisateur et de vider les sessions en cours. C'est l'un des chantiers les plus longs qu'une DSI puisse engager, ce qui réduit d'autant la marge de négociation avec le fournisseur en place.
Quatre questions à poser sur sa brique d'authentification
| Question | Ce qu'elle révèle | Signal d'alerte |
|---|---|---|
| Que se passe-t-il si le service est indisponible une journée ? | criticité réelle et existence d'un plan de repli | aucun accès de secours testé |
| Quelles données identifiantes le fournisseur détient-il ? | exposition en cas de demande d'autorité ou de compromission | annuaire complet et gabarits biométriques centralisés |
| De quelle juridiction relève l'entité contractante ? | rattachement juridique, à instruire avec vos conseils | absence de réponse écrite claire |
| Combien de temps prendrait une migration ? | dépendance effective et rapport de force | aucune estimation disponible |
La deuxième ligne est celle qui différencie le plus les architectures. Une solution qui centralise des identifiants permanents et, éventuellement, des gabarits biométriques constitue une base de très grande valeur. Une solution qui ne détient aucune donnée identifiante ne peut pas en communiquer ni en laisser fuir : le risque est traité par conception plutôt que par mesure de protection.
Le débat mal posé : localisation contre architecture
La discussion se réduit souvent à la question de l'hébergement. C'est un critère nécessaire mais insuffisant, développé dans l'analyse de l'hébergement en France. Deux paramètres pèsent au moins autant.
Ce que l'architecture détient. Une base centralisée d'identités constitue une cible et un objet de demande possible. Une architecture décentralisée, où la donnée sensible ne quitte pas le terminal de l'utilisateur, ne présente pas le même profil de risque — quelle que soit la localisation des serveurs.
Ce que l'architecture impose. Une solution qui exige un identifiant permanent — le plus souvent une adresse professionnelle — crée mécaniquement un annuaire exploitable. Une approche IDless supprime cet annuaire au lieu de le protéger.
C'est l'orientation retenue par HIAsecure : approche passwordless et IDless, architecture décentralisée, biométrie éventuelle traitée localement sur le terminal, aucune donnée identifiante détenue par l'éditeur, solution conçue, développée et hébergée en France, deux brevets, et une qualification SecNumCloud en cours. Le déploiement possible en overlay d'une MFA existante permet en outre de renforcer la brique la plus sensible sans engager la migration complète de l'annuaire — c'est-à-dire sans payer le coût qui rend justement cette dépendance si difficile à réduire.
Ce que la réglementation demande déjà
Plusieurs textes convergent, sans jamais employer le terme de souveraineté.
- NIS2 attend une gestion des risques incluant la chaîne d'approvisionnement et cite l'authentification multifacteur ou continue parmi les mesures de gestion des risques.
- DORA, applicable depuis janvier 2025 dans le secteur financier, impose une maîtrise du risque lié aux prestataires informatiques critiques, avec des stratégies de sortie documentées. Un fournisseur d'identité entre naturellement dans cette catégorie.
- eIDAS 2 (règlement (UE) 2024/1183) construit un portefeuille d'identité européen, avec une logique de contrôle par l'utilisateur sur ses attributs d'identité.
- Le Cyber Resilience Act (règlement (UE) 2024/2847) porte des exigences de sécurité dès la conception sur le cycle de vie des produits numériques, avec des obligations principales à horizon fin 2027.
Le point commun de ces textes n'est pas une préférence géographique. C'est une exigence de maîtrise démontrable : savoir de quoi l'on dépend, ce qui se passe en cas de défaillance, et comment on en sort. Ces obligations sont détaillées dans le panorama des cadres applicables.
Une trajectoire réaliste
- Coter la brique d'authentification dans votre cartographie de dépendances : criticité, exposition, substituabilité, réversibilité.
- Tester le scénario d'indisponibilité, y compris les accès de secours. Un plan non testé n'est pas un plan.
- Réduire ce qui est détenu : limiter les données identifiantes centralisées, éviter la centralisation de gabarits biométriques.
- Renforcer la preuve avant de refondre l'architecture. Ajouter un facteur robuste et maîtrisé en overlay produit un résultat rapide, là où une migration d'annuaire mobilise des mois.
- Documenter la stratégie de sortie, même si elle n'est pas exécutée. C'est ce que demandent les textes, et c'est ce qui rétablit un rapport de force.
FAQ
Faut-il migrer son fournisseur d'identité pour gagner en souveraineté ?
Rarement en première intention : c'est le chantier le plus long et le plus risqué. Renforcer la preuve d'authentification en overlay, réduire les données identifiantes détenues et documenter une stratégie de sortie produisent des effets plus rapides.
Une solution française est-elle nécessairement plus souveraine ?
Pas automatiquement. Il faut vérifier la structure de l'entité, la localisation de l'exploitation, la chaîne de sous-traitance et la réversibilité. Une origine nationale facilite l'analyse, elle ne la remplace pas.
Que faire des journaux d'authentification ?
Les traiter comme des données sensibles : durée de conservation définie, accès restreint, stockage maîtrisé. Ils décrivent l'organisation aussi précisément que l'annuaire lui-même.
Comment tester un scénario d'indisponibilité de l'IdP ?
Sur un périmètre restreint et hors production si possible : vérifier que les accès de secours fonctionnent, qu'ils sont détenus par les bonnes personnes, et que leur usage déclenche une alerte. L'exercice révèle presque toujours une dépendance non documentée.
Aller plus loin : authentification cognitive : architecture décentralisée · souveraineté numérique : définition · cartographier sa dépendance extra-européenne · choisir une solution française