Vous êtes sur la page 1sur 30

L

Analyse fonctionnelle des systmes - A. Azarian, Y. Pollet


analyse fonctionnelle fait partie de notre culture technique. Cest un
outil mthodologique prcieux dont lapport est essentiel lentreprise amene
concevoir un systme ou un produit quelle que soit sa nature.
Dans cet ouvrage, lanalyse fonctionnelle est aborde sous langle des concepts
et de manire concrte, telle quelle est pratique dans lindustrie. Cet ouvrage
prsente en dtail la procdure danalyse fonctionnelle et fournit lensemble des
tapes logiques quun analyste doit suivre dans sa dmarche. Les applications
de lanalyse fonctionnelle sont abordes, en particulier lanalyse de la valeur,
llaboration du plan de sret et fonctionnement, la conception cot objectif
et enfin la rdaction dun cahier des charges et dune spcification technique.
Prsentant les erreurs viter et sappuyant sur de nombreux exemples,
des exercices, des tests de type QCM et des cas dtude, louvrage
permet au lecteur de sapproprier la mthode et lui fournit les cls de la
rdaction et de lexploitation dun cahier des charges ou dun document Ali Azarian
de spcification technique. Yann Pollet

Les Cours
Mots-cls: analyse fonctionnelle; analyse de la valeur; cahier des charges fonctionnel; spcification
technique du besoin; expression fondamentale du besoin; contrle de validit; MISME: schmas dits
Bte cornes* et Pieuvre*; bloc diagramme fonctionnel (BDF); tableau danalyse fonctionnelle (TAF);
SADT et FAST.

Ali Azarian est ingnieur des Mines de Paris et titulaire dun PhD. Il est expert la Commission europenne
et auditeur certifi IRCA. Riche de 40 ans dexprience dans lindustrie, mais aussi dans la recherche et
lenseignement, il a t en particulier formateur en analyse fonctionnelle la SNCF, au CEA, lInstitut
Ligeron et lONERA. Il enseigne galement lanalyse fonctionnelle dans plusieurs coles dingnieurs.
Analyse fonctionnelle
des systmes
Yann Pollet est ingnieur ENSTA, IAE et docteur en informatique. Il a travaill comme ingnieur tudes
systmes et chef de projets de systmes de dfense. En 2002, il rejoint le Conservatoire national des arts
et mtiers comme professeur titulaire de la chaire dIntgration des systmes. Il est par ailleurs expert
la Commission europenne, expert judiciaire prs une cour dappel, et ingnieur de larmement de rserve.

45 euros
Presses des Mines

Analyse-fonctionnelle.indd 1 26/07/16 15:59


Ali Azarian et Yann Pollet, Analyse fonctionnelle des systmes, Paris: Presses des
MINES, collection Les Cours, 2016.

Presses des MINES - TRANSVALOR, 2016


60, boulevard Saint-Michel - 75272 Paris Cedex 06 - France
presses@mines-paristech.fr
www.pressesdesmines.com

Illustration de couverture: Corentin Echivard

ISBN: 978-2-35671-404-6

Dpt lgal: 2016


Achev dimprimer en 2016 (Paris)

Tous droits de reproduction, de traduction, dadaptation et dexcution rservs pour tous les
pays.
Analyse fonctionnelle
des systmes
Collection Les cours
Dans la mme collection:

Francis Maisonneuve, Mathmathiques 2 et 3


Bernard Wiesenfeld, Une introduction la neutronique
Francis Maisonneuve, Probabilits
Francis Maisonneuve, Mathmathiques 2
Renaud Gicquel, Introduction aux problmes nergtiques globaux
Francis Maisonneuve, Mathmathiques 3
Francis Maisonneuve, Mathmathiques 1
J. Adnot, D. Marchio, Ph. Rivire, Cycles de vie des systmes nergtiques
Brigitte dAndra-Novel, Benot Fabre, Pierre Jouvelot, Acoustique-Informatique-Musique
Jean-Claude Moisdon, Michel Nakhla, Recherche oprationnelle
Anne-Franoise Gourgues-Lorenzen, Jean-Marc Haudin, Jacques Besson, Matriaux pour
lingnieur
Renaud Gicquel, Systmes nergtiques Tome 3
Renaud Gicquel, Systmes nergtiques Tome 2
Renaud Gicquel, Systmes nergtiques Tome 1
Thierry Weil, Stratgie dentreprise
Franois Cauneau, Mcanique des fluides
Pierre Chauvet, Aide-mmoire de gostatistique linaire
Dominique Marchio, Paul Reboux, Introduction aux transferts thermiques
Franois Engel, Frdric Kletz, Cours de comptabilit analytique
Franois Engel, Frdric Kletz, Cours de comptabilit gnrale
Jacques Bouchard, Jean-Paul Deffain, Alain Gouchet, Introduction au gnie atomique
Daniel Fargue, Abrg de thermodynamique: principes et applications
Georges Pierron, Introduction au traitement de lnergie lectrique
Bernard Degrange, Introduction la physique quantique
Michel Cohen de Lara, Brigitte dAndra-Novel, Cours dautomatique
Fixari Daniel, Les Imperfections des marchs
Jacques Lvy, Introduction la mtallurgie gnrale
Hugues Molet, Comment matriser sa productivit industrielle?
Margaret Armstrong, Jacques Carignan, Gostatistique linaire
Ali Azarian et Yann Pollet

Analyse fonctionnelle
des systmes
Remerciements

Ce nest pas sans une certaine motion que nous rdigeons cette page de remerciements.

Nous souhaitons tout dabord et en premier lieu remercier le Professeur Dominique


Marchio du Dpartement dnergtique de lEcole des Mines de Paris, qui nous a
encourag et soutenu dans notre dmarche de rdaction et de publication de ce livre.

Nous adressons galement tous nos remerciements Monsieur Pierre Barbier, ancien
collgue dAli Azarian la socit Bertin, expert en analyse de la valeur, qui a
permis dans le pass ce dernier de parfaire sa maitrise de lanalyse fonctionnelle et
lanalyse de la valeur, et qui a de plus apport une contribution majeure au prsent
ouvrage en acceptant de relire et vrifier le chapitre ddi lapplication de lanalyse
fonctionnelle. Quil en soit chaleureusement remerci.

Nous remercions de mme Monsieur Guy Baudot, ancien collgue dAli Azarian et
expert de la Socit Ligeron, qui a prodigu des conseils fort utiles quant la partie de
cet ouvrage ddie la sret de fonctionnement.

Nous remercions galement la Direction du groupe Sonovision (Division Ligeron)


