Recherche préalable à la création d’un service d’évaluation et de certification de l’interopérabilité des données d’information voyageurs du transport public








télécharger 1.27 Mb.
titreRecherche préalable à la création d’un service d’évaluation et de certification de l’interopérabilité des données d’information voyageurs du transport public
page2/57
date de publication09.06.2018
taille1.27 Mb.
typeRecherche
ar.21-bal.com > loi > Recherche
1   2   3   4   5   6   7   8   9   ...   57

3.2.2. TRIDENT
TRIDENT est un acronyme pour ”TRansport Intermodality Data sharing and Exchange NeTwork » Les spécifications techniques TRIDENT sont issues d’un projet européen à caractère normatif du même nom coordonné par Ertico(1).
Il définit des mécanismes réutilisables permettant d’échanger des données multimodales (bus, tram, métro, ferré et routier) entre opérateurs de transport et fournisseurs de services. Son champ est à la fois plus large que celui de Transmodel puisqu’il concerne à la fois l’information sur le réseau routier (source DATEX(2)) et l’information sur le transport public et plus étroit puisqu’il ne couvre pas l’ensemble des domaines fonctionnels de Transmodel (la problématique de l’exploitation en particulier n’est pas prise en compte).
Par ailleurs, les spécifications de TRIDENT sont basées sur la version v4.0 de Transmodel. Cela entraîne des différences sémantiques et conceptuelles entre TRIDENT et Transmodel v5.1 qui ont fait l’objet d’un examen spécifique dans ce rapport.
Pour ce qui concerne le champ de BATERI, on doit retenir que TRIDENT reprend, en principe, la sémantique de description de Transmodel et y ajoute la syntaxe de programmation du langage XML pour permettre, d’une manière standardisée, les échanges de données entre les systèmes.
3.2.3. CHOUETTE
L'application CHOUETTE a pour objectif de permettre à l'ensemble des acteurs du transport public concernés (notamment les exploitants de réseaux, autorités organisatrices de transport et fournisseurs de services), de disposer d'un outil d'échange d'informations concernant la description "statique" de l'offre Transports Collectifs (réseau, horaires) suivant les spécifications techniques TRIDENT.


Elle assure, d’une part, une fonction d'import aux formats CSV ou XML TRIDENT/CHOUETTE dans une base de données ; et, d’autre part, par l'intermédiaire d'une IHM simplifiée, une fonction de saisie des données et un export au format XML TRIDENT/CHOUETTE.
Pour assurer une interopérabilité complète des jeux de données, une adaptation des spécifications techniques TRIDENT a conduit à créer un « profil d’échange(3) TRIDENT/CHOUETTE » de la façon suivante :
a) TRIDENT recouvre une pluralité de domaines fonctionnels. Pour réaliser un service d'échange de données entre partenaires du domaine du transport, il est nécessaire de

fixer le périmètre fonctionnel des échanges (données véhicule particulier ou transport collectif ; données temps réel, informations de perturbation ou horaires théoriques, par exemple), de sélectionner les données à échanger dans ce périmètre fonctionnel et de

définir une structure d'assemblage des données sélectionnées, appelée « profil d'échange ».

TRIDENT est donc un support pour l'échange de données de transport qui se décline de diverses façons (profils d’échange) selon les besoins fonctionnels.

b) En retenant diverses fonctionnalités au sein de celles que propose TRIDENT, CHOUETTE a établi de façon consensuelle au sein de l’AFNOR/BNEVT/CN03/GT7 un « profil d’échange » de données de transport dédié aux transports en commun. Au stade actuel de son développement, il ne concerne que les données horaires théoriques ainsi que la description de la topologie du réseau. Les échanges couvrent donc la description d'un réseau de transport complet en fonction du besoin fonctionnel initial qui est l’information aux voyageurs. Le « profil d'échange » CHOUETTE permet en particulier de décrire la totalité des données constitutives des lignes d’un réseau et procéde aux échanges et traitement de ces données ligne par ligne ; chaque ligne est constituée d’un seul fichier XML.

c) La spécification CHOUETTE se compose :


  • d'un schéma XSD qui définit le « profil d'échange » composé de toutes les données élémentaires TRIDENT constitutives d'une ligne (à savoir les arrêts, les itinéraires, les tronçons, les missions, les courses, les zones d’arrêt et les correspondances).

  • d'un ensemble de règles fonctionnelles qui complète celles déjà posées par TRIDENT.



