«Nous migrons vers le cloud» est devenu une phrase aussi fréquente dans les comités de direction que vague dans son contenu. Une PME de 40 employés qui déplace son serveur de fichiers vers OneDrive n'a pas accompli la même chose qu'une entreprise industrielle qui transfère son ERP vers Azure avec haute disponibilité et reprise après sinistre. Appeler les deux «migration cloud» génère de la confusion, des attentes mal calibrées et, dans le pire des cas, des projets échoués avec des factures inattendues. Cet article démonte le processus dans ses parties réelles : ce qui se déplace, dans quel ordre, ce qui peut mal tourner et quelles économies sont légitimes à attendre.
Que signifie réellement «migrer vers le cloud» ?
Le terme englobe au moins quatre mouvements distincts qu'il convient de séparer dès le départ :
- Lift-and-shift (rehosting) : les machines virtuelles sont prises telles quelles et transférées chez un fournisseur cloud (AWS EC2, Azure VMs, Google Compute Engine). C'est l'option la plus rapide mais celle qui tire le moins parti des avantages du cloud.
- Replatforming : l'application est ajustée pour utiliser les services gérés du fournisseur (base de données administrée, équilibreurs de charge, mise à l'échelle automatique) sans réécrire le code.
- Refactoring / re-architecting : l'application est repensée sous forme de services natifs cloud (microservices, serverless, conteneurs). Investissement plus important, gain plus élevé à long terme.
- Remplacement SaaS : une application interne est retirée et remplacée par un service cloud existant (par exemple, abandonner un serveur de messagerie Postfix et passer à Microsoft 365 ou Google Workspace).
Pour la majorité des PME en Espagne, 80 % des projets appelés «migration cloud» sont en réalité une combinaison de remplacement SaaS (messagerie, bureautique, visioconférence) et de replatforming de l'ERP ou des applications métier critiques. Le lift-and-shift pur est généralement une étape intermédiaire, pas une destination.
Les modèles cloud et les responsabilités qui restent à votre charge
L'une des erreurs les plus fréquentes est de supposer qu'«être dans le cloud» dispense des responsabilités opérationnelles. La réalité est que le modèle de responsabilité partagée varie selon la couche que vous contractez :
| Couche | IaaS (ex. Azure VM) | PaaS (ex. Azure App Service) | SaaS (ex. Microsoft 365) |
|---|---|---|---|
| Matériel physique | Fournisseur | Fournisseur | Fournisseur |
| Réseau et virtualisation | Fournisseur | Fournisseur | Fournisseur |
| Système d'exploitation | Client | Fournisseur | Fournisseur |
| Middleware et runtime | Client | Fournisseur | Fournisseur |
| Application | Client | Client | Fournisseur |
| Données et accès | Client | Client | Client |
| Sauvegardes | Client | Partagée | Client |
Le point le plus critique : les données sont toujours la responsabilité du client, quel que soit le modèle. Un fournisseur SaaS qui ferme ou subit un incident n'a aucune obligation de vous restituer vos données dans un format utilisable si vous n'avez pas explicitement contracté une option d'exportation. C'est la base pour laquelle la stratégie de sauvegarde doit être conçue avant — et non après — la migration.
Les 6 phases d'une migration cloud bien exécutée
Phase 1 : Inventaire et classification des charges de travail
Avant de déplacer quoi que ce soit, il faut savoir ce que l'on possède. Cela implique d'inventorier toutes les applications, serveurs et dépendances, et de classer chaque charge de travail selon trois variables : criticité pour l'activité, compatibilité technique avec le cloud et coût de migration estimé. Des outils comme Azure Migrate, AWS Migration Evaluator ou même un inventaire manuel dans un tableur structuré servent à cette fin. Le résultat est une matrice qui détermine ce qui se déplace en premier, ce qui est retiré et ce qui reste on-premise pour des raisons techniques, réglementaires ou de coût.
Phase 2 : Conception de l'architecture cible
Une fois les charges classées, l'architecture cloud est conçue : quelles régions utiliser (cela a des implications sur la latence et le respect du RGPD en matière de localisation des données), comment le réseau virtuel est structuré, quels services gérés remplacent quels composants actuels, et quelle est la stratégie d'identité (intégration avec Active Directory, SSO, MFA). Cette phase définit également le modèle de gouvernance cloud : politiques d'étiquetage, limites de dépenses, alertes de coût et qui peut provisionner des ressources.
Phase 3 : Preuve de concept et migration pilote
Aucune migration de production ne devrait être exécutée sans avoir préalablement migré un environnement non critique. Le pilote valide que les applications fonctionnent dans l'environnement cloud, que les temps de réponse sont acceptables, que les intégrations avec des tiers restent opérationnelles et que l'équipe interne connaît les procédures d'exploitation. Une semaine de pilote peut éviter des semaines d'incidents en production.
Phase 4 : Migration de production par vagues
Les charges de travail sont migrées par vagues, en commençant par les moins critiques. Pour chaque vague, une fenêtre de migration est définie (normalement en dehors des heures d'activité), un plan de retour arrière clair et un ensemble de vérifications post-migration (tests de fumée) qui confirment que l'application est opérationnelle avant de clore la fenêtre. Pour les applications avec une base de données active, la technique habituelle est la réplication continue : la base source reste synchronisée avec la destination jusqu'au moment du basculement, minimisant le temps d'arrêt réel.
Phase 5 : Optimisation et ajustement des coûts
La facture cloud surprend quand elle n'est pas gérée activement. Le premier mois post-migration est généralement le plus cher, car les tailles d'instance sont définies de façon conservatrice. L'optimisation implique d'ajuster le dimensionnement (rightsizing), d'activer la mise à l'échelle automatique le cas échéant, d'éliminer les ressources orphelines et de profiter des modèles d'achat réservé (Reserved Instances sur AWS, Azure Reserved VM Instances) qui peuvent réduire la facture de calcul de 30 % à 60 % par rapport aux prix à la demande, selon les engagements de 1 ou 3 ans.
Phase 6 : Exploitation continue et amélioration
La migration ne se termine pas le jour où le serveur on-premise est éteint. L'exploitation cloud nécessite une surveillance continue, la gestion des mises à jour de sécurité (notamment dans les modèles IaaS), des révisions périodiques des coûts et l'évolution de l'architecture au fil des changements de l'activité. Chez Summum Sistemas, nous accompagnons les entreprises aussi bien dans le projet de migration vers le cloud que dans l'exploitation continue qui suit.
Les risques réels que les projets cloud sous-estiment
Les coûts de sortie (egress) que personne ne mentionne dans l'offre
Les grands fournisseurs cloud facturent les données qui sortent de leur plateforme (egress), mais pas celles qui entrent. Pour les applications qui déplacent de grands volumes de données vers l'extérieur (exports vers des clients, intégrations avec des systèmes on-premise non migrés, sauvegardes téléchargées localement), ce coût peut être significatif et n'apparaît pas dans les estimations initiales. AWS, Azure et Google Cloud publient leurs tarifs de transfert de données, qui doivent être intégrés au TCO (coût total de possession) avant de prendre la décision.
La dépendance technique au fournisseur (vendor lock-in)
L'utilisation de services propriétaires d'un fournisseur (fonctions serverless, bases de données NoSQL propriétaires, services de messagerie spécifiques) accroît la dépendance. Si vous souhaitez ultérieurement changer de fournisseur ou récupérer l'exploitation on-premise, la portabilité sera coûteuse. La décision d'utiliser des services propriétaires plutôt que des services standard (conteneurs Docker, bases de données PostgreSQL, Kubernetes) doit être prise de façon consciente, en évaluant le bénéfice immédiat par rapport au coût de migration futur.
La conformité réglementaire des données
Le Règlement Général sur la Protection des Données (RGPD) exige que les transferts internationaux de données personnelles vers des pays hors de l'Espace Économique Européen bénéficient de garanties adéquates. Les grands fournisseurs cloud (AWS, Azure, Google Cloud) proposent des régions au sein de l'Union Européenne et des clauses contractuelles types, mais c'est au client de vérifier que les données sont stockées et traitées dans les bonnes régions et que le contrat avec le fournisseur respecte les exigences du sous-traitant selon l'article 28 du RGPD. L'Agence Espagnole de Protection des Données (AEPD) a publié des guides spécifiques sur l'informatique en nuage qu'il convient de consulter avant de migrer des données à caractère personnel.
La continuité pendant la migration elle-même
La période de transition est le moment de risque le plus élevé : les données peuvent exister en deux endroits à la fois, les sauvegardes peuvent ne pas couvrir l'état intermédiaire et les équipes opèrent sur une architecture qu'elles ne maîtrisent qu'à moitié. Un plan de contingence documenté, avec des responsables clairement désignés et des critères de retour arrière explicites, n'est pas un document pour les audits : c'est ce qui permet de dormir tranquille la nuit de la migration.
Combien une PME économise-t-elle vraiment en migrant vers le cloud ?
La réponse honnête est : cela dépend de la situation de départ. Une entreprise qui dispose de serveurs physiques de moins de cinq ans avec une utilisation élevée n'économisera probablement pas sur le seul calcul en migrant vers l'IaaS. Le cloud lui apportera d'autres avantages (élasticité, résilience, accès à distance), mais pas une réduction de la facture d'infrastructure.
En revanche, une entreprise avec des serveurs anciens dont la maintenance est coûteuse, une infrastructure surdimensionnée pour couvrir des pics qui surviennent deux fois par an, ou des coûts élevés de salle des serveurs (climatisation, onduleurs, surveillance), constate généralement une réduction réelle des coûts opérationnels après la migration.
Les économies les plus solides et les plus constantes proviennent de trois vecteurs :
- Remplacement des applications on-premise par du SaaS : le coût des licences, des mises à jour, du support et de l'administration des applications internes dépasse généralement clairement le coût de l'équivalent SaaS lorsque le temps interne consacré est comptabilisé.
- Élimination du matériel obsolète : ne pas renouveler des serveurs dont la durée de vie utile est arrivée à son terme et dont les coûts de maintenance augmentent.
- Réduction du temps de reprise après sinistre : ce n'est pas une économie directe sur le compte de résultat quotidien, mais le coût d'une interruption de 8 heures des systèmes critiques d'une entreprise de taille intermédiaire dépasse fréquemment le coût annuel d'un plan de continuité cloud bien conçu.
Si vous avez besoin d'une estimation réaliste pour votre situation concrète, le point de départ est une analyse de faisabilité de la migration cloud basée sur votre inventaire réel, et non sur des moyennes sectorielles.
Cloud public, privé et hybride : lequel convient à votre entreprise
Le cloud public (AWS, Azure, Google Cloud) est l'option majoritaire pour les PME, car il élimine la gestion de l'infrastructure physique et offre une mise à l'échelle à la demande. Le cloud privé (infrastructure dédiée, gérée on-premise ou en colocation) a du sens lorsqu'il existe des exigences réglementaires très strictes, des volumes de données qui rendent le cloud public inefficace ou des besoins de latence ultra-faible. Le modèle hybride combine les deux : il maintient on-premise ce qui ne peut ou ne doit pas être déplacé (pour des raisons de coût, de réglementation ou de latence) et transfère tout le reste vers le cloud public.
Pour la majorité des PME espagnoles comptant entre 20 et 200 employés, le modèle hybride avec Microsoft Azure comme cloud public et Microsoft 365 comme couche de productivité est l'architecture de référence qui offre le plus d'agilité opérationnelle et la moindre friction d'adoption, en particulier lorsque Active Directory est déjà présent dans l'environnement.
Questions fréquentes
Combien de temps dure une migration cloud complète ?
Cela dépend du périmètre. Une migration de messagerie et de bureautique vers Microsoft 365 pour une entreprise de 50 utilisateurs peut être réalisée en 2 à 4 semaines, formation incluse. Une migration d'ERP on-premise vers une plateforme cloud avec intégration des données historiques, formation et stabilisation post-démarrage se clôt rarement en moins de 3 mois et peut s'étendre à 6 dans des environnements complexes. La planification réaliste du projet est l'un des facteurs qui influence le plus la réussite : la précipitation est la cause numéro 1 des incidents graves en production lors des migrations.
Puis-je migrer vers le cloud si je possède des données sensibles ou réglementées ?
Oui, avec les précautions adéquates. Les secteurs soumis à des réglementations spécifiques (santé, finance, données de mineurs, défense) ont des exigences concrètes sur l'endroit et la façon dont les données sont stockées. Les grands fournisseurs cloud proposent des régions au sein de l'Union Européenne et des contrats de sous-traitance conformes au RGPD. Pour les secteurs soumis à une réglementation supplémentaire (comme le Schéma National de Sécurité — ENS — obligatoire pour les entités traitant des données des administrations publiques), il est nécessaire de vérifier que le fournisseur cloud et la configuration choisis disposent des certifications correspondantes.
Que se passe-t-il si le fournisseur cloud subit une panne ?
Les grands fournisseurs publient des SLA de disponibilité généralement supérieurs à 99,9 % pour leurs services, mais aucun ne garantit 100 %. Une architecture bien conçue distribue les charges critiques entre des zones de disponibilité (voire entre régions) afin que la défaillance d'un centre de données ne prive pas l'ensemble de l'entreprise de service. La conception pour la résilience est une décision d'architecture, pas une caractéristique automatique de la souscription cloud : elle doit être demandée et payée explicitement.
Est-il pertinent de migrer vers le cloud si ma connexion internet n'est pas fiable ?
Il s'agit d'un point de départ légitime que de nombreuses entreprises en zones rurales ou à connectivité limitée doivent évaluer. La dépendance à la connectivité est réelle dans un environnement 100 % cloud. Les solutions habituelles comprennent : une double ligne internet (fibre principale + 4G/5G en secours), des architectures avec cache local pour les applications les plus critiques, et une analyse honnête permettant de déterminer si le temps moyen de coupure de la connexion est comparable ou inférieur au temps moyen d'incidents du serveur on-premise à remplacer. Dans de nombreux cas, la connectivité en Espagne s'est suffisamment améliorée pour que cet argument ne soit plus déterminant, mais il convient de le vérifier avec des données réelles avant de s'engager.
Conclusion : la migration cloud est un projet d'entreprise, pas seulement un projet informatique
Les projets de migration cloud qui échouent présentent presque toujours le même schéma : ils sont conçus comme des projets techniques sans impliquer les personnes qui utilisent les applications, sans désigner de responsable métier clairement identifié et sans établir de critères objectifs de succès au-delà de «que ça fonctionne». Ceux qui réussissent commencent par définir quel problème d'entreprise est résolu et remontent la chaîne pour choisir l'architecture qui le résout le mieux au risque raisonnable le plus faible.
Chez Summum Marketing, nous accompagnons les PME et les entreprises de taille intermédiaire dans leurs projets de transformation technologique depuis 2007. Depuis Summum Sistemas, nous gérons les migrations cloud avec une méthode structurée qui minimise le risque opérationnel et maximise le retour réel. Si vous évaluez le passage au cloud, le premier diagnostic ne coûte rien : parlez-nous de votre situation et nous vous dirons honnêtement si cela a du sens, quand et comment.