de nous avoir permis de rutiliser les transparents et les supports du cours danalyse
fonctionnelle de lInstitut Ligeron. Ali Azarian a t en effet durant plus de dix ans
responsable et principal animateur de ce cours, contribuant ainsi former les ingnieurs
et clients de cette entreprise. Bien entendu, les contenus de ce cours ont constitu des
sources que nous avons naturellement exploites dans la rdaction de cet ouvrage.
Les rfrences, figures ou tableaux puiss dans ce cours sont bien sr explicitement
mentionnes, en addition aux rfrences bibliographiques.

Une gratitude tout particulire doit galement tre adresse Madame Catherine Laval
de METRATECH / APTE SYSTEM, laquelle nous a permis de faire, dans cet ouvrage
caractre pdagogique, les rfrences utiles la mthode APTE, ainsi qu des
lments terminologiques propres celle-ci, afin de lui donner ici sa juste place dans
le panorama des outils mthodologiques en France.

Enfin, nous ne pourrions bien sr en aucun cas omettre de remercier la SNCF, et


plus spcialement la Direction de la Recherche et de lInnovation, pour lautorisation
accorde de faire figurer ici les rsultats danalyse fonctionnelle du projet Prdit-TR@
IN-MD, labors par Ali Azarian dans le cadre de son activit la Division Ligeron
de Sonovision.

Ali AZARIAN et Yann POLLET


Table des matires

Remerciements7

Introduction 13

Chapitre 1- Identification des besoins17


Introduction17
1. Cycle de vie dun systme18
2. Analyse du besoin19
2.1. Hexamtre de Quintilien ou QQOQCPC 22
2.2. Mind Maps ou cartes heuristiques22
3. Mthodes didentification des besoins23
3.1. Ingnierie des exigences25
3.2. Cycle de dveloppement27
3.3. Exploitation, maintenance et retrait de service30
3.4. Particularits du cycle en V30

Chapitre 2 - Objectifs de lanalyse fonctionnelle 33


Introduction33
1. Comprhension dun besoin complexe et volutif 34
2. Formalisation et validation des besoins identifis36
3. Classement et gestion de fonctions et de contraintes37
4. Communication claire avec le client: MOE, MOA ou groupe dutilisateurs37
5. Rdaction du Cahier des Charges Fonctionnel (CdCF)38
6. Rdaction de la spcification technique du besoin (STB)38
7. laboration dun devis prcis et argument39
8. Aide la conception et recherche de solutions techniques: CCO39
9. Re-engineering ou retro-ingnierie40
10. Aide lanalyse de la valeur41
11. Modes dgrads et dfaillances: tude de risques techniques42
12. Optimisation de la maintenance base fiabilit (OMF)42
13. dition de rapports vivants et volutifs43
10 Analyse fonctionnelle des systmes

Chapitre 3 - Prsentation de la mthode misme 45


Introduction45
1. Analyse fonctionnelle externe46
1.1. TAPE 1: Dfinition de lobjectif et du systme46
1.2. TAPE 2: Expression fondamentale du besoin ou contrle de validit48
1.3. TAPE 3: Positions dutilisation ou cycle de vie52
1.4. TAPE 4: Diagramme denvironnement ou de contexte ou graphe des interactions56
2. Analyse fonctionnelle interne64
2.1. TAPE 1: Dcomposition de systme: arborescence fonctionnelle65
2.2. TAPE 2: Bloc Diagramme Fonctionnel (BDF)68
2.3. TAPE 3: Tableau dAnalyse Fonctionnelle (TAF)75
3. Cohrence fonctionnelle77
4. Procdure danalyse fonctionnelle79
5.Exercices82

Chapitre 4 - Les mthodes sadt, sa-rt et fast 93


Introduction93
1.Mthode SADT - IDEF094
1.1. Introduction et prsentation gnrale94
1.2. Concepts de base 95
1.3.Dcomposition SADT 98
1.4. Dualit actigramme - datagramme 100
1.5.Conventions 105
1.6. Limites de la mthode SADT  107
2.Mthode SA-RT (SA/RT) 108
2.1. Introduction et prsentation gnrale 108
2.2. Principes de base 108
2.3.Outils SA-RT 113
3.Mthode FAST 113
3.1. Introduction et prsentation gnrale  113
3.2. Trilogie et diffrents types de fonctions  113
4.Exercices 117

Chapitre 5 - Autres mthodes et techniques danalyse


fonctionnelle  127
Introduction 127
1. La mthode RELIASEP 128
1.1. Prsentation gnrale de la mthode RELIASEP 128
Table des matires 11

1.2. Principes gnraux de la mthode RELIASEP 128


2.Le GRAFCET 130
3. La mthode QFD 131
3.1. Prsentation gnrale de QFD 131
3.2. Concepts de base de QFD 132
3.3. La mthode MERISE 134
3.4. Prsentation gnrale de MERISE 134
3.5. Principes de la dmarche MERISE 136
3.6. La mthode KANO 139
3.7. La mthode OMT 141

Chapitre 6 - Applications de lanalyse fonctionnelle 143


Introduction 143
1. Le cahier des charges fonctionnel (CdCF) 143
2. La spcification technique du besoin (STB) 143
3. Lanalyse de la valeur (AV) 144
3.1.Introduction 144
3.2. Concepts fondamentaux de lanalyse de la valeur  145
3.3. Les phases de la dmarche danalyse de la valeur  148
3.4. Particularits et intrt de lanalyse de la valeur 152
3.5. Pratique de lanalyse de la valeur  154
3.6. Synthse des principes de lanalyse de la valeur 159
4. La conception cot objectif (CCO) 160
4.1.Introduction 160
4.2. Objectifs de CCO 160
4.3. Dmarche CCO 161
4.4. Estimation de cots  163
5. Conception base sur le cot global (CCG) 166
6. tude de risques techniques et application en sret de fonctionnement 167
6.1. Croisement de larborescence technique et de larborescence fonctionnelle  170
6.2. Croisement de larborescence technique et fonctionnelle: rduction des cots 175
7. Application en sret de fonctionnement: allocation etcalcul de fiabilit 176
7.1.Redondance 181
8. Logiciels courants 183
9. Applications pour loptimisation de la maintenance 184
12 Analyse fonctionnelle des systmes

Chapitre 7 - Cahier des charges et spcification technique  191


1. Cahier des charges fonctionnel 191
2. Utilit et intrt du CdCF 192
2.1. Notions de base 194
2.2. Critres dapprciation (ou de performance) 195
2.3. Appel variantes  200
2.4. Cadre de rponse  200
3. Spcification technique du besoin 203

Chapitre 8 - Choix des mthodes et outils danalyse fonctionnelle  211


