Guide de Sortie Cloud · Fiche B · DSI

GUIDE DE SORTIE CLOUD · FICHE B · MARCHÉ FRANÇAIS · JUIN 2026

◆◆◆

L'AUDIT DE DÉPENDANCE
DU DSI
Mesurer le niveau de dépendance avant de décider de partir

◆

À l'usage exclusif des Directions des Systèmes d'Information
et des architectes infrastructure · AWS · Google Cloud · Microsoft Azure
Marché français · Droit en vigueur juin 2026

◆◆◆

3Couches de dépendance

4Stratégies de sortie

15Questions pré-renouvellement

1Grille d'évaluation

◆

SOMMAIRE

◆ Page 2 · Les 3 couches de dépendance

◆ Page 3 · La grille d'évaluation par service

◆ Page 4 · Les 4 stratégies de sortie technique

◆ Page 5 · 15 questions pré-renouvellement

◆◆◆

Amine RAITI · Architecte Infrastructure & SRE
Document public · CC BY-NC-SA 4.0 · Ce document ne constitue pas un conseil juridique
Opération Dindon

LES 3 COUCHES DE DÉPENDANCE — CARTOGRAPHIER AVANT DE DÉCIDER

CE QUI VOUS RETIENT VRAIMENT

◆

◆ COUCHE 1 · DÉPENDANCE CONTRACTUELLE — ce que le juriste gèreIDENTIFIER EN PREMIER

Ce que vous devez extraire de votre compte de facturation et de vos contrats :

Reserved Instances / Savings Plans : durée restante en mois × tarif mensuel = exposition financière totale. À extraire depuis la console de facturation (AWS Cost Explorer · GCP Billing · Azure Cost Management).

Capacity Blocks Azure : non annulables, non remboursables. À identifier dans les Product Terms EES ou MOSA et dans les commandes actives.

Engagements Bedrock throughput (AWS) : non résiliables même après résiliation de l'accord. À identifier dans la console AWS Bedrock sous "Provisioned Throughput".

◆ CE QUE CELA SIGNIFIE POUR LA SORTIE

Ces engagements sont le plancher financier incompressible d'une sortie. Une migration progressive laisse ces engagements courir jusqu'à leur terme naturel pendant qu'on migre le reste. Une résiliation anticipée (possible sous certains fondements légaux) nécessite l'intervention du juriste.

◆ COUCHE 2 · DÉPENDANCE TARIFAIRE — les egress feesQUANTIFIER AVANT TOUT

Méthode de calcul du coût de sortie des données :

Étape 1 : Identifier le volume total de données stockées par service (S3/GCS/Azure Blob · bases de données · data warehouses · logs).

Étape 2 : Appliquer le tarif d'egress Internet du fournisseur (AWS : 0,08–0,09 $/Go · GCP : 0,08–0,12 $/Go · Azure : 0,07–0,09 $/Go). Pour 100 To : fourchette 7 000–12 000 € selon fournisseur et région.

Étape 3 : Demander au fournisseur une simulation écrite du coût d'egress sur votre volume exact. Ce chiffre écrit est opposable dans une négociation au titre du Data Act art. 25.

◆ POINT D'ATTENTION

Certains transferts vers Internet sont partiellement exemptés (Azure : 5 Go/mois gratuits · AWS : transferts vers certains services AWS gratuits). Calculer le coût net après exemptions avant de présenter le chiffre à la direction.

◆ COUCHE 3 · DÉPENDANCE TECHNIQUE — les APIs propriétairesÉVALUER PAR SERVICE

Trois niveaux de dépendance technique :

Niveau 1 — Faible : service utilisant des standards ouverts (S3-compatible storage · PostgreSQL managed · Kubernetes). Migration possible en quelques semaines.

Niveau 2 — Moyen : service avec API propriétaire mais alternative open-source viable (Lambda → OpenFaaS · BigQuery → ClickHouse · Azure Functions → Knative). Migration nécessite un refactoring partiel : quelques semaines à quelques mois.

Niveau 3 — Fort : service sans équivalent direct (AWS Bedrock · Google Vertex AI · Azure OpenAI · certains services managés de ML). Migration nécessite une réécriture substantielle ou un changement d'approche : plusieurs mois.

