Guide de Sortie Cloud · Fiche E · DRH · Change Management · Directions Métiers

HUMAN

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

◆◆◆

LE VERROUILLAGE
DES COMPÉTENCES
DRH · Change Management · Product Owners · Directions Métiers

◆

Les deux faces invisibles du vendor lock-in :
le verrouillage des compétences (Skills Lock-in) que subissent les équipes techniques
et le verrouillage par la demande (Demand Lock-in) que génèrent les directions métiers

◆◆◆

◆ THÈSE CENTRALE

Le skills lock-in est la couche de verrouillage la plus durable. Une entreprise qui migre techniquement vers une stack ouverte mais dont les équipes continuent de penser en termes de "Lambda functions" et de "BigQuery datasets" n'a pas vraiment migré. Et une direction métier qui exprime ses besoins en produits nommés ("je veux Azure OpenAI") plutôt qu'en fonctionnalités ("je veux un service d'inférence LLM") ferme la concurrence avant que la DSI ne commence à négocier.

◆

5Profils de résistance

10Reformulations PO

5Questions PO obligatoires

6Couches de verrouillage

◆

SOMMAIRE

◆ Page 2 · Partie 1 — Skills Lock-in · Anatomie & profils

◆ Page 3 · Partie 1 — Plan de transformation des compétences

◆ Page 4 · Partie 2 — Demand Lock-in · PO & Directions Métiers

◆ Page 5 · Synthèse · 6 couches · Plan d'action commun 6 mois

◆◆◆

Ce document ne constitue pas un conseil juridique au sens de la loi du 31 décembre 1971 ni un conseil RH individualisé.
Pour toute situation spécifique, consultez un cabinet spécialisé en transformation digitale et gestion du changement.

◆

Amine RAITI · Architecte Infrastructure & SRE · SIPS/BCE · Paris
Document public · CC BY-NC-SA 4.0

HUMAN

PARTIE 1 · DRH & CHANGE MANAGEMENT · PAGE 1/2

SKILLS LOCK-IN — ANATOMIE & 5 PROFILS DE RÉSISTANCE

Le verrouillage des compétences est la couche la plus durable car elle est la seule à être invisible dans un bilan comptable

◆

◆ ANATOMIE DU SKILLS LOCK-IN — COMMENT IL SE FORMESTRUCTUREL

AWS compte 12 certifications officielles. GCP 11. Azure 9+. Ces programmes sont gratuits ou fortement subventionnés par les hyperscalers eux-mêmes — parce qu'un ingénieur certifié AWS est un ingénieur dont la valeur marchande dépend de la continuité d'AWS dans son entreprise. Ce n'est pas de la malveillance : c'est de l'écosystème. Le biais d'attachement fonctionne dans les deux sens. L'ingénieur ne veut pas déprécier sa certification. L'entreprise ne veut pas perdre l'ingénieur. Résultat : personne ne propose de migrer.

5 PROFILS DE RÉSISTANCE — NATURE · LEVIER · CE QU'ON NE DIT PAS

① L'INGÉNIEUR "FULL HYPERSCALER" — Certifié AWS/GCP/Azure · >3 ans sur la plateforme

Résistance : peur explicite de la perte de valeur marchande. "Si on quitte AWS, mes certifications ne valent plus rien."

Levier : montrer que CKAD, CKA, Linux Foundation, OpenTofu certifications sont plus portables et mieux rémunérées à long terme. Les compétences hyperscaler = niche. Les compétences ouvertes = marché.

Ce qu'on ne dit pas : sa résistance est rationnelle à court terme. Ne pas la nier — la contextualiser sur 3–5 ans de carrière.

② L'INGÉNIEUR "CONFORT MANAGED SERVICES" — DevOps · SRE · Ops

Résistance : peur du travail opérationnel supplémentaire. "Avant, je cliquais dans la console. Maintenant je dois gérer des fichiers de config à 2h du matin."

Levier : montrer que l'IaC moderne (Terraform/OpenTofu · Helm · ArgoCD) réduit le travail manuel autant que la console. Le diff n'est pas la quantité de travail mais sa nature.

Ce qu'on ne dit pas : les consoles hyperscaler sont des chefs-d'œuvre d'UX conçus pour créer cette dépendance. La nommer aide à la dépasser.