Introduction 211
1. Les critres de choix dune mthode danalyse fonctionnelle 211
2. Liste des outils logiciels daide lanalyse fonctionnelle 214
3. Exercices: test dvaluation 216

Bibliographie 221

Abrviations et sigles 229


Introduction
Lanalyse fonctionnelle est une approche mthodologique qui, en France, fait partie
intgrante de notre culture technique nationale. Elle est largement pratique au sein
des entreprises, en particulier dans des secteurs de lindustrie tels que la dfense,
le domaine ferroviaire, lautomobile, le nuclaire, etc. Dans la plupart des pays
industriels ou en voie de dveloppement, les ingnieurs et les techniciens ne pratiquent
pas lanalyse fonctionnelle sous la forme que nous connaissons et avons lhabitude
dappliquer. Ainsi, lorsquon voque des termes trs utiliss dans notre pratique de
lanalyse fonctionnelle, on ralise que ceux-ci sont parfois mconnus en dehors de
lhexagone, et la traduction de ces termes pose alors une difficult toute particulire.
Cependant, notre culture technique est riche et notre valeur ajoute nationale en
matire de systmes et de produits industriels concerne prcisment la matrise de
plusieurs points cls tels que, par exemple, la diffrentiation entre le cahier des charges
et les spcifications techniques, ou encore le niveau de sret de fonctionnement
(objectifs des tudes dites FMDS1), le niveau de contrle, les deux niveaux dits de
vrification et de validation, etc. Tous ces points sensibles ont naturellement un lien
direct avec lanalyse fonctionnelle. Elle constitue donc lun des tout premiers maillons
de la chane dans le cycle du projet affrent la ralisation dun systme.

Depuis plus de quinze ans, nous avons form et continuons de former lanalyse
fonctionnelle des ingnieurs et des techniciens issus dentreprises telles que la
SNCF (Direction du matriel), lONERA, le CEA, le groupe THALES ou encore
la division Ligeron du groupe Sonovision. Nous avons expliqu et nous expliquons
toujours nos stagiaires, qui font partie du personnel de ces entreprises, comment, par
exemple, construire et rdiger un cahier des charges fonctionnel (CdCF) ou encore
une spcification technique du besoin (STB), documents souvent crs et diffuss
dans le cadre des projets industriels. Nous savons en effet quun ingnieur est bien
souvent amen durant sa longue carrire, soit rdiger lui-mme de tels documents,
soit devoir les exploiter avec efficacit. Mais ceci nest bien sr quun aspect parmi
beaucoup dautres.

Nous possdons une exprience industrielle acquise au sein de diffrentes entreprises, et


ont eu ainsi lopportunit dappliquer les diffrentes mthodes danalyse fonctionnelle
dans le cadre de projets de ralisation ou de recherche et dveloppement. En tant
quacteurs directs, ils ont pu ainsi largement percevoir et apprcier les difficults
pratiques lies la mise en uvre de telles mthodes sur le terrain, mais aussi mesurer
tous les bnfices susceptibles dtre tirs dune dmarche bien mene. Signalons ce
propos trois difficults particulires qui mritent ici dtre mentionnes.

1 Fiabilit, Maintenabilit, Disponibilit et Scurit.


14 Analyse fonctionnelle des systmes

Tout dabord, comme on peut le constater sur le terrain, la terminologie nest pas
homogne, et chaque entreprise emploie ainsi ses propres termes. Malheureusement,
les documents normatifs, notamment ceux de lAFNOR, narrivent pas toujours
homogniser la terminologie et le vocabulaire dans ce domaine. Un exemple frappant
est la dfinition de simples termes tels que fonction de service, fonction dusage, etc.
Ceci est une premire difficult.

Par ailleurs, lanalyse fonctionnelle nest pas une science exacte. Pour un mme
problme, plusieurs schmas de reprsentation fonctionnelle sont souvent possibles, ce
qui implique donc quil puisse y avoir plusieurs solutions techniques correspondantes.
Afin de minimiser ce problme, les entreprises font ainsi plutt appel des groupes de
travail susceptibles darriver un consensus sur les rsultats et les schmas danalyse
fonctionnelle.

Enfin, signalons un dernier point. Il arrive que des analystes, au lieu de poursuivre
lusage dune mme mthode jusqu la fin dun projet, dcident de changer de
mthode en cours de route. Par exemple, on pourra passer de MISME SADT ou
encore FAST. Comme on peut le constater, un mme dossier danalyse fonctionnelle
comprendra ainsi parfois des schmas lis deux, voire trois mthodes. Ceci est un
facteur de difficult supplmentaire.

Au vu de ces difficults rcurrentes, il nous semble donc crucial que les approches et
techniques de lanalyse fonctionnelle soient enseignes dans les coles dingnieur,
et mieux connues du milieu acadmique. Ainsi, depuis de nombreuses annes, nous
enseignons lanalyse fonctionnelle dans plusieurs coles dingnieurs, telles que le
Cnam, lENSTA, lISTIA dAngers, Tlcom Bretagne (Brest), lEPF, lENSAT
(Maroc) ou encore HECI (Maroc).

Au travers de ces enseignements, nous avons pu constater que les stagiaires des
entreprises et les lves-ingnieurs posaient rgulirement les mmes questions, et en
particulier les suivantes:
-- Quel est le livre de rfrence en analyse fonctionnelle, permettant daboutir
la matrise de cette mthode et de ces techniques?
-- Peut-on trouver des exercices ou des tests type QCM affrents la pratique de
lanalyse fonctionnelle?
-- O peut-on trouver des exemples industriels ralistes, avec, par exemple, un vrai
cahier des charges ou encore une vraie spcification technique du besoin?
-- Comment choisir la bonne mthode ou technique danalyse fonctionnelle
pour tel ou tel projet?
-- Quelle est la procdure suivre pour mener bien les diffrentes tapes
requises pour une analyse fonctionnelle?
Introduction 15

-- Pour un projet o doit tre mene une analyse fonctionnelle, par quelle tche
faut-il commencer en pratique?
-- Comment labore-t-on un dossier danalyse fonctionnelle, en pralable la
rdaction du cahier des charges?

Les rponses ces questions ne sont pas toujours simples. titre dlments de
rponse, nous pouvons tenter ce stade de mettre en avant, pour chacune de ces
questions, quelques points issus de notre vision et de notre exprience.

Sur le plan des sources de rfrence, il existe des ouvrages, en particulier les livres de
R. Tassinari et B. de la Bretesche, qui constituent des rfrences reconnues pour ce qui
concerne la mthode APTE. Malheureusement, un jeune ingnieur qui doit aborder un
projet industriel sur lequel sappliquent beaucoup de contraintes, peut prouver quelques
difficults appliquer une mthode sur la seule base de ces livres. On pourra noter que
les documents normatifs notamment ceux de lAFNOR ne sont pas toujours facilement
applicables. De plus, laccs ces documents nest pas toujours vident.

