Un distributeur de matériel électrique à Casablanca, 45 salariés, décide de remplacer le logiciel de gestion installé en 2012 par un ERP moderne. Le devis de l’intégrateur tient en une page et demie, et la ligne « reprise des données » y figure pour 12 000 MAD, forfait, deux jours d’intervention. Dans la base actuelle : 9 400 fiches clients, douze ans de factures, des bons de livraison scannés sur un partage réseau, et un champ « Observations » où les commerciaux ont écrit pendant une décennie tout ce que le logiciel ne savait pas stocker.
Le cas est fictif, mais sa structure revient dans presque tous les projets de bascule. Les deux jours facturés couvrent un transfert technique. Ils ne couvrent pas la décision qui pilote le budget réel : qu’est-ce qui mérite de passer dans le nouveau système, sous quelle forme, et qui tranche quand les deux modèles de données ne se ressemblent pas.
Le jour où « changer de logiciel » devient un projet de données
Trois choses très différentes portent le mot « données » dans un devis IT. L’intégration relie des systèmes vivants qui continuent d’échanger en permanence, avec ses propres logiques de prix que nous avons détaillées dans notre article sur les prix et délais de l’intégration de données au Maroc. L’entrepôt consolide des copies à des fins d’analyse, sans obligation de reprendre fidèlement l’opérationnel. La migration est autre chose : un transfert unique, à date fixée, après lequel l’ancien système s’éteint.
Cette finalité change la gestion du projet. Un flux d’intégration mal réglé se corrige le lendemain matin. Une migration incomplète se découvre six semaines plus tard, quand un client conteste une facture de 2021 et que personne ne la retrouve ailleurs que dans une sauvegarde qu’aucun poste ne sait plus ouvrir. Le projet logiciel a une date de démarrage, le projet données doit commencer avant. Et si le périmètre fonctionnel n’est pas encore arrêté, la question ERP ou CRM se tranche en amont, parce qu’elle détermine ce qu’il y aura à migrer.
Ce qu’on migre vraiment : clients, historique, documents, relations
Chez notre distributeur, le périmètre se décompose en quatre couches qui n’ont ni la même valeur ni le même coût.
Les référentiels d’abord : clients, fournisseurs, articles, tarifs, comptes comptables. C’est le socle, et c’est là que le nettoyage prend tout son sens. Vient ensuite l’historique transactionnel : commandes, factures, règlements, mouvements de stock. Troisième couche, les documents, souvent stockés hors du logiciel : PDF de factures, bons signés, contrats, pièces jointes aux dossiers. Enfin les relations, la couche qu’on oublie : quel contact appartient à quel compte, quel règlement solde quelle facture, quel article remplace quel article obsolète.
Les trois premières couches se transfèrent avec de la méthode. La quatrième produit les mauvaises surprises. Une base de 9 400 clients importée proprement mais privée de ses liens donne un nouvel ERP où chaque fiche existe et où aucun encours n’est juste. Arbitrez couche par couche, avec une règle simple : les référentiels et les soldes ouverts passent en données vivantes, l’historique ancien passe en lecture seule ou en archive, et cet arbitrage s’écrit noir sur blanc.
Le nettoyage avant le transfert : doublons, formats, données orphelines
Une base de douze ans contient toujours les mêmes défauts. Le même client saisi trois fois sous « SARL ATLAS », « Atlas Distribution » et « ATLAS DIST. », avec des factures réparties sur les trois fiches. Des téléphones écrits en 06, en +212 6 et en 00212. Un ICE renseigné pour un client sur deux, parfois dans le champ « Observations ». Des dates de création au 01/01/1900 parce que le champ était obligatoire. Des articles désactivés mais liés à des commandes encore ouvertes.
Le nettoyage des données CRM ou ERP n’est pas un travail technique, et c’est précisément ce qui le rend coûteux. Un développeur sait détecter que trois fiches se ressemblent. Il ne peut pas décider laquelle garder, ni si les deux Atlas sont la même société ou deux agences avec des comptes séparés. Cette décision appartient à l’assistante commerciale et au comptable qui suivent ces dossiers depuis des années, et leur temps doit figurer dans le planning au même titre que celui du prestataire.
La séquence qui fonctionne : extraire, profiler (compter les doublons, les champs vides, les valeurs hors format), produire des listes de correction par thème, les faire valider par un responsable métier nommé, puis réimporter. Corriger directement dans l’ancien système gêne la production, alors qu’un fichier de transit permet de refaire l’opération autant de fois qu’il le faut. C’est la même logique qu’un audit qualité des données avant un projet BI, et si vous en avez déjà mené un, une bonne partie du travail est capitalisable.
Le mapping des champs : pourquoi deux systèmes ne se parlent jamais directement
Deux logiciels ne stockent jamais la même information de la même façon. L’ancien a un champ « Adresse » unique, le nouveau sépare facturation et livraison. L’ancien stocke « 30 jours fin de mois » en texte libre, le nouveau attend un code de condition de paiement dans une liste fermée. L’ancien ne distingue pas prospect et client, le nouveau si.
Le mapping de champs ERP est donc un exercice de décision, pas de traduction. Pour chaque champ source, il existe trois issues : transfert direct, transformation selon une règle écrite, ou abandon assumé. La troisième est parfaitement légitime, à condition d’être validée par celui qui utilise le champ au quotidien et pas par le chef de projet seul.
Deux points méritent une vigilance particulière. Les champs fourre-tout, d’abord : le fameux « Observations » mélange conditions commerciales, coordonnées, litiges et notes personnelles. Les trier à la main sur 9 400 fiches est irréaliste, les transférer en bloc dans une note libre est acceptable, mais il faut annoncer clairement que ce contenu ne sera pas cherchable de façon structurée. Les codes clients ensuite. Si le nouvel ERP renumérote, tous les documents papier, les relances et les échanges antérieurs pointent vers des références disparues. Conserver l’ancien code dans un champ dédié coûte presque rien et évite des mois de confusion.
Migration de données Maroc : les fourchettes de prix 2026
Cinq variables font le prix : le nombre d’entités à reprendre, la disponibilité d’un export propre ou d’une API côté ancien système, le nombre d’années d’historique, le volume de documents, et le nombre de décisions métier à instruire. Une base de 200 000 lignes bien structurée coûte moins cher qu’une base de 8 000 fiches sale et sans schéma documenté. Les ordres de grandeur observés pour une PME marocaine en 2026 :
- Migration CRM simple (contacts, sociétés, opportunités, pas de documents, export CSV exploitable) : 15 000 à 40 000 MAD.
- Bascule ERP de PME (référentiels complets, 3 à 5 ans d’historique, reprise des soldes clients et fournisseurs, quelques milliers de documents) : 60 000 à 180 000 MAD.
- Ancien système non documenté (base propriétaire, accès par écrans ou exports partiels, multi-sites, GED à reprendre, développements spécifiques) : 180 000 à 450 000 MAD.
Ces montants correspondent à des taux journaliers de 3 000 à 6 000 MAD selon le profil mobilisé. Mais le coût migration de données le plus souvent oublié est interne : si deux personnes du métier consacrent quinze jours au nettoyage et aux recettes, c’est un mois de charge que personne n’a budgété. Dernier réflexe utile, quand un éditeur annonce un forfait « reprise de données », demandez par écrit ce qu’il contient. Dans la majorité des cas il couvre les référentiels, pas l’historique, pas les documents, pas les corrections.
La période de double saisie, et le moment où elle casse
Entre l’arrêt de l’ancien système et la confiance dans le nouveau, il y a une zone grise. La pratique courante consiste à faire tourner les deux en parallèle : on saisit la commande dans l’ancien ERP, puis dans le nouveau, et on compare. L’intention est bonne, la durée annoncée est presque toujours fausse.
Une double saisie tient une à deux semaines. Au-delà, elle se dégrade sans que personne ne le signale : un commercial pressé ne saisit que dans un système, puis ne reporte dans l’autre que les cas simples, et au bout de trois semaines les deux bases divergent en silence. Le point de rupture classique est la clôture mensuelle, quand la comptabilité doit désigner un système de référence pour facturer.
Deux approches plus honnêtes existent. Soit une bascule franche sur une fenêtre de gel : arrêt des saisies le vendredi soir, migration, contrôles, redémarrage le lundi, avec un plan de secours écrit. Soit une date de coupure, où l’historique reste consultable en lecture seule dans l’ancien outil pendant six à douze mois et où seules les opérations ouvertes basculent. Si vous tenez à une période parallèle, limitez-la à un seul processus et fixez sa date de fin dès le départ.
CNDP et données historiques : ce qu’il faut purger, pas transférer
La migration est le meilleur moment de la décennie pour arrêter de conserver ce que vous n’avez plus de raison de conserver. La loi 09-08 impose une finalité et une durée de conservation proportionnée. Transférer des données dans un nouveau logiciel, c’est prolonger leur vie et réengager votre responsabilité sur des dossiers que vous auriez dû clore.
Dans notre cas fictif, les candidats à la purge sautent aux yeux : prospects jamais convertis depuis 2016, CV reçus en candidature spontanée, données de salariés partis depuis plus de dix ans, coordonnées bancaires stockées en clair dans un champ texte, pièces d’identité scannées « au cas où ». Chaque élément supprimé avant la bascule est un élément qu’on ne mappe pas, qu’on ne nettoie pas et qu’on ne paie pas. Les durées applicables varient selon la nature des données, nous les avons rassemblées dans notre article sur les durées de conservation et la CNDP, et pour les cas limites, vérifiez sur le site de la CNDP.
Formalisez l’opération : une liste par catégorie, la durée retenue, la justification, la date d’exécution, validée par la direction. Pensez aussi aux déclarations. Si vos traitements ont été déclarés avec l’ancien outil, le changement de logiciel et d’hébergement peut imposer une mise à jour, en particulier si les données quittent le Maroc. Ce point se confirme avant la bascule, pas après.
Le test de réversibilité avant de lancer la bascule
Aucune migration ne devrait partir en production sans avoir été jouée au moins une fois en entier sur une copie. La répétition générale mesure trois choses utiles : la durée réelle du transfert, le volume d’anomalies à corriger, et la capacité à revenir en arrière si la journée tourne mal.
Les contrôles de recette se décident avant, pas après. Quelques-uns suffisent s’ils sont les bons : nombre de clients actifs avant et après, somme des encours clients au centime, nombre de factures par année, vérification manuelle des vingt plus gros comptes par un responsable commercial. Un écart non nul sur les encours n’est pas un détail à régulariser plus tard, c’est généralement le signe qu’un lien a sauté quelque part dans le mapping.
Côté réversibilité, trois exigences méritent de figurer au contrat : une sauvegarde complète et testée de l’ancien système, un accès en lecture garanti pendant six à douze mois, et un export brut de vos données dans un format ouvert, en votre possession. Ce dernier point est votre assurance si la relation avec l’ancien éditeur se tend, un scénario fréquent que nous détaillons dans notre guide pour changer de prestataire IT au Maroc.
Avant de signer la ligne « reprise des données »
Demandez trois livrables avant le démarrage : le périmètre couche par couche, le document de mapping, et les critères de recette chiffrés. Un prestataire qui refuse de les écrire vous facturera ces décisions plus tard, en régie. L’équipe data d’Arrowlancer cadre et exécute ce type de migration (audit, nettoyage, mapping, purge, contrôles de recette) en parallèle d’un projet ERP, CRM ou cloud, aux côtés de l’intégrateur logiciel, et le périmètre de nos interventions data est détaillé sur notre page services. Si votre bascule est prévue dans les prochains mois et que cette ligne du devis vous paraît trop courte, parlons-en avant la signature.