La solution logicielle SINERGIE

La solution logicielle SINERGIE

Introduction 

ESCOTA souhaite se doter d’un outil informatique d’aide à la décision pour la gestion et la maintenance du patrimoine. Ce chapitre est consacré aux modèles informatiques de cet outil. Il propose d’une part, la spécification des fonctionnalités qui nous apparaissent comme essentielles pour une aide à la décision pertinente pour assister l’exploitant dans la gestion quotidienne de son patrimoine, d’autre part la structure des données à partager par l’ensemble des acteurs du processus de gestion. Le processus décisionnel impliqué dans la gestion du patrimoine d’ESCOTA, que nous préciserons dans la section 2 de ce chapitre, présente toutes les caractéristiques de la décision en organisation telles que décrites par l’économiste H.A. Simon . Dans le chapitre I, nous avons mentionné à cet égard que si le décideur ne possède que rarement une connaissance totale de la situation, deux causes majeures peuvent être incriminées : d’une part, son incapacité à traiter l’ensemble de tous les flux d’information auxquels il a accès et d’autre part, son enclin naturel pour une représentation simplificatrice monocritère de la situation qui occulte la complexité de la réalité. De façon très résumée, le décideur a donc besoin d’un outil informatique qui lui permette de traiter intelligemment et dynamiquement l’information, en lui proposant en particulier des représentations pertinentes de la situation en adéquation avec ses modes cognitifs. La solution informatique que nous retiendrons s’appuiera donc sur deux grandes approches de la décision : les modèles de type Système de Traitement de l’Information et l’analyse multicritère. Plusieurs études sur la décision en organisation s’accordent ainsi à montrer que le traitement de l’information dans l’organisation est le véritable point clé de la décision en organisation. La gestion du patrimoine à ESCOTA relève de cette catégorie de processus décisionnels. La gestion des opérations est une tâche complexe pour les décideurs qui doivent faire face à une masse d’informations conséquente. Ces derniers ont besoin d’avoir une vision globale du patrimoine en termes d’objectifs et de contraintes, tout en conservant la possibilité de consulter dans le détail l’état d’un élément du patrimoine ou l’évaluation d’une opération à réaliser. L’objectif de notre travail consiste donc à mettre en place un système informatique pour aider l’exploitant à mener une stratégie de gestion durable du patrimoine. Nous verrons dans le chapitre suivant les outils mathématiques qui supportent les fonctionnalités que propose l’outil informatique. Pour l’heure, l’objet de ce chapitre est de construire le modèle de l’outil informatique, support de l’aide à la décision. La section 2 formalise le processus décisionnel de la gestion du patrimoine à ESCOTA et déduit de ce modèle les grandes fonctions à implémenter dans notre logiciel. Le traitement de l’information, son acquisition et son partage sont donc au cœur de la solution que nous proposons. Pour cela, l’outil doit aider à mettre en place une culture de partage de l’information où chaque acteur intervenant dans le processus de gestion du patrimoine, met à la disposition de tous les informations dont il dispose. L’idée est de créer une base de connaissance du patrimoine contenant toutes les informations sur l’état de santé, les décisions prises en termes d’opérations ainsi que les travaux réalisés. Nous décrirons la conception de ce système d’information dans la section 5. Cette base, pour rester pertinente, doit être alimentée et mise à jour par l’ensemble des personnels des Districts et du service Structure Viabilité Sécurité intervenant dans le processus de décision. Le bénéfice de ce travail de partage d’informations réside dans la constitution d’un historique de la gestion du patrimoine. Ainsi, il sera possible d’avoir une vision globale de l’état du patrimoine, de mesurer les effets de la politique de gestion et de la justifier au moyen d’un système d’aide à la décision décrit dans la section 4. Les choix de conception des outils du système d’information et du système d’aide à la décision sont précisés dans la section 3. Enfin, la section 6 analyse la généricité du modèle, notamment sa capacité à intégrer la définition de nouveaux métiers (ou domaines) de gestion de l’infrastructure. Nous étudierons également ces possibilités d’évolution du logiciel. 

Le processus de la décision pour la gestion du patrimoine 

