Projets WMS et RACI

Un projet WMS déraille désormais rarement sur une fonctionnalité manquante. Il déraille sur une question à laquelle personne ne répond, parce que chacun pensait que c’était à l’autre d’y répondre. Classique, hélas.

Qui valide le plan d’adressage des emplacements ? Qui teste l’interface avec l’ERP ? Qui dit « on démarre lundi » ? Cinq acteurs se partagent un projet de WMS : l’éditeur, l’intégrateur, le sponsor, l’équipe métier et l’équipe IT. Chacun connaît à peu près son rôle. C’est entre eux que les semaines se perdent, et c’est là qu’une matrice RACI fait son travail.

Cinq acteurs, cinq intérêts qui ne coïncident pas tout à fait

Tous veulent que le projet réussisse. Aucun ne met exactement la même chose derrière le mot « réussir ». C’est normal, et c’est précisément ce qu’il faut avoir en tête avant de distribuer les rôles.

L’éditeur, propriétaire du progiciel

L’éditeur conçoit le logiciel, le fait évoluer, publie les correctifs et assure le support sur le standard. Il vend une licence ou un abonnement, et sa feuille de route sert l’ensemble de ses clients, pas le vôtre en particulier. Selon la taille du WMS, il réalise lui-même le déploiement ou passe par un réseau de partenaires.

Ce qu’on attend de lui : un produit qui couvre le besoin sans contorsion, des fonctionnalités documentées, un support qui répond dans les délais signés. Son réflexe est de défendre le standard, et il a raison : chaque développement spécifique est une dette qu’il devra porter à chaque montée de version. Le piège est de lui demander de connaître votre entrepôt. Il connaît son logiciel et vous démontre comment votre entrepôt peut fonctionner avec son logiciel.

L’intégrateur, celui qui rend le logiciel utilisable chez vous

L’intégrateur paramètre le WMS, construit les interfaces, reprend les données, forme les utilisateurs clés et accompagne le démarrage. Ce peut être l’éditeur lui-même, un partenaire certifié ou un cabinet indépendant. Dans tous les cas, c’est lui qui traduit vos processus en règles d’affectation, de réapprovisionnement et de préparation.

Son modèle économique oriente son comportement. Payé à la journée, il n’a aucune raison de freiner le spécifique. Engagé au forfait, il a toutes les raisons de borner le périmètre au plus près du contrat. Ni l’un ni l’autre n’est malhonnête, mais il faut le savoir. Et un intégrateur paramètre ce qu’on lui décrit, pas ce qu’on aurait dû lui décrire.

Le sponsor, celui qui tranche

Le sponsor est le dirigeant qui porte le projet : directeur supply chain, directeur des opérations, parfois le dirigeant de l’entreprise dans une PME. Il fixe l’ambition, débloque le budget et les ressources, arbitre quand le métier et l’IT ne s’entendent pas.

Le sponsor qui fait défaut est rarement absent. Il est présent au lancement et au démarrage, et invisible entre les deux. Résultat : le chef de projet se retrouve à arbitrer des sujets qui dépassent sa légitimité, ou n’arbitre pas, et le planning glisse. Un projet WMS engage la capacité de l’entreprise à expédier : c’est une décision de dirigeant, qui ne se délègue pas entièrement ; ou alors avec une confiance très solide entre le sponsor et l’équipe métier. Rare tout de même.

L’équipe métier, celle qui vivra avec le système

Responsable d’entrepôt, chefs d’équipe, utilisateurs clés (les fameux key users) : ce sont eux qui expriment le besoin, valident les processus cibles, rédigent et déroulent la recette, puis forment leurs collègues. Après le démarrage, ce sont eux qui subissent chaque mauvais choix de paramétrage, à chaque préparation.

Le piège classique tient au choix des personnes. On désigne comme utilisateur clé celui qui est disponible, pas celui qui connaît le mieux le terrain. Et on ajoute le projet à sa charge d’exploitation, sans rien retirer, parfois en pleine saison haute. Un utilisateur clé qui n’a pas le temps de tester validera par défaut, et vous le découvrirez au démarrage.

C’est LE piège de ce rôle de Key User. Croire qu’on va gérer un projet IT comme on gère un projet de renouvellement des chariots. Attention spoiler, c’est un peu plus chronophage !

L’équipe IT, celle qui fait tenir l’ensemble

