Airbus est parti. Et vous ? Le playbook d’un CTO pour une sortie du cloud en 2026

Le retrait d’Airbus d’AWS n’a rien d’un sport d’équipe. C’est un signal. Si un grand compte est prêt à remanier sa stack pour retrouver du levier, vous devez au moins vous poser une question brutale : si vous deviez déplacer 25 % de vos charges de travail en 12 mois, pourriez‑vous le faire sans faire exploser la delivery ?

La plupart des startups et scale‑ups ne le peuvent pas. Non pas parce que le code ne tournerait pas ailleurs, mais parce que la colle ne suit pas. Les services managés, le câblage d’identité, les hypothèses réseau et la gravité des données se solidifient. Ce post propose un cadre de décision pour passer de la bonne idée à une option crédible.

Ce que le choix d’Airbus change vraiment pour vous

Quand un poids lourd déclare son indépendance, les fournisseurs cloud écoutent. Les prix s’assouplissent. Des crédits de migration apparaissent. Les roadmaps bougent. Mais vous n’en profitez que si vous êtes techniquement prêt à partir. Le levier vient de votre capacité de sortie, pas de tweets.

En 2026, la capacité de sortie tient moins du « lift and shift » que de la question : « pouvons‑nous opérer aux mêmes SLO sans comportements propriétaires ? » Cela suppose de remplacer les fonctionnalités spéciales (Step Functions, sémantique FIFO SQS, X‑Ray, politiques de clés KMS) par des équivalents ouverts que vous pouvez exécuter partout.

L’inventaire honnête : vos dépendances sont le verrou

Oubliez les slides marketing — faites un recensement des dépendances. En pratique, le lock‑in se cache en cinq endroits :

• Identité et auth : rôles IAM liés à STS/KMS, identités de service spécifiques au cloud et flux d’URL signées intégrés au code.
• Réseau : NAT gateways, endpoints VPC et hypothèses de facturation cross‑AZ. L’egress et les hairpins peuvent dominer le coût et la complexité.
• Data plane : GSIs/streams DynamoDB, SQLismes Redshift et BigQuery, eventing S3 et politiques de cycle de vie du stockage objet.
• Async et workflows : patterns de fan‑out SQS/SNS, Step Functions, règles EventBridge, partitionnement Kinesis.
• Observabilité et ops : traces/métriques/logs cloud‑natifs (par ex. X‑Ray, CloudWatch Logs) et gestionnaires de secrets managés (SSM, Secrets Manager).

Quand nous auditons des stacks réelles, 60–80 % des conteneurs applicatifs sont portables en quelques heures. Les 20–40 % restants sont collés à un fournisseur par les points ci‑dessus. C’est la vraie carte de migration.

Un cadre de décision en quatre cases pour votre portefeuille

Étiquetez chaque charge de travail dans l’un de ces compartiments. Soyez impitoyable.

1) Portable aujourd’hui (à livrer en premier)

Services stateless en conteneurs avec configuration externalisée et OpenTelemetry, parlant à Postgres ou Redis en TCP. Ces services bougent en quelques jours si vous avez les images, de l’IaC et des secrets abstraits. Servez‑vous‑en pour éprouver votre landing zone et votre GitOps.

2) Portable avec shims (adaptateurs) — nécessite des remplacements

Tout ce qui utilise SQS/SNS, CloudWatch/X‑Ray, Secrets Manager, ou du chiffrement par enveloppe KMS lié à IAM. Il vous faudra des équivalents drop‑in : NATS/Redpanda, collecteurs OpenTelemetry, contrôleurs de secrets externes et un KMS de plateforme qui gère des clés d’enveloppe avec des rôles par service.

3) Ancrées par la gravité des données (à déplacer en dernier)

RDS/Aurora multi‑téraoctets, entrepôts Redshift/BigQuery, buckets S3 au pétaoctet avec de la glue événementielle. Prévoyez du dual‑write ou de la réplication CDC, de la normalisation de schémas (ANSI SQL + vues) et des fenêtres de backfill avec RPO/RTO explicites.

4) PaaS fortement ancrés (évitez d’en ajouter)

Step Functions, automatisations très EventBridge, analytics Kinesis, endpoints ML propriétaires. Geler les nouvelles dépendances, amortissez celles que vous pouvez et isolez le reste derrière des façades internes pour limiter le blast radius.

Faites le calcul : egress, NAT et transferts ne sont pas des détails

Ce n’est pas pour faire peur. C’est de l’arithmétique.

