La documentation sur le Projet Garantie et Contrats de Service 

Les outils

Pour mener à bien les missions de PGCS, nous avons, à notre disposition, différents outils.
En laissant de côté les outils de bureautique habituels et Internet, il faut signaler :
-Différents outils permettant de lancer des requêtes les bases de données formant le cœur du système d’information de la Garantie (MyExtra, DBVisualizer).
Un outil de gestion des incidents, Chipre (Changement Incident Problème Référentiel). Il s’agit d’un outil de communication entre les usagers et les différentes instances de Renault. Cet outil peut être utilisé quand un utilisateur rencontre un problème avec une application quelle qu’elle soit : son utilisation n’est pas limitée au périmètre de la garantie. Pour la Garantie, le principe est le suivant : un utilisateur (une affaire, une filiale…) rencontre un problème (il n’arrive pas à accéder à une application, ne retrouve pas une facture, n’a pas été remboursé, etc.). Il contacte alors l’assistance (helpdesk) qui émet un ticket Chipre relatant le problème et donnant (en général) les informations nécessaires pour enquêter sur le problème (numéro de compte, numéro de facture, IPN…). Chaque jour, deux personnes ont pour mission spécifique de s’oc¬ cuper de la cellule de support (une demi-journée chacun). La personne d’astreinte au moment de rémission du ticket commence alors à faire des recherches sur l’incident. S’il manque des informations, ou si la personne responsable de la cellule a des questions à poser à l’utilisateur, le ticket peut être mis à jour et renvoyé à l’utilisateur. Il est ainsi possible de communiquer avec l’utilisateur, où qu’il soit dans le monde. Le ticket peut changer de mains, et passer à un autre groupe (au développement Garantie (RS3), au groupe gérant les droits d’accès, au groupe gérant les fichiers EDR…). D’une manière générale, c’est au FSO d’enquêter en premier, et de résoudre l’incident, ou de le renvoyer vers le groupe compétent selon la nature du problème.
Ci-dessous, la page d’accueil du groupe FSO Garantie sur Chipre, listant les incidents en cours.
Un outil permettant de résoudre les incidents remontés par le métier : eRoom. Cet outil permet au métier de relayer ses demandes d’intervention sur les bases de données, de décrire des problèmes qu’il rencontre, etc. C’est, tout comme Chipre, un outil de communication utilisé de manière très régulière. On peut ainsi poser des questions dans l’eRoom, obtenir une réponse, joindre des fichiers… Comme Chipre, l’utilisation d’eRoom a lieu essentiellement pendant la cellule de support, ainsi que pendant la journée de maintenance (journée SPUFI : SQL Processing Using File Input). Toutes les demandes sont conservées, pour des questions de responsabilité des actions, mais aussi pour capitalisation. On peut ainsi retrouver des requêtes utilisées pour des demandes similaires, chercher des informations sur des incidents qui ressemblent à celui qu’on traite, etc.
Les eRooms sont qualifiés en fonction de l’application impactée, de la nature du problème (bug, cohérence des données…), de la gravité, etc.

Gérer la documentation sur un projet multi-acteurs

La vision idéale

Mémoire organisationnelle

