Que migrer en premier ? Un ordre de migration qui ne stoppe pas votre activité

La troisième partie a terminé le nettoyage : noms unifiés, dates dans un seul format, nombres qui sont réellement des nombres, et significations qui vivaient dans les couleurs des cellules transformées en champs écrits. Les données sont prêtes à partir. Reste la décision qui détermine si la transition se passe calmement ou tourne en semaines de confusion : que migrer en premier ?

Cela ressemble à un détail technique pour celui qui implémente. C'est en réalité une décision opérationnelle, et elle vous revient. Votre entreprise ne fera pas de pause pour la migration. Les clients commanderont, les factures partiront, les fournisseurs livreront — tout cela pendant que la moitié de vos données se trouve à un endroit et l'autre moitié ailleurs. La bonne séquence est ce qui rend cette période gérable au lieu d'une phase où chacun travaille deux fois.

Pourquoi la migration « big bang » ne fonctionne pas

L'instinct est compréhensible : tout migrer pendant le week-end, ouvrir dimanche sur le nouveau système, et c'est réglé. Ce scénario échoue généralement pour trois raisons qui n'ont rien à voir avec la qualité du système.

Premièrement, vous découvrirez pendant la migration plus que vous ne le pensez. Chaque migration fait remonter des données manquantes que personne n'avait remarquées : un client sans numéro fiscal, un article sans unité de mesure, une facture sans référence. Migrez tout ensemble et toutes ces découvertes arrivent en même temps, au moment le plus tendu possible.

Deuxièmement, votre équipe apprend le système tout en l'utilisant. Personne ne maîtrise un nouvel outil en une journée. Une migration d'un seul coup demande à chacun de tout apprendre simultanément, si bien que lorsqu'une erreur apparaît, vous ne savez pas d'où elle vient : les données sont-elles fausses, le système est-il mal configuré, ou le collaborateur n'a-t-il simplement pas encore compris l'écran ?

Troisièmement, elle ne vous laisse aucun retour possible. Si un défaut fondamental apparaît au bout de deux jours, vos seules options sont de forcer le passage ou de tout annuler, et les deux coûtent cher. Une migration par phases maintient toujours une partie de l'activité sur un terrain stable. C'est l'un des schémas qui reviennent dans les projets de système qui s'enlisent : la faute revient rarement à l'outil, et généralement à la volonté de tout changer le même jour.

Les données de référence avant les transactions : la règle sur laquelle repose toute la séquence

Vos données sont de deux types. Les données de référence : clients, fournisseurs, articles ou services, collaborateurs, plan comptable. Et les données transactionnelles : factures, commandes, bons de commande, mouvements de stock, encaissements.

La différence entre elles n'est pas l'importance mais la direction. Les données transactionnelles pointent toujours vers les données de référence : chaque facture renvoie à un client et à des articles, chaque bon de commande renvoie à un fournisseur. L'inverse n'est jamais vrai. La séquence est donc dictée par la dépendance, pas par la préférence : migrez d'abord les données de référence, car les transactions ne peuvent pas s'installer sur quelque chose qui n'existe pas.

Inversez l'ordre et vous obtenez l'échec classique : vous importez trois mille factures, le système crée automatiquement un nouveau client pour chaque nom qui y figure, et vous vous retrouvez avec une liste de clients contenant la même entreprise trois fois, sous trois orthographes. Vous aurez reproduit, à l'intérieur du système, exactement le désordre que la troisième partie a servi à nettoyer — sauf qu'il est désormais plus difficile à corriger.

En pratique, l'ordre se déroule ainsi :

• D'abord : les entités de base. Clients, fournisseurs, articles et services. Des listes courtes, migrées une seule fois et relues à l'œil. C'est la couche sur laquelle tout le reste repose.
• Ensuite : les soldes d'ouverture. Ce que chaque client vous doit et ce que vous devez à chaque fournisseur, les quantités en stock au moment du démarrage, les soldes des comptes. Ce n'est pas de l'historique ; c'est le point zéro à partir duquel le système démarre. Choisissez une date précise pour cela et tenez-vous-y.
• Puis : uniquement les transactions ouvertes. Ce qui est en cours en ce moment — commandes pas encore livrées, factures pas encore encaissées, bons de commande pas encore réceptionnés. C'est ce que l'équipe manipule au quotidien, et c'est bien moins volumineux que vous ne l'imaginez.
• En dernier, et peut-être jamais : l'archive historique. Les factures clôturées des années précédentes.

L'archive historique : la question qui vous fait gagner des semaines

Le premier consommateur de temps et d'argent dans une migration est l'insistance à transporter tout l'historique de l'entreprise dans le nouveau système. La question qui doit précéder cette décision : que ferez-vous réellement de cet historique ?

Si la réponse est « nous en avons besoin pour consulter des informations ou pour un contrôle légal », l'archive remplit déjà cette fonction telle qu'elle est — conservée dans son format d'origine, dans un endroit connu et consultable. Votre obligation légale est de conserver les factures et les registres et de pouvoir les produire sur demande, comme le prévoit l'Autorité de la zakat, des impôts et des douanes (ZATCA), et non que tout cela vive précisément dans le nouveau système.

