SYSTÈME D INFORMATION POUR LA GESTION DES ROUTES ET DU TRAFIC JUILLET 2010

SYSTÈME D INFORMATION POUR LA GESTION DES ROUTES ET DU TRAFIC JUILLET 2010 Département de l Environnement, des Transports, de l Energie et de la Communication - DETEC OFROU

E DITORIAL E Chères lectrices, chers lecteurs, L édition N 8 est une édition particulière. Elle ne traite que de deux sujets: l introduction de MISTRA dans les cantons et, en particulier le «Rollout» de l application Accident de la circulation, ainsi que l application Ouvrages d art et tunnels (KUBA). Dans l article, vous trouverez une description détaillée des fonctionnalités existantes de la version 4 de KUBA ainsi que les nouveautés de KUBA 5. Cette dernière est actuellement en phase de développement. Les travaux pour les autres applications ne sont pas au point mort. Avec de nouvelles applications ou versions qui ont été mises en services depuis novembre 2009 la direction générale du projet MISTRA a atteint ses objectifs. Pour plus d informations, veuillez lire l article «Aperçu du système global». Des travaux préparatoires sont nécessaires pour l introduction de MISTRA. Les conventions cadres, les contrats de services agréés (service level agreement) doivent être rédigés et négociés avec les exploitants et les futurs utilisateurs. Il est temps d agir, l introduction de MISTRA à l OFROU l a bien démontré. Dans ce contexte, l OFROU a réorganisé les domaines «Informatique centrale» et «MISTRA+VMON». Dès le 1er avril 2010 les domaines «Informatique stratégique» et «Management d intégration de l informatique» sont opérationnels. L Informa - tique stratégique est responsable de la planification, la réalisation et l introduction d applications, parmi lesquels figure le programme MISTRA (programme = ensemble de plusieurs logiciels et projets informatiques). Le management d intégration de l informatique (IMI) s occupe entre autre de l introduction de logiciels standards, de la gestion des données, du helpdesk (ou service desk) ainsi que de la gestion des utilisateurs. Toutes des tâches essentielles pour une mise en place et l exploitation avec succès. Bonne lecture. TABLE DES MATIÈRES Aperçu du système global 2 Rollout Accidents de la circulation 4 Introduction dans les cantons 6 Chaussée 8 Ouvrages d art et tunnels 9 Contacts 15 Christoph Käser Directeur général du projet MISTRA IMPRESSUM Rédaction: Jean-Pierre Bolli, GS MISTRA Parution 2 x par année Conception et réalisation: GDesign & communication, Lutry Edition: 300 ex. en allemand - 150 ex. en français 1

A PERÇU DU SYSTÈME GLOBAL Auteur: Jean-Pierre Bolli En complément au guide pour l introduction de MISTRA dans le canton et au «Rollout de VU» (Accidents de la circulation), cet article vous présente un bref résumé de l état du projet MISTRA et des applications. Résumé Neuf applications sont en exploitation à l OFROU: Inventaire des voies historiques de communication suisse (IVS) Système de base (BS) Data Warehouse (DWH) Ouvrages d art (KUBA 4) Monitorage du trafic (VMON) Accidents de la circulation (VU) Gestion des biens-fonds et des contrats (LVS) Autorisations spéciales, solution temporaire (SB) Cadastre du bruit, solution temporaire (LBK) Système de base La version actuelle du système de base est en service depuis mars 2010. Seuls les utilisateurs de l OFROU y ont accès. Les améliorations essentielles ont déjà été décrites dans l édition 7: Performance augmentée Recherche d objet simplifiée Fonctionalités d impression améliorées Les premières réactions spontanées des utilisateurs étaient très positives. Le système de base est prêt pour une introduction à grande échelle au niveau de l office et les premiers cours de formation sont prévus ce mois. L amélioration de la performance grâce aux cartes pré-calculées (cache WMS) a permis d augmenter sensiblement l acceptation auprès des utilisateurs. Les cartes de fonds d écran ne sont plus directement reprises de swisstopo. Les images sont pré-calculées et mises à disposition du système de base. Le «cache WMS» est également à disposition d autres applications. La prochaine version (RE 2.0) prévue en automne 2010 contient les nouveautés suivantes: Historisation des objets de l inventaire Interfaces avec KUBA et TDcost Etiquettes des objets de l inventaire Gestion des chantiers améliorée Au printemps 2011 déjà, une nouvelle version (RE 2.1) suivra. La gestion des axes, en particulier l actualisation des axes et les répercussions sur les applications, y sera traitée. L intégration des données se poursuit en parallèle au développement des nouvelles versions. A fin avril 2010, tous les axes des routes nationales et cantonales pour toute la Suisse et les autres routes pour une dizaine de cantons sont disponibles (BE, BL, FR, GE, GL, GR, LU, NW, OW, SZ, TG, VD, VS, ZG). L intégration de la totalité des axes est prévue en automne 2010. Ces axes sont la base pour la saisie des accidents de la circulation. L intégration des axes cantons par cantons est coordonnée avec l introduction de l application «Accidents de la circulation» (Rollout VU). Fig. 1: Extrait de carte avec des axes routiers En plus des axes routiers, différents réseaux métiers et surfaciques sont en préparation et introduction. Les réseaux métiers n existent encore que pour les routes nationales parce que le réseau des autres routes (cantonales et communales) n est pas encore complété. Des exemples pour des réseaux sont: Carte des risques et l indice des risques Catégorisation du réseau (types de routes selon VSS) Taux d accidents TJM Data Warehouse (DWH) Le Data Warehouse a trois modules: Monitorage du trafic (VMON) Accidents de la circulation (VU) Registre des conducteurs et des véhicules (FFR) L échange des données entre l application VMON et le DWH a été amélioré et automatisé. Les données des compteurs automatiques de la Confédération (AVZ) sont transmises en continu directement dans le DWH. Le module VU est avec le module de saisie un élément important pour l introduction de VU dans les polices cantonales (Rollout VU) parce qu il permet l exploitation statistique des accidents. Les données des accidents des différents cantons sont intégrées continuellement dans le DWH et coordonnées avec l introduction dans les polices concernées. La partie FFR contient les registres FABER (permis de conduire), MOFIS (informations sur les véhicules) et ADMAS (mesures administratives). Monitorage du trafic Les activités pour l unité de réalisation 2 (RE 2) ont été suspendues en faveur des travaux d optimisation de la performance. Le concept de la RE 2 est achevé et doit être passé en revue par les différents cantons pilotes. La RE 2 comprend principalement la gestion des compteurs mobiles et l algorithme d extrapolation des valeurs. Les travaux de développement commenceront après ceux pour l amélioration de la performance. Cette année l objectif est clairement l augmentation de la performance. Toutes les possibilités seront analysées et implémentées d ici fin 2010. 2

