Migration ERP vers le SaaS : notre retour d'expérience

Migration ERP vers le SaaS: notre retour d’expérience

Le marché a surtout changé de centre de gravité. Les entreprises ne veulent plus financer des serveurs, des mises à jour interminables et des contrats de maintenance difficiles à lire. Elles veulent un outil accessible partout, maintenu par l’éditeur et capable d’accompagner leur croissance. Très bien. Mais déplacer un ERP ne consiste pas à remplacer une adresse de connexion par une autre.

Nous le constatons sur le terrain: la difficulté n’est presque jamais le clic qui active le nouvel environnement. Elle se trouve dans les données, les interfaces, les habitudes de travail et les exceptions accumulées pendant des années. Une migration ERP vers le SaaS est un projet d’architecture, de gouvernance et de transformation opérationnelle. Pas une simple souscription logicielle.

Le cloud ne corrige pas un ERP mal conçu

Le problème: un système local devenu impossible à faire évoluer

Un ERP installé sur les serveurs de l’entreprise finit souvent par concentrer toutes les contradictions du système d’information. Il gère la comptabilité, les achats, les stocks, la production, les ventes ou la facturation. À force de personnalisations, il devient aussi le dépositaire de règles qui ne sont écrites nulle part ailleurs.

Une règle commerciale ajoutée dans l’urgence. Un export Excel construit par un contrôleur de gestion. Une interface développée pour relier l’ERP à un ancien logiciel métier. Un traitement manuel réalisé chaque mois par une personne qui connaît seule la procédure. Rien de tout cela n’apparaît correctement dans la documentation technique.

Puis vient le moment de la migration. L’entreprise découvre que son ancien ERP n’est pas seulement un logiciel. C’est un empilement de décisions prises au fil du temps.

La dette technique n’est pas uniquement constituée de code ancien. Elle comprend aussi les données incohérentes, les droits d’accès trop larges, les workflows contournés et les intégrations dont plus personne ne connaît le propriétaire. Le SaaS ne fait pas disparaître cette dette. Il la rend visible au moment où il faut décider ce qui mérite réellement d’être conservé.

La fausse bonne idée: reproduire l’existant à l’identique

La première tentation consiste à demander au nouvel ERP de fonctionner exactement comme l’ancien. Même nomenclature. Même écrans. Même règles. Même exceptions. L’objectif semble raisonnable: limiter la perturbation pour les équipes.

C’est généralement une erreur.

Reproduire l’ancien système dans un environnement SaaS revient à transporter les problèmes sans les corriger. On paie une nouvelle plateforme pour conserver des processus conçus autour des limitations de l’ancienne. On multiplie les développements spécifiques. On dégrade la capacité d’évolution du produit. Et l’on transforme un projet de migration en projet de réécriture sur mesure.

La deuxième fausse bonne idée est symétrique: choisir un ERP standard en affirmant que l’entreprise devra simplement s’adapter. Le standard est utile, mais il n’est pas magique. Certaines règles relèvent d’une réelle différenciation métier. Les supprimer au nom de la pureté fonctionnelle peut produire une organisation plus rigide, pas plus efficace.

Le bon arbitrage se situe entre trois catégories:

• ce qui doit être conservé parce que cela répond à une obligation réglementaire ou à une logique métier essentielle;
• ce qui peut être simplifié parce qu’il s’agit d’une habitude historique sans valeur réelle;
• ce qui doit être repensé parce que le processus actuel crée un goulot d’étranglement.

La solution viable: décider avant de paramétrer

Le choix d’un ERP cloud pour une PME ne doit pas commencer par une démonstration commerciale. Il doit commencer par une cartographie honnête des flux.

Nous devons savoir comment une commande devient une facture, comment un achat modifie le stock, comment une donnée client circule vers le CRM, comment les utilisateurs obtiennent leurs droits et comment les exceptions sont traitées. Sans cette lecture complète, le paramétrage repose sur des suppositions.

