Notre méthode de migration : progressive, réversible, sans coupure

Une migration d'application métier ne se juge pas à la beauté de la cible : elle se juge au fait que l'activité n'a jamais cessé pendant le chantier. Notre méthode est construite autour de cette exigence unique. Cinq étapes, des livrables à chacune, et une règle qui ne souffre aucune exception : à tout moment, on doit pouvoir s'arrêter ou revenir en arrière sans casse.

Le principe : jamais de big bang

Le big bang, cette bascule unique où l'ancien système s'éteint un vendredi et le nouveau s'allume un lundi, est le premier facteur d'échec des migrations. Il concentre tous les risques sur un seul week-end : données, formations, cas particuliers non vus en recette. Nous faisons l'inverse : l'ancien et le nouveau système cohabitent, et la bascule se fait par briques, chacune étant petite, testable et réversible. La migration cesse d'être un saut dans le vide pour devenir une série de pas contrôlés.

Ce que change la cohabitation au quotidien

Concrètement, la cohabitation change trois choses pour vos équipes. D'abord, personne n'est mis devant un outil nouveau du jour au lendemain : chaque bascule concerne un périmètre restreint, préparé et accompagné. Ensuite, les habitudes de travail évoluent par petites touches, ce qui réduit la charge de formation à chaque étape plutôt que de la concentrer sur une semaine critique. Enfin, un incident sur une brique récente n'affecte jamais l'ensemble du parc : les modules déjà stabilisés continuent de fonctionner normalement pendant qu'on corrige le point isolé qui pose problème.

Étape 1 : audit applicatif

Tout commence par cinq jours d'audit : volumétrie et complexité du code, dette technique, état de la base HFSQL, couplages, risque humain, exposition contractuelle. Le livrable est un diagnostic chiffré avec trois scénarios comparés et une trajectoire recommandée. C'est ce document qui permet de décider, y compris de ne pas migrer : une part significative de nos audits conclut qu'un gel sécurisé est la meilleure option du moment.

Étape 2 : trajectoire et priorisation

La trajectoire découpe le parc en briques et les ordonne : par où commencer, qu'est-ce qui attend, qu'est-ce qui ne migre jamais. Les critères sont métier avant d'être techniques : valeur pour les utilisateurs, risque en cas d'incident, dépendances entre modules. Cette étape fixe aussi le calendrier de cohabitation et les jalons de décision où vous choisissez, à chaque fois, de poursuivre ou de marquer une pause.

Étape 3 : cohabitation et bascule par briques

Pendant toute la transition, l'application d'origine reste en service. Chaque brique migrée (un module, un processus, une population d'utilisateurs) bascule quand elle est prête : les données circulent entre les deux mondes par synchronisation, et les utilisateurs concernés changent d'outil sans que les autres s'en aperçoivent. Si un problème apparaît, la brique revient sur l'ancien système le temps de corriger. Ce pattern de cohabitation est ce qui lève la peur, légitime, de l'arrêt d'activité.

Les questions à poser à tout prestataire

• Comment se déroule un retour arrière si une brique migrée pose problème en production ?
• Qui reste maître de la donnée pendant la période où les deux systèmes cohabitent ?
• Quel est le délai réel entre la détection d'un incident et le retour à l'ancien système ?
• Comment la synchronisation des données est-elle vérifiée à chaque cycle ?

Étape 4 : reprise de données

La reprise de données est un chantier à part entière, souvent plus complexe que la reprise du code : extraction depuis le format propriétaire, nettoyage, mapping documenté, rejeux à blanc et recette d'intégrité. Nous la traitons tôt, car une base saine et migrée est le socle qui rend toutes les autres briques possibles. Les contrôles sont systématiques : comptages, agrégats financiers, échantillons de cas limites, comparés entre source et cible à chaque rejeu.

Erreurs fréquentes

• Sous-estimer le temps de nettoyage parce que la base semble propre en surface.
• Traiter la reprise comme une opération unique alors qu'elle doit être rejouée plusieurs fois avant la bascule finale.
• Valider la recette uniquement par des comptages, sans vérifier les agrégats métier ni les cas limites.
• Confier la validation finale à la seule équipe technique, sans signature du référent métier.

Étape 5 : TMA

Pendant la migration, l'existant doit continuer à vivre : corrections, petites évolutions réglementaires, sécurité. Notre TMA transitoire couvre ce maintien en conditions opérationnelles, avec une règle de gel raisonnée : on n'ajoute plus de grandes fonctions à l'ancien système, on le garde fiable le temps que le nouveau le remplace. Après la bascule complète, la TMA se poursuit sur la cible ou se transfère à votre équipe, formée pendant le projet.

Le point de vigilance principal se situe dans la coordination des priorités : une correction urgente sur l'existant ne doit jamais retarder un jalon de migration déjà validé, et inversement, l'avancement du projet ne doit jamais faire passer un correctif bloquant au second plan. Cette coordination se pilote lors d'un point périodique commun aux deux volets, avec un seul calendrier partagé plutôt que deux plannings qui s'ignorent.

Les livrables à chaque étape

Chaque livrable vous appartient et reste utilisable si vous décidez de poursuivre avec une autre équipe. C'est notre définition de la réversibilité : elle s'applique aussi à nous.

FAQ