Accidents de la circulation Il faut plusieurs outils ou modules pour la saisie et l exploitation des données d accident: Module pour la saisie: L application VU offre plusieurs possibilités pour la saisie: saisie manuelle, saisie avec le DPS (digital pen) ou encore la reconnaissance de texte du protocole de saisie via scanner. L application VU est ectuellement en introduction dans les polices cantonales (voir Rollout VU). Exploitations statistiques (voir Data Warehouse) Exploitations SIG: L application VUGIS permettra l exploitation graphique et géographique des données d accidents. Le module est en développement et sera disponible à la fin de l année 2010. Cadastre du bruit (solution temporaire) La solution temporaire pour le cadastre du bruit des routes nationales est en service depuis mars 2010. La gestion des données est décentralisée. Les bureaux mandatés auront une installation locale du cadastre du bruit qui leur permet d apporter les preuves de mise en conformité par rapport au bruit. Les données sont intégrées et archivées dans la base de données centrale à l OFROU, une fois le projet terminé. Elles sont ainsi à disposition des spécialistes des filiales et de la centrale. Fig. 2: Prototype pour l exploitation géographique des accidents Fig. 3: Interface utilisateur de la solution temporaire du cadastre des bruits Gestion des bien-fonds et des contrats L application est en service depuis deux ans. Les contrats relatifs à l utilisation et la gestion des parcelles de l autoroute sont tous saisis. Les mutations des données des parcelles dans les registres fonciers sont en cours. Les clarifications du périmètre de l autoroute, notamment dans les rampes et bretelles, sont également en cours. L application est un logiciel standard adapté pour les besoins de l OFROU. Elle peut être mise à disposition des cantons souhaitant gérer leurs contrats et parcelles en relation avec les routes. Autorisations spéciales (solution temporaire) La solution temporaire pour la gestion administrative des autorisations spéciales est en service depuis deux ans. Elle est utilisée par les spécialistes du centre d intervention du Gothard pour toutes les demandes sur le réseau des routes nationales en Suisse. Environ 150 demandes sont traitées quotidiennement. Depuis décembre 2009 le portail internet est disponible pour la saisie des demandes (application en ligne). Les entreprises de transport ont ainsi la possibilité de soumettre leurs demandes via internet. Elles sont transférées automatiquement dans l application BEAT et peuvent être traitées par les spécialistes. L autorisation est également mise à disposition du requérant via internet. Les demandes d autorisation saisies peuvent être gérées dans l application en ligne (sauvegarder, copier, modifier). Depuis la mise en service de l application en ligne, environ 80% des demandes ont été soumises par ce biais. Gestion de l entretien en site urbain Le concept informatique est terminé. Les résultats des tests in situ ont été intégrés (comparaison des données géographiques du TLM swisstopo avec celles de Tele Atlas). En parallèle, des questions organisationnelles ont été analysées afin de mettre sur pied une organisation qui assure l exploitation et le support pour les utilisateurs. Une collaboration entre la société «Infrastructure communale», la VSS et l OFROU est prévue pour ces activités. La société «Infrastructure communale» devrait également assurer le financement du support des utilisateurs et la promotion de l application. La réalisation sera mise en soumission cette année. L adjudication devrait encore se faire en 2010. La mise en service est prévue en 2014. Mobilité douce Le concept est en phase d achèvement. Une enquête menée auprès des cantons a relevé l intérêt général des cantons pour une telle application. La mise en service est prévue en 2014. Equipement Management System Le concept métier est en achèvement. Ce dernier décrit les processus métiers pour la gestion des équipements d exploitation et de sécurité. Les prochaines étapes sont l établissement de l analyse préliminaire et le concept informatique. La mise en service est prévue en 2014. 3

R OLLOUT APPLICATION MÉTIER (ACCIDENTS DE LA CIRCULATION) Auteur: S. Kiener Le Rollout de l application métier Accidents de la circulation routière (VU) suit sont cours avec l entrée en production successive des cantons qui saisissent leurs données d accidents dans VU. L OFROU a pour objectif une utilisation de VU dans les 26 cantons dès le 1.1.2011. Etat actuel (avril 2010) Depuis novembre 2009 resp. début 2010, les polices cantonales bernoise, thurgovienne et vaudoise saisissent leurs données d accidents au moyen de l application métier Accidents de la circulation routière (VU). Plusieurs méthodes de saisie sont disponibles. Berne utilise la méthode du scanning, Thurgovie travaille avec le Digital Pen (DPS) et Vaud effectue une saisie manuelle des données d accidents. En plus des cantons pilotes susmentionnés, les polices cantonales d Appenzell Rhodes intérieur, de Bâle Campagne et des Grisons ont également commencé à travailler avec VU. Interview des utilisateurs de VU Ci-dessous: Daniel Fuchs (Berne) Martin Rabensteiner (Thurgovie) Roger Reymond (Vaud) vous font part de leurs premières expériences de l utilisation productive de l application métier VU. Les interviews complètes des trois utilisateurs sont disponibles dans le domaine sécurisé sur le site internet de l OFROU. Si vous souhaitez les lire, veuillez prendre contact avec le secteur sécurité par E-Mail. Quelles sont vos premières expériences au niveau du travail quotidien avec VU en lien avec l ergonomie de l application? Daniel Fuchs: L interface est très bien pensée et conviviale. L application, qui est très intuitive, a rapidement été acceptée par mes collaborateurs. Martin Rabensteiner: L interface utilisateur est conviviale et parfaitement adaptée aux travaux des policiers sur le terrain. Grâce à l utilisation du DPS, il est pour la première fois possible de prendre des notes sur place, ce qui satisfait d ores et déjà les besoins du nouveau code de procédure pénale suisse. Roger Reymond: Cette nouvelle application VU nous donne entière satisfaction. Sa présentation est claire, conviviale, facile d utilisation et attractive. Les nouveautés apportées concernant le géoréférencement, la plausibilité ainsi que la possibilité de compléter les champs sur les personnes et les véhicules avec les données correspondantes des véhicules à moteur (MOFIS) et du registre des conducteurs (FABER) de l OFROU, sont une innovation importante. Comment jugez-vous la charge de travail nécessaire à la saisie d un accident? Daniel Fuchs: Le scanner permet la lecture de l accident. Le traitement par étapes est un grand avantage, car il permet de scanner plusieurs accidents en une seule fois. La charge de travail a été réduite. Toutefois, la vérification des données scannées nécessite un certain temps. Dans l application VU, la charge de travail est faible. Martin Rabensteiner: Le temps nécessaire à la saisie d un accident a encore été réduit avec le DPS grâce à la reconnaissance de texte qui élimine en partie la fastidieuse dactylographie. Roger Reymond: Pour la saisie d un accident, mode manuel pour Vaud, il faut compter 6 à 8 minutes pour un accident seul en cause. Sur la totalité des accidents vaudois enregistrés par notre bureau (environ 4000), nous pouvons calculer une moyenne de 15 minutes par accident. Cela représente une importante charge de travail supplémentaire par rapport à notre ancien système. Toutefois, il faut quelque peu relativiser puisque les données demandées sont plus nombreuses et plus complètes. En outre, les contrôles de qualité - géoréférencement et plausibilité - prennent du temps. La priorité a été de faire gagner du temps au niveau du personnel de terrain, ce que nous avons réussi à faire. Daniel Fuchs (Analyse et statistique des accidents, Police cantonale Berne) Martin Rabensteiner (Chef de groupe du service ordre et sécurité, Police cantonale Thurgovie) Roger Reymond (Chef du bureau des statistiques & archives circulation, Police cantonale Vaud) 4