La DSI, ou le prestataire informatique dans une structure plus petite, porte l’architecture, l’hébergement, la sécurité, les comptes utilisateurs et les échanges avec l’ERP, le TMS ou les automates. Elle gère aussi ce que l’on oublie toujours dans les comités : la couverture wifi de l’entrepôt, les terminaux, les imprimantes d’étiquettes. Vous savez le « put**, ça se déconnecte tout le temps dès que je passe l’allée B » après le démarrage.

Deux écueils opposés existent. Le premier consiste à traiter le WMS comme un logiciel de gestion parmi d’autres, alors qu’il fonctionne en temps réel : une borne wifi qui décroche dans une allée, c’est un préparateur arrêté. Le second, plus récent, consiste à écarter l’IT parce que le WMS est en SaaS et que « l’éditeur s’occupe de tout ». L’éditeur héberge le logiciel. Il ne s’occupe ni de vos interfaces, ni de votre réseau, ni de vos terminaux.

Le chef de projet côté client, le rôle qu’on oublie de nommer

Ce n’est pas un sixième acteur avec ses propres intérêts. C’est celui qui fait tenir les cinq autres ensemble. Il tient le planning, anime les comités, suit les actions et les risques, prépare les arbitrages du sponsor et traduit en permanence ce que le métier demande en ce que l’intégrateur doit livrer. C’est aussi lui le gardien du RACI : il sait qui doit faire quoi, et il relance.

Selon les entreprises, il sort du métier, de l’IT ou d’un cabinet d’assistance à maîtrise d’ouvrage. D’où il vient compte moins que trois conditions. Du temps réellement dégagé, d’abord : un projet WMS ne se pilote pas en marge d’un poste déjà plein. Une légitimité donnée explicitement par le sponsor, devant tout le monde, ensuite. Et une connaissance suffisante de l’entrepôt pour sentir quand une réponse de l’intégrateur sonne faux.

Le piège est de le confondre avec le chef de projet de l’intégrateur. Celui-ci pilote sa prestation, ses ressources et son planning, et il défend son contrat, ce qui est son métier. Personne de ce côté de la table ne défendra vos intérêts à votre place. Les deux chefs de projet travaillent en binôme ; ils ne se remplacent pas.

Autre piège, très répandu en PME : nommer le principal utilisateur clé chef de projet « en plus » de son exploitation. On cumule alors les deux rôles les plus chronophages du projet sur une seule personne, qui finira par sacrifier l’un des deux. Rarement l’exploitation 🙂

Les zones grises où un projet perd des semaines

Aucun des sujets qui suit n’est techniquement difficile. Tous sont des sujets de frontière, et c’est pour cela qu’ils traînent.

Les données de base. Fiches articles, conditionnements, plan d’emplacements : le métier pense que l’intégrateur s’en charge, l’intégrateur attend les fichiers du client, l’IT peut les extraire de l’ERP mais n’a pas été sollicitée. Trois semaines passent avant que quelqu’un pose la question en comité. Clairement le plus frustrant en termes de temps perdu car il commence déjà à bouger les lignes et à éclairer les changement sur les zones d’influence de chacun dans l’entreprise.

L’interface avec l’ERP. L’éditeur fournit un connecteur, l’intégrateur le configure, l’IT administre l’ERP. Le jour où un message de commande est rejeté, chacun regarde le journal de l’autre. Sans responsable désigné de bout en bout, une anomalie d’interface peut circuler une semaine entière entre trois boîtes mail. Alors qu’un atelier de 30 minutes avec toutes les parties prenantes fait le job en … 30 minutes.

La recette. Qui écrit les scénarios de test ? Qui les déroule ? Qui décide qu’une anomalie est bloquante ou qu’elle peut attendre ? Si l’intégrateur rédige les scénarios et les valide lui-même, vous recettez sa compréhension du besoin, pas votre besoin. A impérativement faire par l’équipe métier même si elle doit être accompagnée par un chef de projet et/ou l’intégrateur.

La décision de démarrer. L’intégrateur déclare que le système est techniquement prêt. Le responsable d’entrepôt estime que ses équipes ne le sont pas. Le sponsor est en déplacement. Personne n’a le pouvoir de dire non, donc on démarre. Autant avoir prévu le roll-back … juste au cas où !

Le lendemain du démarrage. Lundi, 5 h 40, les terminaux ne remontent plus les tâches de préparation. On appelle qui ? Le support de l’éditeur, la hotline de l’intégrateur, l’astreinte informatique interne ? Si la réponse n’est pas écrite quelque part avant ce lundi-là, elle sera improvisée ce lundi-là. On est déjà dans le PRA plan de reprise d’activité qui n’est effectivement pas toujours un livrable produit à chaque projet. Et c’est une erreur de ne pas le faire.

