ERP sur mesure ou simple paramétrage : quand l'outil dicte vos process

Dans un atelier de mécanique, le responsable de production crée chaque semaine des articles fictifs dans l'ERP pour suivre les pièces envoyées chez un sous-traitant en traitement de surface. Le logiciel ne connaît pas cette étape, alors l'équipe l'a inventée. Faut-il y voir un défaut de réglage, ou le signe qu'un ERP sur mesure deviendrait plus logique que l'outil standard en place ?

La réponse n'est pas toujours celle que le dirigeant redoute. Beaucoup de frictions se règlent par du paramétrage ou de la formation. D'autres traduisent un écart de fond entre la façon dont l'entreprise travaille et le modèle que l'éditeur a codé. Toute la difficulté consiste à faire la différence avant de signer quoi que ce soit.

Ce qu'un ERP standard impose, ce qu'un ERP sur mesure laisse modeler

Un ERP standard n'est pas une boîte vide. Il embarque un modèle d'entreprise : un circuit devis, commande, livraison, facture, une structure d'articles et de nomenclatures, des statuts et des règles de validation. L'éditeur a figé ces choix parce qu'ils conviennent au plus grand nombre de ses clients.

Le paramétrage joue à l'intérieur de ce cadre. Vous pouvez ajouter des champs, régler les droits, adapter les modèles de documents, activer ou désactiver des modules. Des outils comme Odoo Studio vont plus loin, sans toucher au cœur : l'ordre des étapes et la logique des objets restent ceux du logiciel.

Ces pratiques standard ont un intérêt réel. Elles accélèrent le déploiement, limitent le risque et imposent une cohérence entre services. Leur limite tient à leur origine : les solutions ERP du marché décrivent une entreprise type, souvent celle que vous étiez au moment du choix, pas celle que vous êtes devenue après une acquisition, un deuxième site ou un nouveau métier.

Un logiciel développé sur mesure inverse la logique. Le modèle de données et les étapes partent de vos process : vos statuts, vos règles de prix, vos contrôles. La contrepartie est claire : vous financez la conception, puis la maintenance, au lieu de partager ces coûts avec toute la base de clients de l'éditeur.

Comment savoir si mon ERP est inadapté ?

Le premier signe s'entend avant de se voir. Quand les équipes commencent leurs phrases par « le logiciel ne permet pas », l'outil ne sert plus le process : il le dicte.

D'autres indices se repèrent directement dans les données :

• des articles, clients ou commandes fictifs créés pour représenter une étape que l'ERP ignore ;
• un statut détourné de son sens, par exemple « en attente » pour dire « chez le sous-traitant » ;
• une information critique reléguée dans un champ commentaire, donc impossible à filtrer ;
• des validations faites par mail, puis ressaisies après coup ;
• une seule personne qui connaît « la manip » pour sortir un document correct.

Un ou deux de ces signes ne condamnent pas un outil. Quand ils touchent le cœur de l'activité, la production, le chiffrage ou la facturation, l'écart devient structurel et les processus ERP ne reflètent plus le travail réel.

La croissance agit comme une loupe. Une opération qui tient en cinq minutes quand l'entreprise traite 1 000 transactions par jour peut paralyser la chaîne lorsqu'elle en traite 10 000. Même chose avec une deuxième société dans le groupe : un circuit conçu pour une entité unique se transforme vite en séances de rapprochement entre entités, et la comptabilité passe son temps à réconcilier au lieu d'analyser.

Les fonctions qui finissent bricolées à côté de l'outil

Certains besoins reviennent dans la plupart des PME, et vivent presque toujours en dehors du système ERP :

• le chiffrage complexe : devis avec options, coefficients ou temps machine que l'ERP ne sait pas calculer ;
• la planification de l'atelier, des chantiers ou des tournées, tenue sur un tableau blanc ou dans Excel ;
• les interventions terrain : rapports, photos et signatures saisis sur papier puis retapés au bureau ;
• les tarifs particuliers : remises négociées par client, par famille ou par volume, suivies dans un fichier à part ;
• le reporting de direction, reconstruit chaque mois à partir d'exports.

Excel et Google Sheets ne sont pas le problème. Ils deviennent un risque quand un fichier tient lieu de module, avec des formules que personne ne relit et des versions qui circulent par mail. Le pilotage commercial en donne un bon exemple : un tableau de bord Excel qui grossit finit par absorber plus de temps qu'il n'en fait gagner.

Les extensions ajoutées dans l'ERP pour combler ces trous ne règlent pas tout. Développées une par une, au gré des urgences, elles laissent avec les années des champs en double, des workflows abandonnés et des règles qui se recoupent. La réponse astucieuse d'hier devient une dette technique qui complique chaque montée de version.

Chiffrer le coût réel des contournements manuels

