SlideShare une entreprise Scribd logo
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
©Techniques de l’Ingénieur, traité Informatique industrielle S 8 095 − 1
S
8
095
12
-
2001
Cahier des charges des automatismes.
Analyse fonctionnelle
par Michel ROUX
Consultant en ingénierie productique
a conception des systèmes automatisés de production est basée sur une
expression des besoins formalisés dans un cahier des charges fonctionnel.
Le cahier des charges constitue non seulement un outil de travail mais il est
aussi la base contractuelle entre le client et son fournisseur.
La sophistication croissante des systèmes automatiques entraîne une difficulté
accrue dans l’élaboration des cahiers des charges correspondants. C’est pour
tenter de résoudre cette difficulté que de nombreuses réflexions ont été menées,
des méthodes imaginées et des outils créés.
De nombreuses études conduites dans plusieurs pays et notamment aux États-
Unis ont mis en évidence que de nombreux cahiers des charges étaient incomplets,
ambigus voire incohérents et que là se trouvait la raison de l’échec de nombreux
projets (performances non atteintes, délais dépassés, budgets explosés).
Après quelques définitions et réflexions sur les particularités des automa-
tismes par rapport à d’autres biens industriels, seront exposées des méthodes
de recensement puis de formalisation des besoins, ensuite un sommaire géné-
rique de cahier des charges sera proposé.
1. Définitions et rappels concernant les automatismes................... S 8 095 – 2
1.1 Définition du cahier des charges................................................................ — 2
1.2 Cahier des charges et qualité...................................................................... — 2
1.3 Particularités de l’automatisme.................................................................. — 2
1.4 Architecture CIM .......................................................................................... — 3
1.5 L’automatisme comme un lot séparé......................................................... — 3
2. Présentation des cahiers des charges................................................ — 4
2.1 Les différents cahiers des charges ............................................................. — 4
2.2 Les difficultés du cahier des charges ......................................................... — 5
3. Recensement et formalisation des besoins...................................... — 5
3.1 Outils de recensement des besoins ........................................................... — 5
3.2 Outils descriptifs.......................................................................................... — 6
4. Proposition d’un sommaire de cahier des charges ........................ — 7
4.1 La réquisition ............................................................................................... — 8
4.2 Les spécifications générales....................................................................... — 8
4.3 Les spécifications particulières................................................................... — 8
4.4 Le questionnaire .......................................................................................... — 10
4.5 Le cadre de réponse .................................................................................... — 11
4.6 Le calendrier prévisionnel........................................................................... — 11
4.7 Les conditions commerciales ..................................................................... — 11
4.8 Les clauses juridiques ................................................................................. — 11
5. L
’absence de cahier des charges.......................................................... — 11
Pour en savoir plus .......................................................................................... Doc. S 8 095
L
s8095.fm Page 1 Vendredi, 30. novembre 2001 10:49 10
CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE _________________________________________________________________________
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
S 8 095 − 2 ©Techniques de l’Ingénieur, traité Informatique industrielle
1. Définitions et rappels
concernant
les automatismes
1.1 Définition du cahier des charges
Le cahier des charges est quelquefois défini comme étant un acte
qui indique les conditions d’un marché, ce marché étant en cours
d’appel d’offre ou déjà conclu. Une définition, plus industrielle,
pourrait être la description précise et exhaustive de ce qu’un
« client » attend d’un « fournisseur ». Les guillemets indiquent que
les termes de « client » et « fournisseur » doivent être pris dans leur
acception la plus large. Par exemple, les deux acteurs peuvent faire
partie d’une même société, voire d’un même service.
Le Gimélec (Groupement des industries de matériel d’équipe-
ment électrique et de l’électronique industrielle associée) fait sienne
la définition que donne l’Afnor du cahier des charges :
Un cahier des charges d’automatisme doit décrire non seulement
la fourniture attendue, matériel, logiciel et, éventuellement, installa-
tion, mais aussi les services les accompagnant (formation, garantie,
hot-line, etc.) et les modalités d’exécution commerciales et juridi-
ques.
1.2 Cahier des charges et qualité
La qualité est définie comme étant « l’ensemble des propriétés et
caractéristiques d’un produit ou service qui lui confère l’aptitude à
satisfaire des besoins exprimés ou implicites ». Or, qu’est-ce qu’un
cahier des charges sinon l’expression des besoins ? Il apparaît donc
une très forte corrélation entre cahier des charges et qualité.
Plus complètement et plus clairement les besoins seront expri-
més, plus les chances seront grandes d’obtenir une prestation de
qualité. Un « bon » cahier des charges est une condition indispen-
sable, même si elle n’est pas suffisante, à la réussite d’un projet,
notamment d’automatisme. Une étude américaine de 1995 portant
sur l’analyse de 8 380 projets a démontré que la moitié des échecs
de projets d’automatisme étaient dus à la mauvaise qualité du
cahier des charges (manque d’informations du client, spécifications
incomplètes, demandes répétées de modifications, demandes uto-
piques, rédaction ambiguë). A titre d’information, l’autre moitié des
échecs était due à une mauvaise planification et un manque de
moyens ou de compétence. Aucun échec dû à des raisons techni-
ques n’a été recensé.
Notons, au passage, que « l’implicite » de la définition de la qua-
lité constitue une des difficultés de l’établissement d’un cahier des
charges.
1.3 Particularités de l’automatisme
Les automatismes sont aujourd’hui en grande partie constitués
par des logiciels et ceux-ci présentent de fortes originalités par rap-
port à d’autres biens industriels que ce soit du point de vue de l’évo-
lutivité, de la fiabilité ou de la maintenance. Les cahiers des charges
devront en tenir compte.
■ Évolutivité
Un point original des automatismes programmés est la relative
facilité avec laquelle il est possible de modifier quelques lignes de
programme pour faire évoluer les fonctions offertes. Cette médaille
trouve fréquemment son envers. La facilité entraîne souvent un cer-
tain manque de rigueur et la multiplication de nouvelles exigences
souvent mal formalisées et dont la justification n’est pas toujours
évidente.
Dans les technologies précédentes, relais ou modules électroni-
ques, un prescripteur hésitait longuement avant de demander le
décâblage puis le recâblage de tout ou partie d’une armoire de
relayage. Aujourd’hui, devant un logiciel, il hésite beaucoup moins.
■ Fiabilité
Une autre des grandes particularités des automatismes réside
dans les courbes de fiabilité. La fiabilité d’un équipement mécani-
que ou électromécanique (moteur, contacteur, relais...) est représen-
tée par la courbe bien connue dite « en baignoire » (figure 1) alors
que les logiciels ont une courbe de fiabilité décroissante jusqu’à
l’asymptote à zéro (figure 2). Les logiciels ne connaissent pas les
défauts de vieillesse.
Cette particularité a une répercussion immédiate sur les condi-
tions de garantie par exemple et sur les conditions de maintenance.
Glossaire
Partie opérative
Ensemble des moyens matériels opérant physiquement sur
les matières d’œuvre ou les utilités en vue d’assurer la produc-
tion.
Partie commande
Ensemble des moyens de traitement de l’information permet-
tant la commande et le pilotage d’une ou plusieurs partie(s)
opérative(s).
Avant-projet sommaire (APS)
Appelée aussi quelquefois Étude de faisabilité ou Étude préa-
lable, cette phase d’un projet doit voir les tâches suivantes :
— recensement des solutions plausibles ;
— examen des deux ou trois solutions les plus séduisantes ;
— comparaison ;
— préconisation de la meilleure solution ou compromis entre
plusieurs parties de solutions.
Avant-projet détaillé (APD)
Cette phase du projet fait suite à la précédente et permet
d’étudier à fond la solution retenue en fin d’APS.
Hot line
Permanence téléphonique qui permet au fournisseur de
résoudre, à distance, un certain nombre de problèmes.
« Document établi par le demandeur définissant les clauses
techniques, les clauses de qualité et les clauses administratives
applicables à la fourniture recherchée ; il sert de base à la propo-
sition du fournisseur et pourra faire l’objet d’un contrat ».
Figure 1 – Fiabilité d’un équipement mécanique
ou électromécanique
Période d'exploitation normale
Défauts
de
jeunesse
Défauts
de
vieillesse
Âge
Taux
de
défaillance
s8095.fm Page 2 Vendredi, 30. novembre 2001 10:49 10
_________________________________________________________________________ CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
©Techniques de l’Ingénieur, traité Informatique industrielle S 8 095 − 3
Il est à noter que le taux de défaillance d’un équipement électro-
mécanique dépend non seulement de la qualité intrinsèque de
l’équipement, de la responsabilité du constructeur mais aussi des
conditions d’utilisation qui sont de la responsabilité de l’utilisateur.
Ainsi un relais dont les contacts sont calibrés pour 10 A aura un taux
de défaillance moindre (et une durée de vie plus longue) s’il est uti-
lisé pour établir des courants de 5 A que s’il est utilisé pour des cou-
rants de 10 A et quelquefois un peu plus. Rien de tel avec les
logiciels, bien sûr.
■ Maintenance
Pour un équipement industriel classique, la maintenance consiste
à maintenir les caractéristiques et les performances originelles de
cet équipement.
Lorsqu’il s’agit d’un logiciel, le terme « maintenance » prend un
tout autre sens. Il s’agit d’implanter les nouvelles versions du sys-
tème d’exploitation, d’intégrer de nouvelles fonctions ou de perfec-
tionner des fonctions déjà existantes. Il ne s’agit plus de « main-
tenir » au sens étymologique du terme mais bien d’« améliorer » les
performances initiales.
De nombreuses études ont constaté que le coût d’acquisition
d’un logiciel ne représentait guère plus de 50 % du coût global
de possession.
■ Phasage d’un projet d’automatisme
Tous les projets, pour être correctement conduits, et donc plani-
fiés, doivent être décomposés en tâches et en sous-tâches. Pour les
raisons évoquées ci-dessus, notamment l’évolutivité et le laxisme
qui risque d’en découler, cette obligation est d’autant plus pressante
lorsqu’il s’agit de projets d’automatisme.
Plus encore, il semble judicieux de ne s’engager que pour une
étape bien définie : analyse fonctionnelle de l’avant-projet som-
maire, analyse fonctionnelle de l’avant-projet détaillé, puis analyse
organique et développement. Ceci va dans l’intérêt des deux par-
ties, le client comme le prestataire. En effet les risques de dérive
sont nombreux, apparition de nouvelles fonctionnalités, besoins
accrus d’optimisation, etc., pour les mêmes raisons que celles évo-
quées plus haut. Il devient alors difficile de maintenir les clauses
contractuelles initiales et alors, soit le prestataire doit faire face à un
surcroît de travail non rémunéré, soit l’acquéreur reçoit de multiples
avenants qui l’indisposent. Dans les deux cas, la situation devient
vite tendue. Mieux vaut procéder par étapes plus courtes et donc
mieux maîtrisées de part et d’autre.
■ Cas des progiciels
La jurisprudence montre que l’acquéreur d’un logiciel spécifique
qui n’a pas pris la peine d’exprimer correctement ses besoins et qui
est mécontent de la prestation de son fournisseur est le plus sou-
vent débouté. Le cahier des charges est donc « jurispruden-
tiellement » parlant incontournable.
Le cas des progiciels est sensiblement différent. Par définition, un
progiciel (produit logiciel) est disponible, entièrement terminé,
avant même que l’on envisage son acquisition. La jurisprudence
estime donc que l’acheteur peut évaluer le progiciel avant l’acte
d’achat. Elle en déduit que l’acheteur n’est pas tenu de rédiger un
cahier des charges. Il connaît ses besoins et peut juger si le produit
répond à ses besoins. Cette position est un peu formelle, car s’il est
techniquement possible d’évaluer un traitement de texte en quel-
ques heures, il en va tout autrement d’un progiciel d’ordonnance-
ment temps réel ou d’un superviseur disposant de multiples
fonctionnalités. Le seul recours possible, en cas de déconvenue,
réside alors dans les « vices cachés ». A tout prendre, il vaut mieux
travailler avec un bon cahier des charges.
1.4 Architecture CIM
Est-il besoin de rappeler ce qu’est l’architecture CIM (Computer
Integrated Manufacturing) ? Ce concept a vu le jour au courant des
années 1980. Il permet de structurer les automatismes du point de
vue fonctionnel. Ainsi, nous pouvons distinguer les niveaux sui-
vants (tableau 1) :
— le niveau 0 concerne les capteurs, les actionneurs et les pré-
actionneurs, les automatismes « réflexes » de sécurité primaires ;
— le niveau 1 s’intéresse de façon modulaire à l’automatisation
d’une machine ou d’un poste de travail ;
— le niveau 2 fédère les automatismes de niveau 1 d’un ensem-
ble cohérent, ligne de production ou partie de ligne. Il s’appelle sou-
vent supervision. Il peut inclure une partie de l’ordonnancement très
court terme ou cadencement, appelé aussi MES (Manufacturing
Execution System). Dans le cadre de la gestion des fonctions d’un
entrepôt, les automatismes de niveau 2 sont souvent appelés WMS
(Warehouse Management System) ;
— le niveau 3 traite des fonctions de gestion de production et de
gestion commerciale ; il ne fait plus partie de l’automatisation pro-
prement dite ;
— les niveaux supérieurs gèrent la finance de l’entreprise, le per-
sonnel, etc.
Ce concept a été très en vogue à son apparition, puis a été décrié
par une presse technique peu au fait des réalités industrielles. Il est
maintenant mature ; on en parle moins mais on le réussit mieux.
Cette architecture fonctionnelle est un outil méthodologique très
utile pour bien structurer un ensemble d’automatisme. Il est recom-
mandé de l’utiliser dès le début de la phase de conception et d’éla-
boration des spécifications.
(0)
1.5 L
’automatisme comme un lot séparé
Une question fondamentale se pose dès que la conception d’un
système complet est terminée. Doit-on confier la réalisation des
automatismes au constructeur de la partie opérative ou faire appel
à un automaticien spécialiste ? Et donc, doit-on rédiger un ou deux
cahiers des charges ?
Figure 2 – Fiabilité d’un logiciel
Défauts de
jeunesse
Modification
Période d'exploitation normale
Taux
de
défaillance
Âge
Tableau 1 – Pyramide du CIM
Niveau Fonction Matériel Temps de
réponse
3 et au-dessus Gestion
de production
et autres
Ordinateurs
plus puissants
Temps différé
Traitement
batch
2 Supervision
d’une ligne
Petits
ordinateurs
De l’ordre de
20 s
1 Commande
d’une machine
Automate
programmable
De l’ordre de
300 ms
0 Entrées
Sorties
Capteurs
Actionneurs
De l’ordre de
30 ms
s8095.fm Page 3 Vendredi, 30. novembre 2001 10:49 10
CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE _________________________________________________________________________
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
S 8 095 − 4 ©Techniques de l’Ingénieur, traité Informatique industrielle
La réponse aux question suivantes permet d’effectuer un choix
pertinent :
Traiter les automatismes comme un lot séparé permet de choisir
la meilleure offre de mécanique et, à côté, la meilleure offre d’auto-
matisme ; en revanche, cela oblige le maître d’ouvrage, ou son maî-
tre d’œuvre délégué, à coordonner les deux lots, ce qui n’est pas
toujours une tâche facile.
La question ne doit pas se poser pour des fonctions d’automa-
tisme que le constructeur mécanicien a déjà réalisées de multiples
fois. Il serait dommage de se priver de son expertise acquise au fil
du temps.
Les cahiers des charges seront fondamentalement différents sui-
vant la décision prise.
2. Présentation des cahiers
des charges
2.1 Les différents cahiers des charges
Pour bien comprendre la problématique du cahier des charges, il
paraît important de recenser les différents types auxquels ils appar-
tiennent. Ainsi, les dichotomies suivantes peuvent être envisagées
en fonction de leurs destinataires ou de leur place dans le calendrier
général du projet.
■ Cahier des charges de projet ou de produit
Le propre d’un projet est d’être unique et réalisé pour le compte
d’un client alors que la caractéristique principale d’un produit est
d’être destiné à de très nombreux clients qui ne sont pas connus
lors de la conception dudit produit.
Un cahier des charges de projet, l’automatisation d’un atelier par
exemple, est généralement fait par le client lui-même ou son maître
d’œuvre qui sont l’un et l’autre parfaitement au fait des besoins à
satisfaire. De plus, le cahier des charges peut être amendé ultérieu-
rement, lors de la réalisation, par des accords intervenant entre le
client et son fournisseur.
Dans le cas des produits, automatisation d’une voiture ou d’une
machine outil par exemple, la problématique est toute autre ; le
rédacteur du cahier des charges doit travailler pratiquement seul sur
des besoins qui ne le concernent sans doute pas en tant qu’utilisa-
teur. C’est là que les outils de recensement des besoins décrits plus
loin rendent les plus grands services.
■ Cahier des charges interne ou externe
Un cahier des charges peut être établi pour définir ce que l’on
attend d’un prestataire extérieur à la société à laquelle on appartient
ou de ce que l’on attend d’un service interne, service automatisme
ou service informatique.
Dans le premier cas, le document sera plus formel et comprendra
toute une série de rubriques concernant les conditions de paiement,
les pénalités en cas de retard, les tribunaux compétents en cas de
litige, etc. Ces rubriques sont bien sûr inutiles lorsque tous les
acteurs se trouvent à l’intérieur d’une même société.
En revanche, le cœur du cahier des charges, c’est-à-dire la partie
expression des besoins, l’analyse fonctionnelle, devrait être rigou-
reusement la même dans les deux cas.
■ Cahier des charges de consultation ou de commande
Le cahier des charges d’un projet vit deux phases bien distinctes.
Dans un premier temps, il va permettre de faire appel à la concur-
rence dans une procédure d’appel d’offres. Dans un second temps,
il doit formaliser, en termes contractuels, les accords entre le client
et le fournisseur retenu.
En simplifiant les choses à l’extrême, un cahier des charges de
consultation ne devrait parler que de besoins alors qu’un cahier des
charges de commande (une fois le fournisseur choisi entre tous
ceux qui ont été consultés) ne devrait s’exprimer qu’en termes de
solutions et de moyens.
Par exemple, un industriel souhaite acquérir l’automatisme d’une
machine. Lors de la consultation, il décrira les fonctions et les per-
formances attendues. Ensuite, parmi les différentes offres qu’il aura
reçues, l’une d’elles lui paraîtra plus séduisante que les autres, car
l’automaticien aura proposé des automates de tel constructeur, une
architecture bien adaptée, un chef de projet expérimenté pour con-
duire le projet, etc.
Alors que le cahier des charges de consultation était ouvert, lais-
sant le champ libre au consulté pour exprimer toute sa créativité,
tout son savoir-faire personnel, le cahier des charges de commande
va se « verrouiller » en reprenant tous les points de l’offre qui l’ont
fait choisir.
En pratique, il est rare qu’un client puisse laisser une entière
liberté aux consultés pour choisir eux-mêmes tous les moyens
nécessaires à la satisfaction de son besoin. Toutefois, il est recom-
mandé de laisser la plus grande marge de manœuvre raisonnable-
ment admissible.
■ Appel à la créativité ou commande à façonnier
La position exposée dans le paragraphe précédent n’est pas tou-
jours la meilleure. Certaines sociétés multinationales préfèrent
mener des études très approfondies en interne avant toute consul-
tation et lancer un appel d’offres qui n’est exprimé non plus en
termes de besoins mais en termes de moyens et de solutions parfai-
tement définis. C’est ce que l’on appelle faire appel à des
« façonniers ». On ne sollicite plus alors, leur créativité mais leur
seule compétence en réalisation.
Cette démarche permet d’obtenir des équipements rigoureuse-
ment identiques dans toutes les usines du groupe dans le monde
entier. Les performances sont analogues et toutes sont au niveau de
la conception initiale.
Le personnel peut aisément aller d’usine en usine sans jamais se
trouver dépaysé devant des équipements inconnus.
Le stock de pièces de rechange peut être sensiblement réduit.
L’intégration d’une nouvelle version d’un module logiciel peut être
réalisée simultanément ou presque sur tous les sites.
De plus, notons au passage, même si cela est subsidiaire, qu’il
devient beaucoup plus facile de comparer les offres.
■ Appel à variante
Un compromis existe entre les cahiers des charges « ouverts » et
les cahiers des charges « verrouillés » ; c’est l’appel à variante. Dans
ce cas, le cahier des charges décrit avec précision la solution souhai-
tée. L’offre devra répondre au scénario décrit. Mais la liberté est lais-
sée au consulté de répondre, à côté, suivant une solution
personnelle qu’il pense être plus performante ou plus compétitive.
■ Vue externe ou vue interne
La description d’un automatisme peut être donnée par une « vue
externe » ou une « vue interne ». L’approche « vue externe » consi-
● La part de l’automatisme est-elle importante et/ou
complexe ?
● Les fonctionnalités requises sont-elles spécifiques ou sont-
elles standards pour le constructeur mécanicien ?
● Le constructeur mécanicien dispose-t-il d’un service
« automatismes » adapté à la taille du problème, en effectifs et
en compétence ?
● L
’automatisme doit-il fédérer plusieurs parties opératives
de constructeurs différents ?
s8095.fm Page 4 Vendredi, 30. novembre 2001 10:49 10
_________________________________________________________________________ CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
©Techniques de l’Ingénieur, traité Informatique industrielle S 8 095 − 5
dère l’automatisme comme une « boîte noire » et n’est alors défini
que ce que l’on attend de cette entité : quelles fonctions ? à partir de
quelles entrées ? pour animer quelles sorties ?
A l’inverse, l’approche « vue interne » décrit l’intérieur de la
boîte : architecture, organisation des mémoires, éventuellement
algorithmique, etc.
Sauf dans le cas de commande à façonnier, il est nettement préfé-
rable de pratiquer la vue externe.
■ Les cahiers des charges successifs
Les cahiers des charges font souvent partie intégrante d’un projet
complet. Ce projet connaîtra une toute première étape : le plan
directeur. Se succéderont ensuite l’avant-projet sommaire, puis
l’avant-projet détaillé, la consultation des entreprises et enfin arri-
vera la phase de réalisation.
Il est évident que les cahiers des charges se préciseront à chacune
des étapes. Au fil du temps, les problèmes feront place à des axes
de solution et l’on passera du qualitatif au quantitatif. Par exemple,
du « temps réel », notion un peu vague, l’on s’acheminera vers un
nombre précis de millisecondes, etc. (figure 3).
2.2 Les difficultés du cahier des charges
Recenser les difficultés souvent rencontrées devrait permettre de
mieux les surmonter. Celles auxquelles on se heurte le plus fré-
quemment sont les suivantes.
■ Accélération du cycle de vie
Si, depuis bien longtemps, beaucoup d’efforts sont faits pour rac-
courcir les temps de mise en œuvre d’un projet, force est bien de
reconnaître que l’on assiste à une très forte accélération de cette
tendance. Le concept d’ingénierie simultanée n’est pas récent mais
les contraintes deviennent de plus en plus fortes au fur et à mesure
que des outils se développent pour le faciliter : planification, travail
en groupe, EDI, Internet et Intranet, etc. Cette organisation implique
l’obligation de modifier le cahier des charges lorsque les données
de l’étude amont (et néanmoins menée simultanément) changent.
■ Distinction entre besoins et solutions
Les techniciens sont des imaginatifs et dès qu’un problème leur
est posé, ils entrevoient immédiatement des axes de solution. Il est
toujours difficile, même pour les gens d’expérience de prendre suf-
fisamment de recul pour examiner toutes les solutions qui peuvent
satisfaire le besoin et non pas la première qui vient à l’esprit. C’est
le grand intérêt de la phase d’avant-projet sommaire pratiquée par
les ingénieries ; elle impose d’étudier deux ou trois solutions et de
les comparer. La phase suivante, avant-projet détaillé, ne considère
plus que celle qui aura été retenue en fin d’APS.
■ Arbitrage entre exhaustivité et concision
Il pourrait sembler souhaitable qu’un cahier des charges soit le
plus complet et le plus exhaustif possible. Le temps accordé à la
rédaction d’un cahier des charges étant limité, l’épaisseur du dos-
sier est par là même limitée. Mais aussi l’expérience (enquête effec-
tuée auprès de plusieurs dizaines d’entreprises) montre qu’au delà
d’un certain nombre de pages, le lecteur n’exploite plus correcte-
ment et/ou complètement les données qui lui sont fournies. L’étude
a conclu que le nombre maximal de pages d’un cahier des charges
était de l’ordre de 50.
L’on retrouve ici, la notion des besoins implicites évoqués dans la
définition de la qualité donnée dans le paragraphe 1.2. Quels sont
les besoins que l’on doit expliciter et quels sont ceux que l’on peut
considérer comme implicites ? La réponse sera donnée par une
réflexion de pur bon sens et par la connaissance que l’on aura de
ses partenaires. La référence à des normes permet fréquemment
d’alléger le texte.
■ Véritables et fausses contraintes
La distinction entre les besoins et les contraintes n’est pas tou-
jours facile, mais la distinction entre vraies et fausses contraintes est
encore plus difficile. Le rédacteur du cahier des charges dispose
d’une chance de remettre en cause des contraintes « historiques »
dont la raison d’être a disparu depuis longtemps mais qui perdurent
seulement par habitude.
■ Lisibilité
L’on verra plus loin qu’il existe de nombreux langages pour
décrire ce que l’on attend d’un automatisme ; mais le français littéral
reste quand même le plus utilisé. Le cahier des charges sera
d’autant plus lisible que l’on utilisera des phrases courtes : sujet,
verbe complément. Ne s’agissant pas d’une œuvre littéraire, il ne
faut pas craindre les répétitions ; utiliser plusieurs mots synonymes
pour désigner la même chose risque de prêter à confusion. Ceci est
d’autant plus vrai que l’on destine la spécification à la traduction
dans une langue étrangère. Le traducteur ne sera pas forcément
spécialiste des automatismes ou du process à automatiser.
3. Recensement et
formalisation des besoins
3.1 Outils de recensement des besoins
Avant même d’exprimer les besoins, il est nécessaire de recenser
tous ceux qui devront être explicités. Pour cela, il existe plusieurs
entrées au cahier des charges et plusieurs outils méthodologiques.
Figure 3 – Les cahiers des charges successifs
Cahier des
charges de
consultation d'APS
Consultation
et choix du
prestataire
Cahier des
charges de
commande d'APS
Exécution d'APS
et décision d'APD
Cahier des
charges de
consultation d'APD
Consultation
et choix du
prestataire
Cahier des
charges de
commande d'APD
Exécution d'APD
et décision de
réalisation
Etc.
APS
APD
avant-projet sommaire
avant-projet détaillé
s8095.fm Page 5 Vendredi, 30. novembre 2001 10:49 10
CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE _________________________________________________________________________
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
S 8 095 − 6 ©Techniques de l’Ingénieur, traité Informatique industrielle
3.1.1 Entrées du cahier des charges
Les outils créés pour élaborer la liste des besoins sont nombreux
et ne sont surtout pas exclusifs les uns des autres. Il est recom-
mandé de les utiliser tous, ainsi un besoin qui aurait pu être oublié
lors de l’utilisation d’un outil aura moins de chance d’être oublié
avec un autre type de réflexion.
■ L’expérience du rédacteur
Bien sûr, la première entrée est constituée par la connaissance
qu’a le rédacteur à la fois des automatismes et du process à automa-
tiser. Néanmoins, le rédacteur chevronné ne devra pas tomber dans
le piège qui consisterait à considérer trop de besoins comme impli-
cites, son expertise les lui faisant apparaître comme évidents.
Les outils méthodologiques suivants seront d’autant plus utiles
que l’on sera novice mais ils peuvent aussi apporter une aide cer-
taine aux praticiens d’expérience.
■ Les check-lists
La check-list (liste de vérification) est surtout utilisée dans les
bureaux d’étude ou d’ingénierie qui ont le souci de capitaliser leur
savoir-faire acquis au fil des projets précédents. Ces check-lists sont
enrichies à chaque nouveau projet et elles permettent d’améliorer à
la fois la productivité du rédacteur et la qualité de la rédaction. La
forme la plus élémentaire de la check-list est le cahier des charges
(ou parties du cahier des charges) du projet précédent se rappro-
chant le plus du projet en cours.
■ Les interviews
Une autre entrée est constituée par les interviews de tous les
acteurs concernés. Parmi ceux-ci figurent en première place les
futurs exploitants, mais sont aussi concernés, les agents de mainte-
nance, les responsables de la gestion de production, les qualiticiens,
le service achats, etc.
Il serait dommage de ne pas exploiter toutes les informations que
l’on peut glaner aux contacts de ces professionnels. Par contre, la
tâche n’est toujours facile : manque de disponibilité des interlocu-
teurs, timidité, trop grande modestie et barrières de toutes sortes.
Pour débloquer les cas difficiles, il peut être utile de prévoir un
questionnaire, utilisé en dernière extrémité.
■ La méthode FAST
Acronyme de Functional Analysis System Technique, cet outil
méthodologique a été conçu, comme les deux suivants, par des
concepteurs devant spécifier des produits, ce qui présente des diffi-
cultés encore plus grandes que dans le cas d’un projet d’automa-
tisme puisque le client réel n’est pas connu et ne peut donc pas
exprimer son besoin.
Cette méthode préconise de recenser toutes les tâches nécessai-
res à la satisfaction du besoin et, suivant un formalisme bien précis,
de les organiser de telle façon que la tâche N – 1 explique l’utilité de
la tâche N (réponse à la question « pourquoi ? ») et la tâche N + 1
donne le mode opératoire (réponse à la question « comment ? »).
Nota : concernant la méthode FAST, le lecteur pourra consulter l’article [1] des Techni-
ques de l’Ingénieur, ainsi que la référence [7].
■ La méthode SAFE
Acronyme de Sequential Analysis of Functional Elements, cette
méthode recommande de décliner toutes les actions que l’on sou-
haite voir se dérouler dans l’ordre chronologique, suivant un forma-
lisme bien pensé puis d’en déduire toutes les fonctions nécessaires
à l’accomplissement de ces actions (se reporter à l’ouvrage [7]).
■ La méthode des interacteurs
Cette méthode, encore appelée APTE du nom du cabinet d’étude
qui l’a mise au point (Applications des techniques d’entreprises de
Paris), procède d’une autre approche. Elle consiste à recenser tous
les acteurs concernés par l’objet du cahier des charges : exploitants,
agents de maintenance, qualiticiens, etc., et de répertorier toutes les
fonctions qui leur seront nécessaires dans l’exercice de leurs fonc-
tions. Le terme d’acteur doit être pris dans son acception la plus
large ; il recouvre aussi l’environnement, les réseaux d’énergie...
■ La méthode GRAIL/KAOS
KAOS est une méthodologie pour l’analyse des besoins guidée
par les objectifs à atteindre. Son complément, GRAIL, est un outil
informatique support de la méthode qui est à la fois un éditeur
structuré et un vérificateur sémantique et syntaxique. Cette
méthode a été développée par des chercheurs de l’Université catho-
lique de Louvain.
3.1.2 Les outils informatiques
La tentation est toujours grande pour les automaticiens de tenter
d’automatiser leur propre activité. Ainsi ont été développés notam-
ment les outils logiciels suivants :
— GENERIS de la société Saint-Gobain ;
— KSIS développé à l’instigation de la société Elf ;
— TRIFON d’Euriware.
3.2 Outils descriptifs
3.2.1 Outils descriptifs généraux
■ Français littéral
Il s’agit là, bien sûr, du véhicule de la pensée le plus utilisé. Pour
autant que la rédaction soit de qualité, il est universel.
■ GEMMA
Acronyme de Guide d’Étude des Modes de Marche et d’Arrêt, cet
outil méthode, fruit d’un travail collectif, est d’une remarquable effi-
cacité pour effectuer la synthèse d’une analyse fonctionnelle et ini-
tialiser une analyse « dysfonctionnelle », si l’on peut s’exprimer
ainsi.
En effet, nombre de concepteurs se focalisent sur la ou les mar-
ches normales et ont une fâcheuse tendance à omettre les régimes
de marches perturbées et encore plus le passage d’un mode de mar-
che à un autre. Par ailleurs, cet outil décrit très bien « ce qu’il ne faut
pas faire » alors que tous les autres cités plus loin décrivent bien
« ce qu’il faut faire ».
L’application de cette méthode est très simple et pourtant son uti-
lisation n’est pas encore généralisée comme elle le devrait.
3.2.2 Outils descriptifs du niveau 1
Il est à noter qu’un cahier des charges d’automatisme de niveau 1
du CIM peut utiliser plusieurs langages dans le même document
pour décrire des fonctions ayant des caractéristiques différentes.
■ Français littéral
Mêmes remarques que précédemment : d’un usage universel.
■ GRAFCET
Fruit d’une réflexion collective française, le GRAFCET (Graphe de
Commande à Étapes et Transitions) est maintenant mondialement
utilisé. Il permet de décrire d’une façon très claire toutes les fonc-
tions séquentielles d’un automatisme industriel.
L’on distingue le GRAFCET de niveau 1 qui est un véritable
« Espéranto » pour automaticiens et mécaniciens et le GRAFCET de
niveau 2, plus détaillé, plutôt réservé aux seuls automaticiens. Ce
GRAFCET de niveau 2 permet également, grâce à son formalisme
rigoureux, la traduction automatique en langage machine lors de la
programmation des automates programmables notamment.
s8095.fm Page 6 Vendredi, 30. novembre 2001 10:49 10
_________________________________________________________________________ CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
©Techniques de l’Ingénieur, traité Informatique industrielle S 8 095 − 7
Nota : ces deux niveaux n’ont rien à voir avec les niveaux du CIM dont il a été question
plus haut.
Nota : concernant le GRAFCET, le lecteur pourra se reporter à l’article [2] desTechniques
de l’Ingénieur.
■ Logigramme
Les logigrammes ont été très utilisés à l’époque où les modules
logiques électroniques étaient la technologie reine. Ils ne sont plus
guère employés que lors de la conception de circuits intégrés. Ils
sont basés sur l’utilisation des symboles des grandes fonctions élé-
mentaires logiques : ET, OU, NI, PAS, Temporisation, Mémoire, etc.
Ils font l’objet d’un formalisme décrit par la norme européenne
EN 61 346.
■ Chronogramme
Les chronogrammes sont particulièrement utiles dans la descrip-
tion de séquences d’automatisme très rapides, quand le synchro-
nisme ou l’ordre de succession des différentes actions sont
cruciaux. Le formalisme du chronogramme se rapproche beaucoup
de celui d’un diagramme de Gantt enrichi des liaisons de corrélation
des tâches de type PERT (Program Evaluation and Review Techni-
que).
Nota : concernant la méthode PERT et le diagramme de Gantt, le lecteur pourra consul-
ter l’article [3] desTechniques de l’Ingénieur.
■ Schéma à contacts
Les schémas à contact ont une vie étonnement longue à l’ère de
la programmation. Ils ne sont cités que pour mémoire et de toute
façon ne peuvent plus être utilisés que pour la description d’auto-
matismes extrêmement succincts.
3.2.3 Outils descriptifs du niveau 2
Contrairement à ce qui peut se faire pour les automatismes de
niveau 1 du CIM, un cahier des charges d’un automatisme de niveau
2 se doit d’utiliser un seul langage descriptif quel qu’il soit. Le fran-
çais littéral ne sera plus cité que pour mémoire. Il apparaît judicieux
d’opter pour le langage le mieux partagé entre les différents parte-
naires ou, à défaut de les connaître, le langage que l’on pense le
mieux connu, le mieux adapté ou le plus répandu.
■ Ordinogramme
Les ordinogrammes ont été l’un des premiers outils des informa-
ticiens (Ils sont souvent appelés à tort organigrammes). Chacun les
a vus au moins une fois même s’ils sont de moins en moins utilisés.
Le symbole essentiel est un losange contenant une question et com-
portant deux chemins de sortie l’un répondant à la question par oui,
l’autre par non. Ils sont purement graphiques. Ils ont fait l’objet
d’une norme annulée.
■ SADT/IDEF0
Acronyme de Structured Analysis and DesignTechnique, c’est un
outil, créé en 1977, d’expression des besoins très répandu dans le
milieu de l’informatique industrielle après avoir été conçu pour des
applications de gestion. Son approche est descendante et son for-
malisme extrêmement rigoureux le rend quelquefois laborieux à
établir (pour bien le maîtriser, une formation d’au moins deux
semaines est nécessaire à un informaticien déjà expérimenté) mais
il est tellement plaisant à lire ! Il s’agit d’un outil qui apporte beau-
coup plus qu’un mode de représentation graphique.
Son symbole principal est l’actigramme, rectangle contenant un
verbe à l’infinitif indiquant une action. Le côté gauche est réservé
aux entrées, déclencheurs de l’action, le côté droit est dédié aux sor-
ties, résultat de l’action, le côté supérieur indique les données utili-
sées alors que la face inférieure indique les moyens utilisés.
La méthode IDEF0 est une extension de SADT et IDEF1 s’applique
aux données.
Nota : concernant la méthode SADT, le lecteur pourra consulter l’article [1] des Techni-
ques de l’Ingénieur.
■ SART
Acronyme de Structured Analysis / RealTime, c’est une méthode
plus orientée vers la spécification de systèmes d’automatisme à
forte contraintes de temps de réponse et de synchronisme. C’est
dans les milieux universitaires qu’il est le plus utilisé.
■ MERISE
La méthode MERISE (Analyse et conception des systèmes d’infor-
mation) date de la fin des années 1970 ; elle a été mise au point à la
demande du ministère de l’Industrie de l’époque pour aider les
administrations à formuler leurs besoins. Elle se définit comme une
« Méthode de définition d’un système d’information ». Bien que son
formalisme soit relativement complexe, la démarche proposée offre
l’originalité de séparer l’étude des données de l’étude des traite-
ments à effectuer sur lesdites données. Il s’agit là aussi d’un outil
qui apporte beaucoup plus qu’un mode de représentation graphi-
que.
Cette méthode a mis beaucoup de temps à s’imposer dans les
milieux industriels, mais c’est maintenant chose faite, du moins en
France.
Elle propose un phasage très structuré :
— schéma directeur ;
— étude préalable ;
— étude détaillée ;
— étude technique ;
— production du logiciel ;
— mise en œuvre,
et pour chacune de ces phases, elle impose une démarche nécessi-
tant l’établissement pour les données des modèles suivants :
— modèle conceptuel des données ;
— modèle logique optimisé ;
— modèle physique ;
— cycle de vie des objets,
et pour les traitements :
— modèle conceptuel des traitements ;
— modèle organisationnel des traitements ;
— modèle opérationnel des traitements.
Une autre des originalités de cette méthode est l’usage qu’elle fait
de la cardinalité minimale et maximale.
Ces documents établis lors des phases initiales du projet consti-
tuent le cahier des charges des phases suivantes.
■ ALBERT
Acronyme de Agent-oriented Language for Building and Eliciting
RealTime systems, cette méthode et ce langage ont été développés
dans le cadre d’un projet Esprit 2 par une équipe animée par des
chercheurs belges.
■ Nassi Shneidermann et les autres
Nous ne citerons que pour mémoire cette méthode descriptive
proposée par des ingénieurs d’IBM. Elle était structurée feuille à
feuille ce qui rendait sa manipulation remarquablement aisée.
D’autres méthodes ont vu le jour, mais sont restées d’un usage
moins répandu.
4. Proposition d’un sommaire
de cahier des charges
La structure la plus complète d’un cahier des charges élaboré par
les sociétés d’ingénierie est composée des éléments suivants.
s8095.fm Page 7 Vendredi, 30. novembre 2001 10:49 10
CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE _________________________________________________________________________
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
S 8 095 − 8 ©Techniques de l’Ingénieur, traité Informatique industrielle
4.1 La réquisition
La réquisition est en fait le sommaire complet de tout le dossier
de consultation. Elle rappelle tous les éléments constitutifs du dos-
sier avec l’indication rigoureuse des indices de révision. Le soin
apporté à sa mise à jour évitera beaucoup de malentendus par la
suite : travail sur des dossiers incomplets en toute ignorance, utilisa-
tion de documents périmés, etc. La réquisition indique également
l’ordre de préséance des documents : le premier cité l’emporte sur
les suivants en cas de contradiction.
4.2 Les spécifications générales
Les spécifications générales permettent d’améliorer la producti-
vité du bureau d’étude mais aussi la qualité des documents pro-
duits.
Améliorer la productivité car cet élément sera utilisé pour tous les
lots d’un même projet et/ou pour tous les projets d’une même tech-
nologie. Ce document peut être amélioré ou complété à chaque
nouvelle occasion mais point n’est besoin de repartir, chaque fois,
de zéro.
Améliorer la qualité aussi car cette pratique des spécifications
générales évite d’éventuels oublis et permet de capitaliser le savoir-
faire à chaque nouveau projet. Que contiennent les spécifications
générales ?
■ Les informations mises en facteur
Ce document ou ce chapitre comprendra toutes les informations
communes soit au projet soit à la technologie.
Les spécifications générales d’une technologie définiront toutes
les données invariantes d’un projet à l’autre comme les normes
applicables, la méthodologie à suivre, les règles de calcul préconi-
sées, les coefficients de sécurité choisis, le mode de repérage de la
filerie imposé (sans, fils de couleur, numérotation indépendante,
tenant / aboutissant) etc.
Dans le cas des spécifications générales d’un projet, seront men-
tionnés, par exemple, l’adresse du site, les moyens d’accès, le nom
des acteurs, les références et coordonnées des organismes concer-
nés, médecine du travail, Inspection du travail, organisme de sécu-
rité, etc.
■ Les modèles à instancier
Les spécifications générales peuvent inclure des schémas types
indiquant les principes que l’on souhaite voir mis en œuvre. Seules
les valeurs numériques seront à personnaliser par la suite. Par
exemple, pour l’alimentation d’une ligne de production, l’on trou-
vera le schéma type d’une « tête de filerie ». En effet, pourquoi se
reposer toujours les mêmes questions : combien de secondes doi-
vent séparer la mise sous tension des entrées d’automates de la
mise sous tension des sorties ? Combien de secondes doit-il y avoir
entre l’alimentation des circuits transitiques de celle des robots ?
Seuls les calibres des circuits d’alimentation et de protection reste-
ront à définir en cours d’étude.
■ Les méthodes imposées
Pourront être mentionnés également dans les spécifications
générales, les méthodes et les outils que l’on souhaite voir utilisés
comme tel logiciel de gestion de projet, tel simulateur de partie opé-
rative, etc.
4.3 Les spécifications particulières
C’est dans ce chapitre que l’on va trouver toute l’originalité du
projet. C’est pour cela qu’il est difficile ici d’en parler autrement
qu’en termes généraux.
■ L’objet du cahier des charges
Il est recommandé de décrire de façon synthétique, en une demi-
page au maximum, l’objet du cahier des charges. C’est à la fois effi-
cace et courtois. Cela permettra au responsable de l’équipe qui doit
répondre à l’appel d’offre de savoir si le projet proposé est de sa
compétence et, si oui, quel ingénieur le plus apte (compétence par-
ticulière, expérience d’un problème semblable, lieu de résidence...),
sera désigné pour étudier le dossier et ce, sans avoir à lire plusieurs
dizaines de pages.
■ La présentation du projet
Le paragraphe suivant situera l’action en général. On y trouvera
notamment :
— le nom et les coordonnées des acteurs principaux ;
— l’adresse du site et les moyens d’accès ;
— les horaires pratiqués et toutes les procédures particulières
(attribution de badge, etc.), en évitant les redondances avec les spé-
cifications générales du projet, si elles existent.
■ Le glossaire
La présence d’un glossaire est une sage précaution, voire dans
certains cas une précaution indispensable. En effet, il est bien rare
qu’une société ne possède pas plusieurs mots qui lui sont propres
ou des mots d’un usage courant mais qui, dans le cadre de la
société, ont une signification tout à fait particulière.
Le glossaire peut se placer en tête du document ou en fin. Il sem-
ble préférable de le placer au début.
■ Les données de base
Le chapitre suivant définira la volumétrie du projet. Ainsi, à titre
d’exemple, dans le cahier des charges de l’automatisation d’une
bibliothèque l’on précisera le nombre de volumes à accueillir, le
nombre de lecteurs, les horaires d’ouverture, les délais d’attente
souhaités, le nombre de lecteurs attendus, le nombre de places assi-
ses, etc.
Pour l’automatisation d’un entrepôt, seront énoncés le nombre de
palettes en entrée, la loi d’arrivée des camions, la capacité du stock,
le nombre de commandes à servir, le nombre de cartons à préparer,
etc.
Ces données sont quantitatives bien sûr, mais aussi qualitatives.
Les valeurs annoncées concerneront les moyennes mais aussi les
pointes, variations saisonnières ou autres.
■ La définition du besoin (analyse fonctionnelle)
Il s’agit là de la partie la plus importante, le cœur du cahier des
charges. Les besoins auront été recensés à l’aide des moyens indi-
qués dans le paragraphe 2.2 (1er alinéa) et ils seront exprimés à
l’aide des moyens indiqués aux paragraphes 3.1.1 et 3.1.2.
Seront exposés la mise en marche de l’installation, le fonctionne-
ment en exploitation normale, l’arrêt de l’installation et ses marches
de clôture. Pour que cela soit plus clair, les fonctions pourront être
regroupées en fonction de leur point de vue :
— les fonctions de pilotage (commandes, régulations,
optimisations...) ;
— les fonctions de gestion de production (ordonnancement
temps réel, cadencement, synoptiques, tableaux de bord, journaux
de bord...) ;
— les fonctions d’aide à la maintenance (tendances, alarmes,
aide au diagnostic...) ;
— les fonctions d’aide à la qualité (mesures, échantillonnage,
variations, CPK...) ;
— les fonctions liées à la gestion des données techniques ;
— les fonctions logistiques ;
— les fonctions liées au respect de l’environnement.
Nota : concernant l’indicateur de capabilité CPK, le lecteur pourra se reporter à l’article
[6] desTechniques de l’Ingénieur
Les fonctions seront décrites dans un ordre logique de telle façon
que le lecteur suive facilement ce que le concepteur souhaite. Un
poste d’une ligne pourra être complètement décrit en tenant compte
de tous les points de vue avant de passer à la description du poste
s8095.fm Page 8 Vendredi, 30. novembre 2001 10:49 10
_________________________________________________________________________ CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
©Techniques de l’Ingénieur, traité Informatique industrielle S 8 095 − 9
suivant. Une autre solution peut conduire à décrire tous les postes
d’un point de vue avant de passer à un point de vue suivant.
■ La définition des contraintes
Ce chapitre décrira les contraintes du projet. En fonction des
caractéristiques du projet, les contraintes peuvent être de plusieurs
sortes.
On trouvera en premier lieu les contraintes normatives et régle-
mentaires en faisant référence à des textes, français européens ou
internationaux. Une attention particulière sera apportée notamment
à tout ce qui touche à la sécurité.
Les contraintes d’environnement climatique seront aussi explici-
tées : température, pression, humidité relative, air salin, présence de
moisissure, de rongeurs...
Les contraintes d’exploitation seront également évoquées, pré-
sence de substances chimiques agressives, exposition à des projec-
tions d’eau, à des chocs, à des vibrations.
La détermination du degré de protection souhaité évitera tout
malentendu. Les différentes normes françaises et allemandes repri-
ses dans la norme européenne NF EN 60-529 codifient ces degrés de
protection des enveloppes électriques (coffrets, armoires, boîtiers
de capteurs, moteurs, etc.) à l’aide d’un indice de la forme IP x y z
dans lequel :
— IP signifie Indice de Protection ;
— x détermine le degré de protection contre la pénétration de
corps étrangers variant de 0 (non protégé) à 6 (étanche à la
poussière) ;
— y définit le degré de protection contre la pénétration de l’eau
variant de 0 (non protégé) à 8 (immersion prolongée) ;
— z indique le degré de protection contre les chocs variant de 0
(choc faible : énergie ≈ 0,225 J) à 9 (choc très important : 20 J).
Il peut s’agir également de contraintes spécifiques : solutions qui
sont déjà imposées ou de matériels déjà choisis. Cela peut égale-
ment concerner des procédures à suivre ou des outils à utiliser à
moins que cela ait déjà été spécifié auparavant.
Les contraintes peuvent aussi concerner les procédures à mettre
en place lorsque le projet consiste à réhabiliter une ancienne instal-
lation, maintien de la production, basculement en fin de semaine ou
pendant une période de fermeture de l’usine, etc.
■ La documentation
Ce point est trop souvent négligé. Un dossier de fin de projet en
automatisme devrait toujours être composé des éléments suivants :
— plan qualité ;
— schéma descriptif de la partie opérative ;
— notice de fonctionnement ;
— analyse fonctionnelle ;
— graphe d’études des modes de marche et d’arrêt (GEMMA) ;
— liste des entrées/sorties ;
— chronogrammes des éventuels points critiques ;
— architecture générale du système ;
— implantation géographique des matériels ;
— liste des messages N1 ↔ N1, N1 ↔ N2, N2 ↔ N3 (N : niveau,
cf § 1.4) ;
— liste des messages opérateurs ;
— schéma des alimentations électriques ;
— structure des programmes ;
— supports magnétiques des programmes ;
— cahiers de recette ;
— modèle de simulation des programmes ;
— nomenclature détaillée des composants ;
— mode du repérage adopté ;
— manuel d’exploitation ;
— note de sécurité ;
— manuel de maintenance ;
— liste des pièces de rechange ;
— supports ayant servi à la formation.
Le cahier des charges doit bien préciser les documents attendus,
sinon il y a peu de chances d’obtenir la totalité du dossier.
■ La formation
Pour la plupart des automatismes industriels d’une certaine
importance, il y a lieu de prévoir une formation avant la mise en
service. Le cahier des charges doit indiquer clairement la formation
attendue. Cette formation s’adressera vraisemblablement à
plusieurs catégories d’acteurs.
Une première formation s’adressera à l’encadrement pour lui
donner les informations nécessaires à la maîtrise du changement
des conditions de travail et à la compréhension des problèmes qui
pourront surgir ultérieurement.
Une deuxième formation concernera la formation du personnel
d’exploitation et une troisième s’intéressera aux agents de mainte-
nance. Pour cette dernière session, peut-être sera-t-il judicieux de
prévoir des cours séparés pour les électromécaniciens et pour les
automaticiens / informaticiens.
Le calendrier de ces formations doit être réfléchi : ni trop tôt avant
la mise en service (les acteurs se sentiraient peu concernés et
auraient le temps d’oublier ce qu’ils auraient appris), ni trop tard évi-
demment.
Le lieu des formations n’est pas indifférent non plus. Il est préfé-
rable qu’une première partie soit dispensée en dehors du lieu de tra-
vail afin que le personnel concerné puisse être réellement
disponible. Ceci est d’autant plus vrai lorsqu’il s’agit du personnel
de maintenance toujours très sollicité. La seconde partie de la
formation doit bien sûr s’effectuer sur l’installation elle-même.
■ Les conditions de recette
Il est éminemment souhaitable que le cahier des charges précise
dans quelles conditions seront effectués les tests permettant de
vérifier que la fourniture et ses performances sont bien celles que
l’on attendait.
Les validations doivent se faire le plus tôt possible dans le cycle
de vie du projet, afin de corriger les éventuelles erreurs dès que cela
est possible. A cette fin, un calendrier précis doit être élaboré qui
comprendra les phases principales suivantes :
— essais en plate-forme avec simulateur de partie opérative afin
de pouvoir procéder au plus tôt, avant que celle-ci soit disponible ;
— essais en plate-forme avec la partie opérative quand cela est
possible ;
— essais en plate-forme des communications entre les différen-
tes parties d’automatisme (même si les communications sont de
mieux en mieux maîtrisées, il est rare que l’on arrive au « Plug and
Play » et il est plus facile de procéder aux inévitables mises au point
en plate forme que sur le site final).
— essais sur site de tous les raccordements électriques ;
— essais en fonctionnement réel en autonome (s’il y a lieu) ;
— essais d’ensemble avec tous les prestataires du site (s’il y a
lieu).
Chaque phase possédera son cahier d’essai (ou cahier de recet-
tes) dans lequel chaque essai élémentaire sera décrit par une fiche
dans laquelle seront consignés :
— les conditions de l’essai ;
— les manœuvres à effectuer ;
— les résultats attendus ;
— les résultats effectivement obtenus.
Des cases permettront de noter les éventuelles anomalies consta-
tées et le nom des automaticiens qui auront procédé à ces essais.
Les modalités seront définies. Lorsque tous les tests sont jugés
satisfaisants, la réception est prononcée. Elle peut l’être sans réserve
ou, le plus souvent, avec des réserves mineures. Les réserves majeu-
res sont celles qui correspondent à des anomalies suffisamment
graves pour interdire l’exploitation dans des conditions acceptables
d’opérabilité ou de sécurité. Les réserves mineures sont celles qui
correspondent à des carences bénignes (mais qu’il conviendra néan-
moins de corriger à court terme) comme une absence d’étiquette, une
documentation incomplètement remise à jour, etc.
s8095.fm Page 9 Vendredi, 30. novembre 2001 10:49 10
CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE _________________________________________________________________________
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
S 8 095 − 10 ©Techniques de l’Ingénieur, traité Informatique industrielle
Le cahier des charges précisera si l’on prévoit une réception uni-
que ou en deux temps : réception provisoire et réception définitive.
Dans ce dernier cas, la réception provisoire correspond à un fonc-
tionnement normal de l’installation, et, souvent un an plus tard, la
réception définitive est prononcée lorsque l’on aura constaté que les
performances initiales des équipements étaient conservées de
façon fiable.
Nota : le code des marchés publics ne prévoit plus qu’une réception unique ; le droit
privé permet une réception en deux temps.
L
’on peut également prévoir d’accorder la réception définitive dès
que l’on aura constaté le fonctionnement satisfaisant de l’installa-
tion pendant une période significative, un mois par exemple.
Le cahier des charges précisera également si l’acheteur souhaite
attacher un dernier terme de paiement à la réception définitive, libé-
ration de la retenue de garantie.
■ Le descriptif du marché et les limites de fourniture
Ce chapitre a pour but de récapituler de façon concise tous les
besoins et de bien définir les limites des prestations attendues. C’est
ici que l’on trouvera notamment la définition des interfaces entre
différents automatismes, entre l’automatisme et la partie opérative
ou entre les électriciens et les automaticiens.
A titre d’exemple, les réponses seront données à des question
comme :
— qui raccordera les câbles d’alimentation électrique aux armoi-
res et coffrets ?
— qui fixera et réglera les capteurs sur la machine ou le
convoyeur ?
— qui développera les protocoles de communication entre deux
lots d’automatisme et qui fournira et posera le médium
correspondant ?
■ Les exclusions
Il est souvent utile de consacrer un chapitre explicitant les exclu-
sions même si cela présente des risques de redondance. En effet, il
est facile de décrire, pour le demandeur, les travaux ou prestations
diverses qu’il souhaite exécuter lui-même, comme fourniture de
mobilier support de console, alimentations électriques ou travaux
de génie civil. Cela peut éviter quelques malentendus.
■ La garantie
Ce chapitre doit indiquer ce qui doit être couvert par la garantie,
ses modalités d’application et sa durée.
● Pour les matériels, la garantie couvre généralement la répara-
tion, les nouveaux réglages ou le remplacement de ce qui aura été
jugé défectueux. Le cahier des charges devra préciser si la répara-
tion doit être effectuée sur le site ou dans les ateliers du construc-
teur. Il précisera également la durée d’indisponibilité qu’il juge
acceptable et les conditions éventuelles de mise à disposition provi-
soire d’un matériel de remplacement pendant la durée de la répara-
tion.
● Pour les logiciels, la question est plus complexe. En effet, la
garantie ne peut, de façon réaliste, couvrir que les dysfonctionne-
ments reproductibles et ce dans un délai qui peut difficilement être
garanti.
● Les modalités d’application concernent principalement les
délais d’intervention et de remise en route. Plusieurs paramètres
interviennent dans la fixation de ce délai, l’importance stratégique
de l’équipement concerné, la gravité du dysfonctionnement, le
temps de déplacement du technicien pour rejoindre le site, etc. Pour
certaines installations d’importance vitale, le cahier des charges
peut prévoir la mise en astreinte de dépanneurs, afin de pouvoir
procéder à une remise en marche même pendant les périodes chô-
mées.
● La durée de la garantie est généralement d’un an, bien que,
pour certains matériels informatiques et progiciels, la durée propo-
sée par les fournisseurs varie de 3 à 6 mois. Le début de la garantie
est souvent fixé à la date de la réception provisoire ou au début de
l’exploitation.
■ L’assistance au démarrage
Pour des installations complexes, il est judicieux de mentionner
dans le cahier des charges une prestation d’assistance au démar-
rage. Cette disposition permet de rassurer le personnel d’exploita-
tion qui prend possession de son nouvel outil, de l’aider le cas
échéant, et de répondre aux questions non abordées dans le cadre
de la formation.
Un autre avantage de cet arrangement est qu’il permet au fournis-
seur de maintenir un personnel sur place qui pourra, le cas échéant,
pallier un défaut de jeunesse de l’équipement, couvert bien sûr par
la garantie, sans délai d’intervention.
■ La maintenance
Il est bon d’aborder, dès le cahier des charges de consultation, le
sujet de la maintenance. Quel type de maintenance souhaite-t-on ?
Plusieurs scénarios peuvent être envisagés. L’acquéreur peut dispo-
ser d’un service maintenance suffisamment étoffé pour n’avoir
besoin d’aucune prestation extérieure. À l’inverse, le maître
d’ouvrage peut souhaiter externaliser la totalité des actions de
maintenance qu’elle soit curative ou systématique. La troisième
voie consiste à garder en interne les tâches banales d’entretien ainsi
que les tâches de dépannage de premier degré et de faire appel à
l’extérieur pour tout ce qui nécessite une spécialisation un peu
pointue.
Connaître, dès le début du projet, les services attendus après la
mise en route permettra au fournisseur de prévoir, en temps utile, le
personnel nécessaire en nombre et en compétence.
■ Les pièces de rechange
La politique concernant les pièces de rechange doit également
être traitée, en même temps que la question de la maintenance dont
elle est connexe. De ces deux points dépend directement la disponi-
bilité de l’équipement : il s’agit donc d’un sujet vital.
Là aussi, plusieurs scénarios sont envisageables qui seront choi-
sis en fonction d’un certain nombre de critères :
— nature de la pièce concernée, pièce d’usure ou pièce de
dépannage ;
— importance stratégique ou non de la pièce ;
— coût de la pièce ;
— délai d’approvisionnement (voire délai de fabrication) ;
— possibilité de partage d’un stock de pièces de rechange avec
d’autres utilisateurs ;
— etc.
Aborder le sujet dès le début du projet permettra, par exemple, de
fabriquer certaines pièces de rechange (circuits imprimés, capteurs
spéciaux, etc.) en même temps que les pièces de l’équipement ori-
ginal et donc d’obtenir des prix sensiblement inférieurs à ceux que
l’on aurait dû payer si ces pièces avaient été fabriquées en deux fois.
4.4 Le questionnaire
Le questionnaire, dans les cahiers des charges de consultation,
n’est pas d’un usage fréquent. Il a pourtant une double utilité.
D’abord le questionnaire permet d’obtenir des informations qui
permettront un choix plus motivé du fournisseur. Parmi ces ques-
tions, l’on peut trouver :
— l’état du carnet de commande de l’entreprise (pourra-t-elle
dégager, sans problème, les ressources nécessaires à la bonne con-
duite du projet ?) ;
— le chiffre d’affaires de l’entreprise (une trop grande disparité
entre le chiffre d’affaires et la taille du projet pourrait conduire dans
le cas d’un trop petit projet à un certain manque d’intérêt ou, dans le
cas inverse, à une surcharge génératrice de difficultés ou à une
sous-traitance occulte) ;
— le curriculum vitae du chef de projet pressenti ;
s8095.fm Page 10 Vendredi, 30. novembre 2001 10:49 10
_________________________________________________________________________ CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
©Techniques de l’Ingénieur, traité Informatique industrielle S 8 095 − 11
— les trois derniers bilans de la société (pour s’assurer de la
pérennité de l’entreprise) ;
— les références (projets comparables réussis récemment) ;
— la date de la première version du progiciel et de sa dernière
mise à jour ;
— etc.
Ensuite, une seconde famille de questions peut concerner des
points définis auparavant dans le cahier des charges et pour les-
quels on demande confirmation. Cette disposition peut paraître
amener des redondances, mais elle permet sur des sujets impor-
tants d’éviter tous les risques de malentendus du type « Ah ! je
n’avais pas bien lu ce paragraphe ! »
4.5 Le cadre de réponse
Le cadre de réponse définit le détail suivant lequel le montant
total du projet sera décomposé.
Souvent considéré, par les consultés, comme une contrainte inu-
tile, voire une mesure vexatoire, le cadre de réponse ne présente
pourtant que des avantages pour les deux parties. Bien sûr, le degré
de détail demandé doit rester raisonnable.
Le cadre de réponse permet d’abord d’obtenir une offre structu-
rée qui permettra, lors du dépouillement, de comparer les proposi-
tions de façon équitable.
La décomposition en prix élémentaires par rubriques ou sous-
ensembles peut mettre en évidence des disparités qui resteraient
inaperçues avec le seul montant global. Si des différences de prix
supérieures à 10 ou 20 % apparaissent pour une même rubrique
dans deux offres différentes, il peut s’agir soit d’une supériorité
technologique importante soit le plus souvent, d’une mauvaise
interprétation du cahier des charges. Il peut permettre ainsi d’éviter
d’éventuels oublis.
Le cadre de réponse peut aussi permettre de faire des ajuste-
ments, budgétaires notamment, sans importuner les consultés.
4.6 Le calendrier prévisionnel
Il est trop rare que les contraintes de temps figurent dans les dos-
siers d’appel d’offre. Ces contraintes déterminent pourtant la faisa-
bilité pure et simple du projet pour certaines entreprises consultées.
De toutes les façons, le délai imposé conditionne les moyens à
mobiliser sur le projet et donc directement les coûts.
Le planning indiquera la durée globale du projet mais aussi des
dates clés intermédiaires, points de « rendez-vous » avec d’autres
lots notamment. Ces dates peuvent aussi être déterminées en fonc-
tion des contrôles intermédiaires que l’on souhaite effectuer.
Il est recommandé que le cahier des charges demande le plan-
ning, détaillé cette fois, proposé par le consulté. La qualité du plan-
ning présenté, sa pertinence, sa précision en diront long sur la
compétence du fournisseur potentiel et sur les moyens dont il dis-
pose.
Le calendrier mentionnera également toutes les indications utiles
propres à l’entreprise comme dates de fermeture pour congés
annuels, périodes de pointe, dates de lancement de collection, etc.
4.7 Les conditions commerciales
Un cahier des charges externe se doit de prévoir les conditions
commerciales du contrat potentiel. Seront notamment, précisés les
éléments suivants.
● Les termes de paiement. Un échéancier sera le bienvenu. Quel
événement déclenchera quel pourcentage du montant global ? Il est
sain de prévoir des étapes claires comme : remise de l’analyse fonc-
tionnelle détaillée, fin des essais plate-forme, prononciation de la
réception provisoire, etc. Pour éviter tout malentendu, il est judi-
cieux de préciser quels sont les « livrables » pour chacune de ces
étapes.
● Les conditions de paiement. La différence entre un paiement
par chèque à la remise de la facture ou la remise d’une traite à 90
jours, fin de mois peut justifier une différence de prix significative de
la part du fournisseur.
● Les primes et pénalités. Celles-ci peuvent s’appliquer au niveau
de performance de la fourniture ou au respect des délais annoncés.
La plus grande prudence est à conseiller en ce qui concerne les
pénalités de retard. D’une part, la jurisprudence les limite à un pour-
centage peu significatif, toujours inférieur à 10 % et, d’autre part, il
existe des motivations plus fortes et plus constructives : désir de
satisfaire le client et de le fidéliser, volonté de libérer les ressources
mobilisées pour les engager sur d’autres projets, etc.
4.8 Les clauses juridiques
Ce chapitre définira un certain nombre de points comme :
— le ou les bénéficiaires du brevet qui serait déposé à l’occasion
de ce projet (le client, le fournisseur ou les deux ?) ;
— la protection du client en cas de non respect du droit de la pro-
priété intellectuelle ;
— le droit d’exploiter le logiciel sur plusieurs applications ou sur
plusieurs sites ;
— la gestion des droits d’auteur pour les logiciels ;
— la libre disposition des programmes sources. Font-ils partie de
l’offre originale ?
— la disposition des programmes sources en cas de la disparition
du fournisseur. (Programmes déposés chez un notaire et disponi-
bles seulement en cas de cessation d’activité ?) ;
— les modalités de conciliation en cas de graves litiges (recher-
che d’un médiateur expert indépendant, recours à l’avis d’un syndi-
cat professionnel, etc.) ;
— le tribunal qui serait compétent en cas de contentieux.
Ce chapitre sera rédigé par le service juridique du futur acquéreur
ou avec son aide. Dans le cas d’une petite société, ne disposant pas
de structure juridique, peut-être serait-il judicieux de solliciter le
concours de l’avocat habituel.
5. L
’absence de cahier
des charges
Malheureusement et beaucoup plus fréquemment qu’on pourrait
le penser, des projets se déroulent en l’absence de cahier des char-
ges. Cette démarche, fort peu professionnelle, aboutit à des résul-
tats prévisibles : piètres performances, coûts élevés en fin de
parcours, retards à répétition, conflits internes et externes, impossi-
bilité de recours à une expertise ou à une action en justice, etc.
Le prestataire, confronté à une consultation purement verbale se
retrouve devant trois possibilités :
— accepter de travailler sans cahier des charges, ce qui est sans
aucun doute la pire solution pour les raisons évoquées ci-dessus ;
— décliner l’offre, ce qui est toujours une décision commerciale
difficile à prendre ;
— rédiger une offre en forme de cahier des charges, sans doute la
moins mauvaise solution mais qui demande un travail considérable
le plus souvent non rémunéré et quelquefois non récompensé par
l’obtention de la commande.
s8095.fm Page 11 Vendredi, 30. novembre 2001 10:49 10