Si la réponse est « nous voulons des rapports comparant cette année aux années précédentes », alors vous avez besoin d'une partie de l'historique, pas de sa totalité, et généralement à un niveau synthétique plutôt que chaque ligne de facture. La différence entre ces deux migrations est considérable, tant en effort qu'en coût.

La règle de travail : migrez l'historique sur lequel vous fonderez une décision, et conservez le reste comme archive. Ne faites pas de la migration de l'archive une condition préalable à la mise en service — elle peut se faire plus tard sans pression, tandis que la mise en service ne peut pas être reportée indéfiniment.

Le fonctionnement en parallèle : nécessaire, et dangereux s'il reste ouvert

Le fonctionnement en parallèle consiste à enregistrer les transactions dans le nouveau système et dans l'ancien fichier en même temps, pendant une période définie. Il a un objectif précis : confirmer que le système produit les mêmes résultats que ceux que vous connaissez déjà. Vous comparez le total des ventes de la semaine, les soldes clients, la quantité d'un ou deux articles. Si les chiffres concordent, le système se comporte correctement ; s'ils divergent, vous le savez avant que quiconque ne fonde une décision sur un chiffre erroné.

Mais le fonctionnement en parallèle a un coût réel : votre équipe travaille deux fois. Ce coût est acceptable pendant deux semaines et destructeur sur trois mois. Le danger ne tient pas seulement à l'effort. La double saisie commence à se relâcher au bout d'un moment — quelqu'un enregistre à un endroit et reporte l'autre — si bien que les deux copies divergent et que l'exercice perd tout son sens, parce que vous ne savez plus laquelle est la bonne.

La seule règle qui compte ici est donc : un fonctionnement en parallèle avec une date de fin annoncée à tous dès le premier jour. Écrivez la date, informez l'équipe, et ne la prolongez que par une décision explicite assortie d'une raison écrite — jamais par glissement. Une période sans fin n'est pas de la prudence ; c'est une décision différée, et c'est la façon la plus courante pour un nouveau système de rester à moitié utilisé pendant une année entière. Cela s'inscrit dans le travail de conduite du changement que nous traitons en détail dans notre guide sur l'implémentation d'un système par phases.

Le regard d'Origami

Lorsque nous construisons un système sur mesure pour une entreprise qui fonctionne sur des tableurs, nous traitons le plan de migration comme une partie de la conception, et non comme une étape d'exécution en fin de projet. La raison est que l'ordre de migration impose des décisions sur la structure même du système : quelles entités doivent exister de manière autonome, quels champs doivent tolérer d'être temporairement incomplets, et où nous avons besoin d'imports répétables qui ne dupliquent pas les enregistrements.

Nous fixons aussi avec le client, avant de commencer, la date de fermeture de l'ancien fichier, car c'est cette date qui transforme le projet d'une expérience en parallèle en une véritable transition. C'est la même approche que nous adoptons dans nos feuilles de route de numérisation par phases, et elle s'étend à l'ensemble de nos services : chaque phase livre quelque chose qui fonctionne, pas la promesse que tout fonctionnera à la fin.

Le signal qui vous dit que la migration a réussi

Vous n'apprendrez pas si la transition a fonctionné grâce à un rapport d'achèvement ou à un pourcentage de migration. Vous l'apprendrez par un comportement que personne n'a demandé : un collaborateur cesse d'ouvrir l'ancien fichier sans qu'on le lui dise. Lorsque le système devient la première chose qu'il ouvre le matin parce que c'est le chemin le plus rapide vers ce dont il a besoin, la migration a réellement eu lieu. Lorsqu'il continue d'ouvrir le fichier chaque matin alors que tout a été migré, la migration n'a pas encore eu lieu, quel que soit le chiffre d'avancement.

Surveillez ce signal plutôt que les chiffres. Et si vous constatez que les gens retournent à l'ancien fichier, la raison n'est généralement pas la résistance — c'est que le système ne leur donne pas quelque chose dont ils ont besoin, ou le leur donne lentement, ou en plus d'étapes. C'est une cause qu'on peut corriger, mais seulement si vous la voyez tôt et posez la question.

Dans les prochaines parties

Les données ont migré dans le bon ordre, et une question apparaît qui n'existait pas dans le monde des fichiers : quiconque ouvre un fichier voit tout ce qu'il contient, alors qu'un système décide qui voit quoi. La prochaine partie porte sur les permissions — salaires, marges et données clients, et qui peut voir chacun d'eux. Nous passerons ensuite aux rapports que vous construisiez à la main chaque mois, et clôturerons la série avec les trente premiers jours après la migration.

Sources

• Autorité de la zakat, des impôts et des douanes (ZATCA) — exigences de facturation électronique et de conservation et production des factures et documents.
• Autorité saoudienne des données et de l'intelligence artificielle (SDAIA) — la loi sur la protection des données personnelles (PDPL) et les contrôles relatifs au traitement des données personnelles lors du transfert et du stockage.
• Ministère des Ressources humaines et du Développement social — exigences relatives à la conservation des dossiers et des données du personnel.
• Ministère du Commerce — dispositions régissant les livres et registres commerciaux des établissements.
• Autorité nationale de cybersécurité (NCA) — contrôles relatifs à la protection et à la sauvegarde des données.