3.3. Glossaire général

Terme

Définition

AFNOR/BNEVT/CN03/GT7

Association Française de Normalisation / Bureau de Normalisation Exploitation de la Voirie et des Transports / Commission de Normalisation 03 / Groupe de Travail 7 traitant de l’information voyageur (site internet AFNOR, SETRA)

AFAQ AFNOR certification

Société filiale du Groupe AFNOR qui réalise des prestations d'évaluation et de certification.

AO

Autorité Organisatrice (de Transport)

Attribut

Variable destinée à recevoir une valeur au sein d’un objet

Balise

Sert à délimiter des ensembles de données contenues dans un document afin de permettre sa structuration, selon des normes bien précises.

CEN

Comité Européen de Normalisation. C’est l’organisme officiel européen en charge de la normalisation.

CHOUETTE

Création d’Horaires avec un OUtil d’Échange de données TC

selon le format TRIDENT Européen. C’est un outil développé à partir des spécifications TRIDENT mais limitées à la description des réseaux et des données horaires.

Classe

Ensemble d’objets similaires (même attributs et mêmes méthodes). Chaque objet d’une classe se distingue par des valeurs différentes pour ses attributs.

COFRAC

Association chargée de l'accréditation des laboratoires, organismes certificateurs et d'inspection.




Terme

Définition

Concept

Représentation mentale abstraite d’un objet, d'une idée conçue par l’esprit.

ENV / XP / prEN


European prestandard - Europäische Vornorm) Norme expérimentale Sa validité est limitée à trois ans. L'abréviation ENV correspond à l'abréviation XP au plan français. Désormais abandonné et remplacé par la spécification technique (TS)

PrEN : Norme européenne à l’étude

Exploitant

Entreprise offrant des services de transport public.

IFOPT

Identification of Fixed Objects in Public Transport : TS 00278207, projet de norme technique européenne (prEN) permettant notamment la modélisation de l’ensemble des composants constituant un lieu d’arrêt selon une complexité croissante (depuis la position d’embarquement dans un véhicule jusqu’au pôle d’échange).

Interopérabilité (des données)

Capacité à dialoguer, à interagir, et à échanger des données.

Isochrone

Courbes qui matérialisent les temps de parcours en transport collectif à partir d’un point donné.

Méthode

Ensemble d’instructions qui modifient les valeurs des attributs ou produisent un résultat au sein d’un objet.

Norme

Document établi par consensus et approuvé par un organisme de normalisation reconnu.

Objet

Entité identifiable du monde réel qui possède des attributs et des méthodes.

PREDIM


Plate-forme de Recherche et d’Expérimentation pour le Développement de l’Information Multimodale

Terme

Définition

Profil d’échange

TRIDENT/CHOUETTE

Structure de données retenue dans CHOUETTE résultant d’une sélection d’éléments au sein des spécifications techniques TRIDENT et de règles convenues par les partenaires souhaitant la mise en place d’un type d’échange de données.

SIM

Système d’Information Multimodale

SIRI

Spécification Technique pour les échanges d’informations temps réel pour les réseaux de transport (CEN TS 15 531)

SSII

Société de Services en Ingénierie Informatique

Standard

Ensemble de recommandations développées et préconisées par un groupe représentatif d’utilisateurs.

TC

Abréviation désignant le transport en commun ou transport public.

Technical Specification (CEN TS)

Spécification Technique

Transmodel V5.1

Norme européenne permettant la modélisation conceptuelle de l’ensemble des données utilisées dans le transport public à l’aide d’UML (EN 12 896)

TRIDENT

Spécification technique définissant l’échange de données au format XML, s’appuyant sur Transmodel V4.

UML

Unified Modeling Language est un langage de modélisation des données et du comportement d’un système. Il est décrit sous la forme de diagrammes.

VP

Abréviation désignant le véhicule particulier.

Terme

Définition

XML

eXtended Markup Language - Langage de description des documents qui utilise des balises et permet l'échange des données. XML permet de définir de nouvelles balises contrairement à HTML qui est un langage rigide et bien défini.

XSD

XML Schema Definition

W3C

World Wide Web Consortium


