Aller au contenu
Espace client

Audit gratuit

Modernisation

La bascule : faire tourner l’ancien et le nouveau en même temps

Remplacer un système ne se fait pas un week-end. Cela se fait pendant une période où les deux tournent, et cette période se conçoit.

Publié le 9 août 2026 — Algeria Agency

Il y a un moment, dans tout remplacement de système, où l’ancien fonctionne encore et le nouveau fonctionne déjà. Ce moment n’est pas un raté d’organisation : c’est la seule façon connue de changer d’outil sans arrêter l’entreprise. Il dure des semaines, il coûte du travail en double, et il est presque toujours improvisé.

C’est aussi le moment où les migrations échouent. Pas au moment de la reprise des données, qui est technique et se teste, mais quelques semaines après : deux systèmes divergent lentement, personne ne sait plus lequel fait foi, et l’entreprise finit par revenir à l’ancien parce que c’est celui dans lequel les chiffres sont justes.

Cet article décrit cette période et la façon de la traverser : ce qu’il faut vraiment faire en double, dans quel sens saisir, comment vérifier que les deux disent la même chose, et comment on arrête l’ancien pour de bon. L’article qui l’accompagne traite de la décision de remplacer ; rien de cela n’est repris ici.

Il ne contient aucun graphique, et pour une fois ce n’est pas un refus : rien ici ne se décide sur un chiffre. C’est un article de procédure, et la durée d’une bascule dépend de votre activité plutôt que d’une moyenne que quelqu’un pourrait publier.

La bascule est une période, pas une date

Dans presque toutes les conversations, la mise en service est une date : on démarre le premier du mois. Cette phrase décrit ce qui est écrit sur le contrat, pas ce qui se passe dans l’entreprise. Ce qui se passe est une période pendant laquelle l’ancien système continue de porter le travail réel et le nouveau apprend à le porter.

Traiter la bascule comme une date produit une décision unique et irréversible prise un dimanche soir, avec pour seul plan de secours de tout remettre en arrière. Traiter la bascule comme une période produit une suite de petites décisions réversibles, dont chacune peut être annulée sans annuler les autres.

La durée dépend de votre cycle plutôt que de la taille du logiciel, et c’est le point que les plannings ratent. Une entreprise qui facture au mois doit voir passer une clôture mensuelle complète dans le nouveau système avant de pouvoir juger ; une entreprise qui a une saison doit en voir passer une. Ce qui décide est la période au bout de laquelle tous les cas de votre métier se sont présentés au moins une fois.

La conséquence est qu’une bascule ne se planifie pas en semaines de travail mais en événements à observer. « Jusqu’à la première clôture correcte » est une échéance ; « trois semaines » est un vœu, parce qu’il est possible que rien d’intéressant ne se produise pendant trois semaines.

Ce qui doit être vrai avant de commencer

Il existe une courte liste de conditions sans lesquelles la période parallèle ne fait qu’installer le désordre plus vite. Elles se vérifient avant, et une seule manquante suffit à repousser.

La reprise des données doit être rejouable. Pas réussie une fois : rejouable, c’est-à-dire qu’on peut la relancer et obtenir le même résultat. Pendant la période parallèle, l’ancien système continue de recevoir des données, et vous aurez besoin de rejouer la reprise plusieurs fois. Une migration faite à la main une fois est une migration qu’il faudra refaire à la main.

Il faut aussi quelqu’un, nommé, qui tranche. Pendant cette période, les deux systèmes se contrediront sur des cas réels, et la question « lequel a raison » se posera plusieurs fois par semaine. Sans une personne désignée, chaque cas devient une discussion, et les discussions s’accumulent plus vite qu’elles ne se règlent.

Enfin, l’ancien système doit rester capable de fonctionner seul jusqu’à la fin de la période. Cela paraît évident et c’est le premier compromis que l’on fait : on arrête une petite chose dans l’ancien « puisqu’on part de toute façon », et le plan de repli de la section 7 cesse silencieusement d’exister.

