Le cloud computing repose sur une promesse simple : externaliser serveurs, stockage et logiciels pour se concentrer sur son activité. La question de savoir s’il faut l’adopter est souvent posée sous l’angle des avantages et des inconvénients classiques. Cet article mesure un risque moins visible, celui de la concentration technique derrière des fournisseurs en apparence distincts, et ses conséquences sur la continuité des services, la souveraineté des données et la résilience informatique.
Dépendance cachée à un hyperscaler : le risque systémique du cloud
Une entreprise peut choisir un logiciel SaaS européen, un service d’authentification spécialisé, un fournisseur DNS indépendant et une solution de sauvegarde tierce. Sur le papier, la diversification semble acquise.
Lire également : Comment savoir si une image a été manipulée ?
En pratique, ces quatre briques peuvent toutes tourner sur l’infrastructure du même hyperscaler (AWS, Azure ou Google Cloud). Quand le plan de contrôle de cet hyperscaler tombe, l’ensemble de la chaîne s’effondre simultanément, même si l’entreprise n’a aucun contrat direct avec lui.
Ce phénomène est documenté par l’analyse de pannes récentes : des organisations sans lien apparent avec une région cloud touchée ont subi des interruptions via leurs sous-traitants. Le risque ne se limite plus aux serveurs hébergeant les données, il concerne les couches invisibles (authentification, journalisation, résolution DNS) qui font fonctionner l’ensemble.
A voir aussi : La méthode 2FA est-elle sûre ?
| Couche technique | Hébergement propre (on-premise) | Cloud diversifié réel | Cloud à dépendance concentrée |
|---|---|---|---|
| Stockage des données | Contrôle direct | Réparti sur plusieurs fournisseurs | Un seul hyperscaler en backend |
| Authentification (SSO/IAM) | Serveur interne | Fournisseur distinct | Souvent hébergé chez le même hyperscaler |
| DNS | Serveur local ou FAI | Fournisseur DNS autonome | DNS résolu via la même infrastructure cloud |
| Sauvegarde | Bandes/disques locaux | Région ou cloud séparé | Même région, même fournisseur |
| Impact d’une panne majeure | Limité au site | Partiel, récupération possible | Cascade sur toutes les couches |
Pannes cloud et plans de contrôle : ce que les incidents récents mesurent
Les interruptions de service les plus marquantes de ces dernières années ne résultent pas de cyberattaques. Elles proviennent de défaillances internes aux plans de contrôle, ces systèmes qui orchestrent le provisionnement, le routage et l’authentification au sein d’un cloud.
Quand un plan de contrôle dysfonctionne, les machines virtuelles continuent parfois de tourner, mais il devient impossible de s’authentifier, de déployer une mise à jour ou de basculer vers une zone de secours. Le cloud doit être évalué comme un risque opérationnel, pas uniquement comme une surface d’attaque.
Conséquences en cascade sur les services tiers
Un éditeur SaaS dont l’authentification dépend d’un service hébergé chez l’hyperscaler touché se retrouve inaccessible. Son client final, qui n’a jamais souscrit au cloud en question, subit pourtant la panne.
Changer d’application ne suffit pas à diversifier les dépendances techniques. Pour cartographier le risque réel, il faut remonter la chaîne de chaque sous-traitant jusqu’à l’infrastructure physique. Peu d’entreprises réalisent cet audit.
Souveraineté des données et concentration ICT dans les achats cloud
La souveraineté cloud dépasse la localisation géographique des serveurs. Elle englobe désormais le contrôle effectif sur les données, les clés de chiffrement, la juridiction applicable et la chaîne de sous-traitance technique.
- Les achats publics européens intègrent progressivement des critères formalisés de souveraineté cloud, au-delà du simple chiffrement ou de la sécurité des accès.
- Pour les secteurs réglementés (finance, santé, énergie), la concentration ICT chez un nombre limité de fournisseurs devient un enjeu explicite de conformité.
- Un prestataire cloud certifié « souverain » peut lui-même dépendre d’un hyperscaler américain pour ses couches basses, ce qui complexifie l’évaluation réelle de la souveraineté.
Cette situation crée un décalage entre la promesse contractuelle et la réalité technique. Une entreprise qui pense avoir diversifié ses fournisseurs cloud peut, en cas d’audit approfondi, découvrir une dépendance unique à un acteur tiers non identifié dans son registre de risques.
Évaluer le cloud comme risque organisationnel : les questions à poser avant de migrer
Avant toute migration ou renouvellement de contrat cloud, un travail de cartographie s’impose. Il ne porte pas sur les fonctionnalités, mais sur la chaîne de dépendances réelle.
- Quel hyperscaler héberge effectivement chaque brique (logiciel, authentification, DNS, sauvegarde) ? La réponse doit venir du fournisseur, pas d’une supposition.
- En cas de panne du plan de contrôle de cet hyperscaler, quels services restent opérationnels et lesquels deviennent inaccessibles ?
- La sauvegarde est-elle stockée sur une infrastructure physiquement et logiquement distincte de l’infrastructure principale ?
- Les contrats prévoient-ils une clause de réversibilité permettant de récupérer les données dans un format exploitable et dans un délai défini ?
Hébergement local ou cloud hybride : alternatives à la concentration
L’hébergement on-premise n’a pas disparu. Pour certaines charges de travail critiques, conserver un serveur local ou opter pour un cloud hybride réduit l’exposition à une panne en cascade. Le coût initial est plus élevé, mais la maîtrise de la continuité de service reste entre les mains de l’organisation.
Le cloud hybride, qui combine infrastructure locale et ressources cloud, permet de placer les données les plus sensibles sur des systèmes contrôlés tout en exploitant l’élasticité du cloud pour les charges variables. Cette approche suppose toutefois une compétence interne en administration systèmes, ce qui représente un investissement en ressources humaines.
La question n’est pas de rejeter le cloud en bloc. Elle porte sur la capacité à identifier où se situe réellement la dépendance technique, puis à décider en connaissance de cause quels processus méritent d’y être exposés. Un registre de risques qui ignore la couche d’infrastructure de ses sous-traitants cloud reste incomplet, quel que soit le nombre de fournisseurs listés dans l’organigramme informatique.
