Définition de l’ingénierie système

Les premiers éléments de la définition de l’ingénierie système sont extraits des propos de D. Krob lors d’une conférence chez l’éditeur de logiciels Dassault Systeme [Krob,2014a]. D. Krob travaille de-puis de nombreuses années sur ce sujet à la fois en recherche et en lien avec des industriels. Lorsque le nombre d’interactions entre systèmes augmente, une approche en silos [telle qu’elle est aujourd’hui pratiquée dans le secteur de la construction] n’est plus possible. Des changements dans la démarche organisationnelle sont nécessaires comme la redéfinition des rôles et des responsabilités ou la mise en place d’outils informatiques structurants. L’ingénierie système s’intéresse au fonctionnement et dys-fonctionnement des composants techniques (système à produire, intégration pour que les composants techniques fonctionnent ensemble) et du projet (coopération humaines, et outils collaboratifs) [Krob,

2014a]. Lorsque le nombre d’interfaces devient important (pour réaliser beaucoup de fonctions avec un même système),Krobévoque la relation non linéaire (évaluée de manière empirique) entre l’effort d’ingénierie à fournir que l’on notef et la complexitéc. On aurait alors une relation de la forme :

f(c) =cn avecn >1 (classiquement aux alentours de 1,5).

L’ingénierie système permet de diminuer la valeur de cet exposantn et donc de limiter l’explosion de l’effort d’ingénierie à fournir lors de l’augmentation de la complexité du système. De plus, un avantage certain de cette approche par les systèmes est que la quasi-totalité des réalisations humaines sont analysables comme des systèmes : il ne s’agit que d’un choix de modélisation [Krob, 2014b]. Donc toute activité de conception peut s’approprier cette démarche pour modélisation et donc simplifier du

système réelétudié afin de l’étudier. Cette approche est donc en parfaite adéquation avec laconception abstraiteévoquée en section1.2.4page36.

Diab[2014] s’inspire des travaux de D. Krob pour identifier les nouveaux concepts du génie urbain refondé. Cette nouvelle vision intègre pour la ville et l’urbain les concepts de système et de sous-système (techniques ou socio-techniques). Donnons tout d’abord la définition d’un système dans ce contexte :

Un système est constitué d’un ensemble d’éléments [ou sous-systèmes] dont la synergie est organisée pour répondre à une finalité dans un environnement donné [Fiorèse et Meinadier, 2012]. Un sous-système est également un système.

Dans la modélisation et l’analyse du milieu urbain, la ville est considérée comme un système (complexe) et ses nombreux réseaux techniques sont au centre du fonctionnement et du développement urbain [Lhomme,2012]. Ces réseaux portent des services et sont également considérés comme des systèmes. Comme nous l’avons décrit dans notre première partie (Figure1.2page14), une infrastructure intègre de nombreux systèmes. Certains lui sont propres, d’autre sont en interaction avec l’existant ou la traversent seulement. Le concept de système permet une simplification de la réalité pertinente pour l’identification des interfaces entre systèmes, nombreuses pour les projets d’infrastructures routières en milieu urbain. Ce concept apporte également les notions de comportement d’entrée et de sortie ainsi que de comportement interne du système [Krob,2014b]. Une infrastructure par exemple peut perturber le comportement interne du systèmebassin versant(perturbation des écoulements gravitaires) et perturbe donc également la sortie de ce système ; un nouveau projet peut également perturber l’entrée et la sortie du système d’assainissement ou du système viaire existants.

1. AFIS : Association Française d’Ingénierie Système.

4.1. L’INGÉNIERIE SYSTÈME 83 Par contre, le fait de considérer la ville comme un système que l’on scinde en sous-systèmes ne dit rien sur la nature [et les relations] des sous-systèmes en question. La décomposition en sous-systèmes de l’urbain n’est pas unique : elle diffère selon le point de vue : sociale, économique, fonctionnel, etc. [Dupuy,1984]. Nous verrons que même avec un point de vue uniquement technique, les décompositions et abstractions du projet d’infrastructure changent. Ensuite, il est précisé pour l’analyse systémique qu’un système composé de sous-systèmes ne peut être modélisé uniquement par la somme des modèles de ses sous-systèmes (le tout est plus que la somme de ses parties). Nous n’étudions pas en détail ce phénomène d’émergence. Par contre, nous concrétisons ce phénomène au travers de deux concepts que nous détaillons plus tard : leniveau d’abstractionet de la notion d’Entité fonctionnel.