③ L'INGÉNIEUR SENIOR "J'AI CONSTRUIT TOUT ÇA" — >5 ans sur l'architecture existante

Résistance : attachement identitaire à l'architecture. "C'est moi qui ai conçu ce système. Le remettre en question, c'est remettre en question mes décisions."

Levier : l'embarquer comme architecte de la migration, pas comme cible de la migration. Sa connaissance de l'existant est irremplaçable. Il devient l'expert le plus précieux du projet.

Ce qu'on ne dit pas : c'est souvent lui qui a les meilleures raisons de migrer — il connaît les dettes techniques que personne d'autre ne voit.

④ LE MANAGER D'ÉQUIPE — Chef d'équipe tech · Head of Engineering

Résistance : peur des délais et de l'impact sur les OKRs. "Si la migration prend 6 mois, je rate mes objectifs Q3. Mon évaluation va en pâtir."

Levier : donner des chiffres réalistes de migration par couche (voir tableau page 3) · montrer que les migrations progressives n'impactent pas la production · négocier des OKRs de migration spécifiques.

Ce qu'on ne dit pas : sa résistance est souvent un signal que le projet n'a pas été défendu au niveau N+1. Le problème est hiérarchique, pas technique.

⑤ LE MANAGEMENT INTERMÉDIAIRE — Tech Lead · Scrum Master · Chef de Projet

Résistance : résistance passive et invisible. Ni opposition franche ni soutien actif. Priorise les bugs de production sur les tickets de migration. "On verra après la release."

Levier : intégrer explicitement la migration dans les sprints avec des user stories et des définitions de done claires · nommer un champion de migration dans chaque squad · rendre la résistance visible et adressable.

Ce qu'on ne dit pas : c'est le profil le plus dangereux parce qu'il est le moins visible. Son sabotage inconscient peut faire dérailler un projet de migration sans jamais apparaître dans un compte-rendu de comité de pilotage.

HUMAN

PARTIE 1 · DRH & CHANGE MANAGEMENT · PAGE 2/2

PLAN DE TRANSFORMATION DES COMPÉTENCES — 3 PHASES

◆

◆ CARTOGRAPHIE COMPÉTENCES ACTUELLES → COMPÉTENCES REQUISESPRÉALABLE INDISPENSABLE

Compétence hyperscaler

Équivalent ouvert

Delta

Durée formation

AWS Lambda / Cloud Functions / Azure Functions

OpenFaaS · Knative · Fission

Faible

2–4 semaines

CloudWatch / Cloud Monitoring / Azure Monitor

OpenTelemetry + Prometheus + Grafana + Loki

Moyen

3–6 semaines

BigQuery SQL / Redshift / Azure Synapse

ClickHouse SQL · DuckDB

Faible

1–3 semaines

EKS / GKE / AKS

k3s · k0s · Kubernetes vanilla

Faible

1–3 semaines

Terraform (BSL) + console AWS/GCP/Azure

OpenTofu + IaC déclaratif

Faible

1–2 semaines

RDS / Cloud SQL / Azure SQL

PostgreSQL + PgBouncer self-managed

Moyen

3–6 semaines

SageMaker / Vertex AI / Azure ML

vLLM + Ray + MLflow + Hugging Face

Élevé

2–3 mois

S3 / GCS / Azure Blob (SDK AWS)

MinIO (SDK S3 identique) · Scaleway

Nul

0 — zéro refactoring

PLAN DE FORMATION EN 3 PHASES

PHASE 1 · MOIS 1 — SENSIBILISATION · Objectif : lever l'anxiété, créer la curiosité
Sessions de découverte des alternatives (pas de formation technique) · Partage de retours d'expérience de migrations réussies · Démonstrations live de ClickHouse, OpenTelemetry, k3s · Aucune pression sur les timelines · L'objectif est de rendre les alternatives réelles aux yeux des équipes, pas de les convaincre de migrer.

PHASE 2 · MOIS 2–3 — PILOTE · Objectif : prouver sur un cas réel non-critique
Un projet non-critique migré par une équipe volontaire (jamais imposée) · Double compétence maintenue pendant la période · Feedback documenté et partagé à toute l'équipe · Les volontaires deviennent les formateurs internes naturels de la phase 3 · En cas d'échec partiel : documenter pourquoi, pas qui.