Un système documentaire n’est pas un but en soi. C’est un moyen pour arriver à une fin.
Cette fin est la gestion des connaissances, et la gestion de l’accès à cette connaissance. Je vais essayer de décrire dans cette partie le système tel qu’il devrait être mis en place sur PGCS.
Il faut pouvoir retrouver l’information quand on en a besoin, rapidement. Dans cette fonction, je distingue deux parties : la première est celle de la mémoire du service. Quand on doit retrouver les règles de gestion d’une application, un modèle conceptuel de données, etc. il est nécessaire que les documents soient mutualisés et accessibles.
La nature de ces documents est variable. On peut distinguer entre autres les cahiers des charges, les PV de recette (les livrables d’une manière générale), les manuels d’accueil (MAC) mais aussi les documents de gestion interne à chaque équipe qui, eux, ne sont pas consultables par tous. On peut aussi prendre en compte les documents de gestion de chaque GDM : EdB (Études de besoin), grilles de chiffrages, avenants, CDI, etc…
Les problèmes liés à un tel système sont nombreux. Tout d’abord la multiplicité des acteurs.
Chaque équipe rédige des documents, il faut donc trouver une norme pour qu’il n’y ait pas autant de modèles que d’intervenants. De plus, chaque équipe possède son propre espace de stockage sur le serveur, pour des raisons de confidentialité de certains documents. Il faut faire attention à ce que les documents ne se mutiplient pas, pour éviter les confusions de version, ou que deux personnes modifient deux versions du document, aboutissant ainsi à des versions non seulement multiples, mais incomplètes.
Nous sommes ici dans une problématique de mémoire organisationnelle. Stein et Swass (1995) définissent la mémoire organisationnelle comme les moyens par lesquels la connaissance du passé est appliquée pour supporter les activités présentes. La mémoire organisationnelle a par ailleurs été conceptualisée de différentes manières. Ashcraft (1994), par exemple, offre une classification à trois éléments: la mémoire épisodique (les connaissances des événements tels que vécus par les individus), la mémoire sémantique (connaissances factuelles) et la mémoire procédurale (les compétences acquises). Martine Girod (1995), quant à elle, définit la mémoire organisationnelle comme étant un ensemble de compétences associées avec les convictions ainsi que les connaissances, tant déclaratives que procédurales, issues des arrangements structurels inter- et intra-organisationnels. Synthétisant plusieurs disciplines, Girod (1995 ; 1996) distingue trois types de mémoires. Le premier, la mémoire déclarative, est une mémoire explicite renfermant des connaissances accumulées dans les mémoires humaines et se rapportant à des faits, des choses et des événements. Le second, la mémoire procédurale, est implicite et renferme des connaissances sur la manière dont les choses sont faites ou la manière dont certaines tâches sont accomplies. Le troisième, la mémoire de jugement, renferme des connaissances issues de l’expérience personnelle des individus (Girod, 1996).
La mémoire déclarative est la somme des connaissances techniques, scientifiques, et administratives détenues par les membres de l’entreprise. Ces connaissances étant en relation avec leurs tâches, elles devraient être rendues disponibles et accessibles à tous. Étant composée de connaissances explicites sur les faits, les propositions, les événements, les situations, etc. Elle peut inclure des détails sur l’utilisation des machines tels qu’appris à l’école ou tels qu’apportés par les individus lors de leur recrutement.
Sur PGCS, la mémoire déclarative comprend par exemple la connaissance du langage SQL et de la logique relationnelle (ou d’un langage de programmation d’une manière générale).
La mémoire procédurale comprend le savoir-comment que les individus appliquent dans leur quotidien professionnel. Pour Moorman et Miner (1998), c’est la connaissance-compétence et la connaissance-action (skill and action knowledge). Contrairement à la connaissance déclarative qui réside dans les mémoires déclaratives, la connaissance procédurale est le résultat d’un apprentissage personnel. Une entreprise apprenante tente de transformer ce type de connaissances en une connaissance organisationnelle afin de le rendre accessible à tous. Ainsi, des connaissances de routine sont souvent transformées en connaissances procédurales et stockées sous la forme de règles et de procédures de travail (Cohen et Bacdayan, 1994). Girod (1995) qualifie ce type de mémoire de mémoire procédurale collective centralisée et Moorman et Miner (1998) avancent que la mémoire procédurale devient généralement une mémoire automatique ou inconsciente. La plupart du temps tacite, la mémoire procédurale peut, cependant, devenir explicite grâce à l’archivage et à la diffusion sous forme de procédures de travail.
Sur PGCS, ce type de mémoire comprend les techniques de rédaction d’un cahier des charges, la modélisation de processus… Il est à noter que la mémoire procédurale employée dépend beaucoup de l’activité des personnes : un chef de projet emploie des connaissances spécifiques, dont un organisateur n’a pas besoin : planifier l’activité, construire les indicateurs, etc.
La mémoire de jugement reflète la tendance qu’ont les individus à donner une interprétation aux informations reçues, aux événements vécus et à la connaissance en général afin de pouvoir agir. C’est une mémoire sur les raisons pour lesquelles on fait les choses. La mémoire de jugement est également appelée mémoire logique (rational memory) par Moran et Carroll (1996). Par définition, elle se base sur l’expérience et la connaissance propres des individus telles qu’ils perçoivent et interprètent les choses ; c’est ce qui distingue l’opinion d’un expert de celle d’un profane.
C’est malheureusement le type de mémoire qui est le plus susceptible de s’éroder suite à la démission du personnel parce qu’elle est très difficile à extraire, à transférer, à structurer et à formaliser. Au niveau collectif, la mémoire de jugement constitue la somme de toutes les mémoires de jugement individuelles et représente la façon unique qu’une entreprise a de percevoir et d’interpréter son environnement.