Contenu connexe

Tendances

La_Maintenance.ppt
La_Maintenance.pptLa_Maintenance.ppt
La_Maintenance.ppt
LAILAIDRISSI5
 
52 les-niveaux-de-maintenance
52 les-niveaux-de-maintenance52 les-niveaux-de-maintenance
52 les-niveaux-de-maintenance
Benjamin TINAUGUS
 
electronique.ppt
electronique.pptelectronique.ppt
electronique.ppt
AnthonyAbourahal
 
7-AMDEC.ppt
7-AMDEC.ppt7-AMDEC.ppt
7-AMDEC.ppt
TMisSaM
 
CoûT De DéFaillance
CoûT De DéFaillanceCoûT De DéFaillance
CoûT De DéFaillance
youri59490
 
Préparation des actions de maintenance corrective (www.livre-technique.com)
Préparation des actions de maintenance corrective (www.livre-technique.com)Préparation des actions de maintenance corrective (www.livre-technique.com)
Préparation des actions de maintenance corrective (www.livre-technique.com)
Livre Technique
 
les-automates-programmables-industriels
les-automates-programmables-industrielsles-automates-programmables-industriels
les-automates-programmables-industriels
electrolouhla
 
03 - La Fiabilité.pdf
03 - La Fiabilité.pdf03 - La Fiabilité.pdf
03 - La Fiabilité.pdf
AyoubBouelam
 
