Sam Gutman
juillet 27, 2026
Un ERP ne corrige pas un processus flou. Il le rend simplement plus visible, parfois plus rapide, et souvent plus coûteux à contourner. Structurer les processus avant un ERP permet donc d'éviter le scénario classique : un logiciel correctement configuré sur le plan technique, mais rejeté par les équipes parce qu'il ne reflète pas la réalité du terrain.
Pour une PME, le sujet n'est pas de produire une documentation interminable. Il s'agit de décider comment l'entreprise doit fonctionner demain : qui fait quoi, à quel moment, avec quelles données et selon quelles règles. Cette clarification réduit le périmètre inutile, accélère le déploiement et donne une base solide pour mesurer le retour sur investissement.
Dans beaucoup d'entreprises, les processus vivent dans les habitudes des collaborateurs. Un commercial sait à qui demander une remise exceptionnelle. Une personne en comptabilité sait quel fichier Excel contient la bonne version des chiffres. Le responsable d'entrepôt connaît les ajustements à faire en fin de journée pour que le stock paraisse juste.
Ces arrangements peuvent fonctionner à petite échelle. Ils deviennent fragiles dès que l'activité augmente, qu'un collaborateur part ou que plusieurs équipes doivent travailler sur une même donnée. L'ERP impose alors des choix : un statut de commande, une règle de validation, une méthode de valorisation du stock, un responsable de donnée. Sans décision explicite, chacun essaie de reproduire son ancienne méthode dans le nouvel outil.
Le résultat est prévisible : champs non remplis, validations contournées, exports Excel parallèles et demandes de développements spécifiques destinées à préserver des exceptions. Le problème n'est pas l'ERP. Le problème est d'avoir automatisé des ambiguïtés.
Il ne faut pas non plus chercher une perfection théorique. Une PME qui attend d'avoir formalisé chaque cas rare avant de lancer son projet ne démarrera jamais. L'objectif est de stabiliser les flux qui font tourner l'entreprise et qui pèsent réellement sur le chiffre d'affaires, la marge, la trésorerie ou le niveau de service.
Commencez par les flux de bout en bout, pas par les départements ni par les écrans du futur logiciel. Un processus de vente ne s'arrête pas à la signature d'un devis : il va de la demande client à la livraison, à la facture, puis au paiement. C'est précisément aux passages de relais que les délais, les erreurs et les responsabilités floues apparaissent.
Pour chaque flux prioritaire, réunissez les personnes qui exécutent réellement le travail. Pas uniquement les responsables. Un atelier court avec le commercial, l'acheteur, le préparateur, le comptable ou le planificateur révèle souvent plus qu'une série d'entretiens séparés. Demandez-leur de décrire le dernier dossier traité, étape par étape. Les exemples concrets évitent les réponses idéales qui ne correspondent pas aux pratiques réelles.
Cartographiez ensuite la situation actuelle de manière simple : le déclencheur, les étapes, les données utilisées, les contrôles, les sorties et les exceptions fréquentes. Une feuille claire suffit au départ. Ce qui compte n'est pas la qualité graphique du schéma, mais la capacité à identifier où une décision est prise et où l'information se perd.
Les processus à traiter en premier sont généralement les suivants :
Cette liste doit être adaptée au modèle économique. Une société de services aura intérêt à prioriser le temps passé, les projets et la facturation. Un distributeur mettra l'accent sur les disponibilités, les réapprovisionnements et la fiabilité des prix. Un fabricant devra traiter sans détour les nomenclatures, les gammes, les consommations matières et les écarts de production.
Lorsqu'une équipe explique qu'elle suit une procédure particulière, posez une question directe : est-ce une règle de gestion utile, une exception légitime ou un contournement créé pour compenser un dysfonctionnement ? La nuance change complètement le projet.
Une remise au-delà d'un certain seuil doit peut-être être validée par un responsable : c'est une règle. Un client stratégique qui exige un emballage particulier peut justifier une exception maîtrisée. En revanche, recopier une référence article dans trois fichiers parce que les informations ne sont pas fiables est un symptôme à supprimer.
Cette distinction évite deux erreurs coûteuses. La première consiste à paramétrer chaque habitude dans l'ERP, ce qui alourdit l'outil et la formation. La seconde consiste à standardiser trop brutalement, en ignorant une contrainte commerciale, réglementaire ou opérationnelle réelle. Le bon niveau de standardisation dépend de la valeur créée par l'exception et de sa fréquence.
La carte de l'existant sert à comprendre. Elle ne doit pas devenir le cahier des charges du futur. Pour chaque flux, définissez une version cible plus simple, avec une règle claire pour les principaux cas et un traitement explicite des exceptions.
Un bon processus cible répond sans hésitation à quelques questions : à quel moment une commande devient-elle ferme ? Qui peut modifier un prix ? Quand le stock est-il réservé ou décrémenté ? Quelle donnée fait foi pour la facturation ? Qui valide une facture fournisseur ? Que se passe-t-il si une livraison est partielle ?
Désignez également un propriétaire de processus. Il ne doit pas nécessairement exécuter toutes les tâches, mais il est responsable de l'arbitrage lorsque les équipes ne sont pas d'accord. Sans cette responsabilité, les décisions restent ouvertes jusqu'à la configuration, puis reviennent sous forme de demandes urgentes et contradictoires.
Les données méritent le même niveau d'attention que les étapes. Un ERP fonctionne sur des référentiels : clients, fournisseurs, articles, tarifs, unités de mesure, comptes comptables, nomenclatures. Si deux articles désignent le même produit ou si les conditions de paiement sont libres dans chaque dossier client, l'automatisation ne pourra pas produire des résultats fiables.
Avant toute migration, fixez les règles de création, de modification et d'archivage des données. Nettoyez ce qui est réellement utilisé, sans transformer le projet en opération archéologique. Reprendre dix ans d'historique peu fiable coûte cher et apporte rarement de la valeur. Les besoins légaux, les analyses nécessaires et les contrats en cours doivent guider le niveau d'historique à reprendre.
Ce n'est qu'après ce travail qu'il devient pertinent de comparer les fonctionnalités standard, les paramétrages et les développements spécifiques. La question n'est pas « peut-on reproduire notre méthode actuelle ? », mais « quelle option offre le meilleur compromis entre contrôle, simplicité et coût de maintien ? ».
Dans Odoo comme dans tout ERP, le standard mérite d'être privilégié lorsqu'il couvre correctement le besoin. Il bénéficie des évolutions du produit, facilite les mises à jour et réduit la dépendance à un développement sur mesure. Un paramétrage bien pensé est souvent préférable à un module spécifique.
Le développement personnalisé garde toutefois toute sa place lorsqu'il soutient un avantage métier réel, une intégration indispensable ou une contrainte impossible à couvrir autrement. Par exemple, une connexion fiable avec un site eCommerce, un système de paiement ou un équipement de production peut être plus rentable qu'une succession de manipulations manuelles. Il faut simplement évaluer le coût complet : conception, tests, documentation, maintenance et impact des évolutions futures.
Un partenaire sérieux doit être capable de dire qu'un développement n'est pas nécessaire. C'est souvent là que se joue la confiance. Chez Agitech, l'analyse des processus vise d'abord à réduire les frictions opérationnelles, pas à multiplier les lignes de devis.
Un projet ERP doit partir d'un problème mesurable. Sans point de départ, il devient difficile de savoir si le nouvel environnement a créé de la valeur ou s'il a seulement déplacé les tâches.
Choisissez quelques indicateurs liés aux flux prioritaires : délai entre commande et facturation, taux de livraisons complètes, nombre d'ajustements de stock, délai de clôture, encours client, marge par commande ou temps passé à corriger les données. Ne cherchez pas vingt indicateurs. Cinq mesures suivies régulièrement sont plus utiles qu'un tableau de bord surchargé.
Mesurez aussi l'adoption. Si les équipes continuent à gérer leurs fichiers parallèles trois mois après le démarrage, il faut comprendre pourquoi. Il peut s'agir d'une formation insuffisante, d'un écran mal configuré, d'une donnée manquante ou d'une vraie lacune fonctionnelle. Traiter le signal tôt évite que les contournements redeviennent la norme.
Préparer un ERP n'est pas un exercice administratif à confier uniquement à l'informatique. C'est une occasion de rendre les décisions plus rapides, les responsabilités plus nettes et les données plus fiables. Un atelier ciblé sur vos deux ou trois flux les plus coûteux peut déjà faire apparaître ce que votre futur système doit réellement soutenir - et ce qu'il ne faut surtout pas lui demander de reproduire.
Besoin d’un avis franc, d’une estimation budgétaire à la volée ? Vous pouvez directement réserver un visio call avec moi via le lien ci-dessous.
Si votre demande est urgente, vous pouvez m’écrire à l’adresse suivante: sam(at)agitech.io
