Comment créer un cahier des charges

Etablir un cahier des charges est la première étape pour tout développement de logiciel.

Si le cahier des charges est incorrect ou même simplement incomplet, le développement sera difficile et la relation client/développeur le sera tout autant.

Et pourtant, en plus de vingt ans de carrière dans le développement de logiciels, j’ai beaucoup plus souvent vu des cahiers des charges bâclés, incomplets, incorrects, pour ne pas dire quasi inexistant que des cahiers des charges réellement utilisables pour un développement.

C’est vrai que lorsque le projet n’est pas très gros, l’étape du cahier des charges est souvent ignorée par le client, et il est impossible de la faire payer… Mais ne pas réaliser un cahier des charges précis dans un cas de ce genre ouvre la porte à tous les problèmes possibles pendant le développement.

Dans certains cas, cela vous fera même perdre le client.

Ainsi, il y a une dizaine d’années, j’ai été consulté pour développer un logiciel de calculs de statistiques sur les courses de chevaux (pmu). J’ignorais à ce moment la que j’étais en compétition avec d’autres société de développement, et j’ai simplement suivi ma méthodologie habituelle.

Après avoir consulté le client et effectué les différents allers retours nécessaires, je lui ai fourni un cahier des charges/devis de 26 pages, détaillant chaque fonction de son future logiciel, avec le temps nécessaire et le prix correspondant.

Quand il a accepté le devis, il m’a dit pourquoi il m’avait choisi plutôt que mes compétiteurs : son impression en lisant les devis était que j’étais le seul à avoir compris ce qu’il désirait…

Il m’a même montré leur devis : il y en avait quatre, et ils comprenaient tous entre une et deux pages. L’un d’entre eux indiquait simplement ‘réalisation d’un logiciel de statistiques sur le pmu’ et un prix.

Le temps passé à réaliser un cahier des charges complet et précis avait d’ores et déjà payé… J’avais obtenu le projet.

Ce même temps à bien sûr payé une deuxième fois pendant la phase du développement, le cahier des charges me fournissant le squelette logique de l’application.

Pourquoi si difficile ?

La difficulté initiale provient des deux faits suivants :

-         le client ne connaît rien à l’art de développer des logiciels
-         le développeur ne connaît pas (ou pas assez) le métier du client

La conséquence immédiate de ces deux faits est qu’aucun des deux ne peut établir un cahier des charges complet et précis tout seul. Une étroite collaboration est nécessaire.

L’établissement du cahier des charges doit en conséquence être perçue comme une phase d’exploration et d’explications.

Faire au comprendre  au client…

Le premier travail de l’analyste est de faire comprendre ces faits au client, et le deuxième de le persuader d’investir suffisamment de temps et d’argent dans cette étape essentielle au projet.

Je parles de temps et d’argent car établir un cahier des charges est un travail qui se paye (en tout cas que je fais payer) dés que le projet est un tant soit peu complexe.

Méthode

Je vais décrire ici la méthode que j’emploie (quand le client me laisse faire) pour réaliser cette étape. Je l’ai mise au point en plus de vingt ans de développement, et je peux donc vous assurer qu’elle fonctionne.

Bien sûr, en fonction de la taille du projet, cette méthode peut être simplifiée (il est clair que développer un logiciel destiné à être utilisé par une personne seule et un destiné à des groupes de 300 personnes ne doivent pas être traités avec le même niveau de complexité). Mais la méthode décrite ici fonctionne quel que soit le nombre de personnes impliquées dans le projet.

 

On peut décomposer ce travail en 4 phases principales :

- Description initiale
- Questions réponses
- Commentaires
- Chiffrage

L’établissement d’un cahier des charges implique beaucoup de transmissions d’informations entre différents intervenant chez le client et le développeur. Cette transmission peut bien sur se faire par courrier classique, mais cette méthode comporte de nombreux désavantages :

-         Transmission très lente (il y a déjà suffisamment de délais dus à au temps de réaction et de traitement de chaque intervenant)
-         Problèmes de recopies (il est nécessaire de recopier manuellement des éléments de chaque courrier pour y répondre)
-         Délais différents pour atteindre différents intervenant, limitant d’autant les interactions possibles

