Reprise de données

Une migration se juge trois mois après la bascule.

Elle se juge trois mois plus tard, quand quelqu’un compare le chiffre d’affaires de l’an dernier dans le nouveau système avec celui qu’il avait présenté au conseil. Si les deux ne tombent pas juste, la migration a échoué, même si toutes les lignes sont passées.

Catégories d’écarts, toutes tracées: 3
Bascule sur un écart inexpliqué: 0
Business Central, Nav, SAP, Sage: 4 ERP

Notre valeur ajoutée

Déplacer les lignes est la partie facile

Une reprise de données se présente comme un problème technique : extraire, transformer, charger. C’est la partie que les outils savent faire, et c’est rarement là que les projets échouent.

Le problème réel est sémantique. Dans l’ancien système, le champ « catégorie » contient trois valeurs héritées d’une organisation qui n’existe plus depuis 2018 ; le champ « code client 2 » a été détourné pour stocker un code chantier ; une remise commerciale est parfois une ligne de facture négative, parfois un champ de l’entête. Aucune de ces informations n’est dans un schéma. Elles sont dans la mémoire de trois personnes, dont deux sont parties.

Notre travail consiste à retrouver ces conventions, à les écrire, à les faire valider, puis à démontrer par le calcul que la traduction est juste. Le transport des données arrive en dernier, et c’est la partie la plus courte.

Si le total du chiffre d’affaires de l’exercice précédent ne tombe pas au centime près, nous ne basculons pas.
Ce que nous vérifions avant chaque bascule

Le rapprochement

Trois sortes d'écarts, trois traitements

Au premier rapprochement, les totaux ne tombent jamais juste. C’est attendu. Ce qui distingue une migration maîtrisée d’une migration subie, c’est ce qu’on fait de chaque écart.

Documenté, on avance

Expliqué et voulu

L’ancien système comptait les commandes annulées dans le chiffre d’affaires, le nouveau ne les compte plus. L’écart est réel, il est voulu, et il est écrit dans le rapport de recette avec son montant. Personne ne le redécouvrira dans six mois.

On corrige, on rejoue

Expliqué et non voulu

Une erreur de correspondance : deux codes taxes fusionnés à tort, une date de comptabilisation prise à la place de la date de facture. On corrige la règle, on rejoue l’import complet, et on rapproche à nouveau. Jamais de correction manuelle sur les données chargées.

La bascule attend

Inexpliqué

Quatre-vingts euros manquent sur un exercice à quarante millions. Statistiquement négligeable, et pourtant : un écart qu’on ne sait pas expliquer est un écart dont on ne connaît pas la cause, donc pas la portée. Il bloque la bascule jusqu’à ce qu’on la trouve.

Notre connaissance du terrain

Ce que nous savons de chaque système

Chaque système a ses habitudes. Les connaître à l’avance fait gagner des semaines : voici celles que nous rencontrons le plus souvent.

Ce que nous anticipons sur chaque système source
Système	Sa particularité	Ce que nous mettons en place
Business Central	Les FlowFields ne sont pas stockés : ce sont des calculs à la volée. Une extraction naïve les rapatrie à zéro, et les soldes clients paraissent nuls.	Nous les reconstruisons en mesures explicites, à partir des tables d'écritures, et nous rapprochons avec l'écran de l'ERP, ligne à ligne.
Business Central, plusieurs instances	Chaque société a son propre plan comptable, ses propres codes articles et ses propres dimensions. Le même code désigne deux choses.	Nous ajoutons une étape d'alignement avant toute consolidation, et nous utilisons bc2adls pour un export incrémental qui ne sature pas les quotas d'API.
Dynamics Nav	Les dimensions analytiques ont souvent changé de signification au fil des versions, sans que rien ne le trace.	Nous datons chaque convention et nous appliquons la bonne selon la période. Un code n'est pas traduit de la même façon en 2014 et en 2024.
Sage 100 et Sage 1000	L'analytique est souvent tenu partiellement, avec des écritures non ventilées qu'un rapport agrégé masque.	Nous isolons et chiffrons le non-ventilé plutôt que de le répartir au prorata. Un chiffre faux réparti proprement reste un chiffre faux.
SAP	Le volume et la profondeur de l'historique rendent l'extraction complète coûteuse, et les tables sont nombreuses.	Nous restreignons le périmètre aux domaines réellement utilisés en pilotage, après inventaire, pas avant.
Fichiers Excel de service	Ils contiennent les règles réelles, et ils ne sont ni versionnés, ni cohérents entre eux.	Nous les traitons comme une source à part entière : lecture, formalisation des règles, validation par leur auteur, puis remplacement.

Notre position

Entre trois parties, et au service d'une seule

Une reprise met en présence trois acteurs : l’intégrateur de l’ancienne solution, celui de la nouvelle, et vos équipes. Chacun détient une part de la réponse et aucun ne détient l’ensemble.

L'intégrateur historique sait pourquoi un champ a été détourné il y a dix ans ; l'intégrateur de la nouvelle solution sait ce qu'elle attend en face. Ni l'un ni l'autre n'est neutre : le premier termine sa mission, le second vend la suite. Nous nous plaçons entre les deux pour établir la table de correspondance, sans rien avoir à vendre d'un côté ni de l'autre, et le seul intérêt que nous servons est le vôtre.

Entre deux intégrateurs, et au service d'un seul

L'un connaît les raisons du passé, l'autre les attentes du futur. Aucun des deux n'est neutre.