Etes-vous satisfait de VU? Daniel Fuchs: Je suis très content de VU. On a créé une application qui est très orientée vers la pratique. Martin Rabensteiner: Nous sommes très contents de la solution web de saisie des accidents qui satisfait à nos exigences et couvre pleinement nos besoins. L étroite collaboration entre la direction de projet, les développeurs, les statisticiens et les utilisateurs de base est une contribution essentielle à la réussite de ce projet. La saisie des données avec VU vous apporte-t-elle des améliorations par rapport à votre ancien système? Daniel Fuchs: Oui, comme tous les cantons saisissent leurs accidents avec VU, l homogénéité et la qualité des données sera améliorée. Ceci est naturellement un grand progrès. Roger Reymond: La saisie des données avec VU apporte des améliorations certaines par rapport à notre ancien système. Pour nous, la grande différence sera dans la recherche et la comparaison d accidents. Notre ancien programme n autorisait que deux critères de recherches, ce qui nous limitait sérieusement. Dans l ensemble, je suis satisfait de l application VU. Ce programme répond en tous points à nos attentes. Comment jugez-vous le fonctionnement (stabilité, performance) et le soutien/support (Helpdesk)? Martin Rabensteiner: Le fonctionnement du système dépend fortement des systèmes informatiques de chaque corps de police. De notre côté, la performance de VU est optimale et aucun problème de stabilité n a été relevé. Le Helpdesk est un nouvel outil pour nous auquel il faut s habituer. Cependant, il est très pratique, car il permet de voir et de suivre l état des problèmes. Nos expériences avec le Helpdesk sont très positives. Roger Reymond: La stabilité et le fonctionnement de l application VU donnent entière satisfaction. En cas de problèmes, je dois dire que le soutien, tant par le personnel de l OFROU que par le «Helpdesk», a été d une excellente qualité. A plusieurs reprises j ai fait appel à ces instances et la réponse a toujours été claire, rapide, soit dans la journée ou le lendemain Responsables et participants Direction de projet: Mathias Baudenbacher, OFROU Anja Simma, OFROU Réalisation et maintenance: IMS AG avec geo7 et GEOCOM comme sous-traitants Direction de la maintenance: ELCA AG Rollout: couniq consulting GmbH Cantons pilotes: BE, GR, TG, VD Groupe d accompagnement: Cantons pilotes, secteur Sécurité Fig. 5: L interface utilisateur et les masques de saisie de VU sont clairs et intuitifs (extrait) 5

I NTRODUCTION DANS LES CANTONS Activités Auteur: J.-P. Bolli L introduction de MISTRA dans les cantons nécessite une phase de préparation. Un guide a été établi afin de soutenir les cantons dans ces démarches. Il décrit les activités à prévoir. Les annexes au guide contiennent des éléments complémentaires tels que check-listes et informations complémentaires pour l introduction. Le présent article résume les activités principales du guide pour l introduction. Situation initiale Les outils existants de gestion des données routières et du trafic seront remplacés avec l introduction de MISTRA. Ceci implique non seulement un nouveau logiciel à utiliser mais également des changements dans le déroulement du travail et parfois des responsabilités. L introduction de MISTRA doit donc être planifiée rigoureusement. Toutes les questions organisationnelles, professionnelles et techniques doivent être clarifiées. Le guide pour l introduction de MISTRA dans les cantons décrit les activités à entreprendre à l exception de celles pour l introduction de l application métier «Accidents de la circulation» (voir Rollout VU). Les propositions de mesures organisationnelles et pour l exploitation mentionnées dans le guide doivent être vérifiées par chaque canton et mise en place le cas échéant. Les résultats de l enquête menée en 2006 donnaient un grand nombre de cantons favorables à une installation centralisée de MISTRA. Fig. 7: Diagramme d activités pour l introduction Fig. 6: Déclaration d intention des cantons pour une installation centralisée de MISTRA Basé sur cette enquête, des priorités pour l introduction de MISTRA dans les cantons ont été fixées par l OFROU: 1 ère priorité: les cantons STRADA qui sont prêts à utiliser l installation centralisée de MISTRA. 2 e priorité: les cantons non-strada qui sont prêts à utiliser l installation centralisée de MISTRA. 3 e priorité: les cantons STRADA qui veulent utiliser une installation décentralisée (locale) de MISTRA. 4 e priorité: tous les autres cantons. Initialisation L objectif de l initialisation est la mise en place de l organisation de projet ainsi que la définition des paquets de travail et le déroulement du projet. Définition des besoins S il n existe pas encore une analyse structurée des besoins, celle-ci doit être établie par le canton. L analyse doit répondre aux questions suivantes: Pour quels processus métier MISTRA sera utilisé? Quelles applications vont être remplacées par MISTRA? Des exigences spécifiques doivent-elles être fixées à MISTRA? Quelles interfaces vers des applications tierces faut-il prévoir? Les processus d affaires concernés et les unités organisationnelles touchées par l introduction sont à identifier et à adapter le cas échéant. En plus des processus, les exigences concernant l infrastructure informatique doivent être prises en compte. La recherche de solution marque la fin de ces activités. Les différentes solutions techniques et organisationnelles sont comparées les unes avec les autres. 6

Concept détaillé La meilleure variante identifiée préalablement dans la comparaison sera affinée dans un concept détaillé. Celui-ci décrit l intégration de MISTRA dans l infrastructure informatique cantonale, et en particulier: l architecture du système les interfaces avec les applications tierces la configuration spécifique des applications MISTRA pour les besoins cantonaux toute extension ou adaptation nécessaire des applications de MIS- TRA ou d applications tierces. Concept d introduction et d exploitation Le concept d introduction définit comment MISTRA sera mis en service et développe tous les aspects de la migration des données. Il traite notamment les aspects métier, techniques et organisationnels. La formation fait partie du concept d introduction et d exploitation. L OFROU établira un concept de formation dans lequel l offre de formation est décrite. La formation est basée sur des modules et peut être adaptée aux besoins spécifiques des utilisateurs et des rôles. Les coûts de formation sont à la charge des cantons. La formation pour des applications spécifiques du canton et des interfaces concernés doit également être assumée par le canton luimême. Convention avec l OFROU Une convention cadre doit être conclue entre l OFROU et chaque canton pour l utilisation de MISTRA. Elle règle les droits et obligations de chaque partenaire. Les premières démarches sont à entreprendre dès le début du projet. L objectif est de pouvoir signer la convention avant l introduction du système dans les cantons. Un contrat de service (Service Level Agreement) est rédigé et signé pour chaque application choisie par le canton. Ils se réfèrent à la convention cadre. Cette dernière concerne le système de base et le Data Warehouse. Le système de base et le Data Warehouse représentent les applications «minimales» à introduire. En effet, le système de base met à disposition les données de base (axes, réseaux), alors que le Data Warehouse est l outil principal d exploitation des données (voir également Rollout VU); sans ses components de base, les applications ne peuvent fonctionner que partiellement. Introduction L introduction consiste dans l exécution des activités décrites préalablement dans le concept, notamment: la configuration spécifique des applications MISTRA et tierces la migration des données la réalisation de la formation la mise en exploitation des applications l arrêt des systèmes remplacés L archivage des données non migrées clôt la phase de l introduction. Rôles Le rôle le plus important pendant la phase de l introduction et plus tard pour l exécution est celui du responsable MISTRA. Il est l interlocuteur unique pour l OFROU. Toutes les activités et adaptations demandées par le canton doivent être consolidées et transmises à l OFROU par le responsable MISTRA. Il doit, le cas échéant, pouvoir agir sur délégation de plusieurs départements. Les autres rôles sont à définir en fonction des applications et des activités. Certains rôles sont déjà définis par les applications (p.ex. VU). Les rôles spécifiques pour l introduction sont proposés dans le guide: Chef de projet pour l introduction (responsable MISTRA) Responsable du domaine métier: Il est en charge de l accompagnement de l introduction spécifique au métier (appréciation des conséquences sur les processus d affaires ainsi que la détermination des données spécialisées par métier et la réalisation de leur migration). Responsable IT: Responsable de l architecture de solution et de l intégration dans l environnement existant (configuration). Configuration MISTRA: Administrateur du système MISTRA pour la configuration des adaptations spécifiques au canton. Formation: Responsable de l organisation et de la réalisation de la formation. Responsable Qualité: Assurance qualité du processus d introduction. Responsable en particulier de la préparation et de l accompagnement des tests. Les rôles sont une proposition établie par l OFROU et doivent être adaptés en fonction des spécificités dans un canton. Les rôles suivants sont à assigner pour la phase d exploitation: Responsable de l application Help Desk Power User / Super User Délais La durée de la phase préparatoire est estimée à 6 mois. La durée pour l introduction varie entre 2 mois et une année, en fonction du nombre d applications à introduire, de la disponibilité de ces derniers, de la complexité de la migration des données et de l intégration dans l environnement cantonal ainsi que de la formation des utilisateurs. L introduction peut se dérouler par étapes et selon les besoins du canton. C est-à-dire qu il est possible de n introduire au début que le système de base et le DWH avec une application métier (p.ex. VU) et une année plus tard d introduire d autres applications (p.ex. KUBA 5 et TRA). Coûts Les coûts dépendent également de la complexité de l introduction et de la migration des données. Les estimations s élèvent entre 75 à 220 jours de travail pour l introduction et entre 10 à 30 jours pour la formation. Les prestations pour l introduction peuvent être effectuées par le canton lui-même ou être mandatées. 7

