Accueil du site > Les articles > Conduite de projet : documenter.
Version à imprimer Enregistrer au format PDF

Conduite de projet : documenter.

lundi 17 mai 2004, par David Malle Visites  1559 Première mise en ligne le vendredi 10 octobre 2003.

L’absence de documentation plus ou moins formalisée débouche sur un surcoût en temps lié aux itérations successives découlant de l’imprécision de la demande, de la non-traçabilité de la décision prise lors de réunions antérieures. Attention, au même titre que le produit fini, la documentation représente la seule réalité du projet. Ne la négligez pas et pensez à inclure dans les estimations des délais, du temps pour la documentation et à la développer au fur et à mesure de l’avancement du projet.


Les obstacles :

La tenue des délais

Une idée reçue, bien ancrée dans les esprits est la forte consommation de temps découlant de la mise en oeuvre d’une documentation. Cette démarche ne résiste pas à une analyse approfondie de la répartition des temps de travail des membres des l’équipes. L’absence de documentation plus ou moins formalisée débouche sur un surcoût en temps lié aux itérations successives découlant de l’imprécision de la demande, de la non-traçabilité de la décision prise lors de réunions antérieures. La solution consiste à inclure dans les estimations des délais, du temps pour la documentation et à la développer au fùr et à mesure de l’avancement du projet.

L’obsolescence de la documentation

Un argument avancé de toute bonne foi par les équipes, avec exemples à l’appui, porte sur la gestion de la mise à jour de la documentation. Il faut retrouver l’ensemble des documents constituant le dossier, à l’intérieur du document changer la feuille contenant l’ancienne information pour y substituer la nouvelle. Le support n’est pas prévu pour insérer des nouvelles pages ou interclasser certaines. La structure de classement et de pagination choisie est incompatible avec la mise à jour envisagée. Cela se traduit généralement par un ajout sans substitution des informations complémentaires. Lors de recherches futures, un véritable jeu de patience s’engage pour identifier la dernière version parmi les diverses modifications effectuées.

Le complexe de l’écrivain

La production d’une documentation, sans être obligatoirement un exercice de style, nécessite des qualités dans l’expression écrite afin de se fuire comprendre des lecteurs. La maîtrise d’un style direct, pédagogique, comme la bonne connaissance de la syntaxe de la langue sont deux caractéristiques essentielles. Si l’on y ajoute la connaissance d’un vocabulaire enrichi et une orthographe correcte, on comprend le peu d’enthousiasme des équipes à s’engager dans le travail de documentation.

La propriété intellectuelle

Un autre frein caché à la non-rédaction d’une documentation réside dans le sentiment de dépossession de leur oeuvre qu’éprouvent un certain nombre de réalisateurs. A partir du moment où une autre personne possède les clés lui permettant de reconstituer le programme fabriqué il y a perte de pouvoir.

Les arguments

Outil de mémoire

Un des arguments avancé pour différer à jamais la mise au point de la documentation reste la présence des sources. Plusieurs années de pratique conduisent à remettre en cause ce postulat. Quiconque s’est trouvé confronté à la modification d’un programme dont il n’était pas l’auteur est un ardent défenseur de la documentation. L’existence d’outils, de technique de programmation structurée, comme la pratique de normes et standards ne suffit pas pour entretenir un programme écrit par quelqu’un d’autre.

Faute de disposer de documentation, le savoir et le savoir-faire des usagers se transmet oralement, au coup par coup. Il y a perte de mémoire du produit au profit de pratiques polluantes. Cela se traduit à terme par l’abandon de l’application.

La maintenance de nombreux programmes est souvent le résultat d’un dialogue entre un utilisateur à satisfàire et un analyste programmeur prêt à rendre service. La transformation du programme a lieu dans une entente cordiale, alors pourquoi prendre la peine de formuler une demande. Là encore, tout repose sur la mémoire des partenaires.

LOGICIEL = PROGRAMME + DOCUMENTATION

Outil de contrôle

La documentation n’est pas seulement un mode d’emploi de l’applicatif C’est aussi un moyen de contrôle permanent pendant la durée de la réalisation. Elle intervient dans la normalisation et la standardisation des procédures de fàbrication du logiciel d’une équipe à l’autre.

Partie intégrante d’une démarche d’assurance qualité, cette dernière réduit les dépenses de formation, simplifie les procédures de correction.

La documentation reste un des moyens de faire adhérer les équipes à des changements de comportement en imposant des réflexes à petit pas. Elle sera donc établie au fur et à mesure de l’avancement du projet. Elle décrira ce qu’on réalisera ensuite.

Point de départ = DOCUMENT —> PHASE —> Point d’arrivée = DOCUMENT initialisant la phase suivante

Outil de dialogue

Pour de nombreuses équipes projet, une documentation incomplète et floue est une aubaine. C’est un moyen pour se protéger contre d’éventuelles variations des demandes utilisateurs. Encore faut-il arriver à engager le commanditaire dans cette démarche !

Un autre dysfonctionnement réside dans l’absence de démarche contractuelle entre le client et le fournisseur. A défaut d’une solution universelle sur la structure type d’un cahier des charges, on peut a contrario affirmer que le refùs d’un document contractuel augmente la probabilité de désaccords de façon très sensible.

