PROBLEMATIQUE DE LA REPRISE DE DONNEES LORS D'UN CHANGEMENT DE SYSTEME D'INFORMATION
29 avril 2026
Cet article, rédigé sur la base des retours d’expérience de Cyril Jouve – Manager IN2 consulting, et d’autres collaborateurs – poursuit notre analyse des enjeux de la modernisation du système d’information.
Dans un précédent article consacré aux changements de système de gestion, nous avions vu que le choix de la méthode de migration était crucial pour les organisations, impactant de nombreux aspects : coûts, continuité des services, gestion du risque…
Nous avions alors présenté deux approches : le Big Bang et le déploiement par lots, avec chacun leurs avantages et leurs inconvénients.
Quelle que soit la méthode retenue, la reprise de données constitue l'un des aspects les plus critiques et les plus sous-estimés d'un projet de changement de système d'information. Cette étape consiste notamment à extraire les données de l'ancien système, de les transformer en les adaptant au nouveau modèle de données (nettoyer, enrichir…), puis de les charger dans le nouveau système. Elle mobilise des compétences à la fois techniques et métier, et conditionne en grande partie le succès – ou l'échec – du projet dans son ensemble.
COMPLEXITE ET ENJEUX DE LA REPRISE DE DONNEES
La reprise de données ne se résume jamais à un simple transfert technique. Elle révèle généralement des problèmes de données longtemps ignorés ou contournés (doublons, valeurs incohérentes, référentiels obsolètes, champs mal renseignés depuis des années...). Le changement de système devient alors l'occasion de dresser un état des lieux de la qualité réelle des données de l'entreprise. Et le constat est rarement flatteur.
Même si les travaux à mener offrent l'opportunité de repartir sur des bases saines, avec des données fiables et mieux structurées, ils génèrent toutefois un travail considérable, souvent mal anticipé dans les plannings initiaux. Des chamboulements qui peuvent mettre en péril les délais annoncés du projet.
La complexité augmente considérablement lorsque les modèles de données, entre l'ancien et le nouveau système, diffèrent grandement. Un cas fréquemment constaté lors du passage à un progiciel du marché ou à une solution SaaS. Ces reprises nécessitent des arbitrages métier complexes qui ne peuvent pas être tranchés par les seules équipes techniques : que faire des données qui n'ont plus de correspondance dans le nouveau système ? Comment traiter les historiques (doit-on tout reprendre ou se baser sur un critère) ? Quelle profondeur de reprise est nécessaire pour garantir la continuité opérationnelle ? Tant de questions qui impliquent les directions métier, la direction juridique, voire la direction générale, et qui doivent trouver une réponse en amont.
IMPACT SELON LA METHODE DE MIGRATION
Le Big Bang : simplicité conceptuelle, concentration des risques
Dans une approche Big Bang, la reprise de données se fait en une seule opération, généralement lors d'un week-end ou d'une période de fermeture. Cette unicité présente l'avantage de la simplicité conceptuelle : un seul processus de reprise à concevoir, à tester et à exécuter. Il n'y a pas de problème de synchronisation entre deux systèmes co-existant. Le «Jour J» est un point de rupture clair pour toute l'organisation.
Cependant, cette concentration dans le temps présente également des risques majeurs. La reprise doit être parfaitement maîtrisée car toute erreur ou tout retard impactera immédiatement l'ensemble de l'organisation.
Les volumes de données à traiter peuvent être considérables et le temps disponible est contraint par la fenêtre de bascule. Cela nécessite des processus de reprise optimisés, parallélisés et dont les performances ont été mesurées et validées lors des répétitions. En cas de problème lors de la reprise, le projet entier peut être compromis, conduisant potentiellement à un report de la bascule, avec toutes les conséquences organisationnelles et financières que cela implique.
La gestion du go/no-go est ici particulièrement délicate. Il faut définir à l'avance des critères objectifs et mesurables permettant de décider si la reprise est suffisamment conforme pour autoriser le démarrage en production. Ces critères doivent être définis collectivement (équipes projet, métier, direction) bien avant le jour J, afin d'éviter toute prise de décision sous pression et dans l'urgence.
Le déploiement par lots : dilution du risque, complexité de synchronisation
Dans une approche par lots, la reprise de données se décline en multiples reprises partielles, chacune correspondant à un périmètre spécifique (une entité juridique, une offre commerciale, une partie du portefeuille...) Cette fragmentation réduit la complexité et le risque de chaque reprise individuelle : on apprend au fur et à mesure, on affine les processus entre chaque vague et les éventuelles erreurs sont circonscrites à un périmètre limité.
Cette approche introduit cependant une difficulté majeure que l'on sous-estime souvent en début de projet : la gestion de la synchronisation entre les deux systèmes pendant toute la période de coexistence. Les données modifiées dans l'ancien système pour des entités encore en attente de migration doivent être gérées sans perturber les entités déjà migrées dans le nouveau système, et inversement. Lorsque des données sont partagées entre entités (référentiels communs, salariés travaillant sur plusieurs périmètres), cette synchronisation bidirectionnelle peut devenir extrêmement complexe à orchestrer et à maintenir dans la durée.
Le risque principal devient alors la désynchronisation et l'incohérence des données entre les deux systèmes. Ce moment asynchrone peut engendrer des erreurs métier difficilement détectables car elles n'apparaissent pas comme des anomalies techniques. En effet, les données en apparence sont cohérentes mais factuellement fausses. Ces erreurs silencieuses sont les plus dangereuses car elles ne sont souvent découvertes qu'après plusieurs semaines de production.
BONNES PRATIQUES ET RECOMMANDATIONS
Quelle que soit la méthode utilisée, la reprise de données doit être abordée selon des principes clés, indispensables pour garantir le niveau de rigueur qu’elle exige.
Anticiper très tôt l'analyse de la qualité des données. Il est essentiel de démarrer l'audit des données dès les premières phases du projet, bien avant que les équipes techniques ne soient opérationnelles sur les outils de migration. Cette analyse doit aboutir à une cartographie précise des anomalies détectées et à la mise en place de chantiers (par les équipes métier avec l'appui de la DSI) de nettoyage et de fiabilisation. Attendre la phase de réalisation pour découvrir l'état réel des données est l'une des causes les plus fréquentes de dérapage dans les projets de migration.
Tester, répéter, mesurer. La reprise de données doit faire l'objet de tests intensifs et répétés, idéalement en reproduisant plusieurs fois le processus complet sur des jeux de données réels anonymisés, dans un environnement représentatif de la production. Ces répétitions poursuivent plusieurs objectifs : optimiser les performances des traitements, détecter les cas limites non couverts par les spécifications initiales, former les équipes aux procédures d'exploitation et surtout gagner en confiance sur la capacité à tenir la fenêtre de bascule.
Chaque répétition doit faire l'objet d'un bilan formalisé et d'actions correctives.
Définir des indicateurs de qualité et automatiser les contrôles. Après chaque reprise, des vérifications systématiques doivent confirmer l'intégrité, la complétude et la cohérence des données migrées. Ces contrôles ne doivent pas reposer uniquement sur des vérifications manuelles : ils doivent être automatisés autant que possible et documentés de manière exhaustive. Leurs résultats doivent alors être présentés de façon lisible aux équipes métier, qui sont les seules à pouvoir valider le fond. Un tableau de bord de qualité de la reprise, mis à jour en temps réel lors du chargement, est un outil précieux pour piloter le go/no-go.
Prévoir et organiser la gestion des anomalies post-production. Même avec la meilleure préparation, des anomalies seront découvertes après la mise en production, c'est inévitable. Il ne faut pas le nier, mais l'anticiper. Des processus de correction doivent être clairement définis avant la bascule : qui détecte, qui qualifie, qui corrige, qui valide ? Les circuits de décision doivent être connus de tous et les responsabilités clairement établies. Un stock d'anomalies non traitées qui s'accumule en post-ouverture est non seulement un risque opérationnel, mais aussi un facteur d'épuisement des équipes. Il pourra aussi entraîner la défiance des utilisateurs envers le nouveau système.
CONCLUSION
La reprise de données est, à bien des égards, le miroir du projet de migration tout entier. Elle en concentre la complexité, en révèle les imprévus et en conditionne le succès perçu par les utilisateurs.
La bascule vers un nouveau système techniquement parfait mais alimenté par des données erronées ou incomplètes sera immanquablement perçue comme un échec. À l'inverse, une reprise rigoureuse, bien préparée et bien contrôlée, pose les fondements d'une adoption réussie et durable. Elle mérite donc une attention et des ressources à la hauteur des enjeux. Cela suppose alors de la mettre au centre du pilotage du projet et non de la traiter comme une simple tâche technique périphérique.
BESOIN D'UN ACCOMPAGNEMENT ?
IN2 consulting, cabinet de conseil et éditeur de logiciel dans le secteur de l’Assurance depuis une quinzaine d’années, spécialisé dans la mise en œuvre, l’exploitation et l’automatisation des différents flux assurantiels (DSN, Prest’IJ, PRDG, PASRAU, Ficovie, autres EDIs) peut vous aider !
• Vous avez été confronté à ces enjeux ?
• Vous souhaitez nous apporter un éclairage différent ?
• Vous souhaiteriez en savoir plus ?
Remarque : Vous pouvez retrouver notre précédent article lié aux méthodes de changement de systèmes d’information ici !