Un atelier utile ne demande pas seulement aux équipes ce qu’elles souhaitent dans le futur outil. Il leur demande ce qu’elles font réellement aujourd’hui. La différence entre les deux réponses est souvent le cœur du projet.

Un ERP SaaS n’est pas une remise à zéro. C’est un révélateur brutal de tout ce que l’entreprise faisait jusque-là sans vouloir le formaliser.

Le nettoyage des données concentre la vraie charge du projet

Le nettoyage et la préparation des données représentent généralement entre 20 % et 40 % du temps total d’une migration ERP. Ce n’est pas une phase administrative située avant le projet. C’est le projet.

Les bases locales accumulent les doublons, les adresses obsolètes, les comptes clients inactifs, les articles mal codifiés et les champs remplis avec des conventions différentes selon les services. Le même client peut apparaître plusieurs fois. Un produit peut disposer de plusieurs unités de mesure. Une adresse de livraison peut être inscrite dans le commentaire d’une commande plutôt que dans un champ exploitable.

Dans l’ancien ERP, ces défauts restent parfois invisibles parce que les utilisateurs connaissent les contournements. Dans le nouveau, ils bloquent les imports, faussent les tableaux de bord et perturbent les automatisations.

Ce qu’il faut trancher sur les données

Une migration saine ne transfère pas tout. Elle définit une politique de conservation.

Pour chaque famille de données, nous devons déterminer:

• quelles données sont actives et doivent être reprises;
• quelles données historiques doivent rester consultables mais ne nécessitent pas de migration complète;
• quelles données peuvent être archivées hors de l’ERP;
• quelles données sont inutilisables et doivent être supprimées;
• quel service devient responsable de la qualité après la mise en production.

Cette dernière question est souvent négligée. Pourtant, une base propre au jour du lancement peut redevenir incohérente quelques mois plus tard si personne ne contrôle les règles de création et de modification.

La gouvernance des données ne doit pas être un document produit pour le comité de pilotage. Elle doit s’incarner dans des droits, des contrôles et des responsabilités. Qui peut créer un client? Qui valide une nouvelle référence? Qui corrige une donnée bancaire? Qui traite un doublon détecté par le système? Si les réponses sont floues, l’ERP ne résoudra rien.

La précision des données sensibles n’est pas un détail

La question devient encore plus sérieuse lorsque l’ERP contient des informations personnelles, financières ou liées à des situations sensibles. Il ne suffit pas de migrer les données; il faut aussi préserver leur contexte, leurs droits d’accès et leur niveau de confidentialité.

La logique de ciblage et de précision dépasse d’ailleurs largement les systèmes de gestion: dans le domaine médical, les récits autour d’une nouvelle molécule ciblant précisément les tumeurs mammaires rappellent, à leur manière, qu’une donnée ou une action mal ciblée peut perdre toute sa valeur. Dans un ERP, le risque est moins spectaculaire, mais le principe reste identique: une information mal qualifiée finit par produire une mauvaise décision.

Une méthode de préparation qui fonctionne

Nous recommandons de traiter les données en plusieurs passes plutôt que de vouloir tout nettoyer en une seule fois.

1. Inventorier les sources.

L’ERP local n’est souvent pas la seule base à migrer. Il faut identifier les fichiers tableurs, les bases du CRM, les outils de gestion commerciale et les référentiels maintenus par les équipes.

2. Définir une donnée de référence.

Pour chaque objet — client, fournisseur, article, salarié, compte comptable — une source doit être désignée comme autorité principale. Sans cela, les équipes arbitrent ligne par ligne.

3. Détecter les doublons et les incohérences.

Les rapprochements ne doivent pas s’appuyer uniquement sur le nom. Les identifiants, adresses, numéros d’immatriculation et historiques de transaction sont nécessaires pour distinguer un doublon d’une entreprise réellement différente.

4. Construire les règles de transformation.

Les anciens champs ne correspondent pas toujours aux champs du SaaS. Il faut documenter les conversions, les valeurs par défaut et les cas impossibles à reprendre.

5. Tester avec des données représentatives.

