GED

Acquisition et mise en place dun logiciel de Gestion
Electronique
de Documents
Sabine Champenois
To cite this version:
Sabine Champenois. Acquisition et mise en place dun logiciel de Gestion Electronique

de
Documents. Information Retrieval. 2011. <dumas-00693935>
HAL Id: dumas-00693935

http://dumas.ccsd.cnrs.fr/dumas-00693935
Submitted on 10 May 2012
HAL is a multi-disciplinary open access

archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
Larchive ouverte pluridisciplinaire HAL, est

destinee au depot et `a la diffusion de documents
scientifiques de niveau recherche, publies ou non,
emanant des etablissements denseignement et de
recherche francais ou etrangers, des laboratoires
publics ou prives.
CONSERVATOIRE NATIONAL DES ARTS ET METIERS

CENTRE REGIONAL ASSOCIE DE VERSAILLES
________________
MMOIRE
prsent en vue d'obtenir
le DIPLOME D'INGENIEUR CNAM
SPECIALITE : Informatique
OPTION : Systmes d'Information
par
Sabine CHAMPENOIS
________________
Acquisition et mise en place d'un logiciel de Gestion lectronique de Documents

Soutenu le 22 juin 2011
________________
JURY
PRESIDENT :
M. Kamel BARKAOUI
MEMBRES :
M. Georges KERIVEL
M. Michel SCHOUHMANN
Remerciements
Je souhaite tout d'abord remercier l'ensemble du personnel de GTT pour son accueil
chaleureux, sa disponibilit et la participation ce projet d'entreprise.
En particulier, je souhaite adresser mes remerciements M. Yataghne et M. Rodire pour
m'avoir recrute pour mener bien ce projet. Ils m'ont fait confiance et laiss autonome
dans la ralisation de cette tche. Je les remercie galement pour le temps qu'ils ont
consacr la relecture de ce mmoire.
Je remercie galement l'ensemble des participants du COUTIL qui par leurs ides et leur
travail ont contribu la russite de ce projet.
J'ai galement apprci le soutien de l'ensemble du Dpartement Systme d'Information
qui par leur assistance pour la mise en place du logiciel mais aussi par leur espiglerie
m'ont beaucoup aide au quotidien.
Je remercie l'ensemble des enseignants et l'quipe pdagogique du CNAM de Versailles
pour leur enseignement qui m'a beaucoup apport tant au niveau personnel que
professionnel. Sans ses connaissances, je n'aurai pu mener bien ce projet.
Je souhaite remercier tout particulirement M. Schouhmann en tant que tuteur. Ses conseils
et remarques m'ont permis d'aboutir dans ce long travail.
Sabine Champenois
2/125
Sommaire
Remerciements .......................................................................................................................... 2
Sommaire................................................................................................................................... 3
Liste des figures ........................................................................................................................ 5
Liste des tableaux ..................................................................................................................... 6
I
Prsentation gnrale ........................................................................................................ 7
II Matrise de la gestion lectronique des documents ...................................................... 10

II.1 Prsentation de GTT .................................................................................................. 10
II.1.1
Activits de l'entreprise .................................................................................. 10
II.1.2
Services proposs par GTT............................................................................. 11
II.1.3
Organisation de GTT ...................................................................................... 12
II.2 Le besoin en matire de gestion de documents .......................................................... 14
II.2.1
Outils pour la production et la gestion des plans ............................................ 14
II.2.2
Explorateur Windows ..................................................................................... 14
II.2.3
Secrtariat ....................................................................................................... 15
II.2.4
Fonctionnalits proposes par les logiciels de GED ...................................... 16
II.3 Exigences pour un systme de gestion lectronique de documents........................... 17
II.3.1
Exigences fonctionnelles ................................................................................ 17
II.3.2
Exigences non fonctionnelles ......................................................................... 21
II.3.3
Exigences du projet ........................................................................................ 24
III Mise en place du logiciel Cincom ECM......................................................................... 26
III.1 Cycle de vie dun document paramtr ..................................................................... 26
III.2 Fonctionnalits et workflows mis en place ................................................................ 27
III.2.1
Fonctionnalits implantes ............................................................................. 28
III.2.2
Workflows mis en place ................................................................................. 39
III.3 Architecture applicative ............................................................................................. 43
III.4 Architecture technique ............................................................................................... 45
IV Conduite du projet .......................................................................................................... 47
IV.1 Phase Planification ..................................................................................................... 48
IV.1.1
Prsentation des mthodes et des standards utiliss ....................................... 48
IV.1.2
Plan de management du projet........................................................................ 54
IV.2 Phase Acquisition ...................................................................................................... 69
IV.2.1
Recueil des exigences ..................................................................................... 70
IV.2.2
valuation du march ..................................................................................... 75
IV.2.3
Appel d'offre et slection du fournisseur ........................................................ 76
IV.2.4
Contractualisation ........................................................................................... 77
IV.3 Phase Mise en place du logiciel ................................................................................. 78
IV.3.1
Ralisations de Cincom .................................................................................. 78
IV.3.2
Suivi du fournisseur ........................................................................................ 79
IV.3.3
Vrification et validation ................................................................................ 80
IV.3.4
Clture du contrat ........................................................................................... 84
IV.4 Phase Amlioration .................................................................................................... 84
IV.4.1
Planification de projet..................................................................................... 84
IV.4.2
Surveillance et contrle du projet ................................................................... 86
IV.4.3
Gestion des accords avec les fournisseurs ...................................................... 88
IV.4.4
Gestion des risques ......................................................................................... 89
Sabine Champenois
3/125
IV.4.5
IV.4.6
Vrification ..................................................................................................... 90
Validation ....................................................................................................... 91
V Bilan .................................................................................................................................. 92
V.1 Bilan du projet ........................................................................................................... 92
V.2 Bilan technique .......................................................................................................... 94
V.3 Bilan organisationnel ................................................................................................. 95
V.4 Bilan global ................................................................................................................ 96
V.5 Bilan personnel .......................................................................................................... 98
VI Conclusion ...................................................................................................................... 100
VII Abrviations et glossaire ............................................................................................... 102
VIII
Bibliographie ............................................................................................... 104
Annexes .................................................................................................................................. 105

Annexe 1 : Rcapitulatif du PMBOK pour la dfinition du contenu du projet ............... 105
Annexe 2 : Rcapitulatif du PMBOK pour la gestion des dlais du projet ..................... 106
Annexe 3 : Rcapitulatif du PMBOK pour la gestion des cots du projet ...................... 107
Annexe 4 : Rcapitulatif du PMBOK pour la gestion des communications du projet .... 108
Annexe 5 : Rcapitulatif du PMBOK pour la gestion des risques du projet ................... 109
Annexe 6 : Rcapitulatif du PMBOK pour la gestion des modifications du projet ........ 110
Annexe 7 : Exigences selon la norme NF X50-151 pour une expression fonctionnelle
du besoin ....................................................................................................... 111
Annexe 8 : Exigences selon la norme NF X50-151 pour un cahier des charges
fonctionnel .................................................................................................... 112
Annexe 9 : Activit "Acquisition advertisement" selon la norme ISO/CEI 12207 ......... 113
Annexe 10 : Activit "Supplier selection" selon la norme ISO/CEI 12207 ...................... 114
Annexe 11 : Activit "Contract agreement" selon la norme ISO/CEI 12207 ................... 115
Annexe 12 : Activit "Agreement monitoring" selon la norme ISO/CEI 12207 .............. 116
Annexe 13 : Activit "Software verification process" selon la norme ISO/CEI 12207 .... 117
Annexe 14 : Activit "Software validation process" selon la norme ISO/CEI 12207 ...... 120
Annexe 15 : Activit "Software Problem Resolution Process" selon la norme
ISO/CEI 12207 ............................................................................................. 122
Annexe 16 : Activit "Acquirer acceptance" selon la norme ISO/CEI 12207 .................. 123
Annexe 17 : Activit "Closure" selon la norme ISO/CEI 12207 ...................................... 124
Sabine Champenois
4/125
Liste des figures

Figure 1 : Organigramme de GTT ............................................................................................ 12
Figure 2 : Cycle de vie d'un document ..................................................................................... 18
Figure 3 : Cycle de vie d'un document tel que paramtr dans Cincom ECM ......................... 26
Figure 4 : Plan de classement de l'espace Commun ................................................................. 28
Figure 5 : Plan de classement type d'un projet Innover ............................................................ 29
Figure 6 : Plan de classement type d'un projet Produire .......................................................... 29
Figure 7 : Plan de classement type d'un mtier ........................................................................ 30
Figure 8 : Exemple de droits sur une branche .......................................................................... 30
Figure 9 : Mtadonnes renseigner pour crer un document ................................................. 31
Figure 10 : Fentre de l'assistant pour le modle de document projet...................................... 32
Figure 11 : Page de garde d'un document projet renseign l'aide de l'assistant..................... 33
Figure 12 : Identifiant de document gnr en automatique .................................................... 34
Figure 13 : Fichiers annexes dans les mtadonnes ................................................................. 35
Figure 14 : Lien entre documents dans les mtadonnes ......................................................... 35
Figure 15 : Documents de travail et de diffusion ..................................................................... 36
Figure 16 : Mtadonnes propres un courriel ........................................................................ 37
Figure 17 : Rsultats d'une recherche simple ........................................................................... 38
Figure 18 : Tche de validation ................................................................................................ 39
Figure 19 : Cartouche avec signatures...................................................................................... 40
Figure 20 : Lien de type "Est remplac par" dans un document obsolte ................................ 41
Figure 21 : Extrait du contenu d'un TF ..................................................................................... 42
Figure 22 : Architecture applicative ......................................................................................... 43
Figure 23 : Architecture technique ........................................................................................... 45
Figure 24 : Processus du cycle de vie d'un logiciel selon l'ISO/CEI 12207 ............................. 50
Figure 25 : Organisation du projet............................................................................................ 56
Figure 26 : Planning du projet, phase Acquisition ................................................................... 60
Figure 27 : Planning du projet, phase Mise en place ................................................................ 61
Sabine Champenois
5/125
Liste des tableaux

Tableau 1 : Points forts et points faibles des outils utiliss pour la gestion et la production
des plans ............................................................................................................... 14
Tableau 2 : Points forts et points faibles de l'Explorateur Windows pour grer les
documents ............................................................................................................. 15
Tableau 3 : Points forts et points faibles du logiciel Secrtariat .............................................. 15
Tableau 4 : tats du cycle de vie d'un document...................................................................... 19
Tableau 5 : Rcapitulatif des normes et mthodes utilises dans le cadre du projet ................ 53
Tableau 6 : Plan de management des communications du projet ............................................. 64
Tableau 7 : Extrait du registre des risques du projet ................................................................ 68
Tableau 8 : Modle de prsentation d'un cas d'utilisation ........................................................ 71
Tableau 9 : Acteurs et objectifs ................................................................................................ 72
Tableau 10 : Exemple de cas d'utilisation ................................................................................ 73
Tableau 11 : Bilan du domaine de processus "Planification de projet" du CMMI .................. 86
Tableau 12 : Bilan du domaine de processus "Surveillance et contrle du projet" du CMMI . 87
Tableau 13 : Bilan du domaine de processus "Gestion des accords avec les fournisseurs"
du CMMI .............................................................................................................. 88
Tableau 14 : Bilan du domaine de processus "Gestion des risques" du CMMI ....................... 89
Tableau 15 : Bilan du domaine de processus "Vrification" du CMMI ................................... 90
Tableau 16 : Bilan du domaine de processus "Validation" du CMMI ..................................... 91
Tableau 17 : Bilan des cots du projet ..................................................................................... 92
Tableau 18 : Bilan des dlais du projet .................................................................................... 92
Tableau 19 : Bilan des fonctionnalits implmentes .............................................................. 93
Sabine Champenois
6/125
Prsentation gnrale
GTT est une socit d'ingnierie spcialise dans la conception de systmes de stockage et
de transport du Gaz Naturel Liqufi (GNL). Ses processus de production traitent de
l'innovation, la vente, la production et le conseil dans son domaine de comptences. Cet
ensemble d'activits produit principalement des documents destination interne ou
diffuss l'extrieur en tant que livrables clients. Les outils et mthodes existants ont
atteint leurs limites et il apparat donc ncessaire d'acqurir un logiciel de Gestion
lectronique de Documents (GED).
Un tel outil a pour fonction d'acqurir, produire, grer, stocker, archiver et diffuser des
documents au format lectronique afin de les centraliser en une base commune. Cet outil
de travail collaboratif peut, au moyen de workflows, assister, voire automatiser les
diffrentes tapes du cycle de vie d'un document. Il doit tre accompagn d'une
mthodologie de travail afin d'en optimiser l'utilisation.
La Direction Gnrale de GTT m'a donc recrut en tant que chef de projet pour
l'acquisition et la mise en place d'un tel logiciel. Mes objectifs en tant qu'assistant la
matrise d'ouvrage ont t d'tablir les exigences fonctionnelles afin de slectionner un
fournisseur puis de mettre en place le logiciel acquis.
Les fonctions souhaites couvrent le cycle de vie d'un document : sa cration, sa
modification, sa mise en validation, sa consultation, sa diffusion et son archivage. La mise
en place d'un tel outil doit tre accompagne de la formation des utilisateurs et
administrateurs. L'outil doit pouvoir s'intgrer dans le systme d'information de GTT et
pouvoir grer un volume important de documents car la reprise du fonds existant est
prvue terme. L'architecture technique doit permettre d'assurer une trs bonne
disponibilit car c'est un outil central de la production de l'entreprise. Enfin, GTT souhaite
tre autonome sur le paramtrage de l'outil et pouvoir ventuellement faire voluer les
fonctionnalits.
La Direction Gnrale n'a pas impos de budget, ni de dlai. Le projet s'est droul sur
2 ans de janvier 2008 dcembre 2010.
Pendant tout le droulement du projet, je me suis appuye sur le Comit Utilisateurs et le
Comit de Pilotage et j'ai travaill avec le personnel du Dpartement Systme
d'Information auquel je suis rattache. J'ai rapport de l'avancement du projet la Direction
Gnrale car c'est un projet stratgique pour l'entreprise.
La mise en place du logiciel de GED slectionn, Cincom ECM, s'appuie sur les processus
de production et de gestion des divers documents raliss GTT ainsi que sur la procdure
de matrise documentaire du Systme de Management de la Qualit.
Les documents s'organisent au travers de plans de classement par type de projet et mtier
avec des droits d'accs associs. Cincom ECM permet de crer des documents partir de
modles ou partir de fichiers existants. Un certain nombre de mtadonnes associs aux
documents permet leur indexation et l'optimisation des recherches. Le systme permet
galement la gestion des courriels.
L'accs aux documents se fait par l'arborescence documentaire, la recherche et
l'abonnement.
Sabine Champenois
7/125
La validation des documents peut se faire au travers de deux workflows de validation qui
permettent d'obtenir le fichier PDF du document contenant les signatures des divers
approbateurs.
Le suivi des documents livrs est ralis au travers d'un ensemble de fonctionnalits
permettant d'tablir la liste des documents livrer, de gnrer le bon de livraison, de
raliser l'approbation de ce bon, d'exporter l'ensemble des fichiers livrer et d'indiquer
pour chaque document la version, la date et le destinataire.
L'architecture mise en place au travers de serveurs virtuels permet d'obtenir un niveau de
disponibilit satisfaisant.
Le projet s'est droul en quatre grandes phases.
La phase de planification concerne la mise en place du projet avec la rdaction d'un

plan de management du projet.
La phase d'acquisition du logiciel de GED et de slection de son fournisseur a consist

dans le recueil des exigences auprs des utilisateurs pour aboutir la rdaction de
l'expression fonctionnelle du besoin et du cahier des charges fonctionnel. Puis lanalyse
des outils disponibles sur le march a permis de dfinir les solutions logicielles pouvant
rpondre aux exigences de GTT. Enfin, un appel d'offres a permis la slection d'un
logiciel de GED et dun intgrateur du produit dans lenvironnement de GTT pour se
terminer par la contractualisation avec un fournisseur la fois diteur du logiciel :
Cincom.
La phase de mise en place du logiciel de GED a consist en la dfinition des

spcifications fonctionnelles permettant d'tablir les paramtrages ncessaires la mise
en place du logiciel dans le contexte de GTT. Tout au long de cette phase, le suivi du
fournisseur et du contrat a t ralis. Enfin, les activits de validation et vrification
devant conforter le choix du produit pour les utilisateurs se sont acheves avec la mise
en production du systme de GED et la clture du contrat.
La phase dvaluation a eu pour objectif d'valuer les activits et tches ralises tout
au long du projet afin de dterminer les voies d'amlioration.
L'ensemble de la conduite du projet ncessite la mise en uvre de bonnes pratiques :
Le suivi des recommandations du PMBOK (Project Management Body Of Knowledge)

pour l'tablissement du plan de management et donner le cadre de travail l'ensemble
du projet,
la norme ISO/CEI 12207 pour mener les processus d'acquisition, de validation, de

vrification et de rsolution des problmes du logiciel,
la norme NF X50-151 pour dfinir le contenu et le cycle de vie de l'expression

fonctionnelle du besoin et du cahier des charges fonctionnel rdigs pour raliser
l'appel d'offre,
le livre d'Alistair Cockburn pour recueillir les exigences fonctionnelles auxquelles

devra rpondre le logiciel de GED acqurir et ainsi alimenter une partie de
l'expression fonctionnelle de besoin,
le CMMI (Capacity Maturity Model Integration) pour valuer la ralisation et

dterminer des voies d'amlioration.
Sabine Champenois
8/125
Le bilan plutt positif du projet a eu pour objectif de faire un tat des lieux complet de tous
ses aspects. Ce bilan du projet apporte une vue en termes de cot, qualit, fonctionnalits et
dlais. Le bilan technique traite de l'utilisation, de la fiabilit, de la performance, de
l'administration et de l'volutivit de l'application mise en place. Le bilan organisationnel
montre les apports du projet pour l'entreprise et ses salaris du point de vue humain et des
nouveaux processus de travail mis en place. Enfin, un bilan global permet de mettre en
vidence les points forts du projet et les axes d'amlioration mais galement de prsenter
les projets qui dcouleront de cette acquisition et mise en place d'une GED. Pour complter
ces diffrents bilans, je prsenterai ce que m'a apport ce projet.
Ce document prsente dans une premire partie (voir II) l'entreprise et son contexte, la
ncessite de mettre en place un systme de GED pour rpondre ses besoins de gestion
documentaire et les exigences associes. Dans une deuxime partie (voir III), les
fonctionnalits et les workflows mis en place sont dcrits ainsi que l'architecture
applicative et technique. Dans une troisime partie (voir IV), l'ensemble des aspects de la
conduite du projet est trait pour toutes les phases du projet. Les normes et mthodes mises
en uvre et leur application sont expliques. Enfin, dans la dernire partie (voir V), un
bilan de tous les aspects du projet est tabli.
Sabine Champenois
9/125
II Matrise de la gestion lectronique des documents

GTT est une socit d'ingnierie franaise spcialise dans la conception de systmes de
stockage et de transport du GNL (Gaz Naturel Liqufi la pression atmosphrique et
-163C). L'ensemble de ses activits produit principalement des documents destination
interne ou diffuss l'extrieur en tant que livrables des chantiers navals ou des EPC
(Engineering Procurement Construction) auxquels des licences sont concdes. Les outils
et mthodes actuels ont atteint leurs limites et il apparat donc ncessaire d'acqurir un
logiciel de GED (Gestion lectronique de Documents). Dans cet objectif, un chef de projet
a t recrut et des exigences fonctionnelles, non fonctionnelles et de gestion de projet ont
t tablies.
II.1
Prsentation de GTT
GTT est spcialise dans la conception de systmes de confinement membranes pour le

transport et le stockage du GNL. Elle offre ses clients de nombreux services autour de ses
comptences et savoir-faire dans son domaine d'expertise.
L'entreprise s'organise autour de quatre Directions : Innovation, Commerciale, Technique
et Administrative et Financire.
II.1.1 Activits de l'entreprise
GTT est ne de la fusion en 1994 de deux entreprises franaises dingnierie navale
spcialises dans la conception de systmes disolation pour les cuves des navires destins
au transport du GNL : Gaz Transport et S.N. Technigaz.
Le gaz naturel se liqufie la pression atmosphrique lorsque des conditions cryogniques
lui sont associes ; les instances internationales classent le GNL comme tant un produit
dangereux et ce titre requiert des prcautions pour sa manipulation et son transport. Cela
implique que les produits de GTT relvent de technologies de pointe et que GTT agit sur
un march de niche. Ses technologies sont dites " membranes" et GTT est lunique
dtenteur des brevets relevant de ce domaine.
Depuis, GTT a largi son offre dans des domaines connexes tels que le stockage terrestre
de GNL et un tuyau sous-marin permettant de transfrer du GNL depuis un navire jusqu
un stockage terrestre.
Filiale de GDF SUEZ (40%), TOTAL (30%) et Hellman & Friedman (30%), GTT compte
aujourdhui environ 200 salaris. Lentreprise est base en rgion parisienne Saint-Rmyls-Chevreuse (78).
GTT intervient comme bailleur de licence auprs des chantiers navals qui construisent les
mthaniers et auprs de socits d'ingnierie de type EPC construisant des rservoirs
terrestres.
Les chantiers navals et les EPC sont les clients directs de GTT. Les armateurs qui
commandent ces navires aux chantiers constituent les clients finaux de GTT car les navires
sont construits avec une dure de vie de 40 ans qui excde donc la priode de garantie d
peu prs deux ans consentie par les chantiers.
Sabine Champenois
10/125
GTT est trs actif auprs des armateurs tant en amont (faisabilit de leurs projets) quen
aval maintenance des navires pendant toute leur vie. GTT a un rle dexpert technique et
conserve entre autres des archives sur tous les mthaniers construits avec les technologies
membranes, ce qui lui permet de fournir une prestation de conseil recherche.
Afin dapporter le meilleur service aux armateurs, GTT a tabli un rseau de partenaires
varis qui comprend aussi bien des laboratoires spcialiss dans ltude et
l'exprimentation des matriaux que des chantiers navals de rparation qui sont
potentiellement amens intervenir sur les mthaniers pour des oprations de maintenance
ou de rparation.
Ces activits permettent GTT d'offrir divers services ses clients.
II.1.2 Services proposs par GTT
GTT fournit un large ventail de comptences, savoir-faire et ressources dans le domaine
du transport et du stockage de gaz liqufis basses tempratures ou en conditions
cryogniques :
la cession de licences de fabrication selon les brevets de GTT,
la conception de systme de confinement pour le GNL, le GPL (Gaz de Ptrole

Liqufi) et l'thylne,
la ralisation d'avant-projets de navires, barges ou rservoir de stockage et l'laboration

de donnes permettant un chantier ou une socit d'ingnierie de faire une offre dans
des dlais rduits,
les tudes du systme des cuves,
les tudes des systmes de manutention et de transfert de cargaison,
l'homologation des fournisseurs de matriaux et composants des technologies GTT,
l'assistance technique au chantier de construction ou la socit d'ingnierie, le

dveloppement des outillages spcifiques de prfabrication et de montage et
l'industrialisation en gnral des phases de construction,
l'assistance technique pendant lexploitation du navire ou du rservoir terrestre,
la formation,
l'interface avec les socits de classification qui approuvent les technologies conues
par GTT et autorisent la navigation d'un navire une fois sa construction acheve.
GTT s'appuie sur son organisation afin de raliser ces services.
Sabine Champenois
11/125
II.1.3 Organisation de GTT

L'organisation de GTT en quatre Directions permet de raliser les divers services proposs
et vendus ses clients. Elle est prsente la Figure 1.
Prsident Directeur
Gnral
Directeur Gnral
Dlgu
Dlgue
juridique
Direction de
lInnovation
Equipe dlgue
la qualit
Direction
Commerciale
Direction
Technique
Direction
Administrative et
Financire
Figure 1 : Organigramme de GTT
Lquipe dlgue la qualit propose la Direction Gnrale une organisation ainsi que
des modes opratoires permettant lentreprise datteindre ses objectifs notamment en
matire de qualit. Elle met en place, fait vivre et amliore le SMQ (Systme de
Management de la Qualit) de l'entreprise dans le cadre de la certification ISO 9001
version 2008.
La Direction de lInnovation est en charge des dveloppements techniques de l'entreprise
jusqu'au stade de lindustrialisation des technologies, c'est--dire de la conception jusqu'
l'industrialisation gnrique conduite avec un ou plusieurs chantiers. Cette dernire phase
est mene de concert avec les Directions Commerciale et Technique.
Sabine Champenois
12/125
La Direction Commerciale a pour mission gnrale de conduire l'activit commerciale de

la socit et de s'assurer de la bonne excution des contrats. Elle dveloppe des outils
ncessaires l'activit commerciale et participe la promotion des technologies de
l'entreprise. Les principales missions de la Direction Commerciale sont :
rechercher et analyser les informations sur le march et l'environnement,
prparer et dployer la politique de communication,
dvelopper et entretenir les relations avec les prescripteurs (armateurs, gouvernements

et toutes socits ou organismes intervenant lors des processus de dcisions pour la
construction d'un mthanier ou d'un rservoir terrestre),
dvelopper et entretenir les relations avec les licencis et suivre les affaires,
rechercher des voies de diversification et maintenir le dossier d'orientation stratgique.
La Direction Technique a pour mission gnrale de conduire l'activit technique lorsque

celle-ci intervient aprs la phase de dveloppement. Ses missions sont les suivantes :
fournir les notes d'tudes (architecture navale, mouvements de liquide, structure,

procds et instrumentation) lors des phases avant-projet et projet/affaire,
fournir les plans du systme de cuve et des systmes de manutention et du transfert de

cargaison lors de la phase projet/affaire,
assurer un support technique la construction et la maintenance auprs des chantiers

ou autres intervenants.
La Direction Administrative et Financire est en charge de lensemble des activits support

de l'entreprise (finances, ressources humaines, systme d'information et moyens gnraux)
ncessaires au bon fonctionnement de lentreprise.
Au sein de cette Direction, le Dpartement Systme d'Information (SI), auquel j'appartiens
en tant que chef de projet GED, ralise les activits suivantes :
la maintenance, linstallation de tout matriel et logiciel informatique,
l'assistance des utilisateurs sur des problmes gnraux,
le bon fonctionnement du systme, du rseau et de son optimisation,
la scurit en gnrale du systme dinformation,
le recensement des besoins mtiers des utilisateurs, leurs analyses et ventuellement la

proposition de solutions,
le suivi des projets : rdaction des cahiers des charges et des spcifications
fonctionnelles, mise en uvre des solutions et conduite du changement,
la ralisation des tudes, et le cas chant, des dveloppements d'application (en liaison
avec les Directions concernes),
la maintenance des dveloppements existants,
la mise en place de progiciels du march,
la cohrence de lensemble du SI.
Sabine Champenois
13/125
La majorit de la production de l'entreprise consiste en des documents qui ncessitent

d'tre organiss, grs et dont la diffusion doit tre suivie. Tous ces documents sont
produits par l'ensemble des salaris de GTT.
II.2
Le besoin en matire de gestion de documents
GTT ne possde pas de logiciel ddi pour la gestion de ses documents. Ils sont grs au
travers de divers outils :
un outil de CAO (Conception Assiste par Ordinateur) pour les plans,
l'Explorateur de fichiers de Windows pour tous les autres documents,
un logiciel "maison" nomm Secrtariat qui permet de prendre des identifiants de

documents de faon assurer une identification unique de chaque document.
Ses outils possdent des fonctions intressantes mais incompltes pour une gestion
optimise de l'ensemble des documents de l'entreprise. Les fonctions apportes par un
logiciel de GED pourraient permettent de palier ces manques.
II.2.1 Outils pour la production et la gestion des plans
L'outil de CAO SolidWorks Enterprise permet la ralisation des plans et l'outil
SolidWorks Enterprise PDM sert leur gestion et leur validation. Les circuits de
validation sont dfinis au sein de ces outils et permettent une automatisation de
l'approbation des plans avec apposition du paraphe en automatique.
Le Tableau 1 rcapitule les points forts et faibles de ces outils.
Points forts
Gestion des versions
Accs la dernire version valide
Circuits de validation automatiss
Mtadonnes associes aux documents
Fonctions de recherche
Points faibles
Pas d'accs toute l'entreprise
Licence coteuse
Limitation aux documents de type plan
Pas de suivi des diffusions de
documents
Tableau 1 : Points forts et points faibles des outils utiliss pour la gestion et la production des plans
Pour complter ces deux outils et grer les autres types de documents, GTT utilise
l'Explorateur Windows.
II.2.2 Explorateur Windows
Chaque service dispose d'un espace ou plusieurs espaces sur le rseau et organise ses
documents selon ses propres plans de classement. Les accs sont rservs uniquement au
service et parfois des espaces dits "publics" permettent le partage de documents.
Pour complter ces espaces rseaux, un espace est ddi pour les documents diffusion
"officielle" en interne ou en externe. Cet espace est nomm "Archgtt". Ces documents sont
rfrencs dans un fichier Excel. Ce fichier contient la liste de l'ensemble des documents
associs quelques mtadonnes et l'identifiant du document. Les fichiers des documents
sont stocks sur le rseau dans le rpertoire portant l'identifiant du document. Les accs
sont restreints, seuls quelques documents sont accessibles toute l'entreprise.
Sabine Champenois
14/125
Les documents sont approuvs selon des circuits de validation propres chaque service ou
type de document. Les documents sont signs sur la version papier. Celle-ci est parfois
scanne puis enregistre sur le rseau. Dans tous les cas, la version papier signe originale
est conserve dans les diffrentes salles d'archives et gres par un archiviste.
Le Tableau 2 rcapitule les points forts et faibles de ce mode de gestion sous l'Explorateur
Windows.
Points forts
Permet un point d'accs centralis
Identification unique des documents
Points faibles
Accs restreints
Pas d'exhaustivit des documents
Pas d'assurance d'avoir la dernire
version approuve d'un document
Circuits de validation manuels
Pas de suivi des diffusions de
documents
Tableau 2 : Points forts et points faibles de l'Explorateur Windows pour grer les documents
Pour complter ce systme et permettre d'identifier un certain nombre d'autres documents,

un logiciel "maison" a t dvelopp.
II.2.3 Secrtariat
La prise d'identifiant d'un certain nombre de documents est ralise grce au logiciel
"Secrtariat", logiciel dvelopp en interne et accessible tous. Il permet de prendre des
numros de :
courriel, fax, courrier envoy ou reu,
commande,
demandes de calcul et d'essai,
note interne.
Le Tableau 3 rcapitule les points forts et faibles de cet outil.
Points forts
Identification unique
Suivi des diffusions externes des
courriels et commandes
Points faibles
Pas de lien vers le fichier du document
Pas de suivi des versions
Limitation quelques types de
documents
Suivi partiel des diffusions de
documents
Tableau 3 : Points forts et points faibles du logiciel Secrtariat
L'ensemble des outils disposition des utilisateurs ne permet pas une gestion suffisante de
la documentation produite. Les logiciels de GED du march permettent de rpondre ces
problmatiques.
Sabine Champenois
15/125
II.2.4 Fonctionnalits proposes par les logiciels de GED

Les logiciels de GED ou ECM en anglais (Electronic Content Management) permettent
d'acqurir, produire, grer, stocker, archiver et diffuser des documents et des informations
au format lectronique. Ce type d'outil peut s'intgrer avec d'autres outils du Systme
d'Information d'une organisation pour apporter des fonctions complmentaires.
Les fonctions de production des logiciels de GED couvrent l'acquisition des documents et
leur traitement. L'acquisition comprend la numrisation de documents papier grce
l'utilisation de scanners qui peuvent permettent une reconnaissance des documents par
lecture automatique (LAD) et une reconnaissance du texte (OCR). Un logiciel de GED
peut galement tre aliment par import de fichiers informatiques existants ou produire de
nouveaux documents lectroniques et ce, sous diffrents formats de fichiers. Le traitement
des documents permet d'en extraire ou de renseigner des informations ou mtadonnes et
de les indexer pour en faciliter l'accs, le classement, la recherche et la diffusion.
Les fonctions d'organisation permettent la gestion de l'ensemble des tapes du cycle de vie
d'un document et permettent de grer les accs en fonction des profils des utilisateurs et
des niveaux de confidentialit des documents.
Les fonctions de stockage et d'archivage permettent de respecter les obligations lgales
dans ce domaine mais aussi de capitaliser l'information au sein de l'organisation dans le
temps. Les outils et techniques mis en uvre doivent garantir l'authenticit, la prennit, la
confidentialit et l'inviolabilit des documents.
Les fonctions de diffusion permettent la distribution des documents selon diffrents canaux
(Intranet, Internet, application ddie, papier...) dans un objectif de partage de
l'information.
Les logiciels de GED s'inscrivent dans un ensemble plus vaste d'applications informatiques
et permettent ainsi d'enrichir le systme d'information d'une organisation. Ainsi un logiciel
de GED peut intgrer ou s'interfacer avec des applications :
de gestion de contenu (CMS : Content Management System ou WCM : Web Content

Management) qui permettent la conception et la mise jour dynamique de sites
Internet ou Intranet,
d'archivage lectronique (ERM : Electronic Record Management),
de gestion des connaissances (KM : Knowledge Management),
de gestion et l'archivage des courriels,
de gestion des processus ou workflow (BPM : Business Process Management) qui

permettent la mise en uvre de workflows dans un objectif de travail collaboratif.
Les logiciels de GED par les fonctionnalits qu'ils offrent peuvent permettre de rpondre
aux problmatiques de GTT. Il est donc apparu ncessaire la Direction de l'entreprise de
se doter d'un tel outil. J'ai donc t recrute en tant que chef de projet ddi cette tche et
en charge de dfinir les exigences ncessaires pour la gestion des documents.
Sabine Champenois
16/125
II.3
Exigences pour un systme de gestion lectronique de documents
Les outils et mthodes utiliss pour la gestion des documents posent de nombreux
problmes qui ont amen la Direction Gnrale acqurir un logiciel de GED. Hormis les
exigences fonctionnelles demandes par les utilisateurs, peu de contraintes non
fonctionnelles ou pour la gestion du projet ont t imposes.
II.3.1 Exigences fonctionnelles
Les exigences fonctionnelles souhaites pour le logiciel de GED ont t recueillies auprs
des utilisateurs et formalises dans un document Expression fonctionnelle du besoin. Ce
document dfinit le cadre d'utilisation du logiciel, les fonctions de cration de documents,
de gestion, de consultation, de diffusion et de conservation des documents ainsi que les
fonctions d'administration.
II.3.1.1 Cadre d'usage
Un document au sens GTT est un fichier papier ou informatique qui peut-tre au format
Word, Excel, Power Point mais peut aussi tre un courriel ou un plan. Cest un document
crit servant de preuve ou d'information. Il peut tre dfini comme toute information
textuelle au format lectronique associe un logiciel ou non ou au format papier.
Sabine Champenois
17/125
Le logiciel de GED doit permettre de faire vivre les documents selon le cycle de vie
prsent la Figure 2 qui montre l'ensemble des tats possibles dun document.
Nouveau document
Suppression
Modification
En rdaction
Refus
Mise en validation
En validation
Refus
Acceptation
Valid
Nouvelle rvision
Demande de visa
Visa
Mise en approbation
En approbation
Mise en approbation
Acceptation
Approuv
Archivage
Annulation
Remplacement
Annul
Archivage
Archiv
Archivage
T > X ans, Suppression
Remplac
Figure 2 : Cycle de vie d'un document
Sabine Champenois
18/125
Les tats du cycle de vie dun document sont prsents dans le Tableau 4.
Etat
Dbut
En rdaction
En validation
Valid
Visa
En
approbation
Approuv
Diffus
Remplac
Annul
Archiv
Fin
Commentaire
Dmarrage du cycle de vie
Transition
Nouveau
document
Le document a t cr, rvis ou a subi un refus dans le Destruction
cycle de validation. Il est en cours de rdaction ou de
Modification
modification.
Mise en validation
Le document a t mis en validation. Il est en cours de
Acceptation
relecture par un valideur.
Refus
Le document a t accept. Il est dans un tat fictif
Mise en
valid. Il peut passer l'tat suivant du cycle de
approbation
validation (En approbation ou Visa).
Demande de visa
Une demande de visa a t propose. Le document est en Mise en
cours de relecture par le ou les viseur(s). Ceux-ci peuvent approbation
mettre des commentaires.
Le document a t mis en approbation. Il est en cours de Acceptation
relecture par un approbateur.
Refus
Le document a t accept. Il devient approuv. Toutes
Diffusion
les signatures sont apposes sur le cartouche.
Le document est approuv. Son PDF est gnr, il est
Nouvelle rvision
diffus et la rvision approuve du document n'est plus
Remplacement
modifiable.
Annulation
Archivage
Le document est remplac par un autre.
Archivage
Le document est annul.
Archivage
Le document est approuv, remplac ou annul. Il est
Destruction
archiv et le document n'est plus ni modifiable, ni
rvisable.
Pour la premire rvision d'un document en cours de
Aucune
rdaction et qui n'a pas dbut le circuit de validation, le
document est dtruit.
Pour un document archiv, aprs un laps de temps dfini
ou sur dcision d'un utilisateur, le document est dtruit.
Dans le cas d'une premire rvision ou d'un document
archiv, le document est dfinitivement dtruit. Dans le
cas d'une rvision suprieure d'un document en cours de
rdaction, le document revient sa prcdente rvision
approuve.
Tableau 4 : tats du cycle de vie d'un document
Le systme doit permettre de grer les documents en fonction des diffrents tats du cycle
de vie.
Sabine Champenois
19/125
II.3.1.2 Fonctions de cration de documents

Le systme doit permettre de crer des documents par import du fichier dans le systme et
renseignement des mtadonnes. Certaines de ces mtadonnes peuvent tre rcupres du
fichier. Un identifiant unique doit tre attribu chaque document.
L'utilisateur doit pouvoir galement crer un document dans la GED partir d'un modle
s'ouvrant dans l'application correspondante.
Une fonctionnalit d'import doit permettre d'alimenter le systme avec les documents
existants.
II.3.1.3 Fonctions de gestion des documents
Le contenu d'un document peut tre modifi soit en exportant puis en rimportant son
fichier, soit en le modifiant directement dans l'application Microsoft Office
correspondante. La modification du fichier ou des mtadonnes d'un document ne doit tre
possible que par un seul utilisateur la fois.
Il doit tre possible de modifier ou complter les mtadonnes d'un document. Certaines
modifications doivent entraner la cration d'une nouvelle rvision lorsque le document est
approuv.
Il est important que le systme gre les liens entre documents. Les impacts entre
documents lis doivent tre signals lorsqu'une nouvelle rvision d'un document est cre.
Un document doit pouvoir tre annot toutes les tapes de son cycle de vie ; cela afin de
centraliser les diffrentes remarques et de suivre leur prise en compte.
Le cycle de vie des documents doit pouvoir tre paramtr et doit pouvoir dpendre du
type de document. Chaque phase doit permettre d'apposer la signature de l'utilisateur dans
le cartouche du document. Les actions dfinies dans le cycle de vie mais galement dans
les workflows doivent gnrer des alertes aux utilisateurs concerns, soit au travers de la
messagerie, soit l'aide d'une interface de l'application.
Diffrents rapports prexistants ou pouvant tre crs par l'utilisateur doivent lui permettre
de suivre la production et d'tablir des tableaux de bord.
II.3.1.4 Fonctions de consultation et de diffusion des documents
L'accs aux documents doit pouvoir se faire l'aide du plan de classement ou l'aide de
recherches sur les mtadonnes et le contenu.
Toutes les informations concernant un document doivent pouvoir tre consultes.
Un suivi des documents diffuss en interne ou livrs l'extrieur doit tre ralis.
L'utilisateur doit pouvoir dfinir les personnes destinataires de documents. Le systme doit
permettre aux utilisateurs de s'abonner des documents et de grer leur diffusion. La
diffusion externe peut tre prpare par le systme afin que l'utilisateur puisse gnrer le
transmital form (bon de livraison) et envoyer les documents au format PDF ou source par
courriel ou gravs sur un CD/DVD-Rom.
Sabine Champenois
20/125
II.3.1.5 Fonctions de conservation des documents

L'archivage des documents tant un sujet part entire, l'acquisition d'un module
d'archivage sera ralise dans le cadre d'un autre projet.
Toutefois, le systme doit pouvoir proposer un module d'archivage ou bien pouvoir
s'interfacer avec un outil du march
II.3.1.6 Fonctions d'administration
Les interfaces d'administration doivent permettre de grer les utilisateurs, leurs droits
d'accs et leur profil.
Les administrateurs doivent pouvoir paramtrer tous les lments volutifs du systme
(formulaires, workflows, valeurs des mtadonnes, plans de classement).
Ils doivent pouvoir avoir accs un certain nombre de rapports leur permettant d'intervenir
en cas de problmes.
Le systme doit permettre de raliser des sauvegardes et d'effectuer des restaurations. Les
changes d'information avec le systme de CAO pourront se faire l'aide de
dveloppements spcifiques indpendants du systme.
A cet ensemble d'exigences fonctionnelles, des exigences non fonctionnelles doivent tre
respectes.
II.3.2 Exigences non fonctionnelles
Les exigences non fonctionnelles doivent couvrir les aspects formation et conduite du
changement, fiabilit, disponibilit, architecture, administration et enfin, volutivit du
logiciel.
II.3.2.1 Formation et conduite du changement
L'ensemble des protagonistes doit tre form pour l'utilisation qu'ils auront faire de
l'application.
Les utilisateurs doivent tre forms l'utilisation de l'application et ce dans leur contexte
d'utilisation. Les administrateurs mtiers et techniques doivent galement tre forms afin
qu'ils puissent administrer l'application. Enfin, une quipe de dveloppeurs doit monter en
comptences afin que GTT puisse tre autonome dans la ralisation de paramtrages ou de
dveloppements.
Le logiciel doit tre livr avec la documentation correspondante : manuel utilisateur et/ou
aide en ligne, manuel d'installation, manuel d'administration, manuel de paramtrages et
manuel des API (Application Programming Interface).
II.3.2.2 Fiabilit et disponibilit
GTT produisant principalement des documents, le logiciel de GED est une application
centrale de l'entreprise qui sera utilise par tous les salaris (environ 200 personnes) mais
aussi les intrimaires et prestataires. L'application ne doit pas tre indisponible plus d'une
demi-journe.
Sabine Champenois
21/125
II.3.2.3 Exigences d'architecture et d'administration

Les exigences d'architecture concernent les serveurs, les postes utilisateurs et le rseau. Les
exigences d'administration concernent la prise en main du systme par les quipes de GTT.
L'application de GED doit pouvoir fonctionner dans lenvironnement utilisateur existant :
Import de documents du systme de CAO SolidWorks Enterprise et grs l'aide de

PDM SolidWorks Enterprise au format PDF. Ces changes seront raliss en mode
batch par exemple la nuit. Seuls les fichiers approuvs au format PDF seront changs
ainsi qu'un certain nombre de mtadonnes permettant l'indexation des documents.
Microsoft Exchange 2007.
Outlook 2007,
Active Directory. L'application doit permettre une connexion des utilisateurs avec les
mmes login et mot de passe utiliss pour leur connexion Windows et si possible leur
viter une nouvelle saisie chaque lancement de l'application.
Windows XP ou Windows 7.
Office XP ou 2007,
Internet Explorer 6 ou version suprieure,
Adobe Reader 9.
Le rseau interne de l'entreprise a un dbit de 100 MB 1 GB et entre les serveurs de

1 2 GB mais ne permet pas l'accs Internet.
La base de donnes et les fichiers des documents doivent pouvoir tre sauvegards grce
aux outils dj en place chez GTT. Les sauvegardes se font la nuit et le week-end car
aucun utilisateur n'est connect au systme. La sauvegarde de la base de donnes et des
fichiers doit pouvoir se faire au mme moment sans arrter ni la base, ni le serveur.
L'administration et l'exploitation du systme doivent pouvoir tre ralises par le
Dpartement SI.
La maintenance du systme doit tre simple. Des interfaces pour le paramtrage et
l'administration doivent aider au maximum l'administrateur technique.
Un contrat de maintenance corrective et volutive peut tre propos afin d'assurer la
correction des dysfonctionnements, l'acquisition des mises jour du systme et de la
documentation. Il peut intgrer le support aux utilisateurs, administrateurs et dveloppeurs.
Le ou les serveurs seront acquis spcifiquement pour le systme et rpondront donc aux
exigences de l'diteur. Le systme d'exploitation doit tre de prfrence Windows (Linux
n'est pas exclu) et pour la base de donnes Microsoft SQL Server mais d'autres SGBD
(Systme de Gestion de Base de Donnes) ne sont galement pas exclus. GTT souhaite
avoir un serveur et une base de test et un serveur de dveloppement.
Les fichiers des documents ne doivent pas tre stocks dans la base de donnes mais dans
un systme de fichiers. Les disques durs pour le stockage des documents doivent tre en
SAN (Storage Area Network) de prfrence car c'est l'quipement que possde GTT.
Sabine Champenois
22/125
II.3.2.4 Volumtrie
Les quantits de documents grer correspondent une estimation de :
68 000 en initialisation,
119 000 nouveaux documents (incluant les courriels) par an,
2 700 nouveaux documents par projet navire. GTT peut avoir entre 5 et 15 nouveaux
projets chaque anne,
700 nouveaux documents par projet de rservoir terrestre. Le nombre de projet annuel
n'est pas estimable ce jour,
1 200 nouveaux documents par projet de tuyau cryognique. Le nombre de projet

annuel n'est pas estimable ce jour.
II.3.2.5 volutivit
GTT souhaite avoir la possibilit de raliser ses propres paramtrages et de pouvoir faire
voluer les paramtrages existants sans en passer par l'diteur ou une socit de prestation.
Dans ce but, il est important que les dveloppements qu'ils pourraient tre ncessaires de
raliser puissent tre faits au travers d'une API et de prfrence en VB.Net (langage
matris par l'quipe de dveloppement).
GTT souhaite notamment pouvoir connecter le systme de GED une base de donnes
mtier qui doit permettre de renseigner les mtadonnes des documents.
Cette base de donnes mtier est actuellement en cours de conception. Elle contiendra
terme les mtadonnes de type donnes mtier. Il est envisag que les documents du
systme de GED puissent tre associs ces donnes mtier. Lors du renseignement ou de
la modification des mtadonnes d'un document, l'utilisateur pourra aller rechercher les
mtadonnes de type mtier directement dans la base de donnes mtier. Ainsi, les risques
de mauvais renseignements la saisie seront minors et une meilleure homognisation
des valeurs sera permise.
L'ensemble des exigences non fonctionnelles ncessaires la mise en place d'un logiciel de
GED doivent permettre tous une utilisation du systme en fonction des tches qu'ils
devront effectuer mais aussi d'installer une application en conformit avec l'architecture
matrielle et logicielle existante ; tout en assurant l'autonomie du Dpartement SI dans
l'administration et le paramtrage.
Sabine Champenois
23/125
II.3.3 Exigences du projet

Les exigences du projet couvrent les aspects cot, dlais et qualit.
II.3.3.1 Cot
La Direction Gnrale n'a pas souhait dfinir de critres de cot, l'objectif tant de trouver
le produit rpondant au mieux aux exigences des utilisateurs. Cependant, aprs une
premire tude des produits du march, une fourchette de dpenses a t tablie (de
200 000 400 000 ) pour l'acquisition des licences, la maintenance et les prestations
ncessaires la mise en place (installation, paramtrages et formation).
II.3.3.2 Dlai
De mme que pour les cots, la Direction Gnrale n'a pas souhait tablir de dlais, mais
il est vident que l'entreprise ne peut plus continuer avec ses outils actuels et qu'une mise
en place le plus rapidement possible est ncessaire.
Le projet a dbut en janvier 2009 pour s'achever en dcembre 2010 avec la mise en
production du logiciel.
II.3.3.3 Qualit
Le PMBOK assigne au processus de management de la qualit de dfinir les exigences
qualit et les normes, standards et mthodes pour le projet et le produit et la manire dont
la conformit ces exigences sera contrle
GTT possde ni standard, ni de mthode impose pour la gestion de projet. La mthode du
Project Management Institute (PMI) [1], le PMBOK guide, tudi au CNAM a t choisie.
Puis, pour s'assurer que chaque tape du projet se droule dans les meilleures conditions
afin d'obtenir des livrables en conformit avec les exigences, la norme ISO/CEI 12207 [2]
pour l'ensemble du projet a servi de rfrence. Pour la phase d'acquisition, la norme
NF X50-151 [3] a servi de cadre pour l'tablissement de l'expression fonctionnelle du
besoin et du cahier des charges.
Enfin, le CMMI (Capacity Maturity Model Integration) sera utilis comme outil
damlioration des activits du projet qui vont tre mises en uvre.
Conformment aux recommandations du PMBOK un plan de management du projet a t
tabli en dbut du projet et a dfini son organisation.
Sabine Champenois
24/125
Le chef de projet GED (moi-mme), assistant la matrise d'ouvrage (AMO), a pour rle :
de grer le projet en termes d'organisation, de planification, de cots et de qualit,
de rapporter de l'avancement du projet au Comit de Pilotage (COPIL),
d'animer le Comit des Utilisateurs (COUTIL),
de rdiger le cahier des charges,
de renseigner et de proposer des solutions au reprsentant de la Direction,
de participer la phase de recherche et d'valuation de solutions,
danimer sous lautorit du reprsentant de la Direction, la phase de mise en place,
de distribuer la responsabilit des livrables que ce soit en interne GTT ou des

fournisseurs.
Le reprsentant de la Direction ainsi que les quatre directeurs constituent le Comit de

Pilotage du projet et ont pour rle :
de suivre l'avancement du projet,
de dcider les actions suite aux ventuels problmes rencontrs dans le droulement du
projet,
de dcider de la composition du COUTIL,
de suivre le travail du COUTIL,
de prendre la dcision du choix de la solution,
de conduire le changement.
Le Comit des Utilisateurs est dirig par le chef de projet GED. Ces personnes reprsentent
les futurs utilisateurs du systme dans les diffrents Dpartements. Son rle est :
de dfinir les besoins,
de donner son avis dans le choix de la solution,
d'avoir un rle de consultation et de proposition vis--vis du COPIL par le truchement

du Chef de Projet,
d'tre un relais au sein de leur Dpartement pour la collecte de tous les lments
ncessaires et la diffusion des informations concernant le projet,
de participer la phase de mise en place.
Les activits de GTT en tant que socit d'ingnierie produisent principalement des
documents. Cela ncessite de les grer de manire en faciliter l'accs pour l'ensemble de
l'entreprise tout en s'assurant de l'utilisation de la dernire version approuve. De plus,
beaucoup de documents sont des livrables clients, il faut donc pouvoir suivre les versions
diffuses. Les exigences fonctionnelles dfinissent l'ensemble des fonctionnalits attendues
par les utilisateurs du logiciel de GED. De plus, des exigences non fonctionnelles et de
gestion de projet sont tablies. Le systme mis en place rpond l'ensemble de ces
exigences.
Sabine Champenois
25/125
III Mise en place du logiciel Cincom ECM

La mise en place du logiciel de GED slectionn, Cincom ECM, s'appuie sur les processus
de production et de gestion des divers documents raliss GTT ainsi que sur la procdure
de matrise documentaire du Systme de Management de la Qualit. Ces processus sont
traduits en fonctionnalits et en workflows au sein de l'application. Les architectures
applicative et technique misent en place pour le fonctionnement de ce logiciel sont dcrites
en fin de partie.
III.1 Cycle de vie dun document paramtr

Le logiciel acquis par GTT, Cincom ECM, est paramtr afin qu'il fonctionne selon le
cadre d'usage dfini (voir II.3.1.1). Il est dcrit tel que paramtr dans la Figure 3.
Cration
Modification
En rdaction
Refus
Mise en approbation complexe

En validation
Refus
Mise en visa automatique si viseurs

Rvision
En visa
Acceptation
En approbation
Approbation directe
Acceptation ou dure dpasse
Acceptation
Approuv
Annulation
Remplacement
Archivage
Remplac
Archivage
Annul
Archiv
Archivage
Figure 3 : Cycle de vie d'un document tel que paramtr dans Cincom ECM
Cette figure dcrit les diffrents tats dans lequel peut se trouver un document dans
Cincom ECM et les diffrentes transitions possibles pour passer d'un tat un autre.
Sabine Champenois
26/125
Un utilisateur cre un document l'aide des fonctions de cration (voir III.2.1.2) et le

modifie (voir III.2.1.3) jusqu' ce qu'il dcide de l'approuver pour pouvoir le diffuser.
Deux choix lui sont offerts :
il approuve lui-mme son document et alors il lance un workflow d'approbation directe

(voir III.2.2.2),
il a besoin de divers avis et alors il lance un workflow d'approbation complexe (voir

III.2.2.1).
Dans le cas d'une approbation complexe, il dfinit les acteurs participants au workflow : le
valideur, des ventuels viseurs et l'approbateur, et il dfinit galement la dure impartie
pour chaque tape du workflow. Ainsi, le valideur reoit une tche et il peut accepter ou
refuser le document. Si le document est accept et que des viseurs ont t dfinis, ces
derniers reoivent une tche tous au mme moment. Lorsqu'ils acceptent tous le document
ou lorsque la dure dfinie est dpasse, le document passe l'tat "En approbation". Si
aucun viseur n'a t dfini, le document passe galement l'tat "En approbation".
L'approbateur reoit une tche et il peut accepter ou refuser le document. Si le document
est accept, il passe l'tat "Approuv". Si le document est refus par le valideur ou
l'approbateur, il revient l'tat "En rdaction" et son auteur doit le modifier.
Un document l'tat "Approuv" via l'un des deux workflows disponibles dans
l'application est dans un format diffusable (voir III.2.1.4), il est accessible aux utilisateurs
en ayant les droits (voir III.2.1.6) et il peut tre livr (voir III.2.2.6). Toute modification
d'un document l'tat "Approuv" passe par une nouvelle rvision. Il peut galement tre
annul (voir III.2.2.3) ou remplac (voir III.2.2.4) par un autre document.
Un document l'tat "Approuv", "Annul" ou "Remplac" peut tre archiv (voir
III.2.2.5). Il n'est alors plus modifiable et ne peut plus changer d'tat.
Le cycle de vie d'un document paramtr dans Cincom ECM permet d'obtenir un certain
nombre de fonctionnalits de gestion documentaire et de workflows.
III.2 Fonctionnalits et workflows mis en place

Le logiciel de GED tant une application destine l'ensemble de l'entreprise et couvrant
l'ensemble des documents produits, l'objectif initial a t de limiter les paramtrages,
d'aller au plus simple et de couvrir le plus grand nombre de documents. En effet, la mise en
place d'une telle application entrane de nombreux changements en termes d'organisation et
de mthodes de travail. En limiter le primtre permet, dans un premier temps de faciliter
le changement et le dploiement, mais aussi de vrifier que les fonctionnalits rpondent
bien aux besoins des utilisateurs. GTT ayant prvu la formation de dveloppeurs afin de
pouvoir raliser de nouveaux paramtrages, il sera facile dans un deuxime temps
d'amliorer l'existant et de faire voluer l'application.
Cette partie prsente les fonctionnalits mises en place et les workflows paramtrs dans le
logiciel Cincom ECM.
Sabine Champenois
27/125
III.2.1 Fonctionnalits implantes

Les fonctions implantes couvrent l'organisation des documents, leur cration, leur
modification, leur diffusion et leur consultation.
III.2.1.1 Organisation des documents
L'organisation des documents consiste en la dfinition des plans de classements. Ceux-ci
sont reprsents dans l'application sous forme d'arborescence. Pour chaque branche du plan
de classement on doit dfinir les droits de consultation et de modification associs.
Avant la mise en service du logiciel, les plans de classement taient propres chaque
Dpartement avec des accs restreints l'quipe. L'objectif tant d'amliorer les accs
l'information, il a t choisi de classer les documents en s'appuyant sur les processus de
l'entreprise. On obtient les espaces suivants :
un espace commun contenant les documents accessibles tous prsent la Figure 4,
Figure 4 : Plan de classement de l'espace Commun
Sabine Champenois
28/125
un espace projets Innover contenant les documents des projets du processus Innover
prsent la Figure 5,
Figure 5 : Plan de classement type d'un projet Innover
un espace projets Vendre contenant les documents des projets du processus Vendre,
un espace projets Produire contenant les documents des projets du processus Produire
prsent la Figure 6,
Figure 6 : Plan de classement type d'un projet Produire
Sabine Champenois
29/125
des espaces mtiers contenant pour chaque mtier de l'entreprise les documents
n'entrant pas dans le cadre des projets. Le plan de classement type est prsent la
Figure 7.
Figure 7 : Plan de classement type d'un mtier
Pour chaque projet et chaque espace mtier, des arborescences types sont dfinies afin
d'avoir une cohrence dans l'organisation des documents. Ainsi chaque nouveau projet,
cette arborescence type est duplique.
Pour chaque branche du plan de classement sont dfinis les droits de consultation et de
modification. Ces droits sont tablis par rapport aux utilisateurs et groupes d'utilisateurs
contenus dans l'annuaire LDAP (Lightweight Directory Access Protocol) de l'entreprise.
La dfinition des plans de classement et des droits associs est ralise par les
administrateurs du logiciel comme on peut le voir la Figure 8.
Figure 8 : Exemple de droits sur une branche
III.2.1.2 Cration de documents

Un document dans l'application correspond un fichier principal, des fichiers annexes et
un ensemble de mtadonnes. Ces mtadonnes ont t dtermines dans l'expression
fonctionnelle de besoin et paramtres dans l'application. Pour chaque mtadonne, son
format, son ventuelle liste de valeurs et son caractre obligatoire ou non ont t tablis.
Sabine Champenois
30/125
La Figure 9 prsente l'ensemble des mtadonnes qu'il est possible de renseigner pour un
document.
Figure 9 : Mtadonnes renseigner pour crer un document
Sabine Champenois
31/125
La cration de documents partir de modles a galement t paramtre afin

d'homogniser la prsentation des documents produits au sein de l'entreprise. Pour cela,
deux modles au format Microsoft Word ont t tablis : projet et simple. Le modle de
document projet est utilis dans le cadre des projets clients. Le modle simple est utilis
dans les autres cas. De plus, ces modles possdent des variables afin de rcuprer des
informations contenues dans le fichier dans le but d'alimenter des mtadonnes du logiciel
de GED. Ces variables sont galement insres dans le contenu du document afin d'en
faciliter la composition. Le renseignement de variables dans Microsoft Word n'est pas
une fonction utilise ou connue de la majorit des utilisateurs. Pour les assister, une macro
a t cre par un dveloppeur du Dpartement Systme d'Information. La Figure 10
prsente la fentre d'assistance pour le modle de document projet. Les choix pouvant tre
faits se basent sur les donnes prsentes dans la base de donnes du logiciel de GED.
Figure 10 : Fentre de l'assistant pour le modle de document projet
L'utilisateur au sein de la fentre de l'assistant renseigne un certain nombre d'informations.

A la validation, ces informations sont insres au sein du document et sont intgres dans
les variables de Word.
Sabine Champenois
32/125
La Figure 11 prsente un document de type projet rempli l'aide de l'assistant.
Figure 11 : Page de garde d'un document projet renseign l'aide de l'assistant
Sabine Champenois
33/125
La cration de document se fait selon deux modes :
le fichier du document existe et on l'importe dans l'application puis on renseigne ses

mtadonnes,
le document n'existe pas, on le cre partir d'un modle puis on complte ses
mtadonnes.
Dans le premier cas, l'utilisateur lance la fonction de cration d'un document. Il fournit le
fichier et renseigne les mtadonnes. A la validation, le fichier du document est import
dans le systme et le document est cr.
Dans le deuxime cas, l'utilisateur lance la fonction de cration d'un document partir d'un
modle. Il slectionne le modle. Le modle s'ouvre dans l'application correspondante. Il
rdige son document puis le sauvegarde. Le document est cr dans la GED.
Dans ces deux modes, si le fichier du document cr est bas sur un des modles GTT, les
variables sont rcupres et alimentent les mtadonnes.
Lors de la cration d'un document, l'utilisateur peut choisir, s'il le souhaite, de gnrer
l'identifiant du document. En effet, chaque document doit avoir un identifiant unique dans
le systme. Dans le cas o il ne souhaite pas gnrer cet identifiant, il renseigne
l'identifiant existant provenant des anciens modes de codification de l'entreprise. Dans le
cas o il choisit de gnrer l'identifiant, un code unique est gnr se basant sur les
mtadonnes qu'il a renseignes. Cet identifiant est compos comme suit : code sujet du
document, code type de document et numro d'ordre et prsent en Figure 12.
Figure 12 : Identifiant de document gnr en automatique
Sabine Champenois
34/125
III.2.1.3 Modification de documents

Lors de la phase de rdaction, l'auteur d'un document peut en modifier le fichier et les
mtadonnes.
Pour les fichiers au format Microsoft Office, ils peuvent tre directement modifis de la
GED en l'ouvrant dans l'application correspondante. La sauvegarde enregistre les
modifications directement dans Cincom ECM.
Pour les autres formats de fichiers, ils doivent tre exports par l'utilisateur sur leur poste
de travail. Aprs modification, ils doivent tre rimports. Cette fonction permet de
modifier tout format de fichier mais galement d'exporter des documents pour travailler
hors connexion du rseau de l'entreprise.
Toutes les mtadonnes peuvent tre modifies hormis celles servant la gnration de
l'identifiant et l'identifiant lui-mme ainsi que toutes les informations systme sur l'auteur,
la date de cration, les dates de modifications
L'utilisateur peut associer des fichiers annexes au document comme prsent en Figure 13.
Ces fichiers ne sont pas versionns, ni approuvs. Cela permet, par exemple, d'associer au
document les schmas ou les images intgres ou les fichiers de sortie des machines
d'essais servant de base la rdaction du rapport.
Figure 13 : Fichiers annexes dans les mtadonnes
L'utilisateur peut galement crer des liens entre documents. Le lien apparat dans les
mtadonnes du document source et cible comme prsent en Figure 14. Cette fonction
permet de connatre les impacts, lors de la modification d'un document. Par exemple, pour
une norme ayant servi de base la rdaction d'une procdure, on aura un lien entre les
deux documents. Les types de liens suivants sont disponibles :
rfrence,
sert de base ,
est conforme ,
justifie.
Figure 14 : Lien entre documents dans les mtadonnes
Sabine Champenois
35/125
Lors des phases de modifications, le document est verrouill afin d'viter que plusieurs
utilisateurs effectuent des modifications simultanment.
L'utilisateur a galement la possibilit de crer des versions mineures afin de conserver la
trace des modifications apportes.
Tous les utilisateurs peuvent ajouter des annotations sur un document mme s'ils n'ont pas
les droits de modifications. Cela doit permettre d'amliorer la collaboration.
III.2.1.4 Diffusion de documents
Il est indispensable que les utilisateurs consultent la dernire version approuve de chaque
document.
Dans ce but, une notion de document de travail et de document de diffusion a t
paramtre. Les documents au format source et ventuellement en cours de modifications
sont des documents de travail et les documents approuvs au format PDF sont des
documents de diffusion.
Les utilisateurs ayant les droits de consultation ne peuvent voir que les documents
diffusion dans leur dernire version, ainsi aucun risque qu'ils utilisent une mauvaise
version.
Les utilisateurs ayant les droits de modification voient les documents de travail et de
diffusion tel que prsent en Figure 15. Ils peuvent ainsi prparer la version suivante tout
en assurant la diffusion de la version approuve.
Figure 15 : Documents de travail et de diffusion
III.2.1.5 Cas des courriels

Les courriels peuvent tre intgrs dans le logiciel de GED au mme titre qu'un autre
document. Un courriel possde les mmes mtadonnes qu'un autre document avec en plus
des informations sur l'expditeur, le destinataire et la date d'envoi. Le fichier du courriel est
au format "msg". Les pices jointes peuvent tre intgres comme des documents part
entire ou comme des fichiers annexes.
Sabine Champenois
36/125
La Figure 16 prsente l'ensemble des mtadonnes qu'il est possible de renseigner pour un
courriel.
Figure 16 : Mtadonnes propres un courriel
Pour ajouter un courriel dans le systme, l'utilisateur le slectionne dans son logiciel de
messagerie Microsoft Outlook. Une fonction spcifique lui permet de lancer
l'importation du courriel dans le logiciel de GED. Il peut slectionner les pices jointes
qu'il souhaite importer galement en tant que fichiers annexes. Le courriel est import dans
le systme dans l'espace personnel de l'utilisateur. Celui-ci peut complter les mtadonnes
mais il ne peut modifier les mtadonnes provenant du courriel. Puis il dplace le courriel
dans le plan de classement. Le courriel est alors consultable par tous les utilisateurs en
ayant les droits et n'est plus modifiable.
Sabine Champenois
37/125
III.2.1.6 Accs aux documents

L'accs aux documents se fait selon plusieurs modes : l'arborescence, la recherche et
l'abonnement. Les accs vont dpendre des droits dfinis : les utilisateurs ne pourront
consulter uniquement les documents pour lesquels ils ont les droits.
L'arborescence permet de naviguer dans le plan de classement et de consulter les
documents selon l'organisation dfinie (voir III.2.1.1).
Deux modes de recherche sont proposs l'utilisateur : simple et avance. La recherche
simple permet de rechercher un mot ou un groupe de mots sur l'ensemble des documents
du systme. La recherche se fait sur les mtadonnes et le contenu des documents. La
recherche avance permet de combiner une recherche sur des valeurs de mtadonnes, de
rechercher sur des mots contenus dans le document et de choisir une branche particulire
du plan de classement. Cette recherche permet de mieux cibler les rsultats.
Dans le cas d'une recherche simple, les rsultats seront affichs par pertinence et les mots
recherchs mis en surbrillance tel que dans la Figure 17.
Figure 17 : Rsultats d'une recherche simple
Les utilisateurs ont la possibilit d'enregistrer une recherche afin de pouvoir la relancer
tout moment.
Afin de connatre les nouveaux documents produits et diffuss, les utilisateurs peuvent
s'abonner aux rsultats d'une recherche ou sur des branches du plan de classement. Chaque
jour, ils reoivent un courriel rcapitulant les crations ou modifications de documents
avec un lien vers le document.
La consultation d'un document permet l'utilisateur de visualiser l'ensemble des
mtadonnes mais aussi de prvisualiser le document dans l'application au format PDF. En
effet, certains formats de documents produits GTT utilisent des logiciels que peu de
personnes possdent, cela permet tous de pouvoir en consulter le contenu sans possder
la licence du logiciel utilis.
Pour complter ces fonctionnalits provenant d'un usage standard de l'application ou ayant
t paramtres, des workflows ont t mis en place pour l'approbation et la livraison des
documents.
Sabine Champenois
38/125
III.2.2 Workflows mis en place

Un workflow est un ensemble d'actions ralises sur un document par un ensemble de
personnes et contrles par le logiciel de GED.
Les workflows mis en place permettent de suivre le cycle de vie d'un document. Ce cycle
de vie est paramtr en plusieurs workflows : approbation complexe, approbation directe,
annulation, remplacement et archivage d'un document (voir III.1).
La gestion des livraisons de documents est ralise au travers du workflow des transmital
forms (TF).
III.2.2.1 Approbation complexe
L'approbation complexe d'un document doit permettre un auteur de faire approuver son
document en suivant des tapes de validation, de visa et d'approbation conformment au
cycle de vie d'un document (voir III.1). Ce workflow est mis en uvre pour tous les
documents qui doivent tre livrs des clients.
L'auteur d'un document, une fois son document achev dfinit les acteurs du workflow : le
valideur, les ventuels viseurs et l'approbateur. Pour chaque tape, il indique le dlai de
ralisation. Puis, il lance le workflow.
Le valideur reoit une tche tel que prsent en Figure 18. Il peut valider ou refuser le
document. Dans le cas d'un refus, il doit le commenter et le document revient l'tat
"En rdaction" son auteur.
Figure 18 : Tche de validation
Une fois la validation obtenue, si des viseurs ont t dfinis, ils sont aviss simultanment
par une tche. Ils peuvent ajouter des commentaires puis valider le document. Une fois,
tous les visas obtenus ou le dlai imparti dpass, le document passe en approbation.
L'approbateur reoit une tche. Il peut consulter les commentaires faits sur le document. Il
peut approuver ou refuser le document. Dans le cas d'un refus, il doit le commenter et le
document revient l'tat "En rdaction" son auteur. Si le document est approuv, le
document passe l'tat "Approuv", le fichier PDF est gnr, les signatures des acteurs
sont apposes dans le cartouche et sa version de diffusion est cre. Le document n'est
alors plus modifiable sans dclencher une nouvelle rvision.
Sabine Champenois
39/125
La Figure 19 prsente la page de garde d'un document projet avec son cartouche sign.
Figure 19 : Cartouche avec signatures
Sabine Champenois
40/125
Dans ce workflow, rception d'une tche, avant l'chance des dlais ou en cas de
dpassement, les acteurs reoivent des rappels par courriels. A l'approbation du document,
son auteur en est inform par courriel.
III.2.2.2 Approbation directe
L'approbation directe d'un document doit permettre un auteur d'approuver lui-mme son
document afin de le diffuser. Ce workflow est mis en uvre pour les documents internes
qui ne ncessitent pas d'tre revus.
L'auteur d'un document, une fois son document achev lance le workflow. Le document
passe l'tat "Approuv", le fichier PDF est gnr, la signature de l'auteur est appose
dans le cartouche et sa version de diffusion est cre. Le document n'est alors plus
modifiable sans dclencher une nouvelle rvision.
III.2.2.3 Annulation
L'annulation d'un document permet de passer un document de l'tat "Approuv" l'tat
"Annul". L'annulation permet d'indiquer les documents qui sont devenus obsoltes.
L'auteur d'un document dclenche la fonction d'annulation. Le document passe l'tat
"Annul", il n'est alors plus modifiable, ni rvisable.
III.2.2.4 Remplacement
Le remplacement d'un document permet de remplacer un document obsolte par un
nouveau.
L'auteur d'un document marque le document qui va tre le remplaant. Il se place sur le
document remplacer et lance la fonction de remplacement. Le document remplac passe
l'tat "Remplac", il n'est alors plus modifiable, ni rvisable. Un lien de type "Remplace"
est cr entre les deux documents et consultable dans les mtadonnes tel que prsent la
Figure 20.
Figure 20 : Lien de type "Est remplac par" dans un document obsolte
III.2.2.5 Archivage
L'archivage d'un document se fait sur un document l'tat "Approuv", "Annul" ou
"Remplac".
L'auteur d'un document dclenche la fonction d'archivage. Le document passe l'tat
"Archiv", il n'est alors plus modifiable, ni rvisable. Il est conserv dans la GED au titre
de la conservation historique en attendant la mise en place d'un module d'archivage.
Sabine Champenois
41/125
III.2.2.6 Livraison de documents

L'ensemble des fonctions de livraisons de documents permet de prparer le bon de
livraison ou transmital form (TF) et d'indiquer pour chaque document qu'ils ont t livrs.
Pour prparer une livraison, l'utilisateur marque les documents livrer. Le systme
contrle que les documents sont l'tat Approuv et que la diffusion externe est autorise.
A partir de ces documents marqus, l'utilisateur cre le document de type TF et renseigne
les mtadonnes et plus particulirement celles concernant les livraisons (expditeur,
destinataires, date de livraison). Les liens de type "Livrable" sont crs entre le
document et les documents marqus.
L'utilisateur demande la gnration du fichier Microsoft Excel du TF. L'application gnre
automatiquement le fichier qui reprend une partie des mtadonnes et la liste des
documents livrer tel que prsent la Figure 21.
Figure 21 : Extrait du contenu d'un TF
Lorsqu'il a termin la prparation du TF, l'utilisateur l'envoie dans un circuit d'approbation

complexe (voir III.2.2.1). Le valideur et l'approbateur contrlent la compltude de la
livraison et approuve le TF. Celui-ci est sign et sa version de diffusion est cre.
L'utilisateur lance, enfin, la fonction de livraison. Elle lui permet d'obtenir un fichier
compress contenant le TF et l'ensemble des documents livrer au format PDF. Pour
chaque document de la livraison un commentaire est ajout ses mtadonnes afin
d'indiquer la version du document livre avec la date et un renvoi au TF. Ainsi, pour
chaque version de document, il est possible de connatre les destinataires des livraisons.
L'ensemble de ces fonctionnalits et workflows mis en place s'appuient sur l'architecture
applicative du logiciel de GED.
Sabine Champenois
42/125
III.3 Architecture applicative

L'architecture applicative mise en place pour le logiciel de GED est une architecture 3-tiers
qui est prsente dans la Figure 22.
Serveurs
Postes client
Annuaire LDAP
Serveurs dapplication
et Web
JBoss et Cincom ECM
SGBD
Systme
de fichiers
SQL Server
Figure 22 : Architecture applicative
Les postes clients disposent du pack Microsoft Office et Microsoft Internet Explorer avec
lequel ils se connectent l'application.
L'application se compose du serveur d'application et Web JBoss Application Server et de
serveur de contenu du systme de GED : Cincom ECM.
Grce au SSO (Single Sign-On), l'utilisateur est reconnu et peut se connecter l'application
sans saisir son login et mot de passe de connexion. Cela est permis par l'annuaire LDAP de
l'entreprise qui regroupe l'ensemble des utilisateurs du systme d'information ainsi que
leurs donnes de connexion (login, mot de passe et profil d'accs) et permet leur
authentification lors des accs aux donnes ou aux applications de l'entreprise.
JBoss Application Server est un serveur d'application Open Source, crit en Java et il peut
donc fonctionner sur tout type de systme d'exploitation. Il embarque en son sein, le
serveur Web Apache Tomcat qui permet de grer les changes entre les navigateurs des
postes client et le serveur d'application.
Cincom ECM est construit sur des technologies Open Source de gestion de contenu et de
workflow. Il fournit l'ensemble des fonctionnalits de gestion de documents.
Les donnes sont stockes dans une base de donnes Microsoft SQL Server et les fichiers
des documents sont stocks dans un systme de fichiers.
Sabine Champenois
43/125
Cincom ECM embarque un moteur de recherche Open Source, Apache Lucene, qui permet
l'indexation et la recherche des documents. Pour cela, il indexe les mtadonnes et le
contenu des fichiers des documents. Lors d'une recherche effectue par un utilisateur, le
systme utilise les fichier d'index. Cela permet d'augmenter considrablement la vitesse
d'affichage des rsultats. Ainsi, lorsqu'un utilisateur recherche un document sur la base de
divers critres, sa requte est envoye par le navigateur du poste client au serveur Web
Apache Tomcat. Celui-ci transmet les informations au serveur application JBoss qui fait le
lien avec Cincom ECM. Le serveur de contenu envoie sa requte Lucene qui grce ces
index retrouvent les documents correspondants la recherche. Puis Cincom ECM retrouve
ces documents dans la base de donnes et rcupre l'adresse des fichiers et les
mtadonnes. Il trouve ainsi les documents dans le systme de fichier. Il envoie en retour
l'ensemble des informations (mtadonnes et fichiers des documents) aux diffrents
serveurs pour finalement afficher dans le navigateur de l'utilisateur le rsultat de sa
recherche.
Cincom ECM embarque galement le moteur de workflow jBPM. Ce moteur permet de
dfinir des workflows graphiquement en termes d'tapes, de transitions, d'acteurs, de
dlais Les workflows sont lancs par les utilisateurs en fonction des actions qu'ils
ralisent sur un document. Le moteur de workflow interprte les rgles dfinies et envoie
des tches aux utilisateurs via l'application et l'envoi de courriel. L'ensemble de ces
fonctionnalits permet de travailler sur les documents de manire collaborative.
Le systme de sauvegarde de GTT effectue les sauvegardes de la base de donnes et du
systme de fichiers conformment aux procdures existantes : toutes les nuits une
sauvegarde incrmentale des fichiers ajouts ou modifis et tous les week-ends une
sauvegarde complte sont raliss.
Cette architecture applicative a t mise en place conformment aux exigences de l'diteur.
Elle repose sur une architecture technique utilisant la virtualisation.
Sabine Champenois
44/125
III.4 Architecture technique

L'ensemble des ordinateurs et des serveurs fonctionnent sous Windows.
L'architecture technique mise en place est base sur l'utilisation de machines virtuelles
grce loutil de virtualisation VMware. Elle permet d'assurer une trs bonne disponibilit
de l'application de GED grce la redondance des serveurs et une optimisation des
ressources machines. Elle est prsente dans la Figure 23.
Baie de disques
Switch
Switch
Serveur physique 1
Poste de
supervision
Serveurs
application
et Web
SGBD
Switch virtuel
Serveur
physique 2
Serveur
physique 3
LAN
Postes client
Figure 23 : Architecture technique
Les trois serveurs physiques forment un cluster c'est--dire un regroupement de serveurs en

rseau permettant d'augmenter la disponibilit, la monte en charge, la rpartition de la
charge et facilite la gestion des ressources. Ces serveurs physiques ont diverses
applications de l'entreprise installes en plus du systme de GED et fonctionnent tous les
trois en permanence.
Ce cluster est vu comme un serveur unique par le rseau. Sur chacun, un systme
d'exploitation de virtualisation est install : VMware Server ESXi. Le systme
d'exploitation de virtualisation gre le partitionnement du serveur physique en plusieurs
machines virtuelles partageant le processeur, la mmoire, le stockage et les ressources
rseau. Ainsi, il alloue les diffrentes ressources physiques de la machine aux serveurs
virtuels en fonction de leur besoin.
L'ensemble des machines virtuelles est supervis par l'hyperviseur VMWare vSphere
Hypervisor (ESXi) install sur un poste standard sous Windows XP. Cette application
centralise la gestion des machines virtuelles en permettant la migration chaud des
machines, lquilibrage automatique de la charge, la continuit dactivit et la gestion de
lalimentation, tout en fournissant des fonctions de sauvegarde et de restauration pour les
machines.
TM
Sabine Champenois
45/125
Le premier serveur physique implante la GED en deux machines virtuelles. La premire

fait fonctionner les serveurs d'application et Web et le serveur de contenu (JBoss
Application Server et Cincom ECM) ; la seconde fait fonctionner la base de donnes
Microsoft SQL Server. Ces deux machines virtuelles changent via la mmoire du
serveur ce qui amliore les performances. Un switch virtuel, gr par le systme
d'exploitation de virtualisation, se charge de ces changes entre les deux machines et entre
les machines et le rseau.
Les fichiers du serveur de contenu et de la base sont implants dans une baie de disques de
type SAN. Elle se charge de la rpartition des donnes sur plusieurs disques afin
d'amliorer la tolrance aux pannes et la performance. L'espace disque n'est pas ainsi limit
par l'espace de stockage des disques durs du serveur.
Les donnes sont stockes en RAID 5 (Redundant Array of Independent Disks) sur les
disques. Les donnes sont rparties sur les diffrents disques et chaque disque prsente un
bloc de parit qui permet de rcuprer les donnes partir dun fragment de donnes et
dun code de contrle. Le systme en RAID 5 permet d'amliorer les temps d'accs aux
donnes et d'assurer leur intgrit en cas de perte d'un disque.
Les fichiers sur le SAN sont vus comme des fichiers locaux aux serveurs physiques. La
baie de disques est relie aux serveurs physiques par des fibres optiques via des switchs.
Ces quipements permettent l'interconnexion des lments du rseau. Ce mode de liaison
permet la redondance en cas de panne d'un des switchs ou d'un des connecteurs la baie.
Si le premier serveur physique tombe en panne, l'hyperviseur va commander au deuxime
serveur de prendre le relais et va chercher l'image sur la baie de disques. Le systme
d'exploitation de virtualisation gre l'ordonnancement des tches et dmarre d'abord la base
de donnes puis le serveur d'application et web, JBoss Application Server, et le serveur de
contenu, Cincom ECM. L'ensemble est ainsi redmarr en trs peu de temps et de manire
quasi transparente pour les utilisateurs. Cette architecture permet de palier les pannes
matrielles, par contre elle ne permet pas de palier les pannes logicielles. Des alertes par
courriels sont envoyes aux administrateurs afin de les informer de toute anomalie du
serveur. Ils peuvent ainsi ragir rapidement en cas de problmes logiciels.
Cette architecture technique a t mise en place par le responsable Exploitation du
Dpartement SI. GTT avait fait le choix de la virtualisation sur un prcdent projet afin
d'amliorer la reprise sur incident et ainsi augmenter le taux de disponibilit de
l'application mais aussi pour optimiser l'utilisation de ses serveurs et de leurs ressources.
Aujourd'hui, toute nouvelle application est installe selon cette architecture de serveurs en
clusters utilisant des machines virtuelles adaptes aux besoins.
La mise en place de l'application de GED au sein de GTT a ncessit de mettre en uvre
les fonctionnalits et les workflows tablis dans les spcifications fonctionnelles. Le
logiciel s'appuie sur une architecture applicative de type 3-tiers et sur une infrastructure
technique base sur un cluster de serveurs et des machines virtuelles. La mise en place
d'une telle application n'a pu se faire que grce une conduite de projet s'appuyant sur
diverses normes et mthodes.
Sabine Champenois
46/125
IV Conduite du projet
Au sein de GTT, ce projet se situe dans un contexte dans lequel le logiciel acqurir nest
quun outil informatique or jusqu ce jour les logiciels taient choisis pour des besoins
spcifiques mtier. Le projet d'acquisition et de mise en place d'une GED est le premier
logiciel utilisation transverse. De faon crer une base de connaissance sur le sujet de la
conduite de projet, jai choisi en accord avec ma hirarchie de raliser ce projet selon des
normes et mthodes l'tat de l'art en me rfrant mon cursus au CNAM.
J'ai mis en uvre la mthode du PMBOK (Project Management Body Of Knowledge) [1]
pour l'ensemble du projet et l'tablissement du plan de management. Ce document
regroupe l'ensemble des connaissances du domaine du management de projet.
Pour mener les processus d'acquisition, de validation, de vrification et de rsolution des
problmes du logiciel, je me suis appuye sur la norme ISO/CEI 12207 [2] et
principalement ses processus Acquisition, Validation et Vrification.
Dans le cadre du processus Acquisition, j'ai utilis la norme NF X50-151 [3] pour la
rdaction de l'expression fonctionnelle du besoin et du cahier des charges fonctionnel.
Cette norme dcrit le contenu et le cycle de vie de ces deux documents.
Pour recueillir les exigences contenues dans l'expression fonctionnelle de besoin, je me
suis inspire du livre d'Alistair Cockburn [4] permettant de dterminer les cas d'utilisation
et par consquent les exigences fonctionnelles auxquelles devra rpondre le logiciel de
GED acqurir.
Enfin, dans le but d'valuer la ralisation et de dterminer des voies d'amlioration, le
CMMI (Capacity Maturity Model Integration) [5] a t mis en uvre.
Sabine Champenois
47/125
Le processus Acquisition de la norme ISO/CEI 12207 couvre lacquisition dun produit

logiciel de lexpression des besoins la mise en production. On peut distinguer toutefois
quatre grandes phases :
la phase de planification (voir IV.1) concerne la mise en place du projet avec la

rdaction d'un plan qualit projet qui comporte les rgles de management du projet, le
plan de production avec son dcoupage en tches et des rgles de qualit comme la
gestion de la documentation du projet. Dans cette phase mon rle a t celui
dAssistance la Matrise dOuvrage (AMO), responsable de la bonne fin de
lensemble des travaux,
la phase d'acquisition du logiciel de GED et de slection de son fournisseur (voir

IV.2) consiste dans le recueil des exigences auprs des utilisateurs qui a abouti la
rdaction de l'expression fonctionnelle du besoin et du cahier des charges fonctionnel.
Puis lanalyse des outils disponibles sur le march a permis de dfinir les solutions
logicielles pouvant rpondre aux exigences de GTT. Enfin, stant assur de lexistence
de telles solutions, jai procd un appel d'offres et jai slectionn un logiciel de
GED : Cincom ECM puis termin cette phase par la contractualisation avec son
fournisseur : Cincom. Dans cette phase, mon rle a t celui d'AMO, responsable de la
bonne fin de lensemble des travaux,
la phase de mise en place du logiciel de GED (voir IV.3) a consist en la dfinition

des spcifications fonctionnelles permettant d'tablir les paramtrages ncessaires la
mise en place du logiciel dans le contexte de GTT. Tout au long de cette phase, le suivi
du fournisseur et du contrat a t ralis. Enfin, les activits connexes de validation et
vrification se sont acheves avec la mise en production du systme de GED et la
clture du contrat. Dans cette phase, mon rle a t celui d'AMO, responsable du
contrle du fournisseur et de la mise disposition des fournitures la charge de GTT.
Jai eu la charge de la validation et de la vrification du logiciel afin dassurer la
rception de la fourniture,
la phase dvaluation (voir IV.4) a eu pour objectif d'valuer les activits et tches
ralises tout au long du projet afin de dterminer les voies d'amlioration. Jai donc
procder une revue de fin de projet de sorte que GTT dispose dune base de
connaissance sur lutilisation des bonnes pratiques dans la cadre dun projet
dacquisition de logiciel.
IV.1 Phase Planification

La premire phase du projet a eu pour objectif de slectionner les mthodes de travail et les
standards utiliser dans le cadre du projet et galement de rdiger le plan de management
du projet.
IV.1.1 Prsentation des mthodes et des standards utiliss
Au sein de GTT aucune mthode ou standard n'est impose pour la gestion de projet, la
slection et la mise en place de logiciels. Il a donc fallu choisir les outils utiliser en
fonction des activits raliser. Il est apparu ncessaire d'avoir un cadre pour la gestion du
projet, les phases d'acquisition et de mise en place d'un logiciel, pour dterminer les
exigences du logiciel acqurir et galement pour dfinir les amliorations apporter pour
les futurs projets du Dpartement Systme d'Information.
Sabine Champenois
48/125
Lors de mon cursus au CNAM, j'ai eu l'occasion d'tudier le PMBOK [1]. Ce guide est
tabli par le PMI (Project Management Institute) et regroupe l'ensemble des connaissances
du domaine du management de projet. Son objectif est de dfinir de bonnes pratiques dans
ce domaine. Il regroupe les processus d'un projet en domaines de connaissances et dcrit
pour chaque processus les donnes d'entre, les outils et techniques et les donnes de
sortie.
Les domaines de connaissances du PMBOK sont les suivants :
management de l'intgration du projet : dcrit les processus qui intgrent les divers
lments du management du projet,
management du contenu du projet : dcrit les processus ncessaires pour garantir que le
projet comprenne tous les travaux ncessaires sa ralisation, et uniquement ces
travaux,
management des dlais du projet : dcrit les processus ncessaires pour assurer la
ralisation du projet en temps voulu,
management des cots du projet : dcrit les processus de planification, d'estimation, de

budgtisation et de matrise des cots ncessaires pour s'assurer que le projet est ralis
en respectant le budget approuv,
management de la qualit du projet : dcrit les processus ncessaires pour s'assurer que
le projet rponde aux besoins dfinis au dpart,
management des ressources humaines du projet : dcrit les processus ncessaires pour
organiser et diriger l'quipe projet,
management des communications du projet : dcrit les processus ncessaires pour

assurer, en temps voulu et de faon approprie, la gnration, la collecte, la diffusion,
le stockage et le traitement final des informations du projet,
management des risques du projet : dcrit les processus lis au management des risques
dans le cadre du projet,
management des approvisionnements du projet : dcrit les processus ncessaires

l'achat ou l'acquisition de produits, de services ou de rsultats, et les processus de
management des contrats.
Le processus de management de la qualit est un processus gnral l'entreprise. Il ne sera

pas explicit dans le plan de management du projet mais l'quipe projet travaillera en
relation avec le responsable qualit afin de respecter les exigences du systme de
management de la qualit de GTT.
De mme, le processus de management des ressources humaines du projet est un processus
gnral de l'entreprise. On s'appuiera sur les outils existants au sein de l'entreprise :
organigramme, fiches de fonction, tableaux des habilitations et comptences, plan de
formation, entretien individuel annuel et politique de rmunration. Ces outils ne seront
pas dcrits dans le plan de management du projet.
Le processus de management des approvisionnements du projet du PMBOK n'a pas t
utilis ; c'est celui de l'ISO/CEI 12207 qui a t retenu. Ces deux processus tant trs
proches.
Sabine Champenois
49/125
L'tude et la mise en uvre de ces processus de management m'ont permis de rdiger le

plan de management du projet et donc de dfinir le cadre de travail. En fin de document
(voir VII Abrviations et glossaire) sont dfinis les principaux termes utiliss par le
PMBOK.
Dans le domaine du logiciel, la norme ISO/CEI 12207 [2] dcrit l'ensemble du cycle de vie
d'un logiciel sous forme de processus, dcomposs en activits, elles-mmes dcomposes
en tches. Cette norme est applicable durant l'acquisition d'un logiciel ou d'un service et
durant la fourniture, le dveloppement, le fonctionnement, la maintenance et la mise au
rebut de logiciels que ce soit ralis en interne ou en externe une entreprise. Cette norme
s'adresse donc la fois aux acqureurs, aux fournisseurs et aux parties prenantes du cycle
de vie d'un logiciel. La Figure 24 extrait de la norme prsente les diffrents processus.
Figure 24 : Processus du cycle de vie d'un logiciel selon l'ISO/CEI 12207
Sabine Champenois
50/125
De nombreux processus ne couvraient pas les besoins du projet ou taient redondants avec
ceux du PMBOK. Les processus suivants ont t slectionns et mis en uvre dans le
cadre des activits du projet :
"Acquisition process" ou processus d'acquisition. Dans ce processus, l'activit

"Acquisition preparation" ou prparation de l'acquisition ne sera pas utilise car c'est la
norme NF X50-151 qui sera mise en uvre,
"Software verification process" ou processus de vrification du logiciel,
"Software validation process" ou processus de validation du logiciel,
"Software problem resolution process" ou processus de rsolution des problmes du

logiciel.
La norme NF X50-151 [3], "Expression fonctionnelle du besoin et cahier des charges

fonctionnel", traite des exigences pour l'expression et la validation du besoin satisfaire
dans le processus d'acquisition d'un produit. Elle prsente les trois processus suivant :
analyse fonctionnelle du besoin permettant d'laborer l'expression fonctionnelle du

besoin,
tablissement du cahier des charges fonctionnel utilis dans le cadre d'un appel d'offre,
obtention d'une version de rfrence du besoin partir du cahier des charges

fonctionnel final et approuv.
Ces processus permettent de raliser deux documents dont l'objectif est d'exprimer des
besoins en termes de fonctions de service et de contraintes, et cela, sans faire rfrence aux
solutions techniques pouvant les satisfaire. La norme propose une dmarche pour la
recherche d'un optimum entre le besoin exprim et la fourniture correspondant sa
satisfaction.
Dans le cadre du prsent projet, l'ensemble de ces exigences a t respect afin de rdiger
l'expression fonctionnelle du besoin et le cahier des charges fonctionnel qui ont servi dans
le cadre de l'appel d'offre mais aussi tout au long du projet comme documents de rfrence.
Afin de dterminer les fonctions assurer par le logiciel de GED, la mthode propose par
Alistair Cockburn dans son livre "Rdiger des cas d'utilisation efficaces" [4] a t mise en
uvre. L'auteur donne des directives pour la rdaction et la supervision de cas d'utilisation.
La mise en place de cette mthode avec l'aide des reprsentants des utilisateurs m'a permis
d'tablir l'ensemble des exigences fonctionnelles ncessaires pour le logiciel de GED. Ces
exigences sont dcrites dans l'expression fonctionnelle du besoin sous forme de cas
d'utilisation.
Le CMMI est un modle de rfrence [5] tabli par le SEI (Software Engineering Institute)
qui traite des bonnes pratiques relatives aux activits de dveloppement et de maintenance
appliques aux produits et aux services. Il concerne les pratiques qui couvrent le cycle de
vie du produit, de sa conception sa livraison et sa maintenance, et met l'accent sur le
travail ncessaire pour construire et maintenir l'ensemble du produit. Ainsi, il englobe la
gestion de projet, la gestion de processus, l'ingnierie des systmes, l'ingnierie matrielle,
l'ingnierie logicielle et d'autres processus support utiliss par le dveloppement et la
maintenance.
Sabine Champenois
51/125
Le CMMI se concentre sur l'amlioration des processus d'une organisation par une
dmarche volutive permettant de passer de processus opportunistes et immatures des
processus disciplins, matures, de meilleure qualit et efficaces. De plus, il permet de
raliser des valuations de ces processus grce aux reprsentations continue et tage. La
reprsentation continue permet de choisir un domaine de processus et d'amliorer les
processus qui lui sont lis. Elle utilise pour cela des niveaux d'aptitude. La reprsentation
tage utilise des ensembles de domaines de processus prdfinis pour dterminer la voie
d'amlioration. Cette voie est caractrise par des niveaux de maturit.
Dans le cadre du projet d'acquisition et de mise en place d'une GED, le CMMI est utilis
avec la reprsentation continue pour valuer les domaines de processus suivants :
planification de projet,
surveillance et contrle du projet,
gestion des accords avec les fournisseurs,
gestion des risques,
vrification,
validation.
Ces domaines de processus couvrent les principales activits du projet et vont me

permettre d'valuer la mise en uvre ralise et de dfinir des axes d'amlioration pour les
futurs projets.
Sabine Champenois
52/125
Le Tableau 5 rsume pour chaque phase et activit du projet, la norme ou la mthode

utilise et les domaines de processus de contrle du CMMI.
Phases et
activits du
projet
Phase de
planification
Norme ou
mthode
utilise
PMBOK
Organisation du
projet
Dfinition du
contenu du projet
Gestion des dlais
Gestion des cots
Gestion des
communications
Gestion des
risques
Gestion des
modifications
Aucune
Phase
d'acquisition
Recueil des
exigences
Rfrence au sein de la norme

Domaine de
ou de la mthode
processus du CMMI
Management de l'intgration du Planification de projet
projet, processus d'laboration du
plan de management du projet
Planification de projet
PMBOK
Management du contenu du
projet
PMBOK
Management des dlais du projet
PMBOK
Management des cots du projet
PMBOK
Management des
communications du projet
PMBOK
Management des risques du
projet
PMBOK
Management de l'intgration du
projet, processus de surveillance
et de matrise du travail du projet
et processus de matrise intgre
des modifications
ISO/CEI 12207 Acquisition process
NF X50-151
Intgralit des documents
Mthode d'A.
Cockburn
ISO/CEI 12207 Acquisition advertisement
Appel d'offre
Gestion des risques
Surveillance et
contrle du projet
Gestion des accords

avec les fournisseurs
-
Gestion des accords

Gestion des accords
Gestion des accords
-
Aucune
Slection du
ISO/CEI 12207 Supplier selection
fournisseur
Contractualisation ISO/CEI 12207 Contract agreement
Phase de mise en
place
Spcifications
fonctionnelles
Suivi du
fournisseur
Validation et
vrification
ISO/CEI 12207 Agreement monitoring
ISO/CEI 12207 Software verification process

Software validation process
Software problem resolution
process
Acquirer acceptance
Clture du contrat ISO/CEI 12207 Closure
Gestion des accords

Vrification
Validation
Gestion des accords

Tableau 5 : Rcapitulatif des normes et mthodes utilises dans le cadre du projet
Sabine Champenois
53/125
Dans la suite du document, pour chaque activit, les exigences de la norme ou de la

mthode seront rappeles, mon rle en tant que chef de projet MOA et la mise en uvre
concrte dans le cadre du projet sera dcrite et les rsultats obtenus seront prsents.
IV.1.2 Plan de management du projet
Le projet est mis en uvre par une premire phase de planification dont l'objectif est
d'tablir le plan de management du projet. Ce document est ralis l'aide de la mthode
du PMBOK [1].
Mon rle a consist en l'laboration de ce document et en sa validation par le Responsable
Qualit et la Direction Gnrale, puis en l'application de ce document par l'ensemble des
participants du projet et sa mise jour.
Le projet est mis en uvre selon la roue de Deming ou cycle PDCA pour Plan/Planifier,
Do/Drouler, Check/Contrler et Act/Amliorer. Ce cycle peut tre dcrit comme la suite
d'tapes suivantes :
Planifier : tablir les objectifs et les processus ncessaires pour fournir des rsultats
correspondants aux exigences des clients. Cette phase est ralise au travers la
rdaction du plan de management du projet,
Faire : mettre en uvre les processus dfinis dans le plan de management du projet.
Cette phase comporte les activits des phases d'acquisition et de mise en place (hors
activits de validation et de vrification),
Vrifier : surveiller et mesurer les processus et le produit par rapport aux politiques,
objectifs et exigences du produit, et rendre compte des rsultats. Cette phase comporte
l'ensemble des activits de validation et de vrification de chaque activit et du logiciel
livr ainsi que l'tablissement des rapports d'avancement,
Amliorer : entreprendre les actions pour amliorer en permanence les performances

des processus. Cette phase, a pour objectif de capitaliser le retour d'exprience du
projet et ainsi d'amliorer la ralisation des projets suivants. Elle est ralise par une
valuation selon le CMMI.
Le plan de management du projet est tabli en dbut de projet sur la base de la mthode du
PMBOK. Ce document dfinit la manire dont le projet est excut, surveill et matris, et
clos. Il doit permettre d'atteindre les principaux objectifs suivants :
constituer une rfrence commune tous les membres de l'quipe projet,
assurer une bonne cohrence et une homognit dans les mthodes de travail,
garantir la qualit des livrables du projet,
dfinir les procdures suivre, les outils utiliser, les normes respecter, la
mthodologie d'excution du projet et les contrles prvus pour chaque activit.
Ce document dfinit l'organisation du projet, son contenu, la gestion des dlais, des cots,
de la communication, des risques et des modifications du projet. Il est approuv par le
responsable qualit et la Direction avant d'tre mis en uvre.
L'ensemble de ce document est prsent ci-aprs. Pour chaque processus, les principales
activits et les donnes de sortie dfinies par le PMBOK sont synthtises. Puis, dans le
cadre du prsent projet, l'application concrte est dcrite.
Sabine Champenois
54/125
IV.1.2.1 Organisation du projet

Le projet est gr par le chef de projet (moi-mme) qui s'appuie sur deux instances :
le comit de pilotage ou COPIL,
le comit des utilisateurs ou COUTIL.
Le rle du chef de projet (moi-mme) en tant qu'assistance la matrise d'ouvrage est de :
grer le projet en termes d'organisation, de dlais, de cots et de qualit,
rapporter de l'avancement du projet au COPIL,
animer le COUTIL,
rdiger le cahier des charges,
participer la phase de recherche et d'valuation de solutions,
effectuer le suivi du fournisseur lors de la phase de mise en place,
raliser l'ensemble des tests de validation et de vrification permettant de contrler la

conformit du logiciel avant sa mise en production.
Le COPIL est prsid par le Directeur Gnral Dlgu et compos des quatre Directeurs
et du chef du projet. Son rle en tant que matrise d'ouvrage est de :
suivre l'avancement du projet,
dcider les actions suite aux ventuels problmes rencontrs dans le droulement du
projet,
dcider de la composition du COUTIL,
suivre le travail du COUTIL,
de prendre la dcision du choix de la solution,
de conduire le changement.
La composition du COUTIL est dcide par le COPIL et comprend des reprsentants des
utilisateurs de chaque Dpartement de l'entreprise. Il est dirig par le chef de projet. Son
rle est de :
dfinir les besoins,
donner son avis dans le choix de la solution,
avoir un rle de consultation et de proposition vis--vis du COPIL par le truchement du

chef de projet,
tre un relais au sein de leur Dpartement pour la collecte de tous les lments
ncessaires et la diffusion des informations concernant le projet,
participer la phase de mise en place.
Sabine Champenois
55/125
L'organisation du projet est tre rsume dans la Figure 25.

Matrise douvrage
Direction Gnrale
Assistance la matrise douvrage

Dpartement Systme
dInformation
provient
COPIL
Chef de projet
(AMO)
COUTIL
Matrise duvre
Cincom
Figure 25 : Organisation du projet
Le chef de projet en tant qu'assistant matrise d'ouvrage va s'appuyer sur cette

organisation pour excuter l'ensemble des activits du projet.
IV.1.2.2 Dfinition du contenu du projet
La dfinition du contenu du projet a pour objectif de dfinir et matriser ce qui fait ou non
partie du projet. Le contenu comporte le travail qui doit tre ralis pour acqurir et mettre
en place un logiciel de GED. Cette activit s'accompagne de la cration de la structure de
dcoupage du projet (voir Annexe 1 : Rcapitulatif du PMBOK pour la dfinition du
contenu du projet).
Mon rle a t de dfinir le contenu du projet et de crer sa structure de dcoupage.
Dans le cadre du projet, pour les donnes d'entre, il n'y avait de pas de charte du projet
formalise. Cependant la Direction avait affirm plusieurs reprises sa volont de se doter
d'un logiciel de GED et avait pour cela recrut un chef de projet ddi (moi-mme) qui
devait lui rapporter directement de ses activits. Concernant l'nonc prliminaire, il a t
tabli comme suit : "Acqurir un logiciel de GED pour grer l'ensemble de la
documentation de l'entreprise".
L'ensemble des activits dfinies dans le PMBOK est ralis squentiellement. Les outils
et techniques utilises sont dcrits ci-aprs.
Sabine Champenois
56/125
La dfinition du contenu du projet a t ralise en utilisant l'analyse des parties prenantes.

Chaque responsable hirarchique ainsi que des acteurs de l'entreprise confronts
quotidiennement la gestion de documents ont t interrogs sur la base d'un
questionnaire. Celui-ci abordait les thmatiques sur les types de document grs, leur
quantit, leur origine, leur mthode de classement, leur accs, leurs destinataires, leurs
circuits de validation et leur archivage. La synthse de ces entretiens a permis d'obtenir
l'nonc du contenu du projet suivant :
Les fonctions principales attendues par la mise en place d'un logiciel de GED sont :
la centralisation des documents,
l'amlioration des changes de documents entre les Dpartements,
une amlioration du suivi des livrables clients.
La solution sera une application informatique accessible par tout le personnel de GTT
permettant de grer toute documentation interne ou externe. Elle devra pouvoir
communiquer avec les applications existantes et d'ventuelles autres applications qui
seraient mises en place pour rpondre des besoins complmentaires la GED (base de
donnes mtier).
Les livrables du projet sont :
pour la phase d'acquisition, un cahier des charges et un contrat pass avec un ou

plusieurs fournisseurs,
pour la phase de mise en place de la solution, la solution informatique paramtre,

installe et rceptionne, ainsi que la documentation utilisateur et administrateur et la
formation des utilisateurs et des administrateurs.
L'nonc du contenu du projet prsente les limites et les exclusions suivantes.

Le primtre du projet exclura les outils complmentaires la GED, comme par exemple
un outil d'import de l'existant, une base de donnes mtier galement les volutions
futures qui pourront tre apportes la solution seront exclues. Elles feront l'objet d'un
nouveau projet. Ces volutions seront capitalises dans un fichier Excel de suivi des
demandes d'volution.
Aucune contrainte financire et de temps n'est impose par la direction.
Le principal risque identifi ce stade du projet est un rejet de la solution par les
utilisateurs.
Sabine Champenois
57/125
A partir de cet nonc, la structure de dcoupage du projet et son dictionnaire ont t

tablis en subdivisant chaque livrable du projet en composants plus petits.
La structure de dcoupage du projet est la suivante :
pour la phase d'acquisition du logiciel :

o rdaction d'un cahier des charges,
o lancement d'un appel d'offre,
o slection d'un ou plusieurs fournisseurs,
pour la phase de mise en place du logiciel :

o paramtrages ou dveloppements ventuels (raliss par le ou les fournisseurs),
o tests et recette,
o installation,
o formations,
o mise en production.
L'ensemble de ces informations (nonc du contenu du projet, structure de dcoupage et

dictionnaire de la structure de dcoupage) est intgr dans le plan de management du projet
qui est approuv par le responsable qualit et la Direction et constitue la rfrence de base
du contenu.
IV.1.2.3 Gestion des dlais
La gestion des dlais du projet a pour objectif de s'assurer que le projet contient tout le
travail requis, et uniquement celui-ci, pour assurer la bonne fin du projet (voir Annexe 2 :
Rcapitulatif du PMBOK pour la gestion des dlais du projet).
Mon rle a t d'laborer l'chancier du projet et de le matriser.
Les principales donnes d'entre proviennent des sorties de la dfinition du contenu du
projet. La disponibilit des ressources est connue au sein de GTT grce au logiciel de
gestion des absences.
et techniques utilises sont dcrits ci-aprs. Sur l'ensemble de la ralisation, le logiciel de
gestion de projet Microsoft Project est utilis.
L'identification des activits est ralise sur la base de la structure de dcoupage du projet
par dcomposition en tches lmentaires.
Le squencement des activits est obtenu grce la mthode des antcdents. Elle permet
de construire un diagramme de rseau du projet dans lequel les activits sont reprsentes
par des rectangles et sont relies par des flches qui montrent leurs dpendances. Les
liaisons fin-dbut sont tablies. Ainsi, le dmarrage de l'activit successeur dpend de
l'achvement de l'activit antcdente.
Sabine Champenois
58/125
L'estimation des ressources ncessaires aux activits est ralise l'aide du logiciel de
gestion de projet. Ces ressources sont uniquement humaines dans le cadre du prsent
projet.
Pour l'estimation de la dure des activits, j'ai utilis mes retours d'exprience et ajouter
des provisions pour alas prenant en compte un certain nombre de risques du projet.
Enfin, l'laboration de l'chancier a t ralise pour une grand part par le logiciel de
gestion de projet. Celui-ci utilise les contraintes indiques, les dures tablies, les liaisons
entre les activits et le calendrier des ressources prcdemment dfinis. La dfinition des
dates de dbut a t faite en fonction des disponibilits des ressources ou des contraintes du
projet.
La donne de sortie de l'ensemble de ces activits est un planning ralis avec
Microsoft Project et intgr dans le plan de management du projet. Dans ce fichier, on
retrouve :
la liste d'activits avec pour chaque son identifiant,
la liste des jalons symboliss par un losange,
la reprsentation graphique du diagramme de rseau du projet,
les ressources ncessaires aux activits (personne ou fonction),
le calendrier des ressources : jours fris et absences de chaque personne qui ont t
tablies l'aide du logiciel de gestion des absences,
l'estimation de la dure des activits,
l'chancier du projet avec la date de dbut et la date de fin pour chaque activit sous
forme de tableau et de graphique,
les donnes du modle d'chancier avec pour chaque activit, l'indication des
ressources associes.
Pour les activits ralises par Cincom, les donnes qu'il a fournies ont t intgres au
planning.
Mme si aucun dlai de ralisation n'a t impos par la Direction, les contraintes suivantes
ont t tablies :
finalisation des documents ncessaires pour l'appel d'offre fin juin 2009,
slection du ou des fournisseurs et signature du contrat fin 2009.
mise en production en juin 2010.
Sabine Champenois
59/125
Le planning obtenu pour la phase d'acquisition est prsent la Figure 26.
Figure 26 : Planning du projet, phase Acquisition
Sabine Champenois
60/125
Le planning obtenu pour la phase de mise en place est prsent la Figure 27.
Figure 27 : Planning du projet, phase Mise en place
Sabine Champenois
61/125
A la validation du plan de management du projet par le Responsable Qualit et la

Direction, la rfrence de base de l'chancier est enregistre comme planification initiale
dans Microsoft Project et servira de base de surveillance.
Concernant la matrise de l'chancier, l'tablissement du rapport d'avancement
hebdomadaire permet de faire un tat de l'avancement de chaque activit en fonction des
dates relles de dbut et des dures restantes. Ainsi, pour chaque activit, le pourcentage
d'avancement est calcul automatiquement par le logiciel de gestion de projet. Par
comparaison avec la rfrence de base de l'chancier, les carts (avances ou retards) sont
identifis puis analyss et documents dans le rapport d'avancement. Cette analyse permet
de mettre jour l'ensemble des informations de l'chancier et sa rfrence de base.
IV.1.2.4 Gestion des cots
La gestion des cots a pour objectif de s'assurer que le projet peut tre ralis en respectant
le budget approuv (voir Annexe 3 : Rcapitulatif du PMBOK pour la gestion des cots du
projet).
Mon rle a t de dfinir le budget du projet et de le matriser.
Les donnes d'entre proviennent principalement des sorties de la dfinition du contenu du
projet, de la gestion des dlais et des risques.
L'estimation des cots en ressources humaines est ralise par estimation ascendante de
chaque activit de l'chancier du niveau le plus bas vers le plus haut. L'estimation du cot
d'acquisition du logiciel de GED est tablie suite des estimatifs fournis par divers
diteurs. Pour ces deux estimations, des provisions pour alas prenant en compte un certain
nombre de risques du projet sont intgres dans le cot final tabli.
La budgtisation est obtenue par agrgation des cots unitaires de chaque activit.
L'estimation du cot des activits est prsente sous forme d'un tableau rcapitulatif
contenant les cots en jour/homme pour les ressources humaines internes l'entreprise et
les cots en euros pour l'achat du logiciel de GED et les prestations associes.
Le dtail de l'estimation contient les activits de l'chancier avec pour chacune le cot
minimum et maximum estim.
L'ensemble de ces donnes permet d'obtenir le budget total du projet. Ces informations
sont intgres au plan de management du projet. Aucune exigence lie au financement du
projet n'est demande par la Direction.
Le budget ainsi obtenu est le suivant :
de 350 550 jours/homme pour les ressources humaines internes l'entreprise,
de 200 000 400 000 pour l'ensemble des achats.
Sabine Champenois
62/125
A la validation du plan de management du projet par le Responsable Qualit et la

Direction, la rfrence de base des cots est enregistre et servira de base de surveillance.
Concernant la matrise des cots, l'tablissement du rapport d'avancement hebdomadaire
permet de faire un tat des dpenses pour chaque activit en fonction des cots estims et
rels. Par comparaison avec la rfrence de base des cots, les carts sont identifis puis
analyss et documents dans le rapport d'avancement. Cette analyse permet de mettre
jour l'ensemble des informations d'estimation des cots et sa rfrence de base.
IV.1.2.5 Gestion des communications
La gestion des communications a pour objectif d'assurer, en temps voulu et de faon
approprie, la gnration, la collecte, la diffusion, le stockage, la rcupration et le
traitement final des informations du projet (voir Annexe 4 : Rcapitulatif du PMBOK pour
la gestion des communications du projet).
Mon rle a t d'tablir le plan de management des communications du projet et de le
mettre en uvre.
projet, de la gestion des cots et de la gestion des dlais.
La planification des communications est tablie grce une analyse des besoins en
communication. Pour chaque partie prenante du projet sont dfinis les besoins, le niveau de
dtails des informations fournir, le mode de communication, la frquence et la personne
charge de communiquer.
La diffusion de l'information s'appuie sur les comptences en communication de l'quipe
projet et les outils informatiques de l'entreprise. L'ensemble des informations du projet
(documents, fichiers produits ou reus) est mis en rseau dans un espace ddi et
accessible tous les participants du projet. Les mthodes et outils choisis sont les runions
en prsentiel, en visioconfrence ou via Internet, le partage des documents et des fichiers
sur le rseau, les changes de courriels et le tlphone. Chaque runion fait l'objet d'un
ordre du jour et d'une invitation. A l'issue de la runion, j'tablis le compte-rendu et je
l'envoie aux participants pour validation.
L'tablissement du rapport d'avancement est ralis suite la collecte et la compilation de
l'information sur la performance du projet, notamment l'avancement du planning, les temps
passs et les dpenses engages.
Le management des parties prenantes s'appuie sur les mthodes de communication dfinies
dans le plan de management des communications du projet. De plus, un registre des
problmes permet de collecter les problmes majeurs et de suivre leur rsolution.
Sabine Champenois
63/125
La planification des communications a permis de rdiger la partie concernant la gestion des

communications du projet incluse dans le plan de management. Les dispositions sont
tablies dans le Tableau 6 en fonction des parties prenantes.
Partie
prenante
Direction
Gnrale
Besoins
Avancement du
projet
Problmes
rencontrs
ncessitant une
prise de dcision
Mode de
communication
Runion
Courriel
Compte-rendu
d'avancement
hebdomadaire
Chef de
projet
Runion
Courriel
Lors de principaux
jalons du projet
Chef de
projet
Runion
Courriel
Tlphone
Une fois par semaine Chef de

pour l'avancement
projet
Pour les questions
urgentes ou
bloquantes
ncessitant une prise
de dcision
Lors des principaux
jalons du projet
Pour valider les
phases du projet
Information sur
l'avancement, les
problmes
rencontrs, les
dcisions impactant
leur Direction
Runion
Courriel
Compte-rendu
d'avancement
mensuel
COUTIL
Avancement du
projet
Dcisions
concernant les
fonctionnalits du
logiciel
Dmonstration des
produits du march
Avancement du
projet
Prparation au
changement
Avancement du
projet
Questions
Runion
Courriel
Tlphone
Fournisseur
Responsable
Chaque semaine
pour le rapport
d'avancement
Lors des principaux
jalons du projet
Pour valider les
phases du projet
Problme ncessitant
une dcision
Chaque mois pour le
rapport
d'avancement
Lors des principaux
jalons du projet
Pour valider les
phases du projet
Problme ncessitant
leur avis ou une
dcision
Toutes les semaines
lors des travaux de
dfinition des
exigences
A tout moment pour
rpondre aux
questions poses
COPIL
Ensemble
de
l'entreprise
Frquence
Chef de
projet
Chef de
projet
Tableau 6 : Plan de management des communications du projet
Sabine Champenois
64/125
Le rapport d'avancement est ralis toutes les fins de semaine et diffus au Directeur
Dlgu Adjoint. Chaque mois, le rapport est envoy aux membres du COPIL. Ce rapport
contient les informations suivantes :
les faits marquants,
le suivi de l'avancement au travers du planning Microsoft Project ainsi que l'analyse

des carts,
le suivi des cots ainsi que l'analyse des carts,
le suivi des risques,
les problmes rencontrs et l'avancement de leur rsolution,
les actions de modifications en cours,
les prvisions.
L'tablissement de ce rapport permet de mettre jour, entre autres, le planning et les

estimations des cots et le registre des risques.
Le management des parties prenantes est ralis au travers d'un tableau rcapitulant les
problmes majeurs identifis tout au long du projet. Pour chaque problme, les
informations suivantes sont indiques :
un identifiant,
la date de dcouverte,
le dcouvreur,
la description du problme le plus prcisment possible,
le responsable de la rsolution,
la date estime de rsolution,
la rsolution apporte,
la date de clture.
Ce registre des problmes est revu toutes les semaines lors de l'tablissement du rapport
d'avancement.
IV.1.2.6 Gestion des risques
La gestion des risques a pour objectif d'augmenter la probabilit et l'impact des vnements
positifs et de diminuer la probabilit et l'impact des vnements dfavorables au projet
(voir Annexe 5 : Rcapitulatif du PMBOK pour la gestion des risques du projet).
Mon rle a t d'tablir un registre des risques et de le matriser.
projet.
Sabine Champenois
65/125
L'identification des risques est ralise grce des techniques de collecte des informations
comme le remue-mninge sur la base de la structure de dcoupage des risques propose
dans le PMBOK. Lors de la ralisation des entretiens pour dfinir le contenu du projet,
quelques risques ont t identifis et ont servi de base de rflexion.
L'analyse qualitative des risques est ralise en effectuant une valuation de la probabilit
de survenance du risque et de l'impact du risque en termes de dlais, cot, contenu ou
qualit.
L'analyse quantitative des risques n'a pas t ralise dans le cadre du projet faute
d'exprience et de connaissance des outils et techniques utiliss dans ce domaine.
La planification des rponses aux risques utilise des stratgies d'vitement ou d'attnuation
pour les risques ngatifs et ainsi propose des rponses. Dans certains cas, l'acceptation du
risque peut tre dcide et donc aucune rponse n'est mise en uvre pour attnuer ou
diminuer ce risque.
La donne de sortie de l'ensemble de ces activits est un registre des risques intgr au plan
de management du projet. Ce document contient la liste des risques par catgorie avec pour
chaque risque identifi :
les causes,
la probabilit de survenance : trs peu probable, peu probable, probable ou presque

certain,
l'impact sur le projet : trs faible, faible, modr, lev ou trs lev,
le type d'impact : cot, contenu, dlais et/ou qualit,
les rponses potentielles.
Sabine Champenois
66/125
Le Tableau 7 est un extrait du registre des risques prsentant les catgories retenues ainsi
que les risques ayant l'impact le plus leve dans le cadre du projet.
Catgorie
Exigences
Risque
Causes
Probabi- ImType
Rponses
lit
pact impact
Contour des
Manque de
Probable Trs Contenu Dfinition du
exigences mal temps
lev Cot
contour par le
dfinies
Manque de
Dlais
COPIL aprs
retours de la
entretien avec
part des futurs
les diffrents
utilisateurs
responsables et
reprsentants
des futurs
utilisateurs
Exigences
Rgles de
Probable Trs Contenu Rdaction d'une
incompatibles gestion des
lev Cot
procdure de
entre les
documents
Dlais
matrise
Dpartem ents diffrentes
documentaire
dans les
Dpartements
Les niveaux de Politique des Probable Trs Cot
COPIL doit
confidentialit droits d'accs
lev Dlais
revoir sa
dfinis sur les
politique de
documents ne
droits d'accs
doivent pas
limiter les
accs aux
documents.
Le systme
risque d'tre
abandonn par
les utilisateurs
car il ne leur
apportera rien
de plus.
Technologie
Complexit
Performance et
fiabilit
Qualit
Fournisseurs
Sabine Champenois
67/125
Catgorie
Client
Risque
Application
non utilise
Causes
Accs limit
aux
documents
Difficult
d'utilisation
Rejet du
changement
Probabi- ImType
Rponses
lit
pact impact
Probable Trs Cot
Implication du
lev Dlais
COUTIL
Communication
interne
Phase de
formation
Intgration de
la signature
lectronique
pour approuver
les documents
obligeant
l'utilisation du
logiciel
Dpendances du
projet
Ressources
Communication
Tableau 7 : Extrait du registre des risques du projet
Concernant la surveillance et la matrise des risques, l'tablissement du rapport

d'avancement hebdomadaire permet de rvaluer les risques du registre et ainsi d'ajouter,
de complter ou de supprimer des risques. Les modifications ralises sont documents
dans le rapport d'avancement. Cette analyse permet de mettre jour l'ensemble des
informations d'estimation des cots et de dlais du projet.
IV.1.2.7 Gestion des modifications
La gestion des modifications a pour objectif de maintenir le plan de management du projet,
l'nonc du contenu du projet et les divers livrables du projet par une matrise soigneuse et
permanente des modifications. Cela, soit en rejetant, soit en approuvant les demandes de
modifications. Les modifications approuves sont ensuite incorpores dans les documents
et livrables rviss (voir Annexe 6 : Rcapitulatif du PMBOK pour la gestion des
modifications du projet). Les modifications non approuves sont archives ainsi que les
raisons de la non approbation. Ces demandes pourront ventuellement tre rexamines et
intgres dans une volution future.
Mon rle a t de surveiller et de matriser le travail du projet et de matriser les
modifications apportes.
projet et de la gestion des communications mais aussi de l'excution du projet.
Sabine Champenois
68/125
La surveillance et la matrise du travail du projet se font :
par la comparaison du ralis par rapport aux estimations,
par l'analyse, le suivi et la surveillance des risques du projet,
par le suivi de la mise en uvre des modifications approuves.
Ces tches sont ralises lors de l'tablissement du rapport d'avancement et permettent de

dterminer si des actions correctives ou prventives peuvent tre recommandes. De plus,
lors du droulement du projet, les problmes rencontrs peuvent ncessiter des corrections
de dfauts. Enfin, des demandes de modifications peuvent tre nonces par les diffrentes
parties prenantes.
La matrise intgre des modifications traite l'ensemble des demandes (actions correctives,
prventives, modifications et corrections de dfauts) et tudie s'il est ncessaire ou non de
les mettre en uvre. Cette tude est faite par le chef de projet qui peut demander l'avis du
COPIL. L'approbation d'une demande va entraner son traitement, mais galement la
modification de la documentation du projet et/ou des livrables ainsi que l'ensemble des
informations de prvisions du projet (dlais, cots et risques).
L'ensemble de ces demandes est capitalis dans un tableau dcrivant la demande, les
actions demandes et l'acception ou le refus de raliser les actions.
Les modifications engendres par ces demandes sont suivies au travers du tableau de suivi
des rvisions de chaque document. De plus, toute modification d'un document approuv
entrane le changement de son numro de rvision.
L'ensemble des processus de dfinition du contenu du projet, de gestion des dlais, des
cots, des communications, des risques et des modifications est explicit dans le plan de
management du projet. Ce document sert de cadre de rfrence l'ensemble des
participants du projet et de cadre de travail. Les phases et activits du projet dcrites ciaprs respectent les rgles tablies dans ce plan de management.
IV.2 Phase Acquisition

La phase d'acquisition a pour objectif d'acqurir un logiciel de GED du march rpondant
aux exigences dfinis par le Comit des Utilisateurs. Cette phase est dcoupe en activits
suivantes :
recueil des exigences afin d'tablir l'expression fonctionnelle du besoin et le cahier des
charges fonctionnel,
valuation des logiciels de GED du march afin de prslectionner les fournisseurs

pouvant rpondre l'appel d'offre,
lancement de l'appel d'offre auprs des fournisseurs prslectionns, tudes des

rponses et slection du fournisseur,
contractualisation avec le fournisseur slectionn.
L'ensemble de ces activits est dcrit ci-aprs.
Sabine Champenois
69/125
IV.2.1 Recueil des exigences

Le recueil des exigences a consist en la mise en uvre de la mthode d'Alistair
Cockburn [4] afin de dterminer les cas d'utilisation. Ceux-ci ont t intgrs
l'expression fonctionnelle de besoin, complte par un cahier des charges fonctionnel.
Mon rle a t d'tablir et de faire approuver ces deux documents selon les prconisations
de la norme NF X50-151 [3].
IV.2.1.1 Exigences fonctionnelles
Le recueil des exigences fonctionnelles a pour objectif de recenser tous les besoins des
utilisateurs en termes de fonctionnalits attendues par le futur logiciel de GED. Dans son
livre "Rdiger des cas d'utilisation efficaces", Alistair Cockburn [4] propose une mthode
pour raliser cela de manire exhaustive et en regard de l'objectif poursuivi.
Un cas d'utilisation dcrit des exigences fonctionnelles d'un systme ou d'un processus. Il
rassemble tous les scnarios qui conduisent au succs et l'chec. Chaque cas peut se
dcomposer en sous-cas d'utilisation. Pour rdiger ces cas d'utilisation, la mthode
propose est la suivante :
Dfinir les acteurs et leurs objectifs c'est--dire recenser par acteur tous les objectifs
utilisateur que doit prendre en charge le systme.
crire le scnario nominal de chaque cas d'utilisation sans prsenter les interfaces. Un
scnario est une squence d'tapes qui peut dcrire une interaction entre deux acteurs,
une validation ou un changement interne. Un scnario peut faire appel un autre
scnario.
crire les conditions d'chec pour chaque scnario nominal. Pour chaque tape du
scnario nominal o le comportement peut se ramifier en raison d'une condition
particulire, crire la condition puis les tapes de sa prise en charge. Pour cela, il faut
dterminer les cas de chemin alternatif de succs du scnario nominal, les cas de
comportement incorrect de l'acteur, son inaction, les cas d'chec de la validation, les
rponses inappropries ou les absences de rponses et les checs internes.
Collecter les donnes utilises dans les cas d'utilisation pour tablir le rfrentiel des
donnes.
Sabine Champenois
70/125
Dans le cadre du projet d'acquisition et de mise en place d'une GED, j'ai mis en uvre cette
mthode avec le Comit des Utilisateurs. Chaque semaine pendant la phase de dfinition
de recueil des exigences, le COUTIL s'est runi et a travaill l'laboration des cas
d'utilisation sous ma direction.
Tout d'abord, le formalisme de chaque exigence fonctionnelle a t tabli suivant le
Tableau 8.
N : identifiant
de l'exigence
Acteur
principal
Prconditions
Scnario
nominal
Intitul de l'exigence
Acteur concern par l'exigence.
Exigences respecter au pralable.

Liste numrote des actions ralises par l'acteur et le systme. Elle
commence par une condition d'excution et se termine par une condition
de fin qui correspond l'atteinte de l'exigence.
Liste numrote se rfrant une action du scnario nominal et
Extensions
dcrivant les conditions d'chec et leur traitement.
Dans le tableau, les textes souligns renvoient une autre exigence. Les textes en italique
correspondent une donne dcrite dans le rfrentiel des donnes.
Tableau 8 : Modle de prsentation d'un cas d'utilisation
Puis, les premires runions ont permis d'tablir la liste des acteurs et des objectifs
prsente dans le Tableau 9.
Acteur
Consultant de
documents
Crateur de
documents
Objectif
Consulter un document
Crer un document
Modifier un document
Valideur de
documents
Supprimer une rvision

non approuve d'un
document
Crer une nouvelle
rvision d'un document
Mettre en validation un
document
Valider un document
Refuser un document
Viseur de
documents
Sabine Champenois
Viser un document
Rsum de l'objectif
Le consultant recherche un document pour le
consulter et/ou consulter ses mtadonnes.
Le crateur cre un document. Il renseigne
les mtadonnes et associe ventuellement
un ou plusieurs fichiers.
Le crateur recherche un document. Il met
jour ses mtadonnes et/ou modifie ses
fichiers.
Le crateur supprime une rvision d'un
document cre par erreur.
Le crateur cre une nouvelle rvision de
document.
Le crateur met en validation le document
cr.
Le valideur valide un document. Le
document passe en approbation.
Le valideur refuse de valider un document. Il
commente son refus. Le document est
envoy son crateur pour modification.
Le viseur relit un document. Il peut mettre
des annotations.
71/125
Acteur
Objectif
Approbateur de Approuver un document
documents
Refuser un document
Responsable de Diffuser un document

livraisons
vers l'extrieur
externes
Suivre les livraisons
externes
Administrateur Grer les donnes et les
mtier
plans de classement
Grer les workflows
Administrateur
technique
Grer les utilisateurs
Suivre les sauvegardes

des donnes
Restaurer les donnes
Systme
Suivre les changes de

donnes avec
SolidWorks PDM
Recevoir des donnes de
SolidWorks PDM
Rsum de l'objectif
L'approbateur approuve un document. Le
document est approuv et peut tre diffus.
L'approbateur refuse d'approuver le
document. Il commente son refus. Le
document est envoy son crateur pour
modification.
Le responsable diffuse les documents
approuvs en dehors de GTT.
Le responsable consulte les rapports
concernant les livraisons externes.
L'administrateur mtier dfinit les plans de
classement et les listes de valeurs des
mtadonnes.
L'administrateur mtier dfinit les workflows
et les suit.
L'administrateur technique cre, modifie et
supprime des utilisateurs. Il leur donne des
droits d'accs.
L'administrateur technique suit les
sauvegardes des donnes du systme.
L'administrateur technique restaure les
donnes aprs un problme sur le systme.
Les donnes proviennent des sauvegardes.
L'administrateur technique contrle les
changes de donnes avec SolidWorks
PDM.
Le systme reoit des donnes provenant de
SolidWorks PDM. Il les contrle et les
intgre. Il tablit un rapport.
Tableau 9 : Acteurs et objectifs
Sabine Champenois
72/125
Le COUTIL a galement dtermin toutes les fonctionnalits de bas niveau que devait
raliser le logiciel de GED et prciser ses besoins sur les thmatiques suivantes :
les types de documents et les modles,
l'identification des documents,
les formats de fichier,
les mtadonnes associes un document,
le cycle de vie des documents,
les circuits de validation,
la notion de confidentialit,
l'accs au systme,
la cration des documents,
la gestion des documents,
la consultation des documents,
la diffusion des documents,
la conservation,
l'administration du systme.
Sur la base de ces informations, j'ai pu tablir une premire liste des cas d'utilisation, puis
au fur et mesure des runions, crire le scnario nominal de chaque cas d'utilisation et ses
extensions. Un exemple de cas d'utilisation obtenu est prsent dans le Tableau 10.
N4
Acteur
principal
Prconditions
Scnario
nominal
Crer un document
Crateur de documents
L'utilisateur est connect au systme.
1.
2.
3.
4.
5.
6.
7.
Extensions
L'utilisateur slectionne la fonction de cration d'un document.

L'utilisateur peut associer des fichiers. Il indique le fichier principal.
Le systme rcupre les mtadonnes (titre, crateur, date cration) du
fichier principal.
L'utilisateur modifie et complte les mtadonnes.
L'utilisateur peut associer un workflow au document.
L'utilisateur valide la cration du document.
Le systme enregistre le document (mtadonnes et fichiers ventuels).
6a. Les mtadonnes obligatoires ne sont pas toutes renseignes.

6a1. Le systme informe l'utilisateur sur les mtadonnes
manquantes.
6a2. L'utilisateur renseigne les mtadonnes manquantes.
Tableau 10 : Exemple de cas d'utilisation
Ces travaux ont permis d'obtenir les exigences fonctionnelles intgres l'expression
fonctionnelle de besoin. Ce document prend en compte galement les autres types
d'exigences.
Sabine Champenois
73/125
IV.2.1.2 Expression fonctionnelle du besoin

L'expression fonctionnelle du besoin (EFB) est un document constituant une rfrence des
besoins ou des exigences pour l'obtention d'un produit (voir Annexe 7 : Exigences selon la
norme NF X50-151 pour une expression fonctionnelle du besoin).
Mon rle a t d'tablir ce document l'aide du COUTIL et de le faire approuver par le
COUTIL et le COPIL.
L'EFB contient les rubriques suivantes :
dfinition globale du besoin,
dfinition des lments stratgiques du march cible et dbouch du produit,
mise en vidence des principes et concepts dj retenus,
description des fonctions assurer et des contraintes respecter.
La dfinition globale du besoin correspond l'nonc du contenu du projet dfini dans le

plan de management (voir IV.1.2.2). Le logiciel de GED doit pouvoir s'intgrer avec
d'autres applications existantes ou futures de l'entreprise.
La dfinition des lments stratgiques du march cible et dbouch du produit ne sont pas
applicables dans le cas du projet de GTT car l'acquisition de ce logiciel doit rpondre un
besoin et une utilisation interne l'entreprise.
Le seul principe retenu et qui limite les solutions du march est de ne pas avoir besoin
d'Internet pour utiliser l'application. En effet, le rseau de l'entreprise est spar d'Internet
et les utilisateurs n'ont pas accs Internet sur leur poste de travail. Cest un choix de
gestion des risques de piratage. Il aurait pu tre envisag de retenir une solution en SaaS
mais cela aurait conduit un changement darchitecture technique et il ne semblait pas
souhaitable dintroduire deux nouveauts techniques simultanment, lutilisation dun
nouveau logiciel et la construction dune architecture scurise. Par consquent, les
fournisseurs d'applications de GED de type SaaS (Software as a Service) ne seront donc
pas retenus.
Pour la dfinition des fonctions assurer pour le logiciel de GED, la granulomtrie choisit
doit permettre de dcrire toutes les fonctions ncessaires aux utilisateurs sans mettre en
avant une ergonomie ou une solution en particulier. Le cycle de vie du logiciel dans le
cadre du projet est sa mise en place et sa maintenance ; ne sont pas concernes les phases
de conception, de dveloppement et de retrait. Les interacteurs sont prsents tels que dans
le plan de management du projet (voir IV.1.2.1). La description des fonctions et
contraintes est tablie selon la mthode d'Alistair Cockburn (voir IV.2.1.1). Chaque
fonction possde un numro d'identification unique qui permettra son suivi, sa traabilit,
tout au long du projet (lors de l'appel d'offre, de l'valuation des solutions, de la rdaction
des spcifications fonctionnelles et des tests de vrification et de validation). Les fonctions
sont prsentes selon les thmes suivants : accs au systme, cration de documents,
gestion des documents, consultation et diffusion des documents, conservation des
documents et administration du systme. Pour chaque fonction, un critre d'apprciation
prcise si elle est indispensable ou non. Les variations possibles sont galement indiques.
Enfin, aucune contrainte particulire n'est identifie.
Sabine Champenois
74/125
L'expression fonctionnelle du besoin obtenue a t approuve par le COUTIL et le COPIL

et a permis d'alimenter les travaux de rdaction du cahier des charges fonctionnel.
IV.2.1.3 Cahier des charges fonctionnel
Le cahier des charges fonctionnel (CdCF) est un document construit partir de l'expression
fonctionnelle du besoin en termes de fonctions de service et de contraintes. C'est un outil
de dialogue entre le client et les fournisseurs du produit acqurir (voir Annexe 8 :
Exigences selon la norme NF X50-151 pour un cahier des charges fonctionnel).
Mon rle a t d'tablir ce document afin qu'il respecte le contenu dfinit par la norme
NF X50-151, puis de le faire approuver par le COUTIL et le COPIL.
L'ensemble des rubriques obligatoires est prsent dans le CdCF final. Ce document et
l'EFB constituent le dossier d'appel d'offre.
L'ensemble des points de contrle propos dans la norme ont t vrifi avant l'approbation
finale du document par le COUTIL puis le COPIL. Le CdCF approuv sert de base de
rfrence dans la suite du projet.
L'ensemble des travaux de recueil des exigences ont permis de rdiger l'expression
fonctionnelle de besoin et le cahier des charges fonctionnel. Ces deux documents vont
constituer le dossier pour l'appel d'offre.
IV.2.2 valuation du march
L'valuation du march des logiciels de GED a pour objectif d'tablir une liste de
fournisseurs pouvant rpondre l'appel d'offre.
Mon rle a t de raliser cette valuation assiste du responsable du Dpartement SI afin
d'tablir une liste de fournisseurs prslectionns pour l'appel d'offre.
Le salon Documation est un salon professionnel des acteurs de la GED qui a lieu tous les
ans. La visite de ce salon a t l'occasion de rencontrer des fournisseurs potentiels
pralablement slectionns via la visite de leur site sur Internet. Sur le salon, il a t
possible de rencontrer des commerciaux et de prsenter les besoins de GTT et parfois une
dmonstration du logiciel a pu tre faite. Cette premire prise de contact a permis
d'liminer des solutions non satisfaisantes pour GTT. De plus, cela a permis de constater
que de nombreux logiciels pouvaient rpondre pour la majorit des exigences de GTT.
Suite ce salon, des runions avec des fournisseurs potentiels ont permis d'avoir une
dmonstration dtaille et personnalise de leur produit. Ces runions ont permis de valider
que le logiciel pouvait rpondre aux principaux besoins de GTT et galement valider que le
cot d'acquisition tait en adquation avec le budget fix.
Suite ces runions, une liste de sept fournisseurs prslectionns a pu tre tablie. Lors de
l'activit suivante d'appel d'offre, ces fournisseurs ont t destinataires du dossier d'appel
d'offre.
Sabine Champenois
75/125
IV.2.3 Appel d'offre et slection du fournisseur

Les activits d'appel d'offre et de slection du fournisseur ont pour objectif, partir de la
liste des fournisseurs potentiels de slectionner le fournisseur ou les fournisseurs mme
de rpondre au mieux aux exigences de GTT (voir Annexe 9 : Activit "Acquisition
advertisement" selon la norme ISO/CEI 12207 et Annexe 10 : Activit "Supplier
selection" selon la norme ISO/CEI 12207).
Mon rle a t de grer cet appel d'offre jusqu' la slection du fournisseur, assiste du
COUTIL et du COPIL et cela en conformit avec les exigences de la norme ISO/CEI
12207.
Le dossier de l'appel d'offre est constitu de l'expression fonctionnelle du besoin et du
cahier des charges fonctionnel. Ces documents rassemblent l'ensemble des exigences de
GTT dans le cadre de son besoin d'acquisition d'un logiciel de GED et galement dcrit le
cadre de l'appel d'offre. Ces documents ont t adresss aux fournisseurs prslectionns
en leur prcisant la date souhaite de retour de leur offre.
Pendant la priode d'tablissement de la rponse commerciale, j'ai rpondu aux questions
que pouvaient se poser les fournisseurs sur le dossier d'appel d'offre.
A la date de retour des rponses commerciales, il s'est avr que deux fournisseurs n'ont
pas souhait rpondre.
Les documents reus des divers fournisseurs ont t collects et mis sur le rseau afin que
le COUTIL et le COPIL puissent en prendre connaissance et participer l'activit de
slection du fournisseur.
Dans le cadre de l'appel d'offre, une procdure de slection a t pralablement tablie afin
de dterminer comment se ferait ce choix. Cette procdure a t approuve par le COUTIL
et le COPIL qui devait participer la slection et donc l'application de cette procdure.
La premire tape a t de lire et d'valuer les offres crites reues des fournisseurs afin de
dterminer ceux qui pourraient faire une prsentation au COUTIL et au COPIL de leur
solution.
L'ensemble des documents reus des fournisseurs a t lu par le COUTIL et le COPIL. J'ai
tabli une grille de conformit entre les exigences dfinies dans l'expression fonctionnelle
du besoin et les rponses fournies. Cette grille reprenait de manire dtaille l'ensemble
des exigences de l'EFB. Le but tait d'valuer le taux de couverture des exigences. Il a
parfois t ncessaire d'changer avec les fournisseurs pour expliciter ou complter des
points de leur rponse.
Une grille de comparaison des cots et dlais a galement t tablie afin de pouvoir
effectuer un comparatif entre les fournisseurs.
A l'issue de cette tude, une runion avec le COUTIL a permis de dterminer un ordre de
prfrence entre les fournisseurs et de dterminer les points forts et faibles de chaque
solution propose. Sur la base de ces conclusions, le COPIL a choisi de conserver quatre
fournisseurs afin que ceux-ci viennent faire une dmonstration de leur solution propose.
Un seul fournisseur a donc t cart en raison du manque de dtails et d'implication dans
sa rponse.
Sabine Champenois
76/125
La deuxime tape a t d'organiser les soutenances.

Afin de pouvoir comparer objectivement les logiciels lors des soutenances, des scnarios
de dmonstration avec un jeu de donnes ont t adresss aux fournisseurs. L'objectif tait
d'avoir une base commune de fonctionnalits prsenter et reprsentatives de l'utilisation
future du logiciel de GED par GTT.
Chacun des quatre fournisseurs retenus pour une soutenance est venu faire une
dmonstration de son logiciel aux membres du COUTIL et du COPIL. Ces prsentations
ont t l'occasion de poser des questions prcises sur les fonctionnalits mais galement de
prendre connaissance de la mthodologie de mise en place propose par le fournisseur.
Ces soutenances ont permis de complter la grille de conformit aux exigences, la grille de
comparaison des cots et dlais et la liste des points forts et faibles de chaque solution.
Un contrle de la capacit financire effectu par le Directeur Administratif et Financier a
permis de vrifier la sant des fournisseurs potentiels.
A l'issue de ces soutenances, une runion du COUTIL a permis de dgager trois
fournisseurs rpondant quasiment tous les besoins de GTT mais galement dont
l'ergonomie de leur logiciel tait simple et conviviale. Cette liste finale a t approuve par
le COPIL. Pour dpartager ces socits, il a t dcid de rencontrer un de leur client pour
voir une mise en uvre concrte de leur produit. J'ai t charge avec le Responsable du
Dpartement Systme d'Information d'effectuer ces visites accompagne d'un membre du
COUTIL. Cela a permis de se rendre compte pour un cas concret de l'effort de mise en
place et des contraintes du produit dans le cadre de sa maintenance.
Ces visites ont permis de finaliser les points forts et faibles de chaque solution. De plus,
dans le cas d'un des fournisseurs, il s'est avr qu'il n'avait jamais mis en uvre le logiciel
qui tait une solution open source. La finale a donc oppos une solution robuste et
ancienne du march mais avec ses lourdeurs face une solution jeune, volutive mais avec
peu de clients. Pour ces fournisseurs, les cots et dlais de mise en place taient
sensiblement identiques.
La dernire phase a t ralise par la Direction Gnrale qui a ngoci les conditions
financires avec les deux fournisseurs pour dcider de contractualiser avec le moins cher.
La socit Cincom avec son logiciel Cincom ECM a donc t slectionne.
Ces activits d'appel d'offre et de slection d'un fournisseur ont permis de choisir la
solution la plus adapte et rpondant au mieux aux besoins de GTT. La suite a consist en
l'tablissement du contrat avec le fournisseur slectionn.
IV.2.4 Contractualisation
La contractualisation a pour objectif d'tablir et de signer le contrat entre GTT et Cincom
pour l'acquisition du logiciel de GED et sa mise en place (voir Annexe 11 : Activit
"Contract agreement" selon la norme ISO/CEI 12207).
Mon rle a t de grer cette activit selon les exigences de la norme ISO/CEI 12207 afin
d'aboutir un contrat satisfaisant GTT et Cincom.
Sabine Champenois
77/125
Le contrat est ngoci directement entre le fournisseur, Cincom, et GTT. Au sein de

l'entreprise, il n'y a pas de Dpartement Achats. Assist du Responsable du Dpartement
Systme d'Information, de la Dlgue Juridique et de la Direction Gnrale nous avons
tabli le contrat conjointement avec le fournisseur Cincom.
Le contrat contient les lments suivants :
le contrat de licence d'utilisation de logiciel,
le contrat de maintenance du logiciel,
le contrat cadre entre les deux socits prcisant les prestations, les livrables, les cots
et les dlais du projet de mise en place,
l'offre commerciale de Cincom,
l'expression fonctionnelle de besoin de GTT,
le cahier des charges de GTT.
L'ensemble du dossier de contrat a t relu et approuv par Dlgue Juridique avant d'tre
sign par les reprsentants des deux parties.
Pour le suivi des changements du contrat, il a t tabli que chaque demande serait tudie
en termes d'impact sur le projet puis ngocie entre les parties avant d'engendrer un
avenant au contrat sign par GTT et le fournisseur. Cela ne s'est pas produit dans le cadre
du projet.
A l'issu de la contractualisation qui a permis de dfinir le cadre de travail avec Cincom, la
phase de mise en place du logiciel a pu dbuter.
IV.3 Phase Mise en place du logiciel

La phase de mise en place a pour objectif de mettre en place le logiciel de GED, Cincom
ECM, selon le contrat sign entre les deux parties. Cette phase est dcoupe en activits
suivantes :
les ralisations du fournisseur comprenant la rdaction des spcifications fonctionnelles

afin de dterminer les paramtrages du produit raliser, la ralisation de ces
paramtrages, l'installation du logiciel et la dispense des formations,
le suivi du fournisseur en termes de cots, qualit et dlais,
la validation et la vrification du produit livr et suivi de la rsolution des problmes

jusqu' l'acceptation des livrables,
la mise en production du produit accept et la clture du contrat.
L'ensemble de ces activits sont dcrites ci-aprs.

IV.3.1 Ralisations de Cincom
Les ralisations de Cincom ont pour objectif la livraison du logiciel de GED paramtr
pour les besoins de GTT, l'installation de l'environnement de tests et de production et la
ralisation des formations prvues au titre du contrat.
Mon rle a t de suivre l'ensemble de ces ralisations afin d'atteindre les objectifs fixs
dans le contrat avec Cincom.
Sabine Champenois
78/125
L'tablissement de spcifications fonctionnelles a pour but de mettre en relation les

exigences de GTT avec la ralit des fonctionnalits du logiciel acquis.
J'ai assist Cincom dans la ralisation de cette tche. Sur la base de l'expression
fonctionnelle du besoin et de la documentation du logiciel, lors de runions de travail, il a
t dtermin les fonctions utiliser ou les paramtrages raliser pour rpondre chaque
exigence fonctionnelle exprime par GTT. J'ai approuv le document obtenu
conjointement avec Cincom.
Sur la base des spcifications fonctionnelles, Cincom a ralis les paramtrages afin que le
logiciel de GED rponde aux exigences de GTT. Ce logiciel a t install chez GTT avec
l'aide du responsable d'exploitation du Dpartement SI par Cincom sur un environnement
de tests et de production.
Dans le cadre du contrat, Cincom a d former les membres du COUTIL l'utilisation du
logiciel. Il a d galement former l'quipe d'exploitation du Dpartement Systme
d'Information l'administration du systme et une partie de l'quipe des dveloppeurs
son paramtrage.
J'ai suivi l'ensemble de ces ralisations et l'avancement du projet.
IV.3.2 Suivi du fournisseur
Le suivi du fournisseur a pour objectif de connatre l'avancement du projet pour la partie
ralise avec Cincom et d'changer avec lui sur tous les aspects du projet (voir Annexe 12 :
Activit "Agreement monitoring" selon la norme ISO/CEI 12207).
Mon rle a t de suivre Cincom afin qu'il respecte les engagements pris au titre du contrat
et en conformit avec les exigences de la norme ISO/CEI 12207.
Tout au long du projet des points d'avancement par crit ou tlphonique m'ont t fait par
Cincom. Ces points ont t l'occasion de discuter des problmes rencontrs afin de
dterminer les actions entreprendre pour les rsoudre. Les informations obtenues ont
permis d'alimenter les rapports d'avancement.
Les processus de revue et d'audit n'ont pas t mis en uvre dans le cadre du projet.
Toutefois chaque livrable du projet a t vrifi et valid selon les processus dfinis plus
loin. De plus, la fin de la rdaction des spcifications et la livraison du logiciel paramtr
ont donn lieu des runions entre GTT et Cincom afin d'approuver les livrables et de
dcider du dmarrage des activits suivantes.
L'activit de suivi du fournisseur est trs dpendante des processus de validation et
vrification prsents ci-aprs.
Sabine Champenois
79/125
IV.3.3 Vrification et validation

La livraison du logiciel de GED paramtr par Cincom ncessite un effort de vrification et
de validation avant de pouvoir mettre l'application en production. Les non-conformits
rencontres sont intgres un processus de rsolution des problmes. L'acceptation de
l'application est prononce suite la prise en compte de l'ensemble des non-conformits et
permet la mise disposition du logiciel l'ensemble des utilisateurs.
IV.3.3.1 Vrification
Le processus de vrification a pour objectif de confirmer par des preuves tangibles que les
exigences spcifies d'utilisation du logiciel sont satisfaites (voir Annexe 13 : Activit
"Software verification process" selon la norme ISO/CEI 12207).
Mon rle t de mettre en place une stratgie de vrification, de dfinir les critres de
vrification, de raliser cette vrification et d'enregistrer les problmes identifis et cela en
conformit avec les exigences de la norme ISO/CEI 12207.
Dans le cadre de l'implmentation du processus de vrification, aucun risque majeur n'a t
identifi. Cependant, le logiciel de GED est une application centrale de la production de
GTT. Des non-conformits bloquantes peuvent retarder des livraisons clients. Il est apparu
qu'un effort important de vrification devait tre mis en uvre. Du temps et des ressources
sont donc allous cette activit qui est ralise au sein de GTT.
J'ai ralis le processus de vrification tabli dans le cadre du projet. Les tches de ce
processus sont dcrites dans le plan de management du projet et intgres dans la gestion
des dlais et des cots. L'effort de vrification concerne principalement le respect des
exigences. Les aspects de vrification de la conception, du code et de l'intgration sont
raliss par Cincom.
Dans un premier temps, l'ensemble des exigences qui doivent tre traduites en
fonctionnalits dans le logiciel est list. Ce travail est ralis sur la base des cas
d'utilisation de l'expression fonctionnelle du besoin et des spcifications fonctionnelles et
permet l'tablissement du cahier de recette utilis dans le processus de validation.
Dans un deuxime temps, partir de cette liste, la prsence des fonctionnalits dans le
logiciel est contrle. L'ensemble de la documentation livre est vrifi afin que l'ensemble
des fonctionnalits soit dcrit de manire comprhensible par un utilisateur dbutant. A
chaque nouvelle livraison du logiciel ou de la documentation, le numro de version est
contrl afin de s'assurer qu'il est bien incrment. Afin de tester dans des conditions les
plus proches possibles des conditions relles, des membres du COUTIL ont galement
ralis des tests fonctionnels. Cela a permis de valider les aspects ergonomiques et la
facilit d'utilisation. Des tests de charge ont aussi t raliss.
Enfin, les non-conformits sont enregistres dans le processus de rsolution des problmes.
Elles sont traites par Cincom jusqu' correction et acceptation de GTT.
Ce processus de vrification a permis de contrler la conformit du logiciel par rapport aux
exigences spcifies. Ce processus a t ralis en mme temps que le processus de
validation.
Sabine Champenois
80/125
IV.3.3.2 Validation
Le processus de validation a pour objectif de confirmer par des preuves tangibles que les
exigences pour une utilisation spcifique du logiciel sont satisfaites. Les conditions
d'utilisation peuvent tre relles ou simules (voir Annexe 14 : Activit "Software
validation process" selon la norme ISO/CEI 12207).
Mon rle a t de mettre en place une stratgie de validation, de dfinir les critres de
validation, de raliser cette validation et d'enregistrer les problmes identifis et cela en
conformit avec les exigences de la norme ISO/CEI 12207.
Le logiciel de GED est une application centrale de la production de GTT, l'effort de
validation doit tre important. En effet, des non-conformits bloquantes peuvent ralentir la
productivit et retarder des livraisons clients. Du temps et des ressources sont donc allous
cette activit qui est ralise au sein de GTT.
J'ai ralis le processus de validation tabli dans le cadre du projet. Les tches de ce
processus sont dcrites dans le plan de management du projet et intgres dans la gestion
des dlais et des cots. L'effort de validation concerne les tests de l'ensemble des exigences
de l'expression fonctionnelle du besoin.
Dans un premier temps, l'ensemble des exigences est traduit en scnario de test dans le
logiciel. Ce travail est ralis sur la base des cas d'utilisation de l'expression fonctionnelle
du besoin et des spcifications fonctionnelles et sert de base l'tablissement du cahier de
recette. Les cas particuliers et les cas d'erreurs provenant des cas d'utilisation ont t
intgrs au cahier de recette Un jeu d'essai bas sur des donnes relles est galement
prpar ainsi qu'un environnement de test identique l'environnement de production.
Dans un deuxime temps, partir du cahier de recette, chaque cas de test et donc chaque
fonctionnalit sont contrls. A chaque nouvelle livraison du logiciel, l'ensemble du cahier
de recette est rejou. Afin de tester dans des conditions les plus proches possibles des
conditions relles, des membres du COUTIL ont galement ralis des tests.
Enfin, les non-conformits sont enregistres dans le processus de rsolution des problmes.
Elles sont traites par Cincom jusqu' correction et acceptation de GTT. L'avancement des
tests est donn chaque semaine dans le rapport d'avancement.
Ce processus de validation a permis de contrler les fonctionnalits du logiciel par rapport
aux exigences spcifies. Ce processus a t ralis en mme temps que le processus de
vrification. L'ensemble des non-conformits dtectes lors de ces deux processus sont
gres dans le processus de rsolution des problmes.
Sabine Champenois
81/125
IV.3.3.3 Rsolution des problmes

Le processus de rsolution des problmes logiciel a pour objectif d'assurer que tous les
problmes rencontrs sont identifis, analyss, grs et contrls jusqu' leur rsolution
(voir Annexe 15 : Activit "Software Problem Resolution Process" selon la norme
ISO/CEI 12207).
Mon rle a t de mettre en place une stratgie de rsolution des problmes, d'enregistrer et
de suivre l'analyse de ces problmes, l'identification des solutions et la mise en uvre des
rsolutions par Cincom et ce jusqu' la clture du problme et cela en conformit avec les
exigences de la norme ISO/CEI 12207.
J'ai ralis le processus de rsolution des problmes tabli dans le cadre du plan de
management du projet conjointement avec Cincom.
Suite aux processus de vrification et de validation, chaque non-conformit dtecte
(anomalie, question, exigence manquante ou non-conforme) est dcrite dans un fichier
des remontes. Dans ce fichier, on retrouve les informations suivantes :
numro de la remonte,
description de la remonte (ajout de capture d'crans et fournitures du jeu d'essai utilis

si ncessaire pour la comprhension),
date d'ouverture,
auteur,
priorit : basse, moyenne ou haute,
bloquant ou non pour la mise en production,
type de remonte : bug, demande d'volution, utilisation, question,
analyse des causes,
solutions proposes,
date de rsolution,
statut : ouvert, analyse en cours, corrig, volution non traite, test en cours, clos,
date de clture.
Conjointement avec le responsable du Dpartement Systme d'Information, nous avons

vrifi que les anomalies sont reproductibles puis nous avons donn un niveau de priorit
et indiqu si la remonte tait bloquante pour la mise en production.
Le fichier est chang intervalle rgulier (plusieurs fois par semaine) avec Cincom.
Celui-ci le complte avec son analyse des causes, les ventuelles solutions proposes et la
date prvisionnelle de rsolution.
Sabine Champenois
82/125
GTT pour les remontes ouvertes, valide la solution propose et pour les remontes
rsolues, teste que la correction est bien effective la livraison suivante et qu'il n'y a pas de
rgression et clos la remonte. En cas de rgression, la remonte est rouverte ou de
nouvelles remontes peuvent tre galement cres dans le fichier.
Lorsque cela est ncessaire, les remontes sont discutes avec Cincom lors des runions
d'avancement hebdomadaire. L'objectif est d'expliciter la remonte ou de la reproduire
dans le contexte de GTT ou bien de discuter de la solution adopter ou enfin, dans le cas
d'une volution de valider les impacts et de dcider de sa ralisation.
L'avancement du traitement des remontes est indiqu dans le rapport d'avancement
hebdomadaire.
La vrification et la validation sont approuves aprs le complet traitement et la clture de
toutes les remontes ce qui va permettre de traiter l'acceptation du logiciel de GED.
IV.3.3.4 Acceptation
L'acceptation a pour objectif que l'acqureur accepte le produit livr par le fournisseur
(voir Annexe 16 : Activit "Acquirer acceptance" selon la norme ISO/CEI 12207).
Mon rle a t d'aboutir l'acceptation du produit livr selon les exigences de la norme
ISO/CEI 12207
Dans le cadre du projet, les critres d'acceptation sont que toutes les exigences de
l'expression fonctionnelle de besoin et que tous les paramtrages dfinis dans les
spcifications fonctionnelles sont inclus dans le produit livr. De plus, aucune anomalie de
fonctionnement du produit ne doit avoir t dtecte ou non corrige.
L'ensemble des contrles et tests raliss dans le cadre des processus de vrification et
validation a permis d'accepter le produit. En effet, toutes les remontes ont t closes dans
le cadre de la rsolution des problmes. GTT a donc prononc l'acceptation de la livraison
du logiciel de GED.
Le produit Cincom ECM tant sur tagre, GTT n'a pas grer la configuration du produit.
Cela est effectu par Cincom dans le cadre du contrat de maintenance pour les livraisons
des mises jour.
Suite l'acceptation du logiciel, GTT a pu le mettre en production et clore le contrat avec
le fournisseur.
Sabine Champenois
83/125
IV.3.4 Clture du contrat

La clture du contrat a pour objectif de contrler que toutes les prestations ont t ralises
et son conformes dans le cadre du contrat avec un fournisseur (voir Annexe 17 : Activit
"Closure" selon la norme ISO/CEI 12207).
Mon rle a t de conduire cette activit selon les exigences de la norme ISO/CEI 12207
Suite l'acceptation du produit, GTT a honor les cls de facturation dfinies au titre du
contrat c'est--dire que j'ai inform le Dpartement Finances lors de la prsentation de la
facture qu'elle pouvait tre paye car le produit a t livr conformment au contrat.
De plus, une runion de clture avec Cincom a permis de faire le bilan du projet et de
capitaliser les retours d'exprience pour les prochains contrats avec ce fournisseur mais
aussi pour d'autres projets. Lors de cette runion, la clture est prononce et documente
dans le compte-rendu de runion.
Cette dernire tape du projet permet de dclarer qu'il est termin.
La phase de mise en place a consist en un suivi des ralisations de Cincom puis en une
vrification et une validation du logiciel livr jusqu' obtenir que tous les problmes soient
rsolus et par consquent, pouvoir clore le projet et mettre en production le logiciel de
GED.
Pour l'ensemble des processus mis en uvre dans le cadre de ce projet, une valuation
l'aide du CMMI a t ralise afin de dterminer les voies d'amlioration possibles.
IV.4 Phase Amlioration

L'objectif de la phase d'amlioration est d'valuer les processus mis en uvre dans le cadre
du projet l'aide de la reprsentation continue du CMMI [5] et de dterminer les voies
d'amlioration possibles. L'objectif n'est pas d'atteindre un niveau d'aptitude. En effet, seul
le niveau 1, basique, pourrait tre obtenu puisque aucun processus n'est tabli de manire
globale tous les projets au sein de GTT.
Les domaines de processus slectionns sont la planification de projet, la surveillance et le
contrle du projet, la gestion des accords avec les fournisseurs, la gestion des risques, la
vrification et la validation.
Pour chacun de ces domaines, son intention est prsente, les noncs des objectifs et des
pratiques spcifiques sont repris. Pour chaque objectif et pratique, mon rle a t de faire
une valuation sur la base de la ralisation concrte ou non des exigences demandes par le
CMMI. Puis, lorsque cela est ncessaire, les amliorations mettre en uvre sont dcrites.
IV.4.1 Planification de projet
L'intention du domaine de processus "Planification de projet" est d'tablir et maintenir les
plans qui dfinissent les activits du projet.
Sabine Champenois
84/125
Le Tableau 11 rcapitule les objectifs et pratiques gnriques de ce domaine de processus,

les valuations et les voies d'amliorations.
Objectifs
spcifiques
tablir les
estimations
Dvelopper
un plan de
projet
Pratiques spcifiques
valuation
Faire lestimation de la
porte du projet
Fait avec la structure de

dcoupage du projet et
son dictionnaire
Fait avec la gestion des
dlais et des cots
Aucune
Fait avec la structure de

dcoupage du projet et
la gestion des dlais
dlais et des cots
Aucune
tablir les estimations

des attributs des
produits dactivit et
des tches
Dfinir le cycle de vie
du projet
Dterminer les
estimations de charge
et de cot
Amlioration
Aucune
Capitaliser les
estimations des projets
afin de pouvoir utiliser
ces donnes pour les
projets venir
Utiliser les donnes
provenant de la
comptabilit analytique
nouvellement en place
Aucune
tablir le budget et le
calendrier
Identifier les risques du
projet
Prvoir la gestion des
donnes

dlais et des cots
risques
communications
Prvoir les ressources

du projet

dlais et le planning
Microsoft Project
Utilisation des outils RH Aucune
de GTT
Prvoir les
connaissances et
aptitudes ncessaires
Prvoir limplication
des parties prenantes
Fait avec l'organisation

du projet et la gestion
des communications
tablir le plan de projet Fait avec le plan de

management du projet
Sabine Champenois
Voir le processus
gestion des risques
tablir en dbut de
projet la liste des
donnes grer avec
leur format, le contenu
et le niveau de
confidentialit
Utiliser le logiciel de
GED pour amliorer
l'accs aux donnes
Aucune
Formaliser les
interactions sous forme
d'une matrice avec les
parties prenantes et les
activits
Aucune
85/125
Objectifs
spcifiques
Passer en revue les

plans qui ont des
rpercussions sur le
projet
Concilier les niveaux
Obtenir
de charge et de
lengagement
ressources
sur le plan
Obtenir lengagement
au plan
valuation
Amlioration
Fait par le responsable

qualit et le reprsentant
du COPIL
Aucune
Fait avec le rapport

d'avancement et la
gestion des
modifications
Fait partiellement
Aucune
Exiger un engagement
de toutes les parties
prenantes au plan de
management du projet
Tableau 11 : Bilan du domaine de processus "Planification de projet" du CMMI
IV.4.2 Surveillance et contrle du projet

L'intention du domaine de processus "Surveillance et contrle du projet" est de fournir une
apprciation de l'avancement du projet, de telle sorte que des actions correctives puissent
tre prises quand la performance du projet s'carte de faon significative du plan.
Sabine Champenois
86/125

Objectifs
spcifiques
Surveiller les
paramtres de
planification de projet
Surveiller les
engagements
Surveiller les risques du

projet
Surveiller le
projet par
rapport au
plan
Surveiller la gestion des

donnes

d'avancement et la
gestion des
modifications
d'avancement et la
gestion des
modifications
d'avancement et la
gestion des
modifications
Fait partiellement
Surveiller limplication
des parties prenantes
Fait partiellement
Mener des revues

davancement

d'avancement et la
gestion des
communications
Fait partiellement
Mener des revues sur

jalons
Analyser les carts
Grer
laction
corrective
jusqu
clture
valuation
Appliquer une action

corrective
Grer une action

corrective

modifications et la
rsolution des
problmes
modifications et la
rsolution des
problmes
Fait partiellement avec
le rapport d'avancement,
la gestion des
modifications et la
rsolution des
problmes
Amlioration
Surveiller les
connaissances et les
comptences du
personnel du projet
Aucune
Aucune
Formaliser des revues

rgulires de la liste des
donnes grer
rgulires de
l'implication des parties
prenantes
Aucune

chaque jalon du projet
Aucune
Aucune
Analyser les rsultats

des actions correctives
pour mesurer leur
efficacit
Capitaliser les retours
d'exprience sur les
actions appropries en
fonction des carts
Tableau 12 : Bilan du domaine de processus "Surveillance et contrle du projet" du CMMI
Sabine Champenois
87/125
IV.4.3 Gestion des accords avec les fournisseurs

L'intention du domaine de processus "Gestion des accords avec les fournisseurs" est de
grer l'acquisition des produits des fournisseurs.
Objectifs
spcifiques
tablir les
accords
avec les
fournisseurs
valuation
Dterminer le type
dacquisition
Choisir des fournisseurs
Fait avec l'expression

fonctionnelle du besoin
Fait avec l'valuation du
march, l'appel d'offre et
la slection du
fournisseur
Fait avec la
contractualisation
Fait avec le suivi du
fournisseur
tablir des accords avec

le fournisseur
Excuter laccord avec
le fournisseur
Se
conformer
aux accords
avec les
fournisseurs
Surveiller des processus

slectionns chez le
fournisseur
Non fait
valuer des produits

d'activits slectionns
chez le fournisseur
Accepter le produit
acquis
Non applicable car le

livrable est un logiciel
paramtr
Fait avec la vrification,
la validation et
l'acceptation
Fait avec l'installation et
la formation des
administrateurs et
exploitants
Transfrer les produits
Amlioration
Aucune
Aucune
Aucune
Imposer au fournisseur
des comptes-rendus
d'avancement
frquence rgulire
A envisager notamment
pour les processus de
gestion de projet et de
surveillance et de
contrle du projet
Aucune
Aucune
Aucune
Tableau 13 : Bilan du domaine de processus "Gestion des accords avec les fournisseurs" du CMMI
Sabine Champenois
88/125
IV.4.4 Gestion des risques

L'intention du domaine de processus "Gestion des risques" est d'identifier des problmes
potentiels avant qu'ils ne surviennent, de telle sorte que les activits pour traiter les risques
puissent tre planifies et dclenches au besoin tout au long de la vie du produit ou du
projet afin que les impacts nuisibles l'atteinte des objectifs soient attnus.
Objectifs
spcifiques
Se prparer
pour la
gestion des
risques
Identifier et
analyser les
risques
Attnuer les
risques
valuation
Amlioration
Dterminer les sources

et les catgories de
risques
Dfinir les paramtres
des risques

risques
Aucune

risques
tablir une stratgie de

gestion des risques
Identifier les risques

risques
risques et le rapport
d'avancement
Dfinir des valeurs de

seuils pour certaines
catgories de risques
Aucune
valuer, catgoriser et
prioriser les risques

d'avancement
Dvelopper les plans

dattnuation des
risques
Mettre en uvre les
plans dattnuation des
risques

risques
d'avancement
Impliquer les parties

prenantes dont le
fournisseur
Faire au moins une
runion ddie en dbut
de projet et aborder le
sujet rgulirement lors
des autres runions
Impliquer les parties
prenantes dont le
fournisseur.
Utiliser un outil
standardis d'analyse
des risques (prvu dans
le plan qualit 2011)
Faire une analyse
quantitative des risques
Aucune
Aucune
Tableau 14 : Bilan du domaine de processus "Gestion des risques" du CMMI
Sabine Champenois
89/125
IV.4.5 Vrification
L'intention du domaine de processus "Vrification" est de s'assurer que les produits
d'activit slectionns respectent les exigences spcifies qui les concernent.
Objectifs
spcifiques
Se prparer
la
vrification
Raliser des
revues par
les pairs
valuation
Amlioration
Slectionner les produits

dactivit en vue de la
vrification
tablir lenvironnement
de vrification
tablir les procdures et
les critres de
vrification
Prparer les revues par
les pairs
Fait avec la vrification
Impliquer le fournisseur
Aucune
Aucune
Mener les revues par les

pairs
Analyser les donnes
des revues par les pairs
Formaliser et
gnraliser les revues
par les pairs
Aucune
Raliser la vrification
Vrifier les
produits
dactivit
slectionns
Analyser les rsultats de

la vrification

et la rsolution des
problmes
et la rsolution des
problmes
et la rsolution des
problmes
Aucune
Aucune
Aucune
Tableau 15 : Bilan du domaine de processus "Vrification" du CMMI
Sabine Champenois
90/125
IV.4.6 Validation
L'intention du domaine de processus "Validation" est de dmontrer qu'un produit ou un
composant de produit satisfait l'utilisation prvue lorsqu'il est plac dans l'environnement
cible.
Objectifs
spcifiques
Se prparer
pour la
validation
Valider le
produit ou
les
composants
de produit
Slectionner les produits
valider
tablir lenvironnement
de validation
tablir des procdures et
des critres de
validation
Raliser la validation
Analyser les rsultats

des activits de
validation
valuation
Amlioration
Fait avec la validation
Impliquer le fournisseur
Aucune
Aucune
Fait avec la validation et Aucune

la rsolution des
problmes
Fait avec la validation et Aucune
la rsolution des
problmes
Tableau 16 : Bilan du domaine de processus "Validation" du CMMI
L'ensemble des amliorations identifies prcdemment sera men dans le cadre des
prochains projets du Dpartement Systme d'Information. L'objectif, terme, serait
d'atteindre un niveau d'aptitude 2, disciplin, pour les processus de planification de projet,
de surveillance et de contrle du projet, de gestion des accords avec les fournisseurs, de
gestion des risques, de vrification et de validation.
L'identification et la mise en uvre de mthodes de travail dans le cadre du projet
d'acquisition et de mise en place d'un logiciel de GED ont permis d'tablir le plan de
management de projet et de raliser ainsi l'ensemble des activits du projet. La phase
d'acquisition a abouti la contractualisation avec un fournisseur de logiciel de GED. La
phase de mise en place s'est finalise avec la mise en production du logiciel. Enfin, une
valuation des processus mis en uvre permettra d'apporter des amliorations lors des
prochains projets du Dpartement Systme d'Information et d'tablir un cadre de travail
commun tous les projets.
La russite du projet est prsente dans la partie suivante avec son bilan global.
Sabine Champenois
91/125
V Bilan
Le bilan du projet apporte une vue en termes de cot, qualit, fonctionnalits et dlais. Le
bilan technique traite de l'utilisation, de la fiabilit, de la performance, de l'administration
et de l'volutivit de l'application mise en place. Le bilan organisationnel montre les
apports du projet pour l'entreprise et ses salaris du point de vue humain et des nouveaux
processus de travail mis en place. Enfin, un bilan global permet de mettre en vidence les
points forts du projet et les axes d'amlioration mais galement de prsenter les projets qui
dcouleront de cette acquisition et mise en place d'un logiciel de GED. Pour complter ces
diffrents bilans, je prsenterai ce que m'a apport ce projet.
V.1
Bilan du projet
Sil ny avait quun objectif impos par la Direction, celui de bonne fin du projet avec la
mise en place dun processus de travail nouveau sappuyant sur un logiciel de GED, jai
nanmoins fait des estimations initiales sur le budget et les dlais de mise en service.
En termes de cots, le rcapitulatif du budget fix et des dpenses est prsent dans le
Tableau 17.
Type
Ressources humaines
Achats
Prvu
350 550 jours/homme
200 000 400 000
Rel
470 jours/homme
135 000
Tableau 17 : Bilan des cots du projet
Le temps pass en interne par le personnel est rest dans la tranche prvue. Pour les
dpenses, elles ont t galement moindres que prvues. Une bonne ngociation au
moment de la contractualisation avec le fournisseur a permis de faire baisser les cots.
En termes de dlais, le rcapitulatif des objectifs fixs avec le rel est prsent dans le
Tableau 18.
Type
Dossier d'appel d'offre
Slection du fournisseur et
contractualisation
Mise en production de l'application
Prvu
Fin juin 2009
Octobre 2009
Rel
Dbut juillet 2009
Dcembre 2009
Juin 2010
Dcembre 2010
Tableau 18 : Bilan des dlais du projet
La Direction Gnrale de GTT avait peu d'exigences en termes de dlais mme si une mise
disposition de l'application la plus rapide possible tait souhaite. L encore j'ai ralis
une estimation et ainsi fix des dlais au dbut du projet.
Le dossier d'appel d'offre n'a pris qu'un mois de retard en raison principalement au dlai
d'organisation des runions pour la validation finale. Ce retard est peu significatif par
rapport aux autres retards.
La slection du fournisseur a pris plus de temps que prvu. En effet, le processus d'tude
des offres, l'organisation des soutenances et la slection finale est un processus long qui
ncessite d'organiser de nombreuses runions avec les problmes inhrents la
disponibilit de chacun.
Sabine Champenois
92/125
Le retard le plus important est de 6 mois pour la mise en production de l'application. Ce

retard s'explique par plusieurs facteurs. La rdaction des spcifications techniques avec le
fournisseur a ncessit 3 semaines supplmentaires. Bien que le besoin de GTT soit trs
dtaill, l'analyse de ce besoin et sa mise en uvre dans la solution retenue a impliqu un
temps supplmentaire. L'offre par le fournisseur tait base sur sa nouvelle version
d'application qui devait sortir dbut mars. Or, la sortie de cette nouvelle version a eu lieu
en juin. La livraison de l'application a donc eu lieu dbut juillet au lieu de mai (soit 2 mois
de retard). La phase suivante tait la ralisation de tests mais en cette priode estivale les
chefs de projet GTT et ct fournisseur ont t peu prsents en raison des congs. De
plus, j'tais trs prise par un autre projet et n'ai pu tre rellement libre pour raliser les
tests qu' partir de mi-septembre. Lors de cette phase de tests, de trs nombreuses
remontes ont t dcouvertes. Elles ont ncessit deux nouvelles livraisons et chaque
fois la ralisation de l'intgralit des tests. C'est donc principalement cette phase de
validation et de vrification qui a le plus impact dans les retards du projet (plus de 3 mois
de retard).
En termes de qualit, les objectifs sur la phase d'acquisition tait l'approbation du dossier
d'appel d'offre et pour la phase de mise en place, la validation et la vrification avec succs
de l'application afin de pouvoir la mettre en production.
L'approbation du dossier d'appel d'offre ne fut qu'une formalit car tout au long du projet
les documents ont t construits avec l'aide du COUTIL, les points posant problmes
rgulirement remonts au COPIL et les dcisions prises au fur et mesure.
La validation et la vrification ont engendr beaucoup de remontes dans le processus de
rsolution des problmes. Plusieurs facteurs peuvent expliquer cela. Le produit choisi par
GTT est jeune et install chez peu de clients. GTT sest avr tre le premier client de la
nouvelle version donc aucune remonte client n'avait eu lieu. Grce la mthode employe
pour l'expression fonctionnelle de besoin j'ai pu construire un cahier de recette exhaustif et
ainsi tester toutes les fonctionnalits.
Au final, l'application mise en production tait exempte d'anomalies bloquantes. Quelques
non-conformits subsistaient mais ne gnaient en rien les utilisateurs et seront corriges
lors de la livraison de la version suivante.
En termes de fonctionnalits, le rcapitulatif des souhaits exprims dans l'EFB et du ralis
est prsent dans le Tableau 19.
Fonctions souhaites
Bilan
Cration de documents
Gestion des documents
Consultation et diffusion des
documents
Conservation des documents
Fonctions d'administration
Ralis sauf :
l'import en masse de l'existant
Ralis sauf :
les rapports (fonction prsente mais non mise en uvre)
Ralis
Non ralis mais prvu au titre d'un autre projet
Ralis sauf :
l'outil d'import des plans provenant de l'outil de CAO
Tableau 19 : Bilan des fonctionnalits implmentes
Sabine Champenois
93/125
Le produit choisi par GTT rpondait l'ensemble des exigences tablies. Au moment de la
mise en place, il a t choisi de limiter le primtre afin d'acclrer la mise en production
et de ne pas trop complexifier l'usage de l'application vis--vis des utilisateurs. Ainsi, le
systme d'archivage, la reprise de l'existant, l'import des plans provenant de SolidWorks
PDM, la mise en uvre des workflows de demande d'essai et de gestion des
modifications de la conception n'ont pas t mis en uvre. Ils feront l'objet de nouveaux
projets. galement, aucun rapport n'a t paramtr mais les quipes de GTT ont t
formes et sont aptes les paramtrer.
Le bilan du projet en termes de cots, de qualit et de fonctionnalits est conforme aux
attentes. Seuls les dlais ont t notablement allongs ; principalement en raison d'une trs
longue phase de validation et de vrification. Cela a toutefois permis d'assurer une bonne
qualit l'application mise en production. Ce bilan est complt par un bilan technique.
V.2
Bilan technique
Le bilan technique a pour but de vrifier que les objectifs en termes d'utilisation, de
fiabilit, de performance, d'administration et d'volutivit ont t atteints et d'analyser les
ventuelles drives.
Le COUTIL a t form et au travers des questionnaires de satisfaction qu'ils ont remplis,
aucune difficult n'a t signale. De plus, certains n'ont pas souhait suivre la formation et
ont utilis le logiciel sans aide. L'ergonomie et la prise en main sont donc aises. De plus,
le COUTIL est satisfait des fonctionnalits apportes par un tel outil. L'organisation et
l'accs aux documents sont facilits.
La fiabilit est vrifie par le nombre d'anomalies remontes suite la mise en production.
Celles-ci sont peu nombreuses et non bloquantes ce jour.
La performance de l'application est bonne. Cependant lors de la premire connexion, le
chargement des premires pages est un peu long.
Les outils d'administration proposs sont simples d'utilisation. De plus, la formation des
administrateurs permet lors autonomie. Des jours d'accompagnement provisionns
permettront au fournisseur d'assister GTT en cas de questions ou problmes.
L'volutivit de l'application est possible en interne GTT grce la formation de trois
dveloppeurs. Lors des six premiers mois de mise en production, aucune demande de
modifications des paramtrages existants ne sera prise en compte, seules des amliorations
seront mises en uvre. En outre, les fonctionnalits non mises en uvre (reprise de
l'existant, traitement des demandes d'essai) seront ralises sous forme d'volutions dans
le cadre de nouveaux projets. Les demandes d'volution sont capitalises dans un fichier de
suivi. Leur faisabilit est analyse et leur ralisation est accepte par le chef de projet, le
COUTIL ou le COPIL en fonction de la demande. Enfin, la demande d'volution est
ralise, teste et mise en production.
Sabine Champenois
94/125
Le bilan technique du projet en termes d'utilisation, de fiabilit, de performance,

d'administration et d'volutivit est globalement conforme aux attentes. Quelques
anomalies ont t rencontres suite la mise en production et quelques lenteurs ont t
constates mais rien de bloquant. Quelques mois supplmentaires d'utilisation en
production pourront confirmer cela. Ce bilan est complt par un bilan organisationnel.
V.3
Bilan organisationnel
Le bilan organisationnel a pour but de faire un tat des lieux des apports du projet pour
l'ensemble de l'entreprise.
Tout d'abord, en terme humain, ds le dbut du projet, au travers du COUTIL, l'ensemble
de l'entreprise s'est mobilis pour la mise en place du logiciel de GED. Directement ou
indirectement, chacun a particip l'expression de besoin. A chaque phase importante du
projet, une communication l'ensemble du personnel a t donne. En fin de projet, des
prsentations de l'application qui allait tre mise en place ont permis chacun
d'apprhender les nouveaux modes de fonctionnement qui allaient tre mis en uvre pour
la gestion des documents.
En parallle de la phase de mise en place du logiciel, un projet de certification la norme
ISO 9001 a t lanc sur l'anne 2010. Le travail ralis a permis d'tablir l'ensemble des
processus de l'entreprise ainsi qu'une procdure de matrise documentaire. Ces travaux ont
permis de figer un certain nombre de rgles de base dfini par le COUTIL lors des travaux
de recueil des exigences et mis en uvre dans l'outil de GED ; et cela tout en rpondant
aux exigences de la norme.
La mise en place de workflows de validation a permis d'automatiser l'approbation et la
signature des documents et ainsi de rduire cette phase dans la production des documents.
En effet, la possibilit de dfinir des dures limites couples des rappels aux acteurs en
cas de retard a contribu cela. galement, les visas ne sont plus obligatoires pour obtenir
l'approbation du document et pass le temps imparti, le document passe l'tape suivante
ce qui rduit fortement les dlais de production et supprime une partie des blocages
rencontrs.
Le workflow des TF permet de connatre pour chaque version de documents, les livraisons
effectues et les destinataires concerns ce qui n'tait pas le cas avant la mise en place du
logiciel de GED.
Au niveau technique, la mise en place d'une architecture base sur des serveurs virtuels a
permis l'quipe d'exploitation de monter en comptences sur ce sujet et ainsi de matriser
la mise en uvre de ce type d'architecture l'avenir.
Enfin, l'utilisation de normes et mthodes dans le cadre de ce projet constitue une premire
et une rfrence pour les projets venir. Le bilan tant positif, on peut dmontrer que
l'usage de ces bonnes pratiques contribue la russite du projet.
Sabine Champenois
95/125
La mise en place d'un tel outil commun l'ensemble d'une entreprise a permis de mobiliser
l'ensemble des salaris mais surtout d'amliorer sa production de documents, leur
consultation et leur diffusion et cela de manire centralise par un outil unique.
L'application de GED est devenue un outil usage et quotidien pour tous. Ce bilan est
complt par un bilan global.
V.4
Bilan global
Le bilan global a pour but de mettre en avant les points forts, les amliorations et les suites
possibles du projet.
Les points forts portent sur la mthode utilise pour rdiger l'expression fonctionnelle de
besoin, le COUTIL et le mode de slection de la solution et de son fournisseur.
La mthode mise en uvre pour le recueil des exigences a permis d'tre exhaustif et de
rassembler l'ensemble du COUTIL et du COPIL sur la mme base d'exigences. Le
document obtenu et surtout son format a permis d'tablir un cahier de recette complet de
l'ensemble des fonctionnalits et ainsi de raliser des tests de vrification et de validation
exhaustifs.
L'implication de l'ensemble des membres du COUTIL tout au long du projet a permis de
donner une bonne dynamique et ses membres furent et restent de bons relais de
communication au sein des quipes en interne. Cette instance parat indispensable pour un
projet transverse impactant toutes les Directions d'une entreprise.
Le mode d'valuation bas sur les principes d'appel d'offre des marchs publics est un bon
moyen de faire un choix sur la base de critres objectifs et d'aboutir une dcision justifie
et incontestable au sein de l'entreprise. En effet, les membres du COUTIL et du COPIL ont
particip au dpouillement et aux soutenances. Ils ont pu donner leur avis et participer au
choix final. L'outil ainsi mis en place devient un choix collectif, accept de tous, et par
consquent peu discutable ou remis en cause.
Enfin, l'architecture technique base sur des serveurs virtuels permet d'assurer une trs
bonne disponibilit.
Les amliorations portent sur la planification, la surveillance et le contrle du projet, le
suivi du fournisseur, la gestion des risques, la vrification et la validation. La majorit de
ces points ont pu tre identifis grce l'valuation faite avec le CMMI (voir IV.4).
Pour amliorer les estimations faites lors de la planification, les estimations des projets
doivent tre capitalises afin de pouvoir utiliser ces donnes pour les projets venir. Les
donnes provenant de la comptabilit analytique nouvellement mise en place vont
galement pouvoir contribuer cela. De plus lors de l'tablissement du plan de
management, il faut tablir la liste des donnes grer avec leur format, leur contenu et
leur niveau de confidentialit, prvoir d'utiliser le logiciel de GED pour amliorer l'accs
aux documents et formaliser l'implication des parties prenantes sous forme d'une matrice
entre les parties prenantes et les activits du projet. Enfin, un engagement de toutes les
parties prenantes au plan de management du projet est ncessaire la bonne mise en uvre
du plan lors du droulement du projet.
Sabine Champenois
96/125
Pour la surveillance et le contrle du projet, il est important de surveiller les connaissances

et les comptences du personnel du projet. De plus, un certain nombre de revues doivent
tre formalises dans le plan de management du projet. Elles portent sur la liste des
donnes grer, l'implication des parties prenantes et les jalons du projet. Enfin, les
rsultats des actions correctives mises en uvre doivent tre analyss pour mesurer leur
efficacit et capitaliser des retours d'exprience sur les actions appropries en fonction des
carts.
Le suivi d'un fournisseur, mme si un certain nombre d'exigences sont contractualiss et
demandes en dbut de projet, n'est pas chose aise. Les chefs de projets des deux parties
n'ont pas les mmes visions, ni les mmes objectifs. En tant que client, les exigences
doivent souvent tre rappeles et contrles. Les informations concernant les avancements
doivent tre exiges et tudies afin de ne pas avoir de mauvaises surprises. Pour les
prochains projets, lors de la runion de lancement, je demanderai des points d'avancement
rguliers par crit et ferai avec le fournisseur une analyse des risques afin de bien identifier
les problmes pouvant tre rencontrs et leurs impacts. Idalement la ralisation d'audit
chez le fournisseur peut permettre de surveiller ses processus et ainsi d'anticiper des
problmes de qualit.
Au niveau de la gestion des risques, en complment des valuations ralises, il apparat
important de dfinir des valeurs de seuils pour certaines catgories de risques et ainsi
dclencher des alertes lorsque ces seuils sont dpasss. Il apparat galement ncessaire
d'impliquer toutes les parties prenantes dont le fournisseur et de faire au moins une runion
ddie en dbut du projet et d'aborder ce sujet rgulirement lors des autres runions. La
mise en place d'un outil standardis d'analyse des risques et leur analyse quantitative peut
galement permettre d'amliorer la gestion des risques des projets.
La vrification et la validation ncessitent d'impliquer le fournisseur lors de la phase de
prparation afin de lui prsenter la mthode utilise et le cahier de recette et ainsi le niveau
de qualit attendu par GTT. La ralisation des tests et le suivi de la rsolution des
problmes est une tche importante et longue du projet. Ces tches ne doivent pas tre
ngliges et du temps spcifique doit tre allou ainsi qu'une bonne disponibilit du chef
de projet doit tre prvue sur cette priode. En complment de cela, une analyse conjointe
entre le client et le fournisseur de chaque problme doit tre faite en runion afin de
s'assurer de la bonne comprhension et de la reproductibilit ou des conditions de
reproductibilit de l'anomalie. Ces bases doivent permettre lors des prochains projets
d'assurer une efficacit du traitement des anomalies et ainsi d'esprer une diminution des
dlais de traitements. Enfin, formaliser et gnraliser des revues par les pairs pour la
vrification peut galement tre un facteur favorisant la qualit du produit.
A ce jour plusieurs suites possibles sont envisages pour complter la mise en place du
logiciel de GED.
Cette mise en production du logiciel doit tre accompagne d'un dploiement progressif au
sein de l'entreprise. Les quipes de chaque Dpartement doivent tre formes et les rgles
dfinies dans la procdure de matrise documentaire mises en uvre pour leurs documents
et leurs projets. Ce travail a pour objectif d'accompagner les utilisateurs et d'viter de
mauvais usages du logiciel. De plus, cela permet d'identifier les volutions et les
amliorations apporter.
Sabine Champenois
97/125
Nous avons prcdemment vu qu'un certain nombre de fonctionnalits n'a pas t mis en
place dans l'immdiat. Ds prsent, de nouveaux projets ont t lancs pour la reprise de
l'existant, l'import des plans provenant de SolidWorks PDM et la mise en uvre des
formulaires au travers des demandes de calculs (plus simples mettre en uvre que les
demandes d'essai). Les autres types de demandes seront paramtrs plus tard ainsi que la
gestion des modifications de la conception. La mise en place d'un systme d'archivage est
reporte plus long terme, lorsque l'outil de GED sera bien appropri par tous et qu'une
quantit importante de documents y sera gre.
Lors de la cration de documents, un certain nombre de mtadonnes propres au mtier de
GTT a besoin d'tre gr dans une base commune afin d'assurer une homognit dans le
renseignement de ces informations. Une base de donnes dite mtier est donc en cours de
dveloppement pour la consultation et la gestion de ces informations. Lorsque ce
dveloppement sera achev, cette base pourra tre connecte au logiciel de GED et ainsi
permettre le renseignement des mtadonnes partir des informations qui y sont
contenues.
Enfin, les normes et mthodes mises en uvre pour ce projet ont pu dmontrer leur
efficacit et sont une bonne base pour en gnraliser l'usage pour l'ensemble des projets du
Dpartement Systme d'Information et ainsi, tablir un ensemble de processus type.
Le bilan global du projet a permis d'tablir les points forts, les axes d'amlioration et les
volutions. Ces informations sont une premire base de retour d'exprience qui va pouvoir
s'toffer lors des projets suivants grs par le Dpartement Systme d'Information. Ce bilan
est complt par un bilan personnel.
V.5
Bilan personnel
J'ai t recrute spcifiquement pour ce projet au sein de GTT. Ce fut pour moi une
formidable chance de pouvoir en faire un sujet de mmoire pour le CNAM et de mettre en
uvre les bonnes pratiques enseignes. Ce projet m'a apport beaucoup au niveau
relationnel. Le mode de fonctionnement pour la rdaction des exigences avec le COUTIL
sous forme de runion hebdomadaire est trs agrable. Il permet d'impliquer tout le monde
et a t l'occasion pour moi de dcouvrir et comprendre le mtier de ma nouvelle
entreprise.
Par contre, il fut plus difficile d'arriver un consensus ou des prises de dcisions lors des
Comits de Pilotage. Pour aboutir, il important de comprendre les points de vue de chacun
et ses oppositions. Il est ncessaire d'effectuer des manuvres pralables aux runions.
Dialoguer et maintenir un niveau de confiance et un bon relationnel avec un fournisseur
n'est pas chose facile. Des problmes de communication peuvent vite dgrader la situation.
Des changes rguliers doivent favoriser le dialogue et viter les malentendus. Il apparat
ncessaire de trouver l'quilibre entre une ambiance cordiale de travail et une pression
permanente afin d'arriver maintenir les objectifs.
Les normes et mthodes mises en uvre m'ont toutes apport des comptences au niveau
de la ralisation et du suivi du projet informatique.
Le PMBOK est un guide exhaustif et une bonne base de travail pour tous types de projets.
Il m'a permis de dvelopper un certain nombre d'outils facilement rutilisables ou
transposables pour d'autres projets.
Sabine Champenois
98/125
La norme ISO ISO/CEI 12207 est complmentaire au PMBOK. Elle apporte une vision
logicielle que n'a pas le PMBOK plus gnraliste sur la conduite de projet.
La mthode d'Alistair Cockburn pour rdiger des cas d'utilisation ncessite de bien la
comprendre pour la mettre en uvre. Mais elle s'avre trs efficace et permet d'obtenir une
base de travail rutilisable tout au long du projet.
Enfin, le CMMI permet d'valuer son travail. Pour ce projet, cette valuation a t ralise
la fin mais il est intressant de s'valuer diffrentes tapes cls. Ainsi, entre deux
valuations, des actions d'amliorations peuvent tre lances et leur rsultat peut tre
mesur. Pour aller plus loin avec le CMMI, il faut avoir des processus dcrits au sein de
l'entreprise et les adapter chaque projet.
Ce projet que j'ai men au sein de GTT m'a permis de consolider mes comptences en
gestion de projet et d'amliorer mes qualits relationnelles avec toutes les parties prenantes
d'un projet en ayant un rle central d'assistance la matrise d'ouvrage.
Le projet d'acquisition et de mise en place d'un logiciel de GED a un bilan positif dans son
ensemble. Ce nouvel outil a mobilis tous les collaborateurs de l'entreprise et est en passe
de devenir un outil quotidien indispensable. Des points d'amlioration ont t identifis et
pourront tre mis en uvre lors de futurs projets au sein du Dpartement Systme
d'Information de GTT.
Sabine Champenois
99/125
VI Conclusion
Les activits de GTT en tant que socit d'ingnierie produisent principalement des
documents. Cela ncessite de les grer de manire en faciliter l'accs pour l'ensemble de
l'entreprise tout en s'assurant de l'utilisation de la dernire version approuve. De plus,
beaucoup de documents sont des livrables clients, il faut donc pouvoir suivre les versions
diffuses. Ces problmatiques ont mis en vidence la ncessit d'acqurir un logiciel de
GED et de recruter un chef de projet pour recueillir les exigences, raliser un appel d'offre
et suivre la mise en place du logiciel. L'quipe projet tait compose du chef de projet
(moi-mme) agissant en tant qu'assistant la matrise d'ouvrage, un Comit des
Utilisateurs et un Comit de Pilotage. Le tout fut assist par l'quipe du Dpartement
Systme d'Information.
La mise en place de l'application Cincom ECM au sein de GTT a ncessit de mettre en
uvre les fonctionnalits et les workflows tablis dans l'expression fonctionnelle de
besoin. Le logiciel s'appuie sur une architecture applicative de type 3-tiers et sur une
infrastructure technique base sur des machines virtuelles et un cluster des serveurs.
La mise en place d'une telle application n'a pu se faire que grce une conduite de projet
s'appuyant sur diverses normes et mthodes :
le PMBOK pour la gestion du projet,
la norme ISO/CEI 12207 pour l'acquisition, la validation, la vrification et la rsolution

des problmes,
la norme NF X50-151 pour rdiger les documents du dossier d'appel d'offre, le livre
d'Alistair Cockburn pour recueillir les exigences fonctionnelles,
le CMMI pour valuer la ralisation et dterminer les voies d'amlioration.
Le projet a dbut par une phase de planification afin d'tablir le plan de management de
projet. Puis, la phase d'acquisition a abouti la contractualisation avec un fournisseur de
logiciel de GED. Ensuite, la phase de mise en place s'est acheve avec la mise en
production du logiciel. Enfin, une valuation des processus mis en uvre a permis d'tablir
les amliorations apporter pour les prochains projets du Dpartement Systme
d'Information.
Le projet d'acquisition et de mise en place d'une GED a un bilan positif dans son ensemble
mme si des retards importants sont dplorer. Ce nouvel outil a mobilis tous les
collaborateurs de l'entreprise et est en passe de devenir un outil quotidien indispensable.
Des points d'amlioration ont t identifis et pourront tre mis en uvre lors de futurs
projets au sein du Dpartement Systme d'Information de GTT.
Sabine Champenois
100/125
Aujourd'hui, l'application est en cours de dploiement au sein de l'entreprise. Les

utilisateurs sont forms au fur et mesure et les documents des nouveaux projets sont crs
directement dans l'application. Une base de donnes mtier est en cours de dveloppement
et devrait tre connect la GED afin d'assister le renseignement des mtadonnes. La
reprise de l'existant et l'import des plans provenant de SolidWorks PDM sont en cours de
ralisation par le fournisseur du logiciel. Ces nouveaux projets devraient tre finaliss au
cours de l'anne 2011. Des volutions sont ds lors demandes par les utilisateurs et vont
tre tudies et ralises au fur et mesure.
Sabine Champenois
101/125
VII Abrviations et glossaire

Actif
organisationnel
AMO
API
BPM
CAO
CdCF
Charte du projet
Chemin, critique
CEI
CMMI
CMS
CNAM
COPIL
COUTIL
chancier du
projet
ECM
EFB
Enregistrement
EPC
ERM
Facteurs
environnementaux
de l'entreprise
GED
GNL
GPL
GTT
ISO
Jalon
KM
Sabine Champenois
Au sens du PMBOK, actif associ aux processus et provenant d'une

organisation participant au projet, utilis ou utilisable pour
contribuer la russite de ce projet. Il comprend les plans, pratiques,
procdures et directives, qu'ils soient formels ou informels. Il
convient d'y inclure les bases de connaissance de l'organisation telles
que les retours d'exprience et l'information historique.
Assistance Matrise d'Ouvrage
Application Programming Interface
Business Process Management
Conception Assiste par Ordinateur
Cahier des Charges Fonctionnel
Au sens du PMBOK, document mis par l'initiateur ou le
commanditaire du projet, qui en autorise formellement l'existence et
donne autorit au chef de projet pour affecter des ressources de
l'organisation aux activits de ce projet.
Correspond la squence d'activits de l'chancier qui dtermine la
dure du projet. Il s'agit du chemin le plus long du projet.
Commission lectrotechnique Internationale
Capacity Maturity Model Integration
Content Management System
Conservatoire National des Arts et Mtiers
Comit de PILotage
Comit des UTILisateurs
Au sens du PMBOK, ensemble des dates planifies pour l'excution
des activits de l'chancier et pour la ralisation des jalons de
l'chancier.
Electronic Content Management
Expression Fonctionnelle du Besoin
Document faisant tat de rsultats obtenus ou apportant une preuve
de la ralisation d'une activit. Les enregistrements peuvent, par
exemple, documenter la traabilit et apporter la preuve que la
vrification, les actions prventives et les actions correctives ont t
ralises.
Engineering Procurement Construction
Electronic Record Management
Au sens du PMBOK, facteurs internes ou externes l'organisation
qui influencent la russite du projet. Ils comprennent la culture, la
structure et l'infrastructure de l'organisation, les ressources
existantes, les bases de donnes commerciales, les conditions du
march et les logiciels de gestion de projet utiliss.
Gestion lectronique de Documents
Gaz Naturel Liqufi
Gaz de Ptrole Liqufi
Gaztransport & Technigaz
International Standards Organisation
Au sens du PMBOK, point ou vnement significatif d'un projet.
Knowledge Management
102/125
LAD
LAN
LDAP
Mtadonne
NF
OCR
PDCA
PDM
PMBOK
PMI
RAID
RAM
RH
SAN
SEI
SGBD
SI
SMQ
SSO
Structure de
dcoupage du
projet
TF
Transmital form
WCM
Workflow
Sabine Champenois
Lecture Automatique de Documents

Local Area Network
Lightweight Directory Access Protocol
Donne dcrivant le contexte, le contenu et la structure d'un
document ainsi que sa gestion dans le temps.
Norme Franaise
Optical Character Recognition
Planifier, Drouler, Contrler et Agir ou Plan, Do, Check and Act en
version anglaise
Project Data Manager
Project Management Body Of Knowledge
Project Management Institute
Redundant Array of Independent Disks
Random Access Memory
Ressources Humaines
Storage Area Network
Software Engineering Institute
Systme de Gestion de Base de Donnes
Systme d'Information
Systme de Management de la Qualit
Single Sign-On
Au sens du PMBOK, dcomposition hirarchique axe sur les
livrables du travail que l'quipe de projet doit excuter pour atteindre
les objectifs du projet et produire les livrables voulues
Transmital Form
Bon de livraison au format GTT. Document indiquant le destinataire
et la liste des documents livrs
Web Content Management
Ensemble des tches accomplir par diffrents acteurs
103/125
VIII Bibliographie
[1]
Corpus des connaissances en management de projet (Guide PMBOK). 3e dition.

Newtown Square : Project Management Institute, 2004, 388 p.
[2]
ISO/CEI 12207, Systems and software engineering Software life cycle

processes. Seconde dition. Genve : International Standard Organisation,
February 2008, 140 p.
[3]
NF X50-151, Management par la valeur : Expression Fonctionnelle du Besoin et

cahier des charges fonctionnel (Exigences pour lexpression et la validation du
besoin satisfaire dans le processus dacquisition ou d'obtention d'un produit). La
Plaine Saint Denis : AFNOR, septembre 2007, 36 p.
[4]
Cockburn Alistair. Rdiger des cas d'utilisation efficaces. Paris : ditions Eyrolles,
2001, 290 p.
[5]
CMMI pour le dveloppement, L'amlioration des processus pour des meilleurs

produits, Version 1.2, Aot 2006, 588 p.
[6]
Jean Pierre et Petit Henri. Quand le mthane prend la mer / Methane by sea.
Marseille : P. Tacussel diteur, 1998, 185 p.
[7]
Association amricaine pour la gestion de l'information et des images. Your

Information Management & Collaborative Source. Disponible sur : www.aiim.org.
Consult le 24/05/2011.
[8]
Association franaise des professionnels pour l'conomie numrique. APROGED.

Disponible sur : www.aproged.org. Consult le 24/05/2011.
[9]
Cincom Systems Inc. Cincom ECM. Disponible sur : www.cincom-ecm.fr.

Consult le 24/05/2011.
Sabine Champenois
104/125
Annexes
Les annexes suivantes sont des extraits de diffrents documents cits dans la bibliographie
(voir VIII).
Annexe 1 : Rcapitulatif du PMBOK pour la dfinition du contenu du

projet
Activits
Dfinition du contenu
Cration de la structure de dcoupage du projet
Donnes d'entre
Donnes de sortie
Facteurs environnementaux de
nonc du contenu du projet
l'entreprise
Structure de dcoupage du projet
Actif organisationnel
Dictionnaire de la structure de
dcoupage du projet
Charte du projet
nonc prliminaire du contenu du
Rfrence de base du contenu
projet
Sabine Champenois
105/125
Annexe 2 : Rcapitulatif du PMBOK pour la gestion des dlais du projet
Activits
Identification des activits
Squencement des activits
Estimation des ressources ncessaires aux activits
Estimation de la dure des activits
laboration de l'chancier
Matrise de l'chancier
Donnes d'entre
Donnes de sortie
Liste d'activits
l'entreprise
Attributs des activits
Liste des jalons
Diagrammes de rseau du projet
Ressources ncessaires aux activits
Structure de dcoupage des ressources
dcoupage du projet
Calendrier des ressources
Disponibilit des ressources
Estimation de la dure des activits
Rapports d'avancement
chancier du projet
Donnes du modle d'chancier
Rfrence de base de l'chancier
Sabine Champenois
106/125
Annexe 3 : Rcapitulatif du PMBOK pour la gestion des cots du projet

Activits
Estimation des cots

Budgtisation
Matrise des cots
Donnes d'entre
l'entreprise
dcoupage du projet
chancier du projet
Registre des risques
Calendrier des ressources
Contrat
Rapport d'avancement
Sabine Champenois
Donnes de sortie
Estimation du cot des activits
Dtails l'appui de l'estimation du cot
des activits
Rfrence de base des cots.
Exigences lies au financement du
projet
107/125
Annexe 4 : Rcapitulatif du
communications du projet
PMBOK
pour
la
gestion
des
Activits
Planification des communications
Diffusion de l'information
tablissement du rapport d'avancement
Management des parties prenantes
Donnes d'entre
Donnes de sortie
Plan de management des
l'entreprise
communications
Information sur la performance du
Prvisions
travail
Problmes majeurs rsolus
Mesures de performance
Prvisions d'achvement
Livrables
Sabine Champenois
108/125
Annexe 5 : Rcapitulatif du PMBOK pour la gestion des risques du

projet
Activits
Identification des risques
Analyse qualitative des risques
Analyse quantitative des risques
Planification des rponses aux risques
Surveillance et matrise des risques
Donnes d'entre
Donnes de sortie
Registre des risques
l'entreprise
travail
Sabine Champenois
109/125
Annexe 6 : Rcapitulatif du PMBOK pour la gestion des modifications

du projet
Activits
Surveillance et matrise du travail du projet
Matrise intgre des modifications
Donnes d'entre
Donnes de sortie
Plan de management du projet
Demandes de modifications approuves
Demandes de modifications rejetes
Actions correctives approuves
travail
Actions prventives approuves
Demandes de modifications
Correction des dfauts approuve
Livrables
Plan de management du projet mis
jour
nonc du contenu du projet mis jour
Livrables mis jour
Prvisions mises jour
Sabine Champenois
110/125
Annexe 7 : Exigences selon la norme NF X50-151 pour une expression

fonctionnelle du besoin
Thmes
Dfinition globale du besoin
Dfinition des lments
stratgiques du march cible
et dbouch du produit
Mise en vidence des
principes et concepts dj
retenus a priori
Description des fonctions

assurer et des contraintes
respecter
Exigences particulires
applicables au processus de
gnration de l'EFB
Sabine Champenois
Exigences
Formulation du besoin global
Intgration du produit dans un ensemble "plus vaste"
Dfinition des enjeux conomiques
Inventaire des donnes stratgiques du demandeur
Champs des besoins traits
tude de chaque couverture fonctionnelle vise
Expos des principes ou concepts dj retenus a priori
Identification de la granulomtrie (niveau de dtail) de la

description du besoin
Identification des lments de caractrisations obligatoires
et additionnels
Slection et description des phases du cycle de vie
Inventaire et description des interacteurs
Inventaire des fonctions de service
Neutralit technique des fonctions de service
Organisation des fonctions
Hirarchisation / pondration des fonctions
Caractrisation des fonctions
Variations fonctionnelles envisageables
Inventaire organis et description des contraintes
Adaptation des ressources au besoin dcrire
Validation de lEFB
111/125
Annexe 8 : Exigences selon la norme NF X50-151 pour un cahier des

charges fonctionnel
Thmes
Contenu du CdCF
Caractristiques dfinissant la
qualit dun CdCF :
qualimtrie
Exigences particulires
applicables au processus
d'tablissement du CdCF
Sabine Champenois
Exigences
Rubriques obligatoires d'un CdCF :
la prsentation du projet, du contexte demploi du
CdCF,
le "produit" (objet du CdCF) et son domaine d'emploi
la prsentation des parties intresses
les phases du cycle de vie associ
la description des interacteurs
les principes/concepts dj retenus
la liste des fonctions caractrises, a minima sous
forme de critres dapprciation, de niveaux et de
flexibilits
linventaire des contraintes applicables
une rubrique fixant aux offreurs un cadre de rponse
un glossaire prcisant la terminologie utilise
la dfinition du besoin global
le concept gnral du "produit", les principaux
services attendus pour lesquels il doit tre conu
(synthse de la formulation du besoin) et son niveau
dintgration (matriel, quipements, ensembles, sousensembles, composants, etc.)
les informations ncessaires pour motiver le futur
partenaire (dbouchs prvus, esprance de vie
commerciale, situation existante sur le march pour
les produits quivalents, etc.)
Autres rubriques dun CdCF :
des lments complmentaires de caractrisation
prsents dans lEFB
une prsentation de limportance relative des fonctions
(hirarchisation/pondration)
une rubrique dappel variantes
des donnes conomiques
Adaptation de la structure lusage dfini du CdCF
Respect des processus
Lisibilit et comprhension par le destinataire
Capacit accompagner la phase dexploitation
Intgration du CdCF dans le processus d'obtention d'un
produit
Slection des lments de l'EFB intgrer dans le CdCF
Transmissibilit un tiers
Validation du CdCF
112/125
Annexe 9 : Activit
ISO/CEI 12207
"Acquisition
advertisement"
selon
la
norme
Tches
The acquirer shall communicate the request for the supply of a product or service to
identified suppliers.
Sabine Champenois
113/125
Annexe 10 : Activit "Supplier selection" selon la norme ISO/CEI 12207
Tches
The acquirer should establish a procedure for supplier selection including proposal
evaluation criteria and requirements compliance weighting.
The acquirer should select a supplier based upon the evaluation of the suppliers'
proposals, capabilities, and in accordance with the acquirer's acceptance strategy and
conditions.
Sabine Champenois
114/125
Annexe 11 : Activit
ISO/CEI 12207
"Contract
agreement"
selon
la
norme
Tches
The acquirer may involve other parties, including potential suppliers or any necessary
third parties (such as regulators), before contract award, in determining the acquirers
requirements for tailoring of this International Standard for the project. In making this
determination, the acquirer shall consider the effect of the tailoring requirements upon
the suppliers organizationally-adopted processes. The acquirer shall include or
reference the tailoring requirements in the contract.
The acquirer shall then prepare and negotiate a contract with the supplier that addresses
the acquisition requirements, including the cost and schedule, of the software product
or service to be delivered. The contract shall address proprietary, usage, ownership,
warranty and licensing rights associated with the reusable off-the-shelf software
products.
Once the contract is underway, the acquirer shall control changes to the contract
through negotiation with the supplier as part of a change control mechanism. Changes
to the contract shall be investigated for impact on project plans, costs, benefits, quality,
and schedule.
Sabine Champenois
115/125
Annexe 12 : Activit
ISO/CEI 12207
"Agreement
monitoring"
selon
la
norme
Tches
The acquirer shall monitor the supplier's activities in accordance with the Software
Review Process and the Software Audit Process. The acquirer should supplement the
monitoring with the Software Verification Process and the Software Validation Process
as needed.
The acquirer shall cooperate with the supplier to provide all necessary information in a
timely manner and resolve all pending items.
Sabine Champenois
116/125
Annexe 13 : Activit "Software verification process" selon la norme

ISO/CEI 12207
Activits
Process
implementation
Sabine Champenois
Tches
A determination shall be made if the project warrants a verification
effort and the degree of organizational independence of that effort
needed. The project requirements shall be analyzed for criticality.
Criticality may be gauged in terms of:
o The potential of an undetected error in a system or software
requirement for causing death or personal injury, mission failure,
or financial or catastrophic equipment loss or damage.
o The maturity of and risks associated with the software technology
to be used.
o Availability of funds and resources.
If the project warrants a verification effort, a verification process
shall be established to verify the software product.
If the project warrants an independent verification effort, a qualified
organization responsible for conducting the verification shall be
selected. This organization shall be assured of the independence and
authority to perform the verification activities.
Based upon the scope, magnitude, complexity, and criticality analysis
above, target life cycle activities and software products requiring
verification shall be determined. Verification activities and tasks,
including associated methods, techniques, and tools for performing
the tasks, shall be selected for the target life cycle activities and
software products.
Based upon the verification tasks as determined, a verification plan
shall be developed and documented. The plan shall address the life
cycle activities and software products subject to verification, the
required verification tasks for each life cycle activity and software
product, and related resources, responsibilities, and schedule. The
plan shall address procedures for forwarding verification reports to
the acquirer and other involved organizations.
The verification plan shall be implemented. Problems and nonconformances detected by the verification effort shall be entered into
the Software Problem Resolution. All problems and nonconformances shall be resolved. Results of the verification activities
shall be made available to the acquirer and other involved
organizations.
117/125
Activits
Verification
Sabine Champenois
Tches
Requirements verification. The requirements shall be verified
considering the criteria listed below:
o The system requirements are consistent, feasible, and testable.
o The system requirements have been appropriately allocated to
hardware items, software items, and manual operations according
to design criteria.
o The software requirements are consistent, feasible, testable, and
accurately reflect system requirements.
o The software requirements related to safety, security, and
criticality are correct as shown by suitably rigorous methods.
Design verification. The design shall be verified considering the
criteria listed below:
o The design is correct and consistent with and traceable to
requirements.
o The design implements proper sequence of events, inputs,
outputs, interfaces, logic flow, allocation of timing and sizing
budgets, and error definition, isolation, and recovery.
o Selected design can be derived from requirements.
o The design implements safety, security, and other critical
requirements correctly as shown by suitably rigorous methods.
Code verification. The code shall be verified considering the criteria
listed below:
o The code is traceable to design and requirements, testable,
correct, and compliant with requirements and coding standards.
o The code implements proper event sequence, consistent
interfaces, correct data and control flow, completeness,
appropriate allocation timing and sizing budgets, and error
definition, isolation, and recovery.
o Selected code can be derived from design or requirements.
o The code implements safety, security, and other critical
requirements correctly as shown by suitably rigorous methods.
Integration verification. The integration shall be verified considering
the criteria listed below:
o The software components and units of each software item have
been completely and correctly integrated into the software item.
o The hardware items, software items, and manual operations of
the system have been completely and correctly integrated into the
system.
o The integration tasks have been performed in accordance with an
integration plan.
Documentation verification. The documentation shall be verified
considering the criteria listed below:
o The documentation is adequate, complete, and consistent.
o Documentation preparation is timely.
o Configuration management of documents follows specified
procedures.
118/125
Rsultats
verification strategy is developed and implemented;
criteria for verification of all required software work products is identified;
required verification activities are performed;
defects are identified and recorded; and
results of the verification activities are made available to the customer and other
involved parties.
Sabine Champenois
119/125
Annexe 14 : Activit "Software validation process" selon la norme

ISO/CEI 12207
Activits
Process
implementation
Validation
Sabine Champenois
Tches
A determination shall be made if the project warrants a validation
effort and the degree of organizational independence of that effort
needed.
If the project warrants a validation effort, a validation process shall
be established to validate the system or software product. Validation
tasks defined below, including associated methods, techniques, and
tools for performing the tasks, shall be selected.
If the project warrants an independent effort, a qualified organization
responsible for conducting the effort shall be selected. The conductor
shall be assured of the independence and authority to perform the
validation tasks.
A validation plan shall be developed and documented. The plan shall
include, but is not limited to, the following:
o Items subject to validation.
o Validation tasks to be performed.
o Resources, responsibilities, and schedule for validation.
o Procedures for forwarding validation reports to the acquirer and
other parties.
The validation plan shall be implemented. Problems and nonconformances detected by the validation effort shall be entered into
the Software Problem Resolution Process. All problems and nonconformances shall be resolved. Results of the validation activities
shall be made available to the acquirer and other involved
organizations.
Prepare selected test requirements, test cases, and test specifications
for analyzing test results.
Ensure that these test requirements, test cases, and test specifications
reflect the particular requirements for the specific intended use.
Conduct the tests, including:
o Testing with stress, boundary, and singular inputs;
o Testing the software product for its ability to isolate and
minimize the effect of errors; that is, graceful degradation upon
failure, request for operator assistance upon stress, boundary, and
singular conditions;
o Testing that representative users can successfully achieve their
intended tasks using the software product.
Validate that the software product satisfies its intended use.
Test the software product as appropriate in selected areas of the
target environment.
120/125
Rsultats
validation strategy is developed and implemented;
criteria for validation of all required work products are identified;
required validation activities are performed;
problems are identified and recorded;
evidence is provided that the software work products as developed are suitable for their
intended use; and
results of the validation activities are made available to the customer and other
involved parties.
Sabine Champenois
121/125
Annexe 15 : Activit "Software Problem Resolution Process" selon la

norme ISO/CEI 12207
Activits
Process
implementation
Tches
A problem resolution process shall be established for handling all
problems (including nonconformances) detected in the software
products and activities. The process shall comply with the following
requirements:
o The process shall be closed-loop, ensuring that: all detected
problems are promptly reported and entered into the Problem
Resolution Process; action is initiated on them; relevant parties
are advised of the existence of the problem as appropriate; causes
are identified, analyzed, and, where possible, eliminated;
resolution and disposition are achieved; status is tracked and
reported; and records of the problems are maintained as
stipulated in the contract.
o The process should contain a scheme for categorizing and
prioritizing the problems. Each problem should be classified by
the category and priority to facilitate trend analysis and problem
resolution.
o Analysis shall be performed to detect trends in the problems
reported.
o Problem resolutions and dispositions shall be evaluated: to
evaluate that problems have been resolved, adverse trends have
been reversed, and changes have been correctly implemented in
the appropriate software products and activities; and to determine
whether additional problems have been introduced.
Problem
When problems (including non-conformances) have been detected in
resolution
a software product or an activity, a problem report shall be prepared
to describe each problem detected. The problem report shall be used
as part of the closed-loop process described above: from detection of
the problem, through investigation, analysis and resolution of the
problem and its cause, and onto trend detection across problems.
Rsultats
a problem management strategy is developed;
problems are recorded, identified and classified;
problems are analyzed and assessed to identify acceptable solution(s);
problem resolution is implemented;
problems are tracked to closure; and
the status of all problems reported is known.
Sabine Champenois
122/125
Annexe 16 : Activit
ISO/CEI 12207
"Acquirer
acceptance"
selon
la
norme
Tches
The acquirer should prepare for acceptance based on the defined acceptance strategy
and criteria. The preparation of test cases, test data, test procedures, and test
environment should be included. The extent of supplier involvement should be defined.
The acquirer shall conduct acceptance review and acceptance testing of the deliverable
software product or service and shall accept it from the supplier when all acceptance
conditions are satisfied. The acceptance procedure should comply with the provisions
of definition and documentation of the acceptance strategy and conditions (criteria).
After acceptance, the acquirer should take the responsibility for the configuration
management of the delivered software product.
Sabine Champenois
123/125
Annexe 17 : Activit "Closure" selon la norme ISO/CEI 12207
Tches
The acquirer shall make payment or provide other agreed consideration to the supplier
for the product or service rendered.
Sabine Champenois
124/125

Mmoire d'Ingnieur C.N.A.M., Versailles 2011
_________________________________________________________________
RESUME
Un logiciel de Gestion lectronique de Documents (GED) a pour fonction d'acqurir,

produire, grer, stocker, archiver et diffuser des documents au format lectronique. Cet outil
de travail collaboratif peut, au moyen de workflows, assister, voire automatiser les diffrentes
tapes du cycle de vie d'un document.
La socit d'ingnierie GTT, produisant principalement des documents dans le cadre de son
activit, a eu besoin d'acqurir un tel outil afin d'amliorer la disponibilit et la fiabilit des
documents produits.
Ce mmoire prsente les diffrentes phases de l'acquisition et de la mise en place d'un tel
outil. La ralisation du projet s'appuie sur le PMBOK pour la gestion du projet, la norme
ISO/CEI 12207 pour l'acquisition, la validation et la vrification du logiciel, la norme
NF X50-151 pour rdiger les documents du dossier d'appel d'offre, la mthode d'Alistair
Cockburn pour recueillir les exigences fonctionnelles et le CMMI pour valuer la ralisation
et dterminer les voies d'amlioration.
Mots cls : GED, document, workflow, PMBOK, ISO/CEI 12207, NF X50-151, CMMI
_________________________________________________________________
ABSTRACT
The functions of Electronic Content Management (ECM) software are capture, produce,
manage, store, archive and deliver documents in electronic format. It is a collaborative tool
which used with workflow is able to assist and even automates the different steps of document
life cycle.
The GTT engineering company produces mainly documents for its activity and thus has felt
the need to acquire this type of software in order to improve the availability and reliability of
its produced documents.
This document deals with all the different steps of acquisition and implementation of this kind
of software. The project is based on PMBOK for project management, the ISO/CEI 12207
standard for software acquisition, validation and verification, the NF X50-151 standard for
writing all the documents of the request tenders, the Alistair Cockburn method's for collecting
functional requirements and the CMMI to evaluate the accomplishment and to determine
ways of improvement.
Key words : ECM, document, workflow, PMBOK, ISO/CEI 12207, NF X50-151, CMMI

GED

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

GED

Загружено:

Авторское право:

Доступные форматы

Acquisition et mise en place dun logiciel de Gestion

To cite this version:

Sabine Champenois. Acquisition et mise en place dun logiciel de Gestion Electronique

HAL Id: dumas-00693935

HAL is a multi-disciplinary open access

Larchive ouverte pluridisciplinaire HAL, est

CONSERVATOIRE NATIONAL DES ARTS ET METIERS

Acquisition et mise en place d'un logiciel de Gestion lectronique de Documents

Acquisition et mise en place d'un logiciel de Gestion lectronique de Documents

Acquisition et mise en place d'un logiciel de Gestion lectronique de Documents

Prsentation gnrale ........................................................................................................ 7

II Matrise de la gestion lectronique des documents ...................................................... 10

Acquisition et mise en place d'un logiciel de Gestion lectronique de Documents

Bibliographie ............................................................................................... 104

Annexes .................................................................................................................................. 105

Acquisition et mise en place d'un logiciel de Gestion lectronique de Documents

Liste des figures

Acquisition et mise en place d'un logiciel de Gestion lectronique de Documents

Liste des tableaux

Acquisition et mise en place d'un logiciel de Gestion lectronique de Documents

Acquisition et mise en place d'un logiciel de Gestion lectronique de Documents

La phase de planification concerne la mise en place du projet avec la rdaction d'un

La phase d'acquisition du logiciel de GED et de slection de son fournisseur a consist

La phase de mise en place du logiciel de GED a consist en la dfinition des

L'ensemble de la conduite du projet ncessite la mise en uvre de bonnes pratiques :

Le suivi des recommandations du PMBOK (Project Management Body Of Knowledge)

la norme ISO/CEI 12207 pour mener les processus d'acquisition, de validation, de

la norme NF X50-151 pour dfinir le contenu et le cycle de vie de l'expression

le livre d'Alistair Cockburn pour recueillir les exigences fonctionnelles auxquelles

le CMMI (Capacity Maturity Model Integration) pour valuer la ralisation et

Acquisition et mise en place d'un logiciel de Gestion lectronique de Documents

Acquisition et mise en place d'un logiciel de Gestion lectronique de Documents

II Matrise de la gestion lectronique des documents

GTT est spcialise dans la conception de systmes de confinement membranes pour le

Acquisition et mise en place d'un logiciel de Gestion lectronique de Documents

la cession de licences de fabrication selon les brevets de GTT,

la conception de systme de confinement pour le GNL, le GPL (Gaz de Ptrole

la ralisation d'avant-projets de navires, barges ou rservoir de stockage et l'laboration

les tudes du systme des cuves,

les tudes des systmes de manutention et de transfert de cargaison,

l'homologation des fournisseurs de matriaux et composants des technologies GTT,

l'assistance technique au chantier de construction ou la socit d'ingnierie, le

l'assistance technique pendant lexploitation du navire ou du rservoir terrestre,

GTT s'appuie sur son organisation afin de raliser ces services.

Acquisition et mise en place d'un logiciel de Gestion lectronique de Documents

II.1.3 Organisation de GTT

Figure 1 : Organigramme de GTT

Acquisition et mise en place d'un logiciel de Gestion lectronique de Documents

La Direction Commerciale a pour mission gnrale de conduire l'activit commerciale de

rechercher et analyser les informations sur le march et l'environnement,

prparer et dployer la politique de communication,

dvelopper et entretenir les relations avec les prescripteurs (armateurs, gouvernements

rechercher des voies de diversification et maintenir le dossier d'orientation stratgique.

La Direction Technique a pour mission gnrale de conduire l'activit technique lorsque

fournir les notes d'tudes (architecture navale, mouvements de liquide, structure,

fournir les plans du systme de cuve et des systmes de manutention et du transfert de

assurer un support technique la construction et la maintenance auprs des chantiers

La Direction Administrative et Financire est en charge de lensemble des activits support

la maintenance, linstallation de tout matriel et logiciel informatique,

l'assistance des utilisateurs sur des problmes gnraux,

le bon fonctionnement du systme, du rseau et de son optimisation,

la scurit en gnrale du systme dinformation,

le recensement des besoins mtiers des utilisateurs, leurs analyses et ventuellement la

la maintenance des dveloppements existants,