Le besoin dun livre pratique, qui serait le guide de lanalyse fonctionnelle, se fait
donc notre sens largement sentir. Le prsent ouvrage se fixe prcisment le but de
rpondre ce besoin.

En ce qui concerne la mthode ou langage SADT, le livre de M. Lissandre, qui date


de 1991, constitue toujours un livre de rfrence. Il est plus facilement applicable.

Il existe quelques exercices rsolus, accessibles essentiellement sur Internet. Toutefois,


la plupart des livres nont, pour leur part, pas de chapitre ddi aux exercices ou aux
problmes. Sur ce point, nous avons pu noter que le besoin exprim par les stagiaires
et les tudiants tait totalement justifi. Dans le prsent ouvrage, nous avons donc tent
de mettre un accent particulier sur cet aspect, en prsentant des exercices (rsolus ou
non), ainsi que des QCM, permettant de sassurer de la bonne acquisition des points
fondamentaux, mais aussi de commencer leur indispensable mise en pratique.

On notera enfin que les documents industriels ne sont, en rgle gnrale, pas diffuss
lextrieur, mme lorsquil sagit, par exemple, dun cahier des charges labor dans le
cadre dun appel doffre. Dans le prsent ouvrage, nous proposerons un certain nombre
dlments pratiques de rfrence, en particulier en ce qui concerne les sommaires
affrents aux documents cls produire.

Le choix dune mthode est troitement li au centre de gravit du projet, sans


oublier bien entendu de prendre en compte le niveau de familiarisation de lingnieur
en situation avec les diffrentes mthodes. Nous nous sommes ici bass sur une enqute
16 Analyse fonctionnelle des systmes

de lISdF, aujourdhui IMdR2, afin douvrir des pistes destination des ingnieurs et
techniciens placs devant ce choix important.

Concernant la procdure suivre, nous proposons dans ce livre une procdure dtaille
(cf. section 3.4), esprant avoir ainsi rsolu cette difficult. Ce schma a t labor
dans un cadre industriel.

En ce qui concerne la tche formant le point de dpart de la dmarche, la rponse cette


question sera donne dans les chapitres 2 et 3. La procdure propose (cf. 3.4) clarifiera
galement le point de dpart et la fin du projet dtude danalyse fonctionnelle.

Enfin, concernant laide llaboration dun cahier des charges, on constatera que les
lments affrents un dossier danalyse fonctionnelle, y compris ses annexes, sont
dcrits dans ce livre.

Nous tenons prciser que, dans lindustrie en France, ltat de lart concernant lanalyse
fonctionnelle nest pas forcment celui impos ou souhait par la norme. Cest pourquoi
nous prfrons expliquer nos lecteurs ce qui est rellement pratiqu, plutt que de
rester sur le plan thorique en dtaillant ou en commentant les documents normatifs.

Ce livre aborde tout dabord la notion de besoin, ainsi que les exigences, leur
identification, ainsi que leur formalisation. Puis, les diffrents objectifs de ltude
danalyse fonctionnelle sont lists et clarifis. Nos lecteurs prendront alors connaissance
des principes des mthodes usuelles danalyse fonctionnelle. Enfin, nous exposerons
quelles sont les applications de lanalyse fonctionnelle, notamment llaboration dun
cahier des charges et celle dune spcification technique du besoin.

Nous avons galement jug utile de lister quelques outils informatiques danalyse
fonctionnelle disponibles sur le march.

Nous considrons que notre livre est certes perfectible, mais esprons cependant quil
rponde, au moins en partie, un besoin au niveau des entreprises comme celui des
institutions acadmiques.

Ali Azarian et Yann Pollet


Cnam - 292, rue Saint Martin - 75003 Paris

2 Institut pour la Matrise des Risques.


Chapitre 1

Identification des besoins

Introduction
Lobjectif de toute entreprise est bien sr de rpondre aux besoins de ses clients et
rechercher leur satisfaction. Il arrive bien souvent que le client ne soit pas lutilisateur
final du produit ou du systme, qui se trouve en bout de chane. Ainsi, par exemple, une
rame de mtro est commande et acquise par la RATP (Rgie Autonome des Transports
Parisiens), mais les utilisateurs en sont en fait les usagers. Cependant, on notera que
la satisfaction dun client est en principe troitement lie celle des utilisateurs, ainsi
qu celle des exploitants et des oprateurs de maintenance du systme.

Il est noter que rpondre aux besoins des utilisateurs savre souvent difficile, et ce
pour de nombreuses raisons. Examinons les principales difficults.

Le champ des exigences et des attentes des utilisateurs est excessivement vaste et
vari, et, de ce fait, il est le plus souvent impossible en pratique de rpondre toutes
les exigences.

Certaines exigences, dans des domaines tels que lergonomie, le confort, lesthtique,
etc., peuvent varier dans une trs large proportion, voire de de moins linfini
plus linfini! Ainsi, ce qui est considr comme confortable par certains utilisateurs
ne le sera pas ncessairement pour dautres catgories dutilisateurs. Ce sont ici des
exigences non quantifiables, le plus souvent subjectives, et donc par essence difficiles
satisfaire.

Certaines exigences peuvent donner lieu plusieurs interprtations: ainsi on pourra


souhaiter acheter une voiture robuste, la robustesse devenant donc une exigence
satisfaire. Mais que signifie au juste cette exigence de robustesse? Est-ce que lon
souhaite une voiture qui soit fiable et ne tombe pas en panne? Cest une premire
interprtation. Est-ce que cette exigence est lie la scurit, signifiant quen cas
daccident, on sortira indemne, ou bien que la voiture tiendra le choc? Cest une
autre interprtation. Ou bien, est-ce quon entend par robustesse le fait que le
systme rsiste bien aux agressions diverses (vieillissement, conditions climatiques,
corrosion, etc.)? On se rend bien compte ici que, sur le plan de la satisfaction dune
telle exigence, on est sur un terrain tout fait mouvant et instable.
18 Analyse fonctionnelle des systmes

Les utilisateurs expriment le plus souvent un besoin peru linstant t, sachant qu


linstant t+t, voire plusieurs annes aprs, ce besoin pourra changer, et que dautres
exigences mergeront, voire seront explicitement formules. Ainsi, il y a quelques
annes, le wagon dun train de voyageurs navait pas de prise lectrique, sauf peut-
tre dans les toilettes. Aujourdhui, avec les tlphones portables et les ordinateurs dits
lap top (portables), le besoin dune prise au niveau des siges passager se fait de
plus en plus ressentir. Les exigences des utilisateurs sont donc largement fonction du
paramtre temps et de lvolution technologique.

