R publique Tunisienne
Minist re de lEnseignement Sup rieur,
de la Recherche Scientifique et de la Technologie
--
Universit de Carthage
D partement
Informatique
Facult des
Sciences de Bizerte
GUIDE POUR LE CAHIER DES CHARGES
R sum : Le cahier des charges est un pr alable tout projet informatique. Etude de
lexistant, analyse des besoins, sp cifications des caract ristiques fonctionnelles, cadre
juridique : autant daspects quil faut ma triser pour un projet r ussi.
1. Pourquoi un cahier des charges ?
Le projet informatique fait partie de la vie dun service de documentation. Quil sagisse de la
mise en place de son syst me de gestion ou de son remplacement, de la cr ation dun site
Web ou dun portail, de lint gration des ressources num riques, dun projet d dition ou de
num risation, le professionnel doit savoir pr parer une telle d marche.
Pour r ussir, tout projet doit suivre une logique dans laquelle le cahier des charges tient un
r le particulier. Mais comment sy prendre ? Voici quelques conseils pratiques.
1.1. Lenvironnement projet
Sans cahier des charges, pas de projet. Mais sans lenvironnement particulier dun projet, le
cahier des charges na pas de sens. Or, le projet informatique suit sa propre logique :
Dans cet environnement, le cahier des charges remplit trois r les diff rents.
1
1- il d crit un fournisseur potentiel ce quon attend de lui : Synth se de toute la
Publicité
r flexion (...) m thodologique, (il) est le bilan de la d finition des besoins sp cifiques et des
contraintes propres (...) (Duchemin 2000, p313). Accessoirement, il contribue galement la
d finition des crit res de s lection du prestataire.
2- le contenu du cahier des charges est int gr dans le contrat ou march . Lengagement
sur la r alisation des sp cifications techniques et le planning devient ainsi contraignant.
3- le cahier des charges permettra, sous forme de cahier de recette, d valuer
lad quation entre la r ponse du titulaire et les besoins exprim s.
1.2 Les Objectifs
Le cahier des charges est tout dabord un outil de communication et dinformation entre le
professionnel de linformation ( utilisateur ) et le prestataire de service. Les quatre objectifs
dun cahier des charges sont :
1- D finir les objectifs que doit atteindre la solution
2- Indiquer les contraintes respecter imp rativement
3- Etre un outil de dialogue entre les diff rents acteurs
4- Diminuer les risques derreur lors de la r alisation ou linstallation
2. Structuration du cahier des charges
Il ny a pas de plan type pour r diger un cahier des charges. Structure, pr cision et longueur
d pendent de limportance, de lobjet et du contexte du projet. N anmoins, m me si la
pr sentation et lordre peuvent varier, plusieurs l ments doivent n cessairement y figurer.
Lid e directive est dobtenir une structure de base qui aide comprendre ce quon attend du
projet . Tout ce qui, dans un texte, facilite la compr hension est bon prendre : une structure
claire et simple, des paragraphes courts, des sch mas et illustrations etc. Lors de la r daction,
on peut sinspirer dun mod le ou exemple. Mais attention, sinspirer ne veut pas dire copier,
et il faut surtout viter de flouer la sp cificit du projet en question.
2.1 L tude de lexistant
L tude de lexistant consiste mettre plat, de fa on aussi claire que possible, lanalyse
Publicité
qualitative et quantitative du fonctionnement actuel. Une analyse de lexistant comprend trois
parties distinctes :
1. La premi re consiste recueillir les informations ; elle est r alis e partir dentretiens ou
de questionnaires, tableaux de bords, catalogues, tudes, donn es statistiques etc.
2. La seconde consiste analyser, classer et donner une vue synth tique de lensemble des
informations collect es par domaine fonctionnel, en tenant compte des ressources humaines
2
(nombre et profil des personnes assign es aux diverses t ches).
3. La troisi me consiste esquisser une mod lisation grosses mailles des donn es et des
traitements.
L tat des lieux peut aboutir une critique de lexistant qui analyse les points positifs et
n gatifs de lorganisation du travail d j mise en place et d gage les am liorations apporter.
2.2 Lanalyse des besoins
Le besoin cest la n cessit ou le d sir prouv par un utilisateur. Ce besoin peut tre explicite
ou implicite, potentiel, avou ou inavou . Par cons quent, l tude des besoins consiste
d gager les crit res dinformatisation des diverses t ches, choisir celles qui sont
informatiser et valuer les gains de temps, d nergie et defficacit attendus (retour sur
investissement). Elle est r aliser sous forme de questionnaire.
Trois facteurs sont prendre en compte dans lanalyse :
1.
2.
Facteurs li s lapplication informatique elle-m me comme la dur e de vie de
lapplication, le champ de lapplication.
Facteurs li s la solution, comme la mise en place dun portail dinformation, la
gestion de ressources lectroniques.
3.
Publicité
Facteurs li s au projet comme les enjeux, le co t, les cr dits.
Ces facteurs sont prendre en compte avec lint gration de contraintes :
- Les contraintes organisationnelles, par exemple la gestion dun fonds g r sur plusieurs
sites.
- Les contraintes techniques comme lusage dun syst me dexploitation particulier ou un
syst me de gestion de bases de donn es (SGBD).
- Les contraintes humaines et administratives (comp tences, organigramme, planning).
3. Quest-ce quun bon cahier des charges ?
Le cahier des charges nest pas une garantie de succ s mais sans cahier de charges, la r ussite
devient al atoire. La r daction dun cahier des charges repose sur la r gle du PPCR .
R daction collective, relecture, comparaison avec dautres cahiers des charges sont quelques
conseils pour sassurer dune bonne qualit . De m me, lajout dun glossaire qui d finit les
termes et concepts cl s peut faciliter la compr hension.
Rappel : La date limite pour le d p t du cahier des charges est le mardi 16
f vrier 2016
3
Cette partie propose un exemple de structuration pour un cahier des charges dans le domaine
du logiciel. Ce n'est quun exemple g n ral qui pourra tre largement adapt en fonction des
particularit s des projets entrepris.
1. Pr sentation du projet
1.1 Contexte
Environnement dans lequel s'inscrit le projet (strat gie, enjeux, domaine, etc.)
1.2 Objectifs
R sultats que le projet doit atteindre.
1.3 Description de l'existant
Environnement logiciel et mat riel du logiciel.
Publicité
Syst me existant, le cas ch ant.
1.4 Crit res d'acceptabilit du produit
Proc dure de validation et Crit res d'acceptation.
2. Expression des besoins
2.1 Besoins fonctionnels
Fonctions (ou op rations, ou encore transformations) que le logiciel doit r aliser.
Les sp cifications fonctionnelles peuvent tre class es par importance.
2.2 Besoins non fonctionnels
Les sp cifications non fonctionnelles sont toutes les sp cifications qui n'expriment pas
une fonction du logiciel (contraintes de performance, syst me d'exploitation cible...).
3. Contraintes
3.1 Co ts
Budget allou au projet - Moyens mat riels et logiciels mis disposition.
3.2 D lais
Date de livraison du produit - Ech ances interm diaires.
3.3. Autres contraintes
Autres contraintes prendre en compte (normes techniques, clauses juridiques, etc.)
4. D roulement du projet
4.1 Planification
Articulation des grandes phases du projet et des principaux jalons.
4.2 Plan d'assurance qualit
Proc dures adopt es pour contr ler la qualit du logiciel.
4.3 Documentation
Description de la documentation devant accompagner le logiciel sa livraison.
4