Une migration informatique consiste à déplacer des données, des applications ou une partie de l'infrastructure vers un nouvel environnement. Il peut s'agir de remplacer un serveur, de changer de logiciel métier, de transférer une base de données ou de passer vers le cloud. Pour une PME, le risque principal ne vient pas du transfert lui-même, mais d'une dépendance oubliée, d'une sauvegarde inutilisable, d'un délai de bascule trop optimiste ou d'utilisateurs qui découvrent le nouvel outil le jour du changement.
Le bon objectif n'est donc pas de migrer vite. Il est de retrouver, après la bascule, les données attendues, les droits d'accès, les interfaces avec les autres logiciels et un niveau de service compatible avec l'activité. Plus le système est critique, plus la préparation doit être détaillée.
Qu'est-ce qu'une migration informatique et quand la faire ?
Le terme recouvre plusieurs opérations. Une migration de données déplace des informations d'un stockage, d'une base ou d'un logiciel vers un autre. Une migration applicative déplace ou remplace une application et peut imposer de modifier son hébergement, ses connexions, ses comptes utilisateurs ou certaines interfaces. Une migration d'infrastructure concerne par exemple des serveurs, des machines virtuelles ou des services hébergés.
La décision doit partir d'un besoin précis. Elle peut devenir pertinente lorsqu'un système n'est plus maintenu, que les performances ne suffisent plus, que le coût d'exploitation devient difficile à justifier, qu'une fusion impose de regrouper plusieurs environnements ou qu'un nouveau logiciel métier doit remplacer l'ancien. Migrer uniquement parce qu'une technologie est plus récente n'est pas un motif suffisant.
Faut-il forcément migrer vers le cloud ?
Non. Le cloud est une destination possible, pas une finalité. Il peut apporter de la souplesse, faciliter certains déploiements et réduire la gestion de matériel sur site, mais il introduit aussi des questions de coûts récurrents, de dépendance au fournisseur, de sécurité, de localisation des données et de réversibilité. Pour un système sensible, l'ANSSI recommande d'éclairer la décision par une étude d'impact et une analyse de risques avant la migration.
Avant de lancer le projet, formulez le bénéfice attendu en une phrase et définissez un indicateur permettant de vérifier qu'il est atteint. Si vous ne pouvez pas expliquer ce que la migration doit améliorer, le projet n'est probablement pas assez cadré.
Quelles sont les étapes d'une migration informatique ?
Une migration sérieuse se pilote comme un projet. L'inventaire, les tests et la préparation de la bascule prennent souvent plus de temps que le transfert technique, mais c'est précisément ce travail qui réduit le risque d'arrêt ou de perte de données.
- Définir le périmètre et l'objectif. Identifiez ce qui doit être migré, ce qui restera en place et le résultat attendu pour l'entreprise.
- Inventorier l'existant. Recensez les données, applications, comptes, interfaces, dépendances, tâches automatisées, droits d'accès et équipements concernés. Une application secondaire peut dépendre d'une base ou d'un partage réseau que personne n'avait intégré au projet.
- Évaluer et nettoyer les données. Repérez les doublons, formats incohérents, données obsolètes et champs incompatibles. Le nouveau système ne corrigera pas automatiquement les défauts de l'ancien.
- Planifier la bascule. Fixez les responsables, les contrôles, la fenêtre d'interruption acceptable, le support utilisateur et les critères permettant de décider si la migration peut continuer ou doit être annulée.
- Sauvegarder et tester la restauration. La CNIL recommande que les copies de sauvegarde soient testées régulièrement. Une sauvegarde présente sur un disque ou dans le cloud n'est pas une garantie tant qu'une restauration exploitable n'a pas été vérifiée.
- Réaliser une migration pilote. Testez un échantillon représentatif ou un environnement de préproduction pour contrôler les volumes, les temps de transfert, les formats, les permissions et les interfaces.
- Basculer, valider puis surveiller. Après le transfert, contrôlez les données, les comptes, les applications, les échanges avec les systèmes tiers et les performances avant de retirer l'ancien environnement.
Comment préparer un plan de retour arrière ?
Le plan de retour arrière doit préciser à quel moment la migration est considérée comme trop risquée pour continuer, comment remettre l'ancien système en service et quelles données créées pendant la bascule doivent être récupérées. Il doit aussi indiquer qui prend la décision. Un retour arrière improvisé au milieu d'un incident peut être plus dangereux que la migration elle-même.
Big Bang ou migration progressive : que choisir ?
Les deux stratégies sont valables, mais elles ne répondent pas aux mêmes contraintes. Le choix dépend surtout de la durée d'interruption acceptable, du nombre de dépendances, de la possibilité de faire cohabiter deux systèmes et de la facilité à revenir en arrière.
| Critère | Big Bang | Migration progressive |
|---|---|---|
| Principe | Bascule de l'ensemble du périmètre pendant une fenêtre définie | Migration par lots, services, sites ou groupes d'utilisateurs |
| Interruption | Concentrée sur une période courte | Plus faible par étape, mais le projet dure plus longtemps |
| Retour arrière | Doit être préparé avec précision avant la bascule | Peut être limité au lot concerné si les systèmes sont suffisamment indépendants |
| Complexité | Coordination intense sur une seule opération | Cohabitation temporaire de deux environnements à gérer |
| Cas favorable | Périmètre maîtrisé, dépendances limitées, fenêtre d'arrêt acceptable | Système critique, nombreux utilisateurs, migration pouvant être découpée sans incohérence |
Le Big Bang n'est pas automatiquement plus simple ni moins cher. Il évite une longue période de coexistence, mais concentre le risque sur une seule fenêtre. La migration progressive réduit l'impact d'un échec local, mais peut générer des coûts de double exploitation, des synchronisations supplémentaires et une gestion plus complexe des droits ou des données.
Quels outils pour faciliter une migration de données ?
Les outils de migration automatisent une partie du transfert, de la réplication ou de la transformation des données. Ils ne remplacent ni l'inventaire, ni les règles de nettoyage, ni les contrôles après bascule. Leur compatibilité doit être vérifiée pour la source, la cible, les versions utilisées et le volume à traiter.
| Besoin | Exemples d'outils actuels | Point à vérifier |
|---|---|---|
| Migrer ou répliquer des bases de données vers AWS | AWS Database Migration Service | Moteurs et versions source/cible pris en charge |
| Migrer des bases de données vers Azure | Azure Database Migration Service | Scénario de migration, compatibilité et temps d'arrêt attendu |
| Copier et transformer des données dans l'écosystème Microsoft | Azure Data Factory ou Data Factory dans Microsoft Fabric selon le projet | Connecteurs, mappage des schémas et conversions de types |
| Transférer des volumes de fichiers ou d'objets vers Google Cloud | Storage Transfer Service | Source, destination, bande passante, volumétrie et coûts associés |
Ne choisissez pas l'outil avant d'avoir défini le scénario. Une PME qui déplace quelques centaines de gigaoctets de fichiers n'a pas les mêmes besoins qu'une entreprise qui doit répliquer une base transactionnelle en continu. L'outil doit répondre au plan de migration, et non dicter le plan.
Quels risques et coûts cachés anticiper lors d'une migration ?
La perte de données est le risque le plus visible, mais ce n'est pas le seul. Une migration peut aussi casser des droits d'accès, modifier des formats, interrompre une interface avec un logiciel comptable, rendre une macro inutilisable ou créer des écarts entre deux systèmes qui continuent à fonctionner en parallèle.
Si des données personnelles sont concernées, la sécurité ne peut pas être déléguée sans contrôle au prestataire ou au fournisseur cloud. La CNIL rappelle que l'entreprise doit identifier ses traitements, ses supports et ses ressources cloud, puis adapter les mesures de sécurité aux risques. Le contrat doit donc préciser les responsabilités, les accès, les sauvegardes, la gestion des incidents et les conditions de restitution des données.
Le budget doit intégrer davantage que la prestation de transfert. Il peut comprendre le nettoyage des données, les licences temporaires, la double exploitation, l'adaptation d'interfaces, les tests, le temps des utilisateurs référents, la formation, le support après bascule, les transferts de données facturés par certains fournisseurs et la mise hors service de l'ancien environnement.
Que vérifier dans le contrat du prestataire ?
Vérifiez au minimum le périmètre exact, les prérequis à votre charge, la fenêtre de bascule, les responsabilités en cas d'échec, le dispositif de sauvegarde, les critères de validation, le support après migration et la réversibilité. Pour un service cloud, la possibilité de récupérer les données dans un format exploitable et les coûts de sortie sont aussi importants que le prix d'entrée.
Comment sécuriser la bascule et l'après-migration ?
Le jour de la migration, le meilleur indicateur n'est pas que l'outil affiche « terminé ». Il faut vérifier que les utilisateurs peuvent travailler, que les données attendues sont présentes, que les droits sont cohérents et que les applications qui échangent entre elles continuent de le faire.
Ne désactivez pas immédiatement l'ancien système si vous n'avez pas validé le nouveau. Définissez une période de surveillance adaptée à la criticité du service, suivez les anomalies et documentez les corrections. Ce n'est qu'après validation des données, des accès, des interfaces et des sauvegardes du nouvel environnement que l'ancien peut être retiré dans de bonnes conditions.
Avant de demander un devis, préparez un inventaire du périmètre à migrer et exigez que le prestataire décrive noir sur blanc la méthode de test, les critères de réussite et la procédure de retour arrière. Ces trois points donnent souvent une meilleure indication de la solidité du projet que la liste des outils proposés.