LA GRILLE D'ÉVALUATION — SERVICE PAR SERVICE

CARTOGRAPHIER SA DÉPENDANCE AVANT DE DÉCIDER

◆

⚠ MODE D'EMPLOI

Remplir ce tableau pour chaque service cloud utilisé. La colonne "Score" est la somme des trois niveaux : un service noté Faible/Faible/Faible est le premier candidat à la migration. Un service noté Fort/Fort/Fort doit être maintenu jusqu'à la fin de son engagement naturel pendant qu'on migre le reste. Ce document est un outil de priorisation, pas une décision de migration.

Service / Usage

Dép. Contractuelle

Dép. Tarifaire (egress)

Dép. Technique (API)

Stockage objet (S3 · GCS · Blob)

MOYEN Souvent sous Savings

FORT Volume = coût egress

FAIBLE Standards S3-compat.

BDD managée (RDS · Cloud SQL · Azure SQL)

MOYEN Souvent résiliable

MOYEN Export possible

FAIBLE PostgreSQL/MySQL std

Calcul serverless (Lambda · Functions)

FAIBLE Pay-as-you-go

FAIBLE Peu de données

MOYEN Refactoring requis

Data warehouse (BigQuery · Redshift · Synapse)

MOYEN Committed use

FORT Volume important

FORT SQL propriétaire

IA générative (Bedrock · Vertex · Azure OpenAI)

FORT Throughput non rés.

FAIBLE Peu d'egress

FORT API sans équivalent

Kubernetes managé (EKS · GKE · AKS)

FAIBLE Résiliable

MOYEN Données applicatives

FAIBLE K8s standard

Identité & IAM (Cognito · Identity Platform · Entra)

FAIBLE Résiliable

FAIBLE Données légères

FORT Forte intégration

CDN & réseau (CloudFront · Cloud CDN · Azure CDN)

FAIBLE Résiliable

FORT Egress CDN élevé

FAIBLE Standards HTTP

◆ PRIORITÉS DE MIGRATION

FAIBLE/FAIBLE/FAIBLE → Migrer en premier · impact minimal
MOYEN → Planifier sur 3–6 mois
FORT → Laisser courir jusqu'à terme naturel

◆ RÈGLE PRATIQUE

Commencer par migrer ce qui ne coûte rien à sortir. Cela réduit la facture globale et crée un précédent opérationnel utile pour les migrations plus complexes.

LES 4 STRATÉGIES DE SORTIE TECHNIQUE

CHOISIR LA STRATÉGIE ADAPTÉE À SON PROFIL

◆

◆ STRATÉGIE 1 · LIFT AND SHIFT — Migration à l'identiqueRAPIDE · COÛT MODÉRÉ

Principe : reproduire l'architecture existante chez un autre fournisseur cloud sans réécriture applicative. Convient aux workloads containerisés (Kubernetes) ou aux architectures IaaS classiques.

Avantages : délai court (4–12 semaines) · risque opérationnel faible · coût de migration maîtrisé.

Limites : ne réduit pas la dépendance aux services managés propriétaires · le lock-in se transfère d'un fournisseur à l'autre si on choisit des services équivalents chez le nouveau fournisseur.

◆ QUAND L'UTILISER

Workloads IaaS ou conteneurisés sans dépendance forte aux services managés · budget de migration limité · délai de sortie court imposé par la direction.

◆ STRATÉGIE 2 · REFACTORING PROGRESSIF — Substitution des APIs propriétairesLONG · ROI ÉLEVÉ

Principe : remplacer les APIs propriétaires par des alternatives ouvertes ou multi-cloud (Lambda → OpenFaaS/Knative · BigQuery → ClickHouse/DuckDB · Bedrock → modèles open-source hébergés).

Avantages : réduit structurellement le lock-in technique · améliore la portabilité à long terme · chaque service migré est un levier de négociation supplémentaire.

Limites : délai long (6–18 mois selon la complexité) · coût de développement élevé · nécessite une montée en compétence des équipes.

◆ QUAND L'UTILISER

