À quel point es-tu exposé à la dépendance au cloud ? Une évaluation multicloud pour les responsables informatiques

Ce que cette évaluation t’aide à évaluer

Point clé : cette évaluation estime ton niveau d’exposition. Le résultat, c’est un petit résumé qui t’indique quelles parties de ton stack résisteraient à un changement que tu pourrais avoir besoin d’effectuer. Le score sert à alimenter une discussion interne pour faire émerger des décisions concrètes.

Il s’agit d’une fiche de travail qui évalue dans quelle mesure ta configuration cloud actuelle résisterait à un changement que tu pourrais réellement devoir effectuer : une nouvelle région pour un client soumis à une réglementation, une migration pour conclure une négociation tarifaire, ou un retour vers un autre fournisseur après une panne. 

Le résultat est un bref aperçu de tes risques que tu peux présenter lors d’une réunion de travail. Réduire ce type d’enfermement propriétaire est également devenu une priorité réglementaire : la loi européenne sur les données (EU Data Act) exige désormais que les fournisseurs de cloud suppriment les obstacles au changement de service, et la norme internationale ISO/IEC 19941 définit, de manière neutre vis-à-vis des fournisseurs, comment la portabilité et l’interopérabilité du cloud doivent fonctionner.
 

Les quatre domaines d’exposition au multicloud

La dépendance au cloud a tendance à se concentrer dans quatre domaines. Note chaque domaine séparément ; une note combinée masque l’emplacement réel de l’exposition.

1. Dépendance vis-à-vis du fournisseur. Dans quelle mesure ton application est-elle étroitement liée aux services, au modèle d’identité ou aux primitives propriétaires d’un fournisseur ?
2. Difficultés de migration. Combien de temps prendrait réellement un transfert prévu vers un autre fournisseur pris en charge ? Des heures, des jours, des semaines, ou c’est difficile à dire ?
3. Incohérence des processus. Tes équipes utilisent-elles le même processus de déploiement chez tous les fournisseurs, ou ont-elles des approches différentes selon le cloud ?
4. Lacunes en matière de gouvernance. Tes contrôles d’audit, tes secrets et tes règles d’accès sont-ils transférables d’un fournisseur à l’autre, ou sont-ils propres à chaque console ?
    

Évalue ta situation actuelle

Pour chaque domaine, attribue-toi une note de 0 à 3.

• 0 Excellent : transférable, documenté, preuves disponibles sur demande.
• 1 Partiel : transférable en principe, mais lent ou insuffisamment documenté.
• 2 Faible : ça demande beaucoup de travail pour changer quoi que ce soit ; ça repose sur des connaissances tacites.
• 3 Vulnérable : le changement est bloqué par des décisions structurelles que tu ne peux pas annuler rapidement.

Sers-toi de ces questions pour attribuer chaque note :

1. Enfermement propriétaire : si tu devais choisir un autre fournisseur demain, quel pourcentage de ta stack faudrait-il reconstruire ?
2. Difficultés de migration : en partant de zéro, en combien de temps pourrais-tu transférer tes données et ta charge de travail vers un autre fournisseur de cloud ?
3. Incohérence des processus : tes équipes utilisent-elles les mêmes étapes de déploiement et les mêmes outils chez tous les fournisseurs, ou le processus change-t-il en fonction du cloud ciblé ?
4. Lacunes de gouvernance : peux-tu produire des preuves d’audit pour une même charge de travail sur plusieurs fournisseurs en une seule requête ?

Un score combiné compris entre 0 et 4 est satisfaisant. Un score entre 5 et 8 indique qu’il existe un risque réel sur lequel il faut travailler. Un score entre 9 et 12 signifie que la dépendance a façonné ton modèle opérationnel.

Prends rendez-vous pour un bilan d’évaluation multicloud 

À quoi ressemblent les schémas à haut risque ?

Trois schémas sont des indicateurs fiables d’une exposition élevée :

• Un pipeline CI/CD par cloud pour la même charge de travail. Même si ça fonctionne aujourd’hui, ça double ta surface opérationnelle et garantit des dérives.
• Les preuves d’audit ont été reconstituées manuellement à partir de plusieurs consoles. Le temps nécessaire pour obtenir ces preuves est un indicateur fiable de la dette de gouvernance.
• Une équipe de plateforme divisée selon l’expertise par fournisseur. Quand l’équipe est divisée par cloud, la charge de travail l’est aussi.

