Migration cloud-native : les 5 erreurs qui coûtent cher

Nous voyons passer environ 2-3 PME suisses par an qui ont entrepris une migration "cloud-native" et qui, 12-18 mois plus tard, se retrouvent endettées techniquement et budgétairement.

Ce ne sont pas des incompétents. C'est juste qu'ils ont fait les mêmes 5 erreurs. Gartner prévoit que plus de 95% des nouvelles charges de travail seront déployées sur des plateformes cloud-native d'ici 2025, contre 30% en 2021. La migration n'est plus optionnelle, mais la manière de la faire reste critique.

Ces erreurs coûtent cher. Souvent CHF 50-200k. Parfois plus.

Si vous planifiez une migration cloud-native, lisez ceci avant de commencer.

Erreur 1 : Lift-and-shift (alias "on cloud la même chose qu'on-premise")

C'est la plus commune.

Vous avez une application monolithique qui tourne sur un serveur Debian. Vous la dockerisez, vous la lancez dans un cluster Kubernetes cloud, et vous croyez avoir une "application cloud-native".

Spoiler : vous n'en avez pas. Vous avez juste un monolith très cher à tourner sur du cloud.

Qu'est-ce qui se passe mal

Problème 1 : Scalabilité déceptive

Vous avez une app monolithe. Elle consomme 4GB RAM et 2 CPU cores. Vous mettez ça dans Kubernetes. Quand la charge monte, Kubernetes essaie de scaler en lançant 3-4 copies de votre app.

Résultat : vous passez de 8GB + 4 cores à 32GB + 16 cores. Le coût monte de CHF 200/mois à CHF 800/mois.

Pourquoi ? Parce que votre app est un bloc indivisible. Vous ne pouvez pas scaler un composant spécifique (la partie auth) sans scaler l'app entière.

Problème 2 : Zéro résilience

Un monolithe crash, l'app entire est down. Kubernetes aide un peu (il la redémarre). Mais si le redémarrage prend 2 minutes, vos utilisateurs sont affectés 2 minutes.

Une architecture cloud-native découpe ça en services. La partie auth tombe ? Les autres services continuent.

Problème 3 : Déploiements titanesques

Vous avez une petite feature à déployer (un changement de texte UI). Mais puisque l'app est monolithe, vous devez redéployer l'app entière. Ça prend 5-10 minutes.

Avec microservices, c'est 30 secondes.

Comment l'éviter

Ne lift-and-shift pas. Ou plutôt, faites-le comme étape 0, pas comme destination.

Étapes correctes :