Le double fonctionnement : ce qu’on double vraiment

Faire tourner deux systèmes ne veut pas dire tout faire deux fois. C’est le malentendu qui rend la période insupportable et qui la fait abandonner au bout de dix jours : les équipes saisissent tout en double, se fatiguent, et retournent à l’ancien.

Ce qui doit être doublé, ce sont les entrées : ce qui rentre de nouveau dans l’entreprise pendant la période — les commandes, les factures, les mouvements. Ce qui ne doit pas être doublé, ce sont les sorties : les documents envoyés, les paiements, les messages aux clients. Un seul système imprime et envoie, et c’est celui qui fait foi ce jour-là.

Cette distinction est ce qui rend la période supportable, parce qu’elle divise le travail supplémentaire par deux ou trois. Elle évite aussi la catégorie d’incident la plus embarrassante : le client qui reçoit deux fois la même facture, une de chaque système, avec deux numéros différents.

Elle a une conséquence à écrire au tableau : pendant toute la période, il y a à chaque instant un système qui fait foi, et tout le monde sait lequel. Ce n’est pas nécessairement le même du début à la fin — c’est même le but que cela change — mais cela ne doit jamais être ambigu, et le changement se décide plutôt qu’il ne se constate.

Le sens unique : où l’on saisit, où l’on lit

La façon la plus simple de tenir deux systèmes cohérents est de n’en laisser qu’un recevoir la saisie humaine, et de faire circuler les données dans un seul sens vers l’autre. Deux systèmes où l’on saisit des deux côtés divergent en quelques jours, quelle que soit la discipline des équipes.

Le sens naturel au début est ancien vers nouveau : on continue de travailler comme d’habitude, et le nouveau système reçoit une copie. Cela ne demande rien aux équipes, ce qui est précisément sa valeur — la période commence sans effort supplémentaire et sans risque.

Le renversement, quand il vient, est l’événement le plus important de toute la bascule, et il doit être annoncé plutôt que progressif. À partir de tel jour, la saisie se fait dans le nouveau et l’ancien reçoit la copie. Un renversement décidé service par service produit une période où les deux directions coexistent, ce qui est la seule configuration garantie de produire des données fausses des deux côtés.

La copie dans le sens inverse mérite d’être maintenue quelque temps après le renversement, même si plus personne ne lit l’ancien. Elle ne sert pas à travailler ; elle sert à ce que le plan de repli reste réel, et elle coûte peu tant que le mécanisme existe déjà.

Réconcilier : trois contrôles qui suffisent

Comparer deux systèmes ligne à ligne est un projet en soi et personne ne le tient plus d’une semaine. Trois contrôles répétés chaque semaine suffisent à détecter tout ce qui compte, et ils tiennent sur une feuille.

Le compte : combien d’objets de chaque type existent de part et d’autre — clients, commandes du mois, factures émises. Un écart de nombre est le plus facile à voir et le plus révélateur, parce qu’il désigne une catégorie entière qui ne passe pas plutôt qu’une valeur qui se décale.

Le total : la somme des montants sur la même période. Deux systèmes peuvent avoir le même nombre de factures et des totaux différents, ce qui indique une règle de calcul divergente — une taxe, un arrondi, une remise — et non un problème de transfert. C’est le contrôle qui trouve les différences de règles plutôt que les données manquantes.

Les extrêmes : le plus gros et le plus petit objet de la période, regardés à la main des deux côtés. Cela paraît artisanal et c’est le plus efficace des trois, parce que les défauts de migration se logent presque toujours dans les cas limites — la commande à zéro, celle avec cinquante lignes, celle qui a été annulée puis rétablie.

Les données que l’ancien système ne contient pas

Une partie de ce que l’entreprise sait n’est écrite nulle part dans le système que vous remplacez. Elle est dans les têtes, dans un cahier, dans le nom d’un fichier, ou dans une convention que tout le monde connaît sans l’avoir écrite.