Avec cette approche par les systèmes, notre contexte urbain ne paraît absolument pas éloigné de l’industrie manufacturière et nous encourage ainsi à nous approprier ses méthodes et concepts d’ingénierie système notamment. Cette dernière est d’ailleurs évoquée dans [Rochet et Peignot,2013] pour la conception d’écosystèmes urbains. Par contre, des adaptations sont à prévoir : environ 10 % du temps du projet devraient être consacrés à l’abstraction et à la modélisation et non pas directement à la solution technique. D’aprèsKrob[2014a], ce travail diminue les risques pendant le projet. L’utilisation de l’ingénierie système semble en ce sens intéressante pour une application au secteur de la construction mais rappelons que la structuration de notre marché et des contrats ne permet pas l’allocation de ce temps de préparation.

Donnons deux définitions complémentaires : elles permettent d’appréhender le paragraphe et la figure suivante :

Système à faire (ou « système réalisé » ou « produit » ou « système à réaliser ») : résultat ou produit du projet qui répond aux besoins.

Projet : (ousystème pour faire) processus unique, qui consiste en un ensemble d’activités coordonnées et maîtrisées comportant des dates de début et de fin, entrepris dans un but d’atteindre un objectif conforme à des exigences spécifiques telles que les contraintes de délais, de coût et de ressources [NF ISO 10006, 1998]. Le termeprojet désigne le processus de développement d’un système et plus spécifiquement ici d’une infrastructure. Un projet est également considéré par l’ingénierie système comme un système. Il est également appelésystème pour faire.

Afin de bien identifier le rôle et la place de l’ingénierie système par rapport au projet et au sys-tème à faire, nous nous sommes inspirés d’un diagramme proposé par Fiorèse et Meinadier[2012] que nous avons simplifié. En effet, le contexte dans lequel nous travaillons diffère du contexte classique de l’ingénierie système qui est comme décrit précédemment, celui des industries complexes, comme l’aé-rospatial, ou avec une production en série de l’objet conçu. Dans notre travail, nous nous concentrons sur la partie conception dusystème à faireet ne traitons donc pas la partie planification du projet ou la partie des « produits contributeurs au cycle de vie du système » évoqués dans l’analyse deFiorèse et Meinadier[2012] (voir Figure 4.1). Cette figure, bien que simple, illustre de deux manières la per-tinence de l’utilisation de l’ingénierie système dans le travail de recherche présenté ici. Premièrement, l’ingénierie système fait partie des activités du projet. Ainsi, les processus imposés par l’ingénierie sys-tème s’ajoutent aux processus existants de management de projet et de management de l’information. Puisque nous avons défini préalablement le BIM comme un moyen de mettre en œuvre ces méthodes de l’ingénierie système, par la réorganisation des activités du projet, il est donc majoritairement composé de processus. Deuxièmement, l’ingénierie système permet de définir (d’une manière certes spécifique à cette approche) lesystème à faire et ses interfaces avec son environnement. L’ingénierie système inter-vient donc à deux niveaux dans un projet : sur les processus et sur la structuration de l’information. La cohérence de l’analyse de ces deux niveaux avec une approche commune (l’ingénierie système) implique nécessairement une cohérence entre lesystème pour faire et lesystème à faire. C’est pour cette raison

84 ^{CHAPITRE 4. L’INGÉNIERIE SYSTÈME ET LA GESTION DES EXIGENCES : ÉLÉMENTS}D’APPLICATION

que l’utilisation de l’ingénierie système apparaît pertinente pour la définition de ce que nous appelons les BIM uses.