1. Containerisez votre app en tant que monolithe → déployez-le dans Kubernetes (c'est le lift-and-shift)
2. Extractez un premier service critique (auth, par exemple) en microservice. Laissez le reste en monolithe.
3. Testez et stabilisez pendant 3 mois.
4. Itérez. Chaque trimestre, extraire un nouveau service.

Cette approche prend 12-18 mois. C'est lent. Mais à la fin, vous avez une vraie architecture cloud-native. Et vous apprenez au fur et à mesure.

Lift-and-shift seul, c'est prétendre que cloud-native = Kubernetes. Ce n'est pas vrai. Selon le Flexera State of the Cloud Report 2024, 89% des entreprises ont adopté une stratégie multi-cloud, mais seulement 27% ont réellement re-architecturé leurs applications pour en tirer parti.

Erreur 2 : Ignorer CI/CD dès le départ

Vous êtes passé à Kubernetes. Super. Mais vous déployez encore en cliquant sur des boutons Jenkins ou en SSH-ing dans des pods.

Vous avez Kubernetes. Mais vous n'avez pas l'agilité cloud-native. Et vous allez vers un désastre.

Qu'est-ce qui se passe mal

Déploiements manuels = erreurs humaines.

Un opérateur déploie la mauvaise version. Ou oublie de run une migration de DB. Ou déploie en prod avant de tester en staging. Chaque semaine, il y a une story d'un déploiement qui a cassé.

Pas d'audit.

Qui a déployé quoi ? Quand ? Avec quel code ? Aucune idée. Quand il y a un problème, vous investigatez à tâtons.

Scaling manuel impossible.

Vous avez 50 services à déployer. Vous ne pouvez pas les déployer manuellement 50 fois. Donc vous ne déployez pas souvent. Donc les bugs s'accumulent.

Comment l'éviter

Mettez en place CI/CD dès jour 1.

Minimum requis :

• GitHub/GitLab pour le code
• Build automatique quand vous push (dockerfile build)
• Scan de sécurité automatique (SAST, dépendances)
• Test automatique (unit, intégration)
• Déploiement automatique en staging quand les tests passent
• Approval manuel avant prod, puis déploiement automatique en prod

Outils : GitLab CI/CD, GitHub Actions, Jenkins, ArgoCD.

Budget : CHF 2-5k pour setup initial + CHF 500-1000/mois infrastructure.

Ça semble cher. Mais ça vaut CHF 50k en "incidents causés par déploiements manuel" évité chaque année. D'après le rapport DORA (DevOps Research and Assessment) 2024, les équipes "elite" qui automatisent entièrement leur CI/CD déploient à la demande et ont un taux d'échec des changements inférieur à 5%.

Erreur 3 : Pas de plan d'observabilité

Vous êtes passé à Kubernetes avec 10 microservices. Maintenant, une requête utilisateur traverse ces 10 services avant de revenir.

Quand quelque chose casse, vous n'avez aucune idée laquelle de ces 10 services est en faute.

Vous faites du SSH dans les pods et vous loggez du texte brut. Vous avez aucune trace distribuée, aucune métrique, aucun log structuré.

Vous avez échangé "une app monolithe crash" pour "une app microservice qui prend 3 jours à débugger".

Qu'est-ce qui se passe mal

Incident : "la requête est lente".

Avec un monolithe, vous avez une app. Elle est lente. Vous la profile. Vous trouvez la fonction lente. Vous la fixez.

Avec 10 microservices sans observabilité, vous êtes perdu. Vous SSH dans pod 1 : "Pas lent ici". Pod 2 ? Pod 3 ? Vous n'avez aucun moyen de savoir.

Comment l'éviter

Avant même votre première migration, mettre en place l'observabilité.

Minimum : Prometheus (métriques) + Elastic/Loki (logs) + Jaeger (traces).

C'est 2-3 semaines de travail. Ça semble "overkill" au départ. Mais à la première urgence, vous serez heureux.

Et ce n'est pas optionnel. Observabilité en microservices, c'est comme seatbelts en voiture. C'est non-negotiable. Selon le CNCF Annual Survey 2024, 79% des organisations cloud-native considèrent l'observabilité comme un composant critique de leur stack, et Prometheus est déployé dans plus de 86% des environnements Kubernetes.

Erreur 4 : Sous-estimer le training

Vous avez une équipe de devops expérimentés en infrastructure traditionnelle. Vous les mettez sur Kubernetes. Vous croyez qu'ils vont l'apprendre en 2-3 semaines.

Ça prend 3-6 mois pour être réellement compétent en Kubernetes. 12 mois pour être expert.

Si vous apprenez tout seul (pas de consultant), ça peut prendre 12-18 mois. Et pendant ce temps, votre migration traîne.

Qu'est-ce qui se passe mal

Erreurs de design architectural.

Kubernetes a des anti-patterns subtils. Si vous n'êtes pas attentif, vous les reproduisez. Exemple : mettre du state dans vos pods (au lieu de l'externaliser en DB). À la première mise à jour, vous perdez du data.

Over/under-provisioning.

Vous ne savez pas dimensionner les ressources. Soit vous over-alloc (coûts énormes), soit under-alloc (crashs fréquents).

Sécurité piètre.

Vous déployez sans RBAC. Sans network policies. Sans pod security standards. Résultat : n'importe qui peut accéder à n'importe quoi.

Comment l'éviter

Invitez un consultant Kubernetes pendant 1-2 mois.

Non, ce n'est pas un luxe. C'est un sauveur de temps et d'argent. Un bon consultant coûte CHF 150-250/hour. Mais il vous sauve CHF 100k en erreurs évitées.

Ou formez votre équipe sérieusement.

Courses en ligne (Linux Academy, Pluralsight) + labs hands-on + mentoring interne. Budget : CHF 5-10k par personne.

Et ne précipitez pas la migration. Mieux vaut 6 mois d'apprentissage + 6 mois de migration stable que 2 mois de précipitation + 18 mois de dépannage.

Erreur 5 : Choisir un vendor sans garantie suisse

