La reprise des données coûte plus cher que le logiciel qui les recevra
Le poste le plus sous-estimé d'un projet de remplacement applicatif n'est pas le développement. C'est l'état réel des données existantes, que personne n'a mesuré avant de s'engager.
Un projet de remplacement applicatif se chiffre sur le périmètre fonctionnel : le nombre d’écrans, de règles de gestion, d’interfaces. La reprise des données figure en fin de proposition, souvent forfaitisée, parfois mentionnée en une ligne. C’est pourtant le poste qui fait glisser le calendrier dans la majorité des projets qui glissent.
Ce que contient un référentiel de vingt ans
Un fichier métier alimenté pendant deux décennies par des agents successifs porte des états que sa structure n’a jamais prévus. Des doublons créés parce que la recherche ne trouvait pas l’enregistrement existant. Des champs détournés de leur usage initial parce qu’aucun autre n’était disponible. Des dates de naissance au premier janvier, valeur par défaut de saisies inachevées. Des identifiants qui changent de format à partir d’une année donnée, parce que la règle a changé et que l’existant n’a pas été repris.
Aucun de ces états n’est une anomalie du point de vue de l’organisation : le service a continué de fonctionner avec eux. Ils deviennent des anomalies au moment précis où un système nouveau, dont les contrôles de saisie sont plus stricts, refuse de les charger.
Le décompte se fait avant, pas pendant
Un audit de qualité des données conduit avant l’engagement produit trois nombres. La proportion d’enregistrements qui passent les contrôles du système cible sans intervention. La proportion qui exige une reprise automatisable par règle. La proportion qui exige un arbitrage humain, dossier par dossier.
C’est le troisième nombre qui détermine le calendrier, et il est le seul qui ne se compresse pas en ajoutant des moyens. Reprendre à la main quarante mille dossiers demande un nombre d’heures que le nombre de développeurs affectés au projet ne change pas.
Cet audit se conduit en quelques jours sur un extrait, avant la notification du marché. Il coûte une fraction de ce que coûte sa découverte au sixième mois.
Qui arbitre
La question qui bloque n’est presque jamais technique. Deux enregistrements désignent-ils la même personne ? Quelle adresse fait foi lorsque trois sont présentes ? Un dossier incomplet depuis 2014 doit-il être repris, archivé ou clos ?
Ces décisions appartiennent au métier, pas au prestataire. Elles supposent qu’une personne nommée dispose du mandat pour trancher et du temps pour le faire. Un projet qui n’a pas identifié cette personne avant le démarrage la cherchera pendant la phase où elle est le plus nécessaire.
La bascule et le retour
Le jour de la bascule, l’ancien système est arrêté et le nouveau démarre avec les données reprises. Deux dispositions rendent ce moment tenable. La première est un essai de reprise complet, conduit sur une copie de production, chronométré : la durée de la reprise détermine la durée de l’interruption de service, et cette durée doit être connue avant d’être annoncée aux usagers.
La seconde est la possibilité de revenir en arrière. L’ancien système reste disponible en lecture pendant une période définie, avec ses données à l’instant de la bascule. Sans cela, un défaut découvert le troisième jour n’a pas de solution autre que de continuer.
Ce qu’il faut exiger
Un audit de qualité des données rendu avant l’engagement, avec ses trois proportions. Un essai de reprise chronométré sur volume réel avant la date de bascule. La liste des règles de transformation, écrite et validée par le métier. Et le maintien en lecture de l’ancien système pendant une durée inscrite au contrat.
