Strategie

ecette, 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.

Outil de communication

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.

Quatre objectifs d’un cahier des charges

    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.

Structuration

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) Description des besoins de l’établissement Définition de l’objectif du projet 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écoupage en lots ou phases Description des conditions commerciales

Analyse des besoins Description de la solution

Définition de la procédure

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 la Culture a mis en ligne un cahier des charges type pour tout projet informatique d’une bibliothèque publique qui peut également servir de modèle. On trouvera d’autres exemples sur le Web.

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 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 2 e partie, l’analyse des besoins.

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é plusieurs sites. sur

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.

Les caractéristiques fonctionnelles

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 Commentaires de jours

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