Vous migrez sur Kubernetes. Vous choisissez AWS, Google Cloud, ou Azure. C'est moins cher que Suisse. Super.

Mais à cause de la nLPD, vos données suisses ne peuvent pas être en US/Ireland sans compliance complexe.

Donc 18 mois après le déploiement, audit de conformité arrive. Surprise : vous n'êtes pas compliant. Vous devez migrer vers infrastructure suisse.

Ça coûte CHF 50-100k. Et ça doit être fait dans 3 mois (urgence légale).

Qu'est-ce qui se passe mal

Vendor lock-in + compliance = un piège.

Une fois que vous êtes sur AWS ou Azure, migrer est douloureux. Votre cluster Kubernetes est câblé aux services propriétaires du provider (AMI, VPC, IAM chez AWS). Votre DB est RDS. Vos alertes sont CloudWatch. La CLOUD Act américaine s'applique, ce qui pose un problème réel pour les données personnelles suisses.

Migrer vers infrastructure suisse après coup, c'est refaire 80% du travail, et souvent en urgence sous pression réglementaire.

Comment l'éviter

Choisissez un fournisseur cloud avec data center suisse.

Options :

• Hikube.cloud : Kubernetes managé en Suisse, opéré par Hidora, la référence pour souveraineté + managed services
• Infomaniak : cloud traditionnel en Suisse
• Exoscale : cloud public EU avec options suisse
• On-premise : si vos données sont ultra-sensibles

Oui, c'est 10-20% plus cher qu'AWS US. Mais ça vaut CHF 100k en migration d'urgence évitée, sans compter le risque CLOUD Act.

Checklist : êtes-vous prêt pour une migration cloud-native ?

Honnêtement :

Architecture

• Avez-vous une roadmap claire : monolithe → microservices (pas lift-and-shift direct)
• Avez-vous identifié quels services extraire en premier ?
• Vous acceptez une migration lente (12-18 mois) plutôt que rapide et chaotique ?

CI/CD

• Vous avez un plan CI/CD AVANT la migration ?
• Git + automated build + test + deploy automatique en staging ?
• Déploiement manuel en prod (avec approval) ?

Observabilité

• Prometheus pour les métriques ?
• Elastic/Loki pour les logs ?
• Jaeger ou Sentry pour les traces ?
• Dashboards pour les services critiques ?

Training

• Quelqu'un en équipe a expérience Kubernetes (pas "lié sur internet") ?
• Budget pour consultant ou formation (CHF 5-20k) ?
• Plan de learning : labs, POC, puis migration ?

Compliance/Data

• Vous savez où vos données vont (suisse vs EU vs US) ?
• Vous avez choisi un vendor avec garantie suisse ?
• nLPD compliance checklist addressée ?

Comptez les cases.

• 14+/18 : vous êtes prêt. Go.
• 10-13 : il y a des gaps. Adressez-les avant de démarrer.
• <10 : attendez 6 mois, préparez mieux.

Erreurs vs Coûts

Pour quantifier les erreurs :

Autrement dit : prévenez ces 5 erreurs, et vous économisez CHF 350k.

En résumé

Cloud-native n'est pas juste "mettre les conteneurs dans Kubernetes". C'est une transformation complète : architecture (microservices), processus (CI/CD), observabilité, organisation (training).

Si vous essayez de faire juste la partie "infrastructure", vous allez échouer.

Ces 5 erreurs sont évitables. Elles sont juste communes parce que les PME sous-estiment la complexité.

Avant de commencer votre migration :

1. Acceptez que ça prend 12-18 mois, pas 3-4 mois.
2. Planifiez extraction progressive de services (pas lift-and-shift).
3. Mettez CI/CD dès jour 1.
4. Mettez observabilité dès jour 1.
5. Formez votre équipe ou engagez un consultant.
6. Choisissez infrastructure suisse (nLPD compliance).

Ça semble beaucoup. Mais comparé au coût de faire mal, c'est un investissement judicieux.

Et dans 18 mois, vous aurez une infrastructure cloud-native qui scale, qui est résiliente, et qui est agile. Pas un monolithe sur Kubernetes.

À lire aussi :

• Observabilité : pourquoi vos dashboards ne suffisent pas
• LPD/nLPD : ce que ça change pour votre infrastructure IT

Cet article vous a été utile ? Découvrez comment Hidora peut vous accompagner : Professional Services · Managed Services · SLA Expert