Chapitre 2

Principes d’organisation

et aspects fonctionnels

de la certification

1° Schéma général détaillé



Commentaire du schéma


  • Le demandeur fait une demande de certification (1)

  • Il s’adresse à l’organisme de certification (2)

  • L’organisme de certification réceptionne la demande, l’enregistre et transmet les données à un des laboratoires ayant été agréé (3)

  • Le laboratoire effectue le contrôle des données et établit un rapport d’analyse (4)

  • Le rapport d’analyse est transmis à l’organisme de certification (2)

  • Ce dernier délivre un certificat en fonction des résultats du rapport d’analyse (5)


Le processus de certification et le contrôle des données se base sur le référentiel.


2° Principes généraux d’organisation de la certification
2.1. Nature juridique


  • La certification est encadrée par les articles L 115-27 et suivants du code de la consommation. Ils résultent de la loi n° 94-442 du 3 juin 1994(4). Le projet de mise en place d’un dispositif de certification BATERI s’analyse comme une certification de service s’intégrant dans une démarche de qualité collective.




  • Un référentiel de certification peut avoir un caractère public ou privé ; il est public s’il concerne les consommateurs ; il est qualifié de privé s’il ne concerne que des fabricants de produits ou des fournisseurs de services. Le référentiel BATERI vise à faciliter la création de services d’information transport multimodaux en favorisant l’utilisation, par les créateurs et gestionnaires de ces services, de bases contenant des données échangeables. Il ne concerne donc pas directement l’usager (consommateur) et peut être qualifié de référentiel privé de services aux entreprises.



2.2. Acteurs


      1. Demandeur


Dans un processus de certification privée, la personne qui sollicite la délivrance d’un certificat y a un intérêt direct pour les besoins de sa profession.
Dans notre cas, il s’agit des acteurs du transport :


  • Les autorités organisatrices qui sont tenues par la LOTI de mettre des services d’information à la disposition du public et celles qui le font de manière volontaire ;

  • Les opérateurs de transport dans le cadre de leur délégation de service public et pour les besoins opérationnels du service ;

  • Les sociétés qui agissent par délégation des autorités ou des opérateurs pour la mise en œuvre et la gestion des services d’information.


Si l’on souhaite créer un service d’information multimodale ou une centrale de mobilité, l’existence du certificat permettra d’assurer le maître d’ouvrage de l’interopérabilité des données qui lui sont fournies et donc, de lui éviter de réaliser lui-même les vérifications. Cette exigence pourrait facilement être introduite dans les cahiers des charges de conception et de réalisation de services.
2.2.2. Organisme certificateur

« Peuvent seuls procéder à la certification de produits ou de services les organismes qui ont déposé auprès de l'autorité administrative une déclaration relative à leur activité et contenant notamment toutes les informations nécessaires en ce qui concerne les mesures destinées à garantir leur impartialité et leur compétence. Les organismes qui bénéficient d'une accréditation par une instance reconnue à cet effet par les pouvoirs publics sont dispensés de fournir ces dernières informations.» (article 115-28 du code de la consommation)

  • L’organisme certificateur a la responsabilité d’assurer que les données répondent et, s’il y a lieu, continuent de répondre aux exigences du référentiel. Dans la mesure où l’objectif poursuivi se situe au plan national, il est recommandé de créer un unique organisme certificateur ou de confier la responsabilité de la certification à un seul organisme. Il exerce une fonction « notariale », son attestation ayant une valeur de tiers de confiance par rapport à l’ensemble de la communauté.




  • L’organisme certificateur devra déposer une demande d’accréditation auprès du COFRAC, association reconnue par les pouvoirs publics, l’attestation délivrée constituant une reconnaissance formelle de sa compétence à réaliser des activités spécifiques d'évaluation de la conformité. Elle est de nature à offrir aux entreprises et aux pouvoirs publics, une réelle garantie de confiance dans les prestations effectuées par l’organisme de certification.




  • La mise en place de l’organisme de certification supposera une adhésion des autorités organisatrices, des opérateurs de transport et des prestataires de service spécialisés.