Pour toutes ces raisons, il est très préférable de communiquer par email. Le manque de formatage des emails peut par contre rendre les communications plus difficiles. Une solution hybride comme la réalisation de fichiers pdf envoyés en pièce attachée d’email est donc préférable. Si le client n’est pas équipé d’un système de création de fichier pdf, il est possible de lui faire installer un système gratuit comme Cute pdf (http://www.cutepdf.com) qui permet d’imprimer depuis n’importe quel logiciel dans un fichier pdf.

Voyons en détail ce que chaque phase implique.

Phase 1 : Description initiale

En général, ce travail est à réaliser par le client, en interne. Si le projet est relativement petit et/ou si un seul (ou un petit nombre d’) interlocuteur possède toutes les données chez le client, il est aussi possible de réaliser cette phase sous la forme d’une discussion (en personne ou par téléconférence).

A) Le but est de réaliser une description très générale des fonctionnalités nécessaires. Par exemple :

 1. Module de gestion des clients comprenant: fiche client, facturation, gestion des relances, gestion des mailings de prospections, ...
 2. Module de prise de rendez vous par client
 3. Module de gestion des courriers reçus/scan effectués/traitements effectués
 4. ...

Lorsque certain de ces traitements sont d’ores et déjà réalisés à la main ou avec un autre logiciel, il est recommandé de fournir des exemples réels de cas minimum, moyen et maximum (par exemple une facture comprenant une seule ligne, une facture de taille moyenne, une facture très longue). Pour répondre au souci de confidentialité des clients, il est tout à fait possible de noircir les noms et adresses des clients avant de les envoyer. Si le travail est effectué à distance, les documents peuvent être transmis par fax ou mieux encore sous forme de fichiers (pdf par exemple) ou images (provenant d’un scanner).

B) Il faut ensuite réaliser une description très générale de l'architecture matérielle nécessaire ou en place. Par exemple :

 1. Chaque groupe d'utilisateurs travaille de manière indépendant (pas de partage d'information entre les groupes).
 2. Chaque groupe est constitué de n utilisateurs (n typiquement entre 3 et 15 personnes) toute présentes dans le même local/dont certain sont équipés de laptops et travaillent de manière intermittente en local ou à distance/dont certain doivent pouvoir travailler de manière indépendant et synchroniser leur informations pour la raison suivante...etc.
 3. ...

Si l’architecture matérielle est déjà en place, il suffit de la décrire, et d’y ajouter les améliorations (s’il y en a) que la client désire voir correspondre à la nouvelle application. Un exemple fréquent est la mise en place d’un nouveau logiciel permettant à des représentant de prendre des commandes chez le client et de les transmettre facilement, la méthode en place étant encore le crayon et le papier. Cela implique un changement de l’architecture matérielle en même temps que le développement du logiciel correspondant.

Si elle n’est pas en place, il est la encore important d’exercer un rôle de conseil. Il faut demander au client une description en termes de qui fait quoi, où, et quand.

C) Il faut aussi faire une liste des correspondants principaux (et coordonnées / mail / téléphone) pour chacun des modules décrits en A . Il est en effet très rare qu'une seule personne connaisse de manière détaillée TOUS les aspects pratiques d'une organisation... Plusieurs correspondants peuvent bien sur être listés pour chaque module.

Les personnes listées ici seront responsables des informations détaillées transmises pour chaque module. Leur choix est donc très important.

Une fois que la phase 1 a été réalisée par le client (le résultat ne devrait pas être plus de 2 ou 3 pages), envoi du document résultant au consultant (moi).

Conditions particulières

Les conditions particulières peuvent faire partie du cahier des charges ou être mise en place dans un document séparé. Je ne rentrerai pas dans le détail ici de tout ce qu’elles peuvent impliquer. Comme leur nom l’indique, elles sont souvent spécifique à chaque projet. Il faut simplement penser à aborder ces sujets avec le client et à les formaliser dans un accord écrit.

Ces conditions peuvent concerner des domaines très divers, comme par exemple :

