Il y a encore quelques années, lorsqu’une entreprise avait besoin d’un nouveau serveur, le processus pouvait ressembler à ceci :
Elle estimait ses futurs besoins.
Elle commandait du matériel.
Elle attendait sa livraison.
Elle installait le serveur.
Elle configurait le réseau.
Elle installait les logiciels.
Puis elle espérait avoir correctement anticipé la capacité nécessaire pour les trois prochaines années.
Si elle avait prévu trop grand, elle payait pour des ressources inutilisées.
Si elle avait prévu trop petit, elle devait recommencer.
Aujourd’hui, le scénario peut être totalement différent.
Une entreprise a besoin de davantage de puissance informatique.
Quelques minutes plus tard, elle peut provisionner :
- de nouveaux serveurs ;
- du stockage ;
- une base de données ;
- des capacités de calcul ;
- des services d’intelligence artificielle.
Puis réduire ces ressources lorsque le besoin disparaît.
C’est l’une des promesses fondamentales du cloud computing.
Mais elle n’explique qu’une partie de la transformation.
Car si autant d’entreprises migrent aujourd’hui vers le cloud, ce n’est pas simplement pour arrêter d’acheter des serveurs.
Elles cherchent également à devenir :
plus rapides, plus flexibles, plus résilientes et parfois plus innovantes.
Selon la définition de référence du National Institute of Standards and Technology, le cloud computing permet d’accéder à la demande, via le réseau, à un ensemble partagé de ressources informatiques configurables qui peuvent être rapidement fournies et libérées avec un effort de gestion limité. Le NIST retient notamment cinq grandes caractéristiques : libre-service à la demande, accès réseau, mutualisation des ressources, élasticité rapide et service mesuré.
En langage simple :
Le cloud permet à une entreprise de consommer de l’informatique davantage comme un service que comme un ensemble de machines qu’elle doit acheter et exploiter elle-même.
Et cette différence change énormément de choses.
Qu’est-ce que le cloud computing exactement ?
Commençons par éliminer une idée reçue.
Le cloud n’est pas réellement “dans les nuages”.
Les données et applications fonctionnent toujours sur :
- des serveurs ;
- des disques ;
- des réseaux ;
- des datacenters.
La grande différence est principalement :
qui possède et exploite l’infrastructure, comment l’entreprise y accède et comment elle la paie.
Dans un modèle traditionnel, l’entreprise peut acheter :
- ses serveurs ;
- ses équipements réseau ;
- son stockage.
Elle les installe dans ses locaux ou dans un datacenter.
On parle souvent d’infrastructure :
on-premise ou on-premises.
Avec le cloud, une partie de ces ressources peut être fournie à distance par un prestataire.
Parmi les acteurs les plus connus :
- Amazon Web Services ;
- Microsoft Azure ;
- Google Cloud.
Mais il existe évidemment de nombreux autres fournisseurs.
Une analogie simple : acheter une centrale électrique ou acheter de l’électricité
Imaginez que chaque entreprise doive produire elle-même son électricité.
Elle devrait :
- acheter des générateurs ;
- les entretenir ;
- prévoir les pics de consommation ;
- conserver des pièces détachées ;
- embaucher des spécialistes.
Cela serait extrêmement lourd.
À la place, la majorité des entreprises utilisent simplement le réseau électrique.
Elles consomment ce dont elles ont besoin.
L’infrastructure complexe reste principalement chez le fournisseur.
Le cloud applique une logique assez comparable à l’informatique.
Au lieu de posséder nécessairement toute l’infrastructure :
l’entreprise consomme une capacité informatique fournie comme un service.
Cette analogie n’est évidemment pas parfaite, mais elle permet de comprendre le changement de modèle.
Les trois grands modèles : IaaS, PaaS et SaaS
Le NIST distingue trois grands modèles de services cloud : IaaS, PaaS et SaaS.
Voyons-les simplement.
IaaS : Infrastructure as a Service
Le fournisseur vous apporte essentiellement :
- machines virtuelles ;
- stockage ;
- réseau ;
- capacité de calcul.
Mais votre entreprise continue à gérer une partie importante du système.
Par exemple :
- système d’exploitation ;
- applications ;
- configurations.
C’est comme louer une cuisine professionnelle vide.
Le bâtiment existe.
L’électricité fonctionne.
Mais vous devez toujours organiser votre cuisine.
PaaS : Platform as a Service
Le fournisseur gère davantage de choses.
Vous vous concentrez principalement sur :
- votre application ;
- votre code ;
- vos données.
Une partie importante de l’infrastructure technique est abstraite.
C’est comme louer une cuisine déjà équipée et entretenue.
Vous cuisinez.
Le propriétaire gère une grande partie du reste.
SaaS : Software as a Service
Ici, vous utilisez directement le logiciel final.
Exemples typiques :
- messagerie professionnelle ;
- CRM ;
- outils collaboratifs ;
- logiciels de gestion.
L’entreprise n’administre généralement ni les serveurs ni la plateforme sous-jacente.
Elle utilise simplement le service.
Vous utilisez probablement déjà le cloud sans vous en rendre compte
Une PME qui utilise :
- un CRM en ligne ;
- Google Workspace ou Microsoft 365 ;
- un logiciel de facturation accessible via navigateur ;
- Dropbox ;
- Slack ;
- un logiciel RH en SaaS ;
utilise déjà des services cloud.
Migrer vers le cloud ne signifie donc pas nécessairement déplacer un gigantesque datacenter.
Pour une petite entreprise, cela peut simplement vouloir dire :
remplacer plusieurs logiciels installés localement par des solutions accessibles en ligne.
Cloud public, cloud privé et cloud hybride
Autre distinction importante.
Le cloud n’existe pas sous une seule forme.
Le NIST distingue notamment plusieurs modèles de déploiement, parmi lesquels le cloud public, privé et hybride.
Cloud public
L’infrastructure appartient à un fournisseur de services cloud.
Plusieurs clients utilisent les capacités du fournisseur avec une séparation logique entre leurs environnements.
Avantages potentiels :
- grande flexibilité ;
- déploiement rapide ;
- immense catalogue de services ;
- investissement initial limité.
Cloud privé
L’environnement cloud est réservé à une seule organisation.
Il peut être exploité :
- directement par l’entreprise ;
- par un prestataire.
L’objectif peut être d’obtenir certains avantages du cloud tout en conservant davantage de contrôle.
Cloud hybride
L’entreprise combine plusieurs environnements.
Par exemple :
- certaines applications restent dans son datacenter ;
- d’autres passent dans le cloud public.
Elle peut aussi connecter cloud privé et cloud public.
C’est extrêmement fréquent dans les grandes organisations.
Pourquoi ?
Parce qu’une migration complète en une seule fois est rarement réaliste.
Et le multicloud ?
Le multicloud consiste à utiliser plusieurs fournisseurs cloud.
Par exemple :
- certains workloads chez AWS ;
- d’autres chez Azure ;
- d’autres services chez Google Cloud.
Cela peut permettre :
- d’utiliser les meilleurs services de chaque fournisseur ;
- de répondre à certaines contraintes ;
- de diversifier certains risques.
Mais cela ajoute également beaucoup de complexité.
Multicloud ne signifie donc pas automatiquement :
meilleure stratégie cloud.
Pourquoi les entreprises migrent-elles vers le cloud ?
Les motivations varient énormément.
Une startup de dix personnes n’a pas les mêmes raisons qu’une banque internationale.
Mais plusieurs motivations reviennent régulièrement.
1. Pour gagner énormément en vitesse
C’est probablement l’un des bénéfices les plus importants.
Imaginez une entreprise traditionnelle.
Elle veut tester une nouvelle application.
Elle doit peut-être :
- définir les besoins ;
- obtenir un budget ;
- commander un serveur ;
- attendre ;
- installer ;
- configurer ;
- sécuriser ;
- déployer.
Cela peut prendre des semaines.
Dans le cloud :
les ressources peuvent parfois être créées en quelques minutes.
Cette vitesse change profondément la capacité d’une entreprise à expérimenter.
Un développeur peut :
- créer un environnement ;
- tester ;
- mesurer ;
- supprimer l’environnement.
Le coût de l’expérimentation diminue.
2. Pour ne plus dimensionner l’infrastructure plusieurs années à l’avance
C’est l’un des grands problèmes de l’informatique traditionnelle.
Supposons que votre entreprise possède actuellement :
100 000 utilisateurs.
Vous pensez atteindre :
500 000 utilisateurs dans trois ans.
Quelle infrastructure achetez-vous aujourd’hui ?
Celle pour :
100 000 ?
Vous risquez de manquer de capacité.
Celle pour :
500 000 ?
Vous payez maintenant pour des ressources inutilisées.
Le cloud change cette logique.
Vous pouvez démarrer avec une capacité limitée.
Puis l’augmenter lorsque le besoin apparaît.
C’est le principe d’élasticité, l’une des caractéristiques essentielles du cloud retenues par le NIST.
3. Pour absorber plus facilement les pics de trafic
Imaginez un e-commerce.
Trafic habituel :
20 000 visiteurs par jour.
Black Friday :
400 000 visiteurs.
Dans une infrastructure traditionnelle, il faudrait potentiellement posséder toute l’année une infrastructure capable de gérer le Black Friday.
Cela signifie qu’elle serait largement sous-utilisée le reste du temps.
Avec une architecture cloud correctement conçue, la capacité peut augmenter pendant le pic puis diminuer ensuite.
Attention cependant :
le scaling n’est pas automatique simplement parce qu’une application est hébergée dans le cloud.
L’application et l’architecture doivent être conçues correctement.
4. Pour transformer une partie des investissements en dépenses variables
Historiquement, une infrastructure informatique demandait souvent un important investissement initial.
Vous achetiez :
- serveurs ;
- stockage ;
- réseau ;
- licences ;
- équipements.
Puis vous amortissiez ces investissements.
Le cloud permet davantage un modèle :
pay-as-you-go.
Vous consommez.
Puis vous payez en fonction de certains usages.
Cette caractéristique de service mesuré fait partie de la définition du cloud du NIST.
Cela permet notamment de réduire certaines barrières à l’entrée.
Une startup n’a pas besoin d’acheter un datacenter avant d’obtenir ses premiers clients.
Mais attention : cloud ne signifie pas automatiquement moins cher
C’est probablement l’un des mythes les plus importants.
Beaucoup d’entreprises migrent en pensant :
“Le cloud va faire baisser notre facture informatique.”
Parfois oui.
Parfois non.
Et parfois la facture augmente considérablement.
Pourquoi ?
Parce que la facilité d’utilisation du cloud possède un revers.
Créer une ressource est facile.
L’oublier est également facile.
Une entreprise peut accumuler :
- machines inutilisées ;
- stockage oublié ;
- environnements de test ;
- bases surdimensionnées ;
- services non arrêtés.
La gestion des coûts cloud est devenue un sujet stratégique à part entière.
Selon le State of the Cloud 2026 de Flexera, 85 % des répondants considèrent la maîtrise des coûts cloud comme leur principal défi et estiment en moyenne que 29 % des dépenses IaaS/PaaS sont gaspillées. Ces chiffres proviennent d’une enquête d’un fournisseur de solutions de gestion technologique et doivent donc être considérés comme un indicateur du marché plutôt que comme une mesure universelle de toutes les entreprises.
Le cloud change donc la nature du problème financier
Avant :
“Avons-nous acheté trop de serveurs ?”
Maintenant :
“Consommons-nous trop de ressources ?”
C’est une différence importante.
Les entreprises développent donc de plus en plus des pratiques de :
FinOps.
L’objectif est de rapprocher :
- finance ;
- ingénierie ;
- produit ;
- cloud.
Pour répondre à une question simple :
Quelle valeur business obtenons-nous pour chaque euro dépensé dans le cloud ?
5. Pour accélérer le lancement de nouveaux produits
Imaginons deux entreprises concurrentes.
Entreprise A
Pour tester une nouvelle application :
2 mois d’infrastructure.
Entreprise B
Pour tester :
2 jours.
Même si les deux possèdent les mêmes développeurs, l’entreprise B peut réaliser davantage d’expériences.
Sur plusieurs années, cette différence peut devenir considérable.
Le véritable avantage du cloud n’est donc pas toujours :
réduire les coûts informatiques.
Il peut être :
réduire le temps entre une idée et son test sur le marché.
Et pour une startup, ce délai peut être extrêmement important.
6. Pour accéder à des technologies qui seraient très coûteuses à construire soi-même
Les grands clouds proposent aujourd’hui des centaines de services.
Par exemple :
- bases de données ;
- machine learning ;
- intelligence artificielle ;
- analyse de données ;
- traitement vidéo ;
- reconnaissance d’images ;
- traduction ;
- stockage ;
- cybersécurité ;
- IoT.
Une entreprise peut donc utiliser une infrastructure sophistiquée sans la reconstruire intégralement.
Prenons une base de données.
Construire une infrastructure complète autour d’une base distribuée demande :
- compétences ;
- backups ;
- réplication ;
- monitoring ;
- mises à jour.
Un service managé peut prendre en charge une partie importante de ces tâches.
7. Pour réduire une partie du travail d’administration
C’est une évolution extrêmement importante.
Prenons une base de données traditionnelle.
L’équipe doit potentiellement gérer :
- serveur ;
- système d’exploitation ;
- patches ;
- sauvegardes ;
- haute disponibilité ;
- monitoring.
Avec une base de données managée, le fournisseur peut prendre en charge une partie de ces responsabilités.
L’équipe interne peut alors consacrer davantage de temps à :
la valeur métier.
Par exemple :
développer la fonctionnalité que le client utilisera.
Plutôt que :
mettre à jour un serveur.
8. Pour améliorer la résilience
Une entreprise moderne dépend énormément de son système informatique.
Une panne peut :
- arrêter les commandes ;
- bloquer les salariés ;
- empêcher les paiements ;
- rendre un service inaccessible.
Les grands fournisseurs cloud possèdent généralement plusieurs :
- régions ;
- datacenters ;
- zones de disponibilité.
Une architecture correctement conçue peut donc répartir les services sur plusieurs emplacements.
Si un composant tombe, d’autres peuvent continuer.
Mais il existe une nuance capitale :
le cloud donne accès à des outils de résilience. Il ne rend pas automatiquement une application résiliente.
Si vous déployez toute votre entreprise sur :
- une seule machine ;
- une seule zone ;
- sans sauvegarde ;
vous restez vulnérable.
9. Pour améliorer les plans de reprise après sinistre
Que se passe-t-il si :
- un datacenter brûle ;
- une machine critique tombe ;
- des données sont corrompues ;
- une attaque bloque l’infrastructure ?
Les entreprises doivent prévoir un :
Disaster Recovery Plan.
Le cloud peut faciliter la création :
- de sauvegardes distribuées ;
- d’environnements secondaires ;
- de réplication ;
- de restaurations automatisées.
Mais là encore :
avoir une sauvegarde n’est pas suffisant.
Il faut tester régulièrement qu’elle peut réellement être restaurée.
10. Pour soutenir le travail distribué
La pandémie a montré à quel point l’accès à distance aux outils professionnels pouvait devenir critique.
Une entreprise dont les ressources sont accessibles via des services cloud peut plus facilement permettre à ses collaborateurs de travailler :
- depuis le bureau ;
- depuis chez eux ;
- depuis un autre pays.
À condition évidemment que :
- les droits d’accès ;
- les identités ;
- la sécurité ;
soient correctement gérés.
11. Pour faciliter l’expansion internationale
Imaginez une startup française.
Son application fonctionne à Paris.
Puis elle veut servir :
- les États-Unis ;
- Singapour ;
- l’Australie.
Construire ses propres datacenters serait extrêmement coûteux.
Avec le cloud, elle peut parfois utiliser des infrastructures déjà présentes dans différentes régions du monde.
Cela peut aider à réduire :
- latence ;
- complexité d’expansion.
Mais attention :
la localisation des données et les réglementations doivent être analysées attentivement.
12. Pour automatiser davantage l’infrastructure
L’un des grands changements apportés par le cloud est la possibilité de gérer l’infrastructure comme du logiciel.
On parle notamment :
Infrastructure as Code.
Au lieu qu’un ingénieur clique manuellement dans une interface pour créer :
- serveurs ;
- réseaux ;
- bases ;
il peut décrire l’infrastructure dans du code.
Cela permet :
- versioning ;
- répétabilité ;
- automatisation ;
- audits ;
- déploiements plus cohérents.
Exemple
Vous avez besoin de créer :
un réseau ;
trois serveurs ;
une base ;
un load balancer.
Au lieu de tout configurer manuellement :
vous exécutez une configuration automatisée.
Le même environnement peut ensuite être recréé.
C’est particulièrement puissant pour :
- développement ;
- test ;
- production.
13. Pour améliorer la standardisation
Dans certaines entreprises anciennes, l’infrastructure ressemble à ceci :
Serveur A :
Ubuntu 18.
Serveur B :
Ubuntu 20.
Serveur C :
configuration inconnue.
Serveur D :
personne ne sait réellement ce qu’il fait.
Cette accumulation constitue une dette technique.
Une migration cloud peut devenir l’occasion de :
- inventorier ;
- standardiser ;
- automatiser ;
- supprimer les systèmes inutiles.
La migration n’est donc pas seulement physique.
Elle peut devenir un projet de modernisation.
14. Pour faciliter l’accès à l’intelligence artificielle
Depuis l’explosion de l’IA générative, cette motivation prend encore davantage d’importance.
Les fournisseurs cloud proposent aujourd’hui :
- GPU ;
- modèles ;
- API ;
- plateformes de machine learning ;
- outils de données ;
- services spécialisés.
Une entreprise souhaitant expérimenter avec l’IA peut donc accéder rapidement à des capacités de calcul qu’il serait extrêmement coûteux d’acheter pour une utilisation ponctuelle.
Cela contribue également à la hausse des dépenses cloud observée ces dernières années.
Flexera indique notamment que la croissance des workloads liés à l’IA contribue à la complexité croissante de la gestion des coûts cloud.
15. Parce que le cloud permet parfois aux équipes techniques de se concentrer davantage sur le produit
Imaginez une startup avec cinq développeurs.
Chaque semaine, deux passent énormément de temps à :
- réparer des serveurs ;
- installer des mises à jour ;
- gérer des sauvegardes ;
- maintenir l’infrastructure.
Ce temps n’est pas nécessairement perdu.
Mais ce n’est pas le cœur de la différenciation de l’entreprise.
Le cloud permet parfois d’acheter comme service certaines capacités génériques.
Les développeurs peuvent alors consacrer davantage de temps à :
ce qui rend réellement le produit unique.
Migration cloud : les 6 grandes stratégies
Toutes les migrations ne se ressemblent pas.
Une classification classique distingue plusieurs approches.
1. Rehost — déplacer presque tel quel
On parle souvent de :
lift and shift.
L’application est déplacée vers le cloud sans modification majeure.
Avantages :
- rapide ;
- relativement simple.
Inconvénient :
elle n’exploite pas nécessairement les avantages du cloud.
Exemple
Vous avez :
10 machines virtuelles dans votre datacenter.
Vous créez :
10 machines virtuelles équivalentes dans le cloud.
Techniquement :
vous êtes dans le cloud.
Architecturalement :
presque rien n’a changé.
2. Replatform — adapter partiellement
Vous conservez la majeure partie de l’application.
Mais vous remplacez certaines briques.
Par exemple :
avant :
base MySQL gérée sur serveur interne.
Après :
base MySQL managée dans le cloud.
Vous réduisez une partie du travail d’administration.
3. Refactor / Rearchitect
L’application est transformée plus profondément pour utiliser les capacités cloud.
Par exemple :
- microservices ;
- serverless ;
- services managés ;
- architecture événementielle.
Potentiel :
élevé.
Mais :
coût et risque également élevés.
4. Repurchase
Vous remplacez l’application existante par un logiciel SaaS.
Exemple :
ancien CRM installé localement.
Vous migrez vers un CRM cloud.
Vous ne migrez donc pas réellement l’application.
Vous la remplacez.
5. Retire
Pendant l’audit, vous découvrez que certaines applications ne servent plus à rien.
Meilleure stratégie :
les supprimer.
Migrer une application inutile est probablement la migration la moins rentable.
6. Retain
Certaines applications restent là où elles sont.
Pourquoi ?
- réglementation ;
- performance ;
- coût ;
- dépendances ;
- matériel spécialisé.
Une bonne stratégie cloud n’impose pas de tout migrer.
Le meilleur projet cloud commence donc par une question
Pas :
“Comment tout migrer ?”
Mais :
“Qu’est-ce qui mérite réellement d’être migré ?”
C’est très différent.
Pourquoi certaines entreprises ne migrent-elles pas tout ?
Parce que le cloud possède aussi des limites.
Risque n°1 : les coûts peuvent exploser
Le paiement à l’usage est formidable.
Jusqu’à ce que l’usage augmente énormément.
Prenons une application.
Elle fonctionne 24 heures sur 24.
Trafic parfaitement stable.
Infrastructure très prévisible.
Dans certains cas, posséder une infrastructure optimisée peut être moins coûteux sur plusieurs années.
Le cloud n’est donc pas automatiquement le choix économique optimal pour tous les workloads.
Le piège des petits coûts qui deviennent énormes
Une ressource coûte :
0,20 € par heure.
Cela semble insignifiant.
Mais :
0,20 × 24 × 365 = environ 1 752 € par an.
Maintenant multipliez par :
500 ressources.
Vous dépassez :
876 000 € par an.
Dans le cloud, les petites décisions techniques peuvent rapidement devenir de grandes décisions financières.
Risque n°2 : les coûts de sortie de données
Les entreprises regardent parfois uniquement :
- calcul ;
- stockage.
Mais oublient :
le réseau.
Transférer beaucoup de données hors d’un cloud peut entraîner des coûts.
Pour certains business très intensifs en données :
- vidéo ;
- streaming ;
- analytics ;
cela peut devenir significatif.
Risque n°3 : le vendor lock-in
Vous utilisez de plus en plus :
- base propriétaire ;
- fonctions serverless ;
- IA propriétaire ;
- services réseau spécifiques.
Votre application devient profondément liée au fournisseur.
Changer de cloud devient alors difficile.
C’est ce qu’on appelle :
vendor lock-in.
Mais attention à une autre idée reçue :
éviter absolument tout lock-in peut également coûter cher.
Si vous refusez toutes les fonctions avancées du fournisseur uniquement pour rester parfaitement portable, vous pouvez perdre une partie de la valeur du cloud.
La bonne question devient :
Quel niveau de dépendance sommes-nous prêts à accepter en échange de quel avantage ?
Risque n°4 : la sécurité ne disparaît pas
Certaines entreprises pensent :
“Nous sommes chez un grand cloud provider donc nous sommes sécurisés.”
C’est faux.
Les grands fournisseurs sécurisent leur infrastructure.
Mais l’entreprise reste responsable de nombreuses choses :
- utilisateurs ;
- mots de passe ;
- permissions ;
- configurations ;
- applications ;
- données.
C’est ce que l’on appelle souvent :
shared responsibility model.
Une mauvaise configuration peut être catastrophique
Exemple :
un bucket de stockage contenant des données sensibles.
L’entreprise le configure accidentellement en accès public.
Le fournisseur cloud fonctionne parfaitement.
Mais la sécurité de l’entreprise est compromise.
Le problème n’était pas le cloud.
C’était :
la configuration.
Risque n°5 : la souveraineté et la localisation des données
Toutes les données ne peuvent pas nécessairement être hébergées n’importe où.
Selon :
- secteur ;
- pays ;
- type de données ;
- contrats ;
l’entreprise peut avoir des obligations concernant :
- stockage ;
- traitement ;
- transferts.
En Europe, les réglementations concernant les données personnelles doivent évidemment être prises en compte.
Une stratégie cloud sérieuse doit donc inclure :
les équipes juridiques et conformité.
Pas uniquement l’IT.
Risque n°6 : migrer une mauvaise architecture ne la rend pas bonne
C’est probablement le piège le plus important.
Vous possédez une application lente.
Difficile à maintenir.
Mal conçue.
Vous la déplacez dans le cloud.
Résultat :
une application lente, difficile à maintenir et mal conçue… dans le cloud.
La migration n’efface pas la dette technique.
Parfois, elle la rend simplement plus visible.
Risque n°7 : la complexité augmente parfois
Le cloud peut simplifier certaines choses.
Mais il peut en complexifier d’autres.
Une architecture moderne peut inclure :
- Kubernetes ;
- serverless ;
- plusieurs bases ;
- queues ;
- API Gateway ;
- IAM ;
- observabilité ;
- infrastructure as code.
Le système devient extrêmement puissant.
Mais également plus difficile à comprendre.
Il faut donc toujours comparer :
valeur créée
contre :
complexité introduite.
Pourquoi certaines entreprises rapatrient-elles certains workloads ?
Il existe aussi un phénomène appelé :
cloud repatriation.
Une entreprise déplace certaines applications du cloud vers :
- datacenter privé ;
- infrastructure dédiée.
Pourquoi ?
Parfois :
- coûts ;
- performance ;
- réglementation ;
- contrôle.
Les données 2025 de Flexera indiquaient d’ailleurs que les organisations interrogées avaient rapatrié une partie de leurs workloads tout en continuant globalement à augmenter leur utilisation du cloud public.
Cela montre quelque chose d’important :
l’avenir n’est probablement pas “100 % cloud” pour tout le monde.
Il est davantage :
utiliser chaque type d’infrastructure là où il crée le plus de valeur.
Le cloud hybride devient donc logique
Imaginez une industrie.
Elle possède :
- systèmes industriels locaux ;
- données critiques ;
- ERP ;
- e-commerce ;
- analytics.
Elle pourrait conserver :
certaines fonctions localement.
Et placer :
- e-commerce ;
- analytics ;
- sauvegardes ;
- applications collaboratives ;
dans le cloud.
L’architecture devient hybride.
Ce n’est pas nécessairement une étape temporaire.
Pour certaines organisations, cela peut être un modèle durable.
Le cloud est-il plus écologique ?
Question complexe.
Les grands datacenters hyperscale peuvent être extrêmement optimisés en matière d’efficacité énergétique.
Mutualiser les ressources peut théoriquement éviter des milliers de petits serveurs très sous-utilisés.
Mais le cloud facilite également une explosion de la consommation informatique.
IA.
Streaming.
Stockage.
Calcul.
Le bilan dépend donc :
- de l’infrastructure ;
- du fournisseur ;
- de l’énergie ;
- du taux d’utilisation ;
- de l’architecture.
Dire simplement :
“Le cloud est écologique.”
serait donc beaucoup trop simpliste.
Comment savoir si votre entreprise doit migrer vers le cloud ?
Voici quelques signaux.
Signal 1 : votre infrastructure vous ralentit
Il faut plusieurs semaines pour :
- créer un environnement ;
- ajouter des ressources ;
- lancer une application.
Le cloud peut apporter beaucoup de flexibilité.
Signal 2 : votre trafic varie fortement
Vous avez :
- pics saisonniers ;
- campagnes ;
- événements.
L’élasticité devient intéressante.
Signal 3 : vous dépensez énormément de temps sur des infrastructures génériques
Vos équipes passent plus de temps à :
maintenir des serveurs
qu’à :
développer votre produit.
Des services managés peuvent avoir beaucoup de valeur.
Signal 4 : votre matériel arrive en fin de vie
Vous devez prochainement investir massivement dans :
- serveurs ;
- stockage ;
- datacenter.
C’est souvent un moment logique pour comparer les scénarios.
Signal 5 : vous ouvrez de nouveaux marchés
Vous avez besoin d’une infrastructure dans plusieurs zones géographiques.
Le cloud peut accélérer l’expansion.
Signal 6 : vous voulez accélérer l’innovation
IA.
Data.
Machine learning.
Expérimentation.
Le cloud donne accès rapidement à des services complexes.
Mais quand ne faut-il probablement pas migrer immédiatement ?
Si votre système :
- fonctionne très bien ;
- possède une charge stable ;
- coûte peu ;
- n’évolue presque pas ;
- ne limite pas l’activité ;
une migration peut créer davantage de risques que de bénéfices.
Le simple fait qu’une technologie soit moderne ne constitue pas une justification économique.
La grande erreur : calculer seulement le coût des serveurs
Supposons :
Infrastructure actuelle :
100 000 €/an.
Cloud estimé :
80 000 €/an.
Conclusion :
“Nous économisons 20 000 €.”
Pas si vite.
Il faut intégrer :
Migration
Combien coûtera le projet ?
Formation
Les équipes possèdent-elles les compétences ?
Réécriture
Certaines applications doivent-elles évoluer ?
Réseau
Quels nouveaux coûts ?
Sécurité
Quels outils supplémentaires ?
Support
Quel niveau de contrat ?
Exploitation
Combien coûtera la gestion ?
C’est ce qu’on appelle :
Total Cost of Ownership — TCO.
Le cloud doit également être évalué par la valeur
Imaginons :
Infrastructure traditionnelle :
500 000 € par an.
Cloud :
600 000 €.
À première vue :
mauvaise décision.
Mais grâce au cloud :
vous passez de :
4 lancements par an
à :
Et vous gagnez :
3 millions d’euros supplémentaires.
Le cloud coûte davantage.
Mais il crée beaucoup plus de valeur.
C’est pourquoi la réflexion cloud ne doit pas se réduire à :
“Quel serveur coûte le moins cher ?”
Le ROI du cloud peut venir de plusieurs endroits
Réduction des investissements
Moins de matériel à acheter.
Productivité
Moins de maintenance manuelle.
Time-to-market
Produits lancés plus rapidement.
Résilience
Moins d’interruptions.
Innovation
Accès plus rapide à de nouvelles technologies.
Scalabilité
Capacité à absorber la croissance.
Expansion
Déploiement plus rapide dans de nouveaux marchés.
La valeur est donc multidimensionnelle.
Comment réussir une migration cloud ?
Une migration réussie commence rarement par :
“Déplaçons tout.”
Elle commence par une stratégie.
Étape 1 : définir l’objectif business
Pourquoi migrer ?
Réduire les coûts ?
Accélérer les déploiements ?
Améliorer la disponibilité ?
Internationaliser ?
Moderniser ?
Si vous ne connaissez pas l’objectif :
vous ne pourrez pas mesurer la réussite.
Étape 2 : inventorier
Listez :
- applications ;
- bases ;
- serveurs ;
- données ;
- dépendances ;
- flux réseau.
De nombreuses entreprises découvrent pendant cette étape qu’elles ne savent même plus exactement ce qu’elles possèdent.
Étape 3 : classer les applications
Pour chaque application :
- migrer telle quelle ;
- adapter ;
- reconstruire ;
- remplacer ;
- supprimer ;
- conserver.
Toutes ne méritent pas le même traitement.
Étape 4 : calculer le business case
Comparez :
Coût actuel
Infrastructure + personnes + licences + locaux + maintenance.
Coût futur
Cloud + migration + équipe + outils + support + réseau.
Puis ajoutez :
la valeur opérationnelle attendue.
Étape 5 : commencer petit
Choisissez un workload :
- relativement simple ;
- peu critique ;
- mais suffisamment représentatif.
Migrez.
Observez.
Apprenez.
Puis élargissez.
C’est souvent beaucoup plus intelligent qu’un gigantesque “big bang”.
Étape 6 : sécuriser dès le départ
Ne migrez pas d’abord pour ajouter la sécurité ensuite.
Définissez :
- identités ;
- permissions ;
- chiffrement ;
- logs ;
- sauvegardes ;
- segmentation réseau.
La sécurité doit faire partie de l’architecture.
Étape 7 : mettre en place la gouvernance
Qui peut créer des ressources ?
Quelles régions sont autorisées ?
Quels types de machines ?
Comment nommer les ressources ?
Qui vérifie les coûts ?
Sans gouvernance, le cloud peut devenir rapidement chaotique.
Étape 8 : automatiser
Infrastructure as Code.
CI/CD.
Monitoring.
Policies.
Le cloud atteint une grande partie de son potentiel lorsqu’il est automatisé.
Étape 9 : mettre en place le FinOps
Chaque équipe doit comprendre :
ce qu’elle consomme.
Et :
ce que cela coûte.
Quelques pratiques :
- budgets ;
- alertes ;
- tags ;
- rapports ;
- right-sizing ;
- arrêt des environnements inutiles.
Étape 10 : mesurer après migration
Comparez réellement.
Disponibilité
Meilleure ?
Performance
Meilleure ?
Coût
Conforme ?
Temps de déploiement
Réduit ?
Productivité
Améliorée ?
Incidents
Moins nombreux ?
Sinon, vous ne saurez jamais si la migration a réellement créé de la valeur.
Les principaux KPI d’une migration cloud
Coût par utilisateur
Très utile pour les plateformes SaaS.
Coût cloud / chiffre d’affaires
Mesure l’évolution économique.
Utilisation des ressources
CPU.
RAM.
Stockage.
Temps de déploiement
Avant / après.
Fréquence de déploiement
Combien de mises en production ?
Disponibilité
Pourcentage de disponibilité.
MTTR
Temps moyen nécessaire pour restaurer un service après incident.
Coût des ressources inutilisées
Permet de suivre le gaspillage.
Temps nécessaire pour créer un environnement
Indicateur très concret d’agilité.
Les 10 erreurs classiques d’une migration cloud
Erreur n°1 : migrer sans objectif
Vous obtenez :
la même entreprise,
avec une nouvelle facture.
Erreur n°2 : tout faire en lift and shift
Rapide.
Mais parfois très coûteux à long terme.
Erreur n°3 : considérer le cloud comme un datacenter distant
Vous passez à côté d’une grande partie de sa valeur.
Erreur n°4 : sous-estimer les coûts réseau
Particulièrement pour les gros volumes de données.
Erreur n°5 : donner trop de droits
La gestion des identités est critique.
Erreur n°6 : oublier le FinOps
La facture grossit progressivement.
Personne ne sait pourquoi.
Erreur n°7 : adopter trop de services
Votre équipe maîtrise :
3 technologies.
Puis votre architecture en utilise :
Complexité énorme.
Erreur n°8 : migrer les applications inutiles
Supprimer est parfois la meilleure migration.
Erreur n°9 : ne pas former l’équipe
Un nouvel environnement demande :
de nouvelles compétences.
Erreur n°10 : croire que le fournisseur gère tout
Le cloud reste un modèle de responsabilités partagées.
Cloud et startups : pourquoi le modèle est particulièrement puissant
Imaginez une startup qui lance son MVP.
Elle ignore si elle aura :
10 utilisateurs
ou :
10 millions.
Acheter dès le premier jour une infrastructure pour 10 millions serait absurde.
Le cloud lui permet de :
commencer petit.
Tester.
Obtenir des clients.
Puis investir progressivement.
Cela change fondamentalement l’économie de création d’une entreprise technologique.
Et pour une PME ?
Le besoin est différent.
Une PME peut utiliser le cloud principalement pour :
- logiciels SaaS ;
- sauvegardes ;
- collaboration ;
- CRM ;
- ERP ;
- cybersécurité ;
- hébergement web.
Elle n’a pas besoin de devenir experte Kubernetes pour bénéficier du cloud.
C’est essentiel à comprendre.
Adopter le cloud ne signifie pas devenir une entreprise cloud-native du jour au lendemain.
Et pour une grande entreprise ?
Les enjeux deviennent :
- milliers d’applications ;
- réglementation ;
- coûts ;
- héritage technique ;
- sécurité ;
- gouvernance ;
- multicloud ;
- hybride.
La migration devient alors un programme stratégique de plusieurs années.
Ce n’est plus simplement un projet informatique.
Cloud-native : qu’est-ce que cela signifie ?
Une application :
hébergée dans le cloud
n’est pas nécessairement :
cloud-native.
Une application cloud-native est généralement conçue pour exploiter davantage :
- automatisation ;
- élasticité ;
- services distribués ;
- conteneurs ;
- infrastructure programmable.
Exemple :
Vous prenez un logiciel de 2005.
Vous le placez sur une machine virtuelle AWS.
Il est :
dans le cloud.
Mais pas nécessairement :
cloud-native.
Serverless : encore une étape d’abstraction
Avec le serverless, les développeurs se préoccupent encore moins directement des serveurs.
Ils déploient :
- fonctions ;
- applications ;
- logique métier.
Le fournisseur gère :
- capacité ;
- infrastructure ;
- certains mécanismes de scaling.
Contrairement à ce que le nom suggère :
il existe toujours des serveurs.
Simplement :
vous ne les administrez plus directement.
Cloud, Kubernetes et serverless : comment tout cela s’articule ?
Imaginez plusieurs niveaux.
Machine virtuelle
Vous gérez beaucoup.
Conteneurs
Plus standardisés.
Kubernetes
Vous orchestrez de nombreux workloads.
PaaS
Le fournisseur gère davantage d’infrastructure.
Serverless
L’infrastructure devient encore plus abstraite.
Il n’existe pas de niveau universellement meilleur.
Tout dépend du besoin.
Une entreprise doit-elle forcément devenir cloud-native ?
Non.
C’est exactement la même erreur que :
“Tout le monde doit utiliser Kubernetes.”
Une entreprise devrait devenir cloud-native uniquement si les bénéfices :
- rapidité ;
- scalabilité ;
- automatisation ;
- résilience ;
justifient réellement :
- transformation ;
- coût ;
- complexité.
Le futur sera-t-il 100 % cloud ?
Probablement pas de manière universelle.
Nous allons plutôt vers un monde combinant :
- cloud public ;
- cloud privé ;
- edge computing ;
- SaaS ;
- infrastructure locale ;
- infrastructures spécialisées.
Les entreprises chercheront surtout à placer chaque workload :
au bon endroit.
C’est d’ailleurs la logique du cloud hybride.
Ce qui change réellement avec le cloud
Le changement le plus profond n’est peut-être pas technologique.
Avant, l’infrastructure était principalement :
un actif physique.
Avec le cloud, elle devient davantage :
un service programmable.
Cela change :
- la vitesse ;
- les responsabilités ;
- les coûts ;
- les compétences.
Et surtout :
cela rapproche l’infrastructure du rythme du produit.
La question stratégique : le cloud est-il un coût ou un levier ?
Imaginez deux entreprises.
Entreprise A
Objectif cloud :
réduire la facture de 15 %.
Entreprise B
Objectif cloud :
réduire de six semaines à deux jours le lancement d’un nouveau marché.
La première pense principalement :
infrastructure.
La deuxième pense :
business.
Les économies peuvent être importantes.
Mais les plus grands bénéfices du cloud peuvent parfois venir de :
- vitesse ;
- innovation ;
- scalabilité ;
- résilience.
Pas simplement du prix d’un serveur.
Checklist : votre entreprise est-elle prête pour une migration cloud ?
Objectifs
- Nous savons pourquoi nous voulons migrer.
- Nous avons des objectifs mesurables.
- Nous avons identifié la valeur business attendue.
Technique
- Nos applications sont inventoriées.
- Les dépendances sont connues.
- Les besoins de performance sont mesurés.
- Les contraintes réseau sont identifiées.
Finance
- Nous connaissons notre coût actuel.
- Nous avons estimé le TCO cloud.
- Nous avons intégré le coût de migration.
- Nous avons intégré les coûts de réseau et de support.
- Une gouvernance FinOps est prévue.
Sécurité
- Les règles d’accès sont définies.
- Les données sensibles sont identifiées.
- Le chiffrement est prévu.
- Les sauvegardes sont définies.
- Les obligations réglementaires sont connues.
Organisation
- Les équipes sont formées.
- Les responsabilités sont claires.
- Nous savons qui exploitera la plateforme.
- Nous avons défini les procédures d’incident.
Migration
- Nous avons identifié un premier workload pilote.
- Nous avons un plan de rollback.
- Nous avons défini des KPI avant la migration.
Si une majorité de ces questions restent sans réponse, votre priorité n’est probablement pas encore :
migrer.
Elle est :
préparer la migration.
Plan simple de migration en 90 jours
Pour un périmètre limité, une approche pourrait ressembler à ceci.
Jours 1 à 30 — Comprendre
- inventorier ;
- analyser les coûts ;
- identifier les dépendances ;
- définir les objectifs ;
- choisir un workload pilote.
Jours 31 à 60 — Construire
- créer l’environnement cloud ;
- mettre en place la sécurité ;
- automatiser ;
- migrer les données ;
- tester.
Jours 61 à 90 — Valider
- migrer progressivement ;
- mesurer ;
- optimiser ;
- documenter ;
- décider de la prochaine application.
L’objectif n’est pas de déplacer toute l’entreprise en trois mois.
L’objectif est :
d’apprendre suffisamment pour industrialiser la suite.
Les questions que tout dirigeant devrait poser à son équipe avant une migration
Même si vous n’êtes pas technicien, vous pouvez poser :
Pourquoi migrons-nous ?
Quel problème business cela résout-il ?
Combien coûte l’infrastructure actuelle ?
Quel sera le coût total après migration ?
Quelle partie peut être supprimée plutôt que migrée ?
Quelles applications resteront sur site ?
Quel risque crée notre dépendance au fournisseur ?
Comment récupérerons-nous nos données si nous voulons partir ?
Qui contrôlera les dépenses ?
Comment mesurerons-nous le succès ?
Ces questions sont parfois plus importantes que :
“AWS ou Azure ?”
Conclusion : les entreprises ne migrent pas vers le cloud simplement parce que le cloud est moderne
Elles migrent parce que leur environnement économique demande de plus en plus :
de la vitesse.
de la flexibilité.
de la capacité à évoluer.
de la disponibilité.
de l’automatisation.
Le cloud permet de transformer l’infrastructure informatique d’un investissement relativement rigide vers un ensemble de ressources disponibles à la demande.
Mais ce modèle apporte également de nouveaux défis.
Les données 2026 de Flexera illustrent notamment l’importance prise par la maîtrise des coûts : 85 % des répondants de son enquête citent ce sujet comme leur principal défi cloud et l’estimation moyenne du gaspillage des dépenses IaaS/PaaS atteint 29 %.
Autrement dit :
le cloud facilite énormément la consommation d’informatique.
Il ne garantit absolument pas :
une consommation intelligente de l’informatique.
Une bonne stratégie cloud ne consiste donc pas à :
“Tout migrer le plus vite possible.”
Elle consiste à déterminer :
ce qui doit migrer.
pourquoi.
vers quel modèle.
avec quel niveau de service.
avec quel coût.
Et surtout :
pour quel résultat business.
Car une entreprise peut parfaitement réussir sa migration technique…
et rater complètement sa transformation économique.
Elle peut avoir :
des architectures magnifiques,
des dashboards impressionnants,
des centaines de services cloud,
et pourtant :
aucun gain de productivité,
aucune baisse de coûts,
aucune accélération commerciale.
La véritable réussite apparaît lorsque le cloud permet à l’entreprise de :
prendre de meilleures décisions, lancer plus vite, absorber la croissance et consacrer davantage de ressources à ce qui crée réellement de la valeur pour ses clients.
La meilleure infrastructure n’est pas celle qui est “dans le cloud”. C’est celle qui soutient efficacement le modèle économique de l’entreprise.
Votre entreprise envisage une migration vers le cloud ?
Avant de choisir une technologie ou un fournisseur, il faut d’abord comprendre ce que la migration doit réellement apporter à l’activité.
Chez Tommy Montégu Conseil, nous accompagnons les entrepreneurs, startups et dirigeants dans leurs choix de développement, de structuration et de rentabilité.
Dans un projet technologique, cela signifie notamment prendre du recul sur :
- le business case ;
- les coûts ;
- les priorités ;
- la scalabilité ;
- les processus ;
- l’organisation ;
- la rentabilité ;
- les investissements ;
- les risques liés à la croissance.
Car migrer une infrastructure simplement parce que “tout le monde va dans le cloud” n’est pas une stratégie.
La bonne question est :
“Est-ce que cette décision rend réellement notre entreprise plus rapide, plus robuste ou plus rentable ?”
Si la réponse est clairement oui, le cloud peut devenir un formidable accélérateur.
Dans le cas contraire, la meilleure décision peut parfois être…
de ne pas migrer tout de suite.