Apprentissage

Lorsqu’on arrive sur un projet, il y a nécessairement une période de formation, d’acquisition de connaissances spécifiques au contexte du projet. Une personne arrive avec son capital de mémoire déclarative, mais il lui manque souvent la connaissance contextuelle qui la rendra opérationnelle. La méthode employée par Logica est de partager le temps des nouveaux arrivants entre la lecture de documentations et la cellule de support. C’est une façon de faire découvrir le périmètre qui présente des avantages et des inconvénients : parmi les avantages, on peut noter qu’on passe par un côté plutôt théorique, avec les documentations présentant les applications, ainsi qu’un côté pratique avec la cellule de support. Cette dernière activité se fait en binôme pendant les premières semaines. On allie ainsi le compagnonnage à l’apprentissage par manuels. Cela permet au nouveau de poser des questions et d’étudier des incidents avec une autre personne. Cela per¬ met surtout de contextualiser les connaissances acquises. Brown (1989) met en avant l’exigence d’authenticité des situations d’apprentissage en insistant pour que le contexte d’apprentissage soit leplus proche possible du contexte d’usage. La connaissance acquise est alors pertinente dans le contexte de l’apprenant : il n’y a pas besoin d’apprendre l’algorithme d’un contrôle spécifique tant qu’on n’est pas en train d’essayer de résoudre un problème sur ce contrôle. Par contre, comprendre la logique du processus de facturation, de remboursement… est pertinent dans le caontexte d’une arrivée sur le projet. En fait, c’est ici le contexte qui dicte les connaissances à acquérir.
Dans les points négatifs, il y a très clairement le fait que ces deux activités ne sont pas extrêmement motivantes. La lecture de documentations est une activité rigide et fatigante, et la cellule de support peut être une occupation frustrante, surtout quand on ne connaît pas les applications concernées par les incidents remontés. Ainsi, l’arrivant aborde ce passage obligé à contrecoeur. Pourtant, cet apprentissage est efficace, puisque pour comprendre pourquoi une fonctionnalité ne fonctionne pas normalement, il faut comprendre son fonctionnement normal.
Pendant cette phase, l’apprenant est confronté à de nombreuses questions. Les manuels d’accueil répondent à certaines, mais pas à toutes. Il faut alors chercher d’autres sources d’information. CIM est de toute évidence un bon moyen de trouver des réponses, mais encore une fois, cet outil n’est pas toujours suffisant et, comme souvent, la seule possibilité qu’il reste est de poser la question à quelqu’un de plus ancien. Nous reviendrons sur ce point plus tard.
Traçabilité Pour finir sur les buts de la gestion documentaire, j’aimerais aborder un dernier point. Un certain nombre de documents sont rédigés afin d’établir une certaine traçabilité des actions. Par exemple, lors de la journée SPUFI (journée de maintenance des bases de données, où nous effectuons des actions en base qui ne peuvent être réalisées à partir des IHM), nous devons rédiger pour chaque action une fiche sur laquelle sont inscrits : l’identité de la personne qui a rédigé la fiche, la base de données impactées, la (ou les) table(s) impactée(s), les requêtes de contrôle avantaction, la requête de modification/suppression/insertion, les requêtes de contrôle après action, le nombre d’enregistrements impactés et la nature de l’impact (modification/suppression/insertion).
Cette fiche doit être imprimée et signée par un responsable de RS3. Les documents Word sont conservés dans un dossier recensant toutes les actions réalisées sur les bases de données, et les versions papier sont conservées par le FSO. On a ici un double emploi du document : d’une part la traçabilité (qui a fait une action, quand, quelle était l’action, suite à quelle demande) qui permet également de mettre en place une responsabilité, grâce à la signature de RS3. D’autre part, il y a une capitalisation sur les actions effectuées. En effet, il est courant que les actions se répètent tous les mois ou tous les deux mois : on effectue les mêmes requêtes, mais sur des données différentes. Comme les fiches sont conservées, il suffit de retrouver la demande (eRoom) du mois précédent pour retrouver la requête.