C HAUSSÉE Auteurs: L. Seiler und J. Bodenmann En raison de problèmes constatés en novembre 2009, juste avant le début des tests de réception, la première étape de l application métier Chaussée (TRA) n a pas pu être mise en service selon le planning prévu. Etapes TRA La réalisation de TRA a été décomposée en deux étapes: L étape 1 (STR) sert à gérer des données de l espace routier et offre des possibilités pour leur visualisation et leur exploitation selon des points de vue variés. L étape 2 (PMS) comprend l évaluation fonctionnelle et structurelle d un réseau routier et permet sa décomposition en objets d entretien comme base pour la planification des mesures d entretien. Situation à l automne 2009 Les fonctionnalités offertes par l étape 1 ont été présentées en détail dans la dernière édition des MISTRA News. Les réactions à la suite de la dé - monstration effectuée dans le cadre de la journée VSS tenue à Olten en novembre 2009 étaient positives. L ensemble des personnes impliquées étaient convaincues que la conclusion de l étape 1 était proche et que TRA pourrait être mis en production à l OFROU début 2010. Toutefois, des problèmes inattendus concernant la visualisation et le traitement de grande quantité de données sont apparus au cours de tests préliminaires de réception. Il s est avéré que certains cas d utilisation ne pouvaient pas être utilisés et que le système était insuffisant en termes de performance et de stabilité lorsqu il avait affaire à de forts volumes de données. La mise en service ne pouvait dès lors pas avoir lieu selon les prévisions. Volume de données L application TRA contient divers types de données routières. Parmi cellesci, l état des chaussées correspond à un volume de données considérable: le relevé et la représentation d une seule caractéristique d état (par exemple la planéité transversale, indice I3) sur l ensemble des routes nationales nécessitent l utilisation de quelque 60 000 données informatiques. La base de données de TRA contient les relevés d état effectués depuis 2000, ce qui correspond à près d un million de données. La campagne de relevés d état 2009 va se traduire par la récolte d un million de données. En effet, par rapport aux campagnes précédentes, le nombre d axes concernés va être accru (ajout des nouvelles routes nationales et pour la première fois des rampes) et d autres données d état vont être saisies (mesures CPX et de la texture). TRA se doit donc de pouvoir représenter et gérer correctement de tels volumes de données, notamment dans les situations suivantes: calcul des valeurs de tous les indices d état pour l ensemble de la Suisse à partir des mesures brutes; établissement, pour chaque indice, de statistiques concernant l état des chaussées pour toute la Suisse. Optimisation de l application Les problèmes soulevés ont depuis été analysés par la société en charge de développer l application. Elle a proposé diverses mesures d optimisation. A cette occasion, les volumes de données en jeu ainsi que les temps de réaction attendus ont une nouvelle fois été précisés. Les principales conséquences sont: Jusqu à 100 000 données peuvent être sélectionnées, représentées et analysées statistiquement en 3 minutes au maximum. Chaque mode de représentation ou d évaluation ne peut avoir recourt à plus de 100 000 données. Les sessions de travail standards ne permettent pas de modifier plus 10 000 données. Une session de travail dite exclusive permet de modifier autant de données que souhaité. Lorsqu une session exclusive est en cours, le système reste à disposition des utilisateurs en mode de lecture. Il est alors possible de modifier des données, mais celles-ci ne peuvent être mises à disposition des autres utilisateurs. Des adaptations ont en outre été apportées aux interfaces utilisateurs, afin d accroitre la stabilité et les performances de l application. Il a été fait en sorte que ces modifications, dues à des exigences techniques, ne nuisent pas à la flexibilité que doit offrir l application à ses utilisateurs. Aperçu Du point de vue métier, TRA s annonce comme une application efficace et d usage intuitif. Sa mise en service ne pourra se faire que lorsque les volumes de données évoqués précédemment pourront être visualisés et traités de façon performante dans un environnement stable. A l heure où nous rédigeons ces lignes, la planification encore approximative des travaux d adaptation prévoit une implémentation d ici à cet été, avec pour objectif la mise en production de la première étape de TRA à l OFROU pour l automne 2010. Responsables et participants Direction de projet: Luzia Seiler, OFROU Direction de la réalisation: müllerchur AG avec vico group comme sous-traitant Réalisation: Zühlke Engineering AG avec GEOCOM Informatik AG comme sous-traitant Groupe d accompagnement: OFROU, cantons AG, BL, GR, TG, VD, VS Fig. 8: Affichage de l état de la chaussée (60 000 données) 8