Les cas les plus fréquents sont toujours les mêmes : les clients qui ont un accord particulier, les articles qu’il ne faut pas vendre à certains, les délais qu’on accorde à quelques-uns. Rien de tout cela n’a de champ dans l’ancien logiciel, donc rien de tout cela n’est repris — et le nouveau système est jugé mauvais parce qu’il ne sait pas ce que personne ne lui a dit.

La période parallèle est le meilleur moment pour les récolter, et c’est même sa deuxième utilité après la vérification. Chaque fois qu’une personne corrige à la main quelque chose que le nouveau système a proposé, elle vient de nommer une règle non écrite. Ces corrections valent d’être notées à mesure, sur la même feuille que les contrôles.

À la fin de la période, cette liste est le vrai livrable de la migration, davantage que les données elles-mêmes. Elle contient ce que l’entreprise savait sans le savoir, et c’est la première fois qu’elle existe sous une forme qui survit au départ de quelqu’un.

Former sur le nouveau pendant que l’ancien tourne

La formation faite avant la bascule s’oublie, parce qu’elle porte sur des gestes que personne ne fera avant plusieurs semaines. La formation faite après la bascule arrive trop tard, au moment où l’équipe travaille sous pression sur un outil qu’elle ne connaît pas.

La période parallèle est la seule fenêtre où l’on peut apprendre sur des cas réels sans conséquence, puisque l’ancien système porte encore la responsabilité. C’est un avantage que les plannings ne comptent jamais, et il justifie à lui seul une partie de la durée.

Le format qui fonctionne n’est pas une session mais une habitude : chaque personne fait dans le nouveau système, chaque jour, le travail qu’elle vient de faire dans l’ancien. Une demi-heure par jour pendant trois semaines apprend davantage qu’une journée de formation, parce que les cas rencontrés sont les siens.

Il faut accepter que cela produise des questions dont la réponse est « le nouveau système ne fait pas cela comme ça ». Chacune est soit une règle non écrite de la section 5, soit une évolution à demander, soit une habitude que l’entreprise peut abandonner — et les trier pendant la période coûte infiniment moins cher qu’après.

Le plan de repli, et la date après laquelle il n’existe plus

Un plan de repli n’est pas l’intention de revenir en arrière ; c’est une procédure écrite qui dit qui décide, sur quel critère, en combien de temps, et ce qu’on fait des données saisies entre-temps. La dernière partie est celle qu’on oublie et c’est la seule difficile.

Le critère doit être écrit avant, quand personne n’est sous pression, et il doit être observable plutôt qu’une impression. « Si la clôture du mois ne peut pas être produite dans le nouveau système avant le cinq » est un critère ; « si ça se passe mal » n’en est pas un, parce que dans le feu de l’action tout se passe mal.

Il faut aussi dire quand ce plan cesse d’exister. Un repli reste possible tant que l’ancien système est resté capable de fonctionner seul ; au-delà d’un certain point — un mois de saisies uniquement dans le nouveau, un changement d’organisation — revenir coûte plus cher que continuer, et prétendre le contraire est plus dangereux que de l’assumer.

Cette date se décide et s’annonce. C’est ce qui distingue une bascule d’une dérive : après ce jour, l’entreprise ne se demande plus si elle revient en arrière, et l’énergie qui allait dans cette question va dans la correction du nouveau système.

Les jours qu’il ne faut pas choisir

Le choix de la date d’inversion est une décision de calendrier plus que de technique, et quelques dates sont mauvaises pour des raisons qui n’ont rien à voir avec le logiciel.

Une fin de mois est le pire moment, et c’est celui qu’on choisit naturellement parce qu’il paraît propre. C’est le moment où l’équipe est déjà occupée par la clôture, où les volumes sont hauts, et où une erreur se voit immédiatement sur des documents qui partent. Le début de mois, juste après une clôture terminée dans l’ancien système, offre la période la plus calme et un point de comparaison net.