-         Le client veut une licence pour ses 40 divisions incluse dans le prix de développement
-         Le client veux la pleine propriété du source
-         Le client veut que les sources soient déposés chez un notaire de manière à être accessibles en cas de défaut du développeur
-         Le client veut que la maintenance logicielle soit inclus dans le prix de développement pour une durée de 1 an
-         Le client veut que le développeur du logiciel fournisse des prestations de support téléphonique 24/7
-         Le développement doit être effectué dans un délai maximum de…
-         Une description des méthodes d’implémentation, formation, mise à jour peut être fournie ici
-         La récupération de données provenant d’autres logiciels peut être décrite ici…

Une idée fausse très souvent rencontrée chez les client est que le fait de vous donner des informations permettant la réalisation du logiciel leur donne automatiquement des droits de propriétés intellectuelle, et que si le logiciel écrit pour eux est ensuite revendu comme un progiciel, ils ont automatiquement droit à un pourcentage sur les ventes.

Lorsque vous établissez un cahier des charges pour un client, et/ou plus tard lorsque vous fournissez le devis correspondant, vous devez donc aussi aborder ces sujets avec lui et formaliser les décisions prises par écrit.

Phase 2 : Questions réponses

 En me basant sur le document issu de la phase 1, je réalise une liste de questions sur les modules décrits en 1-A, une description plus technique sur l'architecture décrite en 1-B, et éventuellement une description technique et légale des conditions particulières décrite en D avec bien sur aussi des propositions de solutions alternatives, la description des problèmes que chaque solution implique, etc.

J'envoie les questions/propositions à chaque correspondant concerné (et au correspondant principal bien sur) grâce à la liste 1-C et j'effectue un suivant constant des réponses reçues (ou pas).

Au fur et à mesure de l'avancement de ce prcessus, je réalise un arbre des questions réponses consultable à tout moment par le correspondant principal et si désiré par les correspondants/module sous la forme d’une page web (non reliée à quoi que ce soit et protégée par un mot de passe pour des raisons évidentes de confidentialité), avec un arbre des étapes et des liens vers les documents correspondants.

Cette page va se présenter sous la forme suivante (par exemple). Chaque texte souligné est un lien vers le document correspondant. Les dates en rouge correspondent aux document en attente et permettent de visualiser d’un coup d’œil l’avancement des travaux et ce qui reste à faire.

Le délai entre la date d’envoi et le moment ou la réponse est attendue est en général d’une semaine, de manière à laisser aux intervenants le temps de traiter le problème en plus de leur charge de travail normale sans pénaliser le temps de réalisation du cahier de charges. Ce délai est en général discuté avec le client au tout début du processus. Il peut être raccourci ou allongé en fonction des circonstances.

1. Module de gestion des clients comprenant:

            1.1 Fiche client (13 mai 2006)
                        Envoyé à M.X (13 mai 2006). Réponse attendue avant le 20 mai 2006
                        Envoyé à M. Y (13 mai 2006). Réponse attendue avant le 20 mai 2006

             1.2 Facturation (13 mai 2006)
                        Envoyé à M. Z (13 mai 2006).
                              Réponse reçue le 18 mai 2006
                        Envoyé à M. Y (13 mai 2006). Réponse attendue avant le 20 mai 2006

             1.3 Gestion des relances (13 mai 2006)
                        Envoyé à M. A (13 mai 2006).
                                    Réponse reçue le 20 mai 2006
                                               Questions complémentaires (délais et textes des lettres) envoyé à M. A (22 mai 2006). Réponse attendue avant le 29 mai 2006
                        Envoyé à M. Y (13 mai 2006). Réponse attendue avant le 20 mai 2006

            1.4 Gestion des mailings de prospections (13 mai 2006)
                        Envoyé à M. B (13 mai 2006). Réponse attendue avant le 20 mai 2006
                        Envoyé à M. Y (13 mai 2006). Réponse attendue avant le 20 mai 2006

 2. Module de prise de rendez vous par client (14 mai 2006)
                        Envoyé à M. C (14 mai 2006). Réponse attendue avant le 21 mai 2006
                        Envoyé à M. D (14 mai 2006). Réponse attendue avant le 21 mai 2006
                                   Réponse reçue le 19 mai 2006
                        Envoyé à M. E (14 mai 2006). Réponse attendue avant le 21 mai 2006
                        Envoyé à M. Y (14 mai 2006). Réponse attendue avant le 21 mai 2006

 3. Module de gestion des courriers reçus/scan effectués/traitements effectués (14 mai 2006)
                        Envoyé à M. F (14 mai 2006). Réponse attendue avant le 21 mai 2006
                        Envoyé à M. Y (14 mai 2006). Réponse attendue avant le 21 mai 2006

 4. ...