Le RACI, une règle du jeu plus qu’un document

Une matrice RACI croise les activités du projet (en lignes) et les acteurs (en colonnes). Dans chaque case, une lettre dit quel rapport l’acteur entretient avec l’activité. Quatre lettres, quatre rôles distincts.

Lettre	Rôle	Ce que cela engage
R	Réalise	Fait le travail. Il peut y avoir plusieurs R sur une même activité.
A	Approuve	Rend des comptes sur le résultat, valide le livrable, tranche en cas de désaccord. Un seul A par activité.
C	Consulté	Donne son avis avant la décision. L’échange va dans les deux sens.
I	Informé	Est tenu au courant une fois la décision prise. L’information va dans un seul sens.

La traduction française piège beaucoup d’équipes. On rend souvent le R par « responsable », alors qu’en français le responsable est celui qui répond du résultat, c’est-à-dire l’A. Sur le terrain, c’est la confusion la plus courante : deux personnes se croient « responsables » de la même tâche, l’une parce qu’elle la fait, l’autre parce qu’elle la valide.

Parler de « celui qui réalise » et de « celui qui approuve » règle le problème.

Les règles qui rendent la matrice utile

Un seul A par ligne. Deux approbateurs, c’est aucun approbateur : chacun attend l’autre, ou chacun valide une version différente.
Au moins un R par ligne. Une activité sans réalisateur est une activité que personne ne fera.
A et R peuvent se confondre sur une tâche simple, à condition que ce soit un choix et non un oubli.
Les C se dosent. Chaque consulté ajoute un aller-retour. Consulter tout le monde sur tout est une manière polie de ne rien décider.
Une colonne se lit aussi verticalement. Un acteur qui accumule les A devient un goulot d’étranglement ; un acteur sans aucune lettre est soit inutile au projet, soit oublié.

Certaines équipes ajoutent un S, pour Support (on parle alors de RASCI) : celui qui apporte des moyens ou une expertise sans porter le livrable. Sur un projet WMS, la nuance sert pour l’éditeur, qui épaule souvent l’intégrateur sur un point du standard sans en être le réalisateur.

Pourquoi c’est le bien du projet, et pas une formalité

Chaque acteur a un rôle. Ce qui manque, ce sont les règles d’interaction entre ces rôles, et le RACI les rend explicites. Il fait apparaître les désaccords au lancement, quand ils coûtent une réunion, plutôt qu’en recette, quand ils coûtent un décalage de démarrage. Il évite le double travail comme le travail orphelin. Et il donne au chef de projet une base pour relancer quelqu’un sans avoir à négocier sa légitimité à chaque fois.

Exemple de matrice RACI pour un projet WMS

La matrice ci-dessous part d’un cas courant : un éditeur, un intégrateur distinct, une DSI interne. Elle sert de point de départ pour votre atelier, pas de modèle à recopier.

Activité	Sponsor	Chef de projet client	Équipe métier	Équipe IT	Intégrateur	Éditeur
Arbitrer périmètre, budget et planning	A	R	C	C	C	I
Piloter le planning, les risques et les comités	I	A, R	C	C	C	I
Décrire les processus cibles en atelier	I	C	A	C	R	C
Rédiger les spécifications fonctionnelles	I	C	A	C	R	C
Fournir et fiabiliser les données de base	I	C	A, R	R	C	I
Paramétrer le WMS	I	I	C	I	A, R	C
Développer les interfaces ERP, TMS, transporteurs	I	C	C	A	R	C
Équiper le site : wifi, terminaux, imprimantes	I	I	C	A, R	C	C
Corriger le standard du progiciel	I	I	I	I	C	A, R
Écrire les scénarios de recette	I	C	A, R	C	C	I
Dérouler la recette et lever les anomalies	I	C	A	R	R	C
Former les utilisateurs clés	I	I	A	I	R	C
Former les utilisateurs finaux	I	I	A, R	I	C	I
Décider du démarrage (go / no-go)	A	R	C	C	C	I
Assurer le support après démarrage	I	I	R	A	R	R

Deux lignes méritent un commentaire. La décision de démarrage revient au sponsor, jamais à l’intégrateur : celui qui livre ne peut pas être celui qui juge que la livraison est bonne. Et l’A du paramétrage peut basculer côté client si le contrat d’intégration est en régie plutôt qu’au forfait, puisque c’est alors vous qui pilotez le résultat. Le RACI doit refléter le contrat, et non l’inverse.

Faire vivre le RACI après la réunion de lancement

