La majorité des PME françaises exploitent encore des briques applicatives héritées (ERP propriétaires, environnements AS/400, bases de données monolithiques) dont la maintenance absorbe une part croissante du budget IT. Migrer ces composants vers le cloud sans provoquer d’interruption de service suppose une méthode rigoureuse, calibrée sur les contraintes réelles du système d’information en place.
Le cadre réglementaire européen renforce cette exigence : le Data Act, applicable depuis le 12 septembre 2025, encadre désormais les conditions de changement de fournisseur cloud et prévoit la suppression des frais de transfert à compter du 12 janvier 2027.
Cartographie applicative et dépendances cachées d’un SI legacy
La plupart des échecs de migration trouvent leur origine dans une connaissance incomplète de l’existant. Sur un SI vieillissant, les flux entre applications se sont sédimentés au fil des années : un ERP communique avec un module de paie par un fichier plat déposé sur un partage réseau, un programme COBOL sur AS/400 alimente un portail web via une couche intermédiaire dont la documentation a disparu.
L’audit de l’existant ne se limite pas à un inventaire de serveurs. Il doit cartographier chaque dépendance applicative, y compris les flux informels, les scripts planifiés et les intégrations manuelles. Un connecteur oublié entre un outil de gestion commerciale et un automate de facturation peut provoquer un arrêt de production invisible pendant des heures avant d’être détecté.
Cette cartographie produit un livrable structurant : la matrice de dépendances, qui classe chaque application selon sa criticité métier et ses liens techniques. C’est elle qui détermine l’ordre de migration et identifie les composants qui doivent impérativement basculer ensemble. Les entreprises qui sollicitent un accompagnement à la migration cloud gagnent du temps sur cette phase, car l’analyse des interdépendances sur un parc legacy exige une expertise spécifique.
Migration cloud par vagues : préserver la continuité de service
Déplacer l’ensemble d’un SI en une seule opération est un pari que peu de PME peuvent se permettre. La migration par vagues segmente le projet en lots cohérents, chaque lot regroupant des applications dont les dépendances mutuelles sont identifiées et maîtrisées.
Définir les lots et leur séquence
Le premier lot contient généralement les applications les moins critiques : outils collaboratifs, messagerie, environnements de test. Ce lot sert de répétition grandeur nature pour valider les procédures de bascule, les performances réseau et les mécanismes de retour arrière.
Les lots suivants montent en criticité. Un ERP legacy migre en dernier ou en avant-dernier, une fois que l’infrastructure cible a été éprouvée par les vagues précédentes. Pour chaque lot, trois éléments conditionnent le succès :
- Des tests à blanc réalisés sur un environnement miroir, reproduisant les conditions de production (volumes de données, pics de charge, connexions utilisateurs simultanées)
- Un scénario de retour arrière documenté et testé, permettant de restaurer le service sur l’infrastructure d’origine en cas de défaillance pendant la bascule
- Une fenêtre de bascule définie avec les métiers, idéalement en période de faible activité, pour réduire l’exposition au risque
Réplication et bascule courte
La réplication continue des données entre l’environnement source et l’environnement cible permet de réduire la fenêtre de bascule à quelques minutes. Le principe : les deux environnements fonctionnent en parallèle jusqu’à ce que la synchronisation soit complète, puis le trafic est redirigé vers le cloud. La durée d’indisponibilité réelle se mesure en minutes, pas en heures, à condition que la réplication ait été correctement dimensionnée en amont.
Applications legacy sur AS/400 : les options de modernisation
Les programmes RPG ou COBOL exécutés sur AS/400 posent un problème spécifique. Ils ne se déplacent pas vers une machine virtuelle cloud par simple copie. Trois stratégies existent, et le choix dépend du niveau de dette technique accumulée.
Le rehosting (lift and shift) consiste à émuler l’environnement AS/400 dans le cloud. Cette approche conserve le code existant mais ne règle pas les limitations fonctionnelles. Elle convient quand l’application est stable et que sa refonte n’est pas prioritaire.
Le replatforming adapte l’application pour qu’elle tourne sur une base de données cloud (PostgreSQL, SQL Server managé) tout en conservant la logique métier. C’est un compromis qui réduit la dépendance au matériel propriétaire sans réécriture complète.
La refonte complète (refactoring) réécrit l’application en architecture cloud-native. Le coût et la durée sont significativement plus élevés. Cette option se justifie quand l’application legacy freine l’activité ou quand les compétences COBOL/RPG ne sont plus disponibles en interne.
Erreurs de migration cloud et réversibilité réglementaire
Deux erreurs reviennent avec une fréquence notable dans les retours d’expérience de migration.
La première est de sous-estimer la conduite du changement. Un SI modernisé modifie les habitudes de travail : interfaces différentes, temps de réponse modifiés, nouveaux processus d’authentification. Sans accompagnement des équipes métiers, l’adoption reste partielle et les contournements se multiplient, créant une dette technique parallèle.
La seconde est d’ignorer la réversibilité. Le règlement DORA impose aux entités concernées une stratégie de sortie documentée et testée pour tout prestataire cloud soutenant une fonction critique. Cette exigence ne concerne pas uniquement le secteur financier dans son principe : toute PME a intérêt à vérifier, avant de signer, que ses données et ses applications peuvent être rapatriées ou transférées vers un autre fournisseur sans blocage technique.
- Tester la portabilité des données avant la migration, pas après, en vérifiant que les formats utilisés ne créent pas de verrouillage
- Identifier les services managés propriétaires (fonctions serverless, bases de données spécifiques) qui rendraient un changement de fournisseur coûteux
- Négocier contractuellement les conditions de réversibilité en s’appuyant sur les dispositions du Data Act, notamment la suppression progressive des frais de changement
Le risque de concentration sur un seul fournisseur cloud fait désormais l’objet d’une attention réglementaire croissante. Anticiper la substituabilité dès la phase d’architecture évite de découvrir, en situation de crise, qu’une application ne peut pas fonctionner ailleurs que chez son hébergeur d’origine.
Une migration cloud réussie pour une PME ne se mesure pas au nombre de serveurs décommissionnés. Elle se mesure à la capacité du nouveau SI à fonctionner sans rupture le jour de la bascule, et à rester portable dans les années qui suivent.
