Qu'est-ce que le vendor lock-in dans le cloud ?

Le vendor lock-in cloud est une dépendance à un fournisseur si profonde que changer coûterait plus cher — en argent, temps et risque — que rester. Personne ne le signe volontairement ; il s’accumule — un service propriétaire, un téraoctet, un recrutement spécialisé à la fois — jusqu’à ce que le prix de la sortie soit un chiffre que personne ne veut prononcer en réunion.

Points clés

Le prix du départ, en chiffres

Le lock-in est abstrait jusqu’à ce que vous le posiez sur une facture :

# Le péage de sortie sur les seules données (pricing classique de l'egress)
50 To stockés, sortant à ~0,09 $US/Go :
  50 000 Go × 0,09 $US  ≈  4 500 $US — par copie, par tentative

# À l'échelle réelle, d'après des dossiers pré-IPO et des blogs d'ingénierie :
  de grandes plateformes de streaming/réseaux sociaux ont rapporté
  20 à 50 M$US par an rien qu'en egress

Et le versant code du péage : une app écrite contre des API propriétaires paie en réécritures ce que les données paient en egress. Le contre-motif, c’est du code qui traite le fournisseur comme un détail d’implémentation :

// JavaScript / Node.js — Back4app JS SDK
// The whole "migration": point the SDK at any Parse Server you run
Parse.initialize('APP_ID', 'JS_KEY');
Parse.serverURL = 'https://parseapi.back4app.com'; // hosted today
// Parse.serverURL = 'https://api.yourcompany.com/parse'; // self-hosted tomorrow
// Every query, ACL, and Cloud Function call stays identical.

// Flutter / Dart — Back4app Flutter SDK
// Hosted today; swap the URL to self-host tomorrow — nothing else changes
await Parse().initialize(
  'APP_ID',
  'https://parseapi.back4app.com', // or https://api.yourcompany.com/parse
  clientKey: 'CLIENT_KEY',
);

// iOS / Swift — Back4app Swift SDK
// Hosted today; swap the URL to self-host tomorrow — nothing else changes
ParseSwift.initialize(
  applicationId: "APP_ID",
  clientKey: "CLIENT_KEY",
  serverURL: URL(string: "https://parseapi.back4app.com")! // or your own server
)

// Android / Kotlin — Back4app Android SDK
// Hosted today; swap the URL to self-host tomorrow — nothing else changes
Parse.initialize(
  Parse.Configuration.Builder(context)
    .applicationId("APP_ID")
    .clientKey("CLIENT_KEY")
    .server("https://parseapi.back4app.com") // or https://api.yourcompany.com/parse
    .build()
)

Comment le lock-in se cumule

Les cinq types de lock-in

Le mappage qui désamorce la première ligne : pour la plupart des services propriétaires, un équivalent ouvert existe — base de données gérée → compatible PostgreSQL ; file propriétaire → Kafka ou RabbitMQ ; fonctions propriétaires → runtimes ouverts comme Knative ou OpenFaaS ; backend propriétaire → Parse Server. Choisir la variante compatible open-source d’un service géré coûte peu au moment de l’adoption et change le prix de toute la sortie.

Architecture verrouillée vs. architecture portable

Le tournant réglementaire

L’économie du lock-in a changé par la loi. Le Data Act de l’UE — applicable depuis septembre 2025 — plafonne ce que les fournisseurs peuvent facturer pour un changement aux coûts directs, et à partir de janvier 2027, les frais de changement pour les services cloud servant des clients de l’UE sont interdits purement et simplement. Les grands fournisseurs l’ont devancé en 2024 en renonçant aux frais d’egress pour les clients qui partent définitivement. Les petites lignes comptent : ces renonciations couvrent typiquement le départ, pas les mouvements de données multi-cloud de routine — et le Data Act ne fait rien contre les API propriétaires ni les compétences. La réglementation a baissé le péage ; l’architecture décide toujours si la route existe.

Cas d’usage courants

• Choisir les services gérés délibérément. Évaluer chaque adoption propriétaire “commode” face à son alternative compatible open-source — la décision de lock-in la moins chère est celle prise au moment de l’adoption.
• Planification de la stratégie de sortie. Les régimes de conformité et les conseils d’administration exigent de plus en plus des plans de sortie cloud documentés et testés ; l’inventaire du tableau ci-dessus est le modèle.
• Négociation de contrats. Connaître votre coût réel de changement est un levier au renouvellement — les fournisseurs calibrent leurs offres sur votre prix de sortie.
• Fusions et consolidation. La consolidation cloud post-acquisition est l’endroit où les sorties jamais testées deviennent des surprises très coûteuses.
• Choix de plateforme pour de nouveaux produits. Le moment du choix maximal et du coût minimal — celui où les plateformes basées sur l’open-source convertissent le lock-in de piège en préférence.

Devriez-vous optimiser contre le lock-in ? Matrice de décision

La synthèse : la profondeur est acceptable, l’aveuglement non. Prenez la vélocité mono-fournisseur — avec des services compatibles open-source là où ils existent, un chemin d’export que vous avez réellement exécuté et un prix de sortie que vous pouvez énoncer à voix haute.

Limites et trade-offs

• La portabilité a aussi un prix. Couches d’abstraction, outillage multi-cloud et choix de services au plus petit dénominateur commun coûtent du temps d’ingénierie réel — dépensé à se prémunir d’une migration qui ne viendra peut-être jamais.
• Le multi-cloud n’est pas le remède par défaut. Deux fournisseurs peuvent signifier deux plateformes maîtrisées à moitié, une surface d’intégration doublée et des données réparties entre deux puits de gravité.
• L’open source déplace le risque au lieu de l’effacer. Auto-héberger un stack ouvert échange la dépendance au fournisseur contre une charge opérationnelle ; la sortie est réelle, mais elle n’est pas gratuite.
• Les contrats survivent aux architectures. Le parc conteneurisé le plus propre reste verrouillé par un engagement de trois ans signé pour la remise.
• La part impossible à atténuer : ce qui différencie réellement un fournisseur est, par définition, ce que rien d’autre n’offre. Utilisez-le — en connaissance de cause, à un seul endroit, derrière une interface qui vous appartient.

Le vendor lock-in sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. L’analyse du lock-in est inhabituellement courte : le stack entier est open source, donc le même backend — données, appels de SDK, fonctions, ACL — tourne auto-hébergé sur n’importe quelle infrastructure, et la migration montrée dans les onglets de code ci-dessus est un changement d’URL, pas une réécriture. Cela convertit le trade-off habituel du BaaS (la commodité la plus profonde, le lock-in le plus profond) en commodité gérée avec une sortie permanente et répétable — la dépendance comme un choix que vous refaites sans cesse, et non une porte qui s’est refermée derrière vous.