Si l’un de ces éléments est présent et persistant, tu obtiens un score de 2 ou 3 dans au moins un domaine. Si deux d’entre eux sont présents, l’exposition s’aggrave.
 

À quoi ressemble généralement une amélioration

Les mesures d’amélioration sont plus modestes que ce à quoi on s’attend. Trois changements expliquent l’essentiel de la réduction de l’exposition :

• Une définition d’application, validée sur Git, qui cible n’importe quel fournisseur pris en charge sans réécriture. C’est la base ; sans ça, les autres mesures sont moins efficaces.
• Une politique déclarée sous forme de code, appliquée au niveau de la plateforme. La gouvernance reste la même d’un cloud à l’autre, ce qui réduit les cycles d’audit.
• Un seul processus de livraison pour toutes les équipes. Les développeurs n’ont pas besoin d’apprendre un nouveau pipeline quand la cible de déploiement change.

Upsun est conçu selon ce modèle et prend en charge AWS, Azure, Google Cloud, IBM Cloud et OVHcloud depuis une seule et même plateforme.
 

Ce qu’il faut examiner ensuite en interne

Choisis tes deux domaines ayant obtenu les meilleurs scores et organise une session de travail de 30 minutes avec l’équipe responsable de la charge de travail. Pose trois questions : quelle décision a rendu cette vulnérabilité permanente ? À quoi devrait ressembler le changement ? Quel serait le coût de laisser les choses en l’état pendant encore douze mois ?

Les réponses apparaissent généralement clairement pendant la session. Le plus dur, c’est de décider s’il faut agir.

Lis le guide de migration : échapper à la dépendance sans perturbation 

Foire aux questions (FAQ)

Qu’est-ce que la dépendance au cloud ?

La dépendance au cloud, c’est le degré auquel tes applications, tes opérations et ta gouvernance sont liées à un fournisseur de cloud spécifique. Ça se traduit par des services difficiles à déplacer, des processus qui ne fonctionnent que sur un seul cloud et des preuves d’audit que seule une console peut produire. Plus la dépendance est forte, plus tout changement devient lent et coûteux.

Comment mesure-t-on l’exposition à l’enfermement propriétaire ?

L'exposition se mesure selon quatre critères : la dépendance vis-à-vis du fournisseur (à quel point l'application est liée aux services d'un fournisseur), les frictions liées à la migration (combien de temps prendrait un transfert prévu), l'incohérence des processus (si les équipes utilisent le même processus d'un cloud à l'autre) et les lacunes de gouvernance (si les contrôles sont transférables). Note chaque critère sur une échelle de 0 à 3 pour voir où se concentre l'exposition.

Quels sont les signes d’une forte exposition au cloud ?

Trois signes indiquent de manière fiable une forte exposition : le fait de maintenir un pipeline CI/CD par cloud pour la même charge de travail, la reconstruction manuelle des preuves d’audit à partir de plusieurs consoles, et une équipe de plateforme divisée selon l’expertise par fournisseur. Chacun de ces éléments est un problème qu’il vaut mieux régler. Deux d’entre eux combinés aggravent l’exposition plus rapidement que n’importe quelle décision architecturale prise isolément.

Peut-on réduire la dépendance au cloud sans changer de fournisseur ?

Oui. La majeure partie de la réduction de la dépendance au cloud provient de changements au niveau de la couche de déploiement. Une définition d’application portable, une politique déclarée sous forme de code et un processus de déploiement unique réduisent la dépendance sans nécessiter de migration. Le choix du fournisseur devient une décision en aval une fois que la couche de déploiement est consolidée.

Comment réduire concrètement l’exposition au multicloud ?

Trois changements expliquent l’essentiel de la réduction de l’exposition au multicloud : une définition d’application portable enregistrée sur Git, une politique déclarée sous forme de code appliquée au niveau de la plateforme, et un processus de déploiement unique, quel que soit le cloud cible. Le premier changement est le fondement ; sans lui, les autres sont moins efficaces.