2.2.3. Laboratoire agréé
Le certificateur peut s’appuyer sur un ou plusieurs laboratoires agréés. Il peut également cumuler les rôles de laboratoire et de certificateur. L’agrément repose sur un certain nombre de critères posés par les normes CEN de la série 45000. Le COFRAC a également qualité pour agréer des laboratoires d’essai. Mais il est aussi possible, puisqu’on se situe dans un contexte de droit privé, que le certificateur souhaite lui-même agréer les laboratoires sur lesquels il s’appuie.
Le laboratoire est chargé de réaliser les contrôles d’interopérabilité et de délivrer un rapport d’analyse sur la base duquel le certificateur décidera d’accorder ou de ne pas accorder le certificat d’interopérabilité. Les contrôles sont réalisés à l’aide d’une plateforme ou banc de test qui permet d’automatiser la procédure. Les opérations peuvent se dérouler manuellement ou en ligne.



    1. Référentiel


Le terme « référentiel » recouvre une pluralité de situations de documents de nature fort différentes. Il peut s’agir de « guides de bonnes pratiques », de « méthodologies génériques » ou de « spécifications techniques ». Ils visent les produits, les services et la qualité des produits et des services.
Le projet de référentiel BATERI est un ensemble de règles, principes fonctionnels et de spécifications techniques, permettant d’assurer l’interopérabilité des données d’information de transport public, issues de plusieurs détenteurs ou gestionnaires.
Les normes et standards sur lesquels est basé le projet de référentiel peuvent connaître des évolutions pouvant entraîner des modifications de ce dernier. Celui-ci peut également être élargi lors de l’apparition de prénormes, normes et standards nouveaux justifiant l’élargissement de son champ.
Dans le domaine concerné par cette étude les élargissements peuvent concerner les évolutions du profil d’échange CHOUETTE (prise en compte des données routières, lignes à fréquence, TAD…), les évolutions des spécifications de TRIDENT (notamment dans l’optique d’une évolution vers le statut de norme CEN), la localisation des objets fixes – points d’arrêt et pôles d’échanges – objet du projet de norme IFOPT – les données temps réel – TS 15-531 SIRI .
Toute modification du référentiel ne peut se faire qu’à l’initiative de l’organisme certificateur et doit tenir compte des versions antérieures en vigueur. Il est important que les détenteurs de certificats soient informés lors de la mise à l’étude de versions nouvelles du référentiel afin de pouvoir, le moment venu, solliciter, si elle le souhaitent l’obtention d’un nouveau certificat.
Lorsque la version nouvelle du référentiel introduit des prescriptions imposées par une loi ou un règlement, elle doit être obligatoirement prise en compte et un nouveau certificat doit être sollicité.


    1. Certificat d’interopérabilité


Dans le cadre de la certification privée, le certificat d’interopérabilité n’a de force que vis-à-vis des parties – demandeur et organisme de certification – et par rapport aux tiers qui lui font confiance.
Afin de garantir dans le temps l’homogénéité des données, la durée de validité d’un certificat doit être limitée.
Des contrôles doivent pouvoir être opérés périodiquement pour éviter les dérives au-delà de la délivrance du certificat. La sanction de ces contrôles doit pouvoir aller jusqu’au retrait du certificat.

3° Aspects fonctionnels et de procédure
3.1 Les étapes de la procédure
3.1.1. Processus manuel ou en ligne
La procédure doit pouvoir se dérouler manuellement ou en ligne :


  • Dans le premier cas, le demandeur adresse par voie postale le formulaire signé accompagné d’un support de stockage contenant les données à certifier. L’organisme de certification lui retourne le formulaire signé valant accusé de réception et enregistrement de la demande. Un délai doit être déterminé pour effectuer les tests et délivrer le certificat. Ceci s’adresse aux petits réseaux de transport public disposant de moyens informatiques et de communication très limités. La procédure manuelle doit être limitée.




  • Dans le second cas, la demande est formulée en ligne – remplissage du formulaire - et les données sont téléchargées sur un site mis à disposition par l’organisme de certification.