Organisation avec des équipes techniques solides · enjeu de coût cloud supérieur à 500 k€/an · décision stratégique de long terme de réduction de la dépendance.

◆ STRATÉGIE 3 · MULTI-CLOUD — Répartition sans sortie totaleLEVIER DE NÉGOCIATION

Principe : répartir les workloads sur plusieurs fournisseurs pour réduire la dépendance à un seul et créer un vrai levier de négociation. Même une présence partielle chez un concurrent crédibilise la menace de migration.

Avantages : levier de négociation immédiat · continuité opérationnelle assurée · réduction du risque de concentration.

Limites : complexité opérationnelle accrue · coûts de formation et d'outillage · ne supprime pas les engagements non résiliables existants.

◆ STRATÉGIE 4 · RETOUR ON-PREMISE PARTIEL — Pour les données sensiblesCONFORMITÉ · DONNÉES SENSIBLES

Principe : rapatrier les données et workloads sensibles sur des infrastructures internes hébergées en France, conformément à la circulaire "Cloud au centre" (Borne, 31 mai 2023) pour les entités publiques.

Avantages : élimine la problématique du CLOUD Act américain · conformité totale avec la doctrine "Cloud au centre" · maîtrise totale des données.

◆ QUAND L'UTILISER

Données de santé · données fiscales · données personnelles sensibles · entités publiques soumises à la doctrine "Cloud au centre".

15 QUESTIONS À POSER AVANT DE SIGNER OU RENOUVELER

CE QU'UNE MAUVAISE RÉPONSE SIGNIFIE

◆

🔵 QUESTIONS TECHNIQUES

Quels services utilisent des APIs propriétaires non portables ? Mauvaise réponse : "Tous nos services sont standards." À demander par écrit avec liste exhaustive.

Quel est le coût d'egress estimé sur notre volume actuel de données ? Mauvaise réponse : renvoi à la grille tarifaire sans estimation sur votre volume spécifique.

Dans quel format nos données sont-elles exportables ? Format propriétaire = dépendance technique. Exiger format ouvert documenté.

Quels outils de migration fournissez-vous si nous décidons de partir ? Absence d'outil = obstacle au switching au sens du Data Act art. 25.

Vos SLA sont-ils garantis contractuellement ou "best effort" ? "Best effort" dans un engagement non résiliable = déséquilibre significatif.

Quels sont les délais de préavis pour chaque service avant suppression ? Absence de délai = risque de coupure sans préavis (AWS s.1.4).

Où sont hébergées physiquement nos données et nos clés de chiffrement ? Clés gérées par le fournisseur aux USA = exposition CLOUD Act.

🔴 QUESTIONS CONTRACTUELLES

Quelle version linguistique des CGV fait foi ? "La version anglaise prime" = Loi Toubon art. 5 violée. Demander confirmation écrite que la version française est contractuellement opposable.

Quels engagements ne peuvent pas être résiliés en cas de changement de stratégie ? Liste exhaustive requise avec montants et durées. Absence de liste = risque de surprise.

Sous quelles conditions les Product Terms peuvent-ils être modifiés ? "À tout moment sans préavis" = Code Civil art. 1193 violé.

Les egress fees sont-ils plafonnés ou négociables dans notre contrat ? Absence de plafond = obstacle tarifaire au switching (Data Act art. 25).

Quel tribunal est compétent en cas de litige ? Tribunal étranger = CPC art. 48 · inopposable en France dans un contrat d'adhésion.

Avez-vous signé le Data Act Addendum ? Absence = droits Data Act art. 23-25 non formalisés contractuellement. AWS l'a incorporé (s.1.28) — demander l'équivalent à GCP et Azure.

Les frais d'ingestion sont-ils garantis à 0 pour la durée du contrat ? Les fournisseurs peuvent introduire des frais d'ingestion — à verrouiller contractuellement.

Votre opt-out IA (désactivation de l'entraînement des modèles sur nos données) est-il activé et confirmé par écrit ? Non-confirmation = RGPD art. 6 · consentement non établi.

Fondé sur les analyses juridiques CGV AWS · GCP · Azure · MOSA & EES · juin 2026
Per aspera ad astra · Document public · CC BY-NC-SA 4.0 · Amine RAITI