Mesurer sa dépendance technologique ne consiste pas à compter les fournisseurs par nationalité. Cela consiste à identifier les briques dont la défaillance, l'indisponibilité ou une contrainte externe aurait un effet majeur sur l'activité, puis à évaluer la capacité réelle d'en changer. Une dépendance critique et non substituable sur un composant discret pèse plus lourd que dix abonnements remplaçables en une semaine.
Pourquoi la nationalité du fournisseur est un mauvais point de départ
Trois raisons pratiques.
La dépendance est en cascade. Un fournisseur européen peut reposer sur une infrastructure extra-européenne, elle-même dépendante de composants matériels dont la chaîne d'approvisionnement est mondiale. L'exposition est celle du maillon le plus contraint, pas celle de la façade contractuelle.
Toutes les briques ne pèsent pas pareil. Un outil de gestion de projet interrompu gêne ; un fournisseur d'identité interrompu arrête l'entreprise. Traiter les deux avec la même attention consomme un budget d'analyse limité sur le mauvais périmètre.
Le vrai indicateur est le coût de sortie. Si vous pouvez changer de fournisseur en trois semaines sans perte, la dépendance est faible quelle que soit son origine. Si la bascule prendrait dix-huit mois, la dépendance est forte — y compris avec un fournisseur national.
Une méthode en quatre étapes
Étape 1 — Inventorier par fonction, pas par contrat. Listez les fonctions du système d'information : identité et accès, poste de travail et gestion de flotte, messagerie et collaboration, hébergement applicatif, données et analytique, réseau et diffusion de contenu, DNS, sécurité et supervision, développement et chaîne de construction logicielle, signature électronique, paiement. Cette entrée par fonction fait apparaître des dépendances qu'un inventaire de contrats manque, notamment les briques gratuites ou incluses.
Étape 2 — Coter chaque brique selon quatre axes indépendants (voir grille ci-dessous).
Étape 3 — Croiser criticité et substituabilité. Le quadrant « critique et difficilement substituable » constitue votre exposition réelle. Il compte généralement peu d'entrées — souvent moins de dix — et c'est une bonne nouvelle : le sujet devient traitable.
Étape 4 — Définir une trajectoire. Pour chaque brique du quadrant sensible : mesure de réduction possible, alternative identifiée, délai de bascule estimé, et décision assumée d'accepter le risque lorsque aucune option n'est raisonnable. Une dépendance documentée et acceptée vaut mieux qu'une dépendance ignorée.
La grille de cotation
| Axe | Question | Cotation basse | Cotation haute |
|---|---|---|---|
| Criticité fonctionnelle | que se passe-t-il si le service s'arrête demain ? | gêne, contournement possible | arrêt d'activité |
| Exposition juridique | de quelle juridiction relève l'entité contractante, et quelles données lui sont confiées ? | données banales, entité européenne | données sensibles ou stratégiques, juridiction tierce |
| Substituabilité | existe-t-il une alternative crédible, et à quel coût ? | plusieurs offres équivalentes | aucune alternative connue |
| Réversibilité | les données et configurations sont-elles récupérables et exploitables ? | export standard, documenté, testé | format propriétaire, export incomplet |
Un principe de bon sens : coter sur des faits vérifiables, pas sur des déclarations commerciales. La réversibilité, en particulier, ne se cote correctement qu'après un test d'extraction sur un périmètre réduit. Beaucoup d'exports jugés satisfaisants sur le papier se révèlent incomplets à l'usage — configurations absentes, historiques tronqués, formats difficilement réimportables.
Les dépendances que l'on oublie systématiquement
- Le DNS et la diffusion de contenu. Peu visibles, souvent concentrés, et bloquants en cas d'interruption.
- La chaîne de construction logicielle. Dépôts de code, registres de composants, plateformes d'intégration continue, signature de paquets. Une interruption y arrête toute mise en production.
- Les magasins d'applications mobiles. Une solution d'authentification qui repose sur une application mobile dépend des conditions de distribution de ces magasins.
- Les services de notification. L'acheminement des notifications d'approbation passe par les services des systèmes d'exploitation mobiles : une dépendance rarement inventoriée, alors qu'elle conditionne le fonctionnement d'une MFA par notification push.
- Les certificats et l'horodatage. Autorités de certification, services d'horodatage qualifié.
- Les modèles et services d'intelligence artificielle intégrés dans des outils métiers, souvent arrivés sans décision d'architecture.
Le cas de l'identité : à traiter en premier
Le fournisseur d'identité mérite d'être coté séparément, pour une raison structurelle : il ne se contente pas d'être critique, il est transverse. Son indisponibilité rend inaccessibles toutes les applications raccordées, y compris celles qui fonctionnent parfaitement. Sa compromission donne accès à l'ensemble du périmètre. Et sa substitution est parmi les plus longues à mener, puisqu'elle suppose de reconnecter chaque application et de réenrôler chaque utilisateur.
C'est pourquoi la souveraineté appliquée à l'authentification mérite un examen à part. Une solution déployable en overlay d'un dispositif existant présente ici un intérêt particulier : elle ajoute une brique maîtrisée sans imposer la migration complète de l'annuaire, ce qui permet de réduire l'exposition sans engager le chantier le plus coûteux.
Ce que la réglementation attend déjà
Pour une partie des organisations, cette cartographie n'est plus optionnelle. DORA impose au secteur financier une gestion documentée du risque lié aux prestataires de services informatiques, incluant des stratégies de sortie. NIS2 étend les exigences de gestion des risques à la chaîne d'approvisionnement des entités concernées. Dans les deux cas, l'attendu est comparable : savoir de quoi l'on dépend, et avoir prévu ce que l'on ferait en cas de défaillance.
FAQ
Par où commencer si l'inventaire n'existe pas ?
Par les fonctions dont l'arrêt stopperait l'activité en moins de vingt-quatre heures. La liste est généralement courte : identité, messagerie, hébergement des applications métiers, réseau. Elle suffit à engager la démarche.
Faut-il viser zéro dépendance extra-européenne ?
Ce n'est ni réaliste ni nécessairement souhaitable. L'objectif est de connaître ses dépendances, de les hiérarchiser et de conserver une capacité de sortie sur les plus critiques.
Comment évaluer la réversibilité sans tout migrer ?
En testant une extraction sur un périmètre réduit et en tentant de la réimporter ailleurs. C'est l'exercice le plus instructif de toute la démarche, et le moins pratiqué.
À quelle fréquence refaire la cartographie ?
Une revue annuelle, complétée d'une mise à jour à chaque décision structurante : nouveau fournisseur critique, changement d'architecture, opération capitalistique chez un fournisseur existant.
Aller plus loin : une brique d'authentification conçue en France · souveraineté numérique : définition · CLOUD Act : mécanisme et portée · déployer en overlay d'un IdP existant