Windows Search

À force de demandes répétées, l’installation d’un moteur de recherche interne a été acceptée et mise en place. Il s’agit de Windows Search. Ce moteur indexe les documents présents sur le réseau de l’entreprise (ceux auxquels les droits d’utilisateur permettent d’accéder). Il agit la nuit, ou en cas de non-utilisation de l’ordinateur. L’indexation se fait sur le plein texte, le titre, les métadonnées… L’intérêt de cet outil est immédiatement visible : on peut trouver des documents sans avoir recours aux arborescences. Il y a cependant des désavantages : tout d’abord le mode d’indexation. L’indexation se fait sur tout mot trouvé, qu’il soit dans le texte, l’en-tête ou le pied de page, le titre, la description du document… Ce qui pourrait être un avantage s’il y avait un algorithme de valorisation des termes trouvés selon leur contexte. Il faudrait donner du  ‘poids’ à ce qui est trouvé dans un titre de chapitre, et moins à ce qui est trouvé dans une note de bas de page, par exemple. L’absence d’un tel algorithme empêche tout classement par pertinence de la sélection trouvée. De plus, le fait qu’il n’y ait pas de politique documentaire définie fait que l’auteur peut mettre ce qu’il veut comme descripteur du document. On trouve donc parfois, suite à une recherche, des documents qui n’ont rien ou peu à voir avec la recherche effectuée. Par ailleurs, et cela a été une surprise quand je l’ai démontré à l’équipe, Windows Search n’est pas capable d’indexer à l’intérieur d’une archiveZip ou Rar. Or la politique de Renault est d’essayer de gagner de la place sur les serveurs en archivant sous ce genre de format les documents des années précédentes. On peut actuellement trouver dans l’arborescence des documents de 2008 ou 2009, mais pour des documents plus vieux, il faut chercher dans différentes archives pour retrouver ce que l’on cherche. Par conséquence, quand on cherche des règles de gestion rédigées il y a longtemps (le plus souvent pour des applications qui n’évoluent presque plus), Windows Search est inutile. Pour lutter contre le phénomène des règles de gestion éparpillées à plusieurs endroits, Renault essaie de mettre en place un nouveau type de document.

Sésame, l’intranet de Logica

Logica a mis en place un intranet. Celui-ci permet une communication verticale (essentiellement du haut vers le bas), ainsi qu’une communication horizontale, entre employés. Un annuaire est ainsi accessible, où on peut retrouver les CV des employés, parfois leur photo, leur domaine de compétence, et on peut également les contacter. Il existe aussi des communautés rassemblées autour d’unsujet particulier. Par exemple : Communauté Cortex, Communauté Sésame, Communauté e-université, Communauté OMEGA AMO… Il est ainsi possible de trouver des documents mis à disposition par les employés de Logica : Plans Action Qualité, Plans de Gestion Documen taire, Portfolio des offres, etc.
Une équipe-projet se doit de communiquer pour être efficace, et pour survivre en tant qu’équipe, et non en tant qu’addition d’individus. Même s’il est possible de trouver les réponses dans les documentations, le fait de poser une question au reste du groupe est bien souvent plus efficace que de lire une documentation pendant une heure. Dans le pire des cas, si personne n’a la réponse à la question, on peut alors lire la documentation. Cela représente un gain de temps, mais pas seulement. Pour la plupart des gens, le compagnonnage est la méthode d’apprentissage laplus efficace.

Le concept de pratique

