Alain Collignon, INIST-CNRS, alain.collignon@inist.fr
Joachim Schöpfel, INIST-CNRS,
joachim.schopfel@inist.fr
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.
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 documentaire 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 de l’information doit savoir préparer une telle
démarche, choisir le prestataire, vérifier le résultat.
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 sans
réinventer la roue ou perdre du temps ? Comment éviter les écueils ?
Où trouver des renseignements, références et aides utiles ? Voici quelques
conseils pratiques.
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.
Etudes préalables Etudes de l’opportunité d’un
développement
spécifique
ou achat d’un progiciel
Définition
des besoins et de l’objectif du projet
Détermination
du budget et de la procédure
Cahier des charges Présentation
de l’existant
Description
des besoins
Spécifications
des caractéristiques fonctionnelles
Type
de logiciel ou de prestation
Choix Choix
de la procédure (appel d’offres)
Eventuellement
négociations (rarement)
Choix
du prestataire ou de la solution
Commande
ou contrat avec planning
Réalisation Préparation,
prototype
Tests,
formations
Réalisation
complète
Recette,
mise en service et poursuite des formations
Dans cet environnement, le cahier des charges remplit trois rôles
différents. D’abord 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.
Par la suite, surtout s’il s’agit d’un sous-traitant ou fournisseur
externe, 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.
Finalement, 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.
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. Ce prestataire
n'est généralement pas un informaticien : les sociétés de service auront leur
propre chef de projet qui a souvent le même profil que le chef de projet côté
client, mais avec, naturellement des intérêts différents. C'est ce chef de
projet qui est en relation directe avec les informaticiens de sa société, au
moment et sur les questions pour lesquelles on a besoin d'eux.
§
Définir
les objectifs que doit atteindre la solution.
§
Indiquer
les contraintes à respecter impérativement.
§
Etre
un outil de dialogue entre les différents acteurs.
§
Diminuer
les risques d’erreur lors de la réalisation ou l’installation.
Dans un projet, le professionnel de l’information n’agit pas seul. Il
est entouré d’utilisateurs internes et externes, des services administratifs et
informatiques, et de sa hiérarchie. Un
cahier des charges ne se construit pas sans la contribution de tous ces
acteurs. En tant que chef de projet utilisateur (CPU), le professionnel a tout
intérêt de s’entourer dès le début d’une équipe projet qui sera chargée du
projet. Le comité de pilotage composé par le CPU, des différents responsables
informatiques et des utilisateurs suivra l’avancement des travaux. Il prendra
les décisions stratégiques et, selon l’avancée du projet, réorientera si
nécessaire le déroulement du projet et devra en assumer l'échec le cas échéant.
Pas d’illusion : 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. Pas besoin de monter une usine à gaz,
d’étaler par exemple sur plus de 20 pages les besoins et spécifications quand
il ne s’agit que de numériser quelques documents – cela peut se faire en
quelques paragraphes. A l'inverse, nous avons déjà vu – malheureusement - des courriels, schémas ou tableaux faisant office de
cahier des charges.
Néanmoins, même si la présentation et l’ordre peuvent varier,
plusieurs éléments doivent nécessairement y figurer.
Les quatre éléments clés d’un cahier des charges
Etude de l’existant Présentation
générale de l’établissement
Etude
de l’environnement (pas seulement informatique)
(état
des lieux)
Analyse
des besoins Description des besoins de
l’établissement
Définition
de l’objectif du projet
Description
de la solution Caractéristiques fonctionnelles
Réponse
opérationnelle souhaitée (le prestataire peut
avoir la liberté de proposer toute solution technique à partir du moment où les
contraintes informatiques de l'établissement sont respectées, si il y en a)
Définition
de la procédure Découpage en lots ou phases
Description
des conditions commerciales
L’idée directive est d’obtenir une structure de base qui aide le
prestataire potentiel à comprendre « ce qu’on attend de lui ». 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.
Duchemin (2000) propose une méthodologie détaillée pour
l’informatisation d’une bibliothèque. Pour un projet de numérisation on
trouvera des recommandations utiles dans le guide de Buresi et Cédelle-Joubert
(2002). Le Ministère de
L’étude de l’existant consiste à mettre à plat, de façon aussi claire
que possible, l’analyse qualitative et quantitative du fonctionnement actuel de
la bibliothèque ou du centre de documentation.
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 (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 : les taches effectuées et les
taches non effectuées, les services rendus et les services non rendus, etc.
Cette critique sera ainsi une transition vers la 2e partie,
l’analyse des besoins.
Selon
Bénard (1990), 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. Cette étude
donne une vue globale des besoins des professionnels de l’information mais
aussi des utilisateurs.
Trois
facteurs sont à prendre en compte dans l’analyse :
1. Facteurs liés à l’application
informatique elle-même comme la durée de vie de l’application, le champ de
l’application.
2. 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).
§
Les
contraintes financières (budget).
Comme pour l’étude de l’existant, le rôle du professionnel de
l’information se situe ici en particulier au niveau du filtre, de la synthèse
et de la communication : à lui de pondérer, prioriser et présenter les
besoins et objectifs d’une manière réaliste, cohérente et compréhensible.
Dans le cahier des charges le service de documentation a exprimé ses
besoins et ses attentes. Il attend en retour une réponse du prestataire. Le
cadre de réponse est l’appellation globale des tableaux que le prestataire doit
remplir : tableaux cadre des caractéristiques fonctionnelles et
techniques. Ces tableaux seront des instruments très utiles à trois
niveaux :
1. Pour comparer et sélectionner le
prestataire ou la solution.
2. Pour obliger le prestataire à
s’engager sur toutes les questions.
3. Pour permettre de réaliser la
vérification d’aptitude (recette).
Le
cadre de réponse est souvent mis en annexe au cahier des charges, mais dans le
cadre d’un appel d’offre il est préférable de
l'annexer à l’acte d’engagement, premier document constituant le marché.
Voici
l’exemple d’un tableau cadre des caractéristiques fonctionnelles :
|
N° |
Besoins, fonctions |
Pondération |
STD |
PAR |
SPE |
NON |
Nbre de jours |
Commentaires |
|
1 |
|
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
|
|
|
4 |
|
|
|
|
|
|
|
|
|
5 |
|
|
|
|
|
|
|
|
Le prestataire potentiel indiquera pour
chaque fonctionnalité si elle est :
§
Gérée en standard dans le système (STD).
§
Gérable moyennant un paramétrage qu’il estimera en nombre de
jours (PAR).
§
Gérable par un développement spécifique qu’il chiffrera en
nombre de jours (SPE).
§
Non gérée (NON).
La colonne intitulée « pondération » est gardée à la
discrétion de l’établissement qui priorisera ses besoins.
Tout projet, une fois lancé, possède un caractère contractuel. Ce
contrat engage client et prestataire sur la base du cahier des charges.
Si la prestation est externalisée, le cahier des charges intégrera un
cadre juridique contraignant et spécifique : un contrat de droit privé si le
projet est lancé par une entreprise, un marché dans le cadre du Code des
Marchés Publics s’il s’agit d’un établissement public.
Le professionnel de l’information n’a pas à formaliser le contrat,
ceci sera affaire du service administratif ou juridique. Néanmoins, quelques
notions lui seront utiles pour bien préparer le cahier des charges et pour
choisir la procédure la plus adéquate :
L’objet du
contrat :
Choisir un intitulé succinct pour caractériser la prestation attendue.
Les lieux
d’exécution et de livraison : Dans les locaux du titulaire ? Sur le site de
production du prestataire ? A proximité géographique du service ? En
France ?
La durée du
contrat/marché :
Début, fin et durée globale du contrat ? Délai d’exécution ?
Pénalités en cas de dépassement/retard ?
Ces trois éléments
rentreront dans la rédaction du Cahier des Clauses Administratives
particulières (CCAP) rédigés conjointement par le professionnel de
l’information et le service juridique.
Les
caractéristiques principales : Prévoir une brève description de la prestation objet du
contrat ou marché ; établir une estimation du budget (montant global du
contrat TTC), éventuellement avec un maximum et un minimum (fourchette) ;
le cas échéant informer sur l’allotissement (découpage de la prestation en
plusieurs lots, attribution éventuelle à plusieurs prestataires) ; donner
des indications sur la volumétrie ; prévoir une information aussi sur la
passation du contrat/marché (commande globale ou par bons de commandes).
Toutes ces informations seront consignées dans le Cahier des Clauses Techniques Particulières (CCTP), qui sera rédigé par le professionnel de l’information et sera relu par le service juridique pour en vérifier le formalisme administratif.
Les critères
d’attribution du marché : En cas de mise en concurrence (appel d’offres), il faut
informer sur les critères de sélection, notamment : la valeur technique de
l’offre (expériences et références du prestataire, moyens et ressources mis en
œuvre, plan qualité etc.) ; le prix (prix global, tarifs des prestations,
structure de la tarification). Comme le Code des Marchés Publics exige le choix
de « l’offre économiquement la plus avantageuse » appréciée en
fonction de critères clairement énoncés avec une pondération, ces critères
d’attribution doivent être pondérés (par exemple, 60% valeur technique, 40%
prix).
Ces critères quant à
eux viendront compléter le Règlement Particulier de
Pour un établissement
public, l’estimation du montant du marché (économie) a un impact direct sur le
choix de la procédure, en particulier pour deux aspects : la publicité
pour la mise en concurrence (bulletin officiel, presse spécialisée etc.), et le
délai entre publicité et remise des candidatures. Actuellement, le seuil pour
une procédure simplifiée est de 90000€ HT (cf. le portail des marchés publics).
En fonction de la
connaissance de l’offre des prestataires potentiels, les procédures d’un appel
d’offres (ouvert ou restreint) ou d’un dialogue compétitif peuvent être des
options intéressantes :
Appel d’offres
ouvert : Option
de choix la plus couramment utilisée. Elle présente l’avantage d’être rapide
(durée de 52 jours) mais possède l’inconvénient d’obtenir beaucoup d’offres (ce
qui a une incidence sur la durée de sélection du titulaire).
Appel d’offres restreint : Option de choix s’il n’existe
qu’un nombre restreint de prestataires potentiels. Procédure en deux temps -
les entreprises doivent faire acte de candidature, elles sont retenues selon
les critères indiqués dans l'avis. Seules les entreprises retenues peuvent
faire une offre. Un cas particulier est le marché négocié, sans publicité
préalable – quand pour une prestation spécifique il n’existe qu’un seul
prestataire potentiel.
Dialogue
compétitif :
Option de choix si l’établissement n’est pas en mesure de définir
les moyens techniques qui répondent à ses besoins ou s’il n’est pas en
mesure d’établir le montage juridique ou financier de son projet. Procédure en
trois temps - les entreprises doivent faire acte de candidature, elles sont
retenues selon les critères indiqués dans l'avis. Seules les entreprises
retenues sont invitées à participer au dialogue compétitif avec l’établissement
qui aboutira à un cahier des charges précis. Ensuite, ces entreprises
soumettront une nouvelle proposition.
Attention : La
réglementation des marchés publics change régulièrement, et le professionnel de
l’information a tout intérêt de se tenir au courant du cadre juridique en cours
(cf. portail des marchés publics) et de travailler étroitement avec les
services administratifs et juridiques de son établissement lors de la
préparation de son cahier des charges.
Une dernière
remarque : En principe, ces conseils sont valables uniquement si la
prestation est externalisée. Ceci étant, certains établissements (surtout dans
le secteur privé) prévoient une contractualisation aussi en cas d’une
prestation « in house », assurée par un autre service du même
établissement (par exemple,
Après avoir choisi le prestataire ou la solution, paramétré le système
et assuré la formation des utilisateurs, il reste à vérifier que les
engagements du prestataire sont en adéquation avec les besoins spécifiés dans
le cahier des charges. Cette étape de vérification s’appelle recette. Elle est
divisée en deux étapes :
§
La
vérification d’aptitude (VA).
§
La
vérification de service régulier (VSR).
Ces étapes sont importantes car elles conduisent à l’acceptation ou au
rejet de la solution.
La vérification d’aptitude est réalisée à partir du tableau cadre des
caractéristiques fonctionnelles. Des tests unitaires sont réalisés sur les
fonctionnalités auxquelles le titulaire a répondu par l’affirmative.
La vérification de service régulier consiste à s'assurer du bon
fonctionnement du système en exploitation normale. Il s'agit donc d'une
utilisation réelle et pas d'un test en vraie grandeur.
Les durées de
Dans un autre contexte – quand il s’agit d’une prestation
sous-traitée, par exemple pour la numérisation de documents ou la
rétroconversion d’un catalogue – le cahier des charges jouera ce rôle de cahier
de recette déjà tout au début du projet, quand le prestataire aura mis en place
sa chaîne de production. Avant de passer en production, il faut prévoir une
phase test sur un échantillon représentatif dont le résultat sera à valider ou
à rejeter à partir des spécifications du cahier des charges.
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 ».
1.
Précis : Notamment pour les fonctionnalités émergeantes, le flou peut conduire
à des déconvenues.
2.
Prospectif : Il ne s’agit pas de s’aligner sur les systèmes obsolètes mais de
prendre en compte les évolutions en cours.
3.
Concis : Car un document démesurément épais et détaillé, source
d’investissement en temps pour le fournisseur, réduira le nombre de
propositions donc le choix de la bibliothèque.
4.
Réaliste : Il ne s’agit pas d’imaginer un système idéal « qui fait
tout » (« killer application » en anglais) mais de rester
réaliste par rapport aux besoins réels et à la faisabilité technique et
financière.
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 entre professionnels de l’information et
informaticiens, notamment quand il s’agit d’une prestation externalisée et/ou
d’un prestataire non francophone.
Plus en amont, le professionnel a tout intérêt de
se tenir au courant de l’évolution technologique dans le domaine concerné. Une
bonne connaissance du marché et des prestataires sont des clés pour élaborer un
cahier des charges pertinent et prévenir des surcoûts.
Cette veille peut se faire de plusieurs
façons : rencontres professionnelles (ADBS, CNRS etc.), salons (ADBU,
I-Expo), listes (adbs info, Biblio.fr), publications (BBF, Archimag,
cf. par exemple Ochanine 2006) sont quelques vecteurs. Lors de la préparation
d’un projet d’envergure, il ne faut pas hésiter à prendre contact avec des
fournisseurs et prestataires potentiels ou d'autres utilisateurs des logiciels
existants, pour discuter des besoins et objectifs et organiser des
démonstrations des solutions du marché. Le temps investi dans cette phase
préalable sera profitable pour la suite.
Un bon cahier des charges sera toujours le reflet d’une compréhension
et du respect mutuel des métiers. Le professionnel de l’information n’a pas à
se substituer à l’informaticien. Le cahier des charges n’est pas destiné à
imposer au prestataire comment il doit réaliser le projet mais à lui expliquer
les besoins de l’établissement et décrire les fonctionnalités cibles.
Un bon document ne fera que cela : servir d’outil de
communication au dialogue entre professionnel de l’information et
informaticien, et déterminer les engagements mutuels. Sa qualité réside dans la
clarté, la pertinence et la lisibilité du contenu.
Comment mener un projet à terme dont les objectifs sont vagues et les
spécifications, incohérentes, incomplètes, voire irréalistes ? Ceci étant,
il ne faut pas non plus verser dans l’autre extrême, laisser définir (ou
plutôt, limiter) les besoins d’un service documentaire d’emblée par les
professionnels de l’informatique. Dans ce sens, le meilleur cahier des charges
sera toujours l’expression d’un compromis entre les besoins et objectifs du
service et la faisabilité technique et financière, basé sur un partenariat bien
compris entre utilisateur et prestataire. Mais une telle collaboration n’est
pas facile à réaliser, d’autant moins que les procédures des marchés publics ne
favorisent pas toujours un réel dialogue entre les deux parties durant la
période de l’appel d’offres. Même un cahier des charges qui a nécessité la plus
grande attention n’est pas un gage de réussite du projet. Ajoutons que la
capacité des équipes à choisir la bonne démarche et la capacité des
organisations, des femmes et des hommes à piloter des projets (cf. Quan 2006)
restent des facteurs clés pour réussir.
Ressources
Bénard, C. : Le cahier des
charges d’une application informatique. Paris 1990.
Buresi, C., Cédelle-Joubert,
L. : Conduire un projet de numérisation. Paris 2002.
Duchemin, P.Y. : L’art
d’informatiser une bibliothèque. Paris 2000.
Lubkov, M. :
« Informatique documentaire : comment concevoir un cahier des
charges. » Archimag 1996, 98, 36-39.
Ochanine, H. :
« Prestataires en numérisation : Un large éventail de
prestations. » Archimag 2006, 194, 36-40.
Quan, D. : L’impossible
conduite du projet de SI. Paris 2006.
http://www.adbdp.asso.fr/outils/infogestion/ccinfobds.htm
Guide pour l’informatisation d’une bibliothèque municipale
http://www.gouv.culture.fr/culture/mrt/bibliothèque/dll/guide_dll.htm
Guide du Ministère de
http://www.dsi.cnrs.fr/conduite-projet
Guide du CNRS pour la conduite d’un projet informatique
http://djo.journal-officiel.gouv.fr/MarchesPublics
Portail des marchés publics.