Pour avoir une bonne visibilit sur les besoins, il conviendrait idalement de mettre
la disposition des utilisateurs un premier systme conu et fabriqu, puis, ensuite,
de collecter les donnes ou les informations affrentes lapprciation de ce systme
durant son exploitation, synthtises pendant la production des donnes de REX. Or,
en rgle gnrale, il faut identifier lintgralit des besoins (explicites et implicites)
avant de concevoir le systme, interdisant une telle pratique.

Par ailleurs, les utilisateurs raisonnent en termes de fonctions et non en termes de


composants ou de matriaux. Ainsi, lacheteur dune voiture nachte bien sr pas
1200 1500 kg de ferraille ou de pices, mais un systme qui lui permettra de se
dplacer! De ce fait, lunivers et le langage des utilisateurs ne sont pas toujours
matriss par le ralisateur-dveloppeur du systme (cf. 2.1.) en charge de dfinir la
solution technique.

Enfin, les exigences sont parfois irralistes. Ainsi, un client qui souhaite disposer dun
systme 100% fiable ou disponible ne sait peut-tre pas quune telle exigence est
irraliste.

Nous essayons dans ce chapitre de traiter les diffrents aspects lis aux besoins.

1. Cycle de vie dun systme


Afin de matriser les aspects lis aux besoins des utilisateurs, il est important de bien
comprendre ce que lon appelle le cycle de vie dun systme ou dun projet.

La Figure 1 ci-aprs prsente de manire schmatique le cycle de vie dun systme


sous la forme dun V. Ce modle de cycle de vie classique, dit cycle en V, conu
lorigine pour les logiciels (modle de dveloppement logiciel), est aujourdhui
retenu avec plus ou moins de nuances pour les systmes. Il est en effet globalement
applicable tout systme, sachant par ailleurs quil sagit dun modle particulier
parmi dautres possibles.
Chapitre 1 - Identification des besoins 19

Figure 1: Prsentation schmatique du cycle de vie dun systme

2. Analyse du besoin
Le cycle de vie dun systme commence par une premire phase appele le plus
souvent analyse du besoin (cf. Figure 1), dont lanalyse fonctionnelle constitue le
pilier principal. Cette phase comprend tout un ensemble dactivits, que lon appelle
galement les tudes amont. Pour lancer un produit sur le march, un nouveau produit
ou une version amliore dun produit existant, il est ainsi ncessaire:
-- Deffectuer une tude de march. Il ne serait en effet pas opportun de se lancer
dans une entreprise de dveloppement si le produit vis na pas de segment
de march identifi, jug suffisant pour assurer son succs commercial. Ainsi,
un constructeur automobile, avant de lancer un nouveau modle de voiture,
effectue naturellement une tude de march, de manire estimer la taille du
segment de march vis, le profil des acheteurs, leur capacit financire, ainsi
que dautres caractristiques lies au marketing comme la tendance du march.
-- Dentreprendre une analyse de la valeur affrente au systme faisant lobjet
du projet (cf. section 6.3). Il sagit ici de slectionner diffrentes technologies
envisageables, avec leur cot respectif.
-- Didentifier les besoins explicites et implicites des clients et utilisateurs potentiels.
-- De formaliser les besoins identifis sous la forme dexigences.
-- De faire une tude de faisabilit sur la base des besoins ainsi formaliss. Par
exemple, si les usagers et voyageurs souhaitaient avoir un train qui roule
1000km/heure, ce besoin ne pourrait tre satisfait ce jour, pour des raisons
videntes lies ltat de lart de la technique. De manire anecdotique,
nombreuses sont les personnes qui souhaiteraient visiter notre galaxie, la voie
lacte, mais, pour linstant, un tel projet nest pas faisable techniquement; il
est du domaine du rve.
20 Analyse fonctionnelle des systmes

-- Dlaborer enfin un dossier davant-projet, comprenant un certain nombre


de notes et des documents affrents lide du projet (volet technique,
comprenant la note de cadrage, le document dorientation ou dinitialisation,
etc.), ainsi que des estimations de cot (volets conomique et financier).

Le dossier davant-projet permettra aux dcideurs ou la hirarchie de dcider de la


poursuite du projet en connaissance de cause. Si la dcision de lancer le dveloppement
du systme ou le projet est prise (dcision positive), alors on entame ce que lon
appelle lanalyse fonctionnelle.

Il convient de noter quun certain nombre dentreprises sont dotes de rfrentiels


internes, notamment en ce qui concerne le phasage ou le cycle de vie dun projet.
Lapproche du cycle en V, comme on la dj indiqu, nest ainsi quune approche
parmi dautres.

titre dexemple, la Figure 2 prsente une telle approche, telle que mise en uvre
dans le domaine de lindustrie ferroviaire. Ce schma, propos dans le cadre du cours
danalyse fonctionnelle destination des agents SNCF, et anim par lun des auteurs, met
en vidence les jalons du projet (points cls Stop or Go, ou Go/No Go), ainsi que
les revues les plus importantes. En matire de documentation, la Figure 7 du chapitre 2
fournit les dtails relatifs aux diffrents documents produits, savoir le CdCF (Cahier
des Charges Fonctionnel), la STB (Spcification Technique du Besoin), le DD (Dossier
de Dfinition), le DJD (Dossier Justificatif de dfinition), le DL (Dossier de Livraison),
et enfin le LS (Livret Suiveur: terme employ dans lindustrie ferroviaire sachant que le
LS nest rien dautre que le carnet ou cahier dentretien).

Figure 2: Prsentation schmatique du cycle de vie dans lindustrie ferroviaire


( SNCF)
Chapitre 1 - Identification des besoins 21

Dans tout ce qui suit, nous nous baserons sur lapproche dite en V du cycle de vie,
illustre sur la Figure 1.

En synthse, nous pourrions dire que lanalyse fonctionnelle, qui constitue le cur de
la phase de lanalyse du besoin, est effectue lorsque:
-- Les besoins explicites et implicites sont identifis et formaliss, produisant ce
quon appelle de nos jours les exigences.
-- On est assur que la faisabilit technique ne pose pas de problme majeur.
-- Le dossier davant-projet contenant les notes ou documents type cadrage,
document dorientation ou dinitialisation, est bien disponible.
-- Les lments affrents la caractrisation du segment de march, ainsi que
des tudes conomiques de type analyse de la valeur, sont bien consultables
(aspect li la faisabilit conomique).

