Une fenêtre d'expédition qui a failli faire dériver tout un projet

Le déploiement se déroule chez un producteur de matériaux de construction: sables, graviers, granulats. Les camions partent toute la journée, les chargements sont regroupés, et le service expédition est au cœur de l'activité.

Lors des ateliers, son responsable formule une demande claire: retrouver dans le nouvel ERP une fenêtre de regroupement des expéditions identique à celle de l'ancien système.

Dans l'ancien outil, il cochait d'une croix les lignes à expédier, puis ajustait les quantités au fil de l'eau, ligne après ligne.

Le standard de l'ERP en cours de déploiement raisonne autrement: l'expédition groupée est un document unique, auquel on ajoute ou retire des lignes, et dont on met à jour les quantités avant de valider. Le résultat final est le même, seule la manière d'y arriver diffère.

La demande paraît anodine. Pourtant, le développement engagé pour y répondre glisse vite vers une modification de la validation des expéditions elle-même. Or toucher à la validation, c'est toucher au traitement standard du stock: mouvements, valorisation, traçabilité, et tous les tests qui en dépendent. Une question d'ergonomie était en train de devenir la refonte d'un processus important.

La sortie de crise n'est venue ni d'un refus sec ni d'une acceptation complète. Le chef de projet a construit un compromis avec le responsable: une nouvelle fenêtre, proche de ses habitudes de travail, qui s'appuie sur le document standard sans modifier la validation, en échange de l'acceptation de travailler légèrement différemment. Le service expédition a gardé une interface confortable, et le projet a gardé un moteur de stock standard.

Pourquoi une demande raisonnable devient une dérive

Cette histoire résume le mécanisme du scope creep. Aucune demande, prise isolément, ne semble déraisonnable. Celle du responsable des expéditions était légitime: il connaissait son métier, ses contraintes de cadence, et voulait éviter de perdre du temps au quai de chargement. Le problème ne venait pas de son besoin, mais de la forme sous laquelle il l'exprimait.

Un utilisateur décrit rarement un besoin. Il décrit une solution, le plus souvent celle qu'il connaît déjà. "Une fenêtre identique à l'ancien système" est une solution. "Préparer rapidement un chargement regroupant plusieurs commandes" est un besoin. Tant que le projet travaille sur la solution demandée plutôt que sur le besoin, chaque atelier ajoute des développements, et le périmètre s'élargit sans que personne ne l'ait décidé.

Le terrain est d'autant plus favorable que les objectifs de départ sont flous. Un projet lancé pour "moderniser le système d'information" ou "gagner en efficacité" ne fournit aucun critère pour trancher. Sans cible mesurable, toute demande peut se justifier.

Dérive, clarification ou oubli: trois situations à distinguer

Tout ce qui s'ajoute en cours de projet n'est pas de la dérive.

Avant de dire oui ou non, il faut qualifier la demande, car chaque cas appelle un traitement différent.

La dérive réelle

Un souhait nouveau apparaît en cours de route, sans lien avec les objectifs validés: un portail fournisseurs "tant qu'on y est", un tableau de bord supplémentaire. Elle relève d'un arbitrage, d'une phase ultérieure ou d'un avenant.

La clarification

Un besoin déjà validé se précise: la règle exacte de calcul d'un tarif, le détail d'une étape de préparation. C'est le fonctionnement normal d'un projet, et elle s'absorbe dans le périmètre existant.

L'oubli de cadrage

Un besoin qui existait dès le départ a échappé à l'analyse, par exemple une contrainte réglementaire de traçabilité. Ce n'est pas un caprice métier mais une erreur d'analyse, qui se traite avec le sponsor, sans chercher de coupable.

La demande du responsable des expéditions relevait d'une quatrième catégorie, la plus fréquente et la plus trompeuse, l'habitude présentée comme un besoin. Elle mérite une écoute attentive, puis une négociation sur la forme.

Les signaux qui doivent alerter

Certains signaux permettent de repérer la dérive avant qu'elle ne pèse sur le calendrier. Le premier est le vocabulaire: "comme avant", "identique à l'ancien système", "on a toujours fait comme ça".

Le deuxième est la zone touchée: une demande qui modifie une validation, un calcul de stock, de coût ou de comptabilité n'est jamais une petite demande, quelle que soit la simplicité de l'écran qui la porte.

