Une migration reprend des données et les relations qui leur donnent un sens. Avant de remplacer Excel ou un ancien logiciel, il faut déterminer ce qui fait référence, ce qui doit être conservé et qui vérifiera la reprise. Un import techniquement réussi peut laisser des dossiers inutilisables si ces décisions n’ont pas été préparées.
Les repères pour décider.
- Cartographier les sources et leurs relations avant de transformer les fichiers.
- Tester les correspondances et les contrôles sur un échantillon représentatif.
- Définir une seule source de référence pendant la bascule.
1. Inventorier les sources et désigner une référence.
Listez les fichiers, bases, pièces jointes et exports qui portent les informations du processus. Identifiez leur propriétaire, leur format, leur fréquence de mise à jour et les personnes qui les utilisent. Une donnée peut avoir plusieurs copies sans que l’une soit explicitement considérée comme la bonne.
Lorsque les sources se contredisent, la règle de priorité doit être décidée par le métier. Ne déduisez pas qu’un fichier plus récent contient forcément les informations les plus fiables. Pour un client, un dossier et une intervention, précisez quelle source fournit l’identité, l’état et l’historique.
2. Décider ce qui doit être repris.
Tout reprendre augmente le travail et peut importer des problèmes anciens dans le nouvel outil. Distinguez données actives, historique nécessaire au fonctionnement et archives dont l’usage doit être précisé. Les durées de conservation et les règles de traitement sont à examiner selon la nature des données et votre contexte.
Décrivez les conséquences d’une exclusion : un dossier actif doit-il rester consultable dans l’ancien outil ? Une pièce jointe est-elle indispensable à une opération ? Prévoyez où les informations non migrées pourront être retrouvées et par qui. La décision appartient au responsable métier, avec les interlocuteurs concernés par les exigences applicables.
3. Construire les correspondances et conserver les relations.
La table de correspondance relie chaque champ source à sa destination. Elle précise le type, les transformations et le traitement des valeurs manquantes. Les dates, les unités, les codes de statut et les identifiants doivent être explicités ; leurs conventions ne sont pas toujours visibles dans l’écran de l’ancien outil.
Exemple illustratif : une intervention pointe vers un client identifié par un code interne. Si le nouvel outil utilise un autre identifiant, conservez une table reliant les deux. Sans cette correspondance, les clients peuvent être importés correctement tandis que leurs interventions restent détachées. Vérifiez les relations, pas seulement le nombre de lignes.
Faites défiler le tableau horizontalement pour lire toutes les colonnes.
| Élément | Exemple illustratif |
|---|---|
| Source et destination | client_code dans l’export → identifiant du client dans l’application. |
| Transformation | Conversion d’un statut textuel vers une valeur validée par le métier. |
| Valeur manquante | Mise en anomalie plutôt que création d’une valeur fictive. |
| Contrôle | Chaque intervention importée référence un client existant. |
| Responsable | Personne qui valide la règle et tranche les exceptions. |
4. Nettoyer sans rendre les anomalies invisibles.
Repérez les doublons, les valeurs invalides et les informations contradictoires. Une règle de fusion doit préciser ce qui est conservé et permettre de retrouver les décisions prises. Une suppression automatique fondée sur un nom similaire peut réunir deux entités distinctes.
Conservez un journal des transformations et une liste des éléments non repris avec leur motif. Un enregistrement rejeté doit pouvoir être corrigé ou explicitement exclu. Cela permet aux équipes de comprendre le résultat et d’éviter qu’une opération de nettoyage ne devienne une perte silencieuse d’information.
5. Tester un échantillon qui contient des cas difficiles.
Ne choisissez pas uniquement les dossiers complets. Incluez des caractères particuliers, des données absentes, des dossiers anciens, des doublons et des pièces jointes. Si l’échantillon représente seulement le scénario idéal, le test ne dira pas comment la migration traite les cas réels.
Après l’import, réalisez les opérations métier dans le nouvel outil. Vérifiez les totaux pertinents, les relations, les statuts et les documents accessibles. Faites valider les résultats par les personnes responsables des données. Un rapprochement technique et une recette métier se complètent.
6. Organiser la bascule et la reprise sur incident.
Choisissez le moment où l’ancien outil cesse d’être la référence. Si les données continuent à changer pendant la migration, définissez comment reprendre les écarts. Évitez que deux systèmes acceptent des modifications concurrentes sans règle de synchronisation.
Prévoyez une sauvegarde vérifiée, des contrôles après migration et les conditions qui conduiraient à reporter la bascule. Un retour en arrière devient plus difficile dès que des opérations nouvelles ont été réalisées dans la nouvelle application. Décidez à l’avance comment elles seraient récupérées et qui pourrait autoriser cette procédure.
7. Suivre les anomalies après le lancement.
Donnez aux équipes un moyen clair de signaler un dossier incomplet ou une relation incorrecte. Distinguez les défauts de reprise des nouvelles erreurs de saisie. Chaque correction doit être traçable et, si elle révèle une règle manquante, conduire à examiner les autres données concernées.
La migration est terminée lorsque les contrôles convenus sont validés, les anomalies connues sont traitées ou acceptées et les utilisateurs savent où retrouver leur information. Préparer cette étape dès le cadrage permet d’estimer le travail et de construire une application qui part d’un référentiel compris.