Reprise de données : le chantier que tout le monde sous-estime
Vincent
Co-fondateur, direction technique
En bref
Comment réussir la reprise de données lors du remplacement d'une application ?
En la traitant comme un projet à part entière, avec son propre planning et ses propres critères de réussite. La difficulté n'est jamais technique : elle vient de ce que les données existantes ne respectent pas les règles que le nouveau système impose. La méthode qui fonctionne consiste à faire une reprise à blanc très tôt, à mesurer le taux de rejet, à décider avec le métier quoi faire des cas non conformes, et à répéter l'opération jusqu'à ce qu'elle soit fiable et chronométrée.
Sur les projets de remplacement d’application, la reprise de données est la ligne la plus souvent sous-estimée du chiffrage. Je l’ai vue représenter 30 % de la charge totale sur un projet où elle avait été budgétée à 5 %.
Ce n’est pas un problème de compétence. C’est que la difficulté n’est pas là où on la cherche.
Ce qui est difficile, et ce qui ne l’est pas
Déplacer des lignes d’une base à une autre est simple. N’importe quel développeur écrit ce programme en une journée.
Ce qui est difficile, c’est que les données existantes ne respectent pas les règles du nouveau système. Et elles ne les respectent pas parce que l’ancien système ne les imposait pas.
Quelques exemples que je rencontre à chaque fois. Des dates de fin antérieures à la date de début, parce que rien ne l’empêchait. Des adresses électroniques contenant deux adresses séparées par une barre oblique, parce qu’il n’y avait qu’un seul champ. Des clients en double, avec des orthographes différentes, chacun portant une partie de l’historique. Un champ « commentaire » qui contient en réalité une information structurée que quelqu’un a décidé d’y mettre en 2016.
Aucun de ces cas n’est un bug. Ce sont des adaptations que les utilisateurs ont inventées pour faire fonctionner un outil qui ne prévoyait pas leur besoin. Elles portent souvent de l’information métier réelle — et c’est précisément ce qui interdit de les jeter.
La reprise à blanc, très tôt
La seule méthode qui fonctionne, et elle tient en une idée : faire tourner la reprise avant d’avoir fini de développer l’application.
Concrètement, dès que le modèle de données du nouveau système est stabilisé — pas les écrans, le modèle — on écrit une première version des programmes de reprise et on les exécute sur une copie complète de la production.
Cette première exécution échoue massivement, et c’est l’objectif. Elle produit le chiffre le plus important du projet : le taux de rejet, ligne par ligne, avec le motif.
J’ai vu des premières reprises rejeter 40 % des enregistrements. Découvrir cela quatre mois avant la mise en service laisse le temps d’agir. Le découvrir la semaine du basculement transforme le projet en crise.
Décider quoi faire des rejets
C’est le cœur du travail, et ce n’est pas une décision technique.
Pour chaque motif de rejet, quatre options, et le métier tranche :
Corriger à la source. L’ancien système reste en service quelques semaines ; les utilisateurs corrigent les cas signalés au fil de l’eau. C’est la meilleure option quand le volume est raisonnable et que les données sont utiles.
Corriger automatiquement, avec une règle écrite. « Si la date de fin précède la date de début, on inverse. » Cette règle doit être validée et tracée, parce que quelqu’un la contestera un jour.
Reprendre en dégradé. L’enregistrement passe, avec un champ vide et un marqueur signalant qu’il est incomplet. Utile pour l’historique, dont on veut la trace sans en exiger la perfection.
Ne pas reprendre. Les prospects sans activité depuis huit ans, les brouillons jamais validés. C’est une décision légitime, à condition d’être prise explicitement et de conserver une archive consultable ailleurs.
Ce dernier point est important : ne pas reprendre ne veut pas dire supprimer. Une extraction figée, stockée et consultable, coûte presque rien et évite une conversation très désagréable deux ans plus tard.
Photo : domaine public (CC0).
Répéter, et chronométrer
Une reprise n’est pas fiable parce qu’elle a marché une fois. Elle l’est quand elle a marché plusieurs fois de suite, avec le même résultat.
Ce que nous faisons : rejouer la reprise complète toutes les deux semaines jusqu’à la mise en service, sur une copie fraîche de la production. Chaque exécution produit deux chiffres — le taux de rejet et la durée totale.
La durée est capitale et souvent oubliée. Une reprise qui prend quatorze heures impose une fenêtre de bascule d’un week-end entier, avec tout ce que cela suppose d’organisation. On préfère le savoir deux mois avant, quand il est encore possible d’optimiser ou de découper l’opération.
À la fin, le déroulé de la bascule est écrit minute par minute, et il a été répété. Le jour J n’est plus une inconnue, c’est une répétition de plus.
Photo : domaine public (CC0).
Comment vérifier que la reprise est juste
Une reprise sans erreur n’est pas une reprise correcte. Elle peut avoir tout transféré, et mal.
Trois contrôles, systématiquement.
Les totaux de contrôle. Nombre d’enregistrements par type, sommes des montants, nombre de relations. Ces chiffres doivent correspondre des deux côtés, à l’unité près, et les écarts doivent s’expliquer par les rejets décidés.
Un échantillon vérifié à la main. Une trentaine de dossiers, choisis par le métier, dont certains volontairement tordus. Quelqu’un ouvre les deux systèmes côte à côte et compare. C’est fastidieux, et c’est ce qui trouve les erreurs que les totaux ne voient pas — une valeur décalée d’une colonne, une devise mal interprétée.
Un contrôle sur les cas limites. Le plus ancien enregistrement, le plus gros, celui avec le plus de pièces jointes, celui avec des caractères accentués ou des emojis. Ces cas trouvent les problèmes d’encodage et de format, qui sont invisibles sur des données moyennes.
Le sujet qu’on découvre trop tard : les fichiers
Les documents joints — contrats signés, photos, pièces comptables — sont presque toujours traités en dernier, et ils réservent trois surprises.
Le volume, d’abord : plusieurs centaines de gigaoctets sont courants, et leur transfert prend un temps qui ne se compresse pas.
Les noms de fichiers, ensuite : accents, espaces, caractères interdits sur le système cible, doublons. Le nettoyage est mécanique mais doit être décidé.
Le lien avec les enregistrements, enfin : si un fichier est rattaché par un chemin sur un disque partagé plutôt que par une référence en base, la correspondance doit être reconstruite — et elle est parfois partiellement perdue.
Je conseille de traiter les fichiers comme un chantier distinct, avec sa propre première exécution à blanc, aussi tôt que les données structurées.
Ce que je fais figurer au planning
Une reprise de données sérieuse comporte quatre jalons, et je refuse de les compresser.
Une analyse des données existantes en début de projet — pas une lecture du schéma, une exploration des valeurs réelles, avec les distributions et les cas aberrants.
Une première reprise à blanc dès que le modèle cible est stable, avec production du taux de rejet.
Un arbitrage métier sur chaque motif de rejet, documenté et validé.
Des répétitions régulières jusqu’à obtenir deux exécutions consécutives conformes et chronométrées.
Ces quatre jalons représentent typiquement 15 à 25 % de la charge d’un projet de remplacement. Les inscrire dès le chiffrage évite la conversation la plus pénible qui soit : celle où l’on explique, trois semaines avant la date annoncée, que les données ne sont pas prêtes.