O UVRAGES D ART ET TUNNELS Auteurs: Alain Jeanneret und Rade Hajdin L application métier Ouvrages d art et tunnels (KUBA) a une longue histoire. La première version de KUBA le fichier électronique des ouvrages d art a été développée il y a 23 ans. Pendant cette longue période, KUBA a non seulement bénéficié de perfectionnements sur le plan informatique, mais en outre, les bases techniques de son développement ont été préparées. Les bases techniques de KUBA correspondent aux «bonnes pratiques» actuelles de la gestion de la maintenance des ouvrages d art et s appuient sur les normes suisses et les directives de l OFROU. KUBA soutient les principales activités de la gestion de la maintenance, depuis la surveillance jusqu à la documentation des me - sures de maintenance réalisées. Introduction Dans les précédents numéros de MISTRA News, il n a pas été possible de présenter en détail les bases techniques de l application métier Ouvrages d art et tunnels (KUBA). Le présent numéro thématique leur accorde suffisamment de place afin d expliquer divers aspects techniques du système KUBA ainsi que son intégration dans les processus de gestion de l OFROU et des cantons. Un tel article est tout à fait d actualité puisque les filiales sont actuellement en train de procéder à la saisie des données. Par ailleurs, le présent article décrit, comme d ordinaire, les nouveautés relatives à KUBA. Rétrospective C est en 1987 qu a été créé le premier «fichier électronique des ouvrages d art», nommé KUBA-DB. Cette première version de KUBA KUBA 1.4 a servi à obtenir une vue d ensemble des ouvrages d art à gérer, ainsi qu à établir une documentation pour chaque ouvrage. Les données recensées n ont pratiquement pas été traitées et il n existait alors guère de possibilités d exploitation informatique. Pour l essentiel, il était possible de consulter les données recensées comme dans un fichier. Par la suite, la version 2.1 incluait déjà un module (devenu ultérieurement le module KUBA-ST) permettant l évaluation du passage de transports spéciaux sur les ponts. Avec le temps, les besoins des cantons en matière de données se sont accrus, et le volume des données de KUBA a augmenté en conséquence. Avec la version 3.0 on a disposé pour la première fois d un module permettant l exploitation électronique des données (le prédécesseur de l actuel module KUBA-RP). En 1992, l de l époque (l OFR) a lancé un projet visant à uniformiser la planification des mesures de maintenance. Dans les années qui ont suivi, on a élaboré et testé un procédé assisté par ordinateur pour planifier les mesures d entretien. Le logiciel soutenant ce procédé a reçu le nom de KUBA-MS-Ticino. Ce logiciel a été perfectionné, puis il a été intégré dans la version 4.0 de KUBA en tant que module KUBA-MS. Il permet d exploiter les données des ouvrages qui sont saisis dans KUBA, soit les viaducs, les ponts, les galeries, les tranchées couvertes, les ponceaux, les ouvrages de soutènement et les ouvrages de protection. Par ailleurs, plusieurs innovations ont été apportées à la version KUBA 4.0, qui a également fait l objet d une amélioration de la convivialité d utilisation. La gestion de la maintenance avec KUBA Le système KUBA sert pour l essentiel à soutenir la gestion de la maintenance des ouvrages d art. Cela signifie qu une partie des activités en liaison avec la gestion de la maintenance des ouvrages d art de l OFROU, ou d un autre exploitant de routes, est soutenue par KUBA. Le système KUBA repose sur une méthodologie spécifique reconnue, développée par l OFROU ces vingt dernières années. Cette méthodologie s appuie sur les normes suisses et les directives de l OFROU dans le domaine de la maintenance. Au sein de la maintenance, on distingue entre Surveillance Contrôle Entretien Réaménagement Les activités listées doivent généralement être soigneusement planifiées. A cet effet, par analogie avec la notion de «maintenance», on utilise celle de «planification de la maintenance» qui englobe la planification de la surveillance ainsi que le contrôle et la planification des mesures d entretien et des mesures de modification. La planification de la maintenance est l activité centrale de la gestion de l entretien, qui inclut également les activités classiques de gestion de projet dans le cadre des études et de l exécution des mesures de maintenance. Il n est pas prévu que le système KUBA soutienne la planification de la surveillance et du contrôle. C est la raison pour laquelle le présent texte utilise la notion de «planification de la maintenance» comme synonyme de la planification de mesures de maintenance (mesures d entretien et mesures de modification). Fig. 9 : Le cycle de vie des ouvrages d art Le but de la planification de la maintenance est de prendre des décisions optimales afin de déclencher des mesures de maintenance qui garantissent la pérennité des ouvrages d art concernés. Ces décisions sont prises sur la base d une méthodologie reconnue et en tenant compte des résultats de la surveillance et du contrôle rassemblés durant le cycle de vie de chaque ouvrage d art. Ce processus est représenté graphiquement à la figure 9. Pour lesdites prises de décisions, et lorsque les ouvrages d art sont très nombreux, il est indispensable de recourir à des moyens informatiques. Le système KUBA élaboré par l OFROU constitue un tel moyen informatique. KUBA occupe une position clé au sein du processus de la maintenance, en tant qu instrument de saisie des résultats de la surveillance et des données relatives aux mesures réalisées d entretien et de modification. Par ailleurs, KUBA soutient aussi la planification des mesures de maintenance, ce qui facilite la prise de décisions en matière de mesures de maintenance. 9

Représentation de la réalité / KUBA-DB Avec la saisie de données, la réalité est représentée dans une banque de données modélisée à cet effet. Une partie de cette représentation de la réalité se rapporte à la forme, à la fonction et à la composition des ouvrages d art et des éléments de construction. Ces caractéristiques n évoluent guère au fil du temps. Les données correspondantes, qui sont saisies initialement dans KUBA-DB, sont nommées données de la substance. Les ouvrages d art et les éléments de construction sont soumis à des processus de détérioration ou bien à des événements destructeurs qui les modifient avec le temps. La surveillance a pour but de suivre ces modifications et de repérer suffisamment tôt les évolutions indésirables. Grâce aux inspections qui occupent le rôle central au sein de la surveillance, une partie de la réalité au moment de l inspection est représentée dans la banque de données. Les dégâts constatés par des examens ciblés, en règle générale visuels (fissures, écaillages, traces de rouille, efflorescences, etc.) ou d autres observations (couvertures d armatures insuffisantes) peuvent également être saisis. L inspection inclut également l interprétation des dégâts par rapport à leurs causes et à leur évolution ultérieure. En règle générale, l aspect d un dégât constaté détermine un certain processus de détérioration qui lui est attribué; dans ce cas, le processus de détérioration est saisi, ainsi que l étendue constatée (pour autant qu on puisse la définir clairement). Le solde de la partie d ouvrage restée sans dégât peut (mais cela n est pas obligatoire) être affecté au même processus de détérioration. On peut saisir un paramètre supplémentaire, baptisé «influence», pour définir la vitesse de dégradation prévisible. Une influence négative, respectivement une détérioration plus rapide, peut être due à des influences agressives de l environnement, ou à une qualité d exécution insuffisante. Inversement, on saisit une influence positive lorsque les conditions de l environnement, par exemple, permettent de prévoir une détérioration plus lente. La gravité d un dégât d une certaine étendue s exprime par une classe d état. Une étendue de dégât peut être affectée aux classes d état 1 à 5. Pour assurer la traçabilité de la détermination de l étendue d un dégât, il est possible d affecter des photos à une étendue de dégât et de saisir une localisation. Dans la plupart des cas, les parties d ouvrages ne sont soumises qu à une combinaison entre un processus de détérioration et une influence. Mais cela n est pas toujours vrai. Il se peut par exemple qu une partie d une pile soit exposée à un environnement agressif (par exemple projection d eau contenant du chlorure) qui ne touche pas le reste de la pile. Pour en tenir compte, un élément de construction peut être segmenté. Les segments d un élément de construction se distinguent selon les processus de détérioration et/ou les influences déterminants. Une segmentation judicieuse peut accroître la précision de l évolution de l état calculée dans KUBA-MS et des résultats qui en découlent. La segmentation peut soit être effectuée à l avance, sur la base du comportement attendu de l élément de construction, même en l absence de dégâts, soit être effectuée ou adaptée continuellement en fonction des dégâts constatés. KUBA permet aussi bien la segmentation à l avance que la segmentation continue. La segmentation à l avance repose sur le comportement futur présumé d un élément de construction et est réalisée d ordinaire lors de la saisie de l inspection de réception de l ouvrage. La segmentation continue est effectuée lorsque l on constate des dégâts. Ce faisant, l étendue d un segment qui est attribuée à la classe d état 1 peut être subdivisée en d autres segments, afin de permettre de simuler plus précisément le comportement de l élément de construction dans KUBA-MS. Il convient de relever que pour une étendue de dégât, la classe d état exprime le degré d avancement d un processus de détérioration. Le risque correspondant à l aspect d un dégât, c est-à-dire les conséquences attendues pour le gestionnaire, les usagers et la collectivité, n est pas pris en considération lors de la détermination de la classe d état. Mais, à vrai dire, un risque ne devient déterminant que lorsqu un dégât présente une image de détérioration avancée, qui correspond à la classe d état 5. Dans cette classe d état, il est d ailleurs obligatoire de définir et de saisir le dégât. Pour prendre en considération le risque de cette manière, KUBA doit encore être complété. La plupart des bases techniques nécessaires pour ce complément viennent d être élaborées dans le cadre de divers projets de recherche. A cet égard, le plus difficile consiste à définir les dépendances entre l aspect des dégâts de un ou de plusieurs éléments de construction et les divers scénarios de défaillance et les conséquences correspondantes. Fig. 10 : Détermination de l étendue 10