Cette position est inconfortable, et c'est la nôtre : nous n'avons rien à vendre sur l'ancien système ni sur le nouveau. C'est ce qui rend la table de correspondance crédible aux yeux des deux parties.

L'intégrateur historique

Il sait pourquoi le champ a été détourné, quelle version a introduit quelle convention, et quels développements spécifiques s’exécutent avant l’enregistrement. C’est la source la plus précieuse et la plus difficile à mobiliser, parce que le projet signe la fin de sa mission.

L’intégrateur de la nouvelle solution

Il sait ce que la cible attend, quels contrôles elle appliquera au chargement, et quelles données elle refusera. Il connaît le format d’arrivée, rarement le sens des données de départ.

Vos équipes

Elles savent quels chiffres doivent tomber juste, et ce sont elles qui valideront ou non la bascule. Elles sont l’autorité finale sur le sens, même quand elles ne connaissent pas la structure des tables.

Notre place

Entre les trois, sans rien à vendre sur l’ancien ni sur le nouveau. Nous établissons le mapping, nous le documentons, et nous le démontrons par le rapprochement. C’est la seule position depuis laquelle l’arbitrage est crédible.

La bascule

Double run, critères, retour arrière

La bascule est un moment à risque, et le risque se réduit par des décisions prises à l’avance, pas par de la vigilance le jour J.

Le double run fait tourner les deux systèmes en parallèle sur une période convenue, avec un rapprochement automatisé chaque jour. Ce n’est pas confortable pour vos équipes, qui saisissent deux fois ; c’est ce qui permet de détecter un écart sur des données réelles, avant qu’il ne devienne irréversible.

Les critères de bascule sont écrits avant, pas décidés le jour même. Quels totaux doivent tomber juste, à quelle tolérance près, sur quels périmètres. Un critère écrit après coup s’adapte toujours au résultat obtenu.

Le plan de retour arrière précise ce qui reste accessible en lecture, pendant combien de temps, et jusqu’à quelle date la décision d’annuler reste possible. Sans date limite, la question se repose indéfiniment et personne n’ose plus trancher.

Aller plus loin

Ce qui prolonge une reprise réussie

Questions fréquentes

Ce qu'on nous demande sur les reprises

Combien de temps faut-il prévoir pour une reprise de données ?

Cela dépend moins du volume que du nombre de règles à retrouver. Reprendre trois ans de ventes depuis un seul Business Central prend quelques jours. Reprendre le même historique depuis un Nav de 2013 dont les dimensions analytiques ont changé deux fois de signification prend plusieurs semaines, non pas pour déplacer les lignes, mais pour établir ce que chaque code voulait dire à chaque époque.

Que se passe-t-il si les totaux ne tombent pas juste ?

C'est le cas normal au premier passage, et c'est précisément l'intérêt du rapprochement. Chaque écart est classé : expliqué et voulu, expliqué et à corriger, ou inexpliqué. Les deux premiers se documentent ou se corrigent. Le troisième bloque la bascule : nous ne basculons jamais sur un écart que personne ne sait expliquer.

Travaillez-vous avec notre intégrateur historique ?

Oui, et c'est souvent la clé. L'intégrateur historique sait pourquoi le champ « code client 2 » a été détourné en 2016 ; l'intégrateur de la nouvelle solution sait ce qu'elle attend. Nous nous plaçons entre les deux et nous établissons le mapping. Cette position est inconfortable et c'est la nôtre : nous n'avons rien à vendre sur l'ancien ni sur le nouveau.

Faut-il tout reprendre ?

Presque jamais. Reprendre dix ans d'historique transactionnel dans un nouvel ERP coûte cher, ralentit le système et sert rarement. La bonne réponse est souvent : deux ou trois exercices dans l'ERP pour les besoins opérationnels, et l'intégralité de l'historique dans la plateforme de données, où il ne coûte presque rien et reste interrogeable. Nous proposons systématiquement ce découpage.

Et si nous devons revenir en arrière ?

Le plan de retour arrière fait partie du plan de bascule, pas d'une option. Concrètement : l'ancien système reste accessible en lecture pendant une période convenue, les imports sont rejouables à l'identique, et la décision de retour arrière a un critère écrit et une date limite. Une bascule sans critère de retour arrière est une bascule qu'on n'ose plus annuler.

La bascule

Un domaine à la fois, en parallèle

Chaque domaine bascule l'un après l'autre pendant que l'existant continue de servir. La période de recouvrement permet à vos équipes de comparer les deux plateformes sur leurs propres chiffres avant de décider de la suite.

Un domaine à la fois, jamais tout d'un coup

L'existant continue de servir pendant que chaque domaine bascule, ce qui laisse vos équipes comparer sur leurs propres chiffres.

La zone de recouvrement est le cœur de la méthode : c'est là que vos équipes confrontent les deux plateformes sur des données réelles. Le rythme de la suite se décide sur ce qu'elles constatent, pas sur un calendrier fixé d'avance.

Dites-nous d'où vous partez, et où vous allez.

Onze collaborateurs expertsSaint-Priest, près de Lyon

Deux heures avec un consultant, offertes. Nous regardons le système de départ, le système d'arrivée et les chiffres qui devront tomber juste, et nous vous disons ce que nous reprendrions, ce que nous laisserions, et où nous attendons des écarts.

Demander un atelier de cadrage

Atelier de cadrage · 2 h · offert