Gestion de projet : quand faut-il tester avant de figer ?
Un projet doit transformer des attentes en engagements, sans traiter comme acquises des hypothèses encore fragiles. La question managériale est précise : quelles exigences faut-il éprouver avant de les figer dans un cahier des charges ?
Ce que la littérature établit
Kathleen M. Eisenhardt et Behnam N. Tabrizi (1995, Administrative Science Quarterly) distinguent, dans le développement de produits informatiques, une logique de compression d'étapes connues et une logique expérientielle fondée notamment sur les itérations et les essais. Leurs résultats indiquent que l'intérêt de ces approches dépend de l'incertitude du contexte. Accélérer un projet ne consiste donc pas toujours à exécuter plus rapidement une séquence déjà définie : cela peut demander d'apprendre plus tôt ce qui doit être développé.
Le mécanisme : rendre une hypothèse testable
Stefan H. Thomke (1998, Management Science) analyse l'expérimentation comme une activité de conception dont l'organisation et les moyens influencent le coût et le temps nécessaires pour apprendre. Un prototype n'est pas seulement une version incomplète du livrable : il peut servir à départager des solutions avant un engagement plus coûteux. Pour le responsable de projet, l'enjeu est de préciser l'incertitude que chaque essai doit réduire, plutôt que de multiplier les démonstrations.
La conclusion trop rapide
On pourrait en déduire qu'il faut remplacer les spécifications par des prototypes. Ces travaux ne justifient pas cette opposition : l'expérimentation aide à établir certaines exigences, tandis que leur formalisation reste nécessaire pour coordonner l'exécution et décider de l'acceptation. Une obligation réglementaire ne devient pas négociable parce qu'un prototype plaît aux utilisateurs. (nos formations pour cadres et collaborateurs)
Ce que ces données ne permettent pas de trancher
Ces articles portent sur le développement de produits et ne constituent pas une validation directe pour tous les projets de services. Un essai réalisé dans un environnement simplifié peut laisser invisibles des contraintes d'intégration, de sécurité ou de fonctionnement à grande échelle. La pratique courante ajoute une difficulté : une démonstration approuvée n'est pas nécessairement un test concluant si aucun critère d'acceptation n'a été fixé au préalable.
Une implication pratique, vérifiable à Genève
Dans le cadre du programme « Gestion de projet » de SHR, un exercice applicable à Genève consiste à choisir une exigence encore incertaine et à consigner, avant sa validation, l'hypothèse, le test et le critère d'acceptation. Selon le secteur, l'essai peut porter sur un parcours d'entrée en relation en banque privée, un circuit d'approbation dans une organisation internationale, une interface de traçabilité en horlogerie de luxe ou un transfert documentaire dans le négoce de matières premières, avec des données fictives si nécessaire. Pendant une phase pilote, mesurer la proportion d'exigences ainsi testées qui sont ensuite rouvertes pour inadéquation à l'usage, en conservant pour chacune la preuve du test et le motif de réouverture. Comparer ce taux à celui des exigences non testées sur la même période, en signalant les différences de complexité : ce rapprochement éclaire une décision locale, sans établir à lui seul un effet causal. Pour aller plus loin : découvrez la formation Gestion de projet à Genève, ou parcourez nos formations pour cadres et collaborateurs en Suisse.
En images : Gestion de projet à Genève
- gestion de projet
- Genève
- recherche
- formation genève