Une veille de congés est le deuxième piège : la bascule se fait, puis les personnes qui savent répondre ne sont pas là pendant deux semaines, et l’équipe restante prend des habitudes de contournement qu’il faudra défaire ensuite. Une saison haute est le troisième, pour des raisons évidentes qui ne sont pourtant pas toujours respectées.

La règle simple : basculer quand vous pouvez vous permettre de ralentir un peu, et quand les personnes qui connaissent le métier sont présentes. Un système mis en service pendant une période calme sera jugé sur ses qualités ; le même mis en service pendant un pic sera jugé sur le pic.

Arrêter l’ancien : geler, archiver, débrancher

L’arrêt de l’ancien système n’est pas un événement mais trois, séparés dans le temps, et les confondre est ce qui laisse des systèmes zombies allumés pendant des années dans des entreprises qui ont pourtant migré.

Geler d’abord : plus personne ne saisit dans l’ancien, il reste consultable. C’est le seul des trois qui se décide, et il doit être annoncé à une date précise plutôt que se produire par désaffection. Un système que quelques personnes continuent d’alimenter « pour être tranquilles » est un système qui n’est pas gelé, et l’entreprise a alors deux vérités.

Archiver ensuite : produire une copie des données dans un format lisible sans l’ancien logiciel — des fichiers, pas une sauvegarde du système. La différence est tout : une sauvegarde exige de remonter la machine et la licence pour être lue, ce que personne ne saura faire dans cinq ans. Un export lisible se relit avec n’importe quoi.

Débrancher enfin, une fois l’archive vérifiée en l’ouvrant. Cette dernière étape libère une licence, une machine, parfois un contrat de maintenance, et c’est la seule qui produit une économie visible. Elle est aussi celle qu’on repousse indéfiniment, ce qui explique le nombre d’entreprises qui paient encore pour un logiciel qu’elles n’utilisent plus.

Ce que devient l’ancien système après

Il reste presque toujours une raison de consulter l’ancien : une question sur un dossier de l’année précédente, un contrôle, un client qui revient avec un document ancien. Prévoir cela évite de garder tout le système allumé pour un besoin qui se produit quatre fois par an.

La bonne forme dépend de la fréquence, et elle se décide en la regardant honnêtement. Si la consultation est rare, l’export archivé de la section précédente suffit, rangé où quelqu’un le retrouvera. Si elle est régulière, il vaut mieux reprendre l’historique dans le nouveau système, en lecture seule, que de maintenir deux outils.

Ce qu’il ne faut pas faire est de garder l’ancien système accessible « au cas où » sans décider de son statut. Il se remet à recevoir des saisies, doucement, par une ou deux personnes qui le préfèrent, et l’entreprise se retrouve deux ans plus tard avec deux systèmes vivants et une migration qui n’a jamais fini.

La durée de conservation, elle, ne se décide pas au feeling : elle se prend sur vos obligations comptables et contractuelles, qui sont presque toujours plus longues que ce que l’on croit. C’est le seul paramètre de cette page qui vient d’ailleurs que de votre organisation, et il vaut une question à votre comptable plutôt qu’une estimation.

Ce que nous faisons, et ce que nous refusons

Notre part est la mécanique de la période : la reprise rejouable plutôt que réussie une fois, la copie à sens unique et son renversement annoncé, la feuille des trois contrôles hebdomadaires, la collecte des règles non écrites à mesure qu’elles apparaissent, et l’export d’archive lisible sans l’ancien logiciel. Ce sont des outils modestes, et ils sont ce qui fait la différence entre une bascule et une dérive.

Nous refusons de promettre une durée. Elle ne dépend pas de la taille du logiciel mais de votre cycle : le nombre de semaines au bout duquel tous les cas de votre métier se sont présentés au moins une fois. Un prestataire qui annonce trois semaines sans connaître votre clôture ni votre saison annonce un chiffre qu’il a choisi pour être rassurant.

Nous refusons aussi de faire la bascule sans plan de repli écrit, y compris quand le client le juge inutile et que cela nous ferait gagner du temps. Le repli ne sert presque jamais ; ce qu’il sert toujours, c’est à obliger tout le monde à écrire à l’avance le critère qui dirait que cela se passe mal, et cette conversation-là a une valeur même quand le repli n’a pas lieu.