Planification de la maintenance / KUBA-MS La notion de «planification de la maintenance» est ici utilisée pour la planification des mesures de maintenance. Au sens strict, la planification de la maintenance devrait aussi inclure la planification de la surveillance et du contrôle. Puisque le système KUBA ne soutient pas ces activités ou ne le fait que de façon rudimentaire, la planification de la maintenance se limite dans KUBA à la planification des mesures de maintenance. S agissant de la planification des mesures de maintenance, on distingue entre les mesures d entretien et les mesures de réaménagement, parce que les processus pour les déterminer ne sont pas les mêmes. Les mesures d entretien découlent principalement de processus de détérioration progressifs. Sur cette base, on peut prévoir l état des éléments de construction et leurs segments à l aide de modèles mathématiques. Les mesures de réaménagement découlent de nouvelles exigences et ne peuvent donc pratiquement pas être calculées de façon algorithmique au vu du grand nombre de possibilités et de facteurs d influence. KUBA soutient la planification de la maintenance en proposant des mesures d entretien sur la base de modèles mathématiques. Les mesures de réaménagement peuvent être saisies et prises en compte par le système, mais ne peuvent pas être générées automatiquement. La détermination de mesures d entretien concrètes n est opportune que pour un horizon de temps de l ordre de 15 à 20 ans, au vu des incertitudes croissantes avec le temps. Cette planification à moyen terme est d ailleurs qualifiée dans KUBA d «étude à l échelle projet». Pour la planification à long terme (à partir de 20 ans environ), on détermine uniquement les besoins financiers annuels attendus sur l ensemble des ouvrages d art d un réseau routier. Cette planification à long terme est appelée dans KUBA «étude à l échelle du réseau». La détermination de mesures d entretien (à l échelle du projet) ainsi que le calcul des besoins financiers (à l échelle du réseau) reposent sur un processus d optimisation qui permet essentiellement de réduire les coûts d exploitation à long terme. Les conséquences éventuelles pour la collectivité, hormis les coûts d utilisation pendant la réalisation des mesures de maintenance, ne sont pas prises en considération. Cela est d ailleurs justifié si l on suppose que les mesures d entretien sont engagées à temps, c est-à-dire à un moment où la probabilité de survenue de conséquences défavorables pour la collectivité est négligeable. Pour les éléments de construction des classes d état 1 à 4, la probabilité de leur défaillance est négligeable, puisque ces classes d état ont été définies dans ce sens. Dans la classe d état 5, cette probabilité n est plus négligeable dans certaines situations, de sorte que KUBA propose alors toujours des mesures d entretien. La durée d une étendue de dégât dans la classe d état 5 est ainsi limitée au strict nécessaire. Le modèle décrit plus haut et mis en œuvre dans KUBA présente cependant certains inconvénients qui seront corrigés dans les versions futures: En fonction du processus de détérioration et de l élément de construction concerné, une étendue de dégât dans la classe d état 5 n entraîne pas obligatoirement une atteinte à la fonctionnalité et/ou à la sécurité. Dans ce cas, KUBA proposera le cas échéant une intervention de conservation superflue, qui se limitera finalement à améliorer l aspect de cet élément de construction. Les processus de détérioration progressifs, tels que par exemple la corrosion, ne constituent pas les seuls dangers pour les ouvrages d art. Des processus soudains ou non analysables, tels que par exemple les risques naturels, doivent être pris en compte dans la planification des mesures de maintenance. Cela n est pas encore le cas dans KUBA. Les deux inconvénients décrits ci-dessus sont apparentés puisque, pour y remédier, il faut introduire des considérations de risque dans la planification de la maintenance. Les travaux de recherche réalisés ces dernières années constituent une bonne base pour leur mise en œuvre. Des développements correspondants de KUBA seront effectués dans les prochaines versions. Planification de la maintenance à l échelle du réseau Dans KUBA, la planification de la maintenance à l échelle du réseau s étend sur un très grand nombre d ouvrages et sur une longue période (plus de 20 ans). Dans ce cadre, on détermine surtout l évolution de l état des éléments de construction déterminants pour les coûts et de leurs segments pour différentes politiques d entretien, et on calcule les besoins financiers correspondants. Une politique d entretien définit pour chaque combinaison de type d élément de construction, de processus de détérioration et d influence, dans quel état il convient d exécuter une mesure de maintenance, et laquelle. Les besoins financiers sont calculés en additionnant les coûts de la réalisation des mesures d entretien correspondantes. La politique d entretien présentant les besoins financiers à long terme les plus faibles correspond à la politique d entretien optimale. Ce processus est soutenu efficacement par KUBA. Ce faisant, on ne tient compte que des coûts de l exploitant (coûts des mesures de maintenance et coûts supplémentaires correspondants) et de la planification des mesures d entretien, à l exclusion des mesures de réaménagement. Comme résultat de cette analyse de rentabilité, KUBA fournit l évolution de l état qui en découle ainsi que les besoins financiers à long terme pour les diverses politiques d entretien. Ce faisant, KUBA détermine aussi la politique d entretien optimale. Les prévisions à long terme nécessaires quant à l évolution de l état des éléments de construction et de leurs segments ne peuvent pas être réalisées sans KUBA. KUBA permet de prendre des décisions fondées lorsque la quantité de données devient considérable, en raison du grand nombre d ouvrages. Planification de la maintenance à l échelle du projet Le but de la planification de la maintenance à l échelle du projet est de déterminer la variante de maintenance optimale pour chaque ouvrage d art considéré. La procédure correspond à une comparaison entre des variantes de maintenance possibles qui reposent sur les mêmes politiques d entretien servant également de base à la planification de la maintenance au niveau du réseau. Les critères pour le choix de la meilleure variante sont la rentabilité d ensemble et le respect des instructions et des contraintes. Pour un ouvrage, la variante de maintenance optimale peut en règle générale être déterminée sur la base de la rentabilité et de l entrave minimale à l utilisation pendant la durée des travaux (minimisation des coûts des utilisateurs). Sur la base d une politique d entretien, des mesures d entretien des éléments de construction sont proposées pour les ouvrages sélectionnés compte tenu d un ensemble de budgets. Des mesures de réaménagement peuvent être ajoutées et soumises, en liaison avec les mesures d entretien, à une autre analyse de rentabilité dans laquelle les coûts des usagers peuvent également être pris en compte. Comme résultat de cette analyse de rentabilité, un programme de travail est établi avec des projets de maintenance portant sur les ouvrages pris en compte. Pour les calculs s étendant sur plusieurs périodes, il faut tenir compte du fait que la simulation de la détérioration et de l efficacité des mesures d entretien ne peut aboutir à des résultats sensés que si le nombre d ouvrages est suffisamment important. 11