Un import réussi sur quelques lignes propres ne prouve rien. Les tests doivent inclure des clients multi-sites, des commandes partielles, des avoirs, des articles inactifs et des cas exceptionnels.

6. Faire valider les résultats par les métiers.

La validation technique confirme que les données sont acceptées. La validation métier confirme qu’elles sont compréhensibles et exploitables.

Ce travail paraît moins valorisant qu’une démonstration de tableau de bord. Il est pourtant déterminant. Un rapport construit sur une base mal nettoyée ne devient pas fiable parce qu’il est affiché dans une interface moderne.

Le calendrier: trois mois pour une petite structure, parfois dix-huit pour une organisation intermédiaire

La durée d’une migration ERP varie fortement selon le périmètre, le nombre d’entités, la qualité des données et la profondeur des intégrations. Pour une petite entreprise de moins de 50 salariés, le projet peut s’étendre sur trois à six mois. Pour une entreprise de taille moyenne, il faut souvent prévoir douze à dix-huit mois.

Ces fourchettes ne sont pas des promesses de planning. Elles servent surtout à remettre les attentes à leur place.

Une PME mono-site, avec peu de personnalisations et une comptabilité bien structurée, ne rencontre pas les mêmes contraintes qu’une ETI disposant de plusieurs filiales, de règles fiscales différentes, d’un catalogue complexe et d’interfaces avec des outils industriels.

Les étapes d’une migration ERP vers le cloud

Le déroulement peut être structuré en cinq grandes séquences.

1. Le cadrage

Le cadrage définit le périmètre fonctionnel, les systèmes connectés, les entités concernées, les contraintes réglementaires et les objectifs mesurables. Il doit aussi identifier les processus qui ne seront pas migrés immédiatement.

Un projet sans périmètre de sortie devient vite un projet sans fin. Chaque demande ajoutée après validation doit être arbitrée selon sa valeur, son coût et son impact sur la date de mise en service.

2. La conception cible

Cette phase décrit les processus futurs. Elle ne consiste pas à reproduire les écrans de l’ancien ERP. Elle doit préciser les rôles, les validations, les circuits d’approbation, les règles de gestion et les échanges avec les autres applications.

C’est ici que l’entreprise doit décider ce qui relève du paramétrage standard et ce qui justifie une extension. La personnalisation n’est pas interdite. Elle doit être rare, documentée et réversible autant que possible.

3. La préparation et la migration des données

Les données sont extraites, nettoyées, transformées puis importées dans un environnement de test. Plusieurs cycles sont nécessaires. Le premier révèle les problèmes évidents. Les suivants traitent les écarts plus subtils: arrondis comptables, historiques incomplets, statuts incohérents ou relations entre objets mal conservées.

4. Les tests et la recette

Les tests techniques vérifient les interfaces, les droits, les traitements automatisés et la robustesse des imports. La recette métier vérifie la réalité quotidienne: créer un devis, le convertir en commande, livrer une partie, facturer le solde, gérer un retour et produire les écritures attendues.

Un scénario de test qui ne couvre que le parcours idéal ne teste pas l’ERP. Il teste une présentation commerciale.

5. La mise en production et la stabilisation

Le lancement n’est pas la fin du projet. C’est le début d’une période où les utilisateurs rencontrent les cas que personne n’avait documentés. Les premières semaines exigent une équipe capable de qualifier rapidement les incidents, de distinguer un défaut de paramétrage d’une erreur de manipulation et de décider ce qui doit être corrigé immédiatement.

La stabilisation doit être prévue dans le calendrier. Sinon, l’organisation confond l’ouverture du système avec son bon fonctionnement.

Le choix entre bascule complète et déploiement progressif

La bascule complète peut réduire la durée de coexistence entre les deux systèmes. Elle concentre cependant le risque sur une date unique. Le déploiement progressif limite l’exposition initiale, mais impose une période de coexistence, avec ses rapprochements et ses interfaces temporaires.