PHASE 3 · MOIS 4–6 — DÉPLOIEMENT · Objectif : généraliser sans brutaliser
Formation par vagues de 4–6 personnes · Les anciens ingénieurs hyperscaler deviennent formateurs internes (valorisation, pas dépréciation) · Certification sur standards ouverts valorisée dans les entretiens annuels · Intégration dans les fiches de poste et les critères d'évaluation · La migration devient un projet de montée en compétence, pas de remplacement.

◆ CE QUE LE CHANGE MANAGER NE DOIT PAS FAIRE

❌ Présenter la migration comme une critique des décisions passées

❌ Promettre une timeline irréaliste ("on migre en 2 semaines")

❌ Former tout le monde simultanément — créer des vagues et des ambassadeurs

❌ Ignorer la résistance passive du management intermédiaire

❌ Mesurer uniquement la vitesse de migration — mesurer aussi la qualité de la montée en compétence

❌ Supprimer les accès à l'ancienne plateforme avant que l'équipe soit à l'aise sur la nouvelle

HUMAN

PARTIE 2 · PRODUCT OWNERS & DIRECTIONS MÉTIERS

DEMAND LOCK-IN — COMMENT LES MÉTIERS DEVIENNENT CO-AUTEURS DU VERROUILLAGE

Ce n'est pas la DSI qui a choisi Azure OpenAI. C'est la direction Marketing qui voulait un copilote IA.

◆

◆ ANATOMIE DU DEMAND LOCK-ININVISIBLE DANS LES ANALYSES DE RISQUE HABITUELLES

Le demand lock-in fonctionne parce que les directions métiers expriment des besoins en termes de produits nommés plutôt qu'en termes de fonctionnalités. "Je veux Azure OpenAI" au lieu de "je veux un service d'inférence LLM compatible API OpenAI". "Je veux BigQuery" au lieu de "je veux un entrepôt de données OLAP requêtable sur de grands volumes". Ce glissement sémantique transforme un besoin fonctionnel en engagement fournisseur avant même que la DSI ne commence à évaluer les alternatives. La DSI n'est alors plus prescriptrice — elle est exécutante d'une décision que les métiers ont déjà prise.

◆ GUIDE DE REFORMULATION — 10 EXEMPLES PAR DIRECTIONÀ SYSTÉMATISER AVANT TOUTE DEMANDE DSI

❌ Demande en produit nommé

✅ Reformulation fonctionnelle (ouvre la concurrence)

🎯 Marketing · "On veut Azure OpenAI pour notre chatbot client"

"On veut un service d'inférence LLM · API OpenAI-compatible · latence <2s · 1 000 requêtes/jour · données client non transmises à un tiers pour entraînement"

📊 Data · "On veut BigQuery pour notre data warehouse"

"On veut un entrepôt OLAP capable de requêter 5 To · réponse <5s · 10 analysts simultanés · export CSV/Parquet natif · SQL standard"

⚙️ Ops · "On veut AWS Lambda pour notre pipeline d'événements"

"On veut un service de compute event-driven · stateless · facturation à l'invocation · runtime Python 3.11 · timeout max 15 min · intégration Kafka"

📈 Finance · "On veut Power BI intégré à Azure pour nos rapports"

"On veut un outil de BI · connecteurs SQL/CSV · partage dashboards par lien · authentification SSO · export PDF · hébergement dans notre périmètre de données"

🛒 E-commerce · "On veut DynamoDB pour notre catalogue produits"

"On veut une base NoSQL document · latence <10ms en lecture · 10 000 req/s en pic · schéma flexible · API REST native · SLA 99.99%"

🤖 Produit · "On veut GitHub Copilot pour les devs"

"On veut un assistant de complétion de code · intégré VS Code · modèle configurable · données de code non envoyées pour entraînement · déployable on-premise possible"

👥 RH · "On veut Microsoft Teams + Azure pour notre collaboration"

"On veut une suite de collaboration · messagerie + visio + partage de fichiers · <200 utilisateurs · hébergement EU · conformité RGPD documentée · export des données possible"

🏥 Conformité · "On veut AWS HealthLake pour nos données santé"

"On veut un entrepôt de données santé · format FHIR R4 · hébergement France · HDS certifié · accès par API REST · chiffrement clés client · pas de sous-traitance hors UE"