• Egress Internet : À la louche, le transfert de données sortant d’un cloud majeur vers Internet varie souvent entre environ $0.05–$0.09/GB selon le palier et le volume. Déplacez 200 To dans un mois et vous êtes dans une fourchette de $10k–$18k rien que pour les octets sortants. Et avant le compute, les lectures de stockage et les opérations.
• Taxe NAT gateway : Beaucoup d’équipes découvrent tard des factures NAT à six chiffres. À $0.045/GB, 500 To/mois de trafic sortant via NAT représentent ≈$23k/mois. Passez votre architecture d’endpoints privés et d’egress au microscope avant de mirrorer du trafic vers un nouveau cloud.
• Liens privés : Les interconnexions directes peuvent réduire sensiblement le coût par Go par rapport à l’egress public, mais vous échangez du capex/des engagements contre des économies d’opex. Prix et planifiez les deux options ; n’assumez pas qu’une voie soit universellement meilleure.
• Export en vrac : Pour des déplacements uniques et massifs depuis le stockage objet, envisagez des dispositifs d’export physiques ou des crédits de migration négociés. Demandez à votre account team. La capacité de sortie augmente vos chances d’obtenir des concessions significatives.

Modélisez trois scénarios : sortie en vrac ponctuelle, double‑run en régime transitoire (3–6 mois) et multi‑cloud en régime établi (indéfini). Chacun a une courbe de coûts et un risque d’exploitation différents.

Principes de conception qui rendent la sortie possible

Ce n’est pas du dogme. C’est la couche minimale de portabilité.

• Identité : OIDC partout. Standardisez sur des identités de service OIDC avec des tokens de courte durée. Pour les identités in‑cluster, adoptez SPIFFE/SPIRE afin que les workloads n’assument pas les IAM/Service Accounts d’un cloud donné. Contrôlez l’accès KMS par des claims OIDC, pas par des rôles spécifiques au fournisseur.
• Secrets : externalisez avec un contrôleur. Utilisez un opérateur de secrets externe (Kubernetes) pouvant lire n’importe quel backend (cloud KMS, HashiCorp Vault). Vos apps obtiennent le même montage quel que soit l’emplacement du secret.
• Compute : containers d’abord, functions ensuite. S’il n’y a pas besoin d’élasticité milliseconde, faites tourner en conteneurs. Là où vous devez conserver du FaaS, choisissez un runtime qui tourne aussi sur Knative ou OpenFaaS et cachez les SDKs fournisseurs derrière une interface interne.
• Réseau : éliminez les hairpins. Avant de mirrorer du trafic, réduisez NAT et hairpins cross‑AZ en utilisant des endpoints VPC, Private Service Connect, du dual‑stack IPv6 et des load balancers internes. La portabilité meurt sous les factures de bande passante.
• Données : formats ouverts et moteurs portables. Préférez Postgres à des NoSQL propriétaires sauf si vous avez réellement l’échelle de Dynamo. Pour l’analytics, standardisez sur Parquet + Apache Iceberg ou des formats de table ouverts similaires afin que les moteurs (Spark, Trino, Dremio, DuckDB) soient interchangeables.
• Async : standardisez sur un bus portable. SQS va bien jusqu’au jour où ça coince. Pour des topologies complexes, standardisez sur Kafka/Redpanda ou NATS JetStream et traitez les files cloud comme des adaptateurs de bordure.
• Observabilité : OpenTelemetry ou rien. Émettez traces/métriques/logs en OTel. Routez via des collecteurs que vous contrôlez. Si vous dépendez de X‑Ray ou Cloud Monitoring, gardez‑les comme sinks, pas comme sources.

Un plan de migration à deux voies qui préserve la delivery

Vous n’avez pas à choisir entre les features et la portabilité. Faites tourner deux voies en parallèle avec un blast radius strictement limité.

Voie A : arrêter de creuser

• Gelez les nouvelles fonctionnalités propriétaires. Mettez en place un processus d’exception. Si quelqu’un veut Step Functions, il apporte une histoire de portabilité ou vous shippez un wrapper interne.
• Standardisez le contrat de plateforme. Définissez des chemins dorés : buildpacks de conteneurs, identités de service, secrets, OTel, sondes de santé, SLO. Rendez la conformité plus facile que la déviation.
• Refactorez la colle, pas l’app. Remplacez les appels aux SDKs cloud par des interfaces internes. Déplacez la signature, la pagination, les retries et l’idempotence dans des bibliothèques partagées que vous possédez.

Voie B : construire la zone d’atterrissage alternative