Il n’existe pas de méthode universelle. Le bon choix dépend de la criticité de l’activité, de la maturité des équipes, de la capacité à maintenir deux référentiels et du niveau de complexité des filiales.

Dans une organisation simple, une bascule complète peut être défendable si les tests sont solides et si le périmètre reste maîtrisé. Dans une structure multi-entités, un déploiement par domaine ou par filiale permet souvent de réduire le risque. Mais il faut alors éviter de créer un nouvel empilement transitoire impossible à résorber.

La conduite du changement ERP ne se résume pas à former les utilisateurs

La résistance au changement est souvent présentée comme un problème de communication. C’est une lecture trop confortable.

Les utilisateurs résistent rarement à une amélioration clairement démontrée. Ils résistent à la perte de repères, à la dégradation temporaire de leur productivité et aux décisions techniques prises sans tenir compte de leur travail réel.

Un ERP modifie les responsabilités. Il rend certaines informations visibles. Il supprime des fichiers personnels. Il impose des validations. Il peut aussi retirer à un service une marge de manœuvre construite au fil des années. La formation ne suffit pas à traiter ces sujets.

Le problème des formations trop tardives

Former les équipes quelques jours avant le lancement est une mauvaise stratégie. Les utilisateurs mémorisent alors des écrans sans comprendre les raisons du nouveau processus. Ils associent l’ERP à une contrainte supplémentaire et cherchent rapidement à contourner les règles.

Une conduite du changement efficace commence pendant la conception. Les représentants des métiers doivent participer aux arbitrages. Ils doivent voir les prototypes, tester les scénarios et signaler les contradictions avant la mise en production.

Cela ne signifie pas que chaque demande doit être acceptée. La participation ne consiste pas à transformer le projet en vote permanent. Elle permet de distinguer une préférence personnelle d’une contrainte opérationnelle réelle.

Ce que les équipes doivent réellement apprendre

La formation doit porter sur les situations de travail, pas sur la liste des menus disponibles.

Un responsable commercial doit savoir gérer une modification de commande et comprendre ses conséquences sur le stock et la facturation. Un comptable doit connaître l’origine des écritures et les contrôles possibles. Un magasinier doit comprendre ce qui se passe lorsqu’une réception est partielle ou qu’un article est remplacé.

Les supports utiles sont courts, contextualisés et disponibles au moment du besoin. Une documentation de plusieurs centaines de pages ne remplace pas une procédure claire intégrée au flux de travail.

Il faut également prévoir un dispositif de retour. Les premiers signalements sont précieux: ils montrent où le processus cible est incomplet, où le vocabulaire du système est mal compris et où le paramétrage crée une friction inutile.

Le changement échoue moins souvent par manque de bonne volonté que par manque de préparation concrète du travail quotidien.

Le SaaS réduit la maintenance, pas la responsabilité informatique

L’argument économique du SaaS est solide sur plusieurs points. L’entreprise n’a plus à maintenir l’infrastructure applicative de la même manière. Les mises à jour, la disponibilité de la plateforme et une partie de la sécurité relèvent de l’éditeur. Les coûts deviennent plus prévisibles.

Mais prévisible ne veut pas dire faible. Et externalisé ne veut pas dire supprimé.

Selon EY, plus de 56 % du chiffre d’affaires du marché français des logiciels provient désormais de l’écosystème SaaS. Cette progression confirme la généralisation du modèle. Elle renforce aussi la dépendance des entreprises à leurs fournisseurs: conditions contractuelles, réversibilité, localisation des données, évolution tarifaire et disponibilité des interfaces deviennent des sujets de direction.

Le coût total dépasse la licence

Le budget d’une migration inclut au minimum:

• les abonnements et les éventuels frais liés au nombre d’utilisateurs;
• le paramétrage initial et les développements spécifiques;
• le nettoyage et la transformation des données;
• les interfaces avec le CRM, la paie, les outils de production ou les plateformes de commerce;
• les tests, la formation et l’accompagnement au lancement;
• la maintenance des extensions et des flux après la mise en production;
• la gestion des droits, des audits et de la conformité;
• la préparation de la réversibilité.

