Gestion documentaire

Gestion documentaire

La gestion documentaire recouvre la production et la maintenance des différentes formes de documentation. Deux catégories de documents sont à considérer : les documents lés à l’application et ceux liés au projet. Ces paragraphes concernent la procédure de création, de mise à jour et de diffusion de l'ensemble des documents utilisés dans le cadre du projet.

Les manuels de formation, d'utilisation, d’administration et d’exploitation ont pour objectif de permettre la mise en œuvre de l’application. La documentation technique permet la réalisation de l’application, puis son évolution. Les documents de gestion permettent de suivre le déroulement du projet et de veiller à la qualité des produits fournis. Deux types techniques de documents se distinguent :

  • les documents évolutifs avec la notion d'historique se basant sur un numéro de version,
  • les documents événementiels qui ne nécessitent pas de gestion de versions.
  • Documents de pilotage et d’Assurance qualité

    Les documents de pilotage du projet et d’assurance qualité constituent une documentation permettant de suivre puis retracer le déroulement du projet, ainsi que de définir et d’organiser les dispositions spécifiques à mettre en œuvre pour s’assurer de la qualité du processus et des fournitures.

    Documents techniques

    La documentation technique de développement a pour objectif de formaliser les exigences, de modéliser la conception et de documenter l'application afin de faciliter sa réalisation et ensuite sa maintenance.

    Documents d’utilisation

    Les documents de formation, d’utilisation et d’exploitation sont réalisés par un personnel, de préférence spécialisé, et reconnu comme apte à produire une communication adaptée au niveau des futurs lecteurs.

    Documents de projet, rapport de pilotage

    Le Tableau 1. — Documents référencés dans l'ouvrage, liste des documents de conduite de projet disponible sur le site www.RAD.fr. La plupart des actions couvertes par ces documents " papier " devraient utiliser un logiciel spécialisé. L’utilité raisonnablement pratique de chaque document est dépendante de la taille et du type de chaque projet.

    Tableau 1. — Documents référencés dans l'ouvrage

    Référence

    Objet du document

    I

    Suivi de l’affectation des ressources du projet

    II

    Synthèse de l'avancement des livrables

    III

    Demande d'une évolution applicative

    VI

    Suivi des évolutions applicatives

    V

    Fiche de vérification d’un document

    VI

    Rapport des risques

    VII

    Suivi des points d’actions

    VIII

    Scénarios des tests de cheminements fonctionnels

    IX

    Fiche de découverte d'une anomalie

    X

    Suivi du traitement des divergences

    XI

    Tableau des courriers émis (*)

    XII

    Tableau des courriers reçus (*)

    XIII

    Journal des événements du projet 

    XIV

    Fiche de tâches à accomplir

    (*) Si on ne dispose pas d’un courrier électronique

    Pratiques RAD de documentation

    Produire une application de qualité et livrer rapidement des fonctionnalités est le seul objectif à considérer dans un projet (documentation d’utilisation incluse). La production d’une documentation projet est de priorité secondaire et doit donc répondre au principe du " nécessaire et suffisant ".

    Une documentation utilisateur moderne doit être en ligne et contextuelle. En ligne, elle concerne les principes de fond. L’aide contextuelle est immédiatement visible et associée à l’action ou au champ sur lequel l’utilisateur est positionné. Le papier doit être réservé à la description des principes généraux.

    La forme d’une documentation " utilisateur " doit faire l'objet d'un choix justifié par son objectif réel :

  • la simplicité s’avère indispensable si l'usager est néophyte,
  • la concision et la complétude (en regard des problèmes complexes) sont nécessaires si l'utilisateur est un expert.
  • Le niveau de la documentation d'utilisation ainsi que sont type, est une affaire de spécialiste. En général, les experts en développement sont de piètres rédacteurs, leur vision est trop technique. Il est plus efficace et moins coûteux de faire appel à une ressource spécialisée. Un spécialiste en documentation dispose d'un savoir-faire (technique, ergonomique) et de la maîtrise d'outils de documentation. Sa présence se rentabilise immédiatement. Le secrétariat de projet n'est pas non plus la solution idéale, mais représente un moindre mal.

    Note : Une autre option est de faire rédiger le cahier des charges de l'application dans l'optique d'une documentation utilisateur par un rapporteur issu de la maîtrise d'ouvrage travaillant en partenariat avec un animateur-facilitateur expérimenté. Dans ce cas les avantages en termes de délais et de budget sont de disposer simultanément et immédiatement de spécifications validées et d'une documentation adaptée.

    www.RAD.fr ® © Jean-Pierre Vickoff