Une migration de données est avant tout une opération de tri. Ce qui se passe avant l’import décide de tout : chaque décision non prise se retrouve dans le nouvel outil sous forme d’anomalie.
Ce qu’est vraiment une migration et pourquoi ce n’est pas un import
Le mot « migration » est souvent utilisé comme synonyme d' »import ». C’est une confusion qui coûte cher, et elle est à l’origine d’une grande partie des projets qui finissent en crise. Un import, c’est l’action technique de faire entrer des données dans un système. Une migration, c’est l’ensemble du processus qui part de l’analyse de l’existant, passe par des décisions de gouvernance, traverse un nettoyage rigoureux, valide les données dans un environnement de test, et s’achève par une bascule maîtrisée vers le nouvel outil. Confondre les deux revient à croire qu’un déménagement consiste à porter des cartons. On peut porter des cartons sans jamais avoir décidé ce qu’on gardait, ce qu’on jetait et ce qu’on donnait. On s’en aperçoit le jour où on ouvre les cartons dans le nouvel appartement et qu’on ne sait plus où est ce dont on a besoin.
Trois notions structurent une migration sérieuse et méritent d’être distinguées dès le départ, avant même de toucher au premier fichier.
La reprise de données désigne la sélection, la transformation et le chargement des données de l’ancien système vers le nouveau. C’est le cœur du sujet technique, mais elle est précédée d’une phase de décision qui est souvent plus longue et plus délicate que l’opération technique elle-même. Qui décide de ce qu’on reprend ? Selon quel critère ? Qui valide le résultat ? Ces questions doivent trouver une réponse avant que quiconque ouvre un fichier.
La bascule est le moment précis où l’ancien système cesse d’être l’outil de référence et où le nouveau prend le relais. Elle peut être progressive ou franche. Une bascule progressive consiste à faire coexister les deux systèmes pendant une période définie, avec des règles strictes sur ce qui est saisi où et comment les écarts sont résorbés. Une bascule franche est plus simple à gérer sur le plan de la cohérence des données, mais elle exige que la migration soit parfaitement préparée, car il n’y a pas de filet. Le choix entre les deux dépend de la complexité de l’activité, du volume des données en cours et de la capacité des équipes à gérer la transition.
La période de double saisie est parfois inévitable. Elle survient quand la migration est longue, quand l’activité ne peut pas s’arrêter pendant la transition, ou quand certaines données dépendent de processus en cours qui ne peuvent pas être gelés. Cette période est dangereuse si elle n’est pas encadrée : chaque saisie effectuée dans l’un des deux systèmes sans être répercutée dans l’autre crée un écart. Il faut définir dès le départ qui saisit quoi, dans quel système, et comment on résorbe les écarts avant la bascule définitive. Une période de double saisie sans règle écrite n’est pas une période de transition, c’est une période de désordre organisé.
Ce qui distingue les migrations réussies des autres n’est pas la qualité de l’outil cible. C’est la qualité des décisions prises avant de toucher au premier fichier. Une migration rate rarement parce que l’outil ne sait pas importer. Elle rate parce que personne n’avait décidé ce qui faisait foi, parce qu’on a voulu tout reprendre sans se poser la question de la pertinence de chaque donnée, et parce que les contrôles ont été construits après la bascule au lieu d’être définis avant. Le meilleur moment pour ne pas reprendre une donnée est avant de l’importer. Une fois dans le nouveau système, chaque donnée inutile ou incorrecte est une anomalie à gérer.
Les cinq familles de données à traiter séparément
Toutes les données ne se migrent pas de la même façon et n’ont pas le même niveau de difficulté. Les traiter dans le même flux, au même moment, avec les mêmes règles, est une erreur fréquente qui génère des incohérences difficiles à démêler. Il faut les identifier, les ordonner, et comprendre précisément ce qui dépend de quoi avant de commencer. L’ordre n’est pas une question de préférence : il est imposé par les dépendances entre les entités. Voici les cinq grandes familles que l’on rencontre dans la majorité des migrations vers un outil de gestion d’activité.
Les tiers : clients et fournisseurs
Les tiers forment la fondation de toute migration. Clients, fournisseurs, contacts, prospects : ce sont les entités auxquelles tout le reste se rattache. Un document commercial ne peut exister sans tiers rattaché. Un projet ne peut être suivi sans client identifié. Une dépense ne peut être affectée sans fournisseur référencé. C’est pourquoi les tiers doivent être migrés en premier, avant toute autre famille de données, sans exception.
La difficulté propre aux tiers est leur qualité. Les bases de tiers accumulées sur plusieurs années contiennent presque toujours des doublons, des entrées partielles, des adresses obsolètes, des contacts qui ne travaillent plus dans l’entreprise, des clients dont le statut commercial n’a jamais été mis à jour. Avant toute migration, un travail de déduplication et de qualification est indispensable. Ce travail prend du temps, mais il conditionne la qualité de tout ce qui suit. Un tiers mal renseigné dans le nouveau système sera un tiers mal renseigné dans toutes les entités qui s’y rattachent.
Il faut également décider des champs à reprendre. Un ancien système peut stocker plusieurs dizaines de champs par tiers. Le nouveau système peut en accepter moins ou en structurer différemment. Quels champs abandonne-t-on ? Quels champs personnalisés crée-t-on pour préserver certaines informations métier ? Ces décisions doivent être prises par les utilisateurs métier, pas par les équipes techniques. Ce sont eux qui savent quelles informations sont réellement utilisées.
Le catalogue produits et services
Le catalogue vient en deuxième position, car les lignes de documents commerciaux s’y réfèrent. Si un devis cite un produit qui n’existe pas encore dans le catalogue du nouvel outil, la migration des devis échouera ou produira des lignes orphelines sans référence valide. L’ordre est donc impératif : catalogue après tiers, avant documents.
La difficulté propre au catalogue est sa cohérence interne. Les catalogues anciens souffrent de références dupliquées sous des libellés différents, de prix obsolètes jamais archivés, d’unités de mesure non standardisées, de catégories mal construites au fil des années. Une référence désignant une prestation de conseil peut avoir été créée sous cinq formes différentes selon la personne qui l’a saisie. Cette déduplication est souvent révélatrice d’une organisation informelle qui s’est construite sans règle de nommage.
Décider ce qu’on reprend dans le catalogue est aussi une occasion de le nettoyer durablement. On distingue trois catégories : les références actives que l’on reprend intégralement, les références archivées que l’on conserve pour garantir la cohérence des documents commerciaux historiques repris, et les références abandonnées que l’on ne reprend pas parce qu’elles n’ont aucun document associé dans le périmètre retenu.
Les documents commerciaux
Devis, bons de commande, factures, avoirs : les documents commerciaux sont la famille la plus volumineuse et la plus sensible. Ils dépendent des tiers et du catalogue, donc ils ne peuvent être migrés qu’après ces deux familles. Tenter de les migrer en parallèle expose à des erreurs de rattachement que l’on ne détectera pas immédiatement.
La difficulté propre aux documents commerciaux est leur multiplicité d’états. Un devis peut être brouillon, envoyé, accepté, refusé, transformé en commande. Une facture peut être en attente, partiellement payée, soldée, annulée, contestée. Ces états doivent être cartographiés entre l’ancien et le nouveau système. Il arrive fréquemment qu’ils ne correspondent pas exactement. Une facture « en litige » dans l’ancien système peut ne pas avoir d’équivalent nommé dans le nouveau. Que fait-on ? On ne peut pas ignorer la question, car cela concerne des montants réels dont le suivi a un impact opérationnel direct.
L’autre difficulté est la décision de périmètre temporel. Reprend-on toute l’histoire ou seulement les trois dernières années ? Reprend-on les documents soldés ou seulement les encours ? La réponse dépend des besoins métier et des obligations légales applicables, mais elle doit être prise avant de commencer, documentée et validée. Un ajustement de périmètre en cours de migration remet en cause tout le travail de cartographie et de nettoyage déjà effectué.
Les données comptables et les soldes
Les données comptables méritent une attention particulière car elles sont soumises à des obligations légales de conservation. Elles incluent les soldes clients et fournisseurs, les échéanciers de paiement, les lettres de créances, les balances et les journaux. Leur migration doit être coordonnée avec les équipes comptables et, selon le contexte, vérifiée par un expert-comptable.
La difficulté propre aux données comptables est leur vérifiabilité absolue. Un solde client dans le nouvel outil doit pouvoir être réconcilié exactement avec le solde dans l’ancien. Si les deux ne concordent pas, la migration n’est pas terminée, quelle que soit la pression calendaire. C’est ici que le contrôle de réconciliation est le plus critique, et c’est ici que les erreurs ont les conséquences les plus lourdes sur l’activité réelle de l’entreprise.
Une pratique fréquente consiste à ne migrer que les soldes d’ouverture à une date de reprise définie, et à conserver l’ancien système en lecture seule pour toute consultation de l’historique antérieur à cette date. C’est une approche raisonnable qui simplifie considérablement la migration sans appauvrir l’information disponible, à condition que la date de reprise soit choisie avec soin et que les utilisateurs soient informés de ce découpage.
Les pièces jointes et documents
Les pièces jointes viennent en dernier car elles dépendent de toutes les autres familles : elles sont rattachées à des tiers, à des documents, à des projets. Elles ne peuvent être associées à leurs entités parents qu’une fois que ces entités existent dans le nouveau système avec leurs identifiants définitifs. Tenter de migrer les pièces jointes avant les entités parents revient à coller des étiquettes sur des rayonnages vides.
La difficulté propre aux pièces jointes est leur volume et leur hétérogénéité. Un système utilisé depuis plusieurs années peut contenir plusieurs dizaines de gigaoctets de fichiers aux formats les plus variés. Il faut évaluer ce volume avant de décider s’il est raisonnable de tout migrer, de ne migrer que les pièces récentes, ou de ne pas migrer les pièces jointes dans le nouvel outil et de les conserver dans un espace de stockage structuré accessible en parallèle. Cette décision doit être prise avec les utilisateurs métier qui savent lesquelles de ces pièces sont consultées régulièrement.
La décision la plus importante : que reprendre et que laisser
La question « que reprend-on ? » est la plus importante de toute la migration. Elle est aussi la plus inconfortable, parce qu’elle oblige à prendre des décisions que personne n’a envie de prendre. Vouloir tout reprendre est une réaction naturelle et compréhensible. C’est aussi la première cause d’échec des migrations : on importe des données inutiles, on perd du temps à les nettoyer, on génère des écarts que personne ne comprend, et on arrive à la bascule avec un système encombré d’informations qui n’auraient jamais dû y entrer.
Une migration n’est pas un archivage. Son objectif n’est pas de préserver tout le passé dans le nouvel outil, mais de transférer ce qui est utile pour l’activité présente et future. Ce qui n’est plus utile n’a pas à être migré. Ce qui doit être conservé pour des raisons légales peut l’être dans l’ancien système maintenu en lecture seule, ou dans un export structuré stocké hors de l’outil actif et accessible à la demande.
Une méthode de tri efficace repose sur trois critères cumulatifs : l’ancienneté, l’activité et la valeur.
- L’ancienneté : à partir de quand une donnée est-elle trop ancienne pour mériter d’être dans le nouveau système actif ? La réponse dépend du secteur, des obligations légales et des habitudes de consultation réelles des équipes. Une règle interne définie collectivement vaut mieux qu’une décision prise dans l’urgence.
- L’activité : cette entité est-elle encore active ? Un client qui n’a pas passé de commande depuis cinq ans est-il un client actif ou un ancien client dont on conserve l’historique à part ? Un fournisseur dont le compte n’a jamais été utilisé doit-il être repris dans le nouvel outil ou simplement archivé ?
- La valeur : cette donnée a-t-elle une valeur pour l’activité future ? Un devis refusé il y a huit ans n’a probablement aucune valeur opérationnelle. Un contrat en cours d’exécution, en revanche, doit absolument être repris avec toutes ses pièces associées.
Le tableau suivant illustre, par famille de données, ce qu’on reprend dans le nouvel outil, ce qu’on archive hors outil et ce qu’on abandonne définitivement.
| Famille | On reprend dans le nouvel outil | On archive hors outil | On abandonne |
|---|---|---|---|
| Tiers clients | Clients actifs des 3 dernières années | Anciens clients inactifs avec solde nul | Doublons, entrées sans activité ni solde |
| Tiers fournisseurs | Fournisseurs avec contrat ou commande en cours | Fournisseurs inactifs avec historique factuel | Fournisseurs jamais utilisés |
| Catalogue | Références actives | Références archivées liées à des documents repris | Références obsolètes sans document associé |
| Documents commerciaux | Factures non soldées, contrats en cours | Documents soldés des 5 dernières années | Devis refusés, documents antérieurs au seuil retenu |
| Données comptables | Soldes d’ouverture à la date de reprise | Journaux et balances antérieurs à la date de reprise | Brouillons non validés, écritures d’annulation sans suite |
| Pièces jointes | Documents rattachés aux entités reprises, récents | Documents rattachés à des entités archivées | Fichiers temporaires, doublons, versions intermédiaires |
Une fois ces décisions prises, il faut les documenter dans un document de référence et les faire valider formellement par les responsables métier et, si nécessaire, par la direction. Une décision de périmètre non validée est une décision que quelqu’un contestera pendant la bascule, au pire moment possible. La validation formelle n’est pas de la bureaucratie : c’est la protection de toute l’équipe projet contre les remises en cause tardives.
Il faut également décider de la durée pendant laquelle l’ancien système restera accessible en lecture seule après la bascule. Cette durée doit être fixée à l’avance et respectée. Si on ne fixe pas de date limite, l’ancien système reste vivant indéfiniment, les utilisateurs continuent à s’y référer, et le nouveau système ne prend jamais véritablement le relais dans les habitudes de travail.
La cartographie des champs
La cartographie des champs est le travail de mise en correspondance entre les champs de l’ancien système et ceux du nouveau. C’est un travail fastidieux, souvent sous-estimé dans les plannings, qui révèle l’essentiel des problèmes bien avant que le premier fichier soit importé. C’est précisément pour cette raison qu’il faut le faire tôt, et non le traiter comme une formalité.
Il faut construire un tableau de correspondance qui liste, pour chaque champ de l’ancien système, son équivalent dans le nouveau. Ce tableau n’est pas un document purement technique. C’est un document de décision. Chaque ligne correspond à une question à trancher par les équipes métier. Qui décide que « STATUT_RELANCE » dans l’ancien système correspond à un champ personnalisé dans le nouveau ? Qui décide qu’on l’abandonne ? Ces décisions appartiennent aux utilisateurs, pas aux développeurs.
Voici un extrait illustratif d’un tableau de correspondance pour la famille « clients » :
| Champ source | Valeur exemple | Champ cible | Transformation nécessaire | Décision si pas d’équivalent |
|---|---|---|---|---|
| NOM_CLIENT | Durand SARL | nom | Aucune | – |
| CODE_CLIENT | C-00452 | ref_origine (champ personnalisé) | Conserver tel quel | Créer un champ personnalisé dédié |
| TEL_PRINCIPAL | 0612345678 | telephone | Reformater en +33612345678 | – |
| STATUT_RELANCE | EN COURS / SUSPENDU / SOLDÉ | Aucun équivalent direct | – | Créer un champ liste personnalisé |
| NOTES_INTERNES | Texte libre long | notes | Tronquer à 2 000 caractères si dépassé | – |
| SEGMENT_COMMERCIAL | Grand compte / PME / Micro | Aucun équivalent | – | Abandonner ou créer un tag |
| DATE_CREATION | 31/12/2020 | date_creation | Convertir en format YYYY-MM-DD | – |
Les champs sans équivalent dans le nouveau système sont les plus délicats à traiter. Trois options se présentent en général.
- Créer un champ personnalisé dans le nouveau système, à condition que cela n’alourdit pas inutilement l’interface pour les utilisateurs au quotidien. Un champ personnalisé créé pour la migration et jamais consulté ensuite est un champ qui encombre.
- Intégrer l’information dans un champ texte libre existant, avec un préfixe ou un format structuré pour rester lisible lors d’une consultation manuelle.
- Abandonner le champ si l’information n’a plus de valeur opérationnelle. Il ne faut pas créer un champ dans le nouveau système uniquement pour préserver une information que personne ne consulte.
Les listes de valeurs méritent une attention particulière. Si l’ancien système comporte un champ « type de client » avec des valeurs définies, et que le nouveau système propose un champ similaire avec des valeurs différentes, la correspondance n’est pas mécanique. Il faut décider, valeur par valeur, quelle correspondance appliquer. Cette décision doit être prise par quelqu’un qui connaît le métier et comprend la signification de chaque valeur dans le contexte de l’activité.
Les champs libres posent un problème différent : ils contiennent souvent des informations hétérogènes saisies de façon informelle au fil des années. Certains utilisateurs y ont stocké des numéros de téléphone secondaires, des références de contrats, des observations commerciales. Avant la migration, il faut décider si ces informations sont extraites et structurées dans des champs dédiés, ou si elles sont reprises telles quelles dans un champ notes en acceptant qu’elles ne seront pas filtrables.
Le nettoyage avant import
Le nettoyage des données est l’étape la plus ingrate et la plus chronophage de la migration. Elle précède obligatoirement l’import, sans exception. Faire le nettoyage après l’import ne simplifie rien : cela déplace le problème dans un système où les erreurs sont plus difficiles à corriger en masse, où elles peuvent déjà avoir causé des incohérences dans d’autres entités, et où les corrections manuelles de plusieurs personnes créent de nouvelles divergences.
La normalisation consiste à harmoniser les valeurs d’un même champ. Des noms de ville écrits sous différentes formes doivent être ramenés à une forme unique. Des civilités exprimées de façons variées doivent être standardisées. Des numéros de téléphone sans indicatif national doivent être reformatés selon une convention définie. Ces opérations semblent triviales mais elles sont indispensables pour garantir que le nouvel outil puisse filtrer, trier et regrouper les données correctement.
La question des doublons mérite une attention spécifique et une méthode rigoureuse qui constitue un sujet à part entière. Pour la migration, il faut au minimum identifier les doublons évidents avant d’importer, car un doublon importé devient deux enregistrements distincts dans le nouveau système, chacun avec son propre historique partiel.
Les champs obligatoires manquants sont une cause fréquente de rejet à l’import. Si le nouveau système exige un email pour chaque contact, et qu’une partie des contacts n’en ont pas dans l’ancien système, l’import rejettera ces lignes sans avertissement préalable. Il faut identifier ces cas avant l’import, mesurer leur volume et décider quoi faire pour chacun : renseigner une valeur par défaut clairement identifiable, exclure les lignes concernées du périmètre de migration, ou les compléter manuellement avant l’import.
Les formats de date et de montant varient selon les systèmes et les paramètres régionaux. Une date au format « 31/12/2022 » dans l’ancien système peut être interprétée différemment ou rejetée si le nouveau système attend un format ISO. Les montants avec virgule comme séparateur décimal peuvent poser des problèmes dans des systèmes qui attendent un point. Ces conversions doivent être systématiques, documentées dans la cartographie des champs, et vérifiées sur un échantillon représentatif avant l’import complet.
L’encodage des caractères est un problème discret mais redoutable. Des caractères accentués mal encodés peuvent traverser toute la migration sans être détectés si on ne vérifie pas explicitement un échantillon de données contenant des accents et des caractères spéciaux. Le format d’encodage cible doit être défini dès le début et appliqué à tous les fichiers sources lors de leur extraction.
Les identifiants : conserver la trace de l’origine
Chaque entité dans l’ancien système possède un identifiant unique : un numéro de client, un numéro de facture, un code produit. Ces identifiants ne doivent pas disparaître lors de la migration. Ils doivent être conservés dans le nouvel outil, dans un champ dédié, clairement nommé pour que tous les utilisateurs comprennent sa signification. Un champ « référence d’origine » ou « identifiant source » suffit.
La raison est simple et pratique. Lors de la migration à blanc, lors des contrôles de réconciliation, ou lors d’une anomalie découverte des semaines après la bascule, il faut pouvoir faire le lien entre un enregistrement dans le nouvel outil et son équivalent dans l’ancien. Sans identifiant d’origine, ce rapprochement devient une opération manuelle incertaine, fondée sur des correspondances approximatives par nom ou par date qui peuvent conduire à confondre deux entités similaires.
Conserver l’identifiant d’origine permet également de traiter les migrations en plusieurs vagues sans créer de doublons. Si une première vague concerne les clients actifs, et qu’une seconde vague est prévue pour les clients dormants, l’identifiant d’origine garantit qu’on ne créera pas un deuxième enregistrement pour un client déjà migré lors de la première vague.
En cas de retour arrière partiel, l’identifiant d’origine permet de savoir exactement quelles entités ont déjà été reprises et lesquelles ne l’ont pas encore été. Sans cela, tout retour arrière devient une opération à l’aveugle où on ne sait plus ce qui a été fait ni dans quel état se trouve le système.
Il faut également conserver la table de correspondance entre les identifiants d’origine et les identifiants générés dans le nouveau système, dans un fichier externe versionné. Ce fichier est précieux en cas de litige ou d’audit, car il permet de reconstituer toute la chaîne de traçabilité d’un enregistrement depuis sa création dans l’ancien système jusqu’à son état actuel dans le nouveau.
La migration à blanc
La migration à blanc est une répétition générale complète. Elle consiste à exécuter le processus d’import dans son intégralité dans un environnement de test, sur des données réelles ou aussi représentatives que possible, sans jamais toucher à l’environnement de production. Elle ne se substitue pas aux contrôles de réconciliation : elle les précède et les prépare.
Son rôle est multiple. Elle permet de détecter les rejets techniques : lignes rejetées à cause d’un format incorrect, d’une valeur manquante ou d’une contrainte d’intégrité non respectée. Elle permet de vérifier la cohérence des données importées : les totaux correspondent-ils, les rattachements entre entités sont-ils corrects, les états sont-ils bien transposés ? Elle permet enfin de mesurer la durée réelle de l’opération d’import, ce qui est indispensable pour planifier le gel des saisies le jour de la bascule.
Il faut faire la migration à blanc au moins deux fois. La première fois révèle les problèmes : des rejets non anticipés, des champs mal mappés, des écarts de réconciliation inexpliqués. Après analyse et correction de chaque problème identifié, la deuxième migration à blanc valide que les corrections apportées ont bien résolu ces problèmes sans en créer de nouveaux. Si la deuxième migration à blanc révèle de nouveaux problèmes, une troisième est nécessaire. La règle est simple : on ne bascule que sur une migration à blanc propre, c’est-à-dire sans rejet inexpliqué et sans écart de réconciliation non résolu.
La migration à blanc doit être réalisée avec les données les plus récentes disponibles, et non avec un extrait figé depuis plusieurs semaines. Plus les données de test sont proches des données réelles du jour de la bascule, plus les résultats sont représentatifs et plus les surprises du jour J sont limitées.
Les utilisateurs métier doivent participer à la validation de la migration à blanc. Ils sont les seuls à pouvoir confirmer que les données importées correspondent à ce qu’ils attendent dans leur contexte de travail. Une migration à blanc validée uniquement par les équipes techniques est une migration à blanc incomplète. Ce qui semble correct techniquement peut être fonctionnellement inexploitable.
Le contrôle de réconciliation
Le contrôle de réconciliation est l’étape qui fait le plus souvent la différence entre une migration réussie et une migration qui finit en crise plusieurs semaines après la bascule. C’est aussi l’étape la plus souvent escamotée, parce qu’elle demande un travail de préparation en amont qui ne semble pas urgent quand on est dans la phase d’import et que les délais commencent à presser.
Le principe est le suivant : avant la bascule, on définit un jeu de contrôles chiffrés. Ces contrôles sont joués une première fois sur les données sources, et leurs résultats sont consignés dans un document de référence. Après l’import dans le système cible, les mêmes contrôles sont joués à l’identique sur les données importées. On compare les résultats ligne par ligne. Tout écart doit être expliqué et documenté. Un écart inexpliqué interdit la bascule. On ne le contourne pas, on ne l’accepte pas « en attendant de voir », on l’investigue jusqu’à en trouver la cause.
Les contrôles à définir couvrent au minimum cinq dimensions complémentaires :
- Le nombre d’enregistrements par entité : combien de clients, de fournisseurs, de références catalogue, de factures dans la source, et combien dans la cible. Un écart de comptage est le signal le plus direct qu’une entité a été perdue ou dupliquée lors de l’import.
- La somme des montants par entité et par année : la somme des montants facturés sur une période donnée doit être strictement identique dans la source et dans la cible. Un écart de montant peut signaler une ligne rejetée, un problème de conversion de devise ou un arrondi incorrect.
- Le nombre de documents rattachés à chaque client : un client qui avait dix factures dans l’ancien système doit en avoir dix dans le nouveau, ni plus ni moins. Un client avec neuf factures signale un document perdu. Un client avec onze factures signale un document dupliqué.
- Le nombre de valeurs vides sur les champs obligatoires : si le nouveau système a rendu certains champs obligatoires, il faut mesurer combien d’enregistrements les ont effectivement renseignés après import. Des valeurs vides sur des champs obligatoires signalent soit un problème de mapping, soit des données sources incomplètes non traitées lors du nettoyage.
- Un échantillon nominatif vérifié à la main : on tire un échantillon aléatoire représentatif et on vérifie, champ par champ, que les données sont correctement reprises. Cette vérification manuelle détecte des problèmes invisibles aux contrôles automatiques, comme des caractères corrompus, des rattachements incorrects ou des valeurs transposées entre deux champs.
Voici un exemple fictif de tableau de réconciliation tel qu’on le remplit avant et après l’import :
| Contrôle | Source | Cible | Écart | Verdict |
|---|---|---|---|---|
| Nombre de clients actifs | 1 243 | 1 243 | 0 | OK |
| Nombre de fournisseurs | 87 | 87 | 0 | OK |
| Nombre de références catalogue actives | 312 | 312 | 0 | OK |
| Nombre de factures (2023) | 3 412 | 3 412 | 0 | OK |
| Nombre de factures (2024) | 4 108 | 4 106 | -2 | ÉCART – BLOQUEANT |
| Somme des montants HT facturés (2024) | 892 340,00 | 891 220,00 | -1 120,00 | ÉCART – BLOQUEANT |
| Valeurs vides sur champ email contact | – | 34 | – | À COMPLÉTER AVANT BASCULE |
| Échantillon nominatif (20 clients) | 20/20 corrects | 19/20 corrects | 1 erreur détectée | ÉCART – À INVESTIGUER |
Dans cet exemple fictif, deux factures de 2024 manquent dans la cible et la somme des montants présente un écart de 1 120 euros. Comment remonte-t-on à la cause ?
La première étape consiste à identifier précisément les enregistrements manquants. On extrait la liste complète des identifiants de factures 2024 depuis la source, et la liste équivalente depuis la cible, puis on recherche les identifiants présents dans la source mais absents de la cible. Dans cet exemple fictif, deux identifiants ressortent de cette comparaison.
La deuxième étape est d’analyser pourquoi ces deux factures ont été rejetées. On consulte les journaux d’import, qui doivent consigner chaque ligne rejetée avec sa cause technique. Dans cet exemple fictif, la première facture a été rejetée parce que le client rattaché avait été identifié comme doublon lors du nettoyage et supprimé du fichier source, entraînant la suppression en cascade de ses factures associées. La deuxième facture a été rejetée parce que son montant était exprimé dans une devise pour laquelle le mapping de conversion n’avait pas été défini.
La troisième étape est de corriger : réintégrer la première facture en la rattachant au client conservé lors de la déduplication, corriger le mapping de devise pour la seconde, relancer la migration à blanc sur le périmètre concerné, et rejouer les contrôles de réconciliation pour vérifier que les écarts ont disparu.
Aucune de ces étapes n’est optionnelle et aucune ne peut être différée à « après la bascule ». Un écart non expliqué interdit la bascule. Ce n’est pas une règle de prudence excessive : c’est la garantie minimale que le nouveau système reflète fidèlement l’état réel de l’activité. Basculer avec un écart inexpliqué, c’est piloter à partir de données dont on sait qu’elles sont incomplètes, sans savoir dans quelle mesure.
Le jour de la bascule
Le jour de la bascule est le moment où l’ancien système cesse d’être la référence. C’est un événement qui se prépare avec le même soin qu’une opération chirurgicale : on planifie chaque geste dans l’ordre, on sait exactement ce qu’on fait si quelque chose ne se passe pas comme prévu, et on dispose d’un plan de retour arrière écrit et testé avant même de commencer.
La préparation commence plusieurs jours avant le jour J. On communique à toutes les équipes concernées la date, l’heure de début, la durée estimée du gel des saisies et ce qu’elles doivent faire et éviter de faire pendant cette période. On identifie un responsable de migration qui est le seul à avoir le pouvoir de décider d’avancer ou de déclencher le retour arrière. On prépare une liste de vérification exhaustive qui sera cochée étape par étape, avec un responsable nommé pour chaque étape.
Le gel des saisies est la première décision opérationnelle du jour. À partir d’un moment précis et annoncé à l’avance, personne ne saisit plus rien dans l’ancien système. Cette règle doit être absolue et communiquée sans ambiguïté. Une saisie effectuée dans l’ancien système après le début de l’import final sera perdue ou créera un écart que les contrôles ne détecteront pas automatiquement. La durée du gel doit être estimée de façon réaliste lors des migrations à blanc, pas calculée en optimiste le matin du jour J.
L’ordre des opérations suit la même logique que l’ordre des familles de données : tiers en premier, catalogue ensuite, documents commerciaux, données comptables, pièces jointes. On ne passe pas à l’étape suivante sans avoir validé l’étape précédente avec les contrôles de réconciliation correspondants. Chaque étape validée est consignée dans le journal de bascule avec l’heure et le nom de la personne qui a validé.
Le point de non-retour est le moment où l’import est terminé, les contrôles de réconciliation sont satisfaisants et le responsable de migration décide formellement que la bascule est validée. Avant ce point, on peut encore revenir en arrière de façon relativement propre. Après, le retour arrière devient une opération coûteuse qui perturbe l’activité. Ce point doit être explicitement déclaré, documenté avec l’heure et la signature du responsable, et communiqué à toutes les équipes.
Le plan de retour arrière doit être écrit et testé avant le jour de la bascule. Un plan de retour arrière non écrit n’existe pas. Il ne suffit pas de savoir « en théorie » qu’on pourrait revenir en arrière. Il faut avoir documenté chaque étape du retour, avoir vérifié que l’ancien système est resté dans l’état attendu et n’a pas été modifié pendant l’opération, et avoir testé le retour arrière dans un environnement de test lors d’une migration à blanc. Si quelqu’un affirme qu’on peut revenir en arrière facilement sans pouvoir montrer le document qui décrit comment, c’est un signal d’alarme à prendre au sérieux.
Il faut également définir un délai maximum pour la bascule. Si à une heure précise les contrôles ne sont pas satisfaisants ou si un problème bloquant est identifié, on déclenche le retour arrière sans discussion ni attente supplémentaire. Repousser indéfiniment la décision dans l’espoir que le prochain contrôle sera bon est une erreur classique qui transforme une bascule ratée en catastrophe gérée dans la précipitation.
Après la bascule : la période de vigilance
La bascule n’est pas la fin de la migration. Elle en est l’aboutissement opérationnel, mais les premiers jours et les premières semaines qui suivent sont une période de vigilance active pendant laquelle des anomalies peuvent apparaître que les contrôles de réconciliation n’avaient pas détectées, parce qu’elles ne sont visibles qu’à l’utilisation réelle.
Cette période doit être organisée et encadrée. Il faut désigner, pour chaque domaine fonctionnel concerné par la migration, un référent qui vérifie quotidiennement que les données et les processus se comportent comme attendu. Le responsable commercial vérifie que ses clients, ses contacts et ses devis sont bien là et correctement rattachés. La comptabilité vérifie que les soldes correspondent aux attentes et que les nouveaux documents sont correctement créés. Le service client vérifie que les historiques d’échanges et les tickets sont accessibles.
Les anomalies découvertes après la bascule doivent être traitées selon un processus défini avant la bascule. Pas de correction sauvage dans le nouveau système sans validation. Chaque anomalie est consignée dans un registre, qualifiée selon sa nature (erreur de migration ou erreur présente dans les données source ?), priorisée selon son impact opérationnel et corrigée selon une procédure validée par le responsable de migration. Sans ce processus, les corrections appliquées en urgence par différentes personnes créent de nouvelles incohérences parfois plus graves que les anomalies initiales.
La durée de la période de vigilance ne peut pas être inférieure à un cycle complet d’activité. Si l’entreprise édite des factures mensuellement, la période de vigilance doit couvrir au moins un mois complet. Si elle prépare des rapports trimestriels, trois mois sont nécessaires pour valider que la migration n’a créé aucune anomalie sur l’ensemble de ce cycle. Raccourcir cette période pour des raisons de confort organisationnel est une économie risquée.
À l’issue de la période de vigilance, une fois les anomalies traitées et les équipes stabilisées sur le nouvel outil, l’ancien système peut être basculé en lecture seule à la date décidée avant la migration. Cette date est celle qui a été annoncée, pas une date repoussée parce que certains utilisateurs s’y réfèrent encore par habitude.
Les pièces jointes et l’historique : ce qu’on sous-estime toujours
Les pièces jointes et l’historique des échanges sont systématiquement sous-estimés dans la planification d’une migration. Ils arrivent en dernier dans l’ordre de traitement des familles de données, et lorsqu’on atteint cette étape, l’équipe est souvent fatiguée, les délais ont déjà glissé et la tentation est forte de les traiter « après la bascule » ou « quand on aura le temps ». Le problème est que ce moment arrive rarement dans les semaines qui suivent la bascule, et six mois plus tard personne ne sait plus où sont les pièces jointes de l’exercice précédent ni comment les retrouver.
Plusieurs options sont possibles selon le volume, la valeur opérationnelle des pièces et les capacités du nouveau système.
- Migration complète dans le nouvel outil : toutes les pièces jointes sont transférées et rattachées à leurs entités parents. C’est l’option la plus propre sur le plan de la centralisation, mais aussi la plus longue à exécuter et la plus exigeante en termes de vérification. Elle est réaliste si le volume est raisonnable.
- Migration partielle par date : seules les pièces jointes des dernières années sont migrées dans le nouvel outil. Les pièces plus anciennes restent accessibles dans l’ancien système en lecture seule ou dans un espace de stockage partagé accessible en dehors du nouvel outil.
- Archivage structuré hors outil : les pièces jointes ne sont pas migrées dans le nouvel outil mais organisées dans un système de fichiers structuré par client, par année et par type de document, avec une convention de nommage claire et documentée. Elles restent consultables sans être dans le nouvel outil. Cette option est pragmatique quand le volume est très important.
- Indexation sélective : seules les pièces jointes les plus fréquemment consultées sont migrées. Le critère de sélection peut être basé sur la date de dernière consultation dans l’ancien système si cette information est disponible.
Quelle que soit l’option retenue, elle doit être décidée et documentée avant la bascule, et communiquée clairement aux utilisateurs. Une réponse précise sur l’emplacement des pièces jointes antérieures est une réponse satisfaisante. L’absence de réponse ne l’est pas.
L’historique des échanges, qu’il s’agisse d’emails archivés, de notes d’appels ou de comptes-rendus de réunions, pose un problème similaire. Il est rarement migré dans sa totalité et ce n’est pas nécessairement un problème, à condition que les utilisateurs sachent où trouver cet historique et qu’un accès en lecture seule soit maintenu pendant la durée décidée.
Ce qu’il ne faut pas faire
Certaines erreurs reviennent avec une régularité remarquable dans les projets de migration, indépendamment de la taille de l’entreprise ou de la complexité des données. Les reconnaître avant de les commettre est la forme la plus efficace de préparation.
- Migrer et changer les processus en même temps. Une migration n’est pas le bon moment pour réorganiser les équipes, renommer les statuts de vente, revoir la nomenclature des produits ou changer la façon dont on classe les clients. Chaque changement simultané est une source de confusion supplémentaire qui empêche de distinguer les anomalies dues à la migration de celles dues aux nouveaux processus. On migre d’abord, on optimise les processus ensuite, une fois que tout le monde est stabilisé sur le nouvel outil.
- Importer sans jeu de contrôle défini. Si on ne sait pas ce qu’on vérifie, on ne peut pas savoir si l’import est bon. Un import qui « semble correct » n’est pas un import validé. Les contrôles doivent être chiffrés, documentés et rejoués à l’identique sur la source et sur la cible. La validation subjective par un utilisateur qui « jette un œil » n’est pas un contrôle de réconciliation.
- Basculer un vendredi soir. Une bascule doit se faire en début de semaine, quand les équipes sont disponibles, reposées et en mesure de traiter les problèmes qui apparaissent dans les premières heures. Une bascule du vendredi soir laisse deux jours sans équipe opérationnelle pour gérer les anomalies, et les utilisateurs arrivent le lundi matin face à un système qu’ils ne comprennent pas encore, sans support disponible.
- Faire confiance à un import qui ne remonte aucune erreur. Un import sans aucune erreur n’est pas nécessairement un import réussi : c’est parfois un import dont les contrôles de validation ne fonctionnent pas, ou un import qui a silencieusement ignoré des lignes sans les consigner dans un journal d’erreurs. Il faut toujours vérifier que le système de validation est actif, qu’il a été sollicité pendant l’import et que le journal d’erreurs est exploitable.
- Supprimer l’ancien système trop tôt. L’ancien système est le filet de sécurité pendant toute la période de vigilance. Il ne faut le fermer qu’une fois cette période terminée, les anomalies traitées et la durée de conservation définie atteinte. Supprimer l’ancien système dès la bascule ou dans les jours qui suivent, c’est retirer le seul moyen de vérifier l’origine d’une anomalie découverte tardivement.
- Laisser chacun corriger les données après coup sans règle. Après la bascule, la tentation est forte pour chaque utilisateur de corriger directement les données qui lui semblent incorrectes, sans en référer à personne. Sans règle et sans traçabilité, ces corrections individuelles créent rapidement de nouvelles incohérences, parfois plus graves que les anomalies initiales, et rendent toute investigation ultérieure impossible.
Une migration se prépare dans l’ancien outil, pas dans le nouveau
Djaboo centralise les clients avec leurs contacts, leurs devis, leurs factures, leurs projets, leurs dépenses et leurs tickets, tous rattachés au même dossier client. Des champs personnalisés peuvent être ajoutés sur les fiches clients et sur d’autres entités, notamment pour conserver un identifiant d’origine issu de l’ancien système, ce qui facilite les contrôles de réconciliation et les investigations post-bascule. Les dépenses acceptent un import depuis un fichier structuré. Les données saisies dans Djaboo restent exportables à tout moment.
La préparation du fichier d’import, le nettoyage des données, la cartographie des champs, les décisions de périmètre et les contrôles de réconciliation restent à la charge de l’entreprise. Djaboo est l’outil cible qui reçoit les données préparées : la migration elle-même, au sens de tout le travail qui précède l’import, appartient à ceux qui connaissent les données.
Questions fréquentes
Quelle est la différence entre une migration et un import ?
Un import est l’opération technique consistant à charger des données dans un système à partir d’un fichier. Une migration est l’ensemble du processus qui précède et entoure cet import : analyse de l’existant, décision sur le périmètre des données à reprendre, nettoyage, cartographie des champs, migrations à blanc, contrôles de réconciliation et bascule planifiée. L’import est une étape de la migration, pas la migration elle-même. Traiter les deux comme synonymes conduit à sauter toutes les étapes préparatoires, ce qui produit des données incorrectes, incomplètes ou incohérentes dans le nouvel outil dès les premiers jours d’utilisation.
Dans quel ordre doit-on migrer les données ?
L’ordre est imposé par les dépendances entre les familles de données, et il n’est pas négociable. Les tiers (clients et fournisseurs) doivent être migrés en premier, car tout le reste y est rattaché. Le catalogue produits et services vient ensuite, car les lignes de documents commerciaux s’y réfèrent. Les documents commerciaux (devis, factures, avoirs) ne peuvent être migrés qu’une fois les tiers et le catalogue en place dans le nouvel outil. Les données comptables et les soldes suivent. Les pièces jointes viennent en dernier, une fois que les entités parents auxquelles elles doivent être rattachées existent dans le nouveau système avec leurs identifiants définitifs.
Combien d’années d’historique faut-il reprendre ?
Il n’existe pas de règle universelle applicable à toutes les activités. La réponse dépend de trois facteurs combinés : les obligations légales de conservation applicables à l’activité concernée, la fréquence réelle à laquelle les utilisateurs consultent des données anciennes dans leur travail quotidien, et le volume que représente cet historique. Une approche pragmatique consiste à reprendre les données actives et les encours dans le nouvel outil, à archiver les données soldées dans un périmètre glissant défini à l’avance, et à conserver l’accès en lecture seule à l’ancien système pour l’historique antérieur. L’essentiel est que cette décision soit prise et documentée avant la migration, validée par les responsables métier, et non ajustée au fil de l’eau selon les demandes individuelles.
Que faire si un écart de réconciliation n’est pas expliqué ?
Un écart non expliqué interdit la bascule, sans exception ni aménagement. Ce n’est pas une position de prudence excessive : c’est la garantie minimale que le nouveau système reflète fidèlement l’état réel des données. Un écart de réconciliation non expliqué signifie qu’on ne comprend pas ce qui s’est passé lors de l’import, et qu’on ne peut pas garantir que les données sont complètes et correctes. La procédure est invariable : investiguer jusqu’à identifier la cause, corriger le problème à la source, relancer la migration à blanc sur le périmètre concerné, et rejouer les contrôles pour confirmer que l’écart a disparu. Passer outre un écart inexpliqué en se disant qu’on « règlera ça après la bascule » revient à piloter une activité sur des données dont on sait qu’elles sont défectueuses.
Peut-on migrer les données sans interrompre l’activité ?
Une migration sans interruption totale de l’activité est possible, mais elle exige une organisation rigoureuse et des règles explicites. Elle repose sur un gel des saisies aussi court que possible le jour de la bascule, délai estimé lors des migrations à blanc, et sur une période de double saisie strictement encadrée si elle est inévitable. Pendant la double saisie, les règles doivent être claires et écrites : qui saisit quoi, dans quel système, à quelle fréquence les deux systèmes sont réconciliés, et qui est responsable de la cohérence finale. Sans ces règles écrites et respectées, la double saisie produit des incohérences qui compliquent considérablement la bascule finale.
Faut-il nettoyer les données avant ou après l’import ?
Avant, sans exception. Nettoyer les données après l’import revient à effectuer une opération délicate sur un système qui est déjà en cours d’utilisation, où chaque correction peut interférer avec les données saisies depuis la bascule, où les corrections en masse sont plus complexes à réaliser et où on perd la traçabilité directe entre les données source et les données importées. Le nettoyage avant import est plus long à organiser, mais il est infiniment plus sûr. Un nettoyage réalisé sur le fichier source, avant tout chargement, laisse l’environnement de production intact et permet de relancer l’import autant de fois que nécessaire jusqu’à obtenir un résultat propre.
Pourquoi faut-il conserver l’identifiant d’origine dans le nouvel outil ?
L’identifiant d’origine est le lien direct entre chaque enregistrement du nouveau système et son équivalent dans l’ancien. Il est indispensable pour mener les contrôles de réconciliation avec précision, pour investiguer les anomalies détectées après la bascule, pour gérer les migrations en plusieurs vagues sans créer de doublons et pour répondre à d’éventuelles questions d’audit ou de litige en reconstituant la chaîne de traçabilité complète d’un enregistrement. Sans cet identifiant conservé dans un champ dédié, tout rapprochement entre les deux systèmes devient une opération manuelle approximative basée sur des correspondances par nom ou par date qui peuvent conduire à confondre deux entités similaires.
Combien de fois faut-il faire la migration à blanc ?
Au moins deux fois, et autant de fois que nécessaire jusqu’à obtenir une migration à blanc propre. La première migration à blanc révèle les problèmes : rejets techniques, champs mal mappés, écarts de réconciliation, encodages incorrects. Après analyse et correction de chaque problème identifié, la deuxième migration à blanc valide que les corrections ont bien résolu les problèmes identifiés sans en introduire de nouveaux. Si la deuxième migration à blanc révèle de nouveaux écarts, une troisième est nécessaire. La règle de base est qu’on ne bascule que sur une migration à blanc propre, validée à la fois par les équipes techniques qui vérifient l’absence de rejet et par les utilisateurs métier qui confirment que les données correspondent à leurs attentes.
Quand peut-on supprimer l’ancien système ?
Pas avant la fin de la période de vigilance décidée avant la bascule, et pas avant d’avoir vérifié que toutes les anomalies découvertes pendant cette période ont été traitées. La durée de maintien de l’accès en lecture seule à l’ancien système doit être décidée et annoncée avant la migration, selon les obligations légales et les besoins réels de consultation des équipes. Supprimer l’ancien système trop tôt est l’une des erreurs les plus difficiles à rattraper : si une anomalie est découverte après sa suppression, les données source ne sont plus accessibles pour investiguer l’origine du problème, et il peut être impossible de déterminer si l’anomalie vient de la migration ou des données elles-mêmes.
Que faire si des anomalies sont découvertes plusieurs semaines après la bascule ?
Les anomalies tardives sont inévitables dans toute migration d’un périmètre significatif. Certaines ne sont visibles qu’à l’occasion d’un processus spécifique qui n’a pas eu lieu pendant la période de vigilance initiale. La préparation consiste à avoir défini avant la bascule un processus de traitement des anomalies : une procédure de signalement accessible à tous les utilisateurs, un responsable qui qualifie et priorise chaque cas, et une règle explicite interdisant les corrections non supervisées. Chaque anomalie doit être qualifiée selon son origine : erreur de migration ou erreur présente dans les données source avant la migration ? La correction à apporter n’est pas la même selon le cas. L’ancien système maintenu en lecture seule est précieux dans cette phase, car il permet de comparer les données dans les deux systèmes et d’identifier avec certitude l’origine de chaque anomalie.
