Acheter trois applications SaaS auprès de trois sociétés différentes ne garantit pas trois dépendances indépendantes. Elles peuvent reposer sur le même hébergeur, la même région, le même service d’identité ou le même mécanisme d’export. Une panne ou une compromission commune peut alors interrompre plusieurs processus à la fois. Cette page propose une carte des dépendances communes, construite à partir des services réellement consommés et de leur substituabilité. Le guide des prestataires TIC sous DORA explique les obligations d’une population réglementée ; ici, la carte sert d’abord à comprendre une architecture d’achat, sans supposer que toute entreprise relève de DORA.
Le NIST SP 1305 relie la gestion du risque de chaîne d’approvisionnement à la gouvernance cyber. Le règlement DORA traite notamment des dépendances TIC et du risque de concentration pour les entités financières entrant dans son champ. Ces sources éclairent le sujet, mais ne fournissent pas la carte de votre entreprise : les relations entre SaaS, infrastructure, identité et processus doivent être établies localement. Un logo de fournisseur ou un contrat ne suffit pas à révéler les points communs cachés.
Choisir l’unité d’analyse : le service métier
Commencez par les processus qui doivent continuer : encaissement, support client, accès aux dossiers, paie ou suivi des incidents. Associez à chacun les applications nécessaires, les utilisateurs et la période où une interruption serait critique. Un fournisseur peut vendre plusieurs modules, et un module peut soutenir deux activités de gravité différente. Si vous ne partez que d’une liste de contrats, vous risquez de compter des fournisseurs sans voir qu’un seul service d’identité conditionne l’accès à tous.
Pour chaque application, inscrivez la personne morale contractante, le service acheté, le propriétaire interne, les données ou opérations principales et la durée tolérable d’indisponibilité choisie par le métier. Cette dernière est une hypothèse de continuité à valider, pas une promesse de l’éditeur. La politique de sécurité des fournisseurs peut définir la collecte et les responsabilités ; la carte relie ces informations à un scénario de défaillance partagé.
Ne transformez pas immédiatement chaque sous-traitant annoncé en une dépendance certaine. Un fournisseur peut utiliser plusieurs régions ou changer de composant selon les clients. Notez la source, la date et le niveau de confiance : contrat, documentation technique, réponse écrite, test de routage ou simple hypothèse. Si le fournisseur ne divulgue pas un détail sensible, indiquez le point inconnu et envisagez un scénario prudent. Une carte précise en apparence mais construite sur des suppositions non signalées est moins utile qu’une carte partielle honnête.
Quatre couches à superposer
La première couche est l’infrastructure : hébergement, stockage, réseau de distribution, DNS, sauvegarde ou prestataire d’exploitation. Deux SaaS peuvent être indépendants au niveau applicatif et tomber ensemble si une zone ou un service sous-jacent est indisponible. Évitez la conclusion inverse trop rapide : « même fournisseur cloud » ne signifie pas toujours même zone, même architecture ou même mode de défaillance. Demandez quelle composante précise serait commune dans le scénario étudié.
La deuxième couche est l’identité. Un fournisseur d’identité unique peut bloquer la connexion à des services hébergés ailleurs ; une fédération, un répertoire ou une politique conditionnelle peuvent représenter le point commun. Cartographiez les comptes de secours et vérifiez s’ils dépendent du même composant. La sécurité des données avec SSO situe les choix d’authentification, mais le fait d’avoir un accès de secours documenté ne démontre pas qu’il fonctionne pendant une panne réelle.
La troisième couche est géographique et juridictionnelle : régions d’hébergement, lieux de réplication, sites de support et contraintes de transfert, lorsque ces informations sont pertinentes. Une « région européenne » commerciale peut couvrir plusieurs centres de données ; la résilience technique dépend de leur séparation et de la façon dont l’application bascule. La région peut aussi compter pour les exigences contractuelles ou de protection des données. Séparez ces questions au lieu de donner à une étiquette géographique un sens qu’elle n’a pas.
La quatrième couche est la substituabilité. Combien de temps faut-il pour exporter les données, rétablir les identités, comprendre le format, reconstruire les intégrations et former les utilisateurs ? Une autre offre du marché n’est pas forcément une alternative exploitable demain. Notez l’existence d’un export testé, d’une sauvegarde indépendante, d’un contrat de transition et du propriétaire du plan. La concentration devient plus préoccupante lorsqu’un même point commun touche des services dont la sortie est longue.
Modèle de carte des dépendances
Un tableau est utile avant de produire un diagramme complexe. Faites une ligne par application et un champ par couche. Ajoutez la source de chaque relation et la date de vérification. Le modèle suivant est un outil d’analyse, pas une obligation documentaire universelle.
| Service métier / SaaS | Infrastructure connue | Identité | Région pertinente | Sortie ou substitution | Confiance de l’information |
|---|---|---|---|---|---|
| Commandes / SaaS A | Hébergeur X, zone déclarée 1 | IdP central I | Région R | Export CSV testé, intégrations à refaire | Contrat et essai |
| Support / SaaS B | Hébergeur X, zone non confirmée | IdP central I | Région R annoncée | Export non testé | Réponse fournisseur |
| Facturation / SaaS C | Hébergeur Y | IdP central I | Région S | Procédure manuelle limitée | Architecture interne |
| Gestion interne / SaaS D | Hébergeur Y | Identité locale | Région S | Remplacement estimé long | Hypothèse à confirmer |
Les noms X, Y, I, R et S sont fictifs. Dans ce cas, une panne d’identité I peut affecter A, B et C. Une panne d’une composante précise de X pourrait toucher A et B, mais l’absence de zone confirmée pour B empêche de conclure exactement comment. D n’utilise pas I, mais sa sortie longue crée un autre type de dépendance. La carte ne cherche pas à produire un score unique : elle montre quelles questions et quels essais sont nécessaires pour décider.
Construire un scénario commun et le tester
Choisissez un événement plausible, puis suivez les flèches de la carte. Exemple : l’IdP I est indisponible pendant une matinée de forte activité. Les employés déjà connectés peuvent-ils continuer ? Les nouveaux utilisateurs peuvent-ils se connecter ? Quels administrateurs gardent un accès de secours, et comment le prouvent-ils ? Le scénario ne doit pas supposer que toutes les sessions expirent simultanément, ni que des sessions existantes dureront toujours. Faites préciser les comportements techniques et les limites de votre essai.
Un second scénario concerne une région d’hébergement. Interrogez les fournisseurs sur le périmètre de leur reprise, mais testez au moins un chemin opérationnel : accès à une copie des données, communication de crise, bascule prévue ou procédure manuelle. Une déclaration « multi-zone » ne dit pas si la fonction précise achetée bascule entre zones. Le guide NIS2 sur les sous-traitants fournit un contexte sectoriel ; il ne certifie pas la résilience d’un service donné.
Pour chaque scénario, écrivez conséquences, durée tolérée, éléments confirmés, hypothèses non testées et action. Une dépendance commune n’est pas automatiquement inacceptable. Elle peut être acceptée parce que le service se dégrade sans s’arrêter, qu’une solution manuelle couvre l’urgence ou que le coût d’une séparation supplémentaire serait disproportionné. La décision doit montrer cette comparaison, avec un responsable et une date de revue. Si la même identité protège tous les systèmes critiques, un exercice d’accès de secours peut être plus utile qu’un nouveau score fournisseur.
Mesurer la concentration sans fabriquer une précision
Un indicateur simple peut compter les processus critiques dépendant d’un même composant confirmé. Un autre peut mesurer la durée de substitution de chaque service affecté. Ces deux vues répondent à des questions différentes : portée simultanée de l’événement et capacité de reprise. Ne multipliez pas le nombre de SaaS par une note arbitraire d’hébergeur pour obtenir une « probabilité de concentration ». Les dépendances sont parfois corrélées, parfois seulement nominalement communes ; la vraisemblance exige des informations que la carte ne possède pas toujours.
Classez les liens comme « confirmé », « probable à vérifier » ou « inconnu ». Ainsi, le décideur voit qu’un groupe apparent de quatre services pourrait être une vraie concentration ou un artefact de données incomplètes. Une demande ciblée au fournisseur peut lever cette incertitude. Le volume de dépenses peut être pertinent pour la négociation, mais un SaaS peu coûteux peut être critique pour la disponibilité d’un processus. La dépense seule n’est donc pas la bonne unité de risque.
Évitez aussi de conclure qu’une diversification contractuelle est toujours une diversification technique. Acheter deux outils auprès de revendeurs différents qui utilisent le même système d’identité et le même hébergeur n’élimine pas le point commun. À l’inverse, deux services du même groupe peuvent être techniquement séparés pour le scénario envisagé. Le dossier doit exposer la relation causale : quel composant tombe, quelles applications en dépendent, quels processus sont touchés et quelles voies indépendantes restent disponibles.
Qualifier le cadre DORA lorsqu’il s’applique
DORA vise des entités financières et des prestataires selon son champ, avec des règles de gestion des risques liés aux tiers TIC. La qualification dépend de l’entité, du service, de la fonction soutenue et des textes applicables. Une entreprise non financière peut utiliser la même méthode de cartographie sans affirmer être soumise aux mêmes exigences. Pour une entité concernée, reliez la carte aux registres et décisions requis dans son dispositif, en tenant compte des services soutenant des fonctions critiques ou importantes lorsque cette qualification est pertinente.
Le dossier contractuel DORA traite les clauses et la surveillance des tiers. La carte ajoute une vue transversale : deux contrats satisfaisants pris isolément peuvent laisser un point de défaillance commun. N’affirmez pas qu’une clause de sortie élimine la concentration ; il faut mesurer le délai de remplacement et tester la restitution. Une possibilité juridique d’export sans données exploitables le jour de la crise n’est pas une solution opérationnelle.
Un comité peut décider de plafonner une dépendance, d’obtenir plus de preuves sur la séparation technique, de prévoir une alternative ou de renforcer les modes dégradés. L’action choisie doit être reliée au scénario. Si le risque vient de l’IdP central, demander un autre certificat de sécurité à SaaS B peut ne rien changer. Si le risque vient de l’impossibilité de récupérer les données, une vérification d’export peut avoir un effet direct. Les mesures doivent être décidées au bon niveau de la chaîne.
Tenir la carte à jour et décider
Révisez la carte lors d’un nouvel achat, d’une migration de région, d’un changement de fédération d’identité, d’une acquisition de fournisseur, d’une panne significative ou d’un changement de sous-traitant important. Une revue calendaire peut compléter ces déclencheurs, mais ne les remplace pas. Conservez les versions pour comprendre pourquoi une décision antérieure était raisonnable à sa date. Si une relation devient inconnue après un changement technique, signalez-le ; ne laissez pas l’ancien « confirmé » par inertie.
Attribuez un propriétaire à chaque couche. Les achats connaissent le contrat, l’architecture connaît l’identité, les métiers connaissent la tolérance à l’interruption, la protection des données peut connaître les contraintes de région. Une carte centralisée sans responsabilité de mise à jour devient rapidement décorative. Le guide de criticité fournisseur peut aider à prioriser les relations à cartographier, tandis que cette page décrit les dépendances croisées après la sélection.
La sortie attendue tient en trois éléments : une carte avec relations et degré de preuve, un ou deux scénarios de défaillance commune, et une décision sur les mesures ou l’incertitude à traiter. Elle n’a pas besoin de prédire parfaitement la prochaine panne. Elle doit permettre d’éviter qu’une organisation découvre, pendant l’incident, que ses applications apparemment diverses reposaient toutes sur la même porte d’entrée ou le même chemin de récupération.
Faire parler la carte pendant un incident
Une carte qui ne sert qu’au renouvellement contractuel manque son usage le plus urgent. Donnez au centre d’incident un accès à la version courante et identifiez le responsable de chaque relation. Lorsqu’un hébergeur annonce une panne, l’équipe peut chercher les applications qui en dépendent directement ou indirectement, puis contacter les métiers concernés. Elle évite ainsi de découvrir le périmètre en parcourant les tickets utilisateurs un par un. L’incident peut aussi révéler un lien absent de la carte ; ajoutez-le ensuite avec sa source et la date de confirmation.
Prévoyez une lecture en mode dégradé. Si la carte est stockée uniquement dans un SaaS qui dépend de l’IdP indisponible, elle ne sera pas accessible au moment voulu. Une copie contrôlée, une procédure d’accès d’urgence et une règle de mise à jour peuvent réduire ce risque, tout en évitant de diffuser publiquement une architecture sensible. Testez au cours d’un exercice que l’équipe trouve les contacts et les dépendances sans l’accès habituel. La carte n’est utile que si elle rejoint la décision opérationnelle sous contrainte.
Après l’incident, confrontez les hypothèses aux faits : quels services sont réellement tombés, lesquels ont continué, quelle substitution a fonctionné, combien de temps l’export a pris. Ne réécrivez pas la carte passée avant de comparer ; gardez la version qui guidait l’équipe pendant l’événement. Les écarts montrent où demander une information plus précise au fournisseur ou où changer le plan de continuité. Cette boucle transforme une représentation statique en méthode de connaissance des dépendances.