Lanalyse fonctionnelle sapplique un produit ou un systme matriel (par exemple


un ordinateur portable, une souris dordinateur, un rtroprojecteur, un aspirateur,
etc.), un logiciel, quil soit technique (temps rel ou non, en charge de calculs, de
contrle commande, etc.) ou de gestion, un processus (fabrication ou production, par
exemple chane de laminage chaud, ou atelier mcanique de rparation, etc.), une
organisation (par exemple un service dachat, un laboratoire danalyse mdicale, un
supermarch, etc.), ou encore un service ou une prestation (maintenance et aprs-
vente, assistance technique on-line, etc.).

Lanalyse fonctionnelle sapplique dans tous les domaines, tels que les domaines
mcanique, lectrique, la production, la gestion de la qualit, la maintenance, le
soutien logistique intgr, etc.

Cette technique est tout fait adapte lanalyse des systmes dits complexes,
surtout lorsquil sagit dun systme nouveau ou innovant.

Note: Lanalyse du besoin possde une dimension temporelle, laquelle concerne une
chelle souvent trs longue. Ainsi, dans le cas du lancement dun nouveau produit tel quun
nouveau modle de voiture ou davion par exemple, cette phase danalyse du besoin prend
souvent plusieurs mois, voire plusieurs annes.

Il arrive souvent que lanalyste dcide demployer les outils type QQOQCPC ou
encore Mind Map, etc., pour clarifier certains points ds le dpart. Ces techniques
sont dcrites trs sommairement ci-aprs.
22 Analyse fonctionnelle des systmes

2.1. Hexamtre de Quintilien ou QQOQCPC

Le QQOQCPC (signifiant Qui-Quoi-O-Quand-Comment-Pourquoi-Combien


quivalent aux 5Ws: What? Who? Where? When? Why?) est une mthode
empirique de questionnement. Toute dmarche danalyse implique en effet une phase
pralable de questionnement systmatique et exhaustif, en vue de collecter les donnes
ncessaires cette analyse. Lapproche ou technique QQOQCPC est souvent employe
en pralable lanalyse fonctionnelle. Le Tableau 1 prsente lapproche QQOQCPC,
illustre par des questions listes en regard de chaque rubrique.

Note: La dernire rubrique combien est souvent optionnelle. Cest pourquoi on parle
dhexamtre (6).

Tableau 1: Prsentation dun tableau relatif loutil QQOQCPC et ses questions clarifier -
Inspir du cours de Rmi Bachelet (cole Centrale Lille)

2.2. Mind Maps ou cartes heuristiques

Les Mind Maps, aussi appeles topogrammes, schmas heuristiques ou encore cartes
mentales, constituent un outil extrmement efficace de recueil et de mmorisation
des informations utiles. Il sagit dune mthode crative et logique, visant prendre
des notes et consigner des ides. Elle consiste littralement cartographier les
rflexions affrentes un thme donn.
Chapitre 1 - Identification des besoins 23

Cette technique est souvent employe avec le support dun logiciel du commerce, tel
que FreeMind, MindView, Mindjet, etc. (liste non exhaustive). La Figure 3 illustre un
exemple de Mind Map.

Figure 3: Prsentation dun exemple de schma Mind-Map concernant un document XML.


Source: linuxfr.org

Note: Ces deux mthodes, qui savrent tre celles les plus couramment employes, sont
dcrites ici sommairement. Les auteurs considrent toutefois quil existe bien dautres
outils susceptibles dtre mis en uvre avant dentreprendre lanalyse fonctionnelle.

En conclusion, on notera que lon naborde pas une analyse fonctionnelle sans lments
pralables, et avec une simple ide en tte! Il faut ainsi bien prparer le terrain.

3. Mthodes didentification des besoins


Il existe diverses mthodes et techniques permettant didentifier les besoins. Parmi
les diffrentes familles de mthodes, on peut distinguer plusieurs approches.

Nous pouvons, en premier lieu, considrer les approches bases sur lexamen de
documents existants et de donnes, mettant en vidence des indications lies aux
besoins. Il sagit ici de documents relatifs des systmes semblables, comprenant
les cahiers des charges, spcifications techniques, nomenclatures, documents
de vrification/validation/rception ou encore de recette, etc. Le REX (Retour
dExprience), sil existe, fera ici lobjet dun examen approfondi.
24 Analyse fonctionnelle des systmes

En second lieu, nous pouvons considrer les approches bases sur les interviews et les
entretiens tlphoniques: il sagit ici dinterroger les utilisateurs du futur systme, et/
ou les diffrents acteurs cls impliqus dans le projet, afin de collecter et identifier les
besoins. Lanalyste devra ici employer la fois des questions fermes (rponse: oui
ou non) et des questions ouvertes (Que pensez-vous de .?). Il est recommand,
dans ce cas, davoir un canevas de questionnement, afin de ne pas se disperser.

Enfin, nous pouvons considrer les approches bases sur la rdaction dun questionnaire
envoy la fois aux futurs utilisateurs et aux acteurs du projet. Le questionnaire
devra comprendre la fois des questions binaires (questions simples) et des questions
ouvertes, o le rpondant sexprimera, et donnera donc son avis. Un tel questionnaire
est, en principe, structur en trois parties.

Une premire partie est ddie aux informations gnrales concernant le rpondant:
entreprise, activit et taille de celle-ci, fonction du rpondant dans lentreprise, rle
ou responsabilit dans le projet, etc. Il est souhaitable que le questionnaire reste
anonyme. Toutefois, les nom, prnom, ge ou nombre dannes danciennet, fonction
ou position actuelle, etc., du rpondant peuvent tre des questions optionnelles, dont
les rponses ne sont pas indispensables.

Une deuxime partie est souvent ddie ltat de lart actuel, notamment en rapport
avec les systmes semblables, dj en exploitation. En fait, il sagit ici dacqurir une
certaine visibilit quant ltat de lart de ce qui existe, ce que lon appelle souvent
La situation telle quelle est ou The situation as it is. Des questions pourront
tre, par exemple, du type: Comment utilise-t-on un systme semblable?, Quels
sont les motifs dinsatisfaction?, La scurit est-elle respecte actuellement?.

Enfin, une troisime et dernire partie traite rellement les besoins en tant que tels, et
lon y voque la situation comme elle devra tre: cest The situation as it should be.
Il faut ici sefforcer de comprendre pourquoi ce nouveau besoin existe. Des questions
pourront tre du type: Quest ce qui justifie llaboration dune version amliore du
systme, voire dun nouveau systme?, Quels sont les paramtres cls influenant
les besoins?, etc.

La synthse des activits lies la collecte des besoins ou exigences savre ncessaire
afin dorienter lanalyse dans la bonne direction, daller lessentiel et dviter de se
disperser.

