Conduite et Gestion de Projet - Cahier des charges

Sophie Toulouse
+33.1.49.40.40.73
toulouse@lipn.univ-paris13.fr

LIPN - Universit Paris 13

99 av. Jean-Baptiste Clment
93430 Villetaneuse - FRANCE

1 Introduction
L'accord contractuel entre le client et le fournisseur se fonde sur un cahier des charges qui dcrit
prcisment les objectifs et rsultats attendus. Le cahier des charges peut maner du client ou du
fournisseur : selon la culture du client et selon l'enjeu, le besoin peut tre exprim clairement, en
incluant mme des exigences en termes d'outils logiciels et mthodologies de dveloppement, ou au
contraire rester trs vague, en ne donnant que les ides directrices. Cependant, mme lorsque que le
client rdige un cahier des charges complet, il revient au fournisseur de rednir les objectifs dans la
rponse appel d'ore : c'est donc nalement toujours le cahier des charges manant du fournisseur
qui, contractuellement, fait foi, ce dernier document se rfrant au cahier des charges initial de sorte
montrer comment la fonctionnalit X propose par le fournisseur rpond bien au besoin Y nonc
par le client.

2 Analyse du contexte
Les phases d'analyse du besoin et de l'existant, allies la prise en compte des moyens en termes
de nances et de dlais, permettront d'baucher une solution concrte de ralisation. Le cahier des
charges a quatre vocations essentielles : la premire, d'ordre fonctionnel, consiste dcomposer le
besoin en fonctionalits ; la deuxime, d'ordre la fois oprationnel et organisationnel, consiste
identier les investissements ncessaires en environnement client pour l'intgration du produit au
terme du projet ; la troisime consiste dterminer les moyens ncesssaires (au service informatique
interne ou au prestataire) pour la ralisation du projet ; enn, la dernire consiste organiser et
plannier le droulement du projet.

2.1 Analyse du besoin

Appropriation du besoin client : il faut avoir compris le besoin et ses enjeux, le traduire en ses propres
termes. Cette premire analyse donne lieu une prsentation synthtique du besoin client.

2.2 Analyse de l'existant

Appropriation de l'environnement client : dcrire l'environnement technique et logiciel dans lequel
s'intgre le projet.

Pour proposer une solution, il faut avoir pleine connaissance de l'environnement technique et
logicel, voire humain (comptences) et organisationnel du client. Cette analyse permet, d'une part,
d'estimer les investissements lis la mise en place du projet (besoins de machines, de logiciels, de
formation), d'autre part d'avoir une premire ide de la conception globale du produit, de sorte
tre en mesure de dnir dans le cahier des charges son intgration au systme d'information client.

2.3 Estimation des contraintes (ce n'est pas une rubrique)

Les contraintes poses par le client doivent videmment tre prises en compte dans la rponse : le
client demande ce qu'un besoin donn soit satisfait, ventuellement dans un cerain budget, dans
une certain dlai. Or, les contraintes poses ne sont pas toujours ralistes, ne serait-ce que parce
que le client n'a pas l'expertise informatique, mais aussi pour mettre en comptition les prestataires
en cas d'appel publique. Le cahier des charges a donc vocation d'expertise : il propose une solution
sous forme de conseil et de prconisations. Il s'agira donc de faire un arbitrage entre, d'une part, le
degr de rponse au besoin et, d'autre part, les contraintes nancires et temporelles poses par le
client. De manire gnrale, il faut parvenir estimer, si elles ne sont pas clairement nonces, les
prfrences du client : objectif de qualit ou de dlai (arbitrage rponse totale aux besoin vs. rponse
adapte un dlai de ralisation), objectif de sret ou d'investissemet moindre cot (arbitrage
logiciel payant vs. logiciel libre).

2.4 Rponse qualitative

2.4.1 Rponse aux besoins fonctionnels
Aprs l'analyse du besoin, on apporte maintenant une solution de mise en uvre, fonctionnelle,
de ce besoin. Cela consiste dcomposer le besoin en fonctionnalits. Pour chaque fonctionnalit
identife, il faut expliquer sa mise en uvre du point de vue utilisateur. Selon l'arbitrage qui sera
fait entre satisfaction du besoin et prise en compte des contraintes nancires, il se peut que l'on
choisisse de ne pas raliser (ou seulement partiellement) certaines fonctionnalits : il faut toutefois
faire gurer celles-ci (indispensable), proposer malrg tout une solution, tout en prcisant que cette
solution pourrait faire, avec d'autres, l'objet d'un avenant au contrat.

2.4.2 Architecture et intgration au SI client

Les choix d'architecture tant fortement structurants, ils sont oprs ds la rponse appel d'ore et
doivent tenir compte de l'environnement client. Il s'agit donc, d'une part de dnir l'architecture de
la solution (ex. : client/serveur vs. n tiers, zone dmilitarise si application extranet, gestion des ux
si projet EAI etc.), d'autre part d'identier les interactions du produit ralis avec l'environnement
actuel : ux d'informations, bases de donnes, communication entre applications etc..

2.4.3 Exigences oprationnelles

Cette rubrique comporte les aspects transversaux du logiciel, notamment : performance, gestion
d'accs, gestion des erreurs. Il est essentiel de prciser les performances vises : rapidit d'un
traitement complexe, volumtrie d'une base de donnes et temps d'interrogation etc.. La gestion

