Nettoyer les données avant la migration : ce qui ne doit pas voyager tel quel

La deuxième partie vous a laissé une liste d'une page : les fichiers critiques, leurs responsables, ce qui en dépend, et s'ils sont sauvegardés. Cette liste vous dit quoi migrer. Cette partie vous dit ce qui ne doit pas migrer tel quel.

L'idée répandue est que la migration est une étape technique : exporter un fichier, l'importer dans le nouveau système, et c'est fini. Techniquement, c'est vrai, et en pratique c'est le moyen le plus rapide de transformer un petit problème en un problème coûteux. Un tableur est indulgent par nature — il accepte tout ce que vous tapez dans n'importe quelle cellule et vous laisse le soin de l'interpréter. Un système ne l'est pas : il s'attend à ce qu'une date soit une date, un nombre un nombre, et un client une entité unique dotée d'une fiche. Ainsi, lorsque des données non nettoyées migrent, le désordre ne disparaît pas ; il ressurgit sous forme de rapports qui ne tombent pas juste, de factures qui ne se rattachent pas à leur client et de soldes qui ne concordent pas. Vient alors la phrase qui met fin à de nombreux projets : le nouveau système ne fonctionne pas.

Pourquoi le nettoyage doit précéder la migration, et non la suivre

La tentation de le reporter a une bonne raison : le nettoyage est un travail fastidieux qui n'apparaît dans aucune présentation, alors qu'un écran de nouveau système, si. On décide donc de migrer maintenant et de nettoyer plus tard. Mais une fois les données entrées, elles commencent à circuler : des factures sont émises sur des clients en double, des commandes se rattachent à des articles en double, et des rapports sont construits sur des chiffres incomplets. Chaque nouvelle transaction ajoute une couche par-dessus l'erreur, ce qui rend sa correction plus difficile et plus risquée, car modifier un enregistrement sur lequel des transactions financières ont été passées n'a rien à voir avec la modification d'une cellule dans un fichier.

Les données non nettoyées sont une cause récurrente de l'enlisement des projets de systèmes en général, et nous les avons présentées aux côtés des autres causes dans pourquoi les projets ERP échouent et comment faire réussir le vôtre. La conclusion pratique est que le nettoyage coûte le moins cher tant que les données se trouvent dans un fichier statique, et le plus cher une fois qu'elles vivent dans un système en fonctionnement.

Les cinq défauts présents dans presque tous les tableurs

Il ne s'agit pas d'erreurs exotiques ; ce sont les conséquences naturelles d'un outil qui permet tout. Vous trouverez la plupart d'entre elles dans votre propre fichier :

• Un même tiers sous plusieurs noms. Le même client apparaît trois fois : une fois sous son nom commercial, une fois sous le nom de son propriétaire, et une fois sous une abréviation tapée par quelqu'un de pressé. Dans le fichier, ce sont des lignes voisines que tout lecteur comprend. Dans un système, elles deviennent trois clients distincts, chacun avec son propre solde et son propre historique, si bien que l'historique de la relation se fragmente et qu'aucun des trois ne vous donne l'image complète. Le même défaut touche les articles et les fournisseurs.
• Des formats de date mélangés. Une même colonne contenant une date au format jour/mois, une autre au format mois/jour, et une troisième écrite en texte, comme « après les fêtes » ou « fin du mois ». Tant que seuls des humains la lisent, cela passe, mais tout tri, calcul de durée ou rapport chronologique construit sur cette colonne renverra une réponse fausse avec assurance — ce qui est plus dangereux que de renvoyer une erreur visible.
• Des nombres stockés comme du texte. Un montant saisi avec un symbole monétaire dans la cellule, une quantité accompagnée de son unité de mesure dans la même case, ou un chiffre qui commence par une espace parasite. À l'œil, cela ressemble à un nombre ; pour la machine, ce n'en est pas un, si bien qu'il ne s'additionne pas, ne se compare pas et ne migre pas — et on le découvre généralement dans le premier rapport financier après la migration.
• Des colonnes que personne ne sait définir. Une colonne intitulée « notes », « statut » ou « temp », ajoutée il y a des années pour un usage aujourd'hui révolu, parfois remplie et parfois vide. Elle voyage généralement parce que personne n'ose la supprimer, et elle entre donc dans le système comme un champ sans définition ni responsable, qui continue d'apparaître à l'écran pour semer la confusion chez vos successeurs.
• Des cellules colorées porteuses de sens. Le plus dangereux de la liste. Le jaune signifie « en retard », le rouge « en attente », le vert « encaissé ». Ce n'est pas de la mise en forme, ce sont des données — mais des données stockées dans la couleur et dans la mémoire de celui qui l'a appliquée. Lorsque le fichier est exporté, le texte voyage et la couleur disparaît, si bien que vous perdez une information avec laquelle vous pilotiez l'activité au quotidien, sans aucun avertissement.

La règle unique : tout sens extérieur à la cellule doit devenir un champ

Si vous ne retenez qu'une phrase de cette partie, retenez celle-ci : tout sens contenu dans une couleur, dans la position d'une ligne ou dans la tête de quelqu'un doit devenir une colonne écrite avant de voyager. Le test est simple et implacable — exportez le fichier en texte brut, sans aucune mise en forme, et demandez-vous quelle information a été perdue. Tout ce qui disparaît lors de ce test est exactement ce qui doit devenir un champ dès maintenant.