Le nombre lev de rponses au questionnaire augmente naturellement la crdibilit


de la dmarche.
Chapitre 1 - Identification des besoins 25

Note: Lanalyse fonctionnelle, contrairement aux ides reues, nidentifie pas les
besoins. Elle ne doit pas non plus conduire crer de nouveau besoin

partir du dossier davant-projet et des rsultats issus de lanalyse fonctionnelle, on


labore alors un cahier des charges fonctionnel (CdCF). Ce document, qui fait lobjet
dun examen approfondi, et dune dcision quant sa diffusion, annonce la naissance
du projet.

La diffrence entre un dossier davant-projet et un CdCF rside dans le fait que, avant
la finalisation du CdCF, le projet nest pas n, alors que, suite la diffusion du CdCF,
le projet est cette fois n.

3.1. Ingnierie des exigences

Depuis quelques annes, beaucoup defforts ont t concentrs sur lidentification


et la formalisation des besoins. Ces activits sont en effet considres comme le
maillon faible du droulement dun projet, car on constate bien souvent des drapages
financiers, dus, dune part, lvolution des besoins, qui conduit modifier de
manire tardive le rfrentiel de dpart, et, dautre part, une srie de re-conceptions
ou modifications consquentes tous les niveaux. De plus, il arrive souvent quune
exigence soit oublie en cours de route: cest ce que lon appelle un orphelin. Dans ce
cas, la traabilit des exigences nest pas respecte.

Une exigence est un nonc exprimant un besoin, une capacit fonctionnelle (du
service ou du produit) ou encore une contrainte lmentaire (contrainte technique,
contrainte de cot ou de dlai), exprim en langage naturel (par exemple: Un
wagon transportant 136 passagers assis) ou encore par le biais dune expression
mathmatique (par exemple: 320km/h < vitesse max < 350km/h). Dans cet
exemple, il y a naturellement conjonction de deux exigences atomiques.

La prise en compte de deux points de vue est ncessaire: dune part la description de
ce dont lutilisateur a besoin, et dautre part la description de ce que le systme doit
faire pour satisfaire cet utilisateur.

Note: Plus tard une erreur dans la spcification est trouve, plus lev sera son cot de
prise en compte.
26 Analyse fonctionnelle des systmes

Les caractristiques attendues dune exigence sont les suivantes:


-- exactitude, ou justesse: lexigence doit tre correcte techniquement
et lgalement. Ainsi, il ne doit pas y avoir ici de contradiction entre les
exigences, ou encore entre des exigences et les besoins oprationnels;
-- compltude: une exigence doit exprimer une ide dans son intgralit, et non
pas partiellement;
-- comprhensibilit: une exigence doit tre non ambigu, cest--dire quune
seule interprtation doit tre possible;
-- vrifiabilit: il devra tre possible dapporter la preuve que le systme
produit satisfait bien lexigence formule;
-- traabilit: lexigence doit tre identifie de manire unique, et toutes ses
modifications doivent tre traces;
-- faisabilit: lexigence doit tre ralisable sur le plan technique, dans les
objectifs fixs de cot et de dlai;
-- indpendance vis--vis de la solution technique: lexigence ne doit pas
imposer de solution technique spcifique.

Les quatre sries dactivits lies ce quon appelle lingnierie des exigences sont:
-- les activits de collecte des besoins: dcouverte, capture et comprhension,
analyse des besoins des utilisateurs et des autres parties prenantes;
-- les activits danalyse des exigences: traduction de ces besoins en exigences
techniques lmentaires, analyse technique des exigences, catgorisation et
classement de celles-ci;
-- les activits de vrification et validation des exigences: analyse individuelle
de la qualit de chaque exigence, analyse de cohrence horizontale (du
mme niveau) et verticale (de niveaux diffrents), et vrification de la
compltude de lensemble des exigences;
-- les activits de modification ventuelles: correction, volution des exigences
conscutives lexcution des diffrents processus dingnierie systme.

Dans un projet, lorsquon a une dizaine dexigences, le chef de projet arrive les
grer, mme en sachant que, lors de larrive aux tests, il pourra y avoir une certaine
combinatoire (chaque exigence pouvant requrir plusieurs tests), et que finalement,
de ce fait, un grand nombre de tests devra tre effectu. En revanche, pour un trs
grand nombre dexigences, il sera absolument indispensable davoir recours un
outil informatique qui viendra en support de lactivit.

Les outils logiciels dingnierie des exigences les plus connus et les plus couramment
employs, sont:
-- DOORS (Telelogic);
Chapitre 1 - Identification des besoins 27

-- Core (Vitech);
-- Reqtify (TNI-Valiosys);
-- RTM (Serena Merant);
-- Caliber-RM (Borland);
-- Requisite Pro (Rational Software).

Note: Lingnierie des exigences est un domaine trs vaste, qui ne peut tre dtaill dans
ce chapitre. La liste des outils indiqus nest videmment pas exhaustive.

3.2. Cycle de dveloppement

Le cycle de dveloppement dun systme dbute lissue de la production du CdCF.


Aprs avoir labor ce document, il convient alors de rdiger la STB (Spcification
Technique du Besoin) affrente au systme raliser. Dans le cas o le systme est
complexe, il sera en gnral ncessaire de dcliner la STBS (STB du Systme) en
diffrentes STBSS (STB Sous-Systme) ou STBE (STB quipement). Lobjectif de
la phase de spcification technique consiste en fait rpondre aux questions suivantes:
Quelles sont les attentes vis--vis du systme compte tenu des besoins? et Que doit
faire le systme et avec quelles performances?. Le chapitre 7 dcrit dans le dtail le
contenu dun document de STB, ainsi que les raisonnements qui accompagnent la phase
de spcification.

La STB est un document de rfrence dans la plupart des projets, car elle est
lexpression fige dun CdC (cf. 7.2).

La STB doit faire lobjet dune revue formelle dite revue de spcification.

Une fois la STB approuve, il sagit alors de progresser vers les phases ou tapes
conceptuelles. Dabord, on mne la conception gnrale du systme, avec slection
de technologies et doutils de dveloppement, llaboration de larchitecture du
systme, la dfinition des interfaces externes et internes. Ensuite, il convient de
passer de la conception la dfinition des composants ou produits. Il sagit alors de
la conception dtaille.

Suite la vrification de la conception, les documents de conception gnrale et de


conception dtaille font lobjet dune revue formelle, de manire tre approuvs,
puis diffuss.

La logique industrielle affrente ce processus est illustre schmatiquement par le


tableau ci-aprs (Tableau 2).
28 Analyse fonctionnelle des systmes

