Pourquoi le multicloud est devenu un enjeu de gouvernance

Pour la plupart des responsables informatiques, le multicloud n’est pas né d’une décision. C’est un fait accompli. Une équipe a choisi AWS pour une charge de travail. Azure s’est imposé via un contrat d’entreprise Microsoft. Une acquisition SaaS a apporté ses propres dépendances cloud. Une exigence de reprise après sinistre a conduit à choisir une deuxième région chez un autre fournisseur. Personne n’a annoncé de stratégie multicloud ; l’entreprise s’est simplement retrouvée dans cette situation.

Aujourd’hui, 87 % des organisations mettent en œuvre une stratégie multicloud, jonglant en moyenne avec 2,6 fournisseurs de cloud public en même temps. Mais l’adoption et la gouvernance centralisée sont deux choses complètement différentes. C’est dans l’écart entre l’évolution de l’infrastructure et celle de la gouvernance que s’accumulent discrètement la plupart des risques liés au multicloud.

Comment le multicloud est devenu la norme

Point clé : la plupart des organisations n’ont pas choisi le multicloud. Elles y sont parvenues par le biais d’acquisitions, de décisions prises au niveau des équipes, de la prolifération du SaaS et des exigences en matière de reprise après sinistre. Les cadres de gouvernance conçus pour un monde à fournisseur unique n’ont pas suivi.

L’ère du cloud unique offrait une certaine simplicité opérationnelle. Un fournisseur, ça voulait dire un contrat, une relation d’assistance, un ensemble de contrôles de conformité à maintenir, une console pour tout gérer. Ça voulait aussi dire un point de défaillance, un seul levier de tarification et des coûts de sortie qui devenaient de plus en plus prohibitifs à chaque service adopté.

Le marché s’est définitivement éloigné de ce modèle. Gartner prévoit que 90 % des entreprises adopteront une approche de cloud hybride d’ici 2027, soulignant que le défi le plus urgent pour l’année à venir sera de gérer la synchronisation des données dans des environnements hybrides fragmentés. 

Cette pression ne vient pas d’une préférence stratégique pour la complexité ; elle est structurelle et s’accumule. Les exigences réglementaires imposent la résidence des données dans des juridictions spécifiques. Les charges de travail liées à l’IA se concentrent sur des fournisseurs différents de ceux du calcul traditionnel. Les acquisitions apportent leurs propres parcs cloud. Les équipes choisissent le meilleur outil pour la tâche à accomplir, et c’est la tâche qui détermine le fournisseur.

Résultat : la plupart des environnements cloud d’entreprise sont désormais véritablement multicloud. Et la plupart des cadres de gouvernance ne le sont pas.

Les pressions opérationnelles qui rendent ça urgent

Point clé : trois pressions qui se rejoignent (risque lié à la résilience, complexité réglementaire et dépendance vis-à-vis des fournisseurs) font passer la gouvernance multicloud du statut de « bonne pratique » à celui d’exigence de continuité d’activité.

Le risque lié à la résilience n’est plus qu’une question théorique 

La concentration sur un seul fournisseur crée une exposition que les contrats standard des fournisseurs ne couvrent tout simplement pas. Selon le rapport d’IBM sur le coût d’une fuite de données, les fuites impliquant plusieurs environnements sont les plus coûteuses à résoudre, avec un coût moyen de 5,05 millions de dollars par incident. Pire encore, il faut en moyenne 276 jours pour les identifier et les maîtriser ; soit près d’un mois de plus que pour les incidents standard sur un seul cloud public. Le risque opérationnel et financier repose entièrement sur l’entreprise, et non sur le fournisseur.

La complexité réglementaire s’est multipliée 

Les exigences en matière de souveraineté des données, le RGPD, les cadres de conformité spécifiques à chaque secteur et les nouvelles réglementations sur la gouvernance de l’IA comportent toutes des dimensions géographiques et propres à chaque fournisseur. Une entreprise qui exécute des charges de travail sur AWS, Azure et GCP dans plusieurs régions n’est pas confrontée à une seule posture de conformité ; elle doit en gérer plusieurs en même temps. Sans gouvernance inter-fournisseurs, la conformité devient un exercice manuel, à effectuer environnement par environnement, qui s’alourdit au fur et à mesure que le nombre de fournisseurs et de régions augmente, au lieu d’être gérée de manière centralisée.

