RECHERCHE :
Bienvenue sur le site de Michel VOLLE
Powered by picosearch  


Vous êtes libre de copier, distribuer et/ou modifier les documents de ce site, à la seule condition de citer la source.
 GNU Free Documentation License.

Intégration de système et système d’information

15 janvier 2005


Pour lire un peu plus :

- L'école de Palo Alto
- Méthodes de la maîtrise d'ouvrage

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 [1]. On y retrouve les mêmes notions (maîtrise d’ouvrage et maîtrise d’œuvre [2], 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.


[1] Jean-Pierre Meinadier, Le métier d’intégration de système, Hermès 2002

[2] Maîtrise d'ouvrage et maîtrise d'oeuvre sont des termes du vocabulaire français de l'ingénierie de systèmes (et pas seulement des systèmes d'information) ; les mêmes responsabilités existent bien sûr dans les entreprises américaines, mais elles les nomment autrement (organization, business engineering etc.)