Informatique documentaire : le cahier des charges sous

toutes les coutures

Alain Collignon, Joachim Schopfel

To cite this version:

Alain Collignon, Joachim Schopfel. Informatique documentaire : le cahier des charges sous
toutes les coutures. Archimag Guide Pratique Manager et developper son service infodoc,
Groupe SERDA, pp.34-42, 93, 2007. <sic 00238533>

HAL Id: sic 00238533

https://archivesic.ccsd.cnrs.fr/sic 00238533
Submitted on 3 Mar 2008

HAL is a multi-disciplinary open access Larchive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
destinee au depot et a la diffusion de documents
scientifiques de niveau recherche, publies ou non,
emanant des etablissements denseignement et de
recherche francais ou etrangers, des laboratoires
publics ou prives.
Informatique documentaire

Le cahier des charges

Alain Collignon, INIST-CNRS, alain.collignon@inist.fr

Joachim Schpfel, INIST-CNRS, joachim.schopfel@inist.fr

Rsum : Le cahier des charges est un pralable tout projet informatique. Etude de
lexistant, analyse des besoins, spcifications des caractristiques fonctionnelles, cadre
juridique : autant daspects quil faut matriser pour un projet russi.

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 systme de gestion documentaire ou de son remplacement,
de la cration dun site Web ou dun portail, de lintgration des ressources numriques,
dun projet ddition ou de numrisation, le professionnel de linformation doit savoir
prparer une telle dmarche, choisir le prestataire, vrifier le rsultat.

Pour russir, tout projet doit suivre une logique dans laquelle le cahier des charges tient
un rle particulier. Mais comment sy prendre sans rinventer la roue ou perdre du
temps ? Comment viter les cueils ? O trouver des renseignements, rfrences et
aides utiles ? Voici quelques conseils pratiques.

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.

Les phases cls dun projet

Etudes pralables Etudes de lopportunit dun dveloppement
spcifique ou achat dun progiciel
Dfinition des besoins et de lobjectif du projet

Dtermination du budget et de la procdure

Cahier des charges Prsentation de lexistant

Description des besoins

Spcifications des caractristiques fonctionnelles

Type de logiciel ou de prestation

Choix Choix de la procdure (appel doffres)

Page 1
 Eventuellement ngociations (rarement)

Choix du prestataire ou de la solution

Commande ou contrat avec planning

Ralisation Prparation, prototype

Tests, formations

Ralisation complte

Recette, mise en service et poursuite des formations

Dans cet environnement, le cahier des charges remplit trois rles diffrents. Dabord il
dcrit un fournisseur potentiel ce quon attend de lui : Synthse de toute la rflexion
() mthodologique, (il) est le bilan de la dfinition des besoins spcifiques et des
contraintes propres () (Duchemin 2000, p313). Accessoirement, il contribue
galement la dfinition des critres de slection du prestataire.

Par la suite, surtout sil sagit dun sous-traitant ou fournisseur externe, le contenu du
cahier des charges est intgr dans le contrat ou march. Lengagement sur la ralisation
des spcifications techniques et le planning devient ainsi contraignant.

Finalement, le cahier des charges permettra, sous forme de cahier de recette, dvaluer
ladquation entre la rponse du titulaire et les besoins exprims.

Outil de communication
Le cahier des charges est tout dabord un outil de communication et dinformation entre
le professionnel de linformation ( utilisateur ) et le prestataire de service. Ce
prestataire n'est gnralement pas un informaticien : les socits de service auront leur
propre chef de projet qui a souvent le mme profil que le chef de projet ct client, mais
avec, naturellement des intrts diffrents. C'est ce chef de projet qui est en relation
directe avec les informaticiens de sa socit, au moment et sur les questions pour
lesquelles on a besoin d'eux.

Quatre objectifs dun cahier des charges

Dfinir les objectifs que doit atteindre la solution.

Indiquer les contraintes respecter imprativement.

Etre un outil de dialogue entre les diffrents acteurs.

Diminuer les risques derreur lors de la ralisation ou linstallation.

Dans un projet, le professionnel de linformation nagit pas seul. Il est entour

dutilisateurs internes et externes, des services administratifs et informatiques, et de sa
hirarchie. Un cahier des charges ne se construit pas sans la contribution de tous ces

Page 2
acteurs. En tant que chef de projet utilisateur (CPU), le professionnel a tout intrt de
sentourer ds le dbut dune quipe projet qui sera charge du projet. Le comit de
pilotage compos par le CPU, des diffrents responsables informatiques et des
utilisateurs suivra lavancement des travaux. Il prendra les dcisions stratgiques et,
selon lavance du projet, rorientera si ncessaire le droulement du projet et devra en
assumer l'chec le cas chant.

