Beaucoup d’organisations traitent la migration de données comme une étape purement technique d’un déploiement : extraire l’information de l’ancien système, l’adapter au nouveau modèle et la charger dans la nouvelle plateforme. De plus, plus l’organisation transfère de données, plus le sentiment de continuité semble fort.
Mais une migration n’est pas seulement un problème technologique.
C’est aussi une décision sur l’information que l’organisation souhaite emporter avec elle vers l’avenir.
En effet, au fil des années, les bases de données accumulent bien plus que de l’information utile. Elles accumulent des doublons, d’anciennes nomenclatures, des champs que plus personne n’utilise, des enregistrements incomplets, des classifications incohérentes et des exceptions que les équipes ont créées pour répondre à des besoins qui ont depuis disparu.
Tout transférer vers une nouvelle plateforme peut préserver l’historique.
Mais cela peut aussi transférer des problèmes.
Une plateforme plus avancée ne transforme pas automatiquement des données incohérentes en information fiable. Autrement dit, si la source contient des erreurs, la nouvelle solution peut simplement rendre ces erreurs plus structurées, plus visibles et potentiellement plus difficiles à corriger ensuite.
C’est pourquoi l’organisation devrait voir la migration comme une occasion de revoir l’information existante, et pas seulement de la déplacer.
Toutes les données anciennes n’ont pas la même valeur
Ainsi, la première étape d’une migration ne devrait pas consister à demander combien d’enregistrements existent.
Elle devrait consister à comprendre lesquels restent nécessaires.
Toute l’information historique n’a pas besoin d’être disponible de manière opérationnelle dans la nouvelle plateforme.
Certaines données peuvent être nécessaires pour des raisons légales ou contractuelles. D’autres comptent pour l’analyse historique, les tendances ou l’audit. Certains enregistrements restent actifs et les équipes les utilisent tous les jours. D’autres peuvent n’avoir qu’une valeur documentaire et rester dans une archive.
Ces situations sont différentes.
Un intervenant qui n’est plus actif depuis plusieurs années n’a pas forcément besoin de figurer dans la même base opérationnelle que les intervenants actuels. Un document expiré peut avoir une valeur historique, sans devoir participer aux règles de conformité de la nouvelle plateforme. De même, un équipement réformé peut devoir rester archivé, sans apparaître dans les listes utilisées par les opérations.
Par conséquent, tout transférer sans discernement augmente le volume sans garantir davantage de valeur.
Plus de données ne signifie pas forcément plus de connaissance.
Dans certains cas, cela signifie seulement plus d’information que quelqu’un doit maintenir, rechercher, protéger et interpréter.
La sélection doit donc prendre en compte au moins trois dimensions : valeur opérationnelle, obligation de conservation et utilité analytique.
Si une donnée ne contribue à aucune d’elles, il vaut la peine de se demander si elle doit faire partie de la migration opérationnelle.
La migration de données exige de comprendre le sens, pas seulement le format
En outre, l’un des plus grands risques d’une migration consiste à supposer que des champs aux noms similaires représentent forcément la même chose.
Par exemple, deux bases peuvent utiliser l’intitulé « statut », mais appliquer des classifications différentes. Un système peut considérer un intervenant comme « actif » parce qu’il a un contrat en cours, alors qu’un autre utilise le même terme pour indiquer qu’il dispose d’une autorisation pour un projet donné.
La correspondance technique entre les champs serait simple.
La correspondance fonctionnelle serait erronée.
Il en va de même pour les catégories, les types de documents, les fonctions, les lieux, les équipements ou les statuts de workflow.
Ainsi, avant de mapper l’information, il faut comprendre le sens qu’elle avait dans la source et celui qu’elle aura dans la destination.
Cette analyse est particulièrement importante en HSE, où de petites différences sémantiques peuvent modifier l’interprétation opérationnelle.
Une fonction professionnelle peut déterminer des exigences différentes. Une catégorie documentaire peut influencer des validations. Un statut peut déclencher une autorisation ou un blocage.
Dès lors, le processus de migration doit inclure une phase claire de mapping conceptuel.
Il ne s’agit pas seulement de décider dans quelle colonne va chaque valeur.
Il s’agit de garantir que le sens reste le même.
Dans une migration de données, nettoyer avant est plus efficace que corriger après
On reporte souvent le nettoyage, car l’objectif principal est de mettre la nouvelle plateforme en service dans les délais prévus.
L’idée semble simple : d’abord migrer, ensuite corriger.
Cependant, en pratique, cette décision peut augmenter considérablement le travail.
Dès que les données entrent dans la nouvelle plateforme, elles commencent immédiatement à interagir avec des utilisateurs, des processus, des workflows, des tableaux de bord et des automatisations.
Un doublon n’est plus seulement un doublon.
Il peut désormais avoir des documents, des actions, des intervenants ou des permissions associés.
Une nomenclature incohérente n’est plus seulement une différence d’écriture.
Elle peut fragmenter les indicateurs et produire des résultats différents dans les rapports.
Donc, plus l’équipe résout tôt certains problèmes de qualité, plus l’impact tend à être faible.
Le nettoyage peut inclure la consolidation des doublons, la normalisation des noms, la correction des formats, la suppression des enregistrements sans valeur et la révision des classifications.
Tout n’a pas besoin d’être parfait.
D’ailleurs, attendre une base parfaitement propre peut retarder indéfiniment un déploiement.
L’objectif doit être d’identifier ce qui peut compromettre le fonctionnement de la nouvelle solution et de fixer des critères clairs pour le reste.
Il faut classer les différences : Sont-elles nécessaires ou historiques ?
Dans les organisations qui comptent plusieurs sites, pays ou projets, l’ancienne base de données peut contenir plusieurs façons de représenter la même réalité.
Certaines différences sont légitimes.
Il peut exister des classifications exigées par la législation locale, des exigences documentaires différentes ou une terminologie propre à une activité donnée.
D’autres différences existent simplement parce que des équipes différentes ont développé leurs propres modèles.
La migration est une occasion importante de distinguer les unes des autres.
Si deux classifications représentent exactement la même réalité, les consolider peut améliorer le reporting et simplifier l’utilisation.
En revanche, si elles correspondent à des exigences distinctes, imposer une normalisation peut supprimer une information nécessaire.
La personne qui réalise techniquement la migration ne doit pas prendre cette décision seule.
Elle a besoin de l’implication des services qui comprennent le sens fonctionnel des données.
Cette analyse peut aussi apporter un bénéfice supplémentaire : créer un modèle de données plus clair pour toute l’organisation.
Au lieu de transférer automatiquement des différences historiques, l’organisation décide consciemment des différences qu’elle souhaite conserver.
Préserver l’information ne signifie pas tout mettre dans l’opérationnel
Il existe une distinction importante entre archive historique et données opérationnelles.
Pour des raisons légales, contractuelles ou d’audit, une organisation peut devoir conserver des informations pendant de nombreuses années.
Cela ne signifie pas que tous ces enregistrements doivent intégrer la même structure que celle qui soutient le travail quotidien.
Mélanger données historiques et information opérationnelle peut compliquer la recherche, augmenter le volume et rendre certaines analyses moins claires.
En ce sens, une approche plus mature peut séparer les deux objectifs.
L’organisation migre vers l’usage opérationnel l’information nécessaire aux processus actuels.
L’information qu’il suffit de conserver peut rester accessible dans une archive adaptée, avec les contrôles nécessaires.
De cette façon, l’organisation conserve l’historique sans obliger la nouvelle plateforme à porter tout le poids du passé.
Cette distinction est particulièrement importante lorsqu’il existe une grande quantité de documentation ancienne.
Conserver l’information et l’intégrer à l’opérationnel dans la nouvelle plateforme sont deux décisions différentes.
La migration a besoin de responsables des données
Un autre problème fréquent apparaît lorsque personne n’a l’autorité claire pour décider de la qualité ou de la structure.
L’équipe technique repère deux entreprises apparemment en double.
Qui décide si l’équipe doit les consolider ?
Il existe trois intitulés pour la même fonction.
Lequel deviendra officiel ?
Un champ donné contient des milliers de valeurs incomplètes.
Faut-il le conserver, le corriger ou le supprimer ?
Autrement dit, ce sont des décisions métier.
Par conséquent, les principaux ensembles d’informations doivent avoir des responsables capables de définir des critères.
Dans certains cas, ce sera le service HSE. Dans d’autres, ce pourra être les ressources humaines, la gestion documentaire, les opérations, les achats ou un autre service.
L’essentiel est d’éviter que quelqu’un prenne des décisions fonctionnelles uniquement en fonction de la commodité technique de la migration.
Cette responsabilité doit se poursuivre après la mise en production.
La migration crée une base.
C’est la gouvernance qui permet de préserver cette base dans le temps.
Sans règles par la suite, les problèmes corrigés pendant le déploiement peuvent réapparaître progressivement.
Il faut tester les données dans le processus, pas seulement dans un tableau
Terminer une migration sur le plan technique ne revient pas forcément à la valider.
On peut confirmer le chargement de dix mille enregistrements et pourtant constater des problèmes importants.
La validation doit observer le comportement de ces données dans la nouvelle plateforme.
Les intervenants apparaissent-ils rattachés aux bonnes entreprises ? Le système interprète-t-il chaque document selon le bon type ? Qu’en est-il des dates d’expiration ? Les équipements actifs figurent-ils dans les bons projets ? Enfin, les tableaux de bord agrègent-ils l’information comme prévu ?
C’est dans ce contexte qu’apparaissent des erreurs qu’une simple comparaison des quantités ne révèle pas.
Un test de migration doit donc inclure des échantillons représentatifs.
Des cas simples.
Des cas complexes.
Données incomplètes.
Enregistrements avec historique.
Situations avec différentes relations entre entités.
Plus les données sont critiques pour les décisions opérationnelles, plus la validation doit être rigoureuse.
Si une information migrée influence la conformité, l’accès, l’autorisation ou le reporting HSE, l’organisation doit avoir suffisamment confiance dans le résultat avant d’en dépendre.
Tout migrer peut compromettre la confiance dans la nouvelle plateforme
Les premiers mois d’utilisation sont déterminants pour la perception des utilisateurs.
Si les utilisateurs trouvent des entreprises en double, des noms incorrects, des documents associés au mauvais intervenant ou des informations anciennes mêlées aux données actuelles, la confiance diminue rapidement.
Et la confiance est difficile à regagner.
Lorsque l’utilisateur commence à douter de l’information affichée, il cherche à la vérifier ailleurs.
Excel refait surface.
Puis l’e-mail.
Enfin, chacun crée sa propre liste.
L’organisation finit par recréer les processus parallèles qu’elle voulait éliminer.
C’est pourquoi la qualité de la migration conditionne directement l’adoption.
L’utilisateur n’a pas besoin de connaître tous les détails techniques du processus.
Il a besoin de croire que ce qu’il trouve dans la plateforme est suffisamment fiable pour faire son travail.
Cette confiance se construit grâce à des données cohérentes, des processus clairs et une correction rapide des situations identifiées.
Une nouvelle plateforme doit démarrer avec une meilleure base, pas seulement avec une base plus grande
Une migration réussie ne doit pas s’évaluer seulement au pourcentage de données transférées.
Elle doit s’évaluer à la qualité de la base mise à la disposition des opérations.
Les données nécessaires sont-elles présentes ?
Les classifications sont-elles cohérentes ?
Existe-t-il des informations en double ?
Avez-vous conservé l’historique nécessaire ?
Les relations entre entités sont-elles correctes ?
Les responsables savent-ils qui doit maintenir chaque ensemble de données à l’avenir ?
Ces questions comptent davantage que de pouvoir affirmer que 100 % de l’ancienne base a migré.
Dans certains projets, 100 % peut être précisément le mauvais résultat.
Une nouvelle plateforme est l’occasion d’établir de meilleurs standards, d’éliminer les incohérences et de créer une structure d’information prête pour de nouveaux workflows, tableaux de bord, intégrations et automatisations.
Transférer sans discernement tout le passé peut compromettre cette occasion.
C’est pourquoi, avant de lancer une migration, la question ne devrait pas être :
« Comment tout transférer ? »
Elle devrait être :
« De quelles informations avons-nous réellement besoin pour que la nouvelle plateforme démarre avec une base plus utile, cohérente et fiable ? »
Ce changement de perspective transforme la migration : d’une tâche technique, elle devient une décision de gestion de l’information.
Et c’est cette décision qui détermine si la nouvelle plateforme démarre seulement avec plus de données ou, réellement, avec de meilleures données.
Pour aller plus loin : Comment choisir une plateforme de gestion documentaire.
À lire aussi : Plus la plateforme HSE est configurable, plus la gouvernance doit être forte et Numériser un ancien processus ne signifie pas le transformer.
Pour situer les durées de conservation des données personnelles dans une migration, consultez les lignes directrices de l’autorité portugaise de protection des données, la Comissão Nacional de Proteção de Dados (CNPD).