La dépendance vis-à-vis d’un fournisseur est un risque stratégique, pas seulement technique. 

Le verrouillage sur les services propriétaires, les modèles tarifaires et les décisions stratégiques d’un seul fournisseur fait basculer, au fil du temps, le pouvoir de négociation de l’acheteur vers le fournisseur. Les frais de sortie de données, les suppressions de services et les changements de tarification ont tous plus de poids quand la migration coûte cher. Une entreprise capable de déplacer ses charges de travail se trouve dans une position de négociation fondamentalement différente de celle qui ne le peut pas, et cette différence se ressent lors des renouvellements de contrats, des négociations de SLA et du coût total de l’infrastructure. Identifier tes lacunes en matière de gouvernance est la première étape pour y remédier.

Lis le guide sur la standardisation de la mise à disposition des applications sur AWS, Azure et GCP.

Pourquoi la gouvernance est le maillon faible

Point clé : les environnements multicloud échouent pas parce que les entreprises ont mal choisi leurs fournisseurs. Ils échouent parce que les cadres de gouvernance n’ont pas été conçus pour s’étendre à plusieurs d’entre eux.

La lacune de gouvernance dans le multicloud ne concerne pas les outils de sécurité ou les tableaux de bord de surveillance. Elle porte sur la question de savoir si les politiques, les contrôles et la visibilité sur lesquels s’appuient les responsables informatiques s’étendent réellement à l’ensemble du parc d’infrastructures, ou s’ils s’arrêtent aux limites de la console de chaque fournisseur.

Quand ils s’arrêtent là, les conséquences sont prévisibles. La visibilité sur les coûts est fragmentée entre des systèmes de facturation qui ne parlent pas la même langue. Les politiques de sécurité strictement appliquées dans un environnement le sont de manière incohérente dans un autre. Les preuves de conformité doivent être rassemblées manuellement à partir de multiples sources avant chaque cycle d’audit. Les contrôles d’accès soigneusement définis dans un environnement s’étendent discrètement dans un autre. Les dérives de configuration s’accumulent à travers les environnements cloud plutôt que simplement entre le développement et la production.

D’après l’étude mondiale de Thales sur la sécurité du cloud, 44 % des entreprises ont subi une fuite de données dans le cloud, les principales causes étant l’erreur humaine, les erreurs de configuration et un contrôle des changements insuffisant entre des environnements disparates. Les entreprises qui gèrent bien le multicloud ne sont pas celles qui ont les architectures cloud les plus sophistiquées. Ce sont celles qui ont considéré la gouvernance comme une exigence de conception inter-fournisseurs dès le départ, plutôt que comme une réflexion après coup pour chaque fournisseur.

Ce qu’exige réellement une gouvernance inter-fournisseurs

Point clé : une gouvernance qui s’étend à tous les fournisseurs doit s’appliquer au niveau de la couche de fourniture, cette couche cohérente qui se situe au-dessus de chaque infrastructure cloud individuelle, et non au niveau de chaque fournisseur, où chaque environnement est par définition différent.

Quand on est confronté à la complexité de la gouvernance, le réflexe est d’aller voir chaque fournisseur pour y configurer la gouvernance. Cette approche s’alourdit au fur et à mesure que le nombre de fournisseurs augmente, ce qui signifie que ça devient plus difficile à mesure que le parc s’étend, au lieu de devenir plus facile. Une équipe qui gère AWS, Azure et GCP ne s’occupe pas de la gouvernance une seule fois. Elle le fait trois fois, dans trois interfaces différentes, avec trois langages de politiques différents, ce qui génère des preuves d’audit qu’il faut rapprocher manuellement.

La gouvernance inter-fournisseurs fonctionne différemment. Elle s’applique au niveau de la couche de livraison : cette abstraction cohérente au-dessus des infrastructures cloud individuelles, où les politiques, les définitions d’environnement, les contrôles d’accès et les processus de déploiement sont définis une seule fois et appliqués partout. C’est le même principe qui permet à la standardisation des plateformes de fonctionner pour la livraison d’applications. Il faut déplacer la logique de gouvernance vers le haut de la stack, vers une couche qui ne change pas d’un fournisseur à l’autre.