La première étape de notre travail a consisté à formaliser le processus de la décision pour la gestion du patrimoine. Trois étapes ont été mises en évidence dans le processus d’évaluation des opérations au chapitre précédent qui correspondent par ailleurs à trois niveaux fonctionnels bien distincts chez ESCOTA (districts, inspecteurs extérieurs ; conducteurs d’opérations (COP) ou experts métiers (EM) ; responsables de l’exploitation) : • Le suivi du patrimoine ; • L’évaluation de l’état du patrimoine ; • Les décisions. Cette gestion se traduit par une surveillance attentive de l’état de santé et l’entretien en temps opportun, ce qui se traduit par la réalisation d’entretiens, d’amélioration ou de mise à niveau. Nous désignerons pour la suite par opération les entretiens, les améliorations et les mises à niveau. Le patrimoine infrastructure d’ESCOTA se compose d’un ensemble d’éléments de patrimoine EP. Tout élément de patrimoine est rattaché à l’un des cinq domaines d’intervention comme nous l’avons vu dans le chapitre précédent. Nous retrouvons chacune des trois étapes précitées représentées à la Figure 17. La logique de mesure correspondant au suivi du patrimoine est réalisée d’une part par les Districts avec des visites annuelles, d’autre part par des inspecteurs spécialisés. Ils fournissent des comptes rendus d’inspection sur les éléments de patrimoine au Conducteur d’Opération (ou Expert Métier, EM) concerné. Par exemple, pour les Ouvrages d’Art, une méthode normalisée par le SETRA est utilisée pour les visites annuelles et pluriannuelles : la méthode Image de la Qualité des Ouvrages d’Art (IQOA). Ainsi, un ouvrage d’art a un score annuel (ou note) d’état de santé (en vert sur la Figure 17). Les expressions de besoins sont des demandes, exprimées par les Districts, en termes d’opérations non basées sur un bilan de santé. Un exemple d’expression de besoin est la demande de création d’un chemin d’accès pour faciliter l’accès des véhicules de la viabilité hivernale sur l’autoroute pour les personnels des Districts. Dans un deuxième temps, la logique d’évaluation (en noir sur la Figure 17) concerne le passage des bilans de santé à la liste des opérations à réaliser sur les éléments de patrimoine qui en ont besoin. Le Conducteur d’Opération fait une synthèse des bilans de santé. Il peut ainsi élaborer le diagnostic de tout EP qu’il classe en urgence d’intervention U1, U2 ou U3 (Ui est plus urgent que Ui+1 ) à partir de critères relevant d’une analyse de risque technique. Il propose alors des opérations regroupant des EP cotés en niveau d’urgence Ui . Ensuite, le chef de service évalue les urgences qui lui sont proposées en priorité d’intervention P1, P2 ou P3 ( Pi est plus urgent que Pi+1 ) en prenant en compte des critères d’analyse relevant cette fois-ci de la stratégie d’entreprise (risques stratégiques). Il s’agit d’un processus d’évaluation en boucle (cf. cycle noir de la Figure 17) car la survenue d’un nouveau bilan de santé sur un ouvrage d’art, par exemple, pour lequel la note IQOA serait moins alarmante, permet de réévaluer les niveaux d’urgence et de priorité. Cette boucle permet également de prendre en compte la révision d’une évaluation si, après vérification au niveau fonctionnel suivant du processus de planification des opérations, les deux évaluateurs ne s’accordent pas sur la décision à prendre. De même, une mauvaise évolution d’une pathologie peut accroître le niveau d’urgence et/ou de priorité. Sur la base des opérations évaluées en priorité d’intervention, le chef de service propose au directeur de l’exploitation une programmation pluriannuelle. Nous entrons dans la dernière phase du processus (logique de décision) où la validation de cette programmation (i.e., la décision de lancer l’opération par le service Structure Viabilité Sécurité (SVS) ou le Directeur d’Exploitation (DEX) à la Figure 17)  déclenche le processus de rédaction du Dossier d’Opération, du Dossier de Consultation des Entreprises, puis la réalisation des travaux pilotés par le COP (cf. en rouge Figure 17). Figure 17 : schéma fonctionnel du processus décisionnel de la gestion du patrimoine d’ESCOTA La description que nous venons de faire du processus décisionnel, qui part de la mesure de symptômes jusqu’à la planification d’opérations dans un plan pluriannuel chez ESCOTA, nécessite une adéquation entre les informations pertinentes disponibles au bon moment et les représentations propres à chaque niveau fonctionnel de l’exploitation pour que le processus se déroule correctement. La solution que nous proposons résulte donc du couplage entre un Système d’Information SI et un outil d’Aide à la Décision basé sur une évaluation multicritère hiérarchique et capable de justifier ses conclusions depuis la base de connaissances du SI (cf. Figure 18) : • Un Système d’Information (SI) pour stocker les informations et partager les connaissances. Ce SI doit être capable de gérer toutes les informations utiles aux évaluations des opérations et est destiné à devenir la mémoire de la gestion du patrimoine à ESCOTA ; • Un Système Interactif d’Aide à la Décision (SIAD) pour aider les décideurs dans la façon dont ils utilisent leur capacité de raisonnement et de traitement de l’information dans les phases d’évaluation et de justification. La Figure 18 ci-dessus schématise le fonctionnement de ce couplage en mettant en évidence la participation de tous les acteurs (Districts, COP et chef de service SVS) dans le partage et la mise à disposition des informations de la gestion du patrimoine. Le SIAD, via un contrôle des droits d’accès des utilisateurs, assure la communication et propose les interfaces adéquates aux utilisateurs afin de : • enregistrer et capitaliser l’information (en noir sur la Figure 18) : les Districts enregistrent les bilans de santé, les anomalies et entretiens courants, ainsi que le contrôle de la réalisation des travaux des opérations. Le COP (resp. le chef de service SVS) dispose d’interfaces pour enregistrer les évaluations en urgence (resp. en priorité d’intervention); • consulter et avoir une vision globale du patrimoine : l’information contenue dans le SI est récupérée par le SIAD et restituée notamment sous la forme de tableaux de bord pour le suivi des bilans de santé, des évaluations en urgence et en priorité. La fiabilité de ce fonctionnement repose sur la base de la collaboration de tous les acteurs dans l’enregistrement et la mise à disposition des informations dont ils disposent pour améliorer la connaissance et le suivi de l’état du patrimoine. L’outil informatique qui doit supporter la gestion du patrimoine à ESCOTA a été baptisé SINERGIE pour Système INteractif d’Evaluation pour le Renouvellement et la Gestion de l’Infrastructure  d’ESCOTA. Ce projet doit induire une évolution significative dans le fonctionnement de la gestion du patrimoine via la formalisation du processus décisionnel qu’il instrumente et le partage des informations qu’il gère. La première étape consiste à structurer les données dans le Système d’Information. Ensuite, il faut développer les fonctions de traitement des données, les Interfaces Homme Machine (IHM) permettant la mise en forme, la consultation et le suivi des données proposées par le SIAD. La description précédente du processus de décision chez ESCOTA a mis en avant les besoins informationnels et les tâches à réaliser à chaque niveau fonctionnel de l’exploitation. Il nous est donc maintenant possible de lister les fonctions principales attendues de SINERGIE. Les fonctions d’administration L’administrateur du système n’est pas un acteur dans la gestion du patrimoine, mais il est le garant du fonctionnement du logiciel SINERGIE. Il initialise l’application, c’est-à-dire qu’il enregistre les données nécessaires au fonctionnement de l’outil : la définition du réseau autoroutier et des éléments de patrimoine. Il assure la gestion des utilisateurs : création (resp. modification) d’un utilisateur District, COP et Chef de service SVS. Il enregistre également les données définissant l’environnement du réseau comme les données de trafic et de zones d’accumulations d’accidents (zaa). Ces données sont disponibles au service EIT (Études et Ingénierie du Trafic) à ESCOTA, où elles sont mises à jour annuellement. Le format de ces données est défini à EIT, l’administrateur dispose donc des fonctions d’insertion automatique de ces données dans le SI. Les fonctions d’enregistrement / consultation La surveillance du patrimoine est possible en consultant les informations relatives à tout élément de patrimoine : sa définition, sa localisation, les caractéristiques environnementales disponibles, les derniers bilans de santé, les anomalies, les entretiens courants réalisés et les derniers travaux le concernant. Pour chaque type de données nécessaires à la surveillance du patrimoine correspondent des fonctions d’enregistrement et de consultation. La consultation dépend de la disponibilité des informations lesquelles doivent avoir été au préalable enregistrées dans le SI. Ainsi, les Districts renseignent des fiches pour les anomalies, les entretiens courants et la réalisation des travaux. Les bilans de santé sont enregistrés par le COP dans le cas des chaussées (dont le protocole est défini en Annexe 4). Dans le cas des Ouvrages d’Art, les bilans de santé sont contenus dans d’autres outils, comme l’outil de gestion des ouvrages OASIS (cf. Figure 18) et dans ce cas, SINERGIE se connecte à cet outil pour récupérer et afficher les informations demandées. Nous avons vu, au paragraphe précédent, que les informations de zaa et de trafic sont mises à jour annuellement par l’administrateur du système et consultables par tous les utilisateurs. Nous avons là une vision sur les informations disponibles en cours. Pour répondre au besoin de capitalisation et d’historique évoqués précédemment, il doit également être possible de faire une recherche sur ces mêmes informations (bilans de santé, anomalies, …) relativement à des années précédentes afin d’évaluer l’évolution de l’état du patrimoine. Par exemple, pour une chaussée où l’on constate des fissures, la consultation de bilans de santé sur l’année précédente permet de juger de l’évolution de l’ouverture de ses fissures. Les évaluations L’approche multicritère de l’évaluation en urgence et priorité d’intervention permet de décomposer le processus décisionnel relatif à la gestion du patrimoine en fonction des informations disponibles à chaque niveau fonctionnel de l’exploitation. Pour toute opération à réaliser sur un ou plusieurs éléments de patrimoine, le Conducteur d’Opération créé l’opération, rentre les éléments de patrimoine concernés par cette opération. Ainsi, pour chaque opération, il est possible de consulter sa nature, ainsi que les éléments de patrimoine concernés. Les EP (concernés par une opération) doivent ensuite être évalués en urgence selon les critères propres au COP, puis en priorité d’intervention selon les critères du chef de service SVS. Lorsque les scores partiels de chaque opération ont été affectés, SINERGIE calcule le niveau global de l’urgence et de la priorité de l’opération. A cet effet, SINERGIE a recours à l’agrégation multicritère : des Chapitre II – 48 – opérateurs d’agrégation ont été définis au préalable dans le logiciel, ils permettent de passer d’un ensemble de scores partiels relatifs aux critères d’évaluation à une note de synthèse en urgence ou priorité. Ainsi, le COP (resp. le chef de service SVS) dispose bien sûr d’interfaces pour définir l’opérateur d’agrégation qui sied le mieux à son comportement décisionnel, mais SINERGIE lui propose également un support logiciel pour l’accompagner dans cette démarche d’identification et de définition de son modèle décisionnel. L’évaluation multicritère d’un élément de patrimoine en urgence (resp. en priorité) repose sur l’agrégation des scores partiels relativement aux critères d’évaluation ; la fonction d’évaluation permet d’enregistrer les scores attribués selon chaque critère et attribue un score global à chaque EP de l’opération. Il est ensuite possible de consulter toute évaluation en récupérant dans le SI la liste des couples critères / scores et recalculer le score global. Le suivi sous la forme d’un tableau récapitulatif (comme cela est proposé à la Figure 18) permet de superviser l’ensemble des opérations en cours avec leur score de synthèse. Les fonctions d’analyse Toute évaluation en urgence (resp. en priorité) enregistrée dans le SI comprend un ensemble de scores et de commentaires associés relativement à chaque critère d’évaluation. Deux fonctions sont essentielles pour l’analyse des évaluations effectuées par les Conducteurs d’Opération et le chef de service SVS : la justification et le contrôle d’erreurs d’évaluation. La première concerne la capacité du système à expliquer quels sont les critères qui ont joué un rôle dans l’affectation du score global de l’opération et l’expliquer grâce à un argumentaire (les commentaires) enregistré lors des évaluations. Cette fonction est la justification : elle permet, à partir d’une note de synthèse, de remonter dans un premier temps aux critères qui ont été déterminants dans l’affectation de ce score, puis dans un second temps de restituer les commentaires textuels associés à ces critères discriminants lorsqu’ils ont été renseignés par le COP (resp. le Chef de Service SVS). Cette fonction constitue le support informatique nécessaire à la construction de l’argumentaire visant à justifier la décision prise par le COP et le Chef de Service quant à la date de programmation de l’opération concernée. Nous détaillerons cette fonction dans la section 4 du chapitre III. La seconde est une analyse de sensibilité consistant à évaluer la fiabilité d’une évaluation en urgence (resp. en priorité) et à en donner les causes d’erreurs les plus probables, i.e. les critères pour lesquels une erreur d’estimation partielle conduit le plus probablement à une erreur d’évaluation en urgence (resp. en priorité). SINERGIE propose deux fonctions de contrôle des erreurs d’évaluation, qui permettent d’estimer les risques d’erreurs a priori et a posteriori et que nous développerons dans la section 5 du chapitre III. L’aide à la planification Enfin, pour chaque opération, les conducteurs d’opération proposent une programmation pluriannuelle en fonction des évaluations en urgence des opérations. En effet, il propose pour chaque EP évalué en urgence un échéancier sur plusieurs années avec le montant des dépenses prévues pour chaque année. Nous avons mis en place une fonction qui permet de contrôler la validité de cette proposition de planification. Ce contrôle systématique proposé par SINERGIE s’appuie sur un ensemble de règles d’exploitation et un test de cohérence entre les interprétations du COP et du Chef de Service pour une opération donnée. Nous avons évoqué précédemment la nécessité de proposer une aide à la planification pertinente dont le processus de construction repose sur l’ensemble des acteurs de la gestion du patrimoine. C’est ce que nous nous proposons de faire en basant notre fonctionnalité d’aide à la planification sur la cohérence des évaluations en urgence Ui et en priorité Pj qui constituent l’aboutissement de toute la chaîne de traitement de l’information assistée par SINERGIE. La planification, qui n’a pas de support mathématique particulier, sera détaillée dans la sous-section aide à la planification du dernier chapitre. Dans un premier temps, l’outil est déployé pour les Chaussées pour ensuite être étendu aux autres métiers du service SVS. La conception de SINERGIE doit donc prévoir l’intégration de nouveaux domaines de gestion du patrimoine. 