Viennent ensuite les signaux de pilotage: un nombre d'écarts de l'analyse fit-gap qui continue d'augmenter après la validation de la conception, des estimations de charge qui gonflent d'un comité à l'autre, des demandes acceptées en atelier sans chiffrage, et des phases qui s'allongent sans cause technique identifiable.

La part de responsabilité de l'intégrateur

La dérive n'est pas l'affaire des seules directions métier.

Une part importante naît chez l'intégrateur. En atelier, le consultant à qui l'on demande si une fonction est réalisable répond volontiers "c'est faisable", ce qui est presque toujours vrai techniquement. L'utilisateur, lui, entend "c'est prévu".

Le mode de contrat accentue le phénomène. Au forfait, chaque ajout non chiffré se paie en marge ou en qualité, et l'avenant que personne n'ose ouvrir finit par peser sur la relation. En régie, le compteur tourne et la dérive se voit moins, jusqu'à la facture. Dans les deux cas, le rôle du consultant expérimenté est de dire ce que coûte une demande, y compris quand la réponse déplaît.

Ce que coûte vraiment une dérive

Le coût d'un développement ne s'arrête pas à sa réalisation. Il faut le tester, le documenter, former les utilisateurs, puis le maintenir à chaque montée de version de l'ERP. Une modification de la validation des expéditions aurait imposé de retester l'ensemble des flux de stock à chaque mise à jour, pendant toute la durée de vie du système.

Le coût humain est tout aussi réel. Quand la cible se déplace sans cesse, l'équipe projet perd de vue la ligne d'arrivée, la date de démarrage est repoussée plusieurs fois et le projet perd sa crédibilité auprès de l'organisation. À ressources constantes, chaque ajout se finance enfin en raccourcissant les tests, et l'on obtient un système qui couvre tout de façon approximative plutôt qu'un périmètre maîtrisé de façon solide.

Tenir le périmètre sans braquer les métiers

Le refus pur et simple fonctionne rarement, l'utilisateur éconduit contourne le système ou freine son adoption. Quelques pratiques permettent de tenir le périmètre tout en restant à l'écoute.

Reformuler la solution en besoin

À chaque demande, la première question porte sur ce que l'utilisateur cherche à accomplir, pas sur l'écran qu'il décrit. C'est souvent là que se trouve le compromis.

Séparer l'interface du moteur

Adapter une fenêtre, une liste ou un raccourci coûte peu et reste local. Modifier une validation, un calcul de stock ou une écriture comptable engage tout le système. Cette frontière est la plus utile à défendre, et c'est elle qui a permis de sortir par le haut dans le cas des expéditions.

Poser la bonne question au sponsor

"Qu'est-ce qui, absent au démarrage, empêche de facturer, d'expédier ou de clôturer le mois?" Ce qui ne passe pas ce filtre peut attendre une phase ultérieure.

Appliquer la règle d'une entrée pour une sortie

Après la validation de la conception, toute demande ajoutée indique ce qu'elle remplace ou ce qu'elle décale.

Réserver une enveloppe de périmètre.

Une réserve de charge visible par le comité de pilotage rend l'arbitrage concret. Quand elle est consommée, les nouvelles demandes attendent.

Tenir un registre des demandes

Chaque demande y est qualifiée, chiffrée et arbitrée. Celles qui sont reportées figurent dans une liste de phase 2 présentée à chaque comité, pour que le report ne soit pas vécu comme un rejet.

Conclusion

Le scope creep ne naît presque jamais d'une mauvaise intention. Il naît de demandes légitimes, formulées sous forme de solutions, que personne ne prend le temps de requalifier. Le responsable des expéditions n'avait pas tort de vouloir travailler efficacement. Il avait simplement décrit son ancien outil au lieu de son besoin.

Maîtriser le périmètre ne consiste donc pas à dire non, mais à savoir ce que l'on protège, le standard, le calendrier et la capacité de l'équipe à livrer.

Au prochain comité de pilotage, un exercice simple suffit pour commencer. Ouvrir la liste des demandes acceptées depuis la validation de la conception, et compter celles qui ont été chiffrées avant d'être acceptées.