Pour les responsables informatiques, ce changement de perspective est important car il modifie la destination des investissements. Les outils de gouvernance intégrés à la console de chaque fournisseur resteront toujours spécifiques à ce fournisseur. La gouvernance qui réside au niveau de la couche de livraison, sous forme de configurations gérées par version, de pipelines automatisés et de définitions d’environnement portables, suit la charge de travail quel que soit l’endroit où elle s’exécute.

C’est ce que ça veut dire quand on dit que le multicloud relève d’un choix de gouvernance plutôt que d’un choix d’infrastructure. La question de l’infrastructure (quels fournisseurs, quelles régions, quels services) reste importante. Mais c’est la question de la gouvernance (comment tu gardes le contrôle, la visibilité et la portabilité sur l’ensemble de ces éléments) qui détermine si le multicloud tient ses promesses ou s’il ne fait qu’ajouter de la complexité au coût.

Consulte l’architecture de référence pour les environnements portables avec des garde-fous de politique.

Foire aux questions (FAQ)

Le multicloud est-il vraiment plus sécurisé qu’un cloud unique ? 

Ça peut l’être, mais seulement si une gouvernance est en place pour appliquer des contrôles cohérents chez tous les fournisseurs. Sans ça, le multicloud élargit la surface d’attaque au lieu de la réduire. L’avantage de la résilience d’une infrastructure distribuée nécessite une discipline de gouvernance pour la gérer de manière cohérente. Les entreprises qui ont subi des fuites de données dans des environnements multicloud citent généralement une mauvaise configuration et une application incohérente des politiques comme causes principales, et non l’architecture multicloud en elle-même.

En quoi la gouvernance multicloud diffère-t-elle de la sécurité cloud ? 

La sécurité du cloud se concentre sur la protection des charges de travail au sein d’un environnement donné. La gouvernance multicloud consiste à maintenir simultanément une politique, une visibilité et un contrôle cohérents sur tous les environnements : comment les charges de travail circulent entre les fournisseurs, comment les preuves de conformité sont produites, comment l’accès est délimité et audité, et comment les coûts sont suivis. La sécurité est une dimension de la gouvernance ; la portabilité, la posture de conformité et la visibilité financière en sont les autres.

Combien coûte réellement l’enfermement propriétaire ? 

Les coûts directs (frais de sortie, coûts de migration, dépendances vis-à-vis de services propriétaires) sont mesurables, mais souvent sous-estimés au moment de l’achat et difficiles à inverser par la suite. Le coût stratégique est plus difficile à quantifier : perte de pouvoir de négociation, exposition à des changements de tarification unilatéraux et dépendance vis-à-vis des décisions d’un seul fournisseur en matière de feuille de route. Le rapport d’IBM sur le coût d’une fuite de données estime les incidents multi-environnements à 5,05 millions de dollars en moyenne, avec un délai moyen de 276 jours pour les identifier et les contenir ; un coût et un délai qui pèsent sur l’entreprise, pas sur le fournisseur.

Par où commencer la gouvernance multicloud ? 

Par la visibilité : savoir ce qui tourne où, avec quelle configuration et quels contrôles d’accès. La plupart des lacunes de gouvernance dans les environnements multicloud ne sont pas le résultat de mauvaises décisions stratégiques. Elles résultent de politiques qui n’ont jamais été appliquées de manière cohérente, car il n’existait pas de couche unifiée à partir de laquelle les appliquer. Le point de départ consiste à mettre en place cette couche, puis à y intégrer l’application des politiques.

Comment la souveraineté des données s’intègre-t-elle dans la gouvernance multicloud ? 

Les exigences en matière de souveraineté des données, qui précisent où les données doivent être stockées et qui peut y accéder, sont l’un des principaux moteurs de l’adoption du multicloud et l’un des aspects les plus difficiles à gérer sans une gouvernance inter-fournisseurs. Les différents fournisseurs, régions et services ont tous des implications différentes en matière de souveraineté. Une gouvernance qui s’étend à tous les fournisseurs permet d’appliquer les exigences de localisation de manière cohérente, plutôt que de les gérer comme des exceptions propres à chaque environnement.