En pratique :


    1. l’organisme de certification réceptionne la demande, l’enregistre et envoie des identifiants (login / password) au demandeur ;

    2. ce dernier accède à un espace sécurisé (exemple : https://www.bateri.fr) et s’authentifie ;

    3. il remplit le formulaire de demande pour la partie qui le concerne ;

    4. il transmet ses données en ligne et au besoin change les paramètres par défaut sur la plateforme ;

    5. les données et un fac simile du formulaire sont transmis automatiquement au laboratoire agréé ;

    6. celui-ci réalise les tests et transmet le rapport d’analyse à l’organisme de certification ;

    7. ce dernier délivre un certificat de conformité ou de non conformité en fonction des résultats du rapport d’analyse.



3.1.2. La demande de certification
Auteurs de la demande
Les demandes de délivrance du certificat sont effectuées auprès de l’organisme certificateur par des autorités organisatrices, des opérateurs de transport - ou les prestataires qu’ils délèguent -, ou encore par des fournisseurs de services dans le domaine de l’information voyageur. La demande s’accompagne de la transmission d’un ou plusieurs « jeux de données ».
Il peut s’agir :


  1. Des données d’une partie d’un réseau.

  2. Des données d’un réseau en entier.

  3. Des données de plusieurs réseaux. Par exemple, le maître d’ouvrage d’un Service d’Information Multimodale (SIM) régional ou d’agglomération demande à être assuré que les données échangées entre les différents réseaux impliqués dans le SIM sont réellement interopérables. Le contrôle est d’abord effectué sur les jeux de données de chacun des réseaux, puis sur les données agrégées.

  4. Des données agrégées de plusieurs SIM. Par exemple, le maître d’ouvrage d’un SIM régional souhaite s’assurer de la possibilité, à terme, d’échanger des données avec le SIM d’une autre région.


Formulation de la demande
Le formulaire ci-après est un exemple de demande de certification qui peut revêtir la forme suivante :



Initialisation de la procédure (certificateur)

Date de la demande




Numéro d’enregistrement




Renseignements sur le demandeur (demandeur)

Nom de l’organisme




Nom du correspondant




Téléphone




Email




Adresse du demandeur

Rue




Code postal




Ville













Description des données (demandeur)

Nombre de jeux




Accès aux données (support)

‫ CD ‫ DVD ‫ site internet ‫ autre (préciser)

Si internet, adresse de téléchargement




Description jeu 1*


Description jeu 2*








Description du jeu n*






Signature organisme certificateur Signature demandeur

* Description de l’aire géographique, des éléments du réseau (lignes, arrêts …), du nom du réseau, de l’AO à laquelle il se rattache.

Des paramètres enregistrés par défaut sur la plateforme de certification doivent être au besoin modifiés selon ceux fixés par le demandeur en fonction de la nature de ses lignes ou réseaux (en effet comme la plate-forme de test affichera des recommandations sur la « logique » du jeu de données, il est nécessaire d’accorder les paramétrages par exemple sur la distance spatiale minimale entre 2 points d’arrêt ….). Ces paramètres sont accessibles grâce à une interface spécifique sur la plateforme.


Paramètres par défaut à modifier éventuellement (demandeur)

Nature du paramètre

Valeurs par défaut

Distance spatiale minimale entre 2 points d’arrêt

100 m

Distance spatiale entre 2 points d’arrêt consécutifs d’une course

Entre 0,1 et 99 km

Vitesse entre 2 arrêts d’une correspondance

Par défaut :

Voyageur habitué :

Voyageur occasionnel :

Voyageur à mobilité réduite :


Entre 3 et 6 km/h

Entre 4 et 7 km/h

Entre 2 et 5 km/h

Entre 1 et 4 km/h

Vitesse entre 2 points d’arrêt consécutifs d’une course

Entre 3 et 80 km/h

Localisation du point d’arrêt de retour de boucle – distance maximale par rapport au point d’arrêt de début de boucle

0,1 km

Temps maximum de stationnement à un point d’arrêt

2 minutes

Variation de la vitesse entre 2 points d’arrêt pour 2 courses consécutives utilisant le même couple de points (V est la vitesse entre les 2 points pour la 1ère course)

Au minimum

Au maximum


V/2

V*2



      1. Exécution des tests



Exécution des tests (laboratoire agréé)

Date de transmission de la demande




Nom du laboratoire de tests




Date de réalisation des contrôles




Rapport d’analyse

(document produit par la plateforme de tests)




Nom du technicien de contrôle

Signature





      1. Emission et délivrance du certificat



Emission et délivrance du certificat (certificateur)

Date de retour du laboratoire




Analyse de conformité

‫ conforme ‫ non conforme ‫ message d’avertissement

Remise du certificat

‫ oui ‫ non




Date et signature organisme certificateur



    1. Présentation du démonstrateur de la plateforme de test


On suppose que la procédure est effectuée en ligne. Les cadres correspondent à des copies d’écran du démonstrateur. Un manuel d’utilisation sera associé au démonstrateur.
3.2.1. Présentation
a) Les jeux de données (1 ou plusieurs fichiers XML) sont fournis sous forme d’un seul fichier au format zip à l’adresse : http://www.bateri.fr


