AG3255 Contrats de L'ingénierie - Annexe 2 - Dispositions Techniques (Partie 1)

Réf.
: AG3255 V1
Contrats de l’ingénierie -
Date de publication :
10 juillet 2005
Annexe 2 : dispositions
techniques (partie 1)
Cet article est issu de : Génie industriel | Conception et Production
par Gilles CASTAN
Résumé Le contrat de maîtrise d’œuvre doit préciser bon nombre d’informations

concernant le Programme, les lots techniques, les phases d’exécution, les tâches à
accomplir. Certains points ne sont pas spécifiques à ce type de contrat, d’autres sont
fortement liés aux opérations de réalisation et à la structure d’organisation. Cet article
prend soin de présenter les concepts techniques de base afin de dissiper les problèmes
d’incompréhension mutuelle.
Pour toute question :

Service Relation clientèle
Techniques de l’Ingénieur
Immeuble Pleyad 1 Document téléchargé le : 02/08/2018
39, boulevard Ornano
93288 Saint-Denis Cedex Pour le compte : 7200049459 - universite savoie mont blanc // 130.190.247.202
Par mail :
infos.clients@teching.com
Par téléphone :
00 33 (0)1 53 35 20 20 © Techniques de l'Ingénieur | tous droits réservés
Ce document a ete delivre pour le compte de 7200049459 - universite savoie mont blanc // 130.190.247.202
Contrats de l’ingénierie
Annexe 2 : dispositions techniques (partie 1)
par Gilles CASTAN
Direction juridique de Thales Engineering & Consulting
1. Programme ................................................................................................ AG 3 255 – 2

1.1 Contenu du programme ............................................................................. — 2
1.1.1 Objectifs fondamentaux du Client..................................................... — 2
1.1.2 Données de référence ........................................................................ — 2
1.1.3 Contraintes .......................................................................................... — 2
1.1.4 Besoins ................................................................................................ — 3
1.1.5 Exigences ............................................................................................ — 4
1.1.6 Faisabilité ............................................................................................ — 8
1.2 Démarche de programmation .................................................................... — 8
1.2.1 Cahier des charges fonctionnel ......................................................... — 9
Parution : juillet 2005 - Ce document a ete delivre pour le compte de 7200049459 - universite savoie mont blanc // 130.190.247.202
1.2.2 Spécification technique de besoin .................................................... — 9

2. Lots techniques ........................................................................................ — 13
Pour en savoir plus........................................................................................... Doc. AG 3 259
omme tout contrat, le Contrat de maîtrise d’œuvre doit préciser, notam-

C ment au plan technique, ce qui doit être fait, comment cela doit être fait et
quand cela doit être fait :
— le Programme décrit ce qui doit être fait ;
— les lots techniques décrivent les parties du Programme à la charge du Maître
d’œuvre ;
— les Phases d’exécution du Contrat de maîtrise d’œuvre décrivent les tâches
à accomplir par les parties et l’ordre dans lequel elles s’accomplissent ;
— les devoirs du Client et des tierces parties permettent de lister les activités
extérieures à la maîtrise d’œuvre qui lui sont opposables ;
— la structure d’organisation du Projet a pour objet de décrire l’organisation
humaine de celui-ci ;
— le planning prévisionnel du Projet a pour objet de décrire l’organisation
temporelle de celui-ci.
Les trois derniers points sont classiques. Ils ne sont pas spécifiques au Contrat
de maîtrise d’œuvre et se retrouvent largement dans toute forme de contrat. En
revanche, les trois premiers points sont très largement spécifiques aux opéra-
tions de réalisation d’investissement. Des non-spécialistes de la matière parle-
raient de cahier des charges : c’est clairement le cas pour le Maître d’œuvre.
Une attention particulière a été portée à l’identification des concepts de base à
connaître en matière technique pour partager un langage commun qui permette
à tous de comprendre la même chose. En effet, selon notre expérience, l’échec
d’un Projet vient trop fréquemment d’une incompréhension mutuelle. Les dispo-
sitions techniques de l’exécution font l’objet de [AG 3 256]. Les dispositions
financières (annexe 3) sont traitées dans [AG 3 257].
Nota : les opinions exprimées sont celles de l’auteur et n’engagent pas son employeur.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur AG 3 255 − 1
tiwekacontentpdf_ag3255 v1 Ce document a ete delivre pour le compte de 7200049459 - universite savoie mont blanc // 130.190.247.202
CONTRATS DE L’INGÉNIERIE _____________________________________________________________________________________________________________
1. Programme Commentaire général concernant le contenu du Programme :

Pour des raisons de commodités, la présentation du contenu standard
du Programme est issue de la pratique en vigueur dans le secteur de
l’immobilier public. La terminologie n’est pas nécessairement la même
Commentaire général relatif au Programme : dans tous les domaines. Par exemple, les normes qualité définissent la
Selon les règles habituelles de l’ingénierie française, le Programme contrainte comme : « caractéristique, effet ou disposition de conception
est le nom donné aux spécifications techniques dont la mise en œuvre qui est rendu obligatoire ou qui a été interdit pour quelque raison que ce
incombe au Maître d’œuvre. soit. Aucune autre possibilité n’est laissée ». Ainsi envisagée par les nor-
Lorsque le Client n’est pas en mesure d’établir lui-même tout ou par- mes qualité, la contrainte couvre le domaine des exigences (§ 1.1.5) aussi
tie du Programme, il peut soit associer quelqu’un (le Maître d’œuvre au bien que des contraintes (§ 1.1.3) en matière de programmation publique.
travers de ce Contrat ou bien une tierce partie au travers d’un contrat
de prestations de services spécifique) à l’accomplissement de cette 1.1.1 Objectifs fondamentaux du Client
tâche ou même la déléguer de façon pure et simple. Néanmoins, le
Programme demeure dans tous les cas établi sous l’autorité et la Dans le cadre de l’élaboration du Programme, les objectifs fonda-
responsabilité du Client. Quelle que soit l’option choisie, les Parties mentaux du Client sont les suivants :
devraient tenir compte des commentaires qui suivent sur le contenu du
— …;
Programme et de démarche de programmation.
— ….
Commentaire concernant les objectifs fondamentaux du Client :
■ Option 1 : le programme est déjà finalisé. Le texte est à élaborer au cas par cas.
L’expression du besoin du Client incluant la détermination, d’une Quel que soit le Projet en cause, il est primordial que le Client soit
part, du besoin fonctionnel par un cahier des charges fonctionnel (ci- clair sur la hiérarchie de ses préoccupations en termes de qualité, coûts
après dénommé CDCF) et, d’autre part, du besoin spécifié par une et délais. Dans le cadre d’un Programme, il est tout aussi important
spécification technique de besoin (ci-après dénommée STB), d’éviter la déformation des objectifs du Client, l’erreur d’objectif résultant
l’ensemble constituant le Programme (ci-après dénommé Pro- d’une insuffisance de l’analyse des besoins, la présence d’objectifs mul-
gramme) est décrit dans le document référence …, du …, dont les tiples et contradictoires, la confusion entre objectifs et solutions, etc.
Parties ont chacune une copie et qu’elle déclarent parfaitement
connaître.
1.1.2 Données de référence
Le Programme représente le référentiel imposé par le Client au
Maître d’œuvre permettant de définir tous les éléments du Produit, Les données de référence (ci-après dénommées Données de Réfé-
leur composition, leur importance, leurs relations et leurs exigences rence) ont pour objet d’identifier les points essentiels qui relèvent de
particulières et la référence précise des textes assujettissant le Pro- l’existant. Dans le cadre de l’élaboration du Programme, les Don-
duit à réaliser à des normes ou spécification. nées de Référence sont les suivantes :
■ Option 2 : la réalisation du Programme est en partie déléguée au — …;
Maître d’œuvre. — ….
Le Programme (ci-après dénommé Programme) sera établi par les Commentaire concernant les Données de Référence :
Parties sous le contrôle du Client. Le Programme désigne tous les
Le texte est à élaborer au cas par cas.
objectifs du Client qui investi dans le Produit. Il permet, notamment,
de vérifier l’opportunité et la faisabilité du Projet par rapport aux En matière de programmation publique française, les Données de
objectifs du Client. Le prix de cette assistance à la programmation Référence (d’habitude seulement dénommées : données) (data) sont
fait l’objet d’une rémunération sur la base des bordereaux de prix rassemblées aux fins d’identifier les points essentiels qui relèvent
unitaires figurant en annexe 3 [AG 3 257]. de l’existant.
Dans le cas d’une opération immobilière, on peut citer par exemple :
Commentaire relatif au prix de la prestation fournie relative à — les plans topographiques généraux ;
l’établissement du Programme : — les reconnaissances préliminaires du sol et du sous-sol ;
Pour participer à la réalisation du Programme, le recours à un prix, — les voies et réseaux divers existants, etc.
effectivement calculé au temps passé, est tout à fait logique. Il est
impossible à la date de conclusion du Contrat de maîtrise d’œuvre de
prévoir la durée des prestations nécessaires pour parvenir à l’établisse- 1.1.3 Contraintes
ment d’un Programme dont la pertinence et la fiabilité dépendent avant
tout de l’implication du Client. Il est donc impossible de quantifier par Les contraintes (ci-après dénommées Contraintes) ont pour objet
avance le travail à effectuer et même, parfois, de le spécifier avec pré- d’identifier la réglementation applicable à tous les aspects de la
cision. En l’espèce, le Maître d’œuvre ne « vend » pas de « l’ingénierie » mise en œuvre du Projet. Dans le cadre de l’élaboration du Pro-
mais du « service », véritablement du temps passé. gramme, les Contraintes sont les suivantes :
— …;
Sont regroupées dans cette annexe 2 [AG 3 255] [AG 3 256] l’ensem-
ble des dispositions ayant pour objet d’exprimer des exigences d’ingé- — ….
nierie liées au Contrat et les prestations techniques à accomplir par Commentaire concernant les Contraintes :
toutes les parties prenantes. Le texte est à élaborer au cas par cas.
En matière de programmation publique française, les Contraintes
(constraints) sont, avant tout, celles qui résultent de l’appréhension de
la réglementation applicable à tous les aspects de la mise en œuvre
1.1 Contenu du programme du Projet. Dans leur expression théorique, les Contraintes ne sont
pas propres au Projet. L’exemple des autorisations d’exploiter peut
être pertinent. Certaines règles proviennent de dispositions générales
Le Programme comprendra les éléments suivants : les objectifs qui ne peuvent être méconnues par aucune des parties prenantes : ce
fondamentaux (§ 1.1.1), les données de référence (§ 1.1.2), les sont les contraintes. D’autres proviennent des textes de demande
contraintes (§ 1.1.3), les besoins (§ 1.1.4), les exigences (§ 1.1.5) et la d’autorisation et de l’autorisation elle-même : ce sont des exigences
faisabilité (§ 1.1.6). qui doivent être traitées comme telles (§ 1.1.5).
AG 3 255 − 2 © Techniques de l’Ingénieur
_____________________________________________________________________________________________________________ CONTRATS DE L’INGÉNIERIE
Dans le contexte de ce document, il est impossible d’envisager toutes ■ Dans les systèmes, une place particulière doit être réservée au logi-
les normes susceptibles de s’appliquer à tous les Projets. Un thème ciel (création intellectuelle consistant en concepts, informations, ins-
est pourtant susceptible d’être envisagé en toutes circonstances : tructions, procédures, règles ou transactions ainsi que documentation
c’est l’obligation de sécurité (safety duty) qui, même dans le silence et données associées liées au fonctionnement d’un système informati-
du Contrat, pèse sur tous les opérateurs économiques. Peu importe que de traitement de l’information) (en anglais : software) (concernant
que le devoir de sécurité ait un fondement général ou spécial, qu’il ait les logiciels, voir le commentaire général sur les facteurs qualité au
une origine légale ou jurisprudentielle, qu’il soit de nature contractuelle paragraphe 1.1.5 et le commentaire général sur les phases d’exécution
ou extracontractuelle ou qu’il porte sur les personnes ou les biens : il du Contrat au paragraphe 1 de [AG 3 256]. Les catégories principales de
doit être mis en œuvre pendant toute la durée de vie du Produit (de sa logiciels rencontrées sont les suivantes (classés par ordre alphabétique
conception à sa destruction). français) :
Selon nous, le Client n’a pas à rappeler l’existence de ce devoir géné- — logiciel d’application (application software) : logiciel propre à
ral dans le cadre du Programme. En revanche, certaines demandes par- des applications particulières ;
ticulières peuvent être incluses dans les exigences (§ 1.1.5).
— logiciel associé (associated software) : logiciel présenté sur un
support spécifique à l’informatique (CD-ROM, disque, disquette, etc.),
1.1.4 Besoins conçu pour fonctionner avec un certain type de matériel mais dissocia-
Les Besoins (ci-après dénommés Besoins) ont pour objet d’identi- ble de celui-ci au stade de la fourniture (tels que logiciels de bureauti-
fier le Produit. Dans le cadre de l’élaboration du Programme, les que, logiciels de banc d’essai livré sur disquette, etc.) ;
Besoins sont les suivants : — logiciel de base (basic software) : ensemble des programmes
— …; nécessaires au fonctionnement général d’un système de traitement de
— …. l’information. Il comprend l’ensemble des programmes de traduction
Commentaire concernant les Besoins : de langages (compilateurs), le logiciel système, les programmes de
Le texte est à élaborer au cas par cas. gestion de la bibliothèque de programmes et de fichiers et divers pro-
grammes standards (tri, opérations mathématiques, etc.) ;
En fonction du Projet en cause, les Besoins (needs) sont relatifs à
l’expression des désirs du Client en termes de surfaces, volumes, — logiciel croisé (cross software) : logiciel fonctionnant sur un cal-
liaisons, etc., nécessaires à la satisfaction des besoins fonctionnels et, culateur A et qui génère du logiciel pour un calculateur B ;
plus généralement, en termes de qualité, coûts, délais, etc. Anticipant
— logiciel sur étagère (off-the-shelf software) : logiciel déjà déve-

le point suivant relatif aux Exigences, on peut affirmer que les Besoins loppé et utilisable tel quel, avec ou sans modification ;
décrivent le Produit alors que les exigences décrivent les caractéris-
tiques attachées au Produit. — logiciel incorporé (firmware) : combinaison d’éléments matériel
L’identification des Produits sur lesquels porte le Contrat est fonda- et d’instructions ou données qui réside sur un support matériel, consti-
mentale. En effet, c’est un des éléments qui clarifie le champ des obli- tuant du logiciel uniquement lisible et qui ne peut pas être modifié par
gations du Maître d’œuvre. les instructions d’un programme. Il est indissociable des équipements
La description peut être très différente selon les cas. Elle dépend de avec lesquels il est appelé à fonctionner ;
la nature du Produit escompté. On peut trouver des descriptions très — logiciel intégré (built-in-software) : logiciel associé ou incorporé
littéraires, notamment pour des Produits statiques courants tels dans un équipement de traitement de l’information embarqué ;
qu’immeuble, pont, route, silos à grain, etc. De telles descriptions ne
— logiciel non développé (non-developmental software) : logiciel
sont pas adaptées à certains Produits dynamiques. Ainsi, certains
livrable, dont le développement n’est pas compris dans le contrat, mais
Produits sont décrits comme un process ou un système.
qui est fourni par le Client ou une tierce partie ;
■ Le Produit peut être décrit comme un process. Ce terme issu de
l’anglais process désigne deux choses que l’on doit distinguer en sui- — logiciel réutilisable (reusable software) : logiciel développé pour
vant les explications de Michel Grout [64] : satisfaire les exigences d’une application et qui peut être utilisé en tota-
— le terme processus désigne deux aspects d’une installation de lité ou en partie pour satisfaire les exigences d’une autre application ;
production, l’un descriptif, l’autre matériel : — logiciel de test (test software) : logiciel destiné à montrer le bon
• aspect descriptif : c’est l’ensemble des opérations détaillées d’éla- fonctionnement d’un matériel ou d’un équipement. Un logiciel de test
boration d’un produit fini devant posséder les caractéristiques imposées peut être de type go/no go ou de type recherche d’avaries.
dans les limites de tolérances fixées, selon un procédé déterminé, Lorsque le Projet porte sur des Produits dynamiques (système,
• aspect matériel : c’est l’installation proprement dite, comprenant procédé industriel, etc.), il est opportun que le Produit envisagé soit
tous les appareils nécessaires à la transformation des matières premières. caractérisé par des plans liminaires. Dans le domaine du process
— le terme procédé est la méthode à suivre, pour obtenir un pro- industriel, ces plans sont usuellement représentés par des schémas
duit. Le procédé est immatériel et se présente sous la forme d’un livre blocs (block drawings). Le schéma bloc, ou schéma fonctionnel, décrit
du procédé (process data book). l’ensemble des étapes (réaction, séparation, mise en forme, etc.) qui
■ Le Produit peut être décrit comme un système (system). Le système conduisent de la matière première au produit fini. Il est construit à partir
est un ensemble d’éléments en interaction dynamique (personnel, maté- de :
riel, logiciel, procédures, etc.) organisés en vue de remplir un certain
— blocs rectangulaires : chaque bloc représente une fonction à
nombre de fonctions opérationnelles. Les fonctions primaires du sys-
assurer ;
tème correspondent aux tâches, actions et activités essentielles pour
assurer la satisfaction du Programme sur la totalité du cycle de vie du — traits : les traits munis de flèches pour indiquer le sens de l’écou-
système. Un système complexe peut utiliser des installations déjà opé- lement, représentent les flux de matières, d’entrée, de liaison et de
rationnelles, des produits déjà développés ou à développer. Il est fré- sortie.
quemment décomposé en différents sous-systèmes (aussi parfois C’est un document simple :
dénommés segments). Lorsqu’elle s’attache à la composante humaine
— de présentation du procédé ;
d’un système, la science de l’ingénierie système prend en considération
l’éducation, la formation, les compétences critiques, etc. Lorsqu’elle — de compréhension du fonctionnement d’une étape de procédé et
s’attache aux produits et aux outils d’un système, la science de l’ingénie- d’un équipement.
rie système prend en considération la technologie. Lorsqu’elle s’attache Dans le cas d’un procédé continu (continuous process), on précise
au processus d’un système, la science de l’ingénierie système prend en à chaque bloc les paramètres de marche, les débits des flux, leur
considération l’analyse du Programme, l’analyse de l’architecture du sys- nature, les charges thermiques, etc. On identifie également les para-
tème, l’analyse de la valeur et des risques, etc. mètres critiques et les points durs à résoudre pour développer le procédé.
Dans le cas d’un procédé discontinu (intermittent process), chaque La SDF est la propriété d’un Produit telle que ses utilisateurs puis-
étape est décrite à l’aide d’un diagramme séquentiel précisant le sent accorder une confiance justifiée dans le service qu’il leur délivre.
déroulement des opérations qui sont effectuées à cette étape, en fonc- Le service désigne le comportement du Produit tel que perçu par un ou
tion du temps et en précisant les quantités mises en jeu. Le contenu plusieurs autres produits/systèmes interagissant avec lui, à savoir ses
des diagrammes séquentiels s’affine en fonction de l’avancement des utilisateurs physiques ou humains. L’obtention de cette propriété
études. nécessite de maîtriser un certain nombre d’entraves qui sont les cau-
Notons qu’il peut arriver que les schémas blocs ne puissent pas être ses (notion de faute) de déviation du service délivré par rapport à celui
intégrés au Contrat et ne soient qu’une donnée de sortie de l’une des spécifié (notion de défaillance). Cette maîtrise résulte de la mise en
premières phases d’étude. œuvre de moyens (méthodes, outils et solutions) pour procurer l’apti-
Un Produit peut être considéré comme complexe. La complexité tude et la confiance en cette aptitude, à délivrer un service sur lequel
est la caractéristique portant sur la difficulté à comprendre un élément on puisse placer sa confiance :
d’un ensemble ou un ensemble de par les relations entre tout ou partie — l’obtention de cette aptitude résulte de la combinaison de
de ses éléments. Un Produit complexe devrait être considérée comme moyens de prévention (par construction) des fautes, ainsi que de tolé-
tel par les Parties lorsqu’il répond aux critères suivants : rance (par redondance) aux fautes résiduelles ;
— il est trop complexe (complexité liée à la taille ou à la technique) — la validation de cet acquis résulte de la combinaison de moyens
pour ne pas être décomposé dans la relation client-fournisseur ; d’élimination (par vérification) et de prévision (par évaluation) des
— il définit une unité fonctionnelle/opérationnelle telle que la fautes.
somme des Dossiers de Définitions des articles qui le composent ne L’expression des propriétés attendues du Produit (en phase de spéci-
suffit pas à l’appréhender ; fication) ou les mesures permettant d’apprécier la qualité du service
— il doit être géré en tant qu’article de configuration dans la relation délivré (en phase opérationnelle) résultant des entraves et des moyens
client-fournisseur. de s’y opposer sont généralement :
Un produit est toujours envisagé par sa structure et par son environ- — fiabilité (reliability) : aptitude d’un Produit à accomplir une fonc-
nement. L’environnement est l’ensemble, à un moment donné, de tion requise, dans des conditions données, pendant une durée donnée.
toutes les conditions et influences extérieures auxquelles un Produit Le terme fiabilité est également utilisé comme caractéristique de fiabi-
est soumis. L’environnement peut être induit (conditions externes à un lité désignant une probabilité de succès ou un pourcentage de succès.
système et engendrées par son fonctionnement) ou naturel (conditions On peut substituer au concept de durée, toute autre grandeur ou unité
engendrées par les phénomènes naturels et dont les effets sont res-
appropriée (nombre de cycles par exemple). La fiabilité se décompose

sentis par le système, qu'il soit au repos ou en fonctionnement). en différents concepts parmi lesquels :
• fiabilité apparente (apparent reliability) : fiabilité estimée en pre-
nant en compte toutes les défaillances observées en exploitation,
1.1.5 Exigences que ces défaillances soient ou non imputables au bien,
• fiabilité estimée (assessed reliability) : fiabilité d’un dispositif
Les exigences (ci-après dénommés Exigences) ont pour objet déterminée par la valeur limite ou les valeurs limites de l’intervalle de
d’identifier les performances escomptées du Produit. Dans le cadre confiance associé à un niveau de confiance donné et basée sur les
de l’élaboration du Programme, les Exigences sont les suivantes : mêmes données que la fiabilité observée de dispositifs nominale-
ment identiques,
— …; • fiabilité extrapolée (extrapolated reliability) : extension par une
— …. extrapolation ou une interpolation définie de la fiabilité observée ou
estimée à des durées et/ou des conditions différentes de celles
Commentaire général concernant les Exigences : correspondant à la fiabilité observée ou estimée,
Le texte est à élaborer au cas par cas. • fiabilité intrinsèque (intrinsic reliability) : fiabilité limitée aux
Les Exigences (requirements) sont avant tout celles qui résultent défaillances provoquées par des causes dues au bien lui-même,
de la volonté du Client pour la mise en œuvre du Projet. Dans leur indépendamment de celles provoquées par des causes extérieures à
expression théorique, elles sont propres au Projet lui-même et ne ce bien (par exemple, par des équipements qui lui sont associés, par
découlent pas des normes applicables (ce qui les distingue nettement des conditions d’environnement non prévues ou par une mauvaise
des Contraintes). utilisation). Elle qualifie une valeur déterminée dans des conditions
de maintenance et d’exploitation supposées idéales,
L’expression des Exigences est fondamentale pour la réussite de
tout Projet. Elles représentent la base potentielle des garanties spé- • fiabilité observée (observed reliability) : il s’agit de qualifier une
cifiques que le Client peut choisir de réclamer. Elles représentent valeur déterminée d’exploitation et de maintenance données. Pour
aussi l’un des principaux postes de réserves éventuelles exprimés des dispositifs non réparés (non repaired devices), c’est le rapport
sous la forme de prérequis que le Maître d’œuvre doit communiquer au du nombre de dispositifs qui, à la fin d’une période de temps don-
Client avant la signature du Contrat de maîtrise d’œuvre. On peut citer née, ont accompli leurs fonctions de façon satisfaisante au nombre
par exemple : total de dispositifs figurant dans l’échantillon au début de la période.
Pour un ou des dispositifs réparés (repaired devices) c’est le rap-
— les éventuelles dates de mise en service ; port du nombre de fois où un dispositif (ou des dispositifs) a accom-
— les performances qualitatives et quantitatives ; pli ses fonctions de façon satisfaisante pendant une période de
— le niveau de qualité exigible de la fourniture requise ; temps donnée au nombre total de fois où le ou les dispositifs ont été
— les groupes et sous-groupes d’ouvrages, d’équipements, etc. ; appelés à fonctionner pendant la même durée,
— l’identification du budget disponible du Client ;
— la quantité maximale de postes de travail à prévoir pour remplir • fiabilité opérationnelle (operational reliability) : fiabilité estimée
certaines fonctions. et établie par un calcul d’après les résultats observés pendant une
certaine durée d’exploitation ; elle est souvent exprimée par le
Nota : il faut raisonner en poste de travail et non pas en nombres de salariés. En effet, il est
illusoire de pouvoir s’engager sur un nombre de salariés : tout dépend de l’organisation interne temps moyen entre défaillances. Elle qualifie une valeur déterminée
du Client, de la loi applicable, de la convention collective, des accords d’entreprise, des usages dans des conditions d’exploitation et de maintenance données,
internes à l’entreprise et au site concerné.
• fiabilité prédite (predicted reliability) : pour des conditions don-
Commentaire général concernant la sûreté de fonctionnement : nées d’utilisation et compte tenu de la conception d’un dispositif, fia-
En fonction des caractéristiques du Projet, le Client peut choisir bilité calculée à partir des fiabilités observées, estimées, extrapolées
d’exprimer des exigences spécifiques en termes de sûreté de fonc- de ses composants ; elle prend compte l’état de maturité (concep-
tionnement (dénommée ci-après SDF) (dependability). tion, fabrication) du dispositif,
• fiabilité prévisionnelle (scheduled reliability) : fiabilité établie — aptitude au soutien (supportability) : mesure du degré auquel il
par un calcul prenant en compte la somme des taux de défaillance de est possible de fournir, en quantité suffisante, toutes les ressources
l’ensemble des composants d’un bien pour des conditions données nécessaires au fonctionnement et à la maintenance du Produit. Le pro-
d’utilisation et compte tenu de la conception du bien. Les résultats gramme d’évaluation de l’aptitude au soutien a pour objets de fournir
obtenus par un calcul prévisionnel doivent être considérés avec pru- des données mesurées permettant d’estimer la disponibilité, le coût de
dence, leur validité dépendant des hypothèses préalables. Il s’agit en possession, les besoins en moyens de soutien, de mettre en évidence
effet de qualifier une valeur numérique attribuée à une grandeur les problèmes d’aptitude au soutien assez tôt pour être en mesure de les
avant que cette valeur soit observable et calculée à partir de valeurs résoudre avant la mise en service et de qualifier la définition du soutien ;
antérieures observées ou estimées de la même grandeur ou — autocontrôle (self-inspection) : contrôle par l’exécutant lui-même
d’autres grandeurs en utilisant un modèle mathématique ; du travail qu’il a accompli, suivant les règles spécifiées ;
— disponibilité (availability) : aptitude d’un Produit à être en état — autodescription (self-descriptiveness) : pour le logiciel, caracté-
d’accomplir une fonction requise dans des conditions données, à un ristiques qui fournissent une explication de la réalisation d’une
instant donné pendant un intervalle de temps donné, en supposant que fonction ;
la fourniture des moyens extérieurs soit assurée. Cette aptitude est — autoassistance (operability) : pour le logiciel, caractéristiques qui
fonction d’une combinaison de la fiabilité, de la maintenabilité et du déterminent les actions et les procédures relatives à l’exécution du
soutien en maintenance de l’entité. Le terme « disponibilité » est aussi logiciel ;
employé pour désigner l’aptitude caractérisée par la probabilité qu’un — autonome, indépendant (stand-alone) : qualificatif qui définit un
Produit soit en état d’accomplir une fonction requise dans des condi- Produit pouvant remplir sa fonction sans être raccordé à d’autres
tions données, à un instant donné ; éléments ;
— maintenabilité (maintainability) : mesure de l’aptitude d’un Pro- — communicabilité (communicativeness) ; pour le logiciel, caracté-
duit à être maintenu ou rétabli, sur un intervalle de temps donné, dans ristiques qui fournissent des entrées et des sorties utiles et dont le lan-
un état dans lequel il peut accomplir sa fonction requise, lorsque gage peut être facilement assimilé ;
l’exploitation et la maintenance sont accomplies dans des conditions — compatibilité (compatibility) : adaptation du Produit à une utilisa-
données, avec des procédures et moyens prescrits ; elle est mise en tion conjointe dans des conditions spécifiques pour satisfaire les exi-
œuvre par la maintenance du Produit définie comme l’ensemble des gences concernées sans provoquer d’interactions inacceptables ;
actions destinées à maintenir ou rétablir un Produit dans un état dans — concision (conciseness) : pour le logiciel, caractéristiques qui
lequel il peut accomplir une fonction requise. On distingue couramment : permettent la réalisation d’une fonction à l’aide d’un volume de code
minimal ;
• la maintenance préventive (preventive maintenance) effectuée

à des intervalles prédéterminés ou correspondant à des critères — contrôle des accès par audit (acces audit) : pour le logiciel,
imposés, en vue de réduire la probabilité de défaillance ou la dégra- caractéristiques qui contrôlent par audit les accès au logiciel et aux
dation des performances d’un dispositif, données ;
• la maintenance corrective (corrective maintenance) effectuée — criticité (criticality) : l’importance des conséquences que peuvent
après apparition d’une défaillance, en vue de rétablir un dispositif avoir une exigence, un module, une erreur, un défaut, une panne ou tout
dans un état dans lequel il peut accomplir sa fonction requise. autre élément sur le développement ou le fonctionnement d’un
— sécurité : au double sens de safety – aptitude d’une entité à évi- Produit ;
ter de faire apparaître, dans des conditions données, des évènements — disponibilité (availability) : voir disponibilité comme sous-ensemble
critiques ou catastrophiques – et security – aptitude à la préservation de de la sûreté de fonctionnement (commentaire précédent) ;
la confidentialité en présence de menaces intentionnelles ou fortuites. — durabilité (durability) : aptitude d’une entité à accomplir une
fonction requise dans des conditions données d’utilisation et de main-
Pour certains Programmes, la STB (§ 1.2.2) peut y inclure d’autres tenance jusqu’à ce qu’un état limite soit atteint. L’état limité d’une
paramètres tels que : entité peut être déterminé par des différents facteurs. Le terme durabi-
— durée de vie (life time) : durée pendant laquelle un Produit lité peut être aussi employé comme caractéristique de cette aptitude ;
accomplit une fonction requise dans des conditions d’utilisation et de — efficacité (efficiency) : degré auquel un Produit réalise ses fonc-
maintenance données, jusqu’à ce qu’un état limite soit atteint. Cette tions attribuées, avec un minimum de consommation de ressources.
durée s‘exprime en unité de temps ou en d’autres unités d’usage tels Pour le logiciel, nombre minimum de ressources informatiques et la
que cycles, kilomètres, etc. On distingue couramment : quantité minimale de codes nécessaires à un programme pour qu’il
• la durée de vie effective (expected life time), puisse réaliser une fonction ;
• la durée de vie attendue (real life time), — efficacité de rangement (storage efficiency) : pour le logiciel,
• la durée de vie médiane (mid life time), caractéristiques qui prévoient le minimum de place de mémoire pour
• la durée de vie moyenne (mean life time), une opération ;
• la durée de vie utile (useful life time) ; — ergonomie (ergonomics ou usability) : recherche de la meilleure
— survivabilité (survivability) : aptitude d’un Produit à accomplir adaptation réciproque possible du système homme-machine afin d’en
une fonction requise, dans un état plus ou moins dégradé, dans des obtenir un rendement optimum. Le terme ergonomie peut être aussi
conditions données, pendant un intervalle de temps donné, lorsqu’il employé comme caractéristique de l’aptitude d’un Produit à respecter
est soumis à des agressions. certaines exigences dues aux limitations des capacités de l’opérateur
humain. Lorsque l’on parle d’ergonomie des systèmes, il faut distin-
Commentaire général concernant les facteurs de qualité : guer, sur l’ensemble des exigences d’ergonomie, celles qui auront un
En fonction des caractéristiques du Projet, le Client peut choisir impact direct :
d’exprimer des exigences spécifiques en termes de facteurs de qua- • ergonomie cognitive (cognitive ergonomics),
lité (quality factors). Les facteurs de qualité sont les caractéristiques • ergonomie du poste de travail (dispositifs physiques) (work sta-
affectant la qualité d’un Produit. Dans certaines circonstances, dans tion ergonomics) ;
une hiérarchie des attributs qualité, les attributs de plus haut niveau — évolutivité (upgradeability) : aptitude potentielle aux évolutions
peuvent être appelés « facteurs de qualité » et ceux de niveaux infé- techniques d’un système ou d’un composant sans remise en cause
rieures « attributs de qualité ». Dans le domaine des programmes, fondamentale de sa structure ;
l’usage considère que les « facteurs de qualité » traduisent l’apprécia- — extensibilité (expandability) : pour le logiciel, caractéristiques qui
tion de l’utilisateur, tandis que les « critères de qualité » se rapportent prévoient une zone d’expansion pour les besoins de stockage des infor-
aux éléments ou propriétés sur lesquels le réalisateur agit (des rela- mations ou des fonctions calcul ;
tions de dépendance ou d’influence existent entre facteurs et critères). — fiabilité (reliability) : pour le logiciel, degré auquel un programme
Dans ce document, on ne distingue pas les deux. Les facteurs et les peut réaliser la fonction prévue avec la précision demandée. Plus géné-
attributs de qualité usuellement rencontrés sont les suivants (classés ralement, voir fiabilité comme sous-ensemble de la sûreté de fonction-
par ordre alphabétique français) : nement (commentaire précédent) ;
— flexibilité, adaptabilité (flexibility) : facilité avec laquelle un Pro- — portabilité (portability) : pour le logiciel, attribut qui permet de
duit peut être modifié pour une utilisation dans une autre application ou faciliter le transfert d’un programme d’une configuration matériel et/ou
dans un environnement différent que ceux pour lesquels il a été conçu ; d’un environnement système logiciel à un autre ;
— formation (training) : caractéristiques du Produit qui permettent — précision (accuracy) : caractéristiques du Produit qui fournissent
la transition d’un fonctionnement courant ou une familiarisation initiale ; la précision requise (pour les logiciels par exemple, dans les calculs et
— généralité (generality) : pour le logiciel, caractéristiques du logi- les données de sortie) ;
ciel qui élargissent les cas d’emploi des fonctions assurées ; — protection des accès (access control) : pour le logiciel, caracté-
— homogénéité (consistency) : pour le logiciel, caractéristiques qui ristiques qui permettent le contrôle des accès au logiciel et aux
donnent des techniques et une notation uniformes de conception et de données ;
réalisation ; — rapidité d’exécution (execution efficiency) : pour le logiciel,
— indépendance logicielle (software system independence) : pour caractéristiques qui assurent un minimum de temps machine ;
le logiciel, caractéristiques qui déterminent ses dépendances vis-à-vis — rectitude (correctness) : degré de réponse d’un Produit aux exi-
de l’environnement logiciel (système d’exploitation, utilités, routines gences spécifiées dans sa spécification, sa conception et sa
d’entrée/sortie, etc.) ; réalisation ;
— indépendance matérielle (machine independence) : pour le logi- — redondance (redundancy) : dans un dispositif, existence de plus
ciel, caractéristiques qui déterminent ses dépendances vis-à-vis du d’un moyen pour accomplir une fonction donnée ;
système logiciel ; — réutilisabilité (reusability) : pour le logiciel, degré auquel un
— instrumentation (instrumentation) : pour le logiciel, caractéristi- module logiciel ou un autre produit du travail peut être utilisé dans plu-
ques qui permettent la mesure des temps de travaux ou l’identification sieurs programmes informatiques ou systèmes logiciels ;
des erreurs ; — robustesse (robustness) : degré auquel un Produit peut fonction-
— intégralité (completeness) : pour le logiciel, caractéristiques qui ner correctement en présence de données d’entrée non valables ou de
fournissent une réalisation complète des fonctions demandées ; conditions d’environnement stressantes ;
— intégrité (integrity) : pour les programmes d’ordinateurs, degré — sécurité (safety/security) : voir sécurité comme sous-ensemble
auquel on peut maîtriser l’accès au logiciel ou aux données par des per- de la sûreté de fonctionnement (commentaire précédent) ;
sonnes non autorisées ; — sévérité (severity) : conséquences d’un mode de défaillance. Les
— interchangeabilité (interchangeability) : pour un besoin déter- catégories de sévérité sont définies afin de fournir une mesure qualita-
miné, aptitude commune à des éléments, de fabrication ou de tive des conséquences potentielles extrêmes, suite à une erreur de
conception différente mais de fonction identique, à être substitués conception ou à une défaillance du Produit. Les catégories de sévérité
les uns aux autres selon des critères bien définis, sans retouche, modi- peuvent se décrire comme suit ;
fication ou sélection de ces éléments et sans modification des fonc- • catastrophique (catastrophic) : défaillance pouvant entraîner la
tions, des performances ou des matériels de mise en œuvre et de mort ou la perte d’un système,
maintenance : • critique (critical) : défaillance pouvant causer une blessure grave,
• interchangeabilité fonctionnelle (functional interchangeability) : des dégâts matériels importants ou endommager un Produit de
un élément est dit interchangeable fonctionnellement avec un autre si façon à entraîner la perte d’une mission,
l’un peut remplacer l’autre et réciproquement sans qu’il soit nécessaire • marginale (marginal) : défaillance pouvant causer une blessure
de l’adapter ou de le tirer, sans qu’il y ait à modifier parallèlement (autre- ou des dégâts mineurs, qui entraînent un retard, une perte de dispo-
ment que par les réglages prévus dans le cadre de l’exploitation) les nibilité ou la dégradation de la mission,
éléments avec lesquels il est en relation, sans que les performances • mineure (minor) : défaillance qui ne cause ni blessure, ni dégât
d’ensemble sortent des performances prévues et, ceci, quels que matériel, ni dommage au Produit mais qui entraîne des opérations de
soient les points d’application de l’élément dans le Produit et/ou ses maintenance ou des réparations non prévues ;
composants, — sévérité d’un aléa (hazard severity) : évaluation du pire accident
• interchangeabilité logistique (logistic interchangeability) : il y a plausible qui pourrait être causé par un aléa particulier ;
interchangeabilité logistique entre deux composés réparables — simplicité (simplicity) : degré auquel un Produit a une conception
lorsqu’il y a interchangeabilité fonctionnelle entre ces deux compo- et un fonctionnement simple et facile à comprendre. En matière de
sés, interchangeabilité fonctionnelle de tous leurs composants sus- logiciel, les caractéristiques qui fournissent la réalisation des fonctions
ceptibles d’être fournis en rechange à quelque niveau que ce soit et de la manière la plus compréhensible (habituellement le non-usage des
que, ni les manuels techniques, ni les listes d’articles de rechange, ni méthodes qui augmentent la compléxité) ;
les moyens de maintenance ne soient affectés ; — testabilité (testability) : attribut qui permet de faciliter l’essai
— interopérabilité (interoperability) : attribut qui permet de faciliter d’un Produit pour s’assurer qu’il effectue la fonction prévue ;
le raccordement d’un Produit à un autre ; — tolérance aux erreurs (error tolerance) : caractéristiques du Pro-
— invulnérabilité (invulnerability) : aptitude d’un Produit à mainte- duit qui fournissent une continuité de fonctionnement dans des condi-
nir son intégrité physique et fonctionnelle lorsqu’il est soumis à des tions autres que les conditions nominales ;
agressions ; — traçabilité (traceability) : pour le logiciel, caractéristiques qui
— maintenabilité (maintainability) : pour le logiciel, attribut qui per- fournissent un fil conducteur depuis la spécification jusqu’à la réalisa-
met de faciliter la localisation et la rectification d’une erreur dans un tion par rapport à l’environnement spécifique de développement et de
programme opérationnel. Plus généralement, voir maintenabilité fonctionnement ;
comme sous-ensemble de la sûreté de fonctionnement (commentaire — utilisabilité (usability) : facilité avec laquelle un utilisateur peut
précédent) ; apprendre le fonctionnement du Produit, la préparation des données
— modularité (modularity) : caractéristiques du système ou du logi- d’entrée et l’interprétation des données de sortie.
ciel qui présentent une structure en modules discrets et très indépen-
dants les uns des autres de telle sorte qu’une modification d’un de ces Commentaire général concernant le soutien logistique intégré :
composants ait un impact minimum sur les autres composants ;
— normalisation des données (data commonality) : pour le logi- Si, on fonction des caractéristiques du Projet, le client choisit d’expri-
ciel, caractéristiques qui permettent l’utilisation des représentations mer des exigences spécifiques en termes de SDF et/ou de facteurs de
standard des données ; qualité, cela engendre des obligations en termes de garanties techni-
— normalisation des interfaces (communications commonality) : ques et peut générer des devoirs particuliers en termes de soutien ou
pour le logiciel, caractéristiques qui permettent l’utilisation des proto- encore de soutien logistique intégré (ci-après dénommé SLI) au titre
coles standards et des routines d’interfaces ; des obligations contractuelles.
Un Produit idéalement fiable et simple d’emploi se suffirait à lui- Le CGP est la somme totale des coûts directs, indirects, récurrents,
même. Tel n’étant pas le cas, certaines « fonctions de soutien » sont à nonrécurrents et autres coûts similaires, supportés ou estimés par anti-
assurer. Composants le Produit, un « système de soutien » est donc cipation comme devant être supportés en conception, développement,
nécessaire, en plus du « système opérationnel ». Lorsque le processus réalisation, production (incluant fabrication en série et celle du proto-
SLI est effectué très tôt, l’idée fondamentale est d’intégrer fortement type ou de la présérie), acquisition, test et évaluation, acceptation,
l’étude du soutien logistique à l’étude du système principal. Cette ana- fonctionnement, maintenance, modernisation, décontamination, sou-
lyse regroupe normalement un ensemble d’activités scientifiques et tien et destruction d’un Produit, par anticipation. Un CGP s’entend pour
techniques, organisées en un processus itératif d’identification, de défi- un Client déterminé. Un tel coût est en général calculé en monnaie
nition, de quantification, de choix et compromis, d’essais et d’évalua- actualisée (ou en une autre unité monétaire datée). Pour tout type de
tions, visant à assurer que les besoins d’aptitude au soutien et les Projet, le calcul du CGP relève avant tout de la responsabilité de l’inves-
autres besoins du SLI sont satisfaits. Il permet, en particulier, de tisseur. Deux conséquences principales en découlent :
s’assurer que le soutien est pris en compte dans l’énoncé des exigen- — une telle exigence n’est jamais incluse dans un Contrat de maî-
ces relatives au Produit et dans la définition de celui-ci, de spécifier et trise d’œuvre. Elle aboutirait à transférer la responsabilité de base de
définir le système de soutien en optimisant le couple système opéra- l’investisseur au Maître d’œuvre pour une somme ridicule ;
tionnel – système de soutien, de préparer et de fournir les données — la seule exigence qui soit parfois rencontrée est le respect d’un
nécessaires pour le mettre en place et le maintenir pendant la durée de coût d’objectif pour la conception, le développement et la réalisation du
vie du Produit contractuellement opposable au Maître d’œuvre et Produit. Les conséquences financières d’une telle exigence sont com-
d’évaluer l’efficacité du système de soutien tel qu’il est défini et tel qu’il mentées dans l’annexe 3 [AG 3 257].
fonctionne. Il est alors possible de concevoir en harmonie les deux sys- Même si ce n’est pas propre au Contrat de Maîtrise d’œuvre, il est
tèmes et de résoudre au mieux les problèmes futurs de soutien, en nécessaire de fournir des explications complémentaires sur les concepts
répartissant les solutions soit sur la conception du système opération- dérivés du CGP qui peuvent influencer la conception du Produit.
nel, soit sur la conception du système de soutien. Une telle démarche On appelle durée de vie (life cycle) celle pendant laquelle une entité
permet de proposer au Client un service global et compréhensible accomplit une fonction requise dans des conditions d’utilisation et de
qui englobe le système opérationnel et son soutien. Un travail de maintenance données, jusqu’à ce qu’un état limite soit atteint. Cette
groupe peut permettre : durée sépare la date de la première mise en service d’une entité de la
— une intégration technique du soutien : la conduite simultanée date à laquelle elle a définitivement cessé d’accomplir la fonction qui lui
de l’étude du système principal et de celle du système de soutien est a été dévolue. Cette durée s’exprime en unité de temps ou en d’autres
indispensable pour définir des solutions harmonieuses. Chacune des unités d’usage (cycles, kilomètres, etc.).
deux études doit pouvoir influencer l’autre, pour que les solutions trou- L’état limite (threshold condition), correspondant à la cessation défi-
vées soient les plus efficaces pour le Client ; nitive de l’utilisation de l’entité, peut être déterminé par la fin de la vie
— une intégration économique de soutien : le Client attend des utile, c’est-à-dire lorsque le risque de défaillance devient inacceptable
solutions rentables en termes de coût global de possession (voir les ou lorsque l’entité est considérée comme irréparable à la suite d’une
commentaires ci-après sur le CGP). Une approche axée simplement panne. On parle alors de durée de vie utile (service life).
sur la réduction des coûts d’acquisition peut ne pas être satisfaite. En L’état limite est le plus souvent lié à une usure ou une dégradation. Il
conséquence une approche multidisciplinaire peut être indispensable peut aussi être déterminé par l’inadaptation de l’entité pour d’autres
pour prendre en compte les coûts futurs d’exploitation et de mainte- raisons économiques ou techniques ou par d’autres facteurs tels que la
nance et pour trouver des solutions économiquement rentables à long mode. Il n’est plus possible, matériellement ou économiquement, de
terme ; remettre l’élément en état suivant des critères acceptables.
— une intégration industrielle du soutien : la production du sys-
La durée de vie peut être évaluée :
tème de soutien peut s’avérer financièrement plus rentable si elle
prend en compte certains critères industriels (lancement simultané des — a priori : on parle alors de durée de vie attendue ;
rechanges et des équipements opérationnels, etc.). — a posteriori : c’est la durée de vie effective.
L’équipe logistique chargée des études du SLI est normalement À ce stade, il est impossible d’éluder certaines informations relatives
composée d’analystes du soutien logistique (notamment chargés à l’analyse de la valeur (value analysis).
d’effectuer les études techniques et économiques), de spécialistes des L’analyse des coûts du Produit est un aspect de l’analyse de la valeur
bases de données logistiques (notamment chargés de la constitution, qui s’inscrit dans le cadre général de la conception à coût d’objectif. La
l’enrichissement, la gestion et l’exploitation de la base de données notion de coût couvre les charges ou dépenses supportées par un
logistiques) et de spécialistes des éléments de soutien à produire (spé- intervenant économique par suite de la production ou de l’utilisation
cialistes de la documentation technique, spécialistes des approvision- d’un Produit. Le coût à considérer dépend de la nature et du contexte
nements et de la documentation de ravitaillement, spécialistes de la de l’action d’analyse de la valeur considérée. Il peut s’agir du coût glo-
formation, spécialistes des équipements de soutien, etc.). bal, ou coût de possession, du coût d’acquisition, du coût de mainte-
nance, etc. Par extension, l’analyse de la valeur peut également
Dans le cadre du Programme, le Contrat doit donc identifier :
s’appliquer à des coûts non économiques (une masse, un volume, une
— le contexte utilisateur et le profil des missions escomptées du consommation d’énergie, etc.). Selon nous, les normes NF EN 1 325,
Produit ; NF X50-151, NF X50-152 et X50-153 relatives à l’analyse de la valeur ne
— les performances techniques attendues (elles découlent des sont pas à prendre comme une contrainte mais plutôt comme un guide
fonctions à réaliser pour remplir la mission, durée de vie escomptée du du processus d’analyse de la valeur.
Produit, classement par ordre d’importance des contraintes sur les per- Selon les dispositions de la norme NF X50-152, une action d’analyse
formances techniques du Produit, objectifs de sûreté de fonctionne- de la valeur peut se décomposer en sept étapes :
ment par fonction et par matériel, autres exigences – en matière de
testabilité, de sécurité, d’ergonomie, etc. –, évolutions envisagées — définition de l’étude et de ses objectifs ;
pour les fonctions et le Produit pendant son cycle de vie) ; — recherche de l’information ;
— les caractéristiques du soutien, telles qu’elles résultent de l’orga- — analyse des fonctions et des coûts/validation des besoins et des
objectifs ;
nisation déjà en place ou de l’organisation attendue par le Client (délais
— recherche d’idées et de voies de solutions ;
spécifiques au Client, facteurs humains, formation, assistance techni-
— étude et évaluation des solutions ;
que, maintenance, équipements de soutien, pièces de rechange, sup-
— choix de la solution ;
ports documentaires).
— suivi de la réalisation et bilan.
Commentaire général concernant le coût global de possession : Les deux premières étapes sont des étapes préliminaires de mise en
En fonction des caractéristiques du Projet, le Client peut choisir place ; les trois étapes suivantes sont des étapes itératives menées con-
d’exprimer des exigences spécifiques en termes de coût global de jointement avec les activités de conception ; les deux dernières étapes
possession (ci-après dénommée CGP) (life cycle cost). sont des étapes finales de prise de décision et de suivi de la réalisation.
Les deux premières étapes devraient toujours être conduites à Les domaines des études de faisabilité sont potentiellement très
l’occasion du processus de programmation. nombreux. Nous envisageons essentiellement la faisabilité technique.
La définition de l’étude et de ses objectifs a pour objet de préciser La faisabilité est la phase initiale d’un Programme, centrée sur la
les points suivants : l’objet et la cause de l’étude, les données du pro- recherche et l’évaluation des concepts susceptibles d’être employés
blème, les enjeux économiques, le champ et les limites de l’étude, les en regard de la satisfaction qu’ils peuvent apporter au besoin opération-
contraintes, les objectifs, les moyens mis en œuvre, la constitution du nel. Elle comporte surtout des travaux d’analyse (sur la mission, sur les
groupe de travail et la définition du calendrier de l’action. solutions techniques) pour dégager les points critiques, pour cerner les
La recherche de l’information a pour objet de dresser un inventaire travaux d’étude et de développement qui sont à initialiser, pour évaluer
des informations nécessaires (techniques, industrielles, économiques, les délais, les coûts et les aléas. Au cas par cas, elle peut comporter
commerciales, réglementaires, etc.) internes ou externes, sans omet- des travaux d’essais et/ou de démonstration.
tre celles relatives au besoin, telles que besoins à satisfaire, marché, Les études de faisabilité peuvent inclure la réalisation de maquettes.
concurrence, solutions et techniques possibles, coûts et contraintes. Une maquette (mock-up) doit être démonstrative et pouvoir servir de
Selon nous, faute d’avoir procédé au moins aux trois premières support à des expérimentations en terme de performances (temps
étapes (la troisième est décrite dans [AG 3 256, § 4]), il est impossible d’accès, occupation mémoire, volume de données traitées…) et en
que le coût d’objectif contractuel soit assis sur une analyse de la terme de caractéristiques opérationnelles (écrans, listages…). L’objec-
valeur dont le contenu peut être démontré. Dans une telle situation, tif d’une maquette est de donner à l’utilisateur une image représenta-
le coût d’objectif ne devrait être considéré que comme l’identifica- tive des interactions entre l’environnement d’exécution final et la
tion des possibilités financières du Client. Autrement, les tribunaux livraison finale lui permettant de corriger des options très dimension-
compétents devraient pouvoir considérer l’existence d’un accord nantes au moment où le coût des modifications est encore peu élevé.
impossible, c’est-à-dire d’un accord dont l’exécution est de fait Une maquette peut être qualifiée de :
impossible. Un tel engagement est légalement nul en droit français
aussi bien qu’en Common law. — maquette statique (static mock-up) : livraison fixant l’enchaîne-
ment externe des fonctions finales ;
Commentaire juridique général concernant les études de — maquette de plate-forme (platform mock-up) : livraison permet-
SDF, les facteurs de qualité, les études de SLI et de CGP : tant de valider sur les lieux de la plate-forme de développement en uti-
Par rapport à une mission standard, la prise en compte de la SDF, des lisant des scénarios figés et sur le support d’outils de maquettage, les
facteurs de qualité, du SLI et/ou du CGP peut multiplier le coût de réali- fonctions finales ;
sation de base des études du Maître d’œuvre. Les définitions de ces ter- — maquette expérimentale (experimental mock-up) : livraison per-
mes montrent à l’évidence que la précision des engagements du Maître mettant de valider sur le terrain, en utilisant des scénarios opération-
d’œuvre et la responsabilité qui peut en découler est inversement pro- nels, et sur le support d’outils de maquettage, les fonctions finales.
portionnelle à la précision du contenu du Programme. De plus, dans cer- Dans de très rares occasions, les études de faisabilité peuvent aussi
tains cas, les objectifs du Client ne peuvent pas être atteints. Si le Client
inclure des travaux de prototypage au travers d’un processus de recher-
venait à demander par exemple une étude de fiabilité complète sur une
che et développement.
installation industrielle, il faudrait disposer pour cela de toutes les étu-
des de fiabilité faites par les fabriquants de tous les composants de cha- Étymologiquement, un prototype est le premier d’une série de Pro-
que équipement. C’est en fait impossible et, selon nous, cela devrait duits qui a les mêmes caractéristiques que l’objet fini sortant de la
être considéré comme une impossibilité en termes de responsabilité production.
(voir § 6 de [AG 3 254]). Le seul secteur qui peut commander de telles étu- La production de série n’existant pas en logiciel (il y a développe-
des est le secteur nucléaire car les exploitants nucléaires sont conscients ment et duplication), on distingue les prototypes suivants :
de la quantité de travail à accomplir et assument les conséquences — prototype exploratoire (exploratory prototype) : outil de dialo-
financières qui en découlent. Pour les autres secteurs, on ne peut rai- gue pour valider des spécifications d’exigences par expérimentation ;
sonnablement escompter que des macroétudes fondées sur l’analyse — prototype expérimental (experimental prototype) : outil de véri-
du fonctionnement des sous-systèmes et des équipements principaux
fication de la faisabilité de parties critiques dans un système en maîtri-
pris dans leur globalité. Si les Parties conviennent de dispositions en ter-
sant la complexité lors de la conception ;
mes de fiabilité, elles doivent prendre en compte ces éléments pour
— prototype évolutif (upgradeable prototype) : outil directement
établir la granulométrie de l’étude et, dans le silence du Contrat, aucune
étude de fiabilité ne peut être escomptée comme devant être remise. utilisable évoluant de version en version pour faciliter la prise en
C’est pourquoi il est, selon nous, raisonnable de considérer, en termes compte de l’évolution du système.
de responsabilité, que : En matière d’équipements, selon les caractéristiques du Projet, on
— dans le silence du Contrat, les engagements du Maître d’œuvre peut aussi rencontrer des prototypes d’autres natures :
sont limitées au respect des dispositions d’ordre public ; — prototype de définition (definition prototype) : il concerne un
— les éventuelles dispositions contractuelles doivent être interpré- matériel construit selon des procédés de fabrication qui peuvent être
tées de façon restrictive au bénéfice du débiteur de l’obligation. différents de ceux qu’exige une production en série mais autant que
possible avec des composants (ou pièces) de type définitif ;
— prototype d’identification (identification prototype) : il concerne
1.1.6 Faisabilité un matériel construit dans sa forme définitive selon des procédés de
fabrication qui peuvent être différents de ceux qu’exige une production
L’objet de la faisabilité (ci-après dénommée Faisabilité) est d’iden- en série mais qui s’en rapprochent cependant le plus possible.
tifier la capacité du Projet à être réalisé, dans le cadre des préoccu-
pations suivantes : Le plus souvent, lorsque les Parties développent un Produit dans le
cadre d’un tel Contrat de maîtrise d’œuvre, il s’agit d’un monotype
— …; (monotype) et non d’un prototype (notons que le prototype est exclu
— …. du champ des polices d’assurance de responsabilité).
Commentaire concernant la faisabilité :
Selon les Projets, l’étude de faisabilité (feasibility study) peut être 1.2 Démarche de programmation
réalisée par le Client (ou n’importe quel organisme qu’il missionne à
cet effet), par le Maître d’œuvre ou par une collaboration des deux.
Dans ce dernier cas, il faut ventiler soigneusement les rôles du Client Conformément aux règles usuelles de gestion de projet, le Pro-
et du Maître d’œuvre. gramme s’établit en deux temps.
Commentaire relatif à la démarche générale de programmation : — …;

Les deux temps auxquels il est fait référence sont les deux premiers — ….
états normalisés de tout Produit (à ce stade, ils correspondent à des
Commentaire concernant cette clause B :
Produits virtuels) :
Les tâches dues par les Parties doivent être listées ici.
— le besoin est fonctionnellement spécifié : besoin fonctionnel
qui se caractérise par l’établissement de la spécification fonctionnelle ■ Clause C : Documents du CDCF
de besoin, plus couramment désignée « cahier des charges
fonctionnel » (functional specification of need ; performance functional Le CDCF se traduit par les documents suivants :
spécification) ; — …;
— le besoin est techniquement spécifié : besoin technique qui se — ….
caractérise par l’établissement de la « spécification technique de
besoin » (requirement engineering specification). Commentaire concernant cette clause C :
1.2.1 Cahier des charges fonctionnel ■ Clause D : Documentation de référence
Une fois réalisé, le CDCF est approuvé par le Client et devient un
La détermination du besoin fonctionnel intervient par l’élabora- document contractuel d’application obligatoire.
tion du cahier des charges fonctionnel (ci-après dénommé CDCF).
Commentaire relatif au cahier des charges fonctionnel :
Le CDCF est le document qui découle de l’analyse fonctionnelle 1.2.2 Spécification technique de besoin
(functional analysis). L’analyse fonctionnelle est une démarche par
laquelle un demandeur exprime (et parfois découvre !) un besoin en Le CDCF de référence constitue le départ d’un processus de
termes de fonctions de services et de contraintes. Pour chacune conception qui fait émerger les spécifications techniques du
d’elles, sont définis les critères d’appréciation et leur niveau, chacun de besoin à satisfaire. Les résultats sont formalisés dans une spéci-
ces niveaux étant assorti d’une flexibilité (chaque critère d’appréciation fication technique du besoin (ci-après dénommée STB).
de nature qualitative est accompagné d’une échelle permettant de
Commentaire général relatif à la STB :
situer le niveau de nature qualitative du critère d’appréciation). À cet

effet, le CDCF n’exprime que des exigences de résultats et aucune exi- Il s’agit ici d’assurer le passage du CDCF à la STB. C’est la fin de la
gence de moyens. réalisation du processus d’expression de besoin. À ce stade, le Pro-
L’analyse fonctionnelle s’applique à la création ou à l’amélioration gramme doit être considéré comme achevé.
d’un Produit. Appliquée au seul besoin, elle est la base de l’établisse- ■ Clause A : Objet de la STB
ment du cahier des charges fonctionnel. La caractérisation des fonc-
tions consiste à énoncer les critères, préciser leurs niveaux et indiquer Établie sous la responsabilité du Client, la STB a pour objet, d’une
la flexibilité. Leur ordonnancement vise à les classifier en fonction de part, d’exprimer le besoin en termes compatibles avec le contenu du
service et en fonctions techniques (en reconception) et à identifier les CDCF et, d’autre part, d’expliciter la solution ou les principes de
relations de dépendance entre elles. Leur hiérarchisation permet d’éva- solution choisis. La STB exprime donc :
luer leur ordre d’importance. Leur valorisation concrétise cet ordre — les spécifications fonctionnelles associées aux divers profils de
d’importance par l’attribution à chacune d’elles d’un poids en valeur mission prévues en tenant compte des conditions
relative ou absolue indépendamment des solutions. Selon qu’elle d’environnement ;
s’intéresse aux fonctions de service (besoin) ou qu’elle s’étend aux
— les éventuelles spécifications en termes :
fonctions techniques (solutions), l’analyse fonctionnelle utilise des
outils différents. • d’exigences de sûreté de fonctionnement, de facteurs de qua-
Au cours de cette démarche, le Produit est appréhendé dans son lité et de soutien logistique intégré décrits au paragraphe 1.1.5 ;
environnement pour mettre en lumière les fonctions requises par ledit • de coûts d’objectif décrits dans l’annexe 3 [AG 3 257] ;
environnement sur les bases suivantes : Commentaire concernant ce paragraphe :
— à quoi et à qui le Produit sert-il ? Si le coût d’objectif impacte le montant des honoraires du Maître
— quel est son but ? d’œuvre, se référer aux dispositions de l’annexe 3 [AG 3 257]. À défaut,
— sur quoi et sur qui le Produit agit-il ? la seule référence au paragraphe 1.1.5 est suffisante.
L’analyse fonctionnelle est la démarche fondée sur le bon sens qui
aboutit à la création de l’arborescence des fonctions et permet d’en hié- — les spécifications d’interface ;
rarchiser l’importance, sans a priori sur la nature des solutions futures.
C’est le domaine de prédilection du rôle des futurs utilisateurs dans Commentaire concernant ce paragraphe :
l’investissement [34]. Il s’agit d’éviter que l’étude de l’investissement L’interface est l’ensemble des caractéristiques physiques et fonc-
ne se réduise à la définition d’une solution technique. En effet, on constate tionnelles requises à une frontière commune entre deux ou plusieurs
statistiquement que de nombreux problèmes rencontrés par les futurs articles, matériels ou logiciels. La spécification décrit donc l’interface
utilisateurs ont pour origine une insuffisante prise en compte en amont d’un article (pièce, équipement, sous-système, etc., susceptible d’être
des contraintes liées aux conditions et aléas d’utilisation du Produit. pris en compte individuellement et examiné ou testé de manière dis-
tincte) qui affecte la conception ou l’utilisation des articles associés.
■ Clause A : Objet du CDCF
— les spécifications concernant la conception, la qualification, la
Établi sous la responsabilité du Client, le CDCF est le document réalisation et l’acceptation du Produit (solutions imposées ou inter-
par lequel le Client exprime ses besoins et ses exigences ou ceux dites, normes rendues applicables, etc.), liées aux justifications à
qu’il est chargé de traduire en termes de fonctions, les différentes apporter ;
conditions d’utilisation envisagées et les flexibilités admises.
— etc.
■ Clause B : Tâches respectives des Parties dans l’élaboration du Commentaire concernant l’ensemble de cette clause A :
CDCF
Le texte est à élaborer au cas par cas. La qualification ne sera envisa-
Dans le cadre de l’élaboration du CDCF, les Parties accompliront gée que si la réalisation d’un Produit fini est précédé par la réalisation
les tâches suivantes : d’un Pilote ou si le Produit s’entend d’une production en série.
■ Clause B : Tâches respectives des Parties dans l’élaboration de la L’exigence peut changer de formulation au cours du processus de
STB formalisation et apparaître in fine dans la spécification sous forme
Dans le cadre de l’élaboration de la STB, les Parties accompliront d’une ou de plusieurs exigences textuelles ou modélisées. Lorsque le
les tâches suivantes : processus de formalisation a abouti à une version de spécification du
Produit, toute exigence d’origine doit être soit exprimée dans la spéci-
— …;
— …. fication du Produit, soit avoir fait l’objet d’une décision de rejet ou
d’acceptation d’évolution.
Commentaire concernant cette clause B :
Un suivi individualisé des exigences est nécessaire. Jugé à un
Le texte est à élaborer au cas par cas. Les tâches dues par les Parties moment donné exploitable et correct compte tenu du contexte connu,
doivent être listées ici. un texte d’exigence sera exploité dans la tâche de consolidation des
■ Clause C : Documents de la STB exigences. Si le texte est utilisé in extenso et apparaît à terme explici-
tement dans la documentation de spécification, on dit qu’il formule une
La STB se traduit par les documents suivants :
exigence de référence.
— …;
Si le contenu de l’exigence est applicable mais a été reformulé (modi-
— ….
fication de la forme) par de nouvelles exigences textuelles, ou par
Commentaire concernant cette clause C : modélisation, l’exigence est dite exigence reformulée (restated require-
Le texte est à élaborer au cas par cas. ment). Elle ne sert que pour l’historique de la formulation des exigences
d’origine, et il doit être possible de tracer la nouvelle formulation à partir
■ Clause D : Documentation de référence de la formulation d’origine. En particulier, si une exigence textuelle est
Une fois réalisée, la STB est approuvée par le Client et devient un reformulée par modélisation, c’est l’objet modélisé (une donnée, un
document contractuel d’application obligatoire. comportement) qui formule l’exigence de référence. On parle alors
Conclusion concernant la démarche de Programmation : d’exigence modélisée (modelled requirement).
Statuer de la présence d’une exigence (dans cette conclusion, on ne L’exigence obsolète (obsolete requirement) est le nom de l’exi-
fait référence qu’aux exigences mais les commentaires qui suivent gence qui ne se retrouve sous aucune forme dans les exigences de
s’appliquent en fait à toutes les caractéristiques du Programme) expri- référence. Elle apparaît dans les situations suivantes :
mée par le Client (oralement ou textuellement) n’est pas un acte trivial. — l’exigence a été définitivement rejetée suite aux négociations ;
L’objectif de la formalisation des exigences (figure 1) est d’aboutir à — l’exigence a subi une évolution : une demande d’évolution de
une base homogène et cohérente d’exigences qui servira de référence l’exigence (modification du fond) a été acceptée et est applicable. La
à toute tâche ou activité d’ingénierie. Cette base est initialement consti- nouvelle exigence qui la remplace peut être retrouvée à partir de la for-
tuée des exigences d’origine (original requirements) exprimées par le mulation d’origine.
Client. Le processus de formalisation transforme progressivement ces L’exigence intermédiaire (intermediary requirement) est le nom de
exigences pour les rendre exploitables. Une exigence exploitable (usa- l’exigence dont on est en attente de décision quant à l’exploitation que
ble requirement) peut donc être considérée comme une exigence de l’on va en faire. Une exigence ne peut être une exigence intermédiaire
référence (reference requirement). Une exigence est inexploitable si : que de façon transitoire.
— elle apparaît dans une structure complexe ; L’exigence d’origine brute (raw original requirement) est le nom de
— elle est incomplète ; l’exigence qui n’a été ni classée, ni analysée. Elle attend d’être analysée
— elle est redondante, etc.
par le processus de formalisation des exigences. L’examen de l’exi-
La conservation d’une exigence sous sa forme originale est l’opéra- gence d’origine est en cours :
tion de formalisation la plus élémentaire. C’est toutefois une opération
— s’il s’agit d’une exigence nouvelle, l’examen est une analyse de
réelle puisqu’elle résulte d’une décision. Toute reformulation des exi-
forme ;
gences peut impliquer une modification contractuelle et peut exiger un
dialogue avec le Client. Les tâches élémentaires sont : — si l’exigence traduit une demande d’évolution d’une autre exi-
gence, elle doit également subir une analyse d’impact qui décide de la
— identifier (ou statuer sur) les exigences ; recevabilité de la demande.
— ajuster chaque exigence (c’est-à-dire ni trop, ni trop peu) ;
— évaluer chaque exigence ; Lorsqu’un problème impliquant le texte a été levé et décrit par une
— éliminer les exigences non nécessaires ; tâche d’analyse ou de consolidation, l’exigence doit être discutée afin
— modifier les exigences (pour proposer une approche plus adaptée de décider in fine si elle est acceptée en l’état, reformulée ou rejetée.
au besoin réel perçu) ; L’état intermédiaire prend fin avec une décision justifiée d’accepta-
— considérer les alternatives (démarche intégrant l’analyse de la tion, de reformulation ou de rejet de l’exigence.
valeur) et les risques. Les états possibles d’une exigence modélisée (figure 3) sont
Différents statuts peuvent s’appliquer aux exigences en cours légèrement différents. De par sa forme qui répond à une syntaxe
de formalisation du Programme (figure 2). contrôlée, la formulation de l’exigence est toujours correcte et l’exi-
Un texte élémentaire, extrait d’un document source du projet et gence est, a priori, une exigence de référence. À tout moment, du
reconnu comme exprimant une exigence du système, est dit formuler fait des travaux de consolidation, son contenu peut être remis en
une exigence d’origine. Les exigences d’origine sont des exigences cause : l’exigence passe dans l’état intermédiaire. Si les négocia-
qui ont un impact opérationnel et elles sont acquises tout au long du tions confirment l’exigence, elle reprend son statut de référence.
processus d’ingénierie. Leur source permet de déterminer le type de Sinon, l’exigence devient « à faire évoluer » et, en attendant sa mise
trace nécessaire à leur exploitation : à jour, associée à l’évolution demandée.
— l’exigence Client (client’s requirement) est le nom de l’exigence En cours de formalisation du Programme, il faut classer et ana-
émise par le Client, dont il faut pouvoir justifier à terme la prise en lyser les textes élémentaires.
compte ou l’abandon dans la spécification du Produit ; L’objet de cette activité est de :
— l’exigence d’origine dérivée (derived requirement) est le nom
de l’exigence émise par le Maître d’œuvre et acceptée par le Client. — répertorier, dans les documents sources d’information pour le
Elle est à traiter comme une demande d’évolution afin d’être négociée système, les textes élémentaires et les classer pour une utilisation plus
et faire l’objet d’une décision dûment enregistrée ; facile par les autres activités ;
— l’exigence implicite (implicit requirement) est le nom de l’exi- — séparer les informations des exigences ;
gence opérationnellement évidente dont on veut pouvoir tracer la — rendre ces textes élémentaires exploitables pour la consolidation
conception (par exemple : démarrer le Produit). des exigences en phase de conception.
Exigence obsolète
Exigence reformulée
En attente
Demande d’évolution
Demande d’évolution
En analyse
En analyse
de forme
d’impact
Point critique Décision d’acceptation

de formulation Point critique d'impact
Décision de
reformulation

Langue

AG3255 Contrats de L'ingénierie - Annexe 2 - Dispositions Techniques (Partie 1)

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

AG3255 Contrats de L'ingénierie - Annexe 2 - Dispositions Techniques (Partie 1)

Transféré par

Droits d'auteur :

Réf.

Cet article est issu de : Génie industriel | Conception et Production

par Gilles CASTAN

Résumé Le contrat de maîtrise d’œuvre doit préciser bon nombre d’informations

Pour toute question :

1. Programme ................................................................................................ AG 3 255 – 2

1.2.2 Spécification technique de besoin .................................................... — 9

omme tout contrat, le Contrat de maîtrise d’œuvre doit préciser, notam-

CONTRATS DE L’INGÉNIERIE _____________________________________________________________________________________________________________

1. Programme Commentaire général concernant le contenu du Programme :

_____________________________________________________________________________________________________________ CONTRATS DE L’INGÉNIERIE

— logiciel sur étagère (off-the-shelf software) : logiciel déjà déve-

CONTRATS DE L’INGÉNIERIE _____________________________________________________________________________________________________________

appropriée (nombre de cycles par exemple). La fiabilité se décompose

_____________________________________________________________________________________________________________ CONTRATS DE L’INGÉNIERIE

• la maintenance préventive (preventive maintenance) effectuée

CONTRATS DE L’INGÉNIERIE _____________________________________________________________________________________________________________

_____________________________________________________________________________________________________________ CONTRATS DE L’INGÉNIERIE

CONTRATS DE L’INGÉNIERIE _____________________________________________________________________________________________________________

_____________________________________________________________________________________________________________ CONTRATS DE L’INGÉNIERIE

Commentaire relatif à la démarche générale de programmation : — …;

situer le niveau de nature qualitative du critère d’appréciation). À cet

CONTRATS DE L’INGÉNIERIE _____________________________________________________________________________________________________________

_____________________________________________________________________________________________________________ CONTRATS DE L’INGÉNIERIE

Point critique Décision d’acceptation