Un RACI que personne ne relit après le lancement n’a servi qu’à rassurer le comité de pilotage. Les erreurs qui le condamnent sont toujours les mêmes.

Le remplir seul. Le chef de projet qui prépare la matrice dans son coin et la diffuse pour information a produit un tableau, pas un accord. La valeur du RACI tient à la discussion qui le construit : c’est en atelier, acteurs réunis, que l’intégrateur découvre qu’on attend de lui la reprise des données et que l’IT apprend qu’elle porte l’interface ERP.
Écrire des noms de services. « Équipe IT » ne décroche pas son téléphone. Derrière chaque lettre, un nom et un suppléant. Un utilisateur clé qui part en congés trois semaines pendant la recette, cela se prévoit.
Le figer. Les responsabilités se déplacent d’une phase à l’autre : l’intégrateur domine la conception et la réalisation, le métier prend la main en recette, l’IT et le support éditeur deviennent centraux après le démarrage. Revoyez la matrice à chaque changement de phase et à chaque départ d’un acteur.
L’oublier dans le contrat. Le RACI ne remplace pas le contrat d’intégration ni les engagements de support de l’éditeur, mais il doit être cohérent avec eux. Le plus simple est de l’annexer au cahier des charges dès la consultation : les candidats savent alors exactement ce que vous attendez d’eux, et ce que vous gardez.

Mieux vaut parfois un RACI plus court mais suivi qu’un RACI exhaustif, qui comme nous l’avons écrit, rassure surtout le comité de pilotage.

L’œil de l’expert

Un projet WMS dure des mois, et l’effort ne se maintient pas tout seul. L’enthousiasme du lancement retombe dès les premiers ateliers de spécifications, les utilisateurs clés sont rappelés par l’exploitation, le sponsor passe à d’autres urgences. La chefferie de projet sert d’abord à cela : soutenir l’effort dans la durée, pas seulement tenir un planning.

Concrètement, cela tient à quelques gestes réguliers. Un comité court et fixe chaque semaine, avec une liste d’actions où chaque ligne porte un nom et une date. Des points de décision préparés à l’avance, pour que le sponsor tranche en dix minutes plutôt qu’il ne reporte. Un temps de projet négocié avec l’exploitation pour les utilisateurs clés, et protégé quand la saison monte. Un avancement rendu visible, jalon par jalon, parce qu’une équipe qui voit le projet avancer continue d’y mettre de l’énergie.

C’est un travail peu spectaculaire, et c’est exactement celui qui manque quand un projet s’essouffle à mi-parcours. Si personne chez vous n’a le temps de le porter, mieux vaut le savoir avant le lancement qu’au milieu de la recette.

Être accompagné sur le pilotage de votre projet WMS

Questions fréquentes

Quelle différence entre un éditeur et un intégrateur de WMS ?

L’éditeur conçoit et maintient le logiciel ; l’intégrateur l’installe et le paramètre chez vous. Les deux rôles sont parfois tenus par la même société, mais ils restent distincts : le premier répond du produit standard, le second de son adaptation à votre entrepôt.

Le chef de projet de l’intégrateur peut-il piloter tout le projet ?

Il pilote sa prestation, pas votre projet. Les données de base, la disponibilité des utilisateurs clés, le réseau de l’entrepôt ou la décision de démarrer restent de votre côté. Sans chef de projet client, ces sujets n’ont pas de pilote, et ce sont précisément ceux qui retardent un démarrage.

Le RACI remplace-t-il le contrat avec l’intégrateur ?

Non. Le contrat fixe les engagements, les prix et les pénalités ; le RACI organise le travail au quotidien. Les deux doivent dire la même chose, d’où l’intérêt de joindre la matrice au cahier des charges avant la signature.

Qui doit décider du démarrage du WMS ?

Le sponsor, après avoir consulté le métier, l’IT et l’intégrateur. L’intégrateur atteste que le système est prêt techniquement ; le métier atteste que les équipes sont prêtes ; la décision appartient à celui qui porte le risque pour l’entreprise.

Faut-il encore impliquer l’IT si le WMS est en SaaS ?

Oui. L’éditeur héberge le logiciel, mais les interfaces avec l’ERP, le réseau wifi de l’entrepôt, les terminaux, les imprimantes et la gestion des accès restent chez vous. Ce sont souvent eux qui bloquent un démarrage.

Combien de lignes doit compter la matrice ?

Assez pour couvrir chaque livrable du projet, pas au point de descendre à la tâche individuelle. Si la matrice ne tient plus sur un écran, elle ne sera plus lue : regroupez les activités par livrable plutôt que de multiplier les lignes.