En général, les membres d’une équipe projet possèdent des pratiques communes. J’utilise ici le terme « pratique » dans le sens que lui donne Etienne Wenger : pour Wenger, la pratique relève du faire, dans ses dimensions à la fois historiques et sociales, et dans sa capacité à produire de la structure et une signification aux actions. Ce concept de pratique inclut à la fois le champ de l’explicite (le langage, les outils, les documents, les symboles, les procédures, les règles que les différentes pratiques rendent explicites), et le registre du tacite (relations implicites, conventions, hypothèses, représentations sur le monde).

Les contraintes

La mise en place d’une organisation de l’information efficace est un processus parfois difficile. Tout changement dans une organisation structurée doit être amené avec précautions, et accompagné d’un dialogue afin de faire accepter ce changement. Il existe, en dehors de ceci, des contraintes plus spécifiques au domaine des SSII, ainsi qu’à Logica.

Contraintes budgétaires

La gestion documentaire paraît nécessaire à la plupart des gens, familier ou non du domaine.
Cependant, pour les entreprises cela représente un investissement dont les effets ne sont pas forcément visibles, notamment en termes de gain d’argent. Il faut dire que ça n’est pas le but premier de la gestion de l’information que de générer de l’argent. En conséquence, l’équation Investissement + Pas de gain visible directement est souvent synonyme de Peu d’investissement.
De plus, il est parfois difficile de trouver quelqu’un possédant les compétences et la volonté de mettre enplace la gestion documentaire sur les projets. Même si une équipe compte une personne adéquate, la nature même de la prestation de service rend difficile ce genre de processus : lorsqu’une personne travaille sur des opérations de gestion de projet (comme c’est le cas pour le PGD), Logica ne facture pas ce temps au client. Même s’il y a un socle pour la gestion de projet qui est facturé au client (un certain nombre de jours défini par contrat), une fois ce socle épuisé, le temps passé à ces opérations n’est plus payé par le client. Dans mon cas, je me déclarais comme travaillant sur un projet autre que PGCS chaque fois que j’effectuais des opérations pour la mise en place du PGD. Ainsi, mon temps de travail n’était pas facturé à Renault, et je ne dépensais pas de temps sur le socle de gestion de projet. C’est un facteur qui peut sembler trivial, mais il est en fait important : les projets doivent être rentables. Pour résumer, au risque d’énoncer une évidence, le client doit payer plus que ce que dépense Logica. Si une équipe projet passe trop de temps à la gestion interne, le projet devient moins rentable.

Contraintes d’entreprise

J’ai déjà présenté Cortex et sa solution de gestion documentaire. Il est important qu’une entreprise fournisse des outils pour faciliter la gestion (documentaire ou autre) d’un projet. Ainsi, Cortex fournit des solutions, mais il ne faut pas que celles-ci soient trop rigides, et finissent par trop contraindre l’utilisateur. Le problème, plus que la contrainte effective, est que proposer des solutions ‘clés en main’ n’est pas forcément une bonne idée quand cette solution doit s’appliquer à des projets dont la nature et l’organisation peuvent varier, d’autant plus quand personne sur le projet n’a été formé à cette façon de s’organiser.

Table des matières
INTRODUCTION 
I. PRESENTATION DU CONTEXTE 
1. Les activites
2. Les applications de la garantie renault
3. les acteurs
• Logica
• Le métier Garantie(Renault)
• RS3
4. Les outils
II. GERER LA DOCUMENTATION SUR UN PROJET MULTI-ACTEURS 27
1. la vision ideale
• Mémoire organisationnelle
•Apprentissage
•Traçabilité
2. Les outils disponibles
• Cortex
• Windows Search
• Sesame, l’intranet de Logica
3. La documentation sur le Projet Garantie et Contrats de Service
•Etat des lieux de la gestion documentaire sur le projet
• Les contraintes
III. L’EVOLUTION DE LA NATURE DES DOCUMENTS 
1. Classifications de documents
2. Une nature évolutive
CONCLUSION 
BIBLIOGRAPHIE 
ANNEXES 
Annexe 1 :Lexique 
Annexe 2 : Tableau des Documents projet 
Annexe 3 : Modèle de Plan de Gestion Documentaire

Lire le rapport complet