Vérifiez la portabilité de vos données métier : fichiers exportés, pièces jointes, relations, formats et tests de reprise avant de changer de logiciel.
Un bouton « exporter » peut produire une liste utile pour un rapport sans permettre de reconstruire les dossiers dans un autre logiciel. Les documents joints, les relations entre enregistrements et les historiques peuvent rester absents. Il faut examiner le contenu réel de la sortie avant d’en avoir besoin.
Un essai de portabilité consiste à récupérer un ensemble de données, comprendre sa structure et vérifier qu’une autre équipe peut l’exploiter. Cet exercice peut être mené sur un périmètre fictif ou de test. Il renseigne sur le travail nécessaire à un futur changement de solution.
Définir les informations à récupérer
Établissez l’inventaire des objets métier : clients, dossiers, lignes de commande et documents, selon votre application. Pour chaque objet, précisez les champs nécessaires et les liens avec les autres objets. Ajoutez les statuts dont le sens influence la reprise.
Séparez les données actives des archives. Certaines informations peuvent être conservées dans une archive consultable sans entrer dans le prochain logiciel. La décision dépend de leur usage et des obligations applicables ; elle ne doit pas être déduite du seul fait qu’un écran ne les montre plus.
Dans un exemple fictif de suivi d’interventions, l’entreprise veut reprendre les dossiers ouverts et leurs pièces jointes. Elle souhaite aussi conserver l’identité des auteurs des commentaires. Un export qui remplace tous les auteurs par « utilisateur supprimé » perd une information demandée dans ce périmètre.
Choisir des formats qui conservent le sens
Un CSV convient à des données tabulaires simples si son format est documenté. Il faut préciser l’encodage, le séparateur et la représentation des valeurs. Un fichier qui s’ouvre dans un tableur n’est pas nécessairement interprété de manière identique par tous les outils.
La RFC 4180 décrit notamment l’usage des guillemets pour les champs contenant des virgules, des retours à la ligne ou des guillemets. Cette référence de format ne définit pas le sens métier des colonnes. Celui-ci doit être fourni séparément.
Pour les structures imbriquées, un format comme JSON peut être plus pratique. Le choix dépend du système de reprise. Dans tous les cas, documentez les identifiants, les dates, les devises et les valeurs absentes. Un code client doit conserver sa représentation lorsqu’elle est significative.
Joindre un dictionnaire de données
Le dictionnaire décrit chaque fichier et chaque champ. Il indique les types attendus, les valeurs possibles et les relations. Un statut numérique sans table de correspondance oblige la prochaine équipe à deviner sa signification.
| Élément fictif | Documentation attendue |
|---|---|
customers.csv | Une ligne par client et identifiant stable |
jobs.csv | Référence du client et définition des statuts |
attachments.csv | Dossier parent, nom du fichier et chemin dans l’archive |
users.csv | Correspondance entre identifiants et auteurs exportés |
| Répertoire de documents | Fichiers annoncés dans le manifeste |
Conservez les relations avec des identifiants stables plutôt qu’avec les seuls noms affichés. Deux clients peuvent porter des noms proches et un nom peut changer. Vérifiez qu’aucune relation indispensable ne dépend uniquement d’un lien vers l’ancien logiciel.
Exporter les pièces jointes réellement nécessaires
Un export de liens vers les documents ne garantit pas que ces documents resteront accessibles après fermeture du compte. Demandez les fichiers eux-mêmes lorsque le périmètre de sortie le nécessite. Le manifeste doit permettre de les rattacher à leurs dossiers.
Vérifiez les noms, extensions et tailles annoncées. Des empreintes de fichiers peuvent aider à contrôler l’intégrité pendant le transfert, mais elles ne prouvent pas à elles seules que tous les documents attendus sont présents. La complétude doit être comparée à l’inventaire de départ.
Testez les fichiers avec des noms accentués, des doublons de noms et des documents volumineux. L’outil de sortie doit définir comment il évite les collisions dans l’archive et comment il signale les échecs partiels.
Contrôler la cohérence de l’ensemble exporté
Si l’application reste utilisée pendant l’export, les fichiers peuvent représenter des instants différents. Un dossier créé après l’export des clients peut référencer un client absent. Demandez comment la sortie obtient un ensemble cohérent ou comment les modifications intervenues pendant l’opération sont reprises.
Comparez les nombres d’objets et quelques totaux métier pertinents. Parcourez un échantillon comprenant des dossiers complexes. Vérifiez qu’une autre personne peut retrouver les pièces jointes et comprendre les statuts avec la documentation fournie.
Une répétition dans un environnement de test permet d’estimer le travail de transformation. Les contrôles décrits dans notre guide de migration des données Excel s’appliquent aussi à la reprise d’un export applicatif, avec les relations et les documents supplémentaires.
Encadrer l’accès aux archives exportées
Une archive complète peut concentrer davantage de données qu’un utilisateur n’en voit habituellement à l’écran. Précisez qui peut la générer, où elle est conservée et comment elle est transmise à l’équipe autorisée. Les copies de test doivent recevoir les mêmes décisions de protection et de conservation.
Inscrivez les conditions de sortie dans le dossier de maintenance : personne responsable, format convenu, délai et coûts éventuels. Après un essai, conservez le rapport de vérification et les écarts. Rejouez l’exercice quand une nouvelle catégorie de données devient nécessaire au métier.