Migrer par briques plutôt qu'en big bang

La question qui bloque la plupart des décisions de migration n'est pas le budget : c'est la peur de l'arrêt d'activité. Elle est fondée quand le projet est conçu comme une bascule unique. Elle ne l'est plus quand la migration est progressive : une suite de petites bascules, chacune réversible. Cette page détaille le pattern.

Pourquoi le big bang échoue

Une bascule unique cumule mécaniquement les risques : tous les modules, toutes les données, tous les utilisateurs, le même jour. La recette la plus soignée ne couvre jamais les cas particuliers accumulés en vingt ans d'exploitation, et le jour J les révèle tous en même temps, sans autre issue que de corriger dans l'urgence sur un système que personne ne maîtrise encore. À l'inverse, une bascule par briques expose à chaque étape une surface de risque faible, connue, et annulable.

Ce que révèle un big bang raté

Le scénario type se déroule ainsi : la recette de préproduction s'est bien passée, la bascule est planifiée un week-end, et le lundi matin les premiers tickets remontent sur des cas que personne n'avait testés, souvent des combinaisons rares de données anciennes. À ce stade, revenir en arrière signifie restaurer une base entière et recommencer, pendant que l'activité est déjà arrêtée. C'est cette absence de marche arrière progressive, plus que la panne elle-même, qui transforme un incident gérable en crise.

Le principe de cohabitation

Pendant la transition, les deux systèmes tournent ensemble. L'ancien reste la référence pour ce qui n'a pas migré ; le nouveau prend la main brique par brique. Entre les deux, une couche de synchronisation maintient les données cohérentes : ce que l'un écrit, l'autre le voit. Cette couche est un investissement temporaire, elle disparaît à la fin, mais c'est elle qui achète la sérénité de toute la trajectoire.

Découper le périmètre : par module ou par population

• Par module : le référentiel articles migre, puis les devis, puis la facturation. Chaque module bascule pour tout le monde à la fois. Adapté quand les modules sont bien séparés.
• Par population : une agence, un site ou un groupe d'utilisateurs pilote passe sur le nouveau système complet, les autres suivent par vagues. Adapté aux parcs décentralisés et aux éditeurs (client par client).
• Mixte : les deux se combinent, un module pilote sur une population pilote, puis extension progressive des deux axes.

Le bon découpage sort de la cartographie d'audit : il suit les lignes de faible couplage du système existant, là où l'on peut couper sans tout défaire.

Ce que nous vérifions à ce stade

Avant de valider un découpage, plusieurs points sont vérifiés systématiquement :

• Le couplage réel entre modules, au-delà de l'organisation apparente du code.
• Les dépendances de données entre les populations d'utilisateurs concernées par chaque vague.
• La disponibilité d'un périmètre pilote suffisamment représentatif pour valider la mécanique sans exposer l'ensemble du parc.
• Les fenêtres calendaires compatibles avec l'activité métier, pour éviter de basculer une brique en pleine période critique.

Synchronisation des données pendant la transition

C'est le sujet technique central de la cohabitation. Selon les cas : synchronisation à sens unique (le nouveau lit l'ancien), bidirectionnelle sur des périmètres disjoints, ou par événements pour les flux critiques. Les règles sont écrites avant la première bascule : qui est maître sur quelle donnée, comment se traite un conflit, comment se rejoue un échec. Le journal de synchronisation fait partie des livrables et se consulte comme un tableau de bord du chantier.

Réversibilité à chaque étape

Chaque bascule de brique s'accompagne de sa procédure de retour : si un problème bloquant apparaît, la brique revient sur l'ancien système en heures, pas en jours, données comprises. Cette réversibilité n'est pas un aveu de doute, c'est une assurance : elle transforme chaque jalon en décision à faible enjeu, ce qui permet précisément d'avancer vite. Les projets qui n'ont pas de marche arrière avancent lentement, car chaque pas y est irréversible.

Erreurs fréquentes

• Définir la procédure de retour arrière après la bascule plutôt qu'avant, dans l'urgence.
• Sous-estimer le temps de restauration réel d'une brique en la testant seulement sur un jeu de données réduit.
• Considérer la réversibilité comme acquise sans l'avoir répétée au moins une fois avant la bascule définitive.
• Basculer plusieurs briques dépendantes le même jour, ce qui complique tout retour arrière isolé.

Durée type d'une trajectoire

Une trajectoire progressive complète se compte en trimestres : quelques mois pour le socle (données, premier module, couche de synchronisation), puis un rythme de croisière où les briques s'enchaînent. C'est plus long qu'un big bang sur le papier, et plus court dans la réalité, car les big bangs ratés se paient en mois de stabilisation. Le calendrier précis dépend du découpage : l'audit en propose un, jalon par jalon.

FAQ