Tout projet, avant même l’écriture de la première ligne de code, commence obligatoirement par la phase dites de « conception de projet ». La conception de projet pourrait être divisée en plusieurs parties :

• La définition du besoin
• L’écriture du cahier des charges
• La conception de la maquette et du story board
• La répartition des ressources et le planning.

Ici, nous nous intéresseront plus particulièrement aux deux premiers points de la conception du projet, en l’occurrence, la définition du besoin et l’écriture du cahier des charges qui en découle. En effet, loin d’être anecdotique, cette partie est l’une des plus cruciale et malheureusement parfois trop vite oubliée. J’ai moi même assisté à un projet à plusieurs centaines de milliers d’euros, voué à l’échec et abandonné car les développements étaient complétement en incohérence avec la demande du client. Le cahier des charges était largement incomplet et imprécis, les développeurs ont donc interprété les demandes du client, et à la livraison, le logiciel présentait d’énormes écarts fonctionnels avec les besoins initiaux du client. Résultat, un logiciel ne répondant pas aux règles métiers, inexploitable pour le client, et beaucoup de temps passé par l’entreprise de développement. Alors, évidemment, un bon cahier des charges ne fait pas un bon logiciel. Mais ce qui est sûr c’est qu’un mauvais cahier des charges peut très vite faire un mauvais logiciel. Car, aussi rapide et beau qu’il pourra être, s’il ne répond pas au besoin initial, il sera complétement inutile et inexploitable.

Afin d’éviter ce type d’échec, il est donc crucial de bien aborder la phase de découverte du besoin. Prenons le cas par exemple, d’un logiciel de gestion d’approvisionnement.

Il est important de bien appréhender les règles métiers de l’entreprise. Les questions que l’on pourrait poser au client seraient :

• est-ce que vous travaillez avec plusieurs devises monétaires?
• Est-ce que vous travaillez en FIFO (First In First Out)
• Est-ce que un même article peut avoir plusieurs codes barres dans sa durée de vie?
• Comment gérez vous vos ruptures?
• Combien de personnes vont utiliser le logiciel?
• Etc…

Parfois, de simple questions peuvent paraitre anecdotiques ou sans importance. Mais lors d’un échange avec le client, certains points seront tellement logique pour lui qu’ils ne pensera pas à vous les préciser. Alors, mieux vaut se renseigner.

Prenons un exemple concret pour illustrer ce point. L’entreprise se sert de son logiciel pour acheter des pots de Nutella. Lors de la définition du besoin, on constate que le fournisseur de Nutella est l’entreprise Ferrero, qui fabrique le Nutella. Au moment du développement, on affecte bien un fournisseur à un article. D’autant plus que pour le développeur, il est tout a fait normal que ce soit Ferrero qui livre du Nutella, ce sont eux qui le fabriquent après tout! A la livraison du logiciel, la personne qui passe les commande veut ajouter un fournisseur à son pot de Nutella. Car elle, elle connait des grossistes qui revendent également des pots de Nutella. Oui mais, problème, la gestion du multi-fournisseur pour un même article n’a pas été prévu dans le développement. Se pose alors un réel problème fonctionnel et une remise en cause du développement. Hors, si ce point avait été abordé à l’initiation du projet et pris tout de suite en compte dans le développement, cela n’aurait pas été compliqué à mettre en place. Par contre, refaire la structure parce que finalement la conception ne correspond pas est une autre paire de manche!

Il ne faut pas hésiter également, dans la mesure du possible, à interviewer différentes personnes dans l’entreprise. Toutes n’ont pas la même utilisation d’un même logiciel!

Une fois cette phase « d’enquête » menée, vous pourrez passer à l’élaboration du cahiers des charges. Ce document va reprendre de façon écrite tous les besoins et toutes les règles métiers que vous a décrit l’entreprise. Ce document permet, non seulement d’avoir une trace de ce qui a été validé en cas de questionnement durant la phase de développement, mais en plus c’est ce qui fera foi en cas de litige.

Et, finalement, ce n’est qu’une fois ces deux étapes correctement effectuées, que l’on pourra passer à l’élaboration de la maquette et au chiffrage et répartition des ressources. Car, tant qu’on ne sait pas de quoi on a besoin, comment le dessiner?

---