Fig.4.1 –Intégration de l’ingénierie système dans un projet et impact sur les systèmes « à faire » et « pour faire » (inspiré deFiorèse et Meinadier [2012]).

Plus qu’un outil visant à construire un produit physique, l’ingénierie système « cherche aussi à guider et à coordonner au mieux l’effort de toutes les disciplines concernées par la conception et la réalisation du produit » [Rochet, 2007]. L’ingénierie système a produit « un mode de pensée et une façon d’appréhender les projets par une approche structurée pour passer du besoin à la solution » [ Fio-rèse et Meinadier, 2012]. L’ingénierie système est une démarche méthodologique générale qui englobe l’ensemble des activités adéquates pour analyser, concevoir et faire évoluer un système [Badreau et Boulanger,2014]. L’ingénierie système apparaît par conséquent comme une contribution à la gestion de projet pour « aider à organiser l’organigramme des tâches en fonction de l’organigramme du produit » à réaliser [Luzeaux et Ruault,2013]. Il s’agit donc bien de s’intéresser de manière conjointe au produit et aux processus pour créer ce produit. Cette approche définie par l’ingénierie système procure une vision holistique et une couverture interdisciplinaire d’un projet [Rochet, 2007]. C’est pour ces raisons que l’approche de l’ingénierie système nous intéresse dans l’optique de redéfinir l’organisation des activités de conception (partie processus des BIM uses) en relation avec la définition du contenu de ces BIM uses. L’ingénierie système apparait également comme une aide certaine dans une réflexion sur la structuration de l’information dans un projet. On retrouve la considération de tout le cycle de vie du système étudié : l’ingénierie système (ainsi que l’ingénierie des exigences comme stipulé dans la section4.2 ci-dessous) vise à couvrir l’ensemble du déroulement d’un projet, de l’expression des besoins au démantèlement du système produit. La Figure4.2 explicite la place de l’ingénierie système dans un projet : les éléments non définis précédemment le sont ci-dessous.

Besoin : nécessité ou désir exprimé pour un utilisateur ou par toute partie prenante intéressée par l’utilisation et l’exploitation du système [Fiorèse et Meinadier,2012].

Processus, méthodes et outils de l’ingénierie système : les activités du projet intègrent ces élé-ments, elles sont mises en œuvre pour en faire bénéficier le système réalisé. Ces éléments font partie du projet.

Cette Figure 4.2 indique que tout est système : non seulement le produit réalisé mais également les moyens ou processus pour y parvenir : ce postulat demeure fondateur de l’ingénierie système. Par conséquent, il convient dans une analyse basée sur une approche d’ingénierie système (ou d’ingénierie des exigences que nous verrons ci-dessous), de bien identifier et délimiter le système étudié. Nous verrons plus bas une manière de parvenir à définir le système étudié ainsi que ses limites et son environnement qui l’influencent au travers d’interfaces.

La difficulté majeure de l’utilisation de l’ingénierie système et de l’ingénierie des exigences dans l’industrie est liée au fait que ces deux approches ne proposent pas de méthode ou de démarche

4.1. L’INGÉNIERIE SYSTÈME 85

Fig.4.2 –Lien entre le projet, son produit et les processus d’ingénierie système. Les autres types de processus (processus de conception, de management...) sont inclus dans l’élémentProjet. Ce diagramme est extrait de [Fiorèse et Meinadier,2012].

stricte puisque les champs d’application sont larges et touchent de nombreux domaines d’activité. Ces approches permettent par contre de poser le problème et de le comprendre avec une analyse structurée du système étudié. Comme pour la modélisation d’un modèle de données avec l’UML, la première étape consiste à sélectionner les outils d’analyse (ou diagrammes). De cette étape dépendent les résultats de modélisation et d’analyse qui vont ou non permettre d’aboutir à une compréhension pertinente du problème, au travers de points de vue adéquats.

Ensuite, en ingénierie système, deux approches complémentaires sont à pratiquer d’aprèsFiorèse et Meinadier[2012].