Évaluation des transports lourds / KUBA-ST KUBA-ST est un outil d aide qui permet, à l aide de calculs comparatifs, de juger si des transports spéciaux, peuvent emprunter des ponts. Les transports spéciaux sont des convois lourds qui dépassent les charges des normes. Les données requises sur les structures porteuses, les charges de trafic des normes utilisées pour le dimensionnement/la vérification des ouvrages d art, les transports spéciaux et les itinéraires à emprunter peuvent être saisies de façon structurée dans KUBA-ST, être gérées et finalement être utilisées pour évaluer la possibilité de circuler. Il convient de noter que la composante KUBA-ST n est pas un programme de calcul destiné à apporter la preuve de la sécurité structurale et de l aptitude au service pour des transports spéciaux empruntant des ponts, mais un filtre qui permet d évaluer rapidement si un transport spécial donné peut circuler sur un pont. Au moyen d une analyse statique simplifiée, la composante KUBA-ST détermine si et comment un pont peut être franchi par un transport spécial. Le programme fournit des valeurs comparatives de la sollicitation maximale exercée sur la structure porteuse principale (dans le sens longitudinal) par le transport spécial et par les charges de trafic des normes déterminantes pour les ponts. Ces valeurs comparatives constituent la base de l évaluation de la possibilité de circuler. La répartition des charges dans le sens transversal est prise en compte par des largeurs transversales déterminantes (largeurs de participation transversales). Le calcul des valeurs comparatives se fait avec un système de base simplifié, afin de réduire à l essentiel les informations relatives aux structures porteuses du pont. A cet effet, chaque structure porteuse du pont est subdivisée en une série de poutres simples ayant des portées caractéristiques et des largeurs transversales déterminantes pour la traversée. Les valeurs comparatives déterminées sur ce système de base par des poutres simples donnent le rapport entre la sollicitation maximale exercée sur la structure porteuse principale par le transport spécial et les valeurs correspondantes sous les charges de trafic des normes sélectionnées. Pour des valeurs comparatives allant jusqu à 1,0, des réserves suffisantes existent en matière de sécurité structurale respectivement de sollicitations. Les valeurs comparatives peuvent être exprimées sous forme numérique aussi bien que sous forme graphique. Des possibilités de franchissement avec ou sans autre trafic (simultané) ainsi qu avec ou sans autres véhicules lourds sont examinées et les résul- tats correspondants sont affichés. Par exemple, il est possible de déterminer que le transport spécial ne pourra franchir le pont que sur la voie de droite et que le pont devra être fermé pour le reste du trafic. Les éléments de construction porteurs transversaux tels que dalle de roulement et poutres transversales ne sont pas pris en compte à l heure actuelle. Au vu de la diversité des ouvrages d art, le besoin d un calcul comparatif dans le sens transversal est reconnu et cette fonctionnalité sera implémentée dans une version future de KUBA. Les valeurs comparatives calculées supérieures à 1,0 ne signifient pas pour autant que le pont ne puisse pas être emprunté. Étant donné que la résistance ultime d un pont dans KUBA-ST correspond exactement à l action de la charge des normes considérée, elle est généralement sous-estimée. Un contrôle peut déterminer la résistance ultime exacte et la réserve de portance ainsi calculée peut être saisie dans KUBA-ST avec un facteur de correction. Par ailleurs, un contrôle peut faire apparaître si un pont ancien répond encore aux exigences des normes de charges les plus récentes. Dans ce cas, la norme de charge la plus récente devrait être utlilisée pour ce pont dans KUBA-ST. Etat de développement KUBA 4.01.04 KUBA 4.01.04 est la dernière version du logiciel KUBA 4.0, qui a vu le jour dans les années 2005 et 2006. Mi-2011, elle sera remplacée par KUBA 5.0. Les concepts introduits dans KUBA 4.0 seront repris et partiellement étendus dans KUBA 5.0. La version 4.01.04 apporte à KUBA-DB de petites adaptations, ajouts et corrections. Les principaux ajouts se trouvent dans le module Transports spéciaux KUBA-ST. Désormais, il est possible d attribuer à un pont plusieurs structures porteuses, ce qui est pris en compte dans le calcul du franchissement du pont par un transport spécial. Désormais, le résultat indiqué montre sur quelle voie de circulation le transport spécial peut circuler. Pour les routes nationales à plusieurs voies, cet ajout est d une grande importance. Pour le reste du trafic qui emprunte le pont en même temps que le transport spécial, un nouveau modèle de charge a été développé et mis en œuvre sur la base des normes de charge les plus récentes (SIA 260 et 261). Fig.11: KUBA-ST (plusieurs structu res porteuses, voies de circulation) 12

Par ailleurs, le facteur de charge des camions-grues a été adapté et s élève désormais à 1.1. Dans les années 2007-2008, plusieurs bureaux d ingénieurs mandatés par l OFROU ont saisi les structures porteuses relatives aux ponts des routes nationales. Étant donné que l affectation de plusieurs structures porteuses à un pont ne sera possible qu avec la nouvelle version, l introduction de cette version s accompagnera également d un apurement des données correspondant. L introduction productive à l OFROU a eu lieu le 5 mai 2010. Elle est suivie par la livraison aux cantons. KUBA 5.0 KUBA 5.0 est un nouveau développement du logiciel des ouvrages d art sur la base des plus récentes technologies Microsoft.Net 3.5, WCF, WPF et Silverlight. Les expériences et les concepts venant de KUBA 4.0 en alimentent le développement. La décision d un nouveau développement a été notamment influencée par la prise en compte des tunnels creusés. Tunnels creusés La structuration actuelle des ouvrages d art en ouvrages et en éléments de construction ne répond pas aux exigences en matière de représentation pour les tunnels creusés. A sa place, on trouvera dans KUBA 5.0 la notion d objet d infrastructure, avec une structure hiérarchique. La hiérarchie et les propriétés sont déterminées par le biais du type d objet d infrastructure. Fig. 12: Structuration de la substance de l ouvrage, propriétés En outre, l inspection d un tunnel ne se fait pas selon la structure de la substance de l ouvrage, mais selon un plan de visite optimal. Cela signifie que l ordre dans lequel les divers objets d infrastructure sont inspectés dépend de la visite choisie. Plusieurs visites peuvent être rassemblées en une campagne. Une campagne peut être établie une fois pour toutes et constituer un modèle régulièrement réutilisé. Fig. 14: Etablissement d une campagne Intégration dans MISTRA KUBA 5.0 va devenir une partie intégrante de MISTRA. Cela implique une implantation centralisée des données et donc un pilotage de la visualisation des objets pour plusieurs mandants (filiales, cantons, villes, etc.). Le concept des mandants s appuie sur les consignes de MISTRA et couvre également les exigences élargies de KUBA. La localisation des ouvrages d art est assurée par le biais du système de repérage de base des routes nationales (SRB). Par ailleurs, KUBA tient compte des interfaces avec MIS- TRA (LDAP pour l authentification et l autorisation, modèle Interlis pour l échange de données, etc.). SIG, esquisses et modèles en 3D Il existe également des exigences accrues en matière de SIG (représentation d axes, saisie d affectations d espaces et contours relatifs à des objets d infrastructure). Les interrogations dans KUBA 5.0 peuvent être limitées dans l espace et les résultats peuvent être visualisés sur la carte. Par ailleurs, il a fallu tenir compte du fait que certaines propriétés changent sur la longueur d un objet d infrastructure. Citons comme exemple le sol encaissant le long du tube d un tunnel. Ces propriétés liées au lieu sont saisies à l aide de séries de propriétés le long de l axe d un objet. Fig. 15: Contours dans l affichage sur la carte Fig. 13: Séries de propriétés pour des propriétés liées à un lieu Il existe également des extensions pour le travail avec les esquisses d ouvrages. Ainsi, il sera possible de saisir dans KUBA 5.0 les dégâts et les groupes de dégâts sur les esquisses d ouvrages et d afficher non seulement les esquisses, mais aussi des modèles en 3D. De manière générale, le travail par le biais d outils graphiques deviendra une partie intégrante importante de KUBA. 13