Enfin, deux choses de cette page se font sans nous et décident d’une grande partie du résultat : nommer la personne qui tranche quand les deux systèmes se contredisent, et choisir une date d’inversion en début de mois, hors congés et hors saison. Les deux sont gratuites, elles se décident cette semaine, et aucun outil ne les remplace.

Questions fréquentes

Combien de temps faut-il faire tourner les deux systèmes ?

Le temps que tous les cas de votre métier se présentent au moins une fois, ce qui dépend de votre cycle plutôt que de la taille du logiciel. Une entreprise qui facture au mois doit voir passer une clôture complète ; une entreprise saisonnière doit voir passer sa saison. « Jusqu’à la première clôture correcte » est une échéance ; « trois semaines » est un vœu, parce qu’il est possible que rien d’intéressant ne se produise en trois semaines.

Faut-il vraiment tout saisir deux fois ?

Non, et c’est le malentendu qui fait abandonner la période au bout de dix jours. On double les entrées — ce qui rentre de nouveau dans l’entreprise — et jamais les sorties : un seul système imprime, envoie et paie, et c’est celui qui fait foi ce jour-là. Cela divise le travail supplémentaire et évite qu’un client reçoive deux factures avec deux numéros.

Comment vérifier que les deux systèmes disent la même chose ?

Trois contrôles par semaine suffisent. Le compte d’objets de chaque type, qui trouve les catégories entières qui ne passent pas. Le total des montants sur la période, qui trouve les règles de calcul divergentes plutôt que les données manquantes. Et les extrêmes — le plus gros et le plus petit objet — regardés à la main, parce que les défauts de migration se logent presque toujours dans les cas limites.

Quand faut-il basculer la saisie dans le nouveau système ?

À une date annoncée, jamais progressivement service par service : deux directions de copie qui coexistent produisent des données fausses des deux côtés. Choisissez un début de mois, juste après une clôture terminée dans l’ancien, hors congés et hors saison haute. Une fin de mois est le pire moment et c’est celui qu’on choisit naturellement parce qu’il paraît propre.

Que fait-on de l’ancien système une fois la migration terminée ?

Trois étapes séparées dans le temps : geler — plus personne ne saisit, il reste consultable — puis archiver sous forme de fichiers lisibles sans le logiciel d’origine, puis débrancher une fois l’archive ouverte et vérifiée. Une sauvegarde système ne suffit pas : elle exige de remonter la machine et la licence, ce que personne ne saura faire dans cinq ans.

À quoi sert un plan de repli si on ne s’en sert presque jamais ?

À obliger tout le monde à écrire à l’avance, sans pression, le critère observable qui dirait que cela se passe mal — « si la clôture ne peut pas être produite avant le cinq », et non « si ça se passe mal ». Cette conversation a une valeur même quand le repli n’a pas lieu. Il faut aussi dater sa fin : au-delà d’un point, revenir coûte plus cher que continuer.

Où nous intervenons

Nommer aujourd’hui celui qui tranchera en cas de désaccord entre l’ancien et le nouveau change presque tout le déroulement, et ne coûte rien.

  • Nous faisons en sorte que la reprise puisse être rejouée, pas seulement réussie.
  • Nous écrivons le plan de repli avant la bascule, y compris quand vous le jugez inutile.
  • Nous plaçons la date en début de mois, juste après une clôture.

Aucune durée ne sera promise : c’est votre cycle qui commande, pas la taille du logiciel, et une date annoncée trop tôt fait basculer au mauvais moment.

À lire ensuite

Parlons de votre projet

Un audit gratuit, sans engagement : nous regardons votre présence en ligne et nous vous disons ce qui coince.

Nous mesurons l’audience de ce site avec Google Analytics, pour savoir quelles pages servent vraiment. Vous pouvez arrêter cette mesure à tout moment depuis le pied de page. Politique de cookies