1. Dans un premier temps, le système est considéré comme inclus dans un environnement avec lequel il interagit. Le système est vu comme uneboîte noire. On s’intéresse ainsi aux aspects structurels du système : finalité, environnement, interaction, interfaces externes, aspects temporels (cycle de vie du système) et aspects de pilotage du système.

2. Dans un second temps, le système est considéré comme constitué d’éléments en interaction. Le système est vu comme uneboîte blanche dont la représentation précise la solution retenue pour répondre au besoin. On s’intéresse ainsi aux aspects structurels (organisation interne, composition, architecture et organisation des interfaces internes), aux aspects temporels (comportement interne et évolution fonctionnelle et structurelle) et aux aspects de pilotage (organisation interne du pilotage).

Le mélange ou la confusion de ces visions de boîte blanche et noir est préjudiciable à la fois pour le système à produire ainsi que pour le projet lui même. Il s’agit d’un des problèmes fondamentaux de l’ingénierie système [Fiorèse et Meinadier,2012]. A noter que cette vision en boîte noire est reprise par lescas d’utilisationde l’UML et qu’il s’agit également de la première étape d’analyse conseillée pour la modélisation d’un système en UML [Booch,1992].

Dans un processus de conception, le Projet développe le système à faire qui devient à la fin du Projet le produit3 ou système réalisé. Par analogie pour le domaine de la construction, le système à

3. Aujourd’hui, il n’est pas courant d’appelerproduitun ouvrage de génie civil ou une infrastructure. Toutefois, nous conservons ce terme afin de travailler d’utiliser les termes et concepts développés par l’ingénierie système pour d’autres industries que celle de la construction.

86 ^{CHAPITRE 4. L’INGÉNIERIE SYSTÈME ET LA GESTION DES EXIGENCES : ÉLÉMENTS}D’APPLICATION

faire est l’infrastructure construite et en exploitation. Toutefois, le changement de paradigme actuel évoqué dans l’introduction de ce chapitre apporte une valeur à l’information qui fait également partie du produit final (voir la partie haute de la Figure4.3). Le système étudié dans notre travail considère le « Projet » comme étant uniquement le projet en phase de conception4: par conséquent, lesystème à fairen’est pas l’infrastructure mais seulement les modélisations de l’infrastructure ainsi que les données relatives aux activités de conception. Il s’agit donc de toute l’information de la conception, structurée, de manière à permettre la transmission de l’information aux étapes suivantes du projet complet dans une optique d’ingénierie concourante avec les acteurs de la phase de construction (voir la partie basse de la Figure4.3). La continuité dans la définition et l’utilisation de l’information sur tout le cycle de vie de l’infrastructure est ce qui donne la valeur à l’information produit et fait qu’elle appartient bien au produit final du projet complet. Par ailleurs, c’est ainsi que se posent les plus importants problèmes d’interopérabilité et de continuité dans les échanges d’information et dans l’établissement des processus. Le terme « base de données » dans la Figure4.3 évoque les différentes bases de données physiques utilisées dans le projet. A noter que chaque projet de la Figure 4.3 peut être organisé en plusieurs projets.

Fig.4.3 –Différenciation du projet d’infrastructure et du projet de conception de l’infrastructure pour l’identification du système à faire. Cette représentation simplifiée ne considère pas le recouvrement possible de certaines phases selon le contrat. La considération de l’environnement contractuel (loi MOP, PPP, etc.) n’influence pas la définition dusystème à faireà ce niveau de représentation. Il reste identique alors que lesystème pour fairelui peut varier selon l’organisation contractuelle des acteurs.

Afin d’expliciter le lien entre les éléments de la Figure4.3 (les différents système à faire) et notre proposition de MCD, nous proposons pour terminer cette partie sur l’ingénierie des exigences par la Figure 4.4. Le système à faire du projet de conception est le modèle du système à faire du projet d’infrastructure complet. Plus précisément, notre proposition de MCD ainsi que la méthode de définition du contenu des BIM uses permettent de structurer lesystème à faire du projet de conception.