des accs, or problmatique de scurit rseau, concerne la gestion de prols utilisateurs (sans entrer
dans le dtail des prols, simplement voquer le mode de gestion). Enn, le mode de gestion des
erreurs doit galement appartre explicitement.

2.4.4 Moyens matriels et logiciels

La mise en uvre de la solution prconise peut ncessiter l'achat de matriel et/ou de logiciels
informatiques. Par exemple, la conception d'un module d'aectation optimise des ressources un
logiciel de gestion des agents de conduite dans un rseau de bus pourra donner lieu l'achat d'une
machine ddie au calcul ainsi qu' celui d'une licence d'un outil d'optimisation du commerce.

2.4.5 Moyens humains et organisationnels

De mme que pour les aspects matriels, le projet peut avoir des implications humaines. Toujours
dans le cadre du module d'aectation optimise des ressources, s'il faut le dployer sur plusieurs
rseaux, il faudra envisager, non seulement la formation du personnel l'utilisation de l'outil,
ventuellement la formation de futurs formateurs, ventuellement encore un organe centralis de
support aux utilsiateurs.

2.4.6 Moyens fournisseur

Le fournisseur lui-mme doit dnir les moyens qu'il juge ncessaire de mettre en place pour mener
bien la ralisation de la solution prconise. Il doit ainsi prciser les moyens techniques de ralisation,
c'est--dire dnir l'environnement de dveloppement et, le cas chant, dnir une simulation de
l'environnement client. Par ailleurs, il doit prciser les comptences qu'il estime devoir mettre en
uvre : dveloppeurs qualis, architecte logiciel, architecte systme, expert fonctionnel etc., selon
les besoins. Parmi ces comptences, certaines peuvent tre sous-traites. Les CV (prols type ou
CV nominatifs) accompagnent la rponse. En plus des comptences techniques, il faut aligner des
comptences en termes de management et de suivi : chef de projet, directeur de projet.

2.5 Rponse quantitative

2.5.1 Moyens matriels et logiciels
Une fois les moyens dtermins, il convient d'en indiquer le prix, d'autant si le fournisseur se propose
de servir d'intermdiaire pour les achats.

2.5.2 Moyens humains et organisationnels

Le fournisseur doit chirer ses prestations de formation et de support ds lors qu'il les incorpore
sa rponse. Sinon, il revient au client de s'organiser : le rle du fournisseur s'arrte en ce cas la
prconisation.

2.5.3 Moyens fournisseur

Pour chaque comptence requise, qu'il s'agisse d'une comptence technique ou de management,
il faut estimer un nombre de jour-homme (JH), c'est--dire prciser : combien de jours de travail d'un dveloppeur java expriment sont-ils ncessaires la ralisation du projet, combien
de jours d'architecte logiciel, combien de jours d'encadrement etc.. Cela n'est pas possible sans
l'tablisssement d'un premier plan de charge, qui se fonde sur la rponse aux besoins fonctionnels,
la rponse technique, ainsi que sur l'organisation prvisionnelle du projet. La rponse fonctionnelle,
en listant les fonctionnalits qui seront ralises, permet d'estimer la charge de dveloppement ; la
rponse technique permet d'estimer la phase de conception globale, les besoins en termes d'expertise
en architecture etc.. Le plan de charge est gnralement compos de deux parties : chirage par
fonctionnalit (charge de dveloppement pur), charge par fonction hors fonction de dveloppement
(encadrement, expertises), charge par tape du projet hors phase de dveloppement (revue dtaille
menant aux spcications fonctionnelles, qualication, intgration l'environnement client, recette).

2.6 Organisation
Une fois les moyens identis, il convient de les organiser : dnir les phases du projet et leurs
chances, prciser le rle des intervants des direntes parties pour le suivi d'avancement, organiser
les runions du comit de pilotage. Les chances sont dnies partir du plan de charge mais on
peut, pour le suivi, ajouter des tapes intermdaires. De plus, la livraison des composants logiciels
peut tre organise en lots : par composant, par anage des fonctionnnalits disponibles etc.. Il
convient galement de priser

3 Proposition commerciale
Mettre un nombre en face de chaque prestation : par jour/homme par comptence, par achat matriel
et logiciel.

4 Clauses juridiques
Chacune des deux parties s'engage contractuellement sur des moyens metttre en uvre, un planning, des objectifs atteindre ; les clauses juridiques sont l pour se prmunir du risque de manquement ces engagements par l'une des deux parties en cas de conit.

5 Rubriques demandes aux quipes projet

On ne s'intresse pas : ni aux clauses juridiques, ni la porposition commerciale ; en revanche, les
moyens doivent tre identis et chirs (jours-homme). En annexe, vous pouvez joindre vos CV,
l'appel d'ore, ainsi que tout document qui vous semblera utile.

5.1 Analyse du contexte

5.1.1 Analyse du besoin
5.1.2 Analyse de l'existant

5.2 Rponse aux besoins

5.2.1 Fonctionnalits
5.2.2 Prconisations techniques
Architecture globale et intgration au SI client
Exigences oprationnelles
5.2.3 Investissement matriel et logiciel
5.2.4 Impacts organisationnels
5.2.5 Moyens fournisseur
Moyens matriels et logiciels
Moyens humains

5.3 Organisation