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 − 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
2Supervision
d’une ligne Petits ordinateurs De l’ordre de 20 s
1Commande
d’une machine Automate programmable De l’ordre de 300 ms
0Entré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