Chaque fois qu’une réponse est reçue, je modifie la page pour le signaler, mets en place un lien vers le texte de la réponse, éventuellement soumets des questions complémentaires, et incorpore les informations obtenues dans le chapitre correspondant du cahier des charges.

Si une date de réponse attendue est dépassée, je relance le correspondant en retard et signale le fait au correspondant principal. Ce système permet en général d’obtenir les réponses dans un délai raisonnable. Tant que la réponse n’est pas obtenue, des relances régulières sont faites, par email et par téléphone. Il s’agit ici d’obtenir des réponses sans s’aliéner les correspondants qui sont en général en retard du fait de leur charge de travail, pas par mauvaise volonté…

Cette phase comprend autant de cycles que nécessaire et produit à chaque cycle un cahier des charges plus précis et complet.

A ce stade la liste de départ est devenue beaucoup plus détaillée (par exemple, la gestion des relances comprend des sous chapitres pour chacun des types de relances successives, avec délai, textes, actions à effectuer, etc.) et chaque ligne de la liste inclut un texte de description aussi précis que possible, avec écrans de maquettes quand cela est nécessaire).

Lorsque le cahier des charges atteint un niveau de cohérence suffisant (c'est à dire quand je n'ai plus de questions restées sans réponse), il est recommandé de passer par une phase de commentaires par les futurs utilisateurs:

Phase 3 : Commentaires

Cette phase n'est pas OBLIGATOIRE, mais elle assure que des problèmes non jugés important par les (ou inconnus des) décisionnaires mais qui bloquent les utilisateurs tous les jours puissent être incorporés, et que l'expérience de la vie pratique de l'entreprise puisse avoir une chance d'être utilisée dans le futur outil :

 A) Le cahier des charges étant dés le départ organisé en modules correspondant aux différentes activités listés en 1-A, chaque partie est envoyée (encore une fois, sous forme de fichier pdf) à :

- Soit tous les utilisateurs concernés
- Soit un groupe d'utilisateurs créé par sélection des individus les plus performants dans chaque branche, par demande de volontaires, etc.

La deuxième méthode est en générale plus efficace, sachant que les utilisateurs en question seront aussi plus tard nécessaires dans la phase de test.

Chaque destinataire dispose d'un temps prédéterminés pour lire et commenter les informations reçues. Si les utilisateurs ne comprennent pas le document reçu ou certaines parties de celui ci, ils posent des questions sur ce qui n'est pas clair pour eux, et ces questions sont souvent aussi révélatrices de problèmes que des commentaires précis.

Encore une fois, je réalise un arbre sur le web visible par les correspondants principaux dans chaque module avec les noms des destinataires, les dates de réponses attendues, les réponses reçues des utilisateurs, et éventuellement, dans le cas de questions, les dialogues engagés...

Suivant la culture d’entreprise en place, il est parfois difficile d’impliquer les utilisateurs. Pour améliorer les retours d’information, il est dans ce cas nécessaire de mettre en place une boite à idées anonyme.

 B) Une fois la partie A terminée (module par module), je réalise un résumé des demandes/questions/commentaires et le soumets à chacun des correspondants principaux avec bien sur mes propres réflexions sur chaque demande.

Les envois de documents, dates de réponses attendus, etc., sont aussi visibles sur le l'arbre du site web.

Une fois que les réponses sont reçues, les modifications nécessaires/voulues correspondantes sont incorporées au cahier des charges et cette phase est répétée pour vérifier au niveau des utilisateurs que les solutions trouvées ne génèrent pas d’autres problèmes.

Plusieurs cycles successifs sont souvent nécessaires à ce niveau pour obtenir une solution qui obtienne le support actif des utilisateurs.

Réussir à obtenir ce support actif signifie que les utilisateurs vont être impatient de pouvoir utiliser le nouveau système et donc que l'on constatera beaucoup moins de résistance au moment de la mise en place du logiciel.

