Recueillir efficacement les besoins
CHAPITRE 3
79
La nature même des relations entre les acteurs est source de mauvaise communication :
les relations contractuelles, avec les concepts de maîtrise d’ouvrage et de maîtrise
d’œuvre – particularisme français qui fait d’ailleurs notre fierté !–, sont érigées comme
un rempart en cas de litige. Les acteurs se protègent derrière cette répartition des rôles
pour ne pas être montrés du doigt ; l’énergie est alors consommée pour savoir comment
« faire pour que l’échec du projet ne me soit pas imputé », alors qu’elle serait utilement
exploitée à déterminer les moyens de « faire en sorte que le projet n’échoue pas ».
Le constat est réel : les problèmes de communication et d’organisation sont à l’origine de
bien des écueils.
L’illusoire exhaustivité
Cependant, la démarche de projet est, en elle-même, responsable de ces écueils. Dans
une démarche traditionnelle, on vise un recensement exhaustif des besoins, avant de
commencer à élaborer et construire la solution.
On demande au client un exercice « surhumain » : décrire sur papier le produit qu’il
imagine ; il doit conceptualiser, mais pour rendre concret ce produit, il étaye avec beaucoup de détails, donnant ainsi corps à son produit. Cette recherche de l’exhaustivité à tout
prix conduit le client à demander plus, à demander tout, par crainte de ne plus pouvoir
faire évoluer son produit par la suite ; il sait qu’il n’aura jamais ce qui n’est pas décrit.
Alors il préfère prendre le risque de sur-spécifier, sans une évaluation préalable de la
pertinence des demandes, plutôt que de se voir reprocher d’avoir oublié un détail. De
toute façon, on ne le blâmera jamais pour la longueur et la précision de ses besoins ! Et
l’on arrive souvent à une situation où cette phase de recueil des besoins n’en finit pas…
et entame déjà considérablement le crédit de jours disponibles pour la réalisation.
L’on sait pourtant que contraindre le client à exprimer au début du projet des besoins
encore diffus dans son esprit l’amènera inévitablement à modifier ses attentes en cours de
projet, en particulier lorsque le produit commencera à prendre forme.
La défaillance du client
À l’opposé, on voit certains projets où l’expression des besoins est réduite au strict minimum, où le développeur doit exprimer, lui-même, les besoins des utilisateurs non disponibles. Cette phase de recueil risque alors d’être biaisée.
Pourquoi les utilisateurs ne sont-ils pas disponibles ? Souvent, parce qu’en haut lieu, par
manque de réalisme – par méconnaissance ? –, on ne leur concède pas cette disponibilité.
Le lancement de nombreux projets, sans qu’ait été précisément évalué le retour sur investissement, amène le client à abdiquer ; sa non-disponibilité traduit un manque d’intérêt
pour le projet lui-même qui ne lui rapporte pas assez, au regard du coût de sa participation.
Non-disponibilité, mais aussi absence de formation ad hoc pour le client qui ne maîtrise
pas les techniques ni les outils pour exprimer ses besoins. Malgré sa bonne volonté, ses
compétences – il est opérationnel dans son domaine –, il ne sait pas toujours rédiger un
cahier des charges, il ne connaît pas toujours le déroulement d’un projet. Une plus grande
GestProjInform Livre Page 79 Vendredi, 3. avril 2009 12:07 12
CHAPITRE 3
79
La nature même des relations entre les acteurs est source de mauvaise communication :
les relations contractuelles, avec les concepts de maîtrise d’ouvrage et de maîtrise
d’œuvre – particularisme français qui fait d’ailleurs notre fierté !–, sont érigées comme
un rempart en cas de litige. Les acteurs se protègent derrière cette répartition des rôles
pour ne pas être montrés du doigt ; l’énergie est alors consommée pour savoir comment
« faire pour que l’échec du projet ne me soit pas imputé », alors qu’elle serait utilement
exploitée à déterminer les moyens de « faire en sorte que le projet n’échoue pas ».
Le constat est réel : les problèmes de communication et d’organisation sont à l’origine de
bien des écueils.
L’illusoire exhaustivité
Cependant, la démarche de projet est, en elle-même, responsable de ces écueils. Dans
une démarche traditionnelle, on vise un recensement exhaustif des besoins, avant de
commencer à élaborer et construire la solution.
On demande au client un exercice « surhumain » : décrire sur papier le produit qu’il
imagine ; il doit conceptualiser, mais pour rendre concret ce produit, il étaye avec beaucoup de détails, donnant ainsi corps à son produit. Cette recherche de l’exhaustivité à tout
prix conduit le client à demander plus, à demander tout, par crainte de ne plus pouvoir
faire évoluer son produit par la suite ; il sait qu’il n’aura jamais ce qui n’est pas décrit.
Alors il préfère prendre le risque de sur-spécifier, sans une évaluation préalable de la
pertinence des demandes, plutôt que de se voir reprocher d’avoir oublié un détail. De
toute façon, on ne le blâmera jamais pour la longueur et la précision de ses besoins ! Et
l’on arrive souvent à une situation où cette phase de recueil des besoins n’en finit pas…
et entame déjà considérablement le crédit de jours disponibles pour la réalisation.
L’on sait pourtant que contraindre le client à exprimer au début du projet des besoins
encore diffus dans son esprit l’amènera inévitablement à modifier ses attentes en cours de
projet, en particulier lorsque le produit commencera à prendre forme.
La défaillance du client
À l’opposé, on voit certains projets où l’expression des besoins est réduite au strict minimum, où le développeur doit exprimer, lui-même, les besoins des utilisateurs non disponibles. Cette phase de recueil risque alors d’être biaisée.
Pourquoi les utilisateurs ne sont-ils pas disponibles ? Souvent, parce qu’en haut lieu, par
manque de réalisme – par méconnaissance ? –, on ne leur concède pas cette disponibilité.
Le lancement de nombreux projets, sans qu’ait été précisément évalué le retour sur investissement, amène le client à abdiquer ; sa non-disponibilité traduit un manque d’intérêt
pour le projet lui-même qui ne lui rapporte pas assez, au regard du coût de sa participation.
Non-disponibilité, mais aussi absence de formation ad hoc pour le client qui ne maîtrise
pas les techniques ni les outils pour exprimer ses besoins. Malgré sa bonne volonté, ses
compétences – il est opérationnel dans son domaine –, il ne sait pas toujours rédiger un
cahier des charges, il ne connaît pas toujours le déroulement d’un projet. Une plus grande
GestProjInform Livre Page 79 Vendredi, 3. avril 2009 12:07 12