Les projets ERP échouent sur le périmètre, pas sur le logiciel

Un ERP est un logiciel qui impose une façon de travailler. C’est son intérêt : il met tout le monde d’accord sur une seule version des données. C’est aussi ce qui le rend difficile à installer, parce que l’entreprise a déjà une façon de travailler, faite d’habitudes, de fichiers Excel personnels et d’exceptions que personne n’a jamais écrites.

Les projets que nous avons vus échouer n’ont pas échoué sur une limite technique du produit. Ils ont échoué sur quatre décisions prises au début.

Trop de modules d’un coup

C’est la première cause, et de loin. La démonstration commerciale montre trente applications, l’entreprise trouve un intérêt à chacune, et le périmètre de départ inclut la vente, les achats, le stock, la production, les projets, les congés et la comptabilité analytique.

Chaque module ajouté rend obligatoires des champs que personne n’a envie de remplir. Multiplié par sept modules, cela produit des écrans que les utilisateurs contournent, puis des données incomplètes, puis un rejet de l’outil.

Nous démarrons délibérément sur un périmètre étroit - souvent vente, facturation et stock - quitte à élargir tous les trimestres. Un ERP qui couvre trois processus et que tout le monde utilise vaut infiniment mieux qu’un ERP qui en couvre douze et que personne ne renseigne.

Une reprise de données bâclée

Le fichier clients existant contient des doublons, des adresses périmées, des tarifs négociés il y a six ans et des contacts partis depuis longtemps. L’importer tel quel garantit que la première recherche d’un utilisateur remontera trois fiches pour le même client.

La confiance dans l’outil se joue dans les dix premiers jours. Une fois perdue, elle ne revient pas : les commerciaux rouvrent leur tableur, et l’ERP devient un endroit où l’on recopie les informations après coup.

Le nettoyage avant import est un travail ingrat, qui demande du temps aux équipes métier et non à l’informatique. Il doit être budgété comme une ligne à part entière du projet, pas traité comme une formalité de dernière semaine.

Aucun référent interne

Quand personne dans l’entreprise ne maîtrise l’outil, chaque question - ajouter un champ, modifier un modèle de devis, comprendre un écart de stock - devient un ticket chez le prestataire. C’est coûteux, c’est lent, et cela finit par décourager les demandes légitimes.

Un référent interne formé plus en profondeur que les autres change complètement l’économie du projet. Il n’a pas besoin d’être informaticien : la personne qui connaît le mieux les processus fait généralement le meilleur référent.

Des développements spécifiques dès le départ

Chaque ligne de code écrite pour vous devient une contrainte à chaque montée de version. Odoo publie une version majeure par an ; les modules spécifiques doivent être repris à chaque fois.

Cela ne signifie pas qu’il faut s’en interdire - certains processus sortent réellement du standard. Cela signifie qu’il faut d’abord chercher la solution en standard, quitte à ajuster une habitude interne, et n’écrire du code que lorsque le besoin est vraiment structurant. Quand il l’est, le code doit vivre dans des modules séparés, jamais en modification du cœur.

Le signe qui ne trompe pas

Six mois après la mise en service, posez une seule question aux équipes : « où regardez-vous pour connaître l’état d’une commande ? »

Si la réponse est l’ERP, le projet a réussi. Si c’est un tableur, un courriel ou un collègue, l’ERP n’est qu’une couche de saisie supplémentaire - et il coûte de l’argent sans rien remplacer.

Ce n’est presque jamais une question de logiciel. C’est une question de périmètre, de qualité des données reprises, et de la personne qui, en interne, en a fait son outil.