Structuration

Pas dillusion : il ny a pas de plan type pour rdiger un cahier des charges. Structure,
prcision et longueur dpendent de limportance, de lobjet et du contexte du projet. Pas
besoin de monter une usine gaz, dtaler par exemple sur plus de 20 pages les besoins
et spcifications quand il ne sagit que de numriser quelques documents cela peut se
faire en quelques paragraphes. A l'inverse, nous avons dj vu malheureusement - des
courriels, schmas ou tableaux faisant office de cahier des charges.

Nanmoins, mme si la prsentation et lordre peuvent varier, plusieurs lments doivent

ncessairement y figurer.

Les quatre lments cls dun cahier des charges

Etude de lexistant
Analyse des besoins
Description de la solution
Dfinition de la procdure
Prsentation gnrale de ltablissement
Etude de lenvironnement (pas seulement informatique)
(tat des lieux)
Description des besoins de ltablissement
Dfinition de lobjectif du projet
Caractristiques fonctionnelles
Rponse oprationnelle souhaite (le prestataire peut
avoir la libert de proposer toute solution technique
partir du moment o les contraintes informatiques de
l'tablissement sont respectes, si il y en a)
Dcoupage en lots ou phases
Description des conditions commerciales

Lide directive est dobtenir une structure de base qui aide le prestataire potentiel
comprendre ce quon attend de lui . Tout ce qui, dans un texte, facilite la
comprhension est bon prendre : une structure claire et simple, des paragraphes
courts, des schmas et illustrations etc. Lors de la rdaction, on peut sinspirer dun
modle ou exemple. Mais attention, sinspirer ne veut pas dire copier, et il faut surtout
viter de flouer la spcificit du projet en question.

Duchemin (2000) propose une mthodologie dtaille pour linformatisation dune

bibliothque. Pour un projet de numrisation on trouvera des recommandations utiles
dans le guide de Buresi et Cdelle-Joubert (2002). Le Ministre de la Culture a mis en
ligne un cahier des charges type pour tout projet informatique dune bibliothque
publique qui peut galement servir de modle. On trouvera dautres exemples sur le
Web.

Page 3
Ltude de lexistant

Ltude de lexistant consiste mettre plat, de faon aussi claire que possible, lanalyse
qualitative et quantitative du fonctionnement actuel de la bibliothque ou du centre de
documentation.

Une analyse de lexistant comprend trois parties distinctes :

1. La premire consiste recueillir les informations ; elle est ralise partir

dentretiens ou de questionnaires, tableaux de bords, catalogues, tudes, donnes
statistiques etc.

2. La seconde consiste analyser, classer et donner une vue synthtique de

lensemble des informations collectes par domaine fonctionnel, en tenant compte
des ressources humaines (nombre et profil des personnes assignes aux diverses
tches).

3. La troisime consiste esquisser une modlisation grosses mailles des donnes

et des traitements.

Ltat des lieux peut aboutir une critique de lexistant qui analyse les points positifs et
ngatifs de lorganisation du travail dj mise en place et dgage les amliorations
apporter : les taches effectues et les taches non effectues, les services rendus et les
services non rendus, etc. Cette critique sera ainsi une transition vers la 2 e partie,
lanalyse des besoins.

Lanalyse des besoins

Selon Bnard (1990), le besoin cest la ncessit ou le dsir prouv par un utilisateur.
Ce besoin peut tre explicite ou implicite, potentiel, avou ou inavou. Par consquent,
ltude des besoins consiste dgager les critres dinformatisation des diverses tches,
choisir celles qui sont informatiser et valuer les gains de temps, dnergie et
defficacit attendus (retour sur investissement). Elle est raliser sous forme de
questionnaire. Cette tude donne une vue globale des besoins des professionnels de
linformation mais aussi des utilisateurs.

Trois facteurs sont prendre en compte dans lanalyse :

1. Facteurs lis lapplication informatique elle-mme comme la dure de vie de

lapplication, le champ de lapplication.

2. Facteurs lis la solution, comme la mise en place dun portail dinformation, la

gestion de ressources lectroniques.

3. Facteurs lis au projet comme les enjeux, le cot, les crdits.

Ces facteurs sont prendre en compte avec lintgration de contraintes :

Les contraintes organisationnelles, par exemple la gestion dun fonds gr sur

plusieurs sites.

Les contraintes techniques comme lusage dun systme dexploitation particulier

ou un systme de gestion de bases de donnes (SGBD).

Page 4
 Les contraintes humaines et administratives (comptences, organigramme,
planning).

Les contraintes financires (budget).

Comme pour ltude de lexistant, le rle du professionnel de linformation se situe ici en

particulier au niveau du filtre, de la synthse et de la communication : lui de pondrer,
prioriser et prsenter les besoins et objectifs dune manire raliste, cohrente et
comprhensible.

Les caractristiques fonctionnelles

Dans le cahier des charges le service de documentation a exprim ses besoins et ses
attentes. Il attend en retour une rponse du prestataire. Le cadre de rponse est
lappellation globale des tableaux que le prestataire doit remplir : tableaux cadre des
caractristiques fonctionnelles et techniques. Ces tableaux seront des instruments trs
utiles trois niveaux :

1. Pour comparer et slectionner le prestataire ou la solution.

2. Pour obliger le prestataire sengager sur toutes les questions.

3. Pour permettre de raliser la vrification daptitude (recette).

Le cadre de rponse est souvent mis en annexe au cahier des charges, mais dans le
cadre dun appel doffre il est prfrable de l'annexer lacte dengagement, premier
document constituant le march.

Voici lexemple dun tableau cadre des caractristiques fonctionnelles :

N Besoins, Pondration STD PAR SPE NON Nbre Commentaires

fonctions de
jours

Le prestataire potentiel indiquera pour chaque fonctionnalit si elle est :

Gre en standard dans le systme (STD).

Grable moyennant un paramtrage quil estimera en nombre de jours (PAR).

Grable par un dveloppement spcifique quil chiffrera en nombre de jours (SPE).

Non gre (NON).

Page 5
La colonne intitule pondration est garde la discrtion de ltablissement qui
priorisera ses besoins.

Le cadre juridique

Tout projet, une fois lanc, possde un caractre contractuel. Ce contrat engage client et
prestataire sur la base du cahier des charges.

Si la prestation est externalise, le cahier des charges intgrera un cadre juridique

contraignant et spcifique : un contrat de droit priv si le projet est lanc par une
entreprise, un march dans le cadre du Code des Marchs Publics sil sagit dun
tablissement public.

Le professionnel de linformation na pas formaliser le contrat, ceci sera affaire du

service administratif ou juridique. Nanmoins, quelques notions lui seront utiles pour bien
prparer le cahier des charges et pour choisir la procdure la plus adquate :

Lobjet du contrat : Choisir un intitul succinct pour caractriser la prestation attendue.

Les lieux dexcution et de livraison : Dans les locaux du titulaire ? Sur le site de
production du prestataire ? A proximit gographique du service ? En France ?

La dure du contrat/march : Dbut, fin et dure globale du contrat ? Dlai

dexcution ? Pnalits en cas de dpassement/retard ?

Ces trois lments rentreront dans la rdaction du Cahier des Clauses Administratives
particulires (CCAP) rdigs conjointement par le professionnel de linformation et le
service juridique.

Les caractristiques principales : Prvoir une brve 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 chant
informer sur lallotissement (dcoupage de la prestation en plusieurs lots, attribution
ventuelle plusieurs prestataires) ; donner des indications sur la volumtrie ; prvoir
une information aussi sur la passation du contrat/march (commande globale ou par
bons de commandes).

Toutes ces informations seront consignes dans le Cahier des Clauses Techniques
Particulires (CCTP), qui sera rdig par le professionnel de linformation et sera relu par
le service juridique pour en vrifier le formalisme administratif.

Les critres dattribution du march : En cas de mise en concurrence (appel doffres),

il faut informer sur les critres de slection, notamment : la valeur technique de loffre
(expriences et rfrences 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 Marchs Publics exige le choix de loffre conomiquement la plus
avantageuse apprcie en fonction de critres clairement noncs avec une
pondration, ces critres dattribution doivent tre pondrs (par exemple, 60% valeur
technique, 40% prix).

Ces critres quant eux viendront complter le Rglement Particulier de la Consultation

(RPC) dfinissant le droulement de lappel offre.

Pour un tablissement public, lestimation du montant du march (conomie) a un impact

direct sur le choix de la procdure, en particulier pour deux aspects : la publicit pour la

Page 6
mise en concurrence (bulletin officiel, presse spcialise etc.), et le dlai entre publicit
et remise des candidatures. Actuellement, le seuil pour une procdure simplifie est de
90000 HT (cf. le portail des marchs publics).

En fonction de la connaissance de loffre des prestataires potentiels, les procdures dun

appel doffres (ouvert ou restreint) ou dun dialogue comptitif peuvent tre des options
intressantes :

Appel doffres ouvert : Option de choix la plus couramment utilise. Elle prsente
lavantage dtre rapide (dure de 52 jours) mais possde linconvnient dobtenir
beaucoup doffres (ce qui a une incidence sur la dure de slection du titulaire).

Appel doffres restreint : Option de choix sil nexiste quun nombre restreint de
prestataires potentiels. Procdure en deux temps - les entreprises doivent faire acte de
candidature, elles sont retenues selon les critres indiqus dans l'avis. Seules les
entreprises retenues peuvent faire une offre. Un cas particulier est le march ngoci,
sans publicit pralable quand pour une prestation spcifique il nexiste quun seul
prestataire potentiel.

Dialogue comptitif : Option de choix si ltablissement nest pas en mesure de dfinir

les moyens techniques qui rpondent ses besoins ou sil nest pas en mesure dtablir le
montage juridique ou financier de son projet. Procdure en trois temps - les entreprises
doivent faire acte de candidature, elles sont retenues selon les critres indiqus dans
l'avis. Seules les entreprises retenues sont invites participer au dialogue comptitif
avec ltablissement qui aboutira un cahier des charges prcis. Ensuite, ces entreprises
soumettront une nouvelle proposition.

Attention : La rglementation des marchs publics change rgulirement, et le

professionnel de linformation a tout intrt de se tenir au courant du cadre juridique en
cours (cf. portail des marchs publics) et de travailler troitement avec les services
administratifs et juridiques de son tablissement lors de la prparation de son cahier des
charges.

Une dernire remarque : En principe, ces conseils sont valables uniquement si la

prestation est externalise. Ceci tant, certains tablissements (surtout dans le secteur
priv) prvoient une contractualisation aussi en cas dune prestation in house ,
assure par un autre service du mme tablissement (par exemple, la DSI). Nanmoins,
mme l o cette contractualisation interne nest pas la rgle, on peut se demander
si un tel accord entre plusieurs services, mme caractre symbolique et sans valeur
juridique stricto senso, ne permettrait pas dans certains cas de clarifier les engagements
mutuels des uns et des autres. -

La recette

Aprs avoir choisi le prestataire ou la solution, paramtr le systme et assur la

formation des utilisateurs, il reste vrifier que les engagements du prestataire sont en
adquation avec les besoins spcifis dans le cahier des charges. Cette tape de
vrification sappelle recette. Elle est divise en deux tapes :

La vrification daptitude (VA).

La vrification de service rgulier (VSR).

Ces tapes sont importantes car elles conduisent lacceptation ou au rejet de la

solution.

Page 7
La vrification daptitude est ralise partir du tableau cadre des caractristiques
fonctionnelles. Des tests unitaires sont raliss sur les fonctionnalits auxquelles le
titulaire a rpondu par laffirmative.

La vrification de service rgulier consiste s'assurer du bon fonctionnement du systme

en exploitation normale. Il s'agit donc d'une utilisation relle et pas d'un test en vraie
grandeur.

Les dures de la VA et de la VSR sont fixes dans le contrat. Normalement, la VA dure

moins longtemps que la VSR qui peut prendre jusqu deux ou trois mois. Attention :
cette double vrification est typiquement franaise ; des prestataires et fournisseurs
anglo-saxons connaissent uniquement la VA et poussent sortir la VSR du projet au sens
strict afin de rgler dventuels problmes dutilisation dans le cadre de la maintenance
ou de lassistance technique (helpdesk).

Dans un autre contexte quand il sagit dune prestation sous-traite, par exemple pour
la numrisation de documents ou la rtroconversion dun catalogue le cahier des
charges jouera ce rle de cahier de recette dj tout au dbut du projet, quand le
prestataire aura mis en place sa chane de production. Avant de passer en production, il
faut prvoir une phase test sur un chantillon reprsentatif dont le rsultat sera valider
ou rejeter partir des spcifications du cahier des charges.

Quest-ce quun bon cahier des charges ?

Le cahier des charges nest pas une garantie de succs mais sans cahier de charges, la
russite devient alatoire. La rdaction dun cahier des charges repose sur la rgle du
PPCR .

1. Prcis : Notamment pour les fonctionnalits mergeantes, le flou peut conduire

des dconvenues.

2. Prospectif : Il ne sagit pas de saligner sur les systmes obsoltes mais de

prendre en compte les volutions en cours.

3. Concis : Car un document dmesurment pais et dtaill, source dinvestissement

en temps pour le fournisseur, rduira le nombre de propositions donc le choix de la
bibliothque.

4. Raliste : Il ne sagit pas dimaginer un systme idal qui fait tout ( killer
application en anglais) mais de rester raliste par rapport aux besoins rels et la
faisabilit technique et financire.

Rdaction collective, relecture, comparaison avec dautres cahiers des charges sont
quelques conseils pour sassurer dune bonne qualit. De mme, lajout dun glossaire qui
dfinit les termes et concepts cls peut faciliter la comprhension entre professionnels de
linformation et informaticiens, notamment quand il sagit dune prestation externalise
et/ou dun prestataire non francophone.

Plus en amont, le professionnel a tout intrt de se tenir au courant de lvolution

technologique dans le domaine concern. Une bonne connaissance du march et des
prestataires sont des cls pour laborer un cahier des charges pertinent et prvenir des
surcots.

Cette veille peut se faire de plusieurs faons : rencontres professionnelles (ADBS, CNRS
etc.), salons (ADBU, I-Expo), listes (adbs info, Biblio.fr), publications (BBF, Archimag, cf.

Page 8
par exemple Ochanine 2006) sont quelques vecteurs. Lors de la prparation dun projet
denvergure, il ne faut pas hsiter prendre contact avec des fournisseurs et prestataires
potentiels ou d'autres utilisateurs des logiciels existants, pour discuter des besoins et
objectifs et organiser des dmonstrations des solutions du march. Le temps investi dans
cette phase pralable sera profitable pour la suite.

En guise de conclusion
Un bon cahier des charges sera toujours le reflet dune comprhension et du respect
mutuel des mtiers. Le professionnel de linformation na pas se substituer
linformaticien. Le cahier des charges nest pas destin imposer au prestataire comment
il doit raliser le projet mais lui expliquer les besoins de ltablissement et dcrire les
fonctionnalits cibles.

Un bon document ne fera que cela : servir doutil de communication au dialogue entre
professionnel de linformation et informaticien, et dterminer les engagements mutuels.
Sa qualit rside dans la clart, la pertinence et la lisibilit du contenu.

Comment mener un projet terme dont les objectifs sont vagues et les spcifications,
incohrentes, incompltes, voire irralistes ? Ceci tant, il ne faut pas non plus verser
dans lautre extrme, laisser dfinir (ou plutt, limiter) les besoins dun service
documentaire demble par les professionnels de linformatique. Dans ce sens, le meilleur
cahier des charges sera toujours lexpression dun compromis entre les besoins et
objectifs du service et la faisabilit technique et financire, bas sur un partenariat bien
compris entre utilisateur et prestataire. Mais une telle collaboration nest pas facile
raliser, dautant moins que les procdures des marchs publics ne favorisent pas
toujours un rel dialogue entre les deux parties durant la priode de lappel doffres.
Mme un cahier des charges qui a ncessit la plus grande attention nest pas un gage
de russite du projet. Ajoutons que la capacit des quipes choisir la bonne dmarche
et la capacit des organisations, des femmes et des hommes piloter des projets (cf.
Quan 2006) restent des facteurs cls pour russir.

Ressources
Bnard, C. : Le cahier des charges dune application informatique. Paris 1990.
Buresi, C., Cdelle-Joubert, L. : Conduire un projet de numrisation. Paris 2002.
Duchemin, P.Y. : Lart dinformatiser une bibliothque. Paris 2000.
Lubkov, M. : Informatique documentaire : comment concevoir un cahier des charges.
Archimag 1996, 98, 36-39.
Ochanine, H. : Prestataires en numrisation : Un large ventail de prestations.
Archimag 2006, 194, 36-40.
Quan, D. : Limpossible conduite du projet de SI. Paris 2006.
http://www.adbdp.asso.fr/outils/infogestion/ccinfobds.htm Guide pour linformatisation
dune bibliothque municipale
http://www.gouv.culture.fr/culture/mrt/bibliothque/dll/guide_dll.htm Guide du Ministre
de la Culture pour linformatisation dune bibliothque
http://www.dsi.cnrs.fr/conduite-projet Guide du CNRS pour la conduite dun projet
informatique
http://djo.journal-officiel.gouv.fr/MarchesPublics Portail des marchs publics.

Page 9