Un contournement ne figure sur aucune facture, c'est pour cela qu'il est rarement chiffré. Mon conseil : listez-les un par un, puis estimez pour chacun le temps passé, la fréquence et le nombre de personnes concernées.

Un exemple simple, avec des hypothèses à adapter : trois personnes qui perdent chacune trente minutes par jour en ressaisies, sur 220 jours travaillés, représentent 330 heures par an. Multipliez par le coût horaire chargé de ces postes et vous obtenez un montant que la direction peut comparer à un budget de projet.

Le temps n'est que la partie visible. Ajoutez :

• les erreurs : une remise mal reportée, une livraison oubliée, une facture à refaire ;
• les délais : un devis envoyé en trois jours au lieu d'un ;
• la dépendance à la personne qui maîtrise le fichier, et le risque qu'elle quitte l'entreprise ;
• des chiffres incomplets pour décider, puisque l'ERP ne voit pas ce qui se passe à côté.

Le calcul doit rester honnête dans l'autre sens. Changer d'outil coûte aussi, et la reprise des données est souvent sous-estimée : les intégrateurs qui reprennent des projets en échec estiment qu'une migration ERP bien conduite peut représenter la moitié du travail de mise en place. Le point de bascule apparaît quand le coût annuel des contournements, cumulé sur plusieurs années, dépasse ce coût de changement.

Qui impliquer en interne avant de remettre l'ERP en cause

La technologie est rarement la première cause d'un projet ERP qui dérape. Les difficultés viennent plus souvent d'objectifs flous, d'une direction qui s'efface une fois le projet lancé et d'utilisateurs clés qui décrochent. Ces problèmes s'installent des mois avant la mise en service. Remettre en cause un ERP existant obéit aux mêmes règles.

Avant toute décision, réunissez :

• un dirigeant qui porte réellement le sujet, pas un parrain de principe qui délègue chaque arbitrage ;
• les utilisateurs de terrain de chaque service : administration des ventes, atelier, logistique, comptabilité ;
• l'auteur des fichiers Excel parallèles, qui connaît mieux que quiconque les manques de l'outil ;
• votre expert-comptable, pour vérifier que les obligations comptables et fiscales restent couvertes ;
• l'intégrateur ou le prestataire actuel, pour savoir ce que le logiciel sait déjà faire.

Je recommande d'interroger les opérateurs avant leurs responsables. Le responsable décrit le process tel qu'il a été prévu, l'opérateur décrit celui qui existe vraiment, avec ses détours. C'est cet écart qui doit guider la décision, bien plus que la liste des fonctionnalités promises par un éditeur concurrent.

Faut-il un ERP standard ou un développement sur mesure ?

Une bonne partie des frictions ne justifient pas un développement. Avant de conclure, posez trois questions.

• La fonction existe-t-elle déjà ? Beaucoup de déploiements laissent des modules inactifs ou mal réglés. Une revue du paramétrage par l'intégrateur règle parfois le problème en quelques jours.
• Les équipes ont-elles été formées ? Une formation insuffisante fait partie des causes classiques d'un ERP mal exploité. Un outil mal compris ressemble beaucoup à un outil inadapté.
• Le process est-il un atout ou une habitude ? Si votre façon de faire ne vous distingue pas de vos concurrents, adopter la logique standard coûte souvent moins cher que de la contourner.

Si la réponse pointe vers un vrai écart, plusieurs niveaux existent avant la refonte totale : un connecteur par API, un outil satellite qui gère l'étape manquante et renvoie ses données dans l'ERP, ou un logiciel central bâti autour de vos flux. C'est le principe d'un ERP conçu sur mesure : partir des process réels pour définir les données et les étapes, au lieu de plier les équipes à un modèle générique.

Cette approche a aussi ses limites. Pour la comptabilité générale ou la paie, un logiciel standard comme Sage ou EBP suit les évolutions réglementaires à votre place, et je déconseille de les redévelopper. Une TPE aux process classiques n'y gagnera rien. Enfin, un développement spécifique crée une dépendance : exigez la propriété du code, une documentation à jour et des tests automatisés, faute de quoi vous remplacez un éditeur par un prestataire tout aussi difficile à quitter.

Le point de bascule se mesure, il ne se devine pas

Un ERP qui bride vos process ne pèse rien sur la facture de licence. Il coûte en heures, en erreurs et en décisions prises sur des chiffres incomplets, et ce coût grandit avec l'entreprise jusqu'à dépasser celui du changement que vous redoutez.

Toute la question est de savoir où se situe ce seuil chez vous. Combien de vos contournements actuels pourriez-vous lister, chiffrer et attribuer à une limite réelle de l'outil plutôt qu'à un réglage jamais fait ?

Sources : L'implémentation d'un ERP a échoué ? Comment y remédier Pourquoi les meilleures pratiques ERP échouent à grande échelle Pourquoi les projets ERP échouent même avant la mise en service