Cet aspect de la réalisation d'un logiciel est largement sous estimé par beaucoup de développeurs et en général TOTALEMENT ignoré par les clients avant leur première expérience de déploiement (et souvent même après, étant donné qu'il est beaucoup plus facile de blâmer l'équipe de développement pour les problèmes de déploiement que d'accepter le fait que les employés de la compagnie font de la résistance).

Une fois cette phase terminée, on obtient un cahier des charges qui est soumis aux différents correspondants pour approbation. Encore une fois, un arbre de soumission/approbation est disponible sur le web pour permettre de suivre le déroulement de cette phase. Normalement, à ce niveau, et sauf erreur flagrante dans une des phases précédentes, l’approbation par les différents correspondant est une formalité.

Il faut préciser que chaque module peut comprendre différentes options parfois incompatibles les unes avec les autres. Des fonctionnalités peuvent être décrites qui sont optionnelles, souhaitées, mais dont la réalisation ne sera effectuée que si le budget le permet, ou dans un deuxième temps.

Phase 4 : Chiffrage

D’accord… Le chiffrage ne fait pas à proprement parler partie de l’établissement du cahier des charges… Il est l’étape suivante de celui-ci.

Il est d’ailleurs clair qu’une fois le cahier des charges établi, rien n’empêche le client de l’utiliser pour faire un appel d’offre et de faire ensuite exécuter le développement par quelqu’un d’autre. C’est même souvent le cas lors de gros projets.

C’est seulement lorsque le cahier des charges atteint ce niveau de précision qu’un chiffrage des coûts de développement PRECIS peut être effectué...

L’expérience nous montre toutefois que même en prenant toutes ces précautions, lors de la phase d’implémentation, des modifications seront soit demandées par le client/les utilisateurs soit rendus nécessaires par des problèmes techniques non envisagés dans les phases précédentes.

Lorsque je soumets une proposition chiffrée à un client, le chiffrage est final si le module est réalisé en conformité avec le cahier de charges. Si des modifications sont nécessaires du fait d’une erreur de ma part, elles sont gratuites. Si des modifications sont demandées par le client, elles sont chiffrées précisément et payantes (sauf si mineures, mais le nivaux de difficulté est déterminé par moi, la simplicité apparente d’une modification demandée entraînant souvent beaucoup de changement en profondeur).

Ces conditions sont celles que j’applique en général. Elles donnent à chaque partie un niveau de sécurité important : ce qui sera réalisé est ce qui est décrit dans le cahier des charges.

Nombreux sont les cas de dépassement de devis dans l’industrie informatique. Ces dépassement sont très souvent dus à un cahier des charges mal fait, parfois entièrement en interne et dans un nombre de cas alarmant remplis d’erreurs, de descriptions incomplètes et de références à des informations non fournies dans le cahier des charges lui même ou dans ses annexes.

Il est clairement impopulaire de renvoyer un cahier des charges de ce type au client potentiel en lui expliquant que le document en question est quasi inutilisable… Mais si vous ne le faites pas et que vous acceptez le travail, attendez vous à une relation développeur/client plus que chaotique.

Consulting

J’espère que ce document sera utile à certain d’entre vous comme cadre de travail.

N’oubliez pas que si vous le désirez, je peux réaliser ce cahier des charges pour vous. Je peux travailler en direct avec un client pour établir le cahier des charges qui sera utilisé pour un appel d'offre, ou sous-traiter l'étape de réalisation du cahier des charges pour un confrère développeur.

Pour quel prix ?

Clairement, cela dépend de la complexité du projet, du nombre de correspondants à gérer, etc.

Deux types de facturation sont possibles :

-         au temps réel : Pour chaque document réalisé, envoyé, réponse lue, incorporée au cahier des charges , publiée sur le web, etc., le temps passé réel est consigné et régulièrement publié sur une page à part sur le web pour le correspondant principal. Chaque semaine (ou mois, selon les conditions négociées), une facture contenant le décompte en question est envoyée et des paiement successifs sont effectuées au fur et à mesure. C’est en général la méthode utilisée pour les gros projets, lorsqu’il n’est pas possible d’évaluer dés le départ la somme de travail nécessaire.

-         Au forfait : Lors de la réception de la description initiale, et si le projet n’est pas trop complexe, j’établis un montant forfaitaire et un échéancier de paiement en me basant sur mon expérience pour estimer le temps nécessaire.