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

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 _________________________________________________________________________
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

_________________________________________________________________________ CAHIER DES CHARGES DES AUTOMATISMES. ANALYSE FONCTIONNELLE
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

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 ?

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é

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.

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.

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

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.

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 ;

— 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.

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

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

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

Plus de SAID MASHATE

Plus de SAID MASHATE (20)

Dernier

Dernier (13)

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