La conversion elle-même n'est pas un travail technique ; c'est un exercice de définition. Il ne suffit pas de créer une colonne de statut — il faut en fixer les valeurs autorisées et trancher celles qui se recoupent. « En attente » et « annulé » sont-ils un seul état ou deux ? À quel moment précis un enregistrement devient-il « en retard » ? Ce sont des questions sur le fonctionnement de l'entreprise, pas sur la programmation, et ce sont les éléments les plus précieux qu'un dirigeant retire de la phase de nettoyage, car y répondre clairement une fois pour toutes met fin à des débats jusque-là tranchés oralement à chaque fois.

Le regard d'Origami

Nous sommes une société technologique qui construit des systèmes pour les entreprises saoudiennes, et nous traitons la phase de nettoyage comme une partie de la conception du système plutôt que comme un travail administratif qui la précède. La raison en est que chaque défaut dans les données révèle une règle métier non écrite : un client en double révèle qu'il n'existe aucun identifiant convenu pour un tiers, et une cellule colorée révèle un état opérationnel réel que personne n'a jamais formellement reconnu. Ces découvertes sont la matière première d'une conception juste, c'est pourquoi nous les lisons avec le client au lieu de les transmettre à un outil d'import.

L'ordre que nous recommandons est d'unifier d'abord les définitions : qui compte comme un seul client, ce qui compte comme un seul article, et quelles valeurs sont autorisées dans chaque champ de décision. Ensuite, la migration devient une opération propre, qui peut être répétée et vérifiée. C'est là que commencent nos services de construction de systèmes, et c'est la même logique que nous avons observée dans un cas réel présenté dans d'une boutique à un système : ce qui distingue une exploitation organisée d'une exploitation improvisée n'est pas l'interface, mais la discipline des données qui se trouve en dessous.

Un ordre pratique pour le nettoyage

Nettoyer entièrement chaque fichier est un projet sans fin. Travaillez dans un ordre qui vous donne quelque chose de migrable en quelques jours :

• Commencez par les données de référence, pas par les transactions. Les clients, les articles et les fournisseurs sont des listes courtes utilisées de façon répétée, et les nettoyer corrige automatiquement les milliers de lignes qui s'y rattacheront ensuite. Les factures et les commandes viennent après.
• Adoptez un identifiant unique par entité. Un code ou un numéro fixe qui ne change jamais et n'est jamais réutilisé, puis faites-y correspondre chaque ancien nom et chaque abréviation. Pour les clients en particulier, des informations réglementaires exactes sur l'acheteur ne sont pas un luxe, car les exigences de facturation électronique de l'Autorité de la zakat, des impôts et des douanes (ZATCA) précisent ce que doit comporter une facture fiscale — et nous avons exposé le lien entre un mouvement et sa facture dans la facturation électronique dans l'usine et l'entrepôt.
• Scindez chaque cellule composite. La quantité dans une colonne et l'unité de mesure dans une autre, le montant dans l'une et la devise dans l'autre, le nom dans l'une et le numéro de mobile dans l'autre. La règle : une case pour une information.
• Unifiez les formats avant tout import. Un seul format de date dans tout le fichier, des nombres sans symbole dans la cellule, et un format unique pour les numéros de mobile. Le travail est répétitif et fastidieux, mais il ne se fait qu'une fois.
• Consignez vos décisions de nettoyage sur une feuille annexe. Ce qui a été fusionné avec quoi, ce qui a été supprimé, et ce qui reste douteux. Lorsque quelqu'un demandera deux mois plus tard où est passé tel client, cette feuille sera la réponse — et sans elle, l'équipe perd confiance dans l'ensemble de la migration.
• Ne supprimez pas l'original. Conservez le fichier d'avant nettoyage comme une copie fermée, en lecture seule. Le nettoyage implique des jugements, et un jugement a besoin d'une référence à laquelle revenir.

Et n'attendez pas des données parfaites pour migrer, car elles n'arrivent jamais. La propreté dont vous avez besoin, c'est que les champs critiques soient exacts, cohérents et définis, et que ce qui reste incomplet soit connu et consigné plutôt que découvert par surprise plus tard.

Dans les prochaines parties

Les données sont désormais aptes à migrer, et il reste la question qui décide si l'activité se poursuit pendant la transition ou s'arrête : qu'est-ce qui migre en premier ? La prochaine partie traite de l'ordre de migration, de la raison pour laquelle les données de référence précèdent toujours les transactions, et du fonctionnement de l'exploitation en parallèle avec une date de fin déclarée plutôt qu'ouverte. Nous aborderons ensuite les permissions et qui voit quoi, puis les rapports que vous construisiez à la main, et nous conclurons la série par les trente premiers jours après la migration.

Sources

• Autorité de la zakat, des impôts et des douanes (ZATCA) — exigences relatives aux factures fiscales, aux informations sur l'acheteur et à la conservation des documents.
• Autorité saoudienne des données et de l'intelligence artificielle (SDAIA) — la loi sur la protection des données personnelles (PDPL) et les règles de traitement des données des personnes.
• Ministère des Ressources humaines et du Développement social — exigences relatives à la tenue des dossiers et des données des employés.
• Ministère du Commerce — dispositions relatives aux livres et registres commerciaux des établissements.
• Autorité nationale de cybersécurité (NCA) — contrôles relatifs à la protection et à la sauvegarde des données.