Exercices triphase
Exercices triphaseExercices triphase
Exercices triphase
MOUHSSINE BEN HAMMOU
 
Approche de la maintenance industrielle
Approche de la maintenance industrielleApproche de la maintenance industrielle
Approche de la maintenance industrielle
Rached Douahchia
 
Compte Rendu D Intervention
Compte Rendu D InterventionCompte Rendu D Intervention
Compte Rendu D Intervention
youri59490
 
Extrudicc TP 120
Extrudicc TP 120Extrudicc TP 120
Extrudicc TP 120
youri59490
 
Exercices corriges en electricite triphase
Exercices corriges en electricite triphaseExercices corriges en electricite triphase
Exercices corriges en electricite triphase
morin moli
 
Extrudicc TP 100
Extrudicc TP 100Extrudicc TP 100
Extrudicc TP 100
youri59490
 
Les outils de diagnostic en maintenance
Les outils de diagnostic en maintenanceLes outils de diagnostic en maintenance
Les outils de diagnostic en maintenance
Fabio Sanders
 
213 les capteurs tor
213 les capteurs tor213 les capteurs tor
213 les capteurs tor
AFAF ELFANIDI
 
Exemple projet amdec
Exemple projet amdecExemple projet amdec
Exemple projet amdec
Sal Ma
 
