Le risque n’est pas technique, il est organisationnel
Une migration échoue rarement parce que le nouveau code est mauvais. Elle échoue parce qu’elle dure trop longtemps, que l’équipe est immobilisée, que les évolutions urgentes doivent être faites deux fois, et que la bascule finale arrive avec dix-huit mois de dette accumulée.
La reprise progressive résout ce problème : chaque lot migré est mis en production immédiatement, et l’entreprise continue de recevoir des évolutions pendant toute la durée du chantier.
Comment on procède concrètement
La nouvelle application est placée devant l’ancienne. Au départ, elle ne fait que transmettre : tout le trafic passe et repart vers le système existant. Puis, lot par lot, des routes sont interceptées et servies par le nouveau code.
L’utilisateur ne voit rien. Le basculement se fait progressivement, et un retour arrière sur un lot précis reste possible à tout moment.
Les données méritent leur propre lot
La reprise de données n’est pas une tâche annexe. Elle demande un environnement de répétition, une exécution à blanc, un rapport de cohérence chiffré et une validation métier explicite. Sur un système de douze ans, on découvre toujours des enregistrements incohérents que personne ne soupçonnait — mieux vaut les traiter avant la bascule que pendant.