Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Informatique documentaire Le cahier des charges Alain Collignon, INIST-CNRS, al

Informatique documentaire Le cahier des charges 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. 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. Les phases clés d’un projet 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. 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) 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 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 2e 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é 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. 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 uploads/Ingenierie_Lourd/ cahier-charge-1 1 .pdf