Intégrateur ERP : rôle, choix, budget et déroulé d’un projet, vus depuis vos données

La consultation est lancée, trois propositions sont arrivées. Chacune détaille le paramétrage, les développements, la formation et la recette. Dans l’une d’elles, une ligne plus courte : « Reprise des données : à la charge du client. » Personne ne la relève en comité. Elle revient à la recette, quand les premiers fichiers chargés font apparaître des articles en double et des clients sans conditions de paiement.

Choisir un intégrateur ERP, c’est choisir qui livrera le logiciel. C’est aussi, sans toujours le dire, décider qui portera vos données : les extraire des anciens outils, les nettoyer, les faire valider, les relier au CRM. Ce guide reprend les quatre questions que l’on se pose avant de signer — le rôle, le choix, le budget, le déroulé — et, pour chacune, regarde ce qui arrive aux données.

Ce que fait un intégrateur ERP

Un intégrateur ERP est le prestataire qui met en place le logiciel choisi : il traduit vos processus en paramétrage, développe ce que le standard ne couvre pas et accompagne le démarrage. Il connaît l’éditeur. Il ne connaît pas vos données avant de les avoir vues.

Paramétrer, développer, former, accompagner la mise en service

Le cœur du métier est le paramétrage : plan comptable, circuits d’achat et de vente, règles de stock, droits des utilisateurs. Viennent ensuite les développements spécifiques, quand un processus ne rentre pas dans le standard, puis la formation des utilisateurs clés et l’assistance au démarrage. Une bonne proposition décrit chaque lot avec ses livrables et ses hypothèses.

Ce qui reste chez vous

Certaines responsabilités ne se délèguent pas. Les décisions métier : quel circuit de validation pour un achat, quelle règle de remise. La validation des données : seul un acheteur sait si une fiche fournisseur est juste, seul le contrôle de gestion sait si un solde est exact. La recette enfin, qui vérifie que l’ERP fait ce que vos équipes attendent, sur vos cas réels.

La zone entre les deux

Entre ces deux périmètres, une zone n’appartient à personne : la reprise, le nettoyage, les référentiels articles et clients, les interfaces. L’intégrateur sait charger un fichier ; il ne sait pas quelle fiche client fait foi parmi trois. Vos équipes le savent ; elles ne savent pas produire le fichier au format attendu, ni le contrôler après chargement.

Ce qui n’est écrit nulle part dans la proposition finit par être fait par quelqu’un qui n’avait pas le temps de le faire.

Les données, là où les projets ERP dérapent

Un paramétrage se corrige en quelques réglages. Une donnée fausse chargée dans l’ERP se propage : dans une commande, une facture, une écriture comptable. C’est pourquoi il faut charger des fichiers réels tôt dans le projet.

Reprendre les données : extraire, transformer, charger, contrôler

La reprise se décompose en quatre gestes. Extraire les données des anciens outils, souvent plus d’un : un ancien ERP, une gestion commerciale, des fichiers Excel. Transformer, c’est-à-dire appliquer les règles de correspondance : une famille d’articles qui devient deux, une condition de paiement qui change de code. Charger dans l’ERP. Contrôler enfin, en comparant ce qui est arrivé avec ce qui était parti : nombre de fiches, totaux, soldes.

Le contrôle est le seul geste qui dit si la reprise est bonne : il doit être prévu dès le départ. Avec plusieurs sources, une question s’ajoute : laquelle fait foi pour chaque objet. Chez Orhatek, la reprise depuis Sellsy vers HubSpot, reliée à Pennylane, a porté sur les contacts, les entreprises, les fournisseurs et le catalogue produits ; ce n’était pas un ERP, mais la question était la même.

Les référentiels articles et clients

Un référentiel est la liste de référence d’un objet : articles, clients, fournisseurs. Un article créé deux fois fausse le stock, un client présent sous trois noms fausse l’encours. Le projet ERP est le moment de décider qu’il n’existe qu’une fiche par client et par article, et d’écrire les règles de création : qui crée, avec quels champs obligatoires. Si vos outils actuels contiennent déjà des doublons, notre article sur la correction des doublons dans un CRM ou un ERP détaille la méthode.

Les interfaces avec le CRM et les outils métier

Un ERP échange avec le CRM, l’outil de support, la logistique. Pour chaque interface, trois décisions : le sens des échanges, la fréquence, et ce qui se passe quand un échange échoue. Ces décisions sont détaillées dans notre guide sur l’intégration entre ERP et CRM.

Le cas de Focal montre ce que coûte une interface absente. Le fabricant de systèmes audio haute-fidélité gérait son service après-vente dans Freshdesk, sans connexion avec son ERP Infor LN : chaque demande client était saisie deux fois. S’y ajoutaient deux instances distinctes, l’une pour la France, l’autre pour le Canada. Le projet a relié Freshdesk et Infor LN sur tout le traitement des demandes, regroupé les deux instances et migré les données nord-américaines avec leur historique, sans interrompre le service. La double saisie a disparu avec cette interconnexion.

Pour savoir quels lots de données sont déjà portés dans votre projet, et lesquels ne le sont par personne, le diagnostic en tête d’article prend quatre questions.

Choisir un intégrateur ERP

À éditeur égal, les propositions se ressemblent sur le paramétrage. Elles diffèrent sur ce qu’elles disent, ou taisent, de vos données.