Fig. 16: Modèle en 3D d un pont Interface utilisateur Un point central dans le développement de KUBA 5.0 a été un guidage de l utilisateur aussi intuitif que possible et un design professionnel. Le choix de WPF comme technologie d aménagement de l interface utilisateur permet de respecter idéalement ces exigences tout en intégrant également des graphiques en tant qu éléments centraux. Cela a cependant occasionné certaines difficultés. Les possibilités élargies de WPF apportent également une plus grande complexité et donc des exigences accrues imposées à l ensemble de l équipe de développement. Tant en matière de design que de performance, il a fallu apporter des améliorations ultérieures dans le courant du projet. Le design s appuie sur Windows 7. Le «ruban» remplace le menu classique. Par le biais d icônes évocatrices et d un texte court et pertinent, le ruban n offre en sélection que les fonctions qui sont importantes dans le contexte du moment. Ainsi, KUBA peut non seulement être utilisé par des experts qui travaillent quotidiennement avec le système, mais aussi soutenir efficacement dans leur travail des utilisateurs occasionnels du système. Avec KUBA-Web, les utilisateurs qui n ont besoin que d informations ou de résultats précalculés sur les ouvrages d art disposent d un accès en lecture seule aux données de KUBA par le biais d un navigateur Internet. La structure de l interface utilisateur est analogue à celle de KUBA. Il existe des fonctionnalités essentielles pour une recherche et une visualisation d objets d infrastructures. Citons en particulier la recherche rapide et la visualisation par le biais du SIG. Pour les inspections, la saisie des constatations et des étendues de dégâts est actuellement mise en œuvre, et on commence désormais la mise en application de la saisie mobile. En outre, le développement des modules Transports spéciaux et KUBA-MS a débuté. Pour le SIG, l intégration du SRB ainsi que l ajout à KUBA-RP de l affichage des résultats sur la carte topographique vont suivre. Le développement sera achevé en octobre 2010. Ensuite aura lieu l introduction, composée d une exploitation provisoire en parallèle avec KUBA 4.0 pendant laquelle des tests intensifs seront réalisés par des utilisateurs sélectionnés et des formations seront Fig. 17: KUBA-Web (contours dans l affichage de cartes topographiques) dispensées. L objectif à cet égard est de passer sans heurt de KUBA 4.0 à KUBA 5.0. La mise en service de KUBA 5.0 est prévue à la fin du premier trimestre 2011. Professionnalisme et innovation L entreprise chargée par l OFROU de développer les versions 3, 4 et 5 de KUBA est un partenaire certifié de Microsoft depuis 2006. En avril 2010, l OFROU et la société de développement ont reçu le prix de l innovation décerné par Microsoft (Microsoft.Net Swiss Innovation Award 2010) pour KUBA 5. La société de développement a collaboré avec un spécialiste en ergonomie de logiciels afin d optimiser la convivialité de KUBA 5. Entre autres, cela aboutit à une qualité optimale et à une excellente acceptation du produit KUBA. Responsables et participants Direction du projet: Alain Jeanneret Direction réalisation et support métier: IMC GmbH Réalisation et maintenance: CAD RZ AG Groupe d accompagnement: Ch. Käser, A. Buntschu, A. Jeanneret, Ch. Gammeter, J.-M. Waeber, P. Henguely, W. Waldis, S. Nendaz, A. Serioli, R. Gall, P. Biehler, H. Ziegler 14

C ONTACTS Directeur général du projet MISTRA Christoph Käser E-Mail: christoph.kaeser@astra.admin.ch Téléphone: 031 323 88 62 Adjoint du directeur général du projet MISTRA Antoine Buntschu E-Mail: antoine.buntschu@astra.admin.ch Téléphone: 031 325 16 32 Responsable des utilisateurs et de la gestion des données Gordana Jegerlehner E-Mail: gordana.jegerlehner@astra.admin.ch Téléphone: 031 325 31 01 Chef de projet Chaussée et Gestion de l entretien des routes nationales Luzia Seiler - E-Mail: luzia.seiler@astra.admin.ch Téléphone: 031 322 94 43 Chef de projet Monitorage du trafic Mario Rubin E-Mail: mario.rubin@astra.admin.ch Téléphone: 031 322 94 21 Chef de projet Ouvrages d art et tunnels Alain Jeanneret E-Mail: alain.jeanneret@astra.admin.ch Téléphone: 031 322 94 34 Directeur GS MISTRA Jean-Pierre Bolli Techdata SA Effingerstrasse 13, 3011 Bern E-Mail: jean-pierre.bolli@techdata.net Téléphone: 021 651 04 67 Chef de projet Système de base Florian Besançon E-Mail: florian.besancon@astra.admin.ch Téléphone: 031 322 94 52 Chef de projet DWH Jürg Landolt Techdata SA Chemin des Roches 38, 1066 Epalinges E-Mail: juerg.landolt@techdata.net Téléphone: 021 651 04 62 Chef de projet Accidents de la circulation Mathias Baudenbacher E-Mail: mathias.baudenbacher@astra.admin.ch Téléphone: 031 323 42 57 Chef de projet Cadastre du bruit Marguerite Trocmé-Maillard E-Mail: marguerite.trocmé@astra.admin.ch Téléphone: 031 322 94 13 Chef de projet Equipement Management System Cédric Joseph E-Mail: cedric.joseph@astra.admin.ch Téléphone: 031 325 52 18 Chef de projet Mobilité douce Niklaus Schranz E-Mail: niklaus.schranz@astra.admin.ch Téléphone: 031 323 42 86 Chef de projet Gestion de l entretien en site urbain Rudolf Fassler Ville d Uster Oberlandstrasse 78, 8610 Uster E-Mail: stadting@stadt-uster.ch Téléphone: 044 944 72 61