La peur de la migration retarde plus de signatures que le prix. Nous le voyons à chaque avant-vente : le dirigeant veut le nouveau système, puis quelqu'un demande comment l'équipe vendra pendant que les données déménagent, et le projet repart en commission pour six mois. La prudence se comprend. Un CRM gelé, c'est une équipe commerciale qui n'enregistre plus rien : les relances s'arrêtent et les commandes finissent sur des post-it. Divisez votre chiffre d'affaires annuel par 250 jours ouvrés : voilà ce que coûte, en moyenne, une journée de système à l'arrêt, avant de compter ce qui ne sera jamais ressaisi.
La vraie question derrière l'hésitation, c'est de savoir si une migration de données CRM sans interruption existe ailleurs que dans les plaquettes commerciales. Elle existe. C'est une méthode en trois étapes, documentée publiquement par les ingénieurs de Stripe, et que nous avons déroulée en production : sur la migration du CRM d'un groupe immobilier, et sur des déplacements de données au sein de la plateforme de réservation de parking aéroportuaire que nous opérons. L'ancien système reste en production du premier au dernier jour. Le nouveau travaille dans l'ombre, jusqu'à la preuve qu'il est prêt.
Voici la méthode, ses limites, et ce qu'elle doit changer dans un devis.
Pourquoi la bascule big bang échoue : l'irréversibilité
Le big bang a une logique séduisante : on arrête l'ancien système le vendredi soir, on migre le week-end, on démarre le nouveau le lundi matin. Le défaut apparaît le lundi à 9 h 02. Dès la première fiche saisie dans le nouveau système, les deux bases divergent. Un problème sérieux découvert le mardi laisse deux options : perdre deux jours de saisie en revenant en arrière, ou fusionner deux bases à la main. Personne ne choisit. On rustine le nouveau système en urgence, sous pression, avec l'activité qui tourne dessus.
Le vrai problème du big bang n'est pas qu'il puisse échouer. C'est qu'il ne s'annule pas. Toute la méthode qui suit vise une seule propriété : à chaque étape, on peut revenir en arrière sans rien perdre.
Une migration de données CRM sans interruption, en trois étapes
Trois étapes, dans cet ordre. Jamais l'inverse.
Étape 1 : le dual write, le nouveau système dans l'ombre
On branche d'abord la double écriture : chaque création et chaque modification dans l'ancien système est rejouée dans le nouveau, en silence. Personne ne lit encore le nouveau système. Il encaisse le trafic réel et les cas tordus sans qu'un seul utilisateur en dépende. Vos commerciaux ne remarquent rien, et c'est le but. Si le nouveau système tombe pendant cette phase, il ne se passe rien : l'ancien reste la seule source de vérité. Nous laissons l'ombre tourner le temps de voir passer un cycle métier complet, une clôture de fin de mois ou un pic de réservations.
Étape 2 : le backfill et la vérification, prouver que les copies concordent
La double écriture ne couvre que les données qui bougent. Reste l'historique, des années de fiches, que le backfill recopie par lots pendant que la double écriture continue. Vient alors la partie que tout le monde sous-estime : la réconciliation. On compare les deux bases enregistrement par enregistrement, on compte les écarts, on corrige les scripts, on rejoue. L'objectif est zéro écart inexpliqué. Pas « à peu près zéro » : zéro, ou une explication écrite pour chaque écart restant. Sur la migration du CRM du groupe immobilier, cette réconciliation a mangé plus de jours que tout le reste : des doublons et des dates rangées dans des champs texte, l'ordinaire d'une base qui a dix ans. Tant que le rapport d'écarts n'est pas propre, personne ne bascule.
On ne croit pas une copie sur parole. On la croit sur un rapport d'écarts à zéro.
Étape 3 : la bascule, un levier de retour arrière, quelqu'un pour le tenir
Préparée ainsi, la bascule devient un non-événement : on inverse le sens de lecture. Les utilisateurs lisent désormais le nouveau système, et l'ancien continue de recevoir les écritures en miroir. Ce miroir est le levier de retour arrière : tant qu'il tourne, revenir à l'ancien système prend quelques minutes et ne perd rien. La vraie question est de savoir qui tient le levier. Chez nous, la réponse est écrite avant la bascule : un ingénieur nommé, des critères de retour décidés à froid (quel taux d'erreur le déclenche, sous quel délai), et un responsable côté client qui sait qu'il peut demander le retour sans se justifier. Un levier que personne n'ose tirer ne protège de rien.
Le miroir ne s'éteint qu'après un cycle complet sans incident. Ce jour-là, la migration est finie.
Les limites : quand une fenêtre de maintenance coûte moins cher
Cette méthode a un coût. La double écriture est du code qu'il faut écrire, tester, puis retirer. Si votre activité s'arrête le week-end, si les utilisateurs sont internes, si les volumes restent modestes, une fenêtre de maintenance un samedi fait le même travail pour bien moins cher.
Chiffrons les deux chemins à nos tarifs publics. Sans interruption, sur un CRM de taille moyenne : 5 jours de dual write à 300 €, 10 jours de backfill et de réconciliation à 300 €, 4 jours de bascule et de double run à 450 €, soit 6 300 €. Avec une fenêtre de maintenance, le même périmètre tient en 8 jours à 300 €, soit 2 400 €, plus un week-end d'arrêt. Si un week-end d'arrêt ne vous coûte rien, la réponse est déjà trouvée. Nous recommandons le chemin sans interruption quand l'activité tourne sept jours sur sept, ou quand la confiance des équipes ne survivrait pas à un lundi raté. Pas par principe.
Le risque de migration dans votre devis
Un prestataire qui maîtrise cette méthode n'a aucune raison de la cacher. Dans un devis sérieux, le risque de migration occupe des lignes visibles :
- des jours de dual write, retrait du code compris ;
- des jours de réconciliation, avec un critère de sortie chiffré : zéro écart inexpliqué ;
- des jours de bascule, double run inclus ;
- le nom de la personne qui tient le levier de retour arrière.
Quand la reprise des données tient en une ligne « incluse », le risque n'a pas disparu. Il a changé de côté de la table.
Ces lignes figurent dans nos devis aux tarifs publics de 150 à 450 € par jour. Sur un périmètre plus large, elles deviennent un pod dédié, entre 15 000 et 40 000 € par mois. Notre modèle hybride, pilotage, qualité et contrats en Belgique et en Suisse, centre d'ingénierie à Rabat, tient ces tarifs sans raccourcir la réconciliation.
Sur nos 17+ projets livrés, nous avons déroulé ces trois étapes plus souvent que nous n'avons accepté de big bang, et aucun client n'a regretté d'avoir payé le rapport d'écarts. Pour savoir ce que ce chemin coûte sur votre propre système, décrivez-le sur jadev-corp.com/quote : un ingénieur relit chaque demande, le devis formel arrive sous un jour ouvré, et le projet peut démarrer au plus tôt deux semaines après la demande.