Le modèle SaaS peut réduire la charge d’infrastructure tout en augmentant la facture d’intégration. C’est particulièrement vrai lorsque l’entreprise conserve de nombreux outils périphériques. Le nouvel ERP devient alors le centre d’un réseau d’interfaces dont chaque modification peut avoir un effet en cascade.

La bonne question n’est donc pas: combien coûte la licence? Elle est: combien coûte le fonctionnement complet du système sur plusieurs années, avec ses utilisateurs, ses flux et ses évolutions prévisibles?

La dépendance à l’éditeur doit être mesurée

Avant de signer, nous devons savoir comment récupérer les données dans un format exploitable, quelles interfaces sont documentées, quelles limites d’usage s’appliquent et comment l’éditeur gère les changements de version.

La réversibilité ne doit pas rester une clause théorique. Il faut identifier les données exportables, la fréquence des sauvegardes, les dépendances aux extensions et la durée nécessaire pour reconstruire un environnement équivalent.

Il faut également regarder la capacité de l’éditeur à répondre au contexte réel de l’entreprise. Un produit peut être excellent sur le marché et mal adapté à une organisation qui a besoin d’un contrôle fin des stocks, d’une comptabilité multi-entités ou d’une intégration industrielle particulière.

Le choix d’un ERP cloud pour une PME doit rester proportionné. Une plateforme trop vaste crée une complexité que l’entreprise n’a ni les équipes ni le budget pour administrer. Une solution trop limitée impose des contournements dès les premiers mois. Dans les deux cas, la promesse de simplicité disparaît rapidement.

Ce que nous retenons après les projets de migration

La migration d’un ERP local vers le SaaS est pertinente lorsque l’ancien système freine réellement l’activité: délais de mise à jour trop longs, accès distant fragile, infrastructure coûteuse, absence de visibilité consolidée ou intégrations devenues impossibles à maintenir.

Elle ne l’est pas lorsqu’elle sert uniquement à suivre une tendance technologique. Remplacer un ERP stable sans objectif opérationnel clair ne crée pas automatiquement de valeur. Cela déplace les coûts et consomme l’énergie des équipes.

Notre méthode tient en quelques principes simples:

1. Commencer par les processus, pas par les catalogues d’éditeurs.

Une démonstration réussie ne prouve pas que le produit correspond aux contraintes de l’entreprise.

2. Traiter les données comme un actif à gouverner.

Les doublons et les historiques incomplets ne sont pas des détails techniques. Ils déterminent la qualité des décisions futures.

3. Limiter les personnalisations.

Chaque extension doit avoir un propriétaire, une justification et une stratégie de maintenance.

4. Tester les exceptions.

Le parcours nominal est rarement celui qui met le système en difficulté. Les retours, les annulations, les commandes partielles et les changements de référentiel sont plus révélateurs.

5. Préparer les utilisateurs avant le lancement.

Une équipe informée des raisons du changement et entraînée sur ses cas réels récupère plus vite sa productivité.

6. Calculer le coût du système complet.

La licence SaaS n’est qu’un poste parmi d’autres. Les interfaces, les données, les extensions et la conduite du changement pèsent souvent davantage dans l’effort réel.

Le SaaS est devenu le choix dominant pour les nouveaux déploiements ERP. Ce mouvement est compréhensible. Il apporte de la souplesse, réduit une partie de la maintenance et facilite l’accès à des fonctions auparavant réservées aux grandes organisations.

Mais la technologie ne dispense pas de gouvernance. Elle ne nettoie pas les données à votre place. Elle ne décide pas quelles règles métier sont encore utiles. Elle ne convainc pas les équipes. Elle ne corrige pas une architecture faite d’interfaces sans propriétaire.

Une migration réussie n’est donc pas celle qui reproduit parfaitement l’ancien ERP dans le cloud. C’est celle qui conserve la valeur métier, supprime les contournements inutiles et donne à l’entreprise une base capable d’évoluer sans recréer immédiatement de la dette technique.