• Choisissez une cible crédible. Un autre hyperscaler, un acteur régional ou un cluster Kubernetes en colo — choisissez et rendez‑la réelle. Ne visez pas un multi‑cloud abstrait ; visez une seconde maison opérable.
• Montez une plateforme minimale. Kubernetes avec GitOps, SPIRE, external‑secrets, collecteurs OTel, stockage objet compatible S3 (natif ou MinIO), Postgres et votre bus de messages. Moins de pièces, mieux c’est.
• Mirrorer le trafic d’un petit service à forte valeur. Choisissez un service portable avec des SLO clairs. Faites‑le tourner côte à côte. Prouvez vos chemins de déploiement, rollback, observabilité et incident dans la nouvelle terre.
• Câblez les données de façon responsable. Utilisez CDC (par ex. Debezium) pour mirrorer Postgres. Pour le stockage objet, répliquez les buckets avec checksums. Pour l’analytics, écrivez les nouvelles tables en Iceberg et faites du backfill incrémental.

Fixez un objectif explicite : sous 90 jours, 10 % du RPS de production doit pouvoir tourner exclusivement sur la nouvelle zone d’atterrissage avec les mêmes SLO. Si cela vous paraît impossible, votre contrat de plateforme est trop lâche.

Patterns pour les points durs

Applications très dépendantes de DynamoDB

Trois options :

• Conserver et isoler : si vous êtes marié aux sémantiques Dynamo (GSIs, streams, écritures conditionnelles), isolez la dépendance derrière un service et gardez les données « à la maison » tandis que le compute bouge. Acceptez la latence et les coûts d’egress.
• Refonte schéma et accès : déplacez les hot paths vers Postgres JSONB avec de bons index ou vers un cluster Cassandra/Scylla. Utilisez CDC pour garder les systèmes en phase jusqu’au cutover.
• Façade d’abord : introduisez une couche repository interne qui ne couvre que le sous‑ensemble de fonctionnalités Dynamo que vous utilisez. Remplacez l’implémentation plus tard.

Step Functions et EventBridge

Remplacez par Temporal ou Cadence si vous dépendez de workflows de longue durée. Ce n’est pas gratuit : vous absorberez de la complexité opérationnelle, mais vous posséderez votre orchestration et pourrez l’exécuter partout.

Événements S3 et URL signées

Standardisez sur les sémantiques de l’API S3 comme contrat interne. Pour d’autres clouds, terminez vers la même API via une gateway (compat S3 native ou proxy) pour éviter d’enseigner de nouveaux dialectes à vos apps. Réimplémentez les triggers d’événements avec votre bus portable.

Endpoints ML et accélérateurs propriétaires

Ne faites pas appeler des SDKs fournisseurs directement depuis le code produit. Placez chaque endpoint de modèle externe derrière un broker que vous contrôlez, avec des feature flags et fallbacks par modèle. Containerisez l’inférence quand c’est possible et gardez les poids dans des formats ouverts. Si vous devez utiliser un accélérateur propriétaire, isolez‑le derrière une interface claire et mesurez trimestriellement le coût de remplacement.

Négociation : la capacité de sortie vaut de l’argent, vraiment

Vous pouvez — et devez — négocier :

• Crédits d’egress pour migration. Demandez des crédits explicitement liés aux fenêtres de sortie ou de double‑run. Vous seriez surpris de ce qui apparaît quand vous avez une alternative fonctionnelle.
• Conditions Bring‑Your‑Own‑Key. Si la garde des clés KMS bloque, négociez des améliorations BYOK/BYOKMS ou des clauses de portabilité pour que tourner la clé plus tard ne vous enferme pas.
• Flexibilité des engagements d’usage. Poussez pour de la convertibilité entre services et régions. La capacité à réallouer des commits facilite une sortie en paliers.

La préparation à la sortie rend aussi les renouvellements rationnels. Vous ne bluffez pas quand vous pouvez déplacer 10–25 % de la charge sans réarchitecture.

Risque et SLO : quoi mesurer pour ne pas mettre le feu à la maison

Les sorties cloud échouent quand les leaders sous‑spécifient le risque. Rendez ces éléments explicites :

• RPO/RTO par tier de service. Tagguez les services par criticité et fixez des cibles concrètes (par ex. Tier 1 : RPO ≤ 1 minute, RTO ≤ 15 minutes). Vos designs de réplication et de failover doivent le prouver.
• Garde‑fous de coût. Ciblez un plafond de coût du double‑run par étape (par ex. +15 % de spend plateforme pendant 90 jours). Si vous le dépassez, mettez en pause et optimisez egress/NAT au lieu de sprinter à l’aveugle.
• Parité opérationnelle. La réponse à incident, l’astreinte, les dashboards, la rétention de logs et les contrôles de sécurité doivent exister dans la nouvelle zone d’atterrissage avant d’y envoyer du trafic client.
• Gating de conformité. Menez une revue de sécurité ciblée sur IAM, gestion des secrets, logging et résidence des données. Les sorties modifient souvent votre posture de conformité ; ne laissez pas les auditeurs être votre premier feedback.

Où un pod nearshore aide vraiment

