Le cahier des charges, la première étape vers un développement logiciel

Brouillon

À venir

0 commentaire

agreement-application-business-893894


Tout projet de développement informatique commence par un cahier des charges et ce quel que soit l’ampleur de ce projet : développement de logiciel sur mesure, développement d’un module, évolution d’un logiciel existant, etc.

Dès que le projet nécessite la création d’au moins une fonctionnalité, il devra être encadré par ce document. On parle d’ailleurs, dans le cadre de projet de développement sur mesure ou projet informatique, plus spécifiquement de cahier des charges fonctionnel (CDdF).

Le cahier des charges sert de base commune de discussion entre le commanditaire du projet et celui qui le réalisera, qu’il s’agisse d’une équipe interne ou d’une société de développement informatique.

Le cahier des charges est réalisé lors du lancement du projet de développement mais il servira tout le long de celui-ci. Ainsi, à la fin, il servira de référentiel entre le commandé et le livré.

Suivant la complexité du projet, des documents plus « macros » qui ne rentrent pas dans le même niveau de détail peuvent être établis :

- Le document de vision - périmètre, qui décrit les grands objectifs du logiciel à réaliser, notamment lorsque celui-ci est complexe (projet pluri-annuel)

- L’expression de besoin, qui décrit les grandes fonctionnalités à obtenir et les scénarios, sans entrer dans les détails d’un cahier des charges

Il est important de bien distinguer ces notions, car ces deux documents n’ont pas la même prétention, et il arrive souvent que des fonctionnels ayant rédigé une expression de besoin le qualifient de « cahier des charges ». Si ce niveau est déjà un bon point d’appui, une mission d’assistance à maitrise d’ouvrage pourra être nécessaire pour établir un cahier des charges.

Quels sont les enjeux de la réalisation du cahier des charges ?

Le cahier des charges est important pour le commanditaire du développement sur mesure comme pour le prestataire.

Pour le premier, il permet de bien définir ses besoins : un bon moyen de formaliser son projet avant de le réaliser. Il permet également de s’assurer que le résultat final qui lui sera livré sera conforme à ses attentes et qu’il prendra en compte ses contraintes.

Un aspect à ne pas négliger lorsque l’on sait que ces développements sur mesure peuvent représenter de véritables enjeux pour les entreprises.

Quant au second, son développement dépend avant tout du besoin client ; il ne peut donc pas commencer sans, sous peine de prendre un sérieux risque d’échec du projet.

Cela permet également à la société de développement (ou l’équipe interne) d’évaluer :

- le temps nécessaire pour réaliser le projet

- et ainsi réaliser le devis (puisque l’un est l’autre sont intimement liés).

Deux aspects qui intéresseront fortement le commanditaire du projet.

A l’inverse, un projet de développement informatique pourrait souffrir de l’absence de cahier des charges. Tout d’abord, le projet étant flou, le commanditaire risque fortement d’être déçu à la livraison.

De plus, si le cahier des charges n’est pas assez détaillé, on risque de mal évaluer le temps nécessaire à la réalisation du projet ce qui risque d’impacter le délai de livraison et les coûts.

Il se peut aussi qu’une évaluation réaliste du projet amène à l’aborder différemment : en réduire le périmètre, l’inscrire dans un calendrier plus long, s’appuyer sur un progiciel existant, ou tout simplement faire un « no go »

Que faut-il mettre dedans ?

Dans le cadre d’un développement sur mesure on parlera avant tout d’un cahier des charges fonctionnel et technique qui permet d’aborder tous les aspects nécessaires aux développeurs.

Concrètement, ce cahier des charges se traduit par un document qui peut être assez long en fonction du besoin et compartimenté en fonction des informations que l’on souhaite y voir apparaître.

Il permet de traiter des aspects du projets plus généraux :

- objectif

- contexte

- contraintes légales et réglementaires

- acteurs

- calendrier du projet

tout en détaillant de manière précise et exhaustive d’autres aspects fondamentaux :

- écrans,

- fonctionnalités,

- nombres d’utilisateurs,

- etc.

Cette partie plus détaillée est aussi la plus importante.

Cela n’est pas suffisant pour autant. Un minimum de cahier des charges technique doit être défini. Quel sera l’environnement de fonctionnement de l’application, comment devra-t-elle être opérée, exploitée, supportée et maintenue ? Devra-t-elle disposer d’interfaces avec d’autres applications (on parle d’API pour les interactions programmées).

Il peut être également nécessaire de spécifier le langage de programmation, s’il existe une contrainte sur ce point. Cela peut-être le cas, par exemple, lorsque le logiciel que l’on souhaite faire évoluer est déjà développé sous le langage .NET.

Le cahier des charges fonctionnel a été encadré par la norme AFNOR NF X50-151 qui a été remplacée par la norme NF EN 16271 qui décrit la mise en place du cahier des charges fonctionnel.

Établir ce cahier des charges permet de fixer les demandes d’un projet de logiciel sur mesure ou autre développement. Cela n’exclue pas une potentielle évolution plus tard : il s’agira d’un autre projet qui fera alors l’objet d’un autre cahier des charges.

L’évolution du cahier des charges : la méthodologie agile

La mise en place de la méthodologie Agile dans les processus de développement a eu un impact sur le cahier des charges. Il est devenu plus évolutif au fur et à mesure des itérations : chaque fonctionnalité peut, dans ce cadre, ne pas être décrite de manière détaillée au début du projet mais au début de chaque sprint.

La méthode ne renie donc pas le cahier des charges fonctionnel et sa nécessité, mais va plutôt modifier sa forme en lui permettant d’être complété alors que le projet est déjà commencé. Il peut également être constitué d’un ensemble de documents.

Avec un cahier des charges moins figé, on risque moins de se retrouver face à des fonctionnalités qui ne seront jamais utilisées par le commanditaire ce qui était le cas fréquemment lorsque le projet était géré en cycle en V. Cependant, cela rend plus difficile l’évaluation du temps et donc du coût du développement total.

C’est en général difficilement compatible avec une approche budgétaire figée et forfaitisée, dans la mesure où le principe même de ces méthodes est d’éviter l’effet tunnel, et d’affiner les arbitrages en coopération entre le responsable produit et l’équipe de réalisation.

Pour autant, l’un n’exclut pas totalement l’autre : on peut avoir une première version de cahier des charges en début de projet mais toujours fonctionner ‘en mode agile’ en le faisant évoluer. C’est ce qui se passe le plus souvent.

D’ailleurs, si vous confiez votre projet à une société de développement informatique, vérifiez bien que votre projet sera géré selon une méthode claire, qu’il s’agisse de respecter un cahier des charges strict selon un méthode en cascade, ou, de manière plus moderne, qu’il sera géré en méthode agile avec un processus d’arbitrage bien défini et des itérations clairement explicitées.

Notons tout de même que si le cahier des charges peut évoluer dans la durée, le projet ne peut commencer sans une expression de besoin relativement détaillée. Même en méthode agile, il est important d’avoir une idée de l’ampleur du projet pour un dimensionnement « macroscopique », sinon, il est impossible de décider du bon niveau d’investissement, de la taille d’équipe optimale et de la durée anticipée, ainsi que d’obtenir l’allocation des budgets par les décisionnaires.


Vous l’aurez compris, le cahier des charges fonctionnel ne doit pas être négligé lorsque l’on entame un projet de développement informatique. Privilégiez les sociétés de développement qui vous en parlent afin d’éviter toute déception une fois le projet terminé.

Pour toute information complémentaire, n’hésitez pas à nous contacter.

Florine GIllebert

Profil de l'auteur