L’ingénierie système et l’ingénierie des exigences étaient au départ deux domaines séparés même si l’ingénierie système traitait déjà partiellement des exigences. De plus, l’ingénierie des exigences se rencontrait le plus souvent pour des applications orientées logiciels. Elle s’applique maintenant de manière beaucoup plus large à bien d’autres métiers. Aujourd’hui, la gestion des exigences passe sous l’aile de l’ingénierie système. Cela donne une plus grande cohérence et lie plus intimement les systèmes et les exigences. Il devient plus aisé d’arriver aux exigences atomiques (indivisibles) et de les affecter à l’objet adéquat : l’allocation des exigences est fondamentale dans l’approche de l’ingénierie système [Badreau et Boulanger,2014].
Les exigences sont le point d’entrée dans le processus de conception. Elles décrivent les objectifs et performances à atteindre. Dans leur ouvrage,Badreau et Boulanger[2014] reprennent les résultats d’un projet d’analyse des raisons d’échec et de réussite des projets (rapport CHAOS du Standish Group, régulièrement mis à jour depuis 1994). D’après ce rapport, une mauvais mise en application de
4.2. L’INGÉNIERIE DES EXIGENCES 89 nierie des exigences est responsable de 22 % des échecs et l’implication des utilisateurs conditionne de quasiment un tiers la réussite du projet. D’où l’importance de définir la structuration de l’information en considérant également les processus et les responsabilités des acteurs. Dans un projet d’infrastructure, ces éléments de processus sont décrits dans des documents d’organisation de la production, éventuel-lement contractuels, comme le BIM Execution Plan (BEP) qui décrit les éléments de mise en place du BIM sur le projet.
Ensuite, au travers de plusieurs références,Badreau et Boulanger[2014] justifient que le coût relatif de correction d’une erreur sur les exigences est exponentiel en fonction de l’avancée des phases de conception (identification des besoins, conception jusqu’à la maintenance). D’ailleurs, il s’agit de ce qui est indirectement évoqué dans la justification du BIM : la mise en place dès le début du projet d’un processus de conception globalisé entre les acteurs favorise la bonne compréhension des exigences du projet (en lien avec ce qu’exprime la Figure1.10page28sur le paradoxe du processus de conception). Elle améliore par conséquent la qualité de la conception puisque, plus les modifications interviennent tard, plus elles sont coûteuses. Une bonne gestion des exigences permet de manière classique la maîtrise des coûts du projet, la diminution des risques, la diminution du temps de mise sur le marché, la satisfaction du client et des utilisateurs ou l’augmentation de la qualité du produit. L’ingénierie des exigences a vocation à optimiser la conception pour répondre au mieux aux besoins à couvrir, en limitant les besoins insatisfaits et les fonctions inutiles du système conçu [Badreau et Boulanger,2014]. Travailler ainsi nous permet de cibler les besoins et de structurer le modèle conceptuel des objets (système à faire) de manière optimale. Ainsi, la première difficulté réside plus dans la définition de ces besoins que dans la réelle structuration du modèle de l’infrastructure.
L’ingénierie des exigences est une démarche méthodologique qui regroupe l’ensemble des activités permettant d’établir et de maintenir un référentiel d’exigences dans le temps [Badreau et Boulanger,
2014]. C’est la charnière entre l’analyse de la problématique à résoudre et la définition de la solution. Les définitions qui suivent sont nécessaires à la bonne compréhension des éléments de cette partie. Elles sont extraites de [Badreau et Boulanger,2014] et cohérentes avec celles données au début de la section sur l’ingénierie système.
Partie prenante : est une personne physique ou morale qui a une influence ou un intérêt direct ou indirect dans un projet. Cette définition convient au terme d’acteur plus couramment utilisé dans notre industrie de la construction.
Acteur : est une personne physique ou un système distant qui interagit avec le système étudié pour atteindre un but précis.
Besoin : est une nécessité, un désir, un manque ou une insatisfaction éprouvés par un utilisateur.
Exigence : est un énoncé qui traduit un besoin ou des contraintes (techniques, coût, délais, etc.). Cet énoncé est rédigé dans un langage qui peut être naturel, mathématique, etc. [AFIS,2012].
Système : un système est un ensemble de composants matériels, logiciels et humains qui coopèrent d’une manière organisée, dans un but d’atteindre un objectif commun.
Il existe plusieurs types d’exigences : Badreau et Boulanger [2014] distinguent celles relatives au produit développé et celles relatives aux processus : il s’agit par exemple des exigences de coût, de délai, de volume de vente, d’organisation [. . . ]Ce sont des contraintes sur la manière de réaliser le système à faire que l’on trouve généralement décrites dans un document appelé Plan de Management de Projet (PMP)7. Comme nous l’avons illustré dans notre première partie, le livrable du projet ne doit plus être un ensemble de plans mais la base de données contenant les informations qui permettent de créer ces plans et de connaître l’historique de la conception. Ainsi, les processus qui permettent de crées cette information et d’en garantir la qualité
7. PMP : Plan de Management de Projet. Document ou ensemble de documents qui décrivent comment le projet sera réalisé, suivi et piloté [ISO 21500 : Lignes directrices sur le management de projet] [AFITEP,2010].
90 CHAPITRE 4. L’INGÉNIERIE SYSTÈME ET LA GESTION DES EXIGENCES : ÉLÉMENTSD’APPLICATION
sont de plus en plus souvent contractuels. Ensuite, les exigences relatives au produit développé se décomposent en deux catégories : les exigences fonctionnelles (liées aux fonctionnalités du système, répondant à la question « Que fait le système ? ») et les exigences non fonctionnelles (liées à la manière dont se comporte le système, répondant à la question « Comment se comporte le système ? »). Elles traitent des performances du système ou de ses composants (voir la partie gauche de la Figure4.6). Les exigences fonctionnelles sont dédiées à la description grossière du projet, avec un niveau d’abstraction plus important que les exigences non fonctionnelles, relatives elles à des composants ou organes du projet. S’ajoute à cela une nuance sur la manière dont elles sont définies. En effet, selon la phase du projet, certaines exigences peuvent ne pas être encore parfaitement définies ou peuvent évoluer. D’autres exigences peuvent être parfaitement définies, avec des valeurs chiffrées de performance comme pour la sécurité des usagers d’une route par exemple, avec les performances des glissières de sécurité. Par contre, la réponse à cette exigence est beaucoup plus floue et sujette à discussion puisqu’elle doit tenir compte des objets constituant l’environnement physique proche de cette glissière. C’est ensuite un expert qui évalue cette réponse, par rapport à cet environnement et à l’exigence de performance. Ce type d’exigence fait donc appel à une multitude d’informations de différents types. Notre proposition de méthodologie d’établissement du contenu des BIM uses vise à établir les liens, nombreux, entre objets, systèmes et exigences, et qui structurent notre MCD de projet. Suite à notre étude de l’ingénierie système et au travers des cas d’usages de notre quatrième partie, l’ingénierie système est selon nous un moyen efficace pour définir ces liens.
Une autre répartition possible des exigences est celle décrite dans [Krob, 2009; Doufene et al.,
2014]. Elle est plutôt utilisée pour l’architecture des systèmes complexes ou dans le développement logiciel. Nous verrons par la suite qu’elle reste tout à fait pertinente pour une application au secteur de la construction. Elle est en fait complémentaire à la précédente différentiation qui vient d’être décrite. Cette répartition considère trois visions illustrées dans la partie droite de la Figure4.6:
1. la visionopérationnellequi a pour but de définir le pourquoi du système, autrement dit de préciser la mission du système et ce à quoi sert le système ;
2. la visionfonctionnellequi a pour objectif d’expliciter le fonctionnement logique du système, c’est-à-dire ce qu’il fait indépendamment de la façon dont on le réalisera ;
3. la vision organique qui explique la façon dont le système est concrètement réalisé, c’est-à-dire l’organisation et la dynamique de ses composants matériels, logiciels et humains (les objets des IFC peuvent par exemple porter certaines des exigences organiques).
Fig.4.6 – Confrontation entre deux manières d’identifier des exigences : partie de gauche basée sur [Badreau et Boulanger,2014] (définition des types d’exigences) et partie de droite basée sur [Krob,2009] (visions portées sur un système (à faire ou pour faire) et qui influence la structuration des exigences).
4.2. L’INGÉNIERIE DES EXIGENCES 91
Nous distinguons donc deux manières d’approcher la structuration des exigences qui sont complé-mentaires. La première se base sur le type d’exigence, pour bien distinguer celles relatives ausystème à faireet celles relatives ausystème pour faire. La seconde établit une structuration des exigences selon les visions portées sur le système étudié (partie de droite de la Figure 4.6). Cette structuration est à développer en parallèle des visions portées sur lesystème à faire [Krob, 2014b]. La structuration par type sert à la création du référentiel d’exigence car elle facilite le travail d’identification et de définition des nombreuses exigences du projet. Nous allons plutôt nous concentrer sur la définition des exigences par vision, puisqu’elle aura des conséquences sur la ou les décompositions en objets du projet. En lien avec la Figure4.7, la hiérarchisation des exigences permet :
– de répercuter des modifications d’une exigences (E1.3) sur d’autres par hérédité (E1.3.1), – de connaître l’impact de la modification d’une exigence (E1.3.1) sur les objets (O1.2.2 et O1.1), – de connaître les exigences à réévaluer (E1.3) lors de la modification d’un objets (O1.1) pour des
raisons non liées aux exigences de cette vision par exemple.
Fig.4.7 –Exemple de relations entre la structuration des exigences et des objets sur une seule vision portée sur le projet.
La modélisation des exigences, bien que nécessitant des compétences et connaissances spécifiques ainsi que des outils et des modèles, procure des avantages indéniables d’aprèsBadreau et Boulanger
[2014] :
– meilleure compréhension du problème et de la solution ; – meilleure analyse du problème et de la solution ;
– réduction de la complexité du domaine grâce à l’abstraction ; – meilleure communication avec les parties prenantes ;
– pose les bases d’un raisonnement sur un problème, une solution ; – amélioration de la cohérence et de la complétude des exigences.
Voici quelques exemples d’exigences dans le contexte d’un projet autoroutier (elles sont extraites des documents réglementaires : dans ces documents les exigences sont parfois posées de manière
inter-92 CHAPITRE 4. L’INGÉNIERIE SYSTÈME ET LA GESTION DES EXIGENCES : ÉLÉMENTSD’APPLICATION
rogative).
– Les vitesses réglementaires pour chaque section sont-elles adaptées ?
– La superficie et la capacité de l’aire de service est-elle cohérente avec le niveau d’aménagement ou sa fonction ? (Cette exigences par exemple nécessite une déclinaison en sous-exigences car elle n’est pas assez précise ni vérifiable.)
– La règle d’implantation des niches et issues est-elle respectée ? Cette exigence implique un contrôle de plusieurs points de la réglementation incendie en tunnels. Elle doit donc également être déclinée en plusieurs autres exigences.
Les exigences sont nombreuses et plus ou moins détaillées. Elles sont également de type bien différent comme nous venons de le voir. Il est impossible de gérer les exigences sans les structurer e tles catégoriser. Il existe de nombreuses règles et bonnes pratiques concernant l’expression des exigences. L’ouvrage de l’AFIS [2012] par exemple donne des pistes pour ce travail. Nous détaillons en Annexe E les étapes d’application de l’ingénierie des exigences que nous avons utilisées pour détailler les exigences à traiter dans nos expérimentations. Évoquons ici seulement le fait qu’une exigence doit être claire, précise, de préférence formalisable et surtout, vérifiable. La définition des exigences et leur gestion constitue un pan entier de recherche et de travaux industriels. Dans un contexte de gestion des exigences, l’utilisation du langage naturel est et restera comme l’écrit Badreau et Boulanger [2014] le principal vecteur de communication des exigences d’un système ou d’un logiciel, notamment du fait des avantages qu’il procure : universel et flexible, facilite la compréhension mutuelle sans formation ou expérience particulière et ce, sans outillage spécifique [Badreau et Boulanger,2014]. Ces points sont tout de même à nuancer selon les contextes car comme le montrent tous les exemples donnés dans l’ouvrage de l’AFIS [2012], la capacité à rédiger correctement des exigences en langage naturel sans connaissances particulières du domaine n’est pas si évident que les propos précédents peuvent laisser paraître. Illustrons nos propos par quelques exemples applicatifs sur un projet d’infrastructure urbaine.
La réponse aux exigences est itérative et selon l’avancée de la conception, pour une même exigence, la précision dans la réponse croît. Par exemple, concernant le plan de signalisation directionnelle8, au début des études, seul le plan dans son ensemble est contrôlé. Puis, selon l’avancée de la conception, la conformité de ce système de signalisation directionnelle est contrôlée avec de plus en plus de rigueur alors que ce qui dirige la conception, les exigences (principalement réglementaires dans ce cas), sont fixes. Il existe donc des nuances dans le contrôle des réponses aux exigences. Nous verrons plusieurs cas explicites dans l’exploitation des BIM uses en quatrième partie. Ensuite, dans le cadre de la loi MOP par exemple, les exigences auxquelles il faut répondre sont de plus en plus précises avec l’avan-cée des phases du projet. Le niveau d’information fourni par la conception pour y répondre doit donc croître de manière similaire. Prenons l’exemple d’une passerelle. D’après [Sétra, 2008], le programme du projet doit indiquer les modes d’utilisation envisagés (piéton, cycliste, équestre) et répondre aux exigences spécifiques à ces modes (réglementation notamment). Ensuite, avec l’avancée de la concep-tion, les exigences se précisent : largeur selon l’utilisation ou conforte des usagers par exemple. A cela peut également s’ajouter la superposition d’exigences de conception et d’exigences de construction qui peuvent être contradictoire, lors de Partenariat Public Privé (PPP) notamment. Nous pouvons citer par exemple de possibles contradictions entre exigences de performances (ouvrage en service) avec des exigences de construction liées aux besoins de limiter l’impact du chantier (pollution visuelle ou sonore notamment pour des chantiers en zone urbaine). Des solutions préfabriquées pour certains ouvrages d’art peuvent être préférées plutôt Ou encore une variabilité de la traduction selon la phase. L’exemple d’une exigence de gabarit libre en tunnel illustre parfaitement ce propos : la hauteur libre est définie par la réglementation (hauteur réglementairedans la Figure 4.8 à gauche). Au niveau PRO, les
4.2. L’INGÉNIERIE DES EXIGENCES 93 teurs9sont implantés verticalement à partir de la chaussée en respectant la hauteur réglementaire qui est fixe. L’exigence de gabarit est donc contrôléevia les clashs10 entre les accélérateurs et l’intrados de la couverture du tunnel. En phase EXE, on s’intéresse à la construction du projet et à la mise en place des équipements. Par conséquent, l’exigence de gabarit (lahauteur évaluée doit être supérieure ou égale à la hauteur réglementaire) est mesurée après implantation de l’accélérateur (le modèle de cet objet est celui du catalogue constructeur par exemple, pour répondre aux exigences de sécurité incendie et de ventilation) selon les dispositions techniques réglementaires. Dans les deux cas de la Figure4.8, l’exigence n’est pas respectée (clash en phase PRO et hauteur libre inférieure à la hauteur réglementaire). Il en est de même pour de nombreux autres équipements ou panneaux de signalisation verticale notamment. Ainsi, selon la phase, une même exigence est évaluée de manière différente.
La structuration des exigences est indispensable pour leur gestion ainsi que pour décider des com-promis lors d’incompatibilités entre exigences (application de plusieurs exigences sur un même objet, potentiellement de plusieurs niveaux d’abstraction ou visions). La répercution de la modification d’une exigence ne va pas nécessairement des exigences opérationnelles vers les exigences organiques. Par exemple, si la géométrie d’une plateforme est trop contrainte par son environnement et ne peut répondre à la réglementation (exigence fonctionnelle, voire organique puisque appliquée à l’objetplateforme), la vitesse limite de circulation peut être diminuée (exigence opérationnelle).
En lien avec les précédents éléments sur l’ingénierie des exigences et la Figure1.10page28sur le paradoxe du processus de conception, nous faisons les constats suivants :
– une réflexion de fond sur les besoins est nécessaire en amont, d’autant plus que le programme engage la majorité du coût d’un projet ;
– la structuration des besoins et leur rapport aux exigences qui en découlent est indispensable pour connaître et mieux gérer les conséquences des choix de conception ;
– l’effort de création de l’information doit être réalisé plus dans les phases amont et la conservation de ce capital informationnel, de manière exploitable, est cruciale.
Le dernier point apparaît régulièrement dans les préconisations pour un « BIM efficace ». Toujours en lien avec le paradoxe du processus de conception illustré en Figure 1.10 page 28, un effort plus important de création de l’information en amont permet de prendre des décisions en se basant sur de l’information plus fiable et donc avec des risques mieux contrôlés. Cette information permet ensuite d’alimenter les BIM uses pour contrôler au plus tôt la réponse de la conception aux exigences. Comme les BIM uses traitent à la fois des exigences et de l’information de conception (système à faire), il est indispensable que notre proposition de MCD apporte une cohérence entre la structuration des exigences et la structuration de l’information. Nous traiterons en détail ce point dans la troisième partie de ce mémoire. Nous verrons également comment l’ingénierie des exigence permet d’affiner le travail de modélisation en trois étapes et garantit la considération des éléments pertinents en fonction de chaque exigence à traiter. Cela correspond à la définition du contenu des BIM uses.
Nous avons présenté ici une procédure rationnelle de définition des exigences. Toutefois, comme le préciseMoine[2006] : « Si un équipement est localisé précisément à tel endroit, ce n’est pas forcément en relation avec une loi d’organisation spatiale reconnue par la communauté scientifique, mais tout simplement parce qu’un acteur politique influent, ou plus raisonnablement un groupe d’acteurs, l’a souhaité en dehors de toute « rationalité » scientifique ». Ainsi, une difficulté supplémentaire s’ajoute
9. Accélérateur : ventilateurs fixés à la couverture du tunnel pour la circulation de l’air intérieur.
10. Un clash est souvent considéré comme une interaction volumique entre deux objets. Il existe d’autres types de clashs : une non continuité, physique ou topologie, ou une distance minimale non respectée entre deux objets sont également des clashs.
94 CHAPITRE 4. L’INGÉNIERIE SYSTÈME ET LA GESTION DES EXIGENCES : ÉLÉMENTSD’APPLICATION
à la réflexion de la structuration du modèle représentatif de l’infrastructure. Elle est liée au flou apporté par l’humain et ses comportements et décisions qui peuvent parfois sortir d’une réflexion rationnelle ou plus simplement technique et fonctionnelle.
De nombreuses questions se posent sur la gestion des exigences. Comment gérer l’hérédité des exigences ? Est-il concrètement possible de lier chaque objet avec les exigences auxquelles il se rapporte ? Est-ce efficient dans la structuration de l’information ? Comment gérer l’hérédité des exigences entre les différentes vues du projet et les décompositions du projet en objets, espaces ou ouvrages fonctionnels (nous verrons le détail de ces trois autres décompositions dans les prochains chapitre) ? Comme déjà évoqué ci-dessus, dans la suite de notre travail, nous n’allons pas nous concentrer sur la manière dont devront être gérées les exigences. Nous allons par contre tenir compte de la nécessaire hiérarchisation des exigences et de l’obligation de les lier à une structuration de l’information du système à faire en cohérence.
Suite à l’analyse ci-dessus de plusieurs outils conceptuels, nous allons maintenant présenter l’ex-ploitation que nous en proposons. Nous expliquons également les adaptations nécessaires pour une exploitation optimale dans notre contexte de projet de construction d’infrastructure. Nous allons tout d’abord décrire comment ces concepts peuvent servir le projet. Nous verrons ensuite que leur utilisa-tion permet de définir les limite du système étudié dans ce travail de thèse ainsi que les éléments qui