Les choix de conception

 On distingue deux approches distinctes pour la conception de systèmes [Gabay, 05]. L’approche dite classique comprend de nombreuses variantes axées sur les techniques utilisées pour développer des systèmes d’information. L’une des méthodes dite classique les plus utilisées est la méthode Merise. Merise se positionne comme une méthode de conception de Système d’Information organisationnel, plus tournée vers la compréhension et la formalisation des besoins du métier que vers la réalisation de logiciel. Cette méthode reste un classique en tant que méthode de conception des Systèmes d’Information et propose une démarche méthodologique de développement. De notre point de vue, sur la seule partie des formalismes, Merise est adaptée à la modélisation des données en vue de la construction d’une base de données relationnelle. Merise se réclame plus de l’ingénierie du Système d’Information métier que du génie logiciel. Depuis quelques années, l’approche orientée objet est de plus en plus utilisée, car elle permet de considérer le système d’information comme une collection d’objets interdépendants qui fonctionnent ensemble pour exécuter des tâches. Un objet est vu comme un élément du système qui peut répondre à des messages. L’idée de l’approche objet est dans un premier temps de définir tous les objets qui travaillent ensemble dans le système. Ensuite, il s’agit de montrer comment ils interagissent entre eux pour exécuter des tâches. Le langage UML (Unified Modelling Language) s’est imposé comme standard à utiliser en tant que langage de modélisation objet. UML, de par son origine (la programmation objet) s’affirme comme un ensemble de formalismes pour la conception de logiciel. C’est la méthode idéale pour concevoir et déployer une architecture logicielle développée dans un langage objet (Java, C++, VB.net). Aujourd’hui, le courant objet est une réalité incontournable dans le monde des méthodes de conception et de développement des Systèmes d’Information. Toutefois, la modélisation des données via le formalisme « Entité Relation » de Merise est plus sophistiquée que le modèle de classe d’UML et garantit une plus grande fiabilité lors du passage au modèle logique et physique de la base de données. De nombreux systèmes développés aujourd’hui combinent les technologies classiques et orientées objets [Satzinger, 04], nous nous proposons donc d’utiliser ces deux méthodes de manière complémentaire. Dans un premier temps, notre analyse UML va nous permettre de poser de manière claire à quels besoins doit répondre SINERGIE, comment le système devra se comporter et structurer l’architecture logicielle. Ensuite, l’analyse Merise sera plus facile, notamment grâce au travail de modélisation général fait avec UML pour modéliser le Système d’Information.