C’est du travail de fond, à la carte, pas un moonshot. Un petit pod nearshore (Brazil vous donne 6–8 heures de chevauchement avec les fuseaux US) peut avaler les tâches de portabilité pendant que votre core team shippe du produit :

• Refactorer l’usage des SDKs cloud derrière des interfaces internes et des bibliothèques partagées.
• Monter GitOps, SPIRE, external‑secrets et des collecteurs OTel avec de l’IaC.
• Remplacer des files/workflows managés par Kafka/NATS/Temporal et durcir avec des tests de chaos.
• Normaliser l’analytics vers Parquet + Iceberg et backfiller avec des checksums vérifiables.
• Instrumenter les runs de migration avec de la télémétrie de coûts (par Go, par requête) pour que la finance voie les progrès en dollars, pas en adjectifs.

Bien fait, vous gagnez des options sans enliser votre roadmap produit.

12 mois, trois jalons

• 0–90 jours : Geler les nouvelles features propriétaires. Construire la zone d’atterrissage alternative. Migrer 1–2 services stateless de bout en bout. Mettre en place le CDC pour une instance Postgres non critique. Implémenter les garde‑fous de coût et de SLO.
• 90–180 jours : Remplacer les chemins d’observabilité et de secrets. Déplacer un vrai service touchant au revenu (tier faible à moyen) et le faire tourner 30 jours à ≥25 % de RPS. Commencer à « dé‑DynamoDB‑iser » un hot path ou l’isoler derrière une façade.
• 180–365 jours : Atterrir votre premier mouvement avec gravité de données (un entrepôt ou un gros bucket objet) avec RPO/RTO mesurables. Atteindre la capacité de faire tourner 25 % du trafic de prod entièrement hors de votre cloud principal pendant au moins une semaine sans régression de SLO.

Les anti‑patterns qui tuent les sorties

• Tout réécrire. Ce n’est pas du greenfield. Enveloppez et étranglez. Remplacez la colle, pas l’app.
• Abstraire jusqu’à l’absurde. Les interfaces fines et maîtrisées valent mieux que des adaptateurs universels que vous ne comprenez pas.
• Escamoter la parité d’observabilité. Si vous ne pouvez pas le voir, vous ne pouvez pas l’opérer. Faites OTel avant le cutover, pas après.
• Considérer l’egress comme trivial. Les octets coûtent de l’argent et du temps. Modélisez. Testez. Négociez.

Le lock‑in ne vient pas que des clouds — surveillez vos formats

Cette semaine a aussi rappelé que les formats propriétaires sont le levier de lock‑in le plus discret. Faites le même choix dans votre stack :

• Données : Parquet + Iceberg plutôt que des couches de tables spécifiques à un vendeur. Traitez le format de table comme un contrat de premier ordre.
• APIs : Préférez des contrats gRPC/HTTP que vous possédez au saupoudrage d’appels de SDKs fournisseurs dans le code produit.
• Config : Gardez l’IaC en Terraform/OpenTofu/Crossplane plutôt que dans des templates propriétaires. Générez, ne cliquez pas.

Une fois vos formats sous votre contrôle, les clouds se battent sur le prix, la latence et les services. C’est ça, le levier.

La conclusion

Vous n’êtes pas obligé de quitter votre cloud. Vous devez être capable de le faire. Le mouvement d’Airbus est la dernière preuve que la capacité de sortie est un actif stratégique. Construisez‑la par couches délibérées — identité, secrets, observabilité, formats de données, async — et prouvez‑la avec une seconde zone d’atterrissage qui porte du trafic réel. Quand la finance demande « pourquoi maintenant », montrez les courbes de coûts et les jetons de négociation que vous gagnez en étant crédiblement multi‑home.

À retenir

• Étiquetez chaque charge de travail en quatre catégories : portable maintenant, portable avec shims, ancrée par les données et PaaS fortement ancré. Planifiez les migrations dans cet ordre.
• Les coûts d’egress, de NAT et de double‑run sont matériels. Modélisez les scénarios « one‑time », « dual‑run » et « multi‑cloud » avant de toucher au trafic.
• Standardisez l’identité (OIDC/SPIRE), les secrets (contrôleurs externes), l’observabilité (OpenTelemetry) et les formats de données (Parquet + Iceberg) pour débloquer la portabilité.
• Suivez un plan à deux voies : geler les nouvelles features propriétaires pendant que vous mettez en place une seconde zone d’atterrissage et migrez un petit service à forte valeur de bout en bout.
• Négociez des crédits d’egress et des engagements flexibles dès que vous pouvez déplacer 10–25 % du trafic sans douleur SLO — la capacité de sortie est un levier.
• Utilisez un pod nearshore pour refactorer la colle et la plomberie de plateforme pendant que votre core team shippe du produit.