Un programme constitue avant tout la réponse à un besoin d’un client exprimé lors de la phase d’étude. L’absence d’une formulation claire et précise de la demande, comme de la solution adoptée conduit à une non-communication, source d’incompréhension, voire de conflit, entre les acteurs.

Beaucoup de projets échouent lors de leur implantation en milieu utilisateur à la suite d’une incompréhension sur les finalités et les possibilités offertes par le produit. La pauvreté de la documentation entraîne une absence de communication efficace entre les usagers et les concepteurs.

Tout le monde connaît l’adage : "ce qui va sans dire va encore mieux en le disant", on pourrait ajouter : "Ce qui va bien à dire va encore mieux en l’écrivant".

Les acteurs et leurs attentes

Plusieurs acteurs interviennent autour de la fabrication d’un logiciel. Ils ont des motivations diverses fàce à l’utilisation d’une documentation.

- L’usager attend un ensemble de moyens pour utiliser le système dans les situations quotidiennes et se sortir d’affàire en cas d’incident.

- Le concepteur attend une aide à la formalisation du produit, afin d’améliorer sa communication avec les réalisateurs du système d’une part, et les commanditaires d’autre part. Sorte de référence permanente, elle s’inscrit dans la pratique d’un langage de modélisation connu des initiés et fait appel à un formalisme strict.

- Le réalisateur attend une simplification de sa tâche pour réaliser le produit en conformité à la demande. Cela suppose une connaissance du formalisme du concepteur.

- L’opérateur attend des consignes d’exploitation lui permettant une bonne prise en charge du logiciel dans l’environnement de production.

- Le formateur attend une bonne compréhension du système à partir de laquelle il est en mesure de construire ses actions de formation.

- Le chef de projet souhaite disposer d’une série d’informations sur le management du projet, sur le produit comme sur les clients. En cas de dérive la documentation permet un recentrage sur les objectifs.

- Le commanditaire recherche à travers la documentation un ensemble de moyens pour suivre l’évolution du produit, se prémunir contre d’éventuelles malfàçons. Elle lui donne les éléments d’un contrôle économique au fui et à mesure de l’avancement du processus de fabrication.

- Le responsable utilisateur attend le fil conducteur lui permettant de vérifier la bonne adéquation aux besoins exprimés.

Les trois pôles de la documentation

La diversité des acteurs comme des objectifs débouche sur une classification de la documentation autour de trois pôles :

- Le projet. Il regroupe l’ensemble des données sur les ressources, les délais, les coûts des travaux. Elle fournit au chef de projet les constats ou les prévisions sur le déroulement du projet en termes d’événements ou de perturbations. Elle regroupe les documents comme les plannings, les comptes-rendus ou rapports d’activité. Elle s’inscrit dans une dynamique prévision / réalisation / suivi.

- Le client. Centrée sur la connaissance de l’usager, les caractéristiques de son poste de travail, les procédures d’organisation existantes ou les ressources informatiques capables d’accueillir le nouveau produit, la documentation client fournit toutes les informations utiles à une meilleure intégration du système dans l’environnement utilisateur.

- Le produit. Composante à part entière du logiciel, la documentation regroupe toutes les données actualisées sur le produit depuis son architecture jusqu’à son mode d’utilisation. Véritable pierre angulaire du système, elle constitue la seule source d’information àpartir de laquelle les actions de formation, d’assistance, d’exploitation peuvent être mises en oeuvre. Ce travail se trouve simplifié par l’appel à des outils liés au dispositif de fabrication du logiciel que sont les ateliers de génie logiciel. Il y a alors intégration des deux processus.

Gestion de la maintenance

Des demandes d’évolution sont adressées aux équipes projet suite à des modifications réglementaires ou à des améliorations attendues par l’utilisateur.

Formuler sa demande de façon à être compris par l’informaticien est l’espérance de nombreux utilisateurs. D’un autre coté, disposer de demandes de maintenance structurées est le rêve de nombreux analystes programmeurs.

La mise en place d’un formulaire type aide à une meilleure prise en compte de la demande..

Qui élabore les documents ?

Dans la cas de petits projets, le chef de projet se voit confier le tenue des divers documents. Il capitalise alors la connaissance de tous les aspects du projet. Il regroupe dans une même série de documents l’aspect gestion de projet, cycle de vie et maintenance.

Une autre solution consiste à ihire faire la documentation par un échantillon de lecteurs potentiels du document concerne. Par exemple, les spécifications globales du besoin font l’objet d’un cahier des charges utilisateur construit par certains d’entre eux dans le cadre de l’équipe projet. Le client futur usager du produit construit le manuel de prise en main du logiciel àpartir de sa compréhension du produit.

Dans le cadre de projets plus amples, la documentation se trouve intégrée dans les différents niveaux du dispositif de conduite de projet. L’ensemble est géré par le chef de projet. Il est aidé dans cette tâche par une cellule technique chargée de la remise en forme du document selon des normes graphiques ou autres fixées par avance.

La documentation, comme les autres activités du projet, consomme des moyens en temps, en ressources et en outils. A ce titre elle doit faire l’objet d’une estimation, d’une planification et d’un suivi.