🔒 Sécurité · "On veut Microsoft Sentinel pour notre SIEM"

"On veut un SIEM · ingestion 50 Go/jour de logs · règles de détection personnalisables · API d'export · rétention 90 jours · intégration SOAR · sans dépendance à un cloud unique"

📦 Logistique · "On veut Google Maps Platform pour notre géolocalisation"

"On veut une API de géocodage + routage · 1 million requêtes/mois · SLA 99.9% · export des données de trajet · alternative : OpenStreetMap + Valhalla open-source"

La reformulation fonctionnelle ouvre la concurrence · La demande en produit nommé la ferme avant l'évaluation

HUMAN

SYNTHÈSE · 6 COUCHES DE VERROUILLAGE · PLAN D'ACTION 6 MOIS

L'ARCHITECTURE COMPLÈTE DU VERROUILLAGE · PLAN D'ACTION COMMUN

◆

◆ 5 QUESTIONS QUE TOUT PO DOIT POSER AVANT DE VALIDER UNE STACKÀ SYSTÉMATISER · PAR ÉCRIT · AVANT TOUTE RÉUNION DSI

"Quelles données de nos clients/utilisateurs seront traitées par ce service ?" → identifier l'exposition RGPD et CLOUD Act avant signature · si données sensibles = exiger hébergement EU et contrat sous droit français

"Sous quel droit applicable ce service est-il contractualisé ?" → identifier si les CGV sont gouvernées par le droit US · une réponse "droit de l'État de Washington" = signal d'alerte

"Quel est le coût de sortie si on change d'avis dans 18 mois ?" → forcer la DSI à quantifier les egress fees et les engagements non résiliables avant de signer

"Existe-t-il une alternative open-source ou souveraine qui couvre 80% du besoin ?" → ne pas exiger 100% de parité · 80% de fonctionnalité avec 100% de souveraineté est souvent le meilleur arbitrage

"Ce service peut-il fonctionner en mode dégradé si le fournisseur est indisponible ?" → résilience et plan de continuité · un service critique sans fallback = dépendance absolue · le fournisseur le sait

◆ LES 6 COUCHES DU VERROUILLAGE — ARCHITECTURE COMPLÈTE

COUCHE 1 · CONTRACTUEL

Clauses non résiliables · Clause de langue · Modification unilatérale · Fiche A

COUCHE 2 · TARIFAIRE

Egress fees · Frais résiliation · Asymétrie entrée/sortie · Fiche C

COUCHE 3 · TECHNIQUE

APIs propriétaires · Services managés · Effet superlinéaire · Fiche B

COUCHE 4 · SKILLS

Certifications propriétaires · Biais d'attachement · Résistance au changement · Fiche E p.2–3

COUCHE 5 · DEMAND

Demandes en produits nommés · Métiers prescripteurs · Fiche E p.4

COUCHE 6 · COGNITIVE

KPIs définis dans la console du fournisseur · Perte des tableaux de bord de pilotage si migration

PLAN D'ACTION COMMUN DRH + MÉTIERS + DSI — 6 MOIS

Période

DRH · Change Manager

Métiers · PO

Indicateur

Mois 1–2

Cartographie certifications · Identification 5 profils · Plan formation

Audit des demandes en produits nommés · Reformulation fonctionnelle · 5 questions PO

Rapport de cartographie validé

Mois 3–4

Phase 2 pilote · Équipe volontaire · Feedback documenté

Validation que l'alternative couvre 80% du besoin métier · Go/No-Go service 1

1 service migré · équipe formée

Mois 5–6

Phase 3 déploiement · Formation par vagues · Certifications ouvertes valorisées

Intégration questions PO dans les processus d'achat · Formation PO sur le demand lock-in

Bilan · décision suite

Continu

Anciens ingénieurs hyperscaler = formateurs internes

Template reformulation dans les briefs · PO = premier filtre de souveraineté

% demandes reformulées

Ce document ne constitue pas un conseil RH ou juridique individualisé · Pour les organisations >200 personnes, un accompagnement par un cabinet spécialisé en transformation digitale est recommandé
Homo sum : humani nil a me alienum puto — Térence · CC BY-NC-SA 4.0 · Amine RAITI