b) Le fichier est valide, et a été téléchargé avec succès.
c) Les données sont alors analysées catégorie par catégorie et la plateforme indique les différentes phases d’analyse :
1) décompression du fichier ZIP

2) analyse des fiches de catégorie 1

3) analyse des fiches de catégorie 2

4) analyse des fiches de catégorie 3

5) création du rapport

Le rapport est disponible ici

d) Un rapport d’analyse est produit et il est détaillé, par catégorie, au niveau de chaque test pour une fiche donnée. Plusieurs cas de figures sont possibles :


  1. le test est conforme ;

  2. le test est conforme mais certaines anomalies non bloquantes ont été décelées. Le rapport comporte un avertissement (mise en garde sur des conséquences éventuelles de dysfonctionnement).

  3. le test est non conforme : un message justifie cette non conformité.



3.2.2. Illustration
Dans le cas suivant, le test 1.1.1 de la fiche 1.1 est non conforme. Les données du fichier n’obéissent pas à la syntaxe du W3C et le test a détecté que la balise  « PTNetwork » (version du réseau) n’est pas fermée correctement.


3.2.3. Certificat
Sur la base du rapport d’analyse, et après examen par un l’expert de l’organisme certificateur, le certificat est émis.

4° Eléments à prendre en compte et recommandations(5)
Les résultats de la recherche BATERI fournissent une base pour la concrétisation des moyens permettant de faciliter l’interopérabilité des données d’information du transport public. Plusieurs propositions peuvent être avancées.
4.1. L’auto-évaluation
4.1.1. Un outil d’auto-évaluation en accès libre
Ce cas est le plus simple. Avec des développements ultérieurs relativement limités, il serait possible de mettre en ligne une application permettant aux détenteurs de données de les tester gratuitement afin de vérifier leur niveau d’interopérabilité par rapport aux spécifications TRIDENT et le profil d’échanges CHOUETTE.
Pour faciliter l’utilisation de l’application en ligne, l’utilisateur disposera d’une « boîte à outils » contenant :


  1. le mode d’emploi de l’application

  2. l’application elle-même

  3. un forum à partir duquel l’utilisateur pourra poser des questions ou émettre des observations


Dans cette hypothèse, on ne peut manquer de faire un rapprochement entre cette application d’autotest BATERI et l’outil CHOUETTE. La première présente l’avantage d’être basée sur des spécifications issues non seulement de CHOUETTE et TRIDENT- qui ne sont pas des normes - mais aussi de la norme TRANSMODEL v5.1 ; la seconde offre une fonctionnalité supplémentaire de saisie de données au format TRIDENT/CHOUETTE.
Si, en définitive, il n’était pas possible d’évoluer jusqu’à un véritable mécanisme de certification, on aurait intérêt à se pencher sur les possibilités de réunir CHOUETTE et BATERI dans un seul et même outil au service des acteurs du transport, qui se réfère à la norme sans ambiguïté et présente une flexibilité propice à la prise en compte des développements normatifs en cours, IFOPT notamment.

Cette étape d’unification devrait s’appuyer sur la complémentarité des compétences de l’équipe BATERI, les instances de normalisation AFNOR/BNEVT/CN03/GT7, la MTI(6) et le CERTU.
Un tel choix serait conforté si, après approfondissement, le référentiel était publié à l’AFNOR, signe de reconnaissance de sa valeur normative.

4.1.2 Un outil d’auto-évaluation préalable à la demande de certification
L’approche outil peut ne pas être exclusive du processus de certification.
En effet, on peut concevoir de mettre en ligne un outil de façon à permettre à tout utilisateur, s’il le souhaite, de tester ses données préalablement à une demande de certification. Cela pourrait aider un détenteur de données à effectuer les corrections les plus importantes de ses données avant d’en demander la certification. Le démonstrateur pourrait donc aussi être également considéré comme un outil d’amélioration.
Ce processus d’auto-évaluation préalable pourrait aussi constituer un levier de progression de la prise de conscience de l’intérêt de l’interopérabilité et contribuer à faire connaître le service de certification.



    1. L’approche de document technique

