|
Jean-Pierre Meinadier a prononcé le 10 janvier 2005 une conférence au
club des maîtres d’ouvrage. Cette fiche
présente des réflexions qui se sont exprimées au cours de cette conférence
et dans le débat qui l'a suivie.
Le SI, cas particulier pour
l'ingénierie de système
L’ingénierie des systèmes
d’information relève de l’ingénierie de système.
On y retrouve les mêmes notions (maîtrise d’ouvrage et maîtrise d’œuvre ,
conduite de projet, spécification des exigences etc.) Le maître d'ouvrage d'un
système d'information a donc tout intérêt à connaître les méthodes de l'ingénierie de
système,
car elles concernent son activité au même titre que tous les autres travaux d'ingénierie.
Cependant le SI présente des
caractéristiques qui font de lui, au sein de l’ingénierie de système, un cas
particulier. L’ingénierie de système est plus difficile dans le SI que
dans les projets techniques, même très complexes.
Un projet technique comme la
conception d’un avion ou d’une centrale nucléaire est en effet réalisé par des
ingénieurs. Ils expriment leurs exigences en termes observables et mesurables,
et sont soucieux de traiter les questions de physique que pose la
conception et la fabrication du produit de telle sorte que celui-ci réponde à
ces exigences.
Par contre un projet de SI concerne non un produit, mais le fonctionnement d’une organisation. Il
n'est pas facile de définir des critères pour évaluer sa réussite. Il
existe d'ailleurs un écart entre l'organisation humaine, dont le flou est à la
fois naturel et entretenu, et le logiciel dont le fonctionnement est
automatique.
Ainsi, alors que l'ingénierie
de système donne une place importante à l'identification précise des exigences,
au suivi de leur réalisation tout au long du projet et enfin à leur vérification
lors de la recette finale, on le fait rarement pour un système d'information. On
devrait pourtant à tout le moins imposer à la maîtrise d'oeuvre de formaliser
les spécifications sous forme d'exigences, avec les méthodes de vérification
associées, et de produire les tableaux de bord qui permettront d'en assurer le
suivi.
On raconte l’anecdote
suivante : un spécialiste de l’ingénierie de systèmes, appelé à mettre en place
un système d’information, demanda que l’on précisât d’abord la répartition des
pouvoirs de décision. Son intervention s’est arrêtée là, les hommes de pouvoir
préférant laisser implicite cette répartition des responsabilités. Un des
membres du club a dit par ailleurs qu’il devait consacrer 95 % de son temps à des questions de
pouvoir, 5 % seulement à des questions relevant du processus de production
de l’entreprise : certes, c'est là un cas extrême, mais il indique une
caractéristique propre au SI.
Comment faire de l’ingénierie de SI ?
Comme le SI s’insère dans
l’organisation et touche à la répartition des pouvoirs légitimes, il faut
l’ancrer sur des choses aussi stables et aussi objectives que possible. Il est donc
salubre de prendre pour point de départ les produits que l’entreprise
élabore, puis leurs processus de production, ensuite les livrables (ou
produits intermédiaires) que fournissent des sous-processus, enfin
les activités qui s'enchaînent dans le parcours de chaque processus.
La
démarche se fonde ainsi sur la physique de l’entreprise – processus de
production et de commercialisation, relations avec les clients et partenaires –
et non sur la répartition des pouvoirs que découpe l’organigramme et que l’on
nomme, par abus de langage, organisation. Les applications informatiques
deviennent alors invariantes par rapport à cette "organisation" qui, elle, est
aujourd'hui de plus
en plus évolutive : un changement de l'"organisation" entraînera une simple
modification de l'affectation des activités aux diverses entités de
l'entreprise.
Les exigences de qualité
s’expriment en termes de qualité des produits, qualité des processus
(maîtrise des délais, satisfaction des clients), efficacité (consommation des
ressources), toutes choses qu’il est possible d’observer et de mesurer. Il faut
donc non seulement que le SI outille le processus en automatismes, mais aussi qu’il
produise en temps réel les indicateurs qui, rendant sa qualité visible par tous,
inciteront à la maintenir.
L’ingénierie doit, dans les
systèmes techniques, satisfaire toutes les exigences initiales (amendées
par d'éventuelles demandes de dérogation formellement acceptées par le maître
d'ouvrage) : ces exigences,
exprimées par des ingénieurs, résultent déjà d’une sélection sévère. Dans les
systèmes d’information, par contre, les exigences initiales sont souvent
démesurées. Il faudra savoir ne retenir parmi elles que les 20% vraiment
indispensables, leur sélection devant être dûment justifiée.
Être raisonnable
Il faut en ingénierie de
système se défier des connotations du mot « optimiser » et du mot « rationnel » :
mieux vaut s'efforcer d'être raisonnable, terme qui a lui aussi pour
racine le mot raison !
Il est en effet impossible,
lorsqu'il faut satisfaire quelques milliers d'exigences, de
mettre l'ensemble des contraintes dans une équation qui donnerait le paramètre
économique à maximiser.
Peut-on d'ailleurs définir le meilleur avion, la meilleure
automobile ? Dans un tel contexte, « optimiser » ne peut pas vouloir
dire que l'on
cherche à maximiser une fonction objectif : il s'agit plutôt de faire une
analyse de la valeur sur les choix successifs, selon une approche qui considère
l'ensemble du cycle de vie du produit.
L'ingénierie de système
implique donc que l'on s'attache à raisonner sur des choix et à les justifier en
tenant compte des points de vue de tous les acteurs concernés. Beaucoup de SI
sont devenus des monstres inexploitables parce que l'on ne s'était pas interrogé
sur la pertinence de la demande des utilisateurs.
Il est raisonnable de chercher
à faire le travail le moins lourd possible tout en satisfaisant convenablement
les besoins : cela implique de ne jamais tenter d’automatiser les tâches que
l’être humain accomplit mieux que l’ordinateur. La FAA (Federal
Aviation Administration aux Etats-Unis), qui a tenté d'automatiser le
travail des contrôleurs aériens, a dû arrêter ce projet alors qu'il avait déjà coûté
plusieurs centaines de millions de dollars. Il ne faut pas non plus tenter d’automatiser les arbitrages politiques, les décisions
stratégiques auxquelles le SI ne peut fournir que des tableaux de bord et des
simulations. Par contre on peut automatiser efficacement une aide à la décision
opérationnelle (quart-opération du transport aérien, décision de prêt dans une
banque, cellule de crise).
Bien souvent, on ne peut pas
assigner de limite rationnelle à la richesse d’un outil, au détail d’un
référentiel etc. Dans ce cas, il sera raisonnable de borner les exigences en se fixant une limite
arbitraire en budget et en délai. On pourra
par la suite enrichir l'outil si le besoin s'en fait fortement sentir.
Enjeux et compétences
Le SI est le langage de
l’entreprise, un langage articulé à son action. Il est organique, lié à son
positionnement, à ses priorités ; il exprime sa personnalité. L’entreprise le
sécrète tout comme une civilisation sécrète sa langue. Il n’est donc pas
étonnant que sa définition révèle des enjeux, suscite des conflits,
s’accompagne de malentendus.
Les compétences de l’ingénieur,
la rigueur avec laquelle il applique les principes de l’ingénierie, ne suffisent
pas pour concevoir un SI : il faut aussi qu'il possède une sensibilité de
sociologue et des compétences en linguistique. Il
faudra qu'il sache « manipuler pour la bonne cause », dans le droit fil de l’École
de Palo-Alto. Ceci est vrai d'ailleurs non seulement pour le SI, mais aussi
pour les projets techniques et scientifiques lorsqu'ils impliquent plusieurs
entreprises, plusieurs pays, plusieurs cultures.
* *
La conception d'un SI suppose
une spécification précise, sans quoi on abandonne au programmeur le choix de ce
qui devra être implémenté. Les choix fondamentaux, qui relèvent de l'analyse de
la valeur, sont in fine du ressort de la maîtrise d'ouvrage qui seule
peut évaluer la rentabilité d'un projet.
L'apport majeur de l'ingénierie
de système réside dans la clarté de la justification des choix du maître
d'ouvrage. Jean-Pierre Meinadier plaide pour une MOA compétente et rigoureuse.
L'expérience lui a montré que la maturité de la MOA était le facteur décisif de
la réussite d'un projet, c'est-à-dire de la satisfaction des utilisateurs et des
autres parties prenantes.
|