Ce que sa proposition doit dire sur vos données

Une proposition sérieuse nomme les lots de données : quels objets, depuis quelles sources, avec quel historique. Elle indique le nombre de reprises à blanc avant la reprise finale, qui nettoie, qui valide chaque fichier et sur quels critères. Elle décrit les interfaces avec leur sens et leur fréquence. Quand ces lignes manquent, la proposition n’est pas moins chère : elle a reporté une partie du travail sur vous.

Les questions à poser en soutenance

• Sur quel jeu de données a-t-il travaillé. Une démonstration standard montre le logiciel ; une démonstration sur un extrait de vos articles et clients montre ce qui vous attend.
• Qui, chez lui, porte la reprise. Un nom, un rôle, du temps prévu. Une reprise confiée « à l’équipe projet » sans responsable désigné n’a pas de responsable.
• Ce qui se passe si les données ne sont pas prêtes. Report de la bascule, démarrage avec un périmètre réduit, avenant : la réponse dit comment le risque est partagé.

Les signaux d’alerte

Trois formulations doivent faire réagir. Une reprise « à la charge du client » sans accompagnement : la clause n’est pas anormale, mais elle suppose que vous ayez les compétences et le temps de la tenir. Une seule reprise prévue, juste avant le démarrage, sans marge pour corriger. Une démonstration faite sans vos données. Pour un projet Odoo, notre guide sur le choix d’un partenaire Odoo complète ces points. Demandez enfin ce qui vous sera remis : documentation, règles de transformation, accès. C’est ce qui limite la dépendance au prestataire.

Budget : ce qui fait varier la facture

Le prix d’un projet ERP dépend de postes absents de certaines propositions, et surtout du volume et de l’état des données à reprendre.

Les postes d’un projet ERP

• Les licences. Facturées par l’éditeur ou revendues, elles sont distinctes du travail de l’intégrateur.
• Le paramétrage et les développements. Ils suivent le nombre de processus couverts.
• La reprise des données. Elle dépend du nombre de sources, du volume et de l’état des données.
• Les interfaces. Chaque connexion avec un autre outil ajoute des règles à écrire et à tester.
• La formation et l’accompagnement après démarrage. C’est une ligne facile à réduire, et difficile à reconstituer ensuite.

Reprendre moins pour dépenser moins

Chaque donnée reprise est extraite, transformée, chargée et contrôlée à chaque reprise à blanc : il faut donc trier avant de chiffrer. Les référentiels et les encours — commandes ouvertes, stocks, soldes clients et fournisseurs — sont repris, après nettoyage. L’historique n’a pas toujours besoin d’être repris ligne à ligne : un solde ou une synthèse peut suffire dans l’ERP, et le détail reste consultable dans l’ancien outil ou une archive. Ce tri se décide avec les métiers, pas seulement avec l’intégrateur.

Forfait ou régie

Le mode de facturation répartit le risque de dépassement : en régie, vous achetez des jours et vous portez ce risque ; au forfait, le prestataire s’engage sur un résultat et le porte à votre place. Pour un exemple de budget sur un éditeur précis, voir le budget d’un projet Odoo.

Le déroulé d’un projet ERP

Les étapes sont connues. Ce qui distingue un projet tenu d’un projet qui glisse, c’est le livrable données attendu à chacune d’elles.

Cadrage et conception

C’est ici que se décide le dictionnaire des données : les objets repris, leurs champs, leur source, leur responsable, et les règles de transformation. Un cadrage qui ne produit que des processus cibles renvoie les données à plus tard, au moment où elles coûtent le plus cher.

Paramétrage et reprises à blanc

Pendant le paramétrage, les reprises à blanc commencent : chargement complet dans un environnement de test, contrôle, corrections, nouvelle reprise. Chaque passage réduit les anomalies et mesure le temps réel de la reprise, utile pour planifier la bascule. Prévoyez-en plusieurs : une seule reprise à blanc ne laisse aucune marge pour corriger.

Recette, bascule et premières semaines

La recette se fait sur des données réelles reprises, pas sur un jeu de démonstration : c’est la seule façon de vérifier qu’une facture sort juste pour un vrai client. La bascule enchaîne l’arrêt des saisies dans l’ancien outil, la reprise finale, les contrôles et le démarrage. Pour préserver la continuité d’activité, elle s’écrit comme une procédure, avec un point de retour arrière défini. Pendant les premières semaines, chaque correction de données doit avoir un responsable.

L’adoption

Un ERP juste mal utilisé redevient faux : les fiches se créent en double, les contournements reviennent. L’adoption se prépare pendant le projet, avec les règles de saisie et ceux qui les font respecter. Notre guide sur la conduite du changement détaille cette étape.

Une bascule réussie est une reprise à blanc de plus, faite pour de vrai.

Par où commencer

Avant de comparer les propositions, faites un état des lieux court de vos données : les outils qui contiennent des clients, des articles ou des fournisseurs, les doublons visibles, les champs sans responsable, l’historique réellement utile. Ce travail rend les propositions comparables et permet d’écrire dans la consultation qui portera chaque lot. C’est le travail que nous faisons chez turnK, en amont ou aux côtés de l’intégrateur que vous avez choisi : fiabiliser les données pour que l’ERP démarre sur une base juste.