Migrer vers le cloud n'est pas un geste unique : cela va du lift-and-shift au replatforming, en passant par le refactoring ou le remplacement par du SaaS, et la plupart des PME espagnoles finissent par combiner remplacement SaaS et replatforming de l'ERP. Une entreprise qui exploite des serveurs sur site récents et fortement utilisés ne réalise que rarement des économies sur le seul calcul brut.
« Nous passons au cloud » est devenue une phrase aussi fréquente dans les comités de direction que floue dans son contenu. Une PME de 40 personnes qui déplace son serveur de fichiers vers OneDrive n'a pas fait la même chose qu'une entreprise industrielle qui migre son ERP vers Azure avec haute disponibilité et plan de reprise après sinistre. Appeler les deux « migration vers le cloud » crée de la confusion, des attentes mal calibrées et, dans le pire des cas, des projets qui échouent avec des factures inattendues. Cet article découpe le processus en ses composantes réelles : ce qui bouge, dans quel ordre, ce qui peut mal tourner et quelles économies il est légitime d'espérer.
Que signifie vraiment « migrer vers le cloud » ?
Le terme recouvre au moins quatre démarches distinctes qu'il faut distinguer dès le départ :
- Lift-and-shift (rehosting) : les machines virtuelles sont reprises telles quelles et déplacées vers 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 managés du fournisseur (base de données managée, équilibreurs de charge, auto-scaling) sans réécrire le code.
- Refactoring / re-architecturation : l'application est repensée sous forme de services cloud-natifs (microservices, serverless, conteneurs). Investissement plus important, gain plus important à long terme.
- Remplacement par du SaaS : une application interne est mise hors service et remplacée par un service cloud existant (par exemple, abandonner un serveur de messagerie Postfix pour passer à Microsoft 365 ou Google Workspace).
Pour la plupart des PME en Espagne, 80 % des projets appelés « migration vers le cloud » sont en réalité une combinaison de remplacement par du 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.
Modèles de cloud et responsabilités qui restent à la charge de votre entreprise
Une des erreurs les plus répandues est de penser qu'« être dans le cloud » supprime les responsabilités opérationnelles. En réalité, le modèle de responsabilité partagée varie selon la couche que vous contractez :
| Couche | IaaS (ex. VM Azure) | 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 environnement d'exécution | Client | Fournisseur | Fournisseur |
| Application | Client | Client | Fournisseur |
| Données et accès | Client | Client | Client |
| Sauvegardes | Client | Partagé | Client |
Le point le plus critique : les données restent toujours sous 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 exploitable si vous n'avez pas explicitement contracté une option d'exportation. C'est pour cela que 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 a. Cela suppose d'inventorier toutes les applications, serveurs et dépendances, et de classer chaque charge de travail selon trois variables : criticité métier, 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 structuré dans un tableur, conviennent à cet usage. Le résultat est une matrice qui détermine ce qui migre en premier, ce qui est mis hors service et ce qui reste sur site pour des raisons techniques, réglementaires ou de coût.
Phase 2 : Conception de l'architecture cible
Une fois les charges de travail classées, l'architecture cloud est conçue : quelles régions utiliser (avec des implications sur la latence et sur la conformité RGPD concernant la localisation des données), comment est structuré le réseau virtuel, quels services managés remplacent quels composants actuels, et quelle est la stratégie d'identité (intégration Active Directory, SSO, MFA). Cette phase définit aussi le modèle de gouvernance cloud : politiques de tagging, limites de dépenses, alertes de coûts et qui peut provisionner des ressources.
Phase 3 : Preuve de concept et migration pilote
Aucune migration en production ne devrait démarrer sans avoir d'abord 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 pilotage peut éviter des semaines d'incidents en production.
Phase 4 : Migration en production par vagues
Les charges de travail sont migrées par vagues, en commençant par les moins critiques. Pour chaque vague est définie une fenêtre de migration (généralement en dehors des heures ouvrées), un plan de retour en arrière clair et une série de vérifications post-migration (smoke tests) 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 de la bascule, ce qui minimise l'indisponibilité réelle.
Phase 5 : Optimisation et ajustement des coûts
La facture cloud surprend quand elle n'est pas activement gérée. Le premier mois après la migration est généralement le plus coûteux, car la taille des instances est définie de façon prudente. L'optimisation consiste à ajuster le dimensionnement (rightsizing), à activer l'auto-scaling là où c'est pertinent, à supprimer les ressources orphelines et à tirer parti 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 à la tarification à la demande, selon des engagements sur 1 ou 3 ans.
Phase 6 : Exploitation et amélioration continues
La migration ne s'achève pas le jour où le serveur sur site est éteint. L'exploitation dans le cloud exige une surveillance continue, une gestion des mises à jour de sécurité (surtout dans les modèles IaaS), des revues de coûts périodiques et une évolution de l'architecture à mesure que l'entreprise change. Chez Summum Sistemas, nous accompagnons les entreprises aussi bien dans le projet de migration vers le cloud que dans l'exploitation continue par la suite.
Les risques réels que les projets cloud sous-estiment
Les coûts de sortie que personne ne mentionne dans la proposition
Les grands fournisseurs cloud facturent les données qui sortent de leur plateforme (egress), mais pas celles qui y entrent. Pour les applications qui déplacent de gros volumes de données vers l'extérieur (exports vers des clients, intégrations avec des systèmes sur site 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, et ceux-ci 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)
Utiliser des 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 ensuite changer de fournisseur ou revenir à une exploitation sur site, la portabilité aura un coût. La décision d'utiliser des services propriétaires plutôt que des services standards (conteneurs Docker, bases de données PostgreSQL, Kubernetes) doit être prise en conscience, en pesant le bénéfice immédiat face 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 répond aux exigences applicables à un sous-traitant au titre de l'article 28 du RGPD. L'Agence espagnole de protection des données (AEPD) a publié des guides spécifiques sur le cloud computing qu'il vaut la peine de consulter avant de migrer des données personnelles.
La continuité pendant la migration elle-même
La période de transition est le moment de plus grand risque : les données peuvent exister à 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 connaissent qu'en partie. Un plan de continuité documenté, avec des responsables clairs et des critères de retour en 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 réellement en migrant vers le cloud ?
La réponse honnête est : cela dépend d'où vous partez. Une entreprise qui dispose de serveurs physiques de moins de cinq ans, fortement utilisés, ne fera probablement pas d'économies sur le seul calcul en migrant vers l'IaaS. Le cloud apportera d'autres avantages (élasticité, résilience, accès à distance), mais pas une réduction de la facture d'infrastructure.
En revanche, une entreprise dont les serveurs vieillissants coûtent cher à entretenir, dont l'infrastructure est surdimensionnée pour couvrir des pics qui ne se produisent que deux fois par an, ou qui supporte des coûts élevés de salle serveur (climatisation, onduleurs, sécurité), constate généralement une réelle réduction de ses coûts opérationnels après la migration.
Les économies les plus solides et les plus constantes proviennent de trois leviers :
- Remplacer des applications sur site 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 nettement celui de l'équivalent SaaS, une fois comptabilisé le temps interne consacré.
- Éliminer le matériel obsolète : ne pas renouveler des serveurs en fin de vie utile dont le coût de maintenance augmente.
- Réduire le 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 panne de 8 heures sur les systèmes critiques d'une entreprise de taille moyenne 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 spécifique, le point de départ est une analyse de faisabilité de migration vers le cloud fondé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 supprime la gestion de l'infrastructure physique et offre une échelle à la demande. Le cloud privé (infrastructure dédiée, gérée sur site ou en colocation) a du sens en présence d'exigences réglementaires très strictes, de volumes de données qui rendent le cloud public inefficace, ou de besoins de latence ultra-faible. Le modèle hybride combine les deux : il garde sur site ce qui ne peut pas ou ne doit pas bouger (pour des raisons de coût, de réglementation ou de latence) et déplace tout le reste vers le cloud public.
Pour la plupart des PME espagnoles de 20 à 200 salariés, le modèle hybride avec Microsoft Azure comme cloud public et Microsoft 365 comme couche de productivité (nos solutions Microsoft pour PME) est l'architecture de référence offrant le plus d'agilité opérationnelle et le moins de friction à l'adoption, surtout lorsque Active Directory est déjà présent dans l'environnement.
Questions fréquentes
Combien de temps dure une migration complète vers le cloud ?
Cela dépend du périmètre. Une migration de la messagerie et de la bureautique vers Microsoft 365 pour une entreprise de 50 utilisateurs peut se boucler en 2 à 4 semaines, formation comprise. Une migration d'ERP sur site vers une plateforme cloud, avec intégration des données historiques, formation et stabilisation post-mise en production, se conclut rarement en moins de 3 mois et peut s'étendre à 6 dans des environnements complexes. Une planification réaliste du projet est l'un des facteurs qui influence le plus la réussite : se précipiter est la première cause d'incidents graves en production pendant les migrations.
Puis-je migrer vers le cloud si mes données sont sensibles ou réglementées ?
Oui, avec les précautions appropriées. Les secteurs soumis à une réglementation spécifique (santé, finance, données d'enfants, défense) ont des exigences concrètes sur où et comment les données sont stockées. Les grands fournisseurs cloud proposent des régions au sein de l'Union européenne et des accords de traitement des données 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 qui traitent des données de l'administration publique), il est nécessaire de vérifier que le fournisseur cloud et la configuration choisis détiennent les 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 répartit les charges critiques entre plusieurs zones de disponibilité (voire plusieurs régions), afin que la panne d'un centre de données ne prive pas toute l'entreprise de service. Concevoir pour la résilience est une décision d'architecture, pas une caractéristique automatique de la contractualisation du cloud : cela doit être demandé et payé explicitement.
Est-il pertinent de migrer vers le cloud si ma connexion internet n'est pas fiable ?
C'est un point de départ légitime que de nombreuses entreprises en zone rurale ou à connectivité limitée doivent évaluer. La dépendance à la connectivité est réelle dans un environnement 100 % cloud. Les solutions habituelles incluent : des lignes internet doubles (fibre principale + 4G/5G en secours), des architectures avec cache local pour les applications les plus critiques, et une analyse honnête de savoir si le temps d'indisponibilité moyen de la connexion est comparable ou inférieur au temps d'incident moyen du serveur sur site que vous souhaitez remplacer. Dans de nombreux cas, la connectivité en Espagne s'est suffisamment améliorée pour que cet argument ne soit plus décisif, mais il faut le vérifier avec des données réelles avant de s'engager.
Conclusion : la migration vers le cloud est un projet d'entreprise, pas seulement informatique
Les projets de migration vers le cloud qui échouent partagent 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 clair et sans établir de critères de réussite objectifs au-delà de « ça marche ». Ceux qui réussissent commencent par définir quel problème métier est résolu, puis remontent pour choisir l'architecture qui le résout le mieux avec le 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 2017. Depuis Summum Sistemas, nous gérons les migrations vers le cloud avec une méthode structurée qui minimise le risque opérationnel et maximise le retour réel. Si vous envisagez de franchir le pas, la première évaluation ne coûte rien : racontez-nous votre situation et nous vous donnerons une réponse honnête sur si cela a du sens, quand et comment.