a) Dans le domaine de la construction et du bâtiment, les DTU (Documents Techniques Unifiés) sont reconnus et approuvés par les professionnels du domaine et servent de référence aux experts. Ils constituent des cahiers des charges types contenant diverses clauses issues des règles de l’art et permettant de mettre en œuvre des produits normalisés. Ils s’adressent aux maîtres d’ouvrage, aux maîtres d’œuvre, aux experts et aux entreprises.

Les DTU sont élaborés par la Commission Générale de Normalisation du Bâtiment présidée par le Centre Scientifique et Technique du Bâtiment (CSTB) et ont été intégrés dans le système normatif.

b) Il paraît possible d’imaginer une démarche du même type dans le domaine de l’information voyageur au sein du transport public.

Le Bureau de Normalisation et d’Exploitation de la Voirie et des Transports (BNEVT) est une entité du SETRA(7) ; elle assure la coordination des actions de normalisation au sein de l’AFNOR, en particulier le secrétariat de la Commission de Normalisation qui traite le transport public sous l’angle de la billettique et de l’information des voyageurs (CN03).

Le BNEVT pourrait être saisi par la Mission des Transports Intelligents pour proposer à la CN03 la validation du référentiel BATERI (à l’issue des travaux de complétude qui sont nécessaires pour parvenir à ce stade) en DTU. La force d’un tel document pourrait, dans un premier temps, être limitée à celle d’un guide technique.

    1. L’approche de certification




      1. La certification AFNOR


Le Groupe AFNOR résulte de l’union en 2003, puis de la fusion en fin d’année 2004, de l’Association Française de NORmalisation (AFNOR) et de l’Association Française pour l’Assurance Qualité, AFAQ. Cette transformation permet au Groupe AFNOR d’assurer une très large gamme de compétences : normalisation, certification, information, formation et développement international des deux organismes.
Une filiale du Groupe AFNOR, AFAQ AFNOR Certification, société à associé unique, a été créée en octobre 2004. Elle bénéficie de l’accréditation du COFRAC.
Ainsi l’AFNOR est-elle en mesure de jouer son rôle originel de créateur et de gardien des normes et, en même temps, d’assumer au moyen de sa filiale, une mission de contrôle de l’application des normes grâce à la certification AFAQ AFNOR certification.
Aussi, plutôt que de créer une structure spécifique pour gérer la certification de l’interopérabilité des données du transport public, pourrait-on estimer préférable de s’appuyer sur une structure existante reconnue.
Le schéma de mise en œuvre, pour cette hypothèse, passerait par les étapes suivantes :


  • Présentation des résultats de la recherche BATERI à la CN03 de l’AFNOR (transmission par le BNEVT),

  • Expertise des résultats et propositions de consolidation,

  • Proposition du projet de référentiel et de la plateforme de test dans leur forme définitive,

  • Agrément de la CN03 et présentation à l’AFNOR en vue de publication du référentiel afin de lui conférer un caractère normatif,

  • Prise en compte par « AFAQ AFNOR certification » et proposition de devenir certificateur,

  • Mise en place d’un processus de certification par « AFAQ AFNOR certification ». Pour la réalisation des contrôles, celle-ci a la possibilité d’utiliser ses propres laboratoires ou de faire appel à des laboratoires extérieurs.


Sous condition que le processus interne AFNOR puisse gérer les différentes étapes de la démarche suffisamment rapidement, une telle hypothèse présenterait l’avantage de s’appuyer sur la logique économique d’un grand groupe.


