République Tunisienne Ministère de l’Enseignement 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 l’existant, analyse des besoins, spécifications des caractéristiques fonctionnelles, cadre juridique : autant d’aspects qu’il faut maîtriser pour un projet réussi.
1. Pourquoi un cahier des charges ? Le projet informatique fait partie de la vie d’un service de documentation. Qu’il s’agisse de la mise en place de son système de gestion ou de son remplacement, de la création d’un site Web ou d’un portail, de l’intégration des ressources numériques, d’un 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 s’y prendre ? Voici quelques conseils pratiques.
1.1. L’environnement projet
Sans cahier des charges, pas de projet. Mais sans l’environnement particulier d’un projet, le cahier des charges n’a 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 qu’on attend de lui : « Synthèse de toute la 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é. L’engagement
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
l’adéquation entre la réponse du titulaire et les besoins exprimés.
1.2 Les Objectifs
Le cahier des charges est tout d’abord un outil de communication et d’information entre le professionnel de l’information (« utilisateur ») et le prestataire de service. Les quatre objectifs d’un 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 d’erreur lors de la réalisation ou l’installation
2. Structuration du cahier des charges Il n’y a pas de plan type pour rédiger un cahier des charges. Structure, précision et longueur dépendent de l’importance, de l’objet et du contexte du projet. Néanmoins, même si la présentation et l’ordre peuvent varier, plusieurs éléments doivent nécessairement y figurer.
Publicité
L’idée directive est d’obtenir une structure de base qui aide à comprendre «ce qu’on 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 s’inspirer d’un modèle ou exemple. Mais attention, s’inspirer ne veut pas dire copier, et il faut surtout éviter de flouer la spécificité du projet en question.
2.1 L’étude de l’existant L’étude de l’existant consiste à mettre à plat, de façon aussi claire que possible, l’analyse qualitative et quantitative du fonctionnement actuel. Une analyse de l’existant comprend trois parties distinctes : 1. La première consiste à recueillir les informations ; elle est réalisée à partir d’entretiens 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 l’ensemble 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 l’existant qui analyse les points positifs et négatifs de l’organisation du travail déjà mise en place et dégage les améliorations à apporter.
2.2 L’analyse des besoins Le besoin c’est 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 d’informatisation des diverses tâches, à choisir celles qui sont à informatiser et à évaluer les gains de temps, d’énergie et d’efficacité attendus (retour sur investissement). Elle est à réaliser sous forme de questionnaire. Trois facteurs sont à prendre en compte dans l’analyse :
1.
2.
Facteurs liés à l’application informatique elle-même comme la durée de vie de
l’application, le champ de l’application.
Facteurs liés à la solution, comme la mise en place d’un portail d’information, la
gestion de ressources électroniques.
3.
Facteurs liés au projet comme les enjeux, le coût, les crédits. Ces facteurs sont à prendre en compte avec l’intégration de contraintes :
- Les contraintes organisationnelles, par exemple la gestion d’un fonds géré sur plusieurs
sites.
- Les contraintes techniques comme l’usage d’un système d’exploitation particulier ou un
système de gestion de bases de données (SGBD).
- Les contraintes humaines et administratives (compétences, organigramme, planning).
Publicité
3. Qu’est-ce qu’un bon cahier des charges ? Le cahier des charges n’est pas une garantie de succès mais sans cahier de charges, la réussite devient aléatoire. La rédaction d’un cahier des charges repose sur la règle du « PPCR ».
Rédaction collective, relecture, comparaison avec d’autres cahiers des charges sont quelques conseils pour s’assurer d’une bonne qualité. De même, l’ajout d’un 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 qu’un 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. 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
Publicité
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