Introdution a la maintenance industrielle
Introdution a la maintenance industrielleIntrodution a la maintenance industrielle
Introdution a la maintenance industrielle
Younes DADSSI
 
Management des risques 8 : Arbre de défaillances/ d’Evénements; Nœud de Papillon
Management des risques 8 : Arbre de défaillances/ d’Evénements; Nœud de PapillonManagement des risques 8 : Arbre de défaillances/ d’Evénements; Nœud de Papillon
Management des risques 8 : Arbre de défaillances/ d’Evénements; Nœud de Papillon
ibtissam el hassani
 

Tendances (20)

La_Maintenance.ppt
La_Maintenance.pptLa_Maintenance.ppt
La_Maintenance.ppt
 
52 les-niveaux-de-maintenance
52 les-niveaux-de-maintenance52 les-niveaux-de-maintenance
52 les-niveaux-de-maintenance
 
Rapport audit one
Rapport audit oneRapport audit one
Rapport audit one
 
electronique.ppt
electronique.pptelectronique.ppt
electronique.ppt
 
7-AMDEC.ppt
7-AMDEC.ppt7-AMDEC.ppt
7-AMDEC.ppt
 
CoûT De DéFaillance
CoûT De DéFaillanceCoûT De DéFaillance
CoûT De DéFaillance
 
Préparation des actions de maintenance corrective (www.livre-technique.com)
Préparation des actions de maintenance corrective (www.livre-technique.com)Préparation des actions de maintenance corrective (www.livre-technique.com)
Préparation des actions de maintenance corrective (www.livre-technique.com)
 
les-automates-programmables-industriels
les-automates-programmables-industrielsles-automates-programmables-industriels
les-automates-programmables-industriels
 
03 - La Fiabilité.pdf
03 - La Fiabilité.pdf03 - La Fiabilité.pdf
03 - La Fiabilité.pdf
 
Exercices triphase
Exercices triphaseExercices triphase
Exercices triphase
 
Approche de la maintenance industrielle
Approche de la maintenance industrielleApproche de la maintenance industrielle
Approche de la maintenance industrielle
 
Compte Rendu D Intervention
Compte Rendu D InterventionCompte Rendu D Intervention
Compte Rendu D Intervention
 
Extrudicc TP 120
Extrudicc TP 120Extrudicc TP 120
Extrudicc TP 120
 
Exercices corriges en electricite triphase
Exercices corriges en electricite triphaseExercices corriges en electricite triphase
Exercices corriges en electricite triphase
 
Extrudicc TP 100
Extrudicc TP 100Extrudicc TP 100
Extrudicc TP 100
 
Les outils de diagnostic en maintenance
Les outils de diagnostic en maintenanceLes outils de diagnostic en maintenance
Les outils de diagnostic en maintenance
 
213 les capteurs tor
213 les capteurs tor213 les capteurs tor
213 les capteurs tor
 
Exemple projet amdec
Exemple projet amdecExemple projet amdec
Exemple projet amdec
 
Introdution a la maintenance industrielle
Introdution a la maintenance industrielleIntrodution a la maintenance industrielle
Introdution a la maintenance industrielle
 
Management des risques 8 : Arbre de défaillances/ d’Evénements; Nœud de Papillon
Management des risques 8 : Arbre de défaillances/ d’Evénements; Nœud de PapillonManagement des risques 8 : Arbre de défaillances/ d’Evénements; Nœud de Papillon
Management des risques 8 : Arbre de défaillances/ d’Evénements; Nœud de Papillon
 

Similaire à 550714060-Cahier-Des-Charges-Des-Automatismes.pdf

Cycle de vie des logiciels.ppt
Cycle de vie des logiciels.pptCycle de vie des logiciels.ppt
Cycle de vie des logiciels.ppt
hbadir
 
[Important] Cycle de vie des logiciels.ppt
[Important] Cycle de vie des logiciels.ppt[Important] Cycle de vie des logiciels.ppt
[Important] Cycle de vie des logiciels.ppt
testuser715939
 
6-Cours de Géniel Logiciel
6-Cours de Géniel Logiciel6-Cours de Géniel Logiciel
6-Cours de Géniel Logiciel
lauraty3204
 
Namaa.APA.Report
Namaa.APA.ReportNamaa.APA.Report
Namaa.APA.Report
Mohamed HOSNI
 
Ddj Architecture & Design Beyond Functional Requirements On Agile Projects
Ddj   Architecture & Design   Beyond Functional Requirements On Agile ProjectsDdj   Architecture & Design   Beyond Functional Requirements On Agile Projects
Ddj Architecture & Design Beyond Functional Requirements On Agile Projects
Emmanuel Hugonnet
 
Le Contrôle Interne Assisté par Ordinateur
Le Contrôle Interne Assisté par OrdinateurLe Contrôle Interne Assisté par Ordinateur
Le Contrôle Interne Assisté par Ordinateur
mohammed EZZOUAK
 
Présentation événement dette technologique micropole
Présentation événement dette technologique micropolePrésentation événement dette technologique micropole
Présentation événement dette technologique micropole
Micropole Group
 
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
jkebbab
 
Gestions des Asset et des changements appliquées au Datacenter: Du concept à ...
Gestions des Asset et des changements appliquées au Datacenter: Du concept à ...Gestions des Asset et des changements appliquées au Datacenter: Du concept à ...
Gestions des Asset et des changements appliquées au Datacenter: Du concept à ...
itSMF France
 
Competitic guide comment faire : achat IT
Competitic guide comment faire : achat ITCompetitic guide comment faire : achat IT
Competitic guide comment faire : achat IT
COMPETITIC
 
Tirer profit d'un outillage de gestion des exigences
Tirer profit d'un outillage de gestion des exigencesTirer profit d'un outillage de gestion des exigences
Tirer profit d'un outillage de gestion des exigences
EchoesLabs
 
Talk sur la Gestion de projet informatique
Talk sur la Gestion de projet informatiqueTalk sur la Gestion de projet informatique
Talk sur la Gestion de projet informatique
Kader KANE
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
Erradi Mohamed
 
présentation fonction méthodes-maintenance.pdf
présentation fonction méthodes-maintenance.pdfprésentation fonction méthodes-maintenance.pdf
présentation fonction méthodes-maintenance.pdf
CheverlyNgobeghaMoun
 
atam guide de developpement v1.3
atam guide de developpement v1.3atam guide de developpement v1.3
atam guide de developpement v1.3
Abdessamad Hamouch
 
scribd.vpdfs.com_paq-chantier.pdf
scribd.vpdfs.com_paq-chantier.pdfscribd.vpdfs.com_paq-chantier.pdf
scribd.vpdfs.com_paq-chantier.pdf
JaouadIDBOUBKER
 
Chp2 - Cahier des Charges
Chp2 - Cahier des ChargesChp2 - Cahier des Charges
Chp2 - Cahier des Charges
Lilia Sfaxi
 
Outsourcing Telecom
Outsourcing TelecomOutsourcing Telecom
Outsourcing Telecom
sylvain Lamblot
 
Bonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigencesBonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigences
Caroline de Villèle
 

Similaire à 550714060-Cahier-Des-Charges-Des-Automatismes.pdf (20)

Cycle de vie des logiciels.ppt
Cycle de vie des logiciels.pptCycle de vie des logiciels.ppt
Cycle de vie des logiciels.ppt
 
[Important] Cycle de vie des logiciels.ppt
[Important] Cycle de vie des logiciels.ppt[Important] Cycle de vie des logiciels.ppt
[Important] Cycle de vie des logiciels.ppt
 
6-Cours de Géniel Logiciel
6-Cours de Géniel Logiciel6-Cours de Géniel Logiciel
6-Cours de Géniel Logiciel
 
Namaa.APA.Report
Namaa.APA.ReportNamaa.APA.Report
Namaa.APA.Report
 