4.3.2. Une certification spécifique
Comment ?
Comme cela a été précédemment décrit, la délivrance du certificat est subordonnée au résultat d’une série de tests. Pour des raisons économiques et du fait du champ relativement limité de la certification BATERI, il serait facilement concevable que l’organisme de certification puisse être organisé de telle sorte qu’il soit en mesure de réaliser lui-même les tests de conformité en s’appuyant sur sa propre plateforme technique. C’est d’ailleurs le schéma qui a été adopté dans la recherche.
Alternativement, on pourrait souhaiter cantonner l’organisme de certification à une mission « notariale » et faire réaliser les tests par des sociétés ou laboratoires agréés. Un tel choix serait justifié par le souci de faire participer de manière large les experts du domaine au processus de certification. Dans la mesure où les tests seraient réalisés par des acteurs économiques qui participent au développement des services d’information transport, ces derniers pourraient avoir un intérêt objectif à l’interopérabilité.
Si le choix se porte sur la seconde solution, un cahier des charges devra être défini afin de fixer la procédure d’agrément reposant sur le respect des normes du domaine (EN 45000).
Qui ?


  • S’il est créé une agence française pour l’information multimodale dont une des missions essentielles est de coordonner le processus de normalisation, elle aura naturellement vocation à devenir organisme de certification. Dans ce cas, les fonctions de laboratoire technique pourront être assurées soit par l’INRETS qui pourrait faire évoluer en ce sens sa plateforme CLAIRE SITI, soit par le réseau scientifique et technique du MEDAD(8) ;




  • Alternativement, il serait possible d’intéresser un organisme de certification existant (ils sont très nombreux) pour assurer la fonction en assurant une participation suffisante des acteurs du domaine ;




  • La création d’un certificateur de toutes pièces est également possible. Mais elle pose des problèmes économiques et juridiques qui doivent être préalablement surmontés et qui, du fait des difficultés à surmonter, conduisent à ne pas privilégier cette solution.


Chapitre 3
Contrôle et validation de l’interopérabilité des données : points de contrôle et tests de validation

1   2   3   4   5   6   7   8   9   ...   57

similaire:

Recherche préalable à la création d’un service d’évaluation et de certification de l’interopérabilité des données d’information voyageurs du transport public iconCev et Actigraph, des acteurs normands du nfc, de la billettique...

Recherche préalable à la création d’un service d’évaluation et de certification de l’interopérabilité des données d’information voyageurs du transport public iconAbraham Claude, Raynard Christine, Auverlot Dominique, Revial Thomas,...

Recherche préalable à la création d’un service d’évaluation et de certification de l’interopérabilité des données d’information voyageurs du transport public iconCahier des charges Consultation des organismes de formation
«salarié agricole qualifié en polyculture» au cours de l’année 2005. Le dossier des référentiels4 «professionnel» / «certification»...

Recherche préalable à la création d’un service d’évaluation et de certification de l’interopérabilité des données d’information voyageurs du transport public iconProjet régional de renforcement des Systèmes Nationaux d’Information...

Recherche préalable à la création d’un service d’évaluation et de certification de l’interopérabilité des données d’information voyageurs du transport public iconCahier des charges Consultation des organismes de formation
«compétences» / «certification» et des situations professionnelles d’évaluation a été élaboré sur l’année 2005, associant les professionnels...

Recherche préalable à la création d’un service d’évaluation et de certification de l’interopérabilité des données d’information voyageurs du transport public iconI. Notion de système d’information : Une proposition de définition
«Un Système d’information (SI) est un ensemble organisé de ressources : matériel, logiciel, personnel, données, procédures… permettant...

Recherche préalable à la création d’un service d’évaluation et de certification de l’interopérabilité des données d’information voyageurs du transport public iconDispositions relatives à la liberte de création et a la creation artistique
«sa communication au public,» sont insérés les mots : «notamment la mise à disposition de manière que chacun puisse y avoir accès...

Recherche préalable à la création d’un service d’évaluation et de certification de l’interopérabilité des données d’information voyageurs du transport public iconCxp-evaluation Extrait du Service Expert

Recherche préalable à la création d’un service d’évaluation et de certification de l’interopérabilité des données d’information voyageurs du transport public iconArchitecture de réseau et caractéristiques fonctionnelles des systèmes...
«Vue d'ensemble des Recommandations relatives au réseau de gestion des télécommu­nications»

Recherche préalable à la création d’un service d’évaluation et de certification de l’interopérabilité des données d’information voyageurs du transport public iconLa deuxième modalité de la commande publique est la délégation de service public ou dsp
«contrat de partenariat public-privé» (que l’on désignera ici par cppp) créé en 2004 – IL est courant que le terme générique de ppp...








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com