DOCUMENT
PHASE QUESTIONS SE POSER OBSERVATIONS
LABOR
Quels sont les besoins ou les
Le CdCF est orient vers
exigences? Pourquoi un tel Dossier davant
les besoins en fonction.
besoin? projet Dossier
Le CdC est plus gnral,
Analyse du besoin Quest ce qui ferait disparatre danalyse
car il contient dautres
ce besoin? fonctionnelle -
lments notamment des
Quest ce qui ferait changer ou CdCF
indications de cots.
voluer ce besoin?
STBS (STB Le STB, une fois
Quattendons-nous du systme?
Systme) approuve, est un
Quelles sont les fonctionnalits
STBSS (STB document de rfrence.
Spcification et les performances attendues
Sous-systme) Tout cart ou demande de
qui rpondent aux besoins
et STBE (STB modification fera lobjet
identifis?
Equipement) dun avenant.
Comment faut-il faire?
Solution technique
Quelles solutions techniques?
Conception retenue aprs valuation
Quelles technologies et quelle
Conception gnrale et et comparaison avec
architecture?
dtaille dautres solutions
Quelles sont les interfaces
alternatives.
externes et internes?
Comment raliser ou crer le Dossier de
systme suite sa conception? fabrication ou
Ralisation Quel processus de fabrication et de ralisation Parfois les tests sont
Dveloppement de production? Quels sont les (DF ou DR). intgrs dans cette phase.
contrles qualit du systme en Dossier de
cours de production? contrle qualit

Tableau 2: Logique de la dmarche industrielle de production de systme

Cette logique, base sur le phasage du projet, peut tre traduite par la Figure 4. On
met en premier lieu les fonctions en regard des besoins: cest le rle de lanalyse
fonctionnelle. Ensuite, on essaie de trouver des solutions techniques pour les fonctions:
cest le rle de la conception du systme.

Ce quil convient absolument dviter est de court-circuiter ce schma (Figure 4),


en mettant directement les solutions techniques en face des besoins.

Figure 4: Le passage logique selon ltat de lart dans lindustrie en France


Chapitre 1 - Identification des besoins 29

Au vu de lensemble des lments qui viennent dtre exposs, on comprend que


la phase danalyse qui vise identifier les fonctions revte un caractre absolument
essentiel pour la bonne comprhension du systme ou du produit raliser. Ainsi, il
est fortement recommand de ne jamais court-circuiter cette tape de la dmarche!

Aprs la ralisation et la fabrication du systme (dans le cas dun logiciel, il sagit


en particulier de la programmation), on commence alors lactivit de test. Il sagit de
faire des tests unitaires en lien avec la conception dtaille dj labore. Ensuite,
on effectue les tests dintgration ou dassemblage. Les rsultats de ces activits
doivent tre conformes la conception gnrale, et notamment larchitecture du
systme, telle quelle a t dfinie lors de la conception gnrale.

Lactivit dintgration peut tre mene selon diffrents types de stratgies:


-- lintgration horizontale: on intgre deux ou plusieurs composants du mme
niveau;
-- lintgration verticale (descendante ou ascendante): il sagit dans ce cas
dintgrer deux ou plusieurs composants de niveaux diffrents;
-- lintgration big bang ou tout azimut: on intgre alors en mme temps
dans toutes les directions possibles envisageables.

Une fois le systme construit, il convient deffectuer des tests de vrification et de


validation. Le systme devra tre ensuite rceptionn par le client ou son reprsentant.
Dans le cas dun logiciel, on emploie le terme recette ou encore qualification. La
validation est dabord interne, cest--dire effectue par lquipe de dveloppement
ou le personnel de lentreprise contractante. Ensuite, il sagit de sengager dans la
validation externe, mene soit par le client ou les futurs utilisateurs, soit par leurs
reprsentants.

Un compte-rendu dat et sign par les parties prenantes doit venir formaliser le
rsultat de cette activit. Dans le cas dun logiciel, on parle de PV (Procs Verbal)
de recette.

La validation dun systme se fait toujours par rapport ses spcifications, et non par
rapport au CdC. Ce point constitue souvent un point de litige, conflit potentiel entre le
client ou donneur dordre et le dveloppeur-ralisateur du systme.

Le systme est souvent livr avec un dossier de livraison (DL). Ce dossier comprend
naturellement le manuel utilisateur.
30 Analyse fonctionnelle des systmes

3.3. Exploitation, maintenance et retrait de service

Une fois le systme rceptionn, et lautorisation de son exploitation ou son


utilisation accorde, on entre alors dans la phase dite dexploitation et de
maintenance du systme. Cette phase possde une chelle temporelle diffrente du
cycle de dveloppement. En effet, on construit un train en moins de 2 ans, mais
on lexploite et on effectue sa maintenance durant 40 ans. Le livret suiveur (LS)
ou carnet dentretien (CE) permet aux oprateurs de maintenance deffectuer la
maintenance prventive ou programme.

Quand le systme arrive en fin de vie, on essaie de dmanteler ce systme et de


rcuprer certains constituants. Le dmantlement est suivi dune mise au rebut, du
transport et du recyclage des matriaux.

Ces tches, qui concernent les activits en aval de la vie du systme, prennent de plus
en plus dimportance, et ce pour les raisons suivantes:
-- Les socits sont de plus en plus sensibles la prservation de lenvironnement
et la rduction de la pollution. En consquence, il ne peut plus tre question
de simplement abandonner un systme dsuet ou en fin de vie dans la nature.
-- Il est souhaitable de rcuprer ce quil est possible de rcuprer. En effet, nos
ressources mondiales sont globalement limites, et donc, au lieu de se lancer
dans une production aveugle et sans souci, il semble ncessaire de prserver,
dans la mesure du possible, et dans le cadre de la loi, les ressources de notre
plante.
-- Le segment de march affrent au dmantlement et au recyclage est immense.
Un pays comme lInde ralise un chiffre daffaires colossal en dmantelant les
bateaux, les navires, les avions et les trains, etc., arrivs en fin de service. De
mme, dans les pays scandinaves, de petites entreprises essaient de recycler
des matriaux de tlphones portables ou des ordinateurs.

3.4. Particularits du cycle en V

Le cycle en V, dans la partie du cycle de dveloppement, vhicule plusieurs messages


implicites quil est important de noter.

Ce cycle est compos dune branche descendante, qui est en fait la branche danalyse,
o lon part du besoin global relatif au systme, et o lon va vers plus de dtails.
Lapproche retenue pour cette branche est top-down. loppos, la branche ascendante
du V part des lments de niveaux infrieurs, et va vers le systme global: cest la
partie de synthse, qui est une approche bottom-up.