Migration cloud : cartographier avant de migrer pour éviter les échecs

La migration vers le cloud est devenue un passage quasi obligé pour les PME et ETI qui veulent gagner en agilité, réduire leurs coûts d'infrastructure et moderniser leur SI. Pourtant, les statistiques sont sans appel : selon Gartner, plus de 60 % des projets de migration cloud dépassent leur budget initial, et une part significative échoue à atteindre les bénéfices attendus.

Le problème n'est presque jamais technologique. Il est méthodologique. Les entreprises qui échouent partagent un point commun : elles ont migré sans cartographier. Elles ont sauté l'étape fondamentale qui consiste à comprendre ce qu'elles ont avant de décider où le déplacer.

Les 5 erreurs classiques de la migration cloud

Erreur n°1 : Le "lift and shift" aveugle

La tentation est grande de simplement déplacer ses serveurs vers le cloud à l'identique. C'est rapide, ça rassure, et les prestataires cloud adorent vendre cette approche. Le problème ? Vous transférez vos inefficiences dans un environnement où elles coûtent plus cher.

Un serveur surdimensionné dans votre datacenter coûte un prix fixe. Le même serveur surdimensionné sur AWS ou Azure vous facture à la consommation réelle des ressources allouées. Sans analyse préalable, vous risquez de payer plus cher pour le même service.

Erreur n°2 : Ignorer les dépendances applicatives

Migrer une application sans connaître ses dépendances, c'est tirer sur un fil sans savoir ce qui est attaché au bout. Un ERP connecté à 15 autres briques applicatives ne se déplace pas comme une application isolée.

Les conséquences sont classiques : interruptions de service, flux de données cassés, utilisateurs bloqués. Et chaque incident non anticipé allonge le calendrier et gonfle le budget.

Erreur n°3 : Sous-estimer la latence et la localisation des données

Certaines applications fonctionnent très bien en cloud. D'autres ont des exigences de latence incompatibles avec un hébergement distant. Les applications temps réel, les outils de production industrielle connectés à des équipements locaux, ou les bases de données avec des requêtes très fréquentes entre elles peuvent souffrir d'une migration non réfléchie.

Sans cartographie des flux de données et de leurs contraintes de performance, vous découvrez ces problèmes en production, au pire moment.

Erreur n°4 : Oublier la conformité réglementaire

Le RGPD et les directives comme NIS2 imposent des contraintes strictes sur la localisation et le traitement des données personnelles. Migrer des données vers un cloud hébergé hors UE sans analyse préalable peut créer des non-conformités graves, avec des sanctions pouvant atteindre 4 % du chiffre d'affaires mondial.

Chaque application manipulant des données personnelles doit être identifiée et classifiée avant toute décision de migration.

Erreur n°5 : Ne pas impliquer les métiers

La migration cloud est souvent perçue comme un projet purement technique. C'est une erreur. Chaque application sert un processus métier. Les utilisateurs connaissent les contraintes de disponibilité, les pics d'usage, les fonctionnalités critiques.

Migrer sans leur input, c'est prendre des décisions techniques déconnectées des réalités opérationnelles.

Pourquoi la cartographie est le prérequis non négociable

La [cartographie du SI](/fr/blog/cartographie-systeme-information-definition-guide) avant migration n'est pas un exercice administratif. C'est un outil de décision qui transforme un projet risqué en une démarche maîtrisée.

Ce que la cartographie révèle

L'inventaire complet de votre patrimoine applicatif :

Combien d'applications avez-vous réellement (y compris le Shadow IT) ?
Lesquelles sont critiques pour le business ?
Lesquelles sont obsolètes et pourraient être décommissionnées plutôt que migrées ?

Les dépendances et les flux :

Quelles applications communiquent entre elles ?
Par quels protocoles et avec quelle fréquence ?
Quels sont les flux temps réel vs batch ?

Les contraintes par application :

Exigences de latence et de performance.
Contraintes réglementaires sur les données.
Fenêtres de maintenance et contraintes de disponibilité.
Licences et compatibilité avec les environnements cloud.

Les coûts actuels détaillés :

Coût par application (infrastructure + licences + support).
Base de comparaison pour évaluer le ROI du cloud.

La matrice de décision migration

À partir de la cartographie, vous pouvez classer chaque application dans l'une des catégories suivantes :

Migrer en l'état (Rehost) : l'application fonctionne bien, pas de dépendances bloquantes, gain de coût attendu en cloud.
Adapter (Replatform) : quelques ajustements nécessaires pour tirer parti du cloud (ex : passage à une base de données managée).
Reconstruire (Refactor) : l'application mérite une réécriture pour exploiter pleinement le cloud natif.
Conserver sur site (Retain) : contraintes de latence, réglementaires ou de coût qui justifient un maintien on-premise.
Décommissionner (Retire) : l'application est obsolète, c'est l'occasion de la supprimer.
Remplacer (Replace) : une solution SaaS cloud native existe et couvre le besoin.

Cette classification, connue sous le nom des "6 R" de la migration cloud, ne peut être réalisée sérieusement qu'avec une cartographie complète.

Checklist de pré-migration cloud

Avant de lancer votre projet de migration cloud, validez chaque point de cette checklist :

Phase de cadrage :

[ ] Objectifs business de la migration clairement définis (réduction de coûts, agilité, scalabilité, conformité).
[ ] Sponsor exécutif identifié.
[ ] Budget de migration et budget cloud récurrent estimés.
[ ] Équipe projet constituée (IT + métiers + sécurité).

Phase de cartographie :

[ ] Inventaire exhaustif des applications réalisé.
[ ] Dépendances inter-applicatives documentées.
[ ] Flux de données identifiés et caractérisés (volume, fréquence, criticité).
[ ] Contraintes réglementaires par application documentées.
[ ] Coûts actuels par application calculés.
[ ] Scoring de chaque application (criticité métier, santé technique, cloud readiness).

Phase de décision :

[ ] Classification "6 R" réalisée pour chaque application.
[ ] Stratégie cloud définie (tout cloud, cloud hybride, multi-cloud).
[ ] Fournisseur(s) cloud sélectionné(s) et zones de disponibilité choisies.
[ ] Architecture cible dessinée, en coherence avec le schema directeur SI.
[ ] Plan de migration séquencé par vagues (commencer par les applications les moins critiques).

Phase d'exécution :

[ ] Environnements cloud provisionnés et sécurisés.
[ ] Tests de performance et de latence réalisés.
[ ] Plan de rollback défini pour chaque vague.
[ ] Communication aux utilisateurs planifiée.
[ ] Monitoring post-migration en place.

Le cloud hybride : une réalité pour la majorité des PME/ETI

La stratégie cloud ETI n'est pas binaire. Rares sont les entreprises qui peuvent ou doivent tout migrer vers le cloud public. Le cloud hybride, qui combine infrastructure on-premise et services cloud, est souvent la réponse la plus pragmatique.

Les raisons de conserver une part d'on-premise sont légitimes :

Applications legacy impossibles à migrer sans refonte majeure, souvent sources de dette technique.
Contraintes de latence pour certains processus industriels.
Données sensibles soumises à des réglementations strictes.
Coûts : pour certaines charges de travail stables et prévisibles, l'on-premise reste plus économique.

La cartographie permet de tracer la ligne de démarcation entre ce qui va dans le cloud et ce qui reste sur site, non pas sur des intuitions, mais sur des critères objectifs et documentés.

Cas d'usage : comment UrbaHive sécurise votre migration cloud

UrbaHive est l'outil de cartographie collaborative qui transforme la phase de pré-audit migration en un processus structuré et visuel.

Cas 1 — Inventaire et scoring pré-migration

Une ETI industrielle de 800 collaborateurs souhaite migrer vers Azure. Avec UrbaHive, l'équipe IT cartographie ses 120 applications en une semaine. Chaque application est scorée sur sa criticité métier, sa santé technique et sa compatibilité cloud. Résultat : 35 applications identifiées pour un rehost immédiat, 20 pour un replatform, 15 à décommissionner. Les 50 restantes sont maintenues on-premise dans un premier temps. Le projet de migration est cadré avec un budget réaliste dès le départ.

Cas 2 — Identification des dépendances critiques

Une PME de services financiers de 200 personnes prévoit de migrer son CRM vers Salesforce en mode SaaS. La cartographie UrbaHive révèle que le CRM actuel est connecté à 8 autres applications via des flux personnalisés. Deux de ces flux alimentent le système de conformité réglementaire en temps réel. Sans cette visibilité, la migration aurait coupé ces flux critiques. Avec UrbaHive, l'équipe planifie les adaptations nécessaires avant la migration.

Cas 3 — Pilotage d'une migration par vagues

Une ETI du retail utilise UrbaHive pour planifier sa migration cloud en 4 vagues sur 18 mois. La cartographie vivante permet de suivre l'avancement en temps réel : quelles applications ont été migrées, lesquelles sont en cours, lesquelles restent à planifier. À chaque vague, l'équipe met à jour la cartographie pour refléter le nouvel état du SI.

Conclusion : cartographier d'abord, migrer ensuite

La migration cloud est un levier puissant de transformation pour les PME et ETI. Mais c'est aussi un projet complexe qui touche à l'ensemble du système d'information. Les entreprises qui réussissent leur migration sont celles qui investissent le temps nécessaire pour comprendre leur SI avant de le déplacer.

La cartographie n'est pas un surcoût. C'est une assurance contre les dépassements de budget, les interruptions de service et les échecs de migration. Elle transforme un projet technique anxiogène en une démarche stratégique maîtrisée.

Vous préparez une migration cloud ? Commencez par cartographier votre SI avec UrbaHive et prenez vos décisions sur des bases solides. Demandez une démo sur urbahive.com.