Gestion de projet ERP, les dangers d'une terminologie non maîtrisée

Depuis 2004, j'ai pris l'habitude de coucher par écrit sur mon blog ERP les histoires de projets qui m'ont marqué, non pas pour le plaisir de raconter, mais pour tenter de comprendre ce qui fonctionne — ou pas — dans les intégrations ERP. Car malgré l'expérience, les certifications, les méthodologies éprouvées, il arrive encore que des projets bien préparés déraillent. Et ce n'est pas toujours une question de budget, de délais ou de choix techniques. Parfois, c'est un simple mot mal compris qui déstabilise tout.

Je vous partage mon expérience sur les dangers d'une terminologie non maîtrisée en gestion de projet ERP

Je repense à ce projet que j'ai piloté il y a quelques années dans une grande entreprise du secteur agroalimentaire. Le contexte était classique : un système vieillissant, des processus hétérogènes entre les sites, et une volonté affichée de “moderniser” et de “standardiser” les pratiques. Jusque-là, rien d'inhabituel. L'équipe IT voulait mettre en œuvre une démarche Agile, qu'elle avait testée sur quelques projets internes avec succès. Le sponsor, enthousiaste, voulait aller vite. Les métiers, eux, n'étaient pas hostiles, mais clairement non préparés à cette culture de l'itération et de la co-construction.

Dès les premiers ateliers de cadrage, les signaux faibles sont apparus. Quand l'équipe IT parlait de “sprints”, de “product owner” ou de “backlog”, les représentants métiers souriaient poliment sans poser de questions. L'ambiance était cordiale, mais je sentais que le dialogue était bancal. On avançait, certes, mais sans vraie compréhension mutuelle. Pire : chacun croyait comprendre ce que l'autre disait, mais les mots n'avaient pas la même signification selon qu'on venait du monde IT ou des opérations.

L'un des moments les plus révélateurs a été une réunion sur le découpage fonctionnel. L'équipe technique présentait le backlog comme une liste de fonctionnalités prioritaires à livrer par itération. Le directeur logistique, visiblement agacé, a fini par dire : “Mais enfin, on ne peut pas lancer une logistique sans WMS complet, non ? Vous me dites qu'on commencera par les réceptions, mais sans les expéditions, on fait quoi ?” À ce moment précis, j'ai compris que nous avions un problème profond de langage. Le mot “priorité” ne voulait pas dire la même chose pour un développeur que pour un exploitant. Pour l'un, c'était une logique de valeur incrémentale ; pour l'autre, c'était une exigence de cohérence opérationnelle.

Ce genre d'écart s'est reproduit tout au long du projet. Quand on parlait de “tests de validation”, les métiers pensaient à une simulation globale du système en conditions réelles ; l'équipe IT, elle, parlait de tests unitaires sur des fonctions isolées. Quand on évoquait le terme “acceptation”, certains y voyaient un feu vert fonctionnel, d'autres une validation technique. Même sur des concepts aussi simples que “recette”, il fallait parfois trente minutes pour accorder les définitions.

J'ai alors pris une décision qui peut sembler banale mais qui a changé la dynamique du projet : créer un glossaire commun. Pas un document académique, mais un outil vivant, partagé, commenté, co-construit. On y a mis tous les termes utilisés dans nos échanges, avec une double définition : celle que l'IT utilisait, et celle que les métiers comprenaient. Puis on a tranché ensemble, mot par mot, en expliquant les implications pratiques de chaque interprétation. Ce travail, fastidieux au départ, a fini par devenir un vrai outil de pilotage. Il a permis d'aligner les attentes, d'éviter les malentendus, et surtout, de rétablir un respect mutuel entre les acteurs.

En parallèle, nous avons redéfini les rôles. Le “Product Owner”, par exemple, avait été désigné côté IT, alors que le bon sens aurait voulu qu'il soit un représentant métier. Mais là encore, faute de clarification, on avait mis en place une structure qui brouillait les responsabilités. Un simple tableau des rôles et responsabilités, commenté lors d'un atelier, a permis d'apaiser bien des tensions. On a précisé qui décidait quoi, à quel moment, avec quelles informations. Ce n'était pas révolutionnaire, mais nécessaire.

L'autre leçon que j'ai tirée de ce projet, c'est l'importance des représentations visuelles. Trop de concepts, dans le monde des projets informatiques, sont verbalisés de manière abstraite. Les plannings sont dans des outils trop techniques, les flux dans des documents inaccessibles. J'ai donc instauré un rituel : à chaque jalon, nous produisions une synthèse visuelle du déroulé du projet — où nous étions, ce qui avait été validé, ce qu'il restait à faire, qui était concerné. Ces représentations, simples et pédagogiques, ont radicalement changé l'engagement des métiers.

Ce projet n'a pas été un long fleuve tranquille. Nous avons dû revoir le planning, redéfinir certaines priorités, et accepter de ne pas tout livrer dans la première version. Mais il a abouti, et surtout, il a été compris. L'un des directeurs m'a dit lors du bilan : “Ce que j'ai appris ici, c'est que comprendre le vocabulaire du projet, c'est déjà faire partie de la solution.” Et il avait raison. Trop souvent, on suppose que tout le monde parle le même langage. Or, dans les projets ERP, chaque mot peut porter des ambiguïtés, des attentes cachées, des tensions sous-jacentes. Prendre le temps de les clarifier, ce n'est pas une perte de temps : c'est la condition pour construire ensemble.

Aujourd'hui encore, je commence chaque projet par une séance de “traduction collective”. C'est devenu un réflexe. Car je sais que derrière chaque échec, il y a presque toujours un mot que personne n'a osé demander à définir.

👉 ( ◍•㉦•◍ ) Michel Campillo consultant expert en solutions de gestion écrit et publie régulièrement depuis 2004 des articles sur son site web professionnel dédié aux outils d'entreprise et aux questions du numérique et des technologies. Comme tout blogueur il écrit aussi sur des sujets divers, voir le blog pour un aperçu des thèmes abordés.

Outre l'email, mobile, téléphone, Linkedin, réseaux sociaux, vous pouvez me retrouver également sur Teams. Installé sur mon poste de travail, je reçois instantanément vos messages. Envoyez-moi votre identifiant par SMS ou email.

Pays de Provence, le 18 juillet 2025

Michel Campillo
Consultant chef de projet IT
☎ 06 89 56 58 18  ✉ contact par email

➽ Les articles d'actualité sur les problématiques d'entreprise sont repris chronologiquement sur la page d'accueil du blog. J'aime cet article sur l'informatique: « Comment supprimer un abonné sur Twitter? ».

Ce billet vous a intéressé? Alors partagez-le en cliquant sur les boutons ci-dessous:

Merci de vos partages! 👷🏻‍



🎯 À consulter : Mentions légales. Derniers articles : Page entreprise sur Linkedin, Factures manuelles, Déblocage de téléphone mobile, Ma playlist du moment, La gestion de projet dans Excel.
⛅ L'automne est arrivé, un temps propice au travail non? ☂️

Copyright © 2004-2025 Michel Campillo, tous droits réservés