Ddj Architecture & Design Beyond Functional Requirements On Agile Projects
Ddj   Architecture & Design   Beyond Functional Requirements On Agile ProjectsDdj   Architecture & Design   Beyond Functional Requirements On Agile Projects
Ddj Architecture & Design Beyond Functional Requirements On Agile Projects
 
Le Contrôle Interne Assisté par Ordinateur
Le Contrôle Interne Assisté par OrdinateurLe Contrôle Interne Assisté par Ordinateur
Le Contrôle Interne Assisté par Ordinateur
 
Présentation événement dette technologique micropole
Présentation événement dette technologique micropolePrésentation événement dette technologique micropole
Présentation événement dette technologique micropole
 
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
Cours Jean-Louis BOULANGER: Réalisation d'une application logicielle.
 
Gestions des Asset et des changements appliquées au Datacenter: Du concept à ...
Gestions des Asset et des changements appliquées au Datacenter: Du concept à ...Gestions des Asset et des changements appliquées au Datacenter: Du concept à ...
Gestions des Asset et des changements appliquées au Datacenter: Du concept à ...
 
Td2 pg2-corrige
Td2 pg2-corrigeTd2 pg2-corrige
Td2 pg2-corrige
 
Competitic guide comment faire : achat IT
Competitic guide comment faire : achat ITCompetitic guide comment faire : achat IT
Competitic guide comment faire : achat IT
 
Tirer profit d'un outillage de gestion des exigences
Tirer profit d'un outillage de gestion des exigencesTirer profit d'un outillage de gestion des exigences
Tirer profit d'un outillage de gestion des exigences
 
Talk sur la Gestion de projet informatique
Talk sur la Gestion de projet informatiqueTalk sur la Gestion de projet informatique
Talk sur la Gestion de projet informatique
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
présentation fonction méthodes-maintenance.pdf
présentation fonction méthodes-maintenance.pdfprésentation fonction méthodes-maintenance.pdf
présentation fonction méthodes-maintenance.pdf
 
atam guide de developpement v1.3
atam guide de developpement v1.3atam guide de developpement v1.3
atam guide de developpement v1.3
 
scribd.vpdfs.com_paq-chantier.pdf
scribd.vpdfs.com_paq-chantier.pdfscribd.vpdfs.com_paq-chantier.pdf
scribd.vpdfs.com_paq-chantier.pdf
 
Chp2 - Cahier des Charges
Chp2 - Cahier des ChargesChp2 - Cahier des Charges
Chp2 - Cahier des Charges
 
Outsourcing Telecom
Outsourcing TelecomOutsourcing Telecom
Outsourcing Telecom
 
Bonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigencesBonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigences
 

Plus de SAID MASHATE

Referentiels----Emploies----Competences.pptx
Referentiels----Emploies----Competences.pptxReferentiels----Emploies----Competences.pptx
Referentiels----Emploies----Competences.pptx
SAID MASHATE
 
pdfcoffee.com_lt-cable-sizing-pdf-free.pdf
pdfcoffee.com_lt-cable-sizing-pdf-free.pdfpdfcoffee.com_lt-cable-sizing-pdf-free.pdf
pdfcoffee.com_lt-cable-sizing-pdf-free.pdf
SAID MASHATE
 
666148532-Formation-Habilitation-ELECTRIQUE-ENTREPRISE-MARS-2017.pptx
666148532-Formation-Habilitation-ELECTRIQUE-ENTREPRISE-MARS-2017.pptx666148532-Formation-Habilitation-ELECTRIQUE-ENTREPRISE-MARS-2017.pptx
666148532-Formation-Habilitation-ELECTRIQUE-ENTREPRISE-MARS-2017.pptx
SAID MASHATE
 
*----------------ITALY--------------.pptx
*----------------ITALY--------------.pptx*----------------ITALY--------------.pptx
*----------------ITALY--------------.pptx
SAID MASHATE
 
diapo_______code_______lourd_______.pptx
diapo_______code_______lourd_______.pptxdiapo_______code_______lourd_______.pptx
diapo_______code_______lourd_______.pptx
SAID MASHATE
 
DÉPLOIEMENT----DE LA NORME ISO 26262.pdf
DÉPLOIEMENT----DE LA NORME ISO 26262.pdfDÉPLOIEMENT----DE LA NORME ISO 26262.pdf
DÉPLOIEMENT----DE LA NORME ISO 26262.pdf
SAID MASHATE
 
ITALY--GEOGRaphy---tourisme------- .pptx
ITALY--GEOGRaphy---tourisme------- .pptxITALY--GEOGRaphy---tourisme------- .pptx
ITALY--GEOGRaphy---tourisme------- .pptx
SAID MASHATE
 
704831031-Le-Syst-de-Transp-Intelligent.pptx
704831031-Le-Syst-de-Transp-Intelligent.pptx704831031-Le-Syst-de-Transp-Intelligent.pptx
704831031-Le-Syst-de-Transp-Intelligent.pptx
SAID MASHATE
 
479561443-Presentation-maintenance-poste-V1-ppt.ppt
479561443-Presentation-maintenance-poste-V1-ppt.ppt479561443-Presentation-maintenance-poste-V1-ppt.ppt
479561443-Presentation-maintenance-poste-V1-ppt.ppt
SAID MASHATE
 
GEO__DATA__ DAYS__2021_1__Spatial_Drouet
GEO__DATA__ DAYS__2021_1__Spatial_DrouetGEO__DATA__ DAYS__2021_1__Spatial_Drouet
GEO__DATA__ DAYS__2021_1__Spatial_Drouet
SAID MASHATE
 
Elaboration_d’un_cahier_des_charges_modèle_pour_la_réalisation_d’un_projet_de...
Elaboration_d’un_cahier_des_charges_modèle_pour_la_réalisation_d’un_projet_de...Elaboration_d’un_cahier_des_charges_modèle_pour_la_réalisation_d’un_projet_de...
Elaboration_d’un_cahier_des_charges_modèle_pour_la_réalisation_d’un_projet_de...
SAID MASHATE
 
Cours-Electricité Industrielle.pdf
Cours-Electricité Industrielle.pdfCours-Electricité Industrielle.pdf
Cours-Electricité Industrielle.pdf
SAID MASHATE
 
Calcul-Eclairage-Publique-pdf.pdf
Calcul-Eclairage-Publique-pdf.pdfCalcul-Eclairage-Publique-pdf.pdf
Calcul-Eclairage-Publique-pdf.pdf
SAID MASHATE
 
fdocuments.net_moteurs-de-recherche-en-sciences-technique-5585e2cd4bbb7.pptx
fdocuments.net_moteurs-de-recherche-en-sciences-technique-5585e2cd4bbb7.pptxfdocuments.net_moteurs-de-recherche-en-sciences-technique-5585e2cd4bbb7.pptx
fdocuments.net_moteurs-de-recherche-en-sciences-technique-5585e2cd4bbb7.pptx
SAID MASHATE
 
dokumen.tips_transmission-towers-description.pdf
dokumen.tips_transmission-towers-description.pdfdokumen.tips_transmission-towers-description.pdf
dokumen.tips_transmission-towers-description.pdf
SAID MASHATE
 
Sense of Place - National Grid Guidance.pdf
Sense of Place - National Grid Guidance.pdfSense of Place - National Grid Guidance.pdf
Sense of Place - National Grid Guidance.pdf
SAID MASHATE
 
CABLES section amont aval transfo HTABThtKP077.pdf
CABLES section amont aval transfo HTABThtKP077.pdfCABLES section amont aval transfo HTABThtKP077.pdf
CABLES section amont aval transfo HTABThtKP077.pdf
SAID MASHATE
 
Fiche Norme 13201.pdf
Fiche Norme 13201.pdfFiche Norme 13201.pdf
Fiche Norme 13201.pdf
SAID MASHATE
 
Economie_denergie_dans_leclairage_public.pdf
Economie_denergie_dans_leclairage_public.pdfEconomie_denergie_dans_leclairage_public.pdf
Economie_denergie_dans_leclairage_public.pdf
SAID MASHATE
 
CMQ P. Béton.pdf
CMQ P. Béton.pdfCMQ P. Béton.pdf
CMQ P. Béton.pdf
SAID MASHATE
 

Plus de SAID MASHATE (20)

Referentiels----Emploies----Competences.pptx
Referentiels----Emploies----Competences.pptxReferentiels----Emploies----Competences.pptx
Referentiels----Emploies----Competences.pptx
 
pdfcoffee.com_lt-cable-sizing-pdf-free.pdf
pdfcoffee.com_lt-cable-sizing-pdf-free.pdfpdfcoffee.com_lt-cable-sizing-pdf-free.pdf
pdfcoffee.com_lt-cable-sizing-pdf-free.pdf
 
666148532-Formation-Habilitation-ELECTRIQUE-ENTREPRISE-MARS-2017.pptx
666148532-Formation-Habilitation-ELECTRIQUE-ENTREPRISE-MARS-2017.pptx666148532-Formation-Habilitation-ELECTRIQUE-ENTREPRISE-MARS-2017.pptx
666148532-Formation-Habilitation-ELECTRIQUE-ENTREPRISE-MARS-2017.pptx
 
*----------------ITALY--------------.pptx
*----------------ITALY--------------.pptx*----------------ITALY--------------.pptx
*----------------ITALY--------------.pptx
 
diapo_______code_______lourd_______.pptx
diapo_______code_______lourd_______.pptxdiapo_______code_______lourd_______.pptx
diapo_______code_______lourd_______.pptx
 
DÉPLOIEMENT----DE LA NORME ISO 26262.pdf
DÉPLOIEMENT----DE LA NORME ISO 26262.pdfDÉPLOIEMENT----DE LA NORME ISO 26262.pdf
DÉPLOIEMENT----DE LA NORME ISO 26262.pdf
 
ITALY--GEOGRaphy---tourisme------- .pptx
ITALY--GEOGRaphy---tourisme------- .pptxITALY--GEOGRaphy---tourisme------- .pptx
ITALY--GEOGRaphy---tourisme------- .pptx
 
704831031-Le-Syst-de-Transp-Intelligent.pptx
704831031-Le-Syst-de-Transp-Intelligent.pptx704831031-Le-Syst-de-Transp-Intelligent.pptx
704831031-Le-Syst-de-Transp-Intelligent.pptx
 
479561443-Presentation-maintenance-poste-V1-ppt.ppt
479561443-Presentation-maintenance-poste-V1-ppt.ppt479561443-Presentation-maintenance-poste-V1-ppt.ppt
479561443-Presentation-maintenance-poste-V1-ppt.ppt
 
GEO__DATA__ DAYS__2021_1__Spatial_Drouet
GEO__DATA__ DAYS__2021_1__Spatial_DrouetGEO__DATA__ DAYS__2021_1__Spatial_Drouet
GEO__DATA__ DAYS__2021_1__Spatial_Drouet
 
Elaboration_d’un_cahier_des_charges_modèle_pour_la_réalisation_d’un_projet_de...
Elaboration_d’un_cahier_des_charges_modèle_pour_la_réalisation_d’un_projet_de...Elaboration_d’un_cahier_des_charges_modèle_pour_la_réalisation_d’un_projet_de...
Elaboration_d’un_cahier_des_charges_modèle_pour_la_réalisation_d’un_projet_de...
 
Cours-Electricité Industrielle.pdf
Cours-Electricité Industrielle.pdfCours-Electricité Industrielle.pdf
Cours-Electricité Industrielle.pdf
 
Calcul-Eclairage-Publique-pdf.pdf
Calcul-Eclairage-Publique-pdf.pdfCalcul-Eclairage-Publique-pdf.pdf
Calcul-Eclairage-Publique-pdf.pdf
 
fdocuments.net_moteurs-de-recherche-en-sciences-technique-5585e2cd4bbb7.pptx
fdocuments.net_moteurs-de-recherche-en-sciences-technique-5585e2cd4bbb7.pptxfdocuments.net_moteurs-de-recherche-en-sciences-technique-5585e2cd4bbb7.pptx
fdocuments.net_moteurs-de-recherche-en-sciences-technique-5585e2cd4bbb7.pptx
 
dokumen.tips_transmission-towers-description.pdf
dokumen.tips_transmission-towers-description.pdfdokumen.tips_transmission-towers-description.pdf
dokumen.tips_transmission-towers-description.pdf
 
Sense of Place - National Grid Guidance.pdf
Sense of Place - National Grid Guidance.pdfSense of Place - National Grid Guidance.pdf
Sense of Place - National Grid Guidance.pdf
 
CABLES section amont aval transfo HTABThtKP077.pdf
CABLES section amont aval transfo HTABThtKP077.pdfCABLES section amont aval transfo HTABThtKP077.pdf
CABLES section amont aval transfo HTABThtKP077.pdf
 
Fiche Norme 13201.pdf
Fiche Norme 13201.pdfFiche Norme 13201.pdf
Fiche Norme 13201.pdf
 
Economie_denergie_dans_leclairage_public.pdf
Economie_denergie_dans_leclairage_public.pdfEconomie_denergie_dans_leclairage_public.pdf
Economie_denergie_dans_leclairage_public.pdf
 
CMQ P. Béton.pdf
CMQ P. Béton.pdfCMQ P. Béton.pdf
CMQ P. Béton.pdf
 

550714060-Cahier-Des-Charges-Des-Automatismes.pdf

  • 1. Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. ©Techniques de l’Ingénieur, traité Informatique industrielle S 8 095 − 1 S 8 095 12 - 2001 Cahier des charges des automatismes. Analyse fonctionnelle par Michel ROUX Consultant en ingénierie productique a conception des systèmes automatisés de production est basée sur une expression des besoins formalisés dans un cahier des charges fonctionnel. Le cahier des charges constitue non seulement un outil de travail mais il est aussi la base contractuelle entre le client et son fournisseur. La sophistication croissante des systèmes automatiques entraîne une difficulté accrue dans l’élaboration des cahiers des charges correspondants. C’est pour tenter de résoudre cette difficulté que de nombreuses réflexions ont été menées, des méthodes imaginées et des outils créés. De nombreuses études conduites dans plusieurs pays et notamment aux États- Unis ont mis en évidence que de nombreux cahiers des charges étaient incomplets, ambigus voire incohérents et que là se trouvait la raison de l’échec de nombreux projets (performances non atteintes, délais dépassés, budgets explosés). Après quelques définitions et réflexions sur les particularités des automa- tismes par rapport à d’autres biens industriels, seront exposées des méthodes de recensement puis de formalisation des besoins, ensuite un sommaire géné- rique de cahier des charges sera proposé. 1. Définitions et rappels concernant les automatismes................... S 8 095 – 2 1.1 Définition du cahier des charges................................................................ — 2 1.2 Cahier des charges et qualité...................................................................... — 2 1.3 Particularités de l’automatisme.................................................................. — 2 1.4 Architecture CIM .......................................................................................... — 3 1.5 L’automatisme comme un lot séparé......................................................... — 3 2. Présentation des cahiers des charges................................................ — 4 2.1 Les différents cahiers des charges ............................................................. — 4 2.2 Les difficultés du cahier des charges ......................................................... — 5 3. Recensement et formalisation des besoins...................................... — 5 3.1 Outils de recensement des besoins ........................................................... — 5 3.2 Outils descriptifs.......................................................................................... — 6 4. Proposition d’un sommaire de cahier des charges ........................ — 7 4.1 La réquisition ............................................................................................... — 8 4.2 Les spécifications générales....................................................................... — 8 4.3 Les spécifications particulières................................................................... — 8 4.4 Le questionnaire .......................................................................................... — 10 4.5 Le cadre de réponse .................................................................................... — 11 4.6 Le calendrier prévisionnel........................................................................... — 11 4.7 Les conditions commerciales ..................................................................... — 11 4.8 Les clauses juridiques ................................................................................. — 11 5. L ’absence de cahier des charges.......................................................... — 11 Pour en savoir plus .......................................................................................... Doc. S 8 095 L s8095.fm Page 1 Vendredi, 30. novembre 2001 10:49 10
  • 2. CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE _________________________________________________________________________ Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. S 8 095 − 2 ©Techniques de l’Ingénieur, traité Informatique industrielle 1. Définitions et rappels concernant les automatismes 1.1 Définition du cahier des charges Le cahier des charges est quelquefois défini comme étant un acte qui indique les conditions d’un marché, ce marché étant en cours d’appel d’offre ou déjà conclu. Une définition, plus industrielle, pourrait être la description précise et exhaustive de ce qu’un « client » attend d’un « fournisseur ». Les guillemets indiquent que les termes de « client » et « fournisseur » doivent être pris dans leur acception la plus large. Par exemple, les deux acteurs peuvent faire partie d’une même société, voire d’un même service. Le Gimélec (Groupement des industries de matériel d’équipe- ment électrique et de l’électronique industrielle associée) fait sienne la définition que donne l’Afnor du cahier des charges : Un cahier des charges d’automatisme doit décrire non seulement la fourniture attendue, matériel, logiciel et, éventuellement, installa- tion, mais aussi les services les accompagnant (formation, garantie, hot-line, etc.) et les modalités d’exécution commerciales et juridi- ques. 1.2 Cahier des charges et qualité La qualité est définie comme étant « l’ensemble des propriétés et caractéristiques d’un produit ou service qui lui confère l’aptitude à satisfaire des besoins exprimés ou implicites ». Or, qu’est-ce qu’un cahier des charges sinon l’expression des besoins ? Il apparaît donc une très forte corrélation entre cahier des charges et qualité. Plus complètement et plus clairement les besoins seront expri- més, plus les chances seront grandes d’obtenir une prestation de qualité. Un « bon » cahier des charges est une condition indispen- sable, même si elle n’est pas suffisante, à la réussite d’un projet, notamment d’automatisme. Une étude américaine de 1995 portant sur l’analyse de 8 380 projets a démontré que la moitié des échecs de projets d’automatisme étaient dus à la mauvaise qualité du cahier des charges (manque d’informations du client, spécifications incomplètes, demandes répétées de modifications, demandes uto- piques, rédaction ambiguë). A titre d’information, l’autre moitié des échecs était due à une mauvaise planification et un manque de moyens ou de compétence. Aucun échec dû à des raisons techni- ques n’a été recensé. Notons, au passage, que « l’implicite » de la définition de la qua- lité constitue une des difficultés de l’établissement d’un cahier des charges. 1.3 Particularités de l’automatisme Les automatismes sont aujourd’hui en grande partie constitués par des logiciels et ceux-ci présentent de fortes originalités par rap- port à d’autres biens industriels que ce soit du point de vue de l’évo- lutivité, de la fiabilité ou de la maintenance. Les cahiers des charges devront en tenir compte. ■ Évolutivité Un point original des automatismes programmés est la relative facilité avec laquelle il est possible de modifier quelques lignes de programme pour faire évoluer les fonctions offertes. Cette médaille trouve fréquemment son envers. La facilité entraîne souvent un cer- tain manque de rigueur et la multiplication de nouvelles exigences souvent mal formalisées et dont la justification n’est pas toujours évidente. Dans les technologies précédentes, relais ou modules électroni- ques, un prescripteur hésitait longuement avant de demander le décâblage puis le recâblage de tout ou partie d’une armoire de relayage. Aujourd’hui, devant un logiciel, il hésite beaucoup moins. ■ Fiabilité Une autre des grandes particularités des automatismes réside dans les courbes de fiabilité. La fiabilité d’un équipement mécani- que ou électromécanique (moteur, contacteur, relais...) est représen- tée par la courbe bien connue dite « en baignoire » (figure 1) alors que les logiciels ont une courbe de fiabilité décroissante jusqu’à l’asymptote à zéro (figure 2). Les logiciels ne connaissent pas les défauts de vieillesse. Cette particularité a une répercussion immédiate sur les condi- tions de garantie par exemple et sur les conditions de maintenance. Glossaire Partie opérative Ensemble des moyens matériels opérant physiquement sur les matières d’œuvre ou les utilités en vue d’assurer la produc- tion. Partie commande Ensemble des moyens de traitement de l’information permet- tant la commande et le pilotage d’une ou plusieurs partie(s) opérative(s). Avant-projet sommaire (APS) Appelée aussi quelquefois Étude de faisabilité ou Étude préa- lable, cette phase d’un projet doit voir les tâches suivantes : — recensement des solutions plausibles ; — examen des deux ou trois solutions les plus séduisantes ; — comparaison ; — préconisation de la meilleure solution ou compromis entre plusieurs parties de solutions. Avant-projet détaillé (APD) Cette phase du projet fait suite à la précédente et permet d’étudier à fond la solution retenue en fin d’APS. Hot line Permanence téléphonique qui permet au fournisseur de résoudre, à distance, un certain nombre de problèmes. « Document établi par le demandeur définissant les clauses techniques, les clauses de qualité et les clauses administratives applicables à la fourniture recherchée ; il sert de base à la propo- sition du fournisseur et pourra faire l’objet d’un contrat ». Figure 1 – Fiabilité d’un équipement mécanique ou électromécanique Période d'exploitation normale Défauts de jeunesse Défauts de vieillesse Âge Taux de défaillance s8095.fm Page 2 Vendredi, 30. novembre 2001 10:49 10
  • 3. _________________________________________________________________________ CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. ©Techniques de l’Ingénieur, traité Informatique industrielle S 8 095 − 3 Il est à noter que le taux de défaillance d’un équipement électro- mécanique dépend non seulement de la qualité intrinsèque de l’équipement, de la responsabilité du constructeur mais aussi des conditions d’utilisation qui sont de la responsabilité de l’utilisateur. Ainsi un relais dont les contacts sont calibrés pour 10 A aura un taux de défaillance moindre (et une durée de vie plus longue) s’il est uti- lisé pour établir des courants de 5 A que s’il est utilisé pour des cou- rants de 10 A et quelquefois un peu plus. Rien de tel avec les logiciels, bien sûr. ■ Maintenance Pour un équipement industriel classique, la maintenance consiste à maintenir les caractéristiques et les performances originelles de cet équipement. Lorsqu’il s’agit d’un logiciel, le terme « maintenance » prend un tout autre sens. Il s’agit d’implanter les nouvelles versions du sys- tème d’exploitation, d’intégrer de nouvelles fonctions ou de perfec- tionner des fonctions déjà existantes. Il ne s’agit plus de « main- tenir » au sens étymologique du terme mais bien d’« améliorer » les performances initiales. De nombreuses études ont constaté que le coût d’acquisition d’un logiciel ne représentait guère plus de 50 % du coût global de possession. ■ Phasage d’un projet d’automatisme Tous les projets, pour être correctement conduits, et donc plani- fiés, doivent être décomposés en tâches et en sous-tâches. Pour les raisons évoquées ci-dessus, notamment l’évolutivité et le laxisme qui risque d’en découler, cette obligation est d’autant plus pressante lorsqu’il s’agit de projets d’automatisme. Plus encore, il semble judicieux de ne s’engager que pour une étape bien définie : analyse fonctionnelle de l’avant-projet som- maire, analyse fonctionnelle de l’avant-projet détaillé, puis analyse organique et développement. Ceci va dans l’intérêt des deux par- ties, le client comme le prestataire. En effet les risques de dérive sont nombreux, apparition de nouvelles fonctionnalités, besoins accrus d’optimisation, etc., pour les mêmes raisons que celles évo- quées plus haut. Il devient alors difficile de maintenir les clauses contractuelles initiales et alors, soit le prestataire doit faire face à un surcroît de travail non rémunéré, soit l’acquéreur reçoit de multiples avenants qui l’indisposent. Dans les deux cas, la situation devient vite tendue. Mieux vaut procéder par étapes plus courtes et donc mieux maîtrisées de part et d’autre. ■ Cas des progiciels La jurisprudence montre que l’acquéreur d’un logiciel spécifique qui n’a pas pris la peine d’exprimer correctement ses besoins et qui est mécontent de la prestation de son fournisseur est le plus sou- vent débouté. Le cahier des charges est donc « jurispruden- tiellement » parlant incontournable. Le cas des progiciels est sensiblement différent. Par définition, un progiciel (produit logiciel) est disponible, entièrement terminé, avant même que l’on envisage son acquisition. La jurisprudence estime donc que l’acheteur peut évaluer le progiciel avant l’acte d’achat. Elle en déduit que l’acheteur n’est pas tenu de rédiger un cahier des charges. Il connaît ses besoins et peut juger si le produit répond à ses besoins. Cette position est un peu formelle, car s’il est techniquement possible d’évaluer un traitement de texte en quel- ques heures, il en va tout autrement d’un progiciel d’ordonnance- ment temps réel ou d’un superviseur disposant de multiples fonctionnalités. Le seul recours possible, en cas de déconvenue, réside alors dans les « vices cachés ». A tout prendre, il vaut mieux travailler avec un bon cahier des charges. 1.4 Architecture CIM Est-il besoin de rappeler ce qu’est l’architecture CIM (Computer Integrated Manufacturing) ? Ce concept a vu le jour au courant des années 1980. Il permet de structurer les automatismes du point de vue fonctionnel. Ainsi, nous pouvons distinguer les niveaux sui- vants (tableau 1) : — le niveau 0 concerne les capteurs, les actionneurs et les pré- actionneurs, les automatismes « réflexes » de sécurité primaires ; — le niveau 1 s’intéresse de façon modulaire à l’automatisation d’une machine ou d’un poste de travail ; — le niveau 2 fédère les automatismes de niveau 1 d’un ensem- ble cohérent, ligne de production ou partie de ligne. Il s’appelle sou- vent supervision. Il peut inclure une partie de l’ordonnancement très court terme ou cadencement, appelé aussi MES (Manufacturing Execution System). Dans le cadre de la gestion des fonctions d’un entrepôt, les automatismes de niveau 2 sont souvent appelés WMS (Warehouse Management System) ; — le niveau 3 traite des fonctions de gestion de production et de gestion commerciale ; il ne fait plus partie de l’automatisation pro- prement dite ; — les niveaux supérieurs gèrent la finance de l’entreprise, le per- sonnel, etc. Ce concept a été très en vogue à son apparition, puis a été décrié par une presse technique peu au fait des réalités industrielles. Il est maintenant mature ; on en parle moins mais on le réussit mieux. Cette architecture fonctionnelle est un outil méthodologique très utile pour bien structurer un ensemble d’automatisme. Il est recom- mandé de l’utiliser dès le début de la phase de conception et d’éla- boration des spécifications. (0) 1.5 L ’automatisme comme un lot séparé Une question fondamentale se pose dès que la conception d’un système complet est terminée. Doit-on confier la réalisation des automatismes au constructeur de la partie opérative ou faire appel à un automaticien spécialiste ? Et donc, doit-on rédiger un ou deux cahiers des charges ? Figure 2 – Fiabilité d’un logiciel Défauts de jeunesse Modification Période d'exploitation normale Taux de défaillance Âge Tableau 1 – Pyramide du CIM Niveau Fonction Matériel Temps de réponse 3 et au-dessus Gestion de production et autres Ordinateurs plus puissants Temps différé Traitement batch 2 Supervision d’une ligne Petits ordinateurs De l’ordre de 20 s 1 Commande d’une machine Automate programmable De l’ordre de 300 ms 0 Entrées Sorties Capteurs Actionneurs De l’ordre de 30 ms s8095.fm Page 3 Vendredi, 30. novembre 2001 10:49 10
  • 4. CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE _________________________________________________________________________ Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. S 8 095 − 4 ©Techniques de l’Ingénieur, traité Informatique industrielle La réponse aux question suivantes permet d’effectuer un choix pertinent : Traiter les automatismes comme un lot séparé permet de choisir la meilleure offre de mécanique et, à côté, la meilleure offre d’auto- matisme ; en revanche, cela oblige le maître d’ouvrage, ou son maî- tre d’œuvre délégué, à coordonner les deux lots, ce qui n’est pas toujours une tâche facile. La question ne doit pas se poser pour des fonctions d’automa- tisme que le constructeur mécanicien a déjà réalisées de multiples fois. Il serait dommage de se priver de son expertise acquise au fil du temps. Les cahiers des charges seront fondamentalement différents sui- vant la décision prise. 2. Présentation des cahiers des charges 2.1 Les différents cahiers des charges Pour bien comprendre la problématique du cahier des charges, il paraît important de recenser les différents types auxquels ils appar- tiennent. Ainsi, les dichotomies suivantes peuvent être envisagées en fonction de leurs destinataires ou de leur place dans le calendrier général du projet. ■ Cahier des charges de projet ou de produit Le propre d’un projet est d’être unique et réalisé pour le compte d’un client alors que la caractéristique principale d’un produit est d’être destiné à de très nombreux clients qui ne sont pas connus lors de la conception dudit produit. Un cahier des charges de projet, l’automatisation d’un atelier par exemple, est généralement fait par le client lui-même ou son maître d’œuvre qui sont l’un et l’autre parfaitement au fait des besoins à satisfaire. De plus, le cahier des charges peut être amendé ultérieu- rement, lors de la réalisation, par des accords intervenant entre le client et son fournisseur. Dans le cas des produits, automatisation d’une voiture ou d’une machine outil par exemple, la problématique est toute autre ; le rédacteur du cahier des charges doit travailler pratiquement seul sur des besoins qui ne le concernent sans doute pas en tant qu’utilisa- teur. C’est là que les outils de recensement des besoins décrits plus loin rendent les plus grands services. ■ Cahier des charges interne ou externe Un cahier des charges peut être établi pour définir ce que l’on attend d’un prestataire extérieur à la société à laquelle on appartient ou de ce que l’on attend d’un service interne, service automatisme ou service informatique. Dans le premier cas, le document sera plus formel et comprendra toute une série de rubriques concernant les conditions de paiement, les pénalités en cas de retard, les tribunaux compétents en cas de litige, etc. Ces rubriques sont bien sûr inutiles lorsque tous les acteurs se trouvent à l’intérieur d’une même société. En revanche, le cœur du cahier des charges, c’est-à-dire la partie expression des besoins, l’analyse fonctionnelle, devrait être rigou- reusement la même dans les deux cas. ■ Cahier des charges de consultation ou de commande Le cahier des charges d’un projet vit deux phases bien distinctes. Dans un premier temps, il va permettre de faire appel à la concur- rence dans une procédure d’appel d’offres. Dans un second temps, il doit formaliser, en termes contractuels, les accords entre le client et le fournisseur retenu. En simplifiant les choses à l’extrême, un cahier des charges de consultation ne devrait parler que de besoins alors qu’un cahier des charges de commande (une fois le fournisseur choisi entre tous ceux qui ont été consultés) ne devrait s’exprimer qu’en termes de solutions et de moyens. Par exemple, un industriel souhaite acquérir l’automatisme d’une machine. Lors de la consultation, il décrira les fonctions et les per- formances attendues. Ensuite, parmi les différentes offres qu’il aura reçues, l’une d’elles lui paraîtra plus séduisante que les autres, car l’automaticien aura proposé des automates de tel constructeur, une architecture bien adaptée, un chef de projet expérimenté pour con- duire le projet, etc. Alors que le cahier des charges de consultation était ouvert, lais- sant le champ libre au consulté pour exprimer toute sa créativité, tout son savoir-faire personnel, le cahier des charges de commande va se « verrouiller » en reprenant tous les points de l’offre qui l’ont fait choisir. En pratique, il est rare qu’un client puisse laisser une entière liberté aux consultés pour choisir eux-mêmes tous les moyens nécessaires à la satisfaction de son besoin. Toutefois, il est recom- mandé de laisser la plus grande marge de manœuvre raisonnable- ment admissible. ■ Appel à la créativité ou commande à façonnier La position exposée dans le paragraphe précédent n’est pas tou- jours la meilleure. Certaines sociétés multinationales préfèrent mener des études très approfondies en interne avant toute consul- tation et lancer un appel d’offres qui n’est exprimé non plus en termes de besoins mais en termes de moyens et de solutions parfai- tement définis. C’est ce que l’on appelle faire appel à des « façonniers ». On ne sollicite plus alors, leur créativité mais leur seule compétence en réalisation. Cette démarche permet d’obtenir des équipements rigoureuse- ment identiques dans toutes les usines du groupe dans le monde entier. Les performances sont analogues et toutes sont au niveau de la conception initiale. Le personnel peut aisément aller d’usine en usine sans jamais se trouver dépaysé devant des équipements inconnus. Le stock de pièces de rechange peut être sensiblement réduit. L’intégration d’une nouvelle version d’un module logiciel peut être réalisée simultanément ou presque sur tous les sites. De plus, notons au passage, même si cela est subsidiaire, qu’il devient beaucoup plus facile de comparer les offres. ■ Appel à variante Un compromis existe entre les cahiers des charges « ouverts » et les cahiers des charges « verrouillés » ; c’est l’appel à variante. Dans ce cas, le cahier des charges décrit avec précision la solution souhai- tée. L’offre devra répondre au scénario décrit. Mais la liberté est lais- sée au consulté de répondre, à côté, suivant une solution personnelle qu’il pense être plus performante ou plus compétitive. ■ Vue externe ou vue interne La description d’un automatisme peut être donnée par une « vue externe » ou une « vue interne ». L’approche « vue externe » consi- ● La part de l’automatisme est-elle importante et/ou complexe ? ● Les fonctionnalités requises sont-elles spécifiques ou sont- elles standards pour le constructeur mécanicien ? ● Le constructeur mécanicien dispose-t-il d’un service « automatismes » adapté à la taille du problème, en effectifs et en compétence ? ● L ’automatisme doit-il fédérer plusieurs parties opératives de constructeurs différents ? s8095.fm Page 4 Vendredi, 30. novembre 2001 10:49 10
  • 5. _________________________________________________________________________ CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. ©Techniques de l’Ingénieur, traité Informatique industrielle S 8 095 − 5 dère l’automatisme comme une « boîte noire » et n’est alors défini que ce que l’on attend de cette entité : quelles fonctions ? à partir de quelles entrées ? pour animer quelles sorties ? A l’inverse, l’approche « vue interne » décrit l’intérieur de la boîte : architecture, organisation des mémoires, éventuellement algorithmique, etc. Sauf dans le cas de commande à façonnier, il est nettement préfé- rable de pratiquer la vue externe. ■ Les cahiers des charges successifs Les cahiers des charges font souvent partie intégrante d’un projet complet. Ce projet connaîtra une toute première étape : le plan directeur. Se succéderont ensuite l’avant-projet sommaire, puis l’avant-projet détaillé, la consultation des entreprises et enfin arri- vera la phase de réalisation. Il est évident que les cahiers des charges se préciseront à chacune des étapes. Au fil du temps, les problèmes feront place à des axes de solution et l’on passera du qualitatif au quantitatif. Par exemple, du « temps réel », notion un peu vague, l’on s’acheminera vers un nombre précis de millisecondes, etc. (figure 3). 2.2 Les difficultés du cahier des charges Recenser les difficultés souvent rencontrées devrait permettre de mieux les surmonter. Celles auxquelles on se heurte le plus fré- quemment sont les suivantes. ■ Accélération du cycle de vie Si, depuis bien longtemps, beaucoup d’efforts sont faits pour rac- courcir les temps de mise en œuvre d’un projet, force est bien de reconnaître que l’on assiste à une très forte accélération de cette tendance. Le concept d’ingénierie simultanée n’est pas récent mais les contraintes deviennent de plus en plus fortes au fur et à mesure que des outils se développent pour le faciliter : planification, travail en groupe, EDI, Internet et Intranet, etc. Cette organisation implique l’obligation de modifier le cahier des charges lorsque les données de l’étude amont (et néanmoins menée simultanément) changent. ■ Distinction entre besoins et solutions Les techniciens sont des imaginatifs et dès qu’un problème leur est posé, ils entrevoient immédiatement des axes de solution. Il est toujours difficile, même pour les gens d’expérience de prendre suf- fisamment de recul pour examiner toutes les solutions qui peuvent satisfaire le besoin et non pas la première qui vient à l’esprit. C’est le grand intérêt de la phase d’avant-projet sommaire pratiquée par les ingénieries ; elle impose d’étudier deux ou trois solutions et de les comparer. La phase suivante, avant-projet détaillé, ne considère plus que celle qui aura été retenue en fin d’APS. ■ Arbitrage entre exhaustivité et concision Il pourrait sembler souhaitable qu’un cahier des charges soit le plus complet et le plus exhaustif possible. Le temps accordé à la rédaction d’un cahier des charges étant limité, l’épaisseur du dos- sier est par là même limitée. Mais aussi l’expérience (enquête effec- tuée auprès de plusieurs dizaines d’entreprises) montre qu’au delà d’un certain nombre de pages, le lecteur n’exploite plus correcte- ment et/ou complètement les données qui lui sont fournies. L’étude a conclu que le nombre maximal de pages d’un cahier des charges était de l’ordre de 50. L’on retrouve ici, la notion des besoins implicites évoqués dans la définition de la qualité donnée dans le paragraphe 1.2. Quels sont les besoins que l’on doit expliciter et quels sont ceux que l’on peut considérer comme implicites ? La réponse sera donnée par une réflexion de pur bon sens et par la connaissance que l’on aura de ses partenaires. La référence à des normes permet fréquemment d’alléger le texte. ■ Véritables et fausses contraintes La distinction entre les besoins et les contraintes n’est pas tou- jours facile, mais la distinction entre vraies et fausses contraintes est encore plus difficile. Le rédacteur du cahier des charges dispose d’une chance de remettre en cause des contraintes « historiques » dont la raison d’être a disparu depuis longtemps mais qui perdurent seulement par habitude. ■ Lisibilité L’on verra plus loin qu’il existe de nombreux langages pour décrire ce que l’on attend d’un automatisme ; mais le français littéral reste quand même le plus utilisé. Le cahier des charges sera d’autant plus lisible que l’on utilisera des phrases courtes : sujet, verbe complément. Ne s’agissant pas d’une œuvre littéraire, il ne faut pas craindre les répétitions ; utiliser plusieurs mots synonymes pour désigner la même chose risque de prêter à confusion. Ceci est d’autant plus vrai que l’on destine la spécification à la traduction dans une langue étrangère. Le traducteur ne sera pas forcément spécialiste des automatismes ou du process à automatiser. 3. Recensement et formalisation des besoins 3.1 Outils de recensement des besoins Avant même d’exprimer les besoins, il est nécessaire de recenser tous ceux qui devront être explicités. Pour cela, il existe plusieurs entrées au cahier des charges et plusieurs outils méthodologiques. Figure 3 – Les cahiers des charges successifs Cahier des charges de consultation d'APS Consultation et choix du prestataire Cahier des charges de commande d'APS Exécution d'APS et décision d'APD Cahier des charges de consultation d'APD Consultation et choix du prestataire Cahier des charges de commande d'APD Exécution d'APD et décision de réalisation Etc. APS APD avant-projet sommaire avant-projet détaillé s8095.fm Page 5 Vendredi, 30. novembre 2001 10:49 10
  • 6. CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE _________________________________________________________________________ Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. S 8 095 − 6 ©Techniques de l’Ingénieur, traité Informatique industrielle 3.1.1 Entrées du cahier des charges Les outils créés pour élaborer la liste des besoins sont nombreux et ne sont surtout pas exclusifs les uns des autres. Il est recom- mandé de les utiliser tous, ainsi un besoin qui aurait pu être oublié lors de l’utilisation d’un outil aura moins de chance d’être oublié avec un autre type de réflexion. ■ L’expérience du rédacteur Bien sûr, la première entrée est constituée par la connaissance qu’a le rédacteur à la fois des automatismes et du process à automa- tiser. Néanmoins, le rédacteur chevronné ne devra pas tomber dans le piège qui consisterait à considérer trop de besoins comme impli- cites, son expertise les lui faisant apparaître comme évidents. Les outils méthodologiques suivants seront d’autant plus utiles que l’on sera novice mais ils peuvent aussi apporter une aide cer- taine aux praticiens d’expérience. ■ Les check-lists La check-list (liste de vérification) est surtout utilisée dans les bureaux d’étude ou d’ingénierie qui ont le souci de capitaliser leur savoir-faire acquis au fil des projets précédents. Ces check-lists sont enrichies à chaque nouveau projet et elles permettent d’améliorer à la fois la productivité du rédacteur et la qualité de la rédaction. La forme la plus élémentaire de la check-list est le cahier des charges (ou parties du cahier des charges) du projet précédent se rappro- chant le plus du projet en cours. ■ Les interviews Une autre entrée est constituée par les interviews de tous les acteurs concernés. Parmi ceux-ci figurent en première place les futurs exploitants, mais sont aussi concernés, les agents de mainte- nance, les responsables de la gestion de production, les qualiticiens, le service achats, etc. Il serait dommage de ne pas exploiter toutes les informations que l’on peut glaner aux contacts de ces professionnels. Par contre, la tâche n’est toujours facile : manque de disponibilité des interlocu- teurs, timidité, trop grande modestie et barrières de toutes sortes. Pour débloquer les cas difficiles, il peut être utile de prévoir un questionnaire, utilisé en dernière extrémité. ■ La méthode FAST Acronyme de Functional Analysis System Technique, cet outil méthodologique a été conçu, comme les deux suivants, par des concepteurs devant spécifier des produits, ce qui présente des diffi- cultés encore plus grandes que dans le cas d’un projet d’automa- tisme puisque le client réel n’est pas connu et ne peut donc pas exprimer son besoin. Cette méthode préconise de recenser toutes les tâches nécessai- res à la satisfaction du besoin et, suivant un formalisme bien précis, de les organiser de telle façon que la tâche N – 1 explique l’utilité de la tâche N (réponse à la question « pourquoi ? ») et la tâche N + 1 donne le mode opératoire (réponse à la question « comment ? »). Nota : concernant la méthode FAST, le lecteur pourra consulter l’article [1] des Techni- ques de l’Ingénieur, ainsi que la référence [7]. ■ La méthode SAFE Acronyme de Sequential Analysis of Functional Elements, cette méthode recommande de décliner toutes les actions que l’on sou- haite voir se dérouler dans l’ordre chronologique, suivant un forma- lisme bien pensé puis d’en déduire toutes les fonctions nécessaires à l’accomplissement de ces actions (se reporter à l’ouvrage [7]). ■ La méthode des interacteurs Cette méthode, encore appelée APTE du nom du cabinet d’étude qui l’a mise au point (Applications des techniques d’entreprises de Paris), procède d’une autre approche. Elle consiste à recenser tous les acteurs concernés par l’objet du cahier des charges : exploitants, agents de maintenance, qualiticiens, etc., et de répertorier toutes les fonctions qui leur seront nécessaires dans l’exercice de leurs fonc- tions. Le terme d’acteur doit être pris dans son acception la plus large ; il recouvre aussi l’environnement, les réseaux d’énergie... ■ La méthode GRAIL/KAOS KAOS est une méthodologie pour l’analyse des besoins guidée par les objectifs à atteindre. Son complément, GRAIL, est un outil informatique support de la méthode qui est à la fois un éditeur structuré et un vérificateur sémantique et syntaxique. Cette méthode a été développée par des chercheurs de l’Université catho- lique de Louvain. 3.1.2 Les outils informatiques La tentation est toujours grande pour les automaticiens de tenter d’automatiser leur propre activité. Ainsi ont été développés notam- ment les outils logiciels suivants : — GENERIS de la société Saint-Gobain ; — KSIS développé à l’instigation de la société Elf ; — TRIFON d’Euriware. 3.2 Outils descriptifs 3.2.1 Outils descriptifs généraux ■ Français littéral Il s’agit là, bien sûr, du véhicule de la pensée le plus utilisé. Pour autant que la rédaction soit de qualité, il est universel. ■ GEMMA Acronyme de Guide d’Étude des Modes de Marche et d’Arrêt, cet outil méthode, fruit d’un travail collectif, est d’une remarquable effi- cacité pour effectuer la synthèse d’une analyse fonctionnelle et ini- tialiser une analyse « dysfonctionnelle », si l’on peut s’exprimer ainsi. En effet, nombre de concepteurs se focalisent sur la ou les mar- ches normales et ont une fâcheuse tendance à omettre les régimes de marches perturbées et encore plus le passage d’un mode de mar- che à un autre. Par ailleurs, cet outil décrit très bien « ce qu’il ne faut pas faire » alors que tous les autres cités plus loin décrivent bien « ce qu’il faut faire ». L’application de cette méthode est très simple et pourtant son uti- lisation n’est pas encore généralisée comme elle le devrait. 3.2.2 Outils descriptifs du niveau 1 Il est à noter qu’un cahier des charges d’automatisme de niveau 1 du CIM peut utiliser plusieurs langages dans le même document pour décrire des fonctions ayant des caractéristiques différentes. ■ Français littéral Mêmes remarques que précédemment : d’un usage universel. ■ GRAFCET Fruit d’une réflexion collective française, le GRAFCET (Graphe de Commande à Étapes et Transitions) est maintenant mondialement utilisé. Il permet de décrire d’une façon très claire toutes les fonc- tions séquentielles d’un automatisme industriel. L’on distingue le GRAFCET de niveau 1 qui est un véritable « Espéranto » pour automaticiens et mécaniciens et le GRAFCET de niveau 2, plus détaillé, plutôt réservé aux seuls automaticiens. Ce GRAFCET de niveau 2 permet également, grâce à son formalisme rigoureux, la traduction automatique en langage machine lors de la programmation des automates programmables notamment. s8095.fm Page 6 Vendredi, 30. novembre 2001 10:49 10
  • 7. _________________________________________________________________________ CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. ©Techniques de l’Ingénieur, traité Informatique industrielle S 8 095 − 7 Nota : ces deux niveaux n’ont rien à voir avec les niveaux du CIM dont il a été question plus haut. Nota : concernant le GRAFCET, le lecteur pourra se reporter à l’article [2] desTechniques de l’Ingénieur. ■ Logigramme Les logigrammes ont été très utilisés à l’époque où les modules logiques électroniques étaient la technologie reine. Ils ne sont plus guère employés que lors de la conception de circuits intégrés. Ils sont basés sur l’utilisation des symboles des grandes fonctions élé- mentaires logiques : ET, OU, NI, PAS, Temporisation, Mémoire, etc. Ils font l’objet d’un formalisme décrit par la norme européenne EN 61 346. ■ Chronogramme Les chronogrammes sont particulièrement utiles dans la descrip- tion de séquences d’automatisme très rapides, quand le synchro- nisme ou l’ordre de succession des différentes actions sont cruciaux. Le formalisme du chronogramme se rapproche beaucoup de celui d’un diagramme de Gantt enrichi des liaisons de corrélation des tâches de type PERT (Program Evaluation and Review Techni- que). Nota : concernant la méthode PERT et le diagramme de Gantt, le lecteur pourra consul- ter l’article [3] desTechniques de l’Ingénieur. ■ Schéma à contacts Les schémas à contact ont une vie étonnement longue à l’ère de la programmation. Ils ne sont cités que pour mémoire et de toute façon ne peuvent plus être utilisés que pour la description d’auto- matismes extrêmement succincts. 3.2.3 Outils descriptifs du niveau 2 Contrairement à ce qui peut se faire pour les automatismes de niveau 1 du CIM, un cahier des charges d’un automatisme de niveau 2 se doit d’utiliser un seul langage descriptif quel qu’il soit. Le fran- çais littéral ne sera plus cité que pour mémoire. Il apparaît judicieux d’opter pour le langage le mieux partagé entre les différents parte- naires ou, à défaut de les connaître, le langage que l’on pense le mieux connu, le mieux adapté ou le plus répandu. ■ Ordinogramme Les ordinogrammes ont été l’un des premiers outils des informa- ticiens (Ils sont souvent appelés à tort organigrammes). Chacun les a vus au moins une fois même s’ils sont de moins en moins utilisés. Le symbole essentiel est un losange contenant une question et com- portant deux chemins de sortie l’un répondant à la question par oui, l’autre par non. Ils sont purement graphiques. Ils ont fait l’objet d’une norme annulée. ■ SADT/IDEF0 Acronyme de Structured Analysis and DesignTechnique, c’est un outil, créé en 1977, d’expression des besoins très répandu dans le milieu de l’informatique industrielle après avoir été conçu pour des applications de gestion. Son approche est descendante et son for- malisme extrêmement rigoureux le rend quelquefois laborieux à établir (pour bien le maîtriser, une formation d’au moins deux semaines est nécessaire à un informaticien déjà expérimenté) mais il est tellement plaisant à lire ! Il s’agit d’un outil qui apporte beau- coup plus qu’un mode de représentation graphique. Son symbole principal est l’actigramme, rectangle contenant un verbe à l’infinitif indiquant une action. Le côté gauche est réservé aux entrées, déclencheurs de l’action, le côté droit est dédié aux sor- ties, résultat de l’action, le côté supérieur indique les données utili- sées alors que la face inférieure indique les moyens utilisés. La méthode IDEF0 est une extension de SADT et IDEF1 s’applique aux données. Nota : concernant la méthode SADT, le lecteur pourra consulter l’article [1] des Techni- ques de l’Ingénieur. ■ SART Acronyme de Structured Analysis / RealTime, c’est une méthode plus orientée vers la spécification de systèmes d’automatisme à forte contraintes de temps de réponse et de synchronisme. C’est dans les milieux universitaires qu’il est le plus utilisé. ■ MERISE La méthode MERISE (Analyse et conception des systèmes d’infor- mation) date de la fin des années 1970 ; elle a été mise au point à la demande du ministère de l’Industrie de l’époque pour aider les administrations à formuler leurs besoins. Elle se définit comme une « Méthode de définition d’un système d’information ». Bien que son formalisme soit relativement complexe, la démarche proposée offre l’originalité de séparer l’étude des données de l’étude des traite- ments à effectuer sur lesdites données. Il s’agit là aussi d’un outil qui apporte beaucoup plus qu’un mode de représentation graphi- que. Cette méthode a mis beaucoup de temps à s’imposer dans les milieux industriels, mais c’est maintenant chose faite, du moins en France. Elle propose un phasage très structuré : — schéma directeur ; — étude préalable ; — étude détaillée ; — étude technique ; — production du logiciel ; — mise en œuvre, et pour chacune de ces phases, elle impose une démarche nécessi- tant l’établissement pour les données des modèles suivants : — modèle conceptuel des données ; — modèle logique optimisé ; — modèle physique ; — cycle de vie des objets, et pour les traitements : — modèle conceptuel des traitements ; — modèle organisationnel des traitements ; — modèle opérationnel des traitements. Une autre des originalités de cette méthode est l’usage qu’elle fait de la cardinalité minimale et maximale. Ces documents établis lors des phases initiales du projet consti- tuent le cahier des charges des phases suivantes. ■ ALBERT Acronyme de Agent-oriented Language for Building and Eliciting RealTime systems, cette méthode et ce langage ont été développés dans le cadre d’un projet Esprit 2 par une équipe animée par des chercheurs belges. ■ Nassi Shneidermann et les autres Nous ne citerons que pour mémoire cette méthode descriptive proposée par des ingénieurs d’IBM. Elle était structurée feuille à feuille ce qui rendait sa manipulation remarquablement aisée. D’autres méthodes ont vu le jour, mais sont restées d’un usage moins répandu. 4. Proposition d’un sommaire de cahier des charges La structure la plus complète d’un cahier des charges élaboré par les sociétés d’ingénierie est composée des éléments suivants. s8095.fm Page 7 Vendredi, 30. novembre 2001 10:49 10
  • 8. CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE _________________________________________________________________________ Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. S 8 095 − 8 ©Techniques de l’Ingénieur, traité Informatique industrielle 4.1 La réquisition La réquisition est en fait le sommaire complet de tout le dossier de consultation. Elle rappelle tous les éléments constitutifs du dos- sier avec l’indication rigoureuse des indices de révision. Le soin apporté à sa mise à jour évitera beaucoup de malentendus par la suite : travail sur des dossiers incomplets en toute ignorance, utilisa- tion de documents périmés, etc. La réquisition indique également l’ordre de préséance des documents : le premier cité l’emporte sur les suivants en cas de contradiction. 4.2 Les spécifications générales Les spécifications générales permettent d’améliorer la producti- vité du bureau d’étude mais aussi la qualité des documents pro- duits. Améliorer la productivité car cet élément sera utilisé pour tous les lots d’un même projet et/ou pour tous les projets d’une même tech- nologie. Ce document peut être amélioré ou complété à chaque nouvelle occasion mais point n’est besoin de repartir, chaque fois, de zéro. Améliorer la qualité aussi car cette pratique des spécifications générales évite d’éventuels oublis et permet de capitaliser le savoir- faire à chaque nouveau projet. Que contiennent les spécifications générales ? ■ Les informations mises en facteur Ce document ou ce chapitre comprendra toutes les informations communes soit au projet soit à la technologie. Les spécifications générales d’une technologie définiront toutes les données invariantes d’un projet à l’autre comme les normes applicables, la méthodologie à suivre, les règles de calcul préconi- sées, les coefficients de sécurité choisis, le mode de repérage de la filerie imposé (sans, fils de couleur, numérotation indépendante, tenant / aboutissant) etc. Dans le cas des spécifications générales d’un projet, seront men- tionnés, par exemple, l’adresse du site, les moyens d’accès, le nom des acteurs, les références et coordonnées des organismes concer- nés, médecine du travail, Inspection du travail, organisme de sécu- rité, etc. ■ Les modèles à instancier Les spécifications générales peuvent inclure des schémas types indiquant les principes que l’on souhaite voir mis en œuvre. Seules les valeurs numériques seront à personnaliser par la suite. Par exemple, pour l’alimentation d’une ligne de production, l’on trou- vera le schéma type d’une « tête de filerie ». En effet, pourquoi se reposer toujours les mêmes questions : combien de secondes doi- vent séparer la mise sous tension des entrées d’automates de la mise sous tension des sorties ? Combien de secondes doit-il y avoir entre l’alimentation des circuits transitiques de celle des robots ? Seuls les calibres des circuits d’alimentation et de protection reste- ront à définir en cours d’étude. ■ Les méthodes imposées Pourront être mentionnés également dans les spécifications générales, les méthodes et les outils que l’on souhaite voir utilisés comme tel logiciel de gestion de projet, tel simulateur de partie opé- rative, etc. 4.3 Les spécifications particulières C’est dans ce chapitre que l’on va trouver toute l’originalité du projet. C’est pour cela qu’il est difficile ici d’en parler autrement qu’en termes généraux. ■ L’objet du cahier des charges Il est recommandé de décrire de façon synthétique, en une demi- page au maximum, l’objet du cahier des charges. C’est à la fois effi- cace et courtois. Cela permettra au responsable de l’équipe qui doit répondre à l’appel d’offre de savoir si le projet proposé est de sa compétence et, si oui, quel ingénieur le plus apte (compétence par- ticulière, expérience d’un problème semblable, lieu de résidence...), sera désigné pour étudier le dossier et ce, sans avoir à lire plusieurs dizaines de pages. ■ La présentation du projet Le paragraphe suivant situera l’action en général. On y trouvera notamment : — le nom et les coordonnées des acteurs principaux ; — l’adresse du site et les moyens d’accès ; — les horaires pratiqués et toutes les procédures particulières (attribution de badge, etc.), en évitant les redondances avec les spé- cifications générales du projet, si elles existent. ■ Le glossaire La présence d’un glossaire est une sage précaution, voire dans certains cas une précaution indispensable. En effet, il est bien rare qu’une société ne possède pas plusieurs mots qui lui sont propres ou des mots d’un usage courant mais qui, dans le cadre de la société, ont une signification tout à fait particulière. Le glossaire peut se placer en tête du document ou en fin. Il sem- ble préférable de le placer au début. ■ Les données de base Le chapitre suivant définira la volumétrie du projet. Ainsi, à titre d’exemple, dans le cahier des charges de l’automatisation d’une bibliothèque l’on précisera le nombre de volumes à accueillir, le nombre de lecteurs, les horaires d’ouverture, les délais d’attente souhaités, le nombre de lecteurs attendus, le nombre de places assi- ses, etc. Pour l’automatisation d’un entrepôt, seront énoncés le nombre de palettes en entrée, la loi d’arrivée des camions, la capacité du stock, le nombre de commandes à servir, le nombre de cartons à préparer, etc. Ces données sont quantitatives bien sûr, mais aussi qualitatives. Les valeurs annoncées concerneront les moyennes mais aussi les pointes, variations saisonnières ou autres. ■ La définition du besoin (analyse fonctionnelle) Il s’agit là de la partie la plus importante, le cœur du cahier des charges. Les besoins auront été recensés à l’aide des moyens indi- qués dans le paragraphe 2.2 (1er alinéa) et ils seront exprimés à l’aide des moyens indiqués aux paragraphes 3.1.1 et 3.1.2. Seront exposés la mise en marche de l’installation, le fonctionne- ment en exploitation normale, l’arrêt de l’installation et ses marches de clôture. Pour que cela soit plus clair, les fonctions pourront être regroupées en fonction de leur point de vue : — les fonctions de pilotage (commandes, régulations, optimisations...) ; — les fonctions de gestion de production (ordonnancement temps réel, cadencement, synoptiques, tableaux de bord, journaux de bord...) ; — les fonctions d’aide à la maintenance (tendances, alarmes, aide au diagnostic...) ; — les fonctions d’aide à la qualité (mesures, échantillonnage, variations, CPK...) ; — les fonctions liées à la gestion des données techniques ; — les fonctions logistiques ; — les fonctions liées au respect de l’environnement. Nota : concernant l’indicateur de capabilité CPK, le lecteur pourra se reporter à l’article [6] desTechniques de l’Ingénieur Les fonctions seront décrites dans un ordre logique de telle façon que le lecteur suive facilement ce que le concepteur souhaite. Un poste d’une ligne pourra être complètement décrit en tenant compte de tous les points de vue avant de passer à la description du poste s8095.fm Page 8 Vendredi, 30. novembre 2001 10:49 10
  • 9. _________________________________________________________________________ CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. ©Techniques de l’Ingénieur, traité Informatique industrielle S 8 095 − 9 suivant. Une autre solution peut conduire à décrire tous les postes d’un point de vue avant de passer à un point de vue suivant. ■ La définition des contraintes Ce chapitre décrira les contraintes du projet. En fonction des caractéristiques du projet, les contraintes peuvent être de plusieurs sortes. On trouvera en premier lieu les contraintes normatives et régle- mentaires en faisant référence à des textes, français européens ou internationaux. Une attention particulière sera apportée notamment à tout ce qui touche à la sécurité. Les contraintes d’environnement climatique seront aussi explici- tées : température, pression, humidité relative, air salin, présence de moisissure, de rongeurs... Les contraintes d’exploitation seront également évoquées, pré- sence de substances chimiques agressives, exposition à des projec- tions d’eau, à des chocs, à des vibrations. La détermination du degré de protection souhaité évitera tout malentendu. Les différentes normes françaises et allemandes repri- ses dans la norme européenne NF EN 60-529 codifient ces degrés de protection des enveloppes électriques (coffrets, armoires, boîtiers de capteurs, moteurs, etc.) à l’aide d’un indice de la forme IP x y z dans lequel : — IP signifie Indice de Protection ; — x détermine le degré de protection contre la pénétration de corps étrangers variant de 0 (non protégé) à 6 (étanche à la poussière) ; — y définit le degré de protection contre la pénétration de l’eau variant de 0 (non protégé) à 8 (immersion prolongée) ; — z indique le degré de protection contre les chocs variant de 0 (choc faible : énergie ≈ 0,225 J) à 9 (choc très important : 20 J). Il peut s’agir également de contraintes spécifiques : solutions qui sont déjà imposées ou de matériels déjà choisis. Cela peut égale- ment concerner des procédures à suivre ou des outils à utiliser à moins que cela ait déjà été spécifié auparavant. Les contraintes peuvent aussi concerner les procédures à mettre en place lorsque le projet consiste à réhabiliter une ancienne instal- lation, maintien de la production, basculement en fin de semaine ou pendant une période de fermeture de l’usine, etc. ■ La documentation Ce point est trop souvent négligé. Un dossier de fin de projet en automatisme devrait toujours être composé des éléments suivants : — plan qualité ; — schéma descriptif de la partie opérative ; — notice de fonctionnement ; — analyse fonctionnelle ; — graphe d’études des modes de marche et d’arrêt (GEMMA) ; — liste des entrées/sorties ; — chronogrammes des éventuels points critiques ; — architecture générale du système ; — implantation géographique des matériels ; — liste des messages N1 ↔ N1, N1 ↔ N2, N2 ↔ N3 (N : niveau, cf § 1.4) ; — liste des messages opérateurs ; — schéma des alimentations électriques ; — structure des programmes ; — supports magnétiques des programmes ; — cahiers de recette ; — modèle de simulation des programmes ; — nomenclature détaillée des composants ; — mode du repérage adopté ; — manuel d’exploitation ; — note de sécurité ; — manuel de maintenance ; — liste des pièces de rechange ; — supports ayant servi à la formation. Le cahier des charges doit bien préciser les documents attendus, sinon il y a peu de chances d’obtenir la totalité du dossier. ■ La formation Pour la plupart des automatismes industriels d’une certaine importance, il y a lieu de prévoir une formation avant la mise en service. Le cahier des charges doit indiquer clairement la formation attendue. Cette formation s’adressera vraisemblablement à plusieurs catégories d’acteurs. Une première formation s’adressera à l’encadrement pour lui donner les informations nécessaires à la maîtrise du changement des conditions de travail et à la compréhension des problèmes qui pourront surgir ultérieurement. Une deuxième formation concernera la formation du personnel d’exploitation et une troisième s’intéressera aux agents de mainte- nance. Pour cette dernière session, peut-être sera-t-il judicieux de prévoir des cours séparés pour les électromécaniciens et pour les automaticiens / informaticiens. Le calendrier de ces formations doit être réfléchi : ni trop tôt avant la mise en service (les acteurs se sentiraient peu concernés et auraient le temps d’oublier ce qu’ils auraient appris), ni trop tard évi- demment. Le lieu des formations n’est pas indifférent non plus. Il est préfé- rable qu’une première partie soit dispensée en dehors du lieu de tra- vail afin que le personnel concerné puisse être réellement disponible. Ceci est d’autant plus vrai lorsqu’il s’agit du personnel de maintenance toujours très sollicité. La seconde partie de la formation doit bien sûr s’effectuer sur l’installation elle-même. ■ Les conditions de recette Il est éminemment souhaitable que le cahier des charges précise dans quelles conditions seront effectués les tests permettant de vérifier que la fourniture et ses performances sont bien celles que l’on attendait. Les validations doivent se faire le plus tôt possible dans le cycle de vie du projet, afin de corriger les éventuelles erreurs dès que cela est possible. A cette fin, un calendrier précis doit être élaboré qui comprendra les phases principales suivantes : — essais en plate-forme avec simulateur de partie opérative afin de pouvoir procéder au plus tôt, avant que celle-ci soit disponible ; — essais en plate-forme avec la partie opérative quand cela est possible ; — essais en plate-forme des communications entre les différen- tes parties d’automatisme (même si les communications sont de mieux en mieux maîtrisées, il est rare que l’on arrive au « Plug and Play » et il est plus facile de procéder aux inévitables mises au point en plate forme que sur le site final). — essais sur site de tous les raccordements électriques ; — essais en fonctionnement réel en autonome (s’il y a lieu) ; — essais d’ensemble avec tous les prestataires du site (s’il y a lieu). Chaque phase possédera son cahier d’essai (ou cahier de recet- tes) dans lequel chaque essai élémentaire sera décrit par une fiche dans laquelle seront consignés : — les conditions de l’essai ; — les manœuvres à effectuer ; — les résultats attendus ; — les résultats effectivement obtenus. Des cases permettront de noter les éventuelles anomalies consta- tées et le nom des automaticiens qui auront procédé à ces essais. Les modalités seront définies. Lorsque tous les tests sont jugés satisfaisants, la réception est prononcée. Elle peut l’être sans réserve ou, le plus souvent, avec des réserves mineures. Les réserves majeu- res sont celles qui correspondent à des anomalies suffisamment graves pour interdire l’exploitation dans des conditions acceptables d’opérabilité ou de sécurité. Les réserves mineures sont celles qui correspondent à des carences bénignes (mais qu’il conviendra néan- moins de corriger à court terme) comme une absence d’étiquette, une documentation incomplètement remise à jour, etc. s8095.fm Page 9 Vendredi, 30. novembre 2001 10:49 10
  • 10. CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE _________________________________________________________________________ Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. S 8 095 − 10 ©Techniques de l’Ingénieur, traité Informatique industrielle Le cahier des charges précisera si l’on prévoit une réception uni- que ou en deux temps : réception provisoire et réception définitive. Dans ce dernier cas, la réception provisoire correspond à un fonc- tionnement normal de l’installation, et, souvent un an plus tard, la réception définitive est prononcée lorsque l’on aura constaté que les performances initiales des équipements étaient conservées de façon fiable. Nota : le code des marchés publics ne prévoit plus qu’une réception unique ; le droit privé permet une réception en deux temps. L ’on peut également prévoir d’accorder la réception définitive dès que l’on aura constaté le fonctionnement satisfaisant de l’installa- tion pendant une période significative, un mois par exemple. Le cahier des charges précisera également si l’acheteur souhaite attacher un dernier terme de paiement à la réception définitive, libé- ration de la retenue de garantie. ■ Le descriptif du marché et les limites de fourniture Ce chapitre a pour but de récapituler de façon concise tous les besoins et de bien définir les limites des prestations attendues. C’est ici que l’on trouvera notamment la définition des interfaces entre différents automatismes, entre l’automatisme et la partie opérative ou entre les électriciens et les automaticiens. A titre d’exemple, les réponses seront données à des question comme : — qui raccordera les câbles d’alimentation électrique aux armoi- res et coffrets ? — qui fixera et réglera les capteurs sur la machine ou le convoyeur ? — qui développera les protocoles de communication entre deux lots d’automatisme et qui fournira et posera le médium correspondant ? ■ Les exclusions Il est souvent utile de consacrer un chapitre explicitant les exclu- sions même si cela présente des risques de redondance. En effet, il est facile de décrire, pour le demandeur, les travaux ou prestations diverses qu’il souhaite exécuter lui-même, comme fourniture de mobilier support de console, alimentations électriques ou travaux de génie civil. Cela peut éviter quelques malentendus. ■ La garantie Ce chapitre doit indiquer ce qui doit être couvert par la garantie, ses modalités d’application et sa durée. ● Pour les matériels, la garantie couvre généralement la répara- tion, les nouveaux réglages ou le remplacement de ce qui aura été jugé défectueux. Le cahier des charges devra préciser si la répara- tion doit être effectuée sur le site ou dans les ateliers du construc- teur. Il précisera également la durée d’indisponibilité qu’il juge acceptable et les conditions éventuelles de mise à disposition provi- soire d’un matériel de remplacement pendant la durée de la répara- tion. ● Pour les logiciels, la question est plus complexe. En effet, la garantie ne peut, de façon réaliste, couvrir que les dysfonctionne- ments reproductibles et ce dans un délai qui peut difficilement être garanti. ● Les modalités d’application concernent principalement les délais d’intervention et de remise en route. Plusieurs paramètres interviennent dans la fixation de ce délai, l’importance stratégique de l’équipement concerné, la gravité du dysfonctionnement, le temps de déplacement du technicien pour rejoindre le site, etc. Pour certaines installations d’importance vitale, le cahier des charges peut prévoir la mise en astreinte de dépanneurs, afin de pouvoir procéder à une remise en marche même pendant les périodes chô- mées. ● La durée de la garantie est généralement d’un an, bien que, pour certains matériels informatiques et progiciels, la durée propo- sée par les fournisseurs varie de 3 à 6 mois. Le début de la garantie est souvent fixé à la date de la réception provisoire ou au début de l’exploitation. ■ L’assistance au démarrage Pour des installations complexes, il est judicieux de mentionner dans le cahier des charges une prestation d’assistance au démar- rage. Cette disposition permet de rassurer le personnel d’exploita- tion qui prend possession de son nouvel outil, de l’aider le cas échéant, et de répondre aux questions non abordées dans le cadre de la formation. Un autre avantage de cet arrangement est qu’il permet au fournis- seur de maintenir un personnel sur place qui pourra, le cas échéant, pallier un défaut de jeunesse de l’équipement, couvert bien sûr par la garantie, sans délai d’intervention. ■ La maintenance Il est bon d’aborder, dès le cahier des charges de consultation, le sujet de la maintenance. Quel type de maintenance souhaite-t-on ? Plusieurs scénarios peuvent être envisagés. L’acquéreur peut dispo- ser d’un service maintenance suffisamment étoffé pour n’avoir besoin d’aucune prestation extérieure. À l’inverse, le maître d’ouvrage peut souhaiter externaliser la totalité des actions de maintenance qu’elle soit curative ou systématique. La troisième voie consiste à garder en interne les tâches banales d’entretien ainsi que les tâches de dépannage de premier degré et de faire appel à l’extérieur pour tout ce qui nécessite une spécialisation un peu pointue. Connaître, dès le début du projet, les services attendus après la mise en route permettra au fournisseur de prévoir, en temps utile, le personnel nécessaire en nombre et en compétence. ■ Les pièces de rechange La politique concernant les pièces de rechange doit également être traitée, en même temps que la question de la maintenance dont elle est connexe. De ces deux points dépend directement la disponi- bilité de l’équipement : il s’agit donc d’un sujet vital. Là aussi, plusieurs scénarios sont envisageables qui seront choi- sis en fonction d’un certain nombre de critères : — nature de la pièce concernée, pièce d’usure ou pièce de dépannage ; — importance stratégique ou non de la pièce ; — coût de la pièce ; — délai d’approvisionnement (voire délai de fabrication) ; — possibilité de partage d’un stock de pièces de rechange avec d’autres utilisateurs ; — etc. Aborder le sujet dès le début du projet permettra, par exemple, de fabriquer certaines pièces de rechange (circuits imprimés, capteurs spéciaux, etc.) en même temps que les pièces de l’équipement ori- ginal et donc d’obtenir des prix sensiblement inférieurs à ceux que l’on aurait dû payer si ces pièces avaient été fabriquées en deux fois. 4.4 Le questionnaire Le questionnaire, dans les cahiers des charges de consultation, n’est pas d’un usage fréquent. Il a pourtant une double utilité. D’abord le questionnaire permet d’obtenir des informations qui permettront un choix plus motivé du fournisseur. Parmi ces ques- tions, l’on peut trouver : — l’état du carnet de commande de l’entreprise (pourra-t-elle dégager, sans problème, les ressources nécessaires à la bonne con- duite du projet ?) ; — le chiffre d’affaires de l’entreprise (une trop grande disparité entre le chiffre d’affaires et la taille du projet pourrait conduire dans le cas d’un trop petit projet à un certain manque d’intérêt ou, dans le cas inverse, à une surcharge génératrice de difficultés ou à une sous-traitance occulte) ; — le curriculum vitae du chef de projet pressenti ; s8095.fm Page 10 Vendredi, 30. novembre 2001 10:49 10
  • 11. _________________________________________________________________________ CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite. ©Techniques de l’Ingénieur, traité Informatique industrielle S 8 095 − 11 — les trois derniers bilans de la société (pour s’assurer de la pérennité de l’entreprise) ; — les références (projets comparables réussis récemment) ; — la date de la première version du progiciel et de sa dernière mise à jour ; — etc. Ensuite, une seconde famille de questions peut concerner des points définis auparavant dans le cahier des charges et pour les- quels on demande confirmation. Cette disposition peut paraître amener des redondances, mais elle permet sur des sujets impor- tants d’éviter tous les risques de malentendus du type « Ah ! je n’avais pas bien lu ce paragraphe ! » 4.5 Le cadre de réponse Le cadre de réponse définit le détail suivant lequel le montant total du projet sera décomposé. Souvent considéré, par les consultés, comme une contrainte inu- tile, voire une mesure vexatoire, le cadre de réponse ne présente pourtant que des avantages pour les deux parties. Bien sûr, le degré de détail demandé doit rester raisonnable. Le cadre de réponse permet d’abord d’obtenir une offre structu- rée qui permettra, lors du dépouillement, de comparer les proposi- tions de façon équitable. La décomposition en prix élémentaires par rubriques ou sous- ensembles peut mettre en évidence des disparités qui resteraient inaperçues avec le seul montant global. Si des différences de prix supérieures à 10 ou 20 % apparaissent pour une même rubrique dans deux offres différentes, il peut s’agir soit d’une supériorité technologique importante soit le plus souvent, d’une mauvaise interprétation du cahier des charges. Il peut permettre ainsi d’éviter d’éventuels oublis. Le cadre de réponse peut aussi permettre de faire des ajuste- ments, budgétaires notamment, sans importuner les consultés. 4.6 Le calendrier prévisionnel Il est trop rare que les contraintes de temps figurent dans les dos- siers d’appel d’offre. Ces contraintes déterminent pourtant la faisa- bilité pure et simple du projet pour certaines entreprises consultées. De toutes les façons, le délai imposé conditionne les moyens à mobiliser sur le projet et donc directement les coûts. Le planning indiquera la durée globale du projet mais aussi des dates clés intermédiaires, points de « rendez-vous » avec d’autres lots notamment. Ces dates peuvent aussi être déterminées en fonc- tion des contrôles intermédiaires que l’on souhaite effectuer. Il est recommandé que le cahier des charges demande le plan- ning, détaillé cette fois, proposé par le consulté. La qualité du plan- ning présenté, sa pertinence, sa précision en diront long sur la compétence du fournisseur potentiel et sur les moyens dont il dis- pose. Le calendrier mentionnera également toutes les indications utiles propres à l’entreprise comme dates de fermeture pour congés annuels, périodes de pointe, dates de lancement de collection, etc. 4.7 Les conditions commerciales Un cahier des charges externe se doit de prévoir les conditions commerciales du contrat potentiel. Seront notamment, précisés les éléments suivants. ● Les termes de paiement. Un échéancier sera le bienvenu. Quel événement déclenchera quel pourcentage du montant global ? Il est sain de prévoir des étapes claires comme : remise de l’analyse fonc- tionnelle détaillée, fin des essais plate-forme, prononciation de la réception provisoire, etc. Pour éviter tout malentendu, il est judi- cieux de préciser quels sont les « livrables » pour chacune de ces étapes. ● Les conditions de paiement. La différence entre un paiement par chèque à la remise de la facture ou la remise d’une traite à 90 jours, fin de mois peut justifier une différence de prix significative de la part du fournisseur. ● Les primes et pénalités. Celles-ci peuvent s’appliquer au niveau de performance de la fourniture ou au respect des délais annoncés. La plus grande prudence est à conseiller en ce qui concerne les pénalités de retard. D’une part, la jurisprudence les limite à un pour- centage peu significatif, toujours inférieur à 10 % et, d’autre part, il existe des motivations plus fortes et plus constructives : désir de satisfaire le client et de le fidéliser, volonté de libérer les ressources mobilisées pour les engager sur d’autres projets, etc. 4.8 Les clauses juridiques Ce chapitre définira un certain nombre de points comme : — le ou les bénéficiaires du brevet qui serait déposé à l’occasion de ce projet (le client, le fournisseur ou les deux ?) ; — la protection du client en cas de non respect du droit de la pro- priété intellectuelle ; — le droit d’exploiter le logiciel sur plusieurs applications ou sur plusieurs sites ; — la gestion des droits d’auteur pour les logiciels ; — la libre disposition des programmes sources. Font-ils partie de l’offre originale ? — la disposition des programmes sources en cas de la disparition du fournisseur. (Programmes déposés chez un notaire et disponi- bles seulement en cas de cessation d’activité ?) ; — les modalités de conciliation en cas de graves litiges (recher- che d’un médiateur expert indépendant, recours à l’avis d’un syndi- cat professionnel, etc.) ; — le tribunal qui serait compétent en cas de contentieux. Ce chapitre sera rédigé par le service juridique du futur acquéreur ou avec son aide. Dans le cas d’une petite société, ne disposant pas de structure juridique, peut-être serait-il judicieux de solliciter le concours de l’avocat habituel. 5. L ’absence de cahier des charges Malheureusement et beaucoup plus fréquemment qu’on pourrait le penser, des projets se déroulent en l’absence de cahier des char- ges. Cette démarche, fort peu professionnelle, aboutit à des résul- tats prévisibles : piètres performances, coûts élevés en fin de parcours, retards à répétition, conflits internes et externes, impossi- bilité de recours à une expertise ou à une action en justice, etc. Le prestataire, confronté à une consultation purement verbale se retrouve devant trois possibilités : — accepter de travailler sans cahier des charges, ce qui est sans aucun doute la pire solution pour les raisons évoquées ci-dessus ; — décliner l’offre, ce qui est toujours une décision commerciale difficile à prendre ; — rédiger une offre en forme de cahier des charges, sans doute la moins mauvaise solution mais qui demande un travail considérable le plus souvent non rémunéré et quelquefois non récompensé par l’obtention de la commande. s8095.fm Page 11 Vendredi, 30. novembre 2001 10:49 10