{ "version": "https://jsonfeed.org/version/1.1", "title": "DiaLog", "language": "fr", "home_page_url": "https://dialog.beta.gouv.fr/blog/", "feed_url": "https://dialog.beta.gouv.fr/blog/feed/feed.json", "description": "Intégration de la réglementation de circulation dans les solutions numériques", "author": { "name": "DiaLog", "url": "https://dialog.beta.gouv.fr/" }, "items": [ { "id": "https://dialog.beta.gouv.fr/blog/fr/cameras-informatique-et-libertes/", "url": "https://dialog.beta.gouv.fr/blog/fr/cameras-informatique-et-libertes/", "title": "Caméras, Informatique et Libertés", "content_html": "\n
\n

\n
\n

Entretien avec Régis Chatellier, responsable d’études prospectives à la CNIL - Commission Nationale de l'Informatique et des Libertés.

\n
\n
\n

\"photo\nQui capte les données aujourd’hui dans l’espace public ?

\n

Depuis les boucles dans le sol associées aux systèmes de feu jusqu’aux caméras de vidéosurveillance, cela fait plus de 50 ans que la ville capte des données. Ce qui est nouveau est l’usage d’objets connectés, géolocalisés et mouvants comme le smartphone. Beaucoup d’acteurs publics et privés aujourd’hui captent de la donnée dans l’espace public via des caméras : collecte des déchets, transporteurs, boutiques et de plus en plus les particuliers eux-mêmes. Les cadres juridiques applicables sont différents.

\n

Est-ce que les enjeux sont différents selon les acteurs et les lieux de captation ?

\n

Le Réglement général sur la protection des données s’applique de manière générale à la captation et au traitement des données personnelles, hors usages domestiques et sécurité publique. Cette dernière fait l’objet de textes spécifiques qui définissent précisément les cas d’usage autorisés (voir plus loin).

\n

Le RGPD dispose que la collecte des données doit s’appuyer sur une base légale (intérêt public, contrat, intérêt légitime, consentement, etc.). Ces données doivent être associées à un usage, une finalité, et être minimisées. L’usage d’une balance connectée par exemple ne doit pas nécessiter de créer un compte, pas plus que l’achat d’un billet de train ne doit imposer à l’acheteur de renseigner son genre. Comme il n’y a pas de tarifs liés à Monsieur ou Madame, la collecte de ces données ne se justifie pas. Idem si j’ai besoin de savoir si une personne a 18 ans, je n’ai pas besoin de collecter son adresse, ni même sa date de naissance. Les données ne doivent pas non plus être collectées et traitées pour d’autres finalités que ce qui a été annoncé initialement.

\n

Le cas d’applications comme Waze, qui capte en temps réel les données de géolocalisation de leur utilisateur, est intéressant de ce point de vue. La captation de ces données repose sur le contrat. dès lors que le service rendu par Waze nécessite de connaître la position exacte de l’utilisateur pour fonctionner. Le fonctionnement de Waze en dépend, c'est pourquoi il ne s’agit pas d’un consentement. On doit pouvoir refuser un consentement de manière libre, sans renoncer au service lui-même, par exemple si nous refusons la publicité ciblée, ou le partage de données à des tiers. Ici, la donnée de géolocalisation conditionne l’accès au service, elle est donc associée au contrat.

\n

Le RPGD “va dire” aux personnes et aux entreprises : pas de problème à collecter de la donnée , à condition de respecter le cadre et de ne pas en collecter plus que nécessaire. Le RGPD répond à une conception anglo-saxonne du droit : le droit est “embarqué” par l’utilisateur des données, le responsable de traitement, qui doit être en capacité de démontrer qu’il respecte ces droits dans les conditions requises par le RGPD. Il n'y a plus de déclaration préalable comme avant 2018, de même, les demandes d’autorisations se limitent à quelques cas spécifiques en santé.

\n

Comment s’assurer que les données diffusées ne soient pas des données personnelles ?

\n

La captation de données dans l’espace public et plus encore leur diffusion ne doit pas conduire à permettre d’identifier les personnes. Pour Google Street View, par exemple, la CNIL a très tôt demandé à ce qu’on anonymise tout ce qui permet d’identifier directement les personnes : plaques d’immatriculation, visages,...\nDans le cas du programme Waze for Cities par lequel les collectivités récupèrent des données d’usage de la voirie collectées par l’application, la donnée est anonymisée par agrégation pour qu’on ne puisse pas isoler des déplacements individuels. La ville a accès à des données de flux mais ne peut pas, ne doit pas, savoir qui circule. L’anonymisation des données est un champ de recherche en soi. Il existe plusieurs manières de le faire comme la suppression de certaines données (si par exemple vous êtes le seul utilisateur d’une voirie), l’introduction de “bruit” dans la donnée,.... C’est un processus dynamique : il doit toujours être réalisé à l’état de l’art car les techniques d’identification progressent.

\n

Quelles sont les données les plus sensibles ?

\n

La donnée dès qu’elle est géolocalisée est extrêmement sensible. Par exemple , si vous avez accès à la trace GPS d’une personne dans ses déplacements quotidiens, vous pourrez aisément remonter à celle-ci. Car il est rare que deux personnes ayant le même lieu de résidence aient également le même lieu de travail. Nous l’avons démontré dans un projet mené par le LINC en 2022-2023. De même, un chercheur a démontré dès 2015, à partir de l'étude des données de cartes bancaires, produites sur trois mois par 1,1 million de personnes, que seuls quatre points "spatio-temporels" (coordonnées géographiques, date et heure) suffisent pour retrouver l'identité de 90% des individus.

\n

Les règles sont-elles les mêmes pour la vidéo dans l’espace public ?

\n

Dans l’espace privé, pour la protection de bâtiments ou de certains lieux fréquentés par le public, il est possible d’installer une caméra pour protéger ce bâtiment, mais celle-ci ne peut être utilisée pour surveiller les personnes, par exemple les salariés.

\n

Dans l’espace public, les usages de la vidéo sont encadrés par le Code de la Sécurité Intérieure. Ce qui n’est pas expressément autorisé est interdit. Les images collectées sont accessibles uniquement aux personnes habilitées. Elles sont déclarées dans un cadre très normé qui prévoit tous les cas d’usage. Par exemple, elles peuvent dans certains cas servir à la vidéoverbalisation pour sanctionner des infractions au code de la route et des dépôts d’ordures sauvages par exemple. Ces caméras ne peuvent en aucun cas capter le son.

\n

Dans le cadre de la loi pour les Jeux Olympiques de Paris 2024, les caméras augmentées, ou algorithmiques, sont autorisées sous forme d’expérimentation, pour certains cas d’usage. Le traitement des images collectées doit permettre d’identifier non pas des personnes mais des évènements, comme des bagages abandonnés ou des mouvements de foule, dans un contexte restreint (voir lien). La reconnaissance faciale (identification d’une personne précise à partir d’une image captée dans l’espace public) est interdite en revanche.

\n

Au-delà de la vidéosurveillance, quelles sont les nouvelles formes de captation dans l’espace public ?

\n

D’autres types de caméras sont en effet utilisées par la Police ou la Gendarmerie, par exemple les caméras-piétons. Le cadre juridique précise que celles-ci doivent être visibles, que les personnes doivent savoir quand elles enregistrent. Elles ne doivent pas tourner en permanence. Elles sont soumises à déclaration pour pouvoir tracer leur usage. Il existe des droits associés aux personnes : si l’on ne peut pas s’opposer à ce qu’on soit filmé, on doit en être informé et avoir la possibilité d’exercer ses droits, comme le droit d’accès. La durée de conservation de ces données est par défaut d' un mois.

\n

Sont apparues également les “systèmes LAPI”, des caméras de Lecture Automatisée de Plaques d’Immatriculation : leur usage est encadré par le Code de la Sécurité Intérieure : uniquement à des fins de constatation d’infraction et de respect du code de la route. Des questions nouvelles se posent avec les usages de caméras à lecture de plaque dans d’autres contextes : parkings barriérés, nouveaux péages automatiques. Avec des questions qui se posent en termes d’information des personnes, notamment.

\n

Pour les caméras embarquées dans les voitures ou “dashcams”, la CNIL a lancé une consultation auprès des parties prenantes afin de répondre aux nouvelles questions juridiques posées par ces dispositifs.\nPour tout ce qui est l’enregistrement de l’habitacle dans des véhicules personnels, il s’agit d’un usage domestique. Dans d’autres cas, il s’agit de la relation contractuelle avec le loueur ou le constructeur du véhicule : ceux-ci doivent annoncer et expliquer ce qu’ils font des données collectées. Idem lorsque des caméras embarquées filment autour de la voiture. La CNIL reçoit également des appels et des plaintes à propos de personnes qui installent des caméras chez elles, qui filment vers l’extérieur l’espace public et chez les voisins.

\n

Enfin, la question des images aériennes de grande précision. Dans certains cas, ces images sont utilisées pour identifier des éléments, par exemple dans le cadre de l’expérimentation menée par la DGFIP pour la détection automatisée de piscines non déclarées. Un usage qui avait nécessité un encadrement juridique spécifique.

\n

Comment intervient la CNIL sur ces questions ?

\n

Le sujet des données étant sensible, on nous demande fréquemment à propos d’un projet , du secteur privé comme du public : “qu’en pense la CNIL ?” La CNIL ne pense rien avant de connaître le projet, ses contours, la manière dont il fonctionne. Il s’agit de connaître quel et le montage en termes juridiques, si cela s’inscrit dans un cadre applicable, et technologique : quelle architecture des systèmes, quels stockage pour les données, quels moyens pour les sécuriser, quel est leur cycle de vie, etc. et surtout, comment à chaque phase, les droits des personnes sont respectés, ou non. Ceci vaut pour les caméras, mais aussi pour tous les systèmes que nous rencontrons, y compris lorsqu’ils sont basés sur de l’IA.\nLa CNIL agit dans l’accompagnement en échangeant avec des porteurs de projets ou parties prenantes, par la production de recommandations spécifiques à certains secteurs.

\n

Les administrations viennent aussi nous voir en amont, avant que le projet de loi ne soit examiné pour étudier avec nous quels sont les enjeux spécifiques. Par exemple, pour la Loi JO, la CNIL a pointé le fait que l’expérimentation prévue ne pouvait consister en une mise en pré-production, mais que celle-ci devait faire l’objet d’une vraie évaluation, avec la production d’un rapport d'expérimentation, porté par des experts indépendants.

\n

La CNIL est une autorité administrative indépendante, son budget et ses effectifs sont votés au parlement, ses missions inscrites dans la loi, mais ensuite elle agit de manière autonome sans autorité de tutelle et en indépendance de fonctionnement. La CNIL ne produit pas de droit “dur” : elle interprète le droit et la loi voté en France ou en Europe. Elle peut produire des recommandations (droit “souple”), qui correspondent à l’application de la loi. La CNIL agit sur toute la chaîne, de la production d’avis sur des textes de loi, jusqu’à la réception d’appels de toute personne ayant des questions sur ses droits. Elle peut également intervenir dans le débat public comme elle l’a fait en 2019, pour alerter la société et les élus sur la nécessité de débattre de manière éclairée sur les risques et les lignes rouges à tracer sur l’usage de certaines technologies, à l’image de la reconnaissance faciale.

\n

RESSOURCES UTILES

\n\n

Propos recueillis par Stéphane Schultz, coach produit DiaLog.

\n
\n", "date_published": "2025-10-28T00:00:00Z" } , { "id": "https://dialog.beta.gouv.fr/blog/fr/itw-aurelie-baton/", "url": "https://dialog.beta.gouv.fr/blog/fr/itw-aurelie-baton/", "title": "Le design chez DiaLog - Entretien avec Aurélie Baton", "content_html": "\n
\n

\n
\n

Derrière le service numérique, il y a une équipe. Jetez un oeil dans les coulisses de DiaLog avec Aurélie, designer sur DiaLog.

\n
\n
\n

\"Aurélie\nQuels sont les enjeux de design pour DiaLog par rapport à d’autres sujets sur lesquels tu as déjà travaillé ?

\n

Pour DiaLog l’enjeu principal est de faire en sorte que les agents publics adoptent notre solution sans ajouter de charge ni de complexité. Ils utilisent déjà souvent des solutions pour numériser leurs documents administratifs. Notre objectif est de leur éviter la double saisie. Pour cela nous étudions leur parcours utilisateur pour nous adapter aux outils qu’ils ont l’habitude d’utiliser. Nous proposons par exemple l’export de l’arrêté complet dans DiaLog sous un format de document.

\n

Il y a également un enjeu de faciliter la prise en main de DiaLog. Le problème des outils métiers dans l’administration ou même en entreprise est qu’ils peuvent devenir très complexes. Ces outils permettent souvent de faire beaucoup de choses, mais la complexité apparaît trop dans l’interface. Pour DiaLog, on ne peut pas se le permettre sinon nous n’auront pas l’adoption de la part des agents.

\n

L’enjeu est donc de décomplexifier tout en permettant une flexibilité : on commence par un formulaire assez simple lors de la création d’un arrêté avec quelques champs à remplir, puis sur la phase suivante on sélectionne le type de restrictions de circulation. Nous avons mis différents niveaux de progression, tous les champs ne sont pas directement visibles dans le formulaire. Par exemple, le cas général par défaut s’applique à tous les véhicules, mais si cela s’applique à une catégorie spécifique, on clique et les choix apparaissent.

\n

Etape 1 : sélection par défaut de tous les véhicules

\n
\n\"L'option
L'option \"Tous les véhicules\" est sélectionnée par défaut dans l’interface de DiaLog
\n
\n

Etape 2 : sélection de certains véhicules uniquement

\n
\n\"Option
Option “Certains véhicules” affichée au clic uniquement
\n
\n

Nous appliquons le même principe pour les exceptions. DiaLog permet d’indiquer des exceptions aux restrictions de circulation, par exemple : interdit à tous les véhicules sauf vélos et véhicules de secours, etc.. Mais nous n’affichons pas toutes les exceptions par défaut, il s’agit encore d’un affichage progressif.

\n

Etape 1 : bouton pour définir une exception (pas obligatoire)

\n
\n\"Option
Option pour définir une exception, le détail est \"caché\" par défaut
\n
\n

Etape 2 : sélection possible des exceptions après avoir cliqué sur le bouton

\n
\n\"Après
Après avoir cliqué sur \"Définir une exception\"
\n
\n

Cette manière progressive d’afficher les champs et options au fur et à mesure permet de rendre l’interface moins complexe et plus facile de prise en main.

\n

Tu n’avais pas d’expérience du secteur de la voirie et de la réglementation locale. Comment as-tu travaillé pour ce projet ?

\n

Au début durant la phase d’investigation Mathieu et Stéphane ont récolté beaucoup d’informations sur les usages, les acteurs, les problématiques terrain... Ensuite nous avons fait une phase de recherche avec des entretiens utilisateurs auprès d’agents de communes, de métropoles, de transporteurs. Les parcours utilisateurs ont été cartographiés à partir des parcours existants depuis la demande de travaux, en passant par les étapes jusqu’à la signature et la diffusion, l’abrogation de l’arrêté... Puis nous avons testé les premières maquettes auprès de quelques utilisateurs et utilisé les retours de ces tests pour mettre à jour les maquettes.

\n

Au quotidien nous étudions les arrêtés publiés pour trouver des récurrences ou au contraire des exceptions. Nous avons également des retours via des sondages auprès des utilisateurs que nous faisons régulièrement. Dans l’interface de DiaLog il y a également un bouton “Donnez votre avis” qui nous permet de recueillir des retours.

\n

Comment t’organises-tu au quotidien pour travailler sur ce projet ?

\n

Toutes les 2 semaines on a des réunions de planning avec l’équipe. On définit les priorités en fonction de l’avancement, des retours utilisateurs et des nouvelles demandes. J’en discute avec Mathieu le chef de projet et l’équipe de développement pour créer des stories. À partir de chaque story je fais des maquettes avec des propositions de fonctionnalités ou d’interfaces. Je les montre à l’équipe pour lever des interrogations. J’ai besoin aussi de discuter des implications techniques pour ne pas proposer des choix trop compliqués à mettre en œuvre pour l’équipe de développement.

\n

En moyenne je travaille environ 5 jours par mois sur ce projet.

\n

Comment intègres-tu les impératifs d’accessibilité et d’écoconception des solutions numériques d’État dans ton travail ?

\n

Les développeurs de l’équipe sont déjà formés à l’écoconception : on peut amener la question sans que tout le monde ne prenne peur. On a pu mettre en place la démarche RGESN, avec une revue tous les 6 mois. Même si nous pensons à l’écoconception dans notre travail au quotidien, cette évaluation permet de nous challenger et examiner des éléments sur lesquels nous n’avons pas forcément la main. Globalement cela ne représente pas une tâche trop lourde en raison de nos pratiques bien en place. Une des bonnes pratiques du référentiel par exemple est de fluidifier le parcours utilisateur et de limiter les fonctionnalités à l’essentiel : on le fait dès la conception. Il y a d’autres bonnes pratiques comme pour les mécanismes d’auto-complétion des champs de formulaire, on ne les lance qu’au 3ème caractère, etc.

\n

Qu’est-ce qui te déplaît ou au contraire te plaît le plus dans ce projet ?

\n

J’apprécie particulièrement le mode agile : les nouveautés sortent rapidement, on a des retours rapidement. On ne fonce pas tête baissée dans une solution pour s’apercevoir un an après que ça ne marche pas.

\n

C’est intéressant de travailler dans le cadre de la communauté Beta.gouv avec les partages d’expériences, on peut demander à d’autres équipes comment ils règlent certains problèmes : pour le système de design de l’Etat (DSFR), l’accessibilité, ou d’autres sujets.

\n

Ce que j’apprécie énormément aussi dans ce projet, c’est qu’on est même allé au-delà de l’écoconception en faisant plusieurs ateliers de design systémiques avec l’équipe, c’est super intéressant.

\n

Sans oublier toute l’équipe DiaLog qui rend le travail plus simple et agréable au quotidien !

\n

Parlons de toi maintenant. Comment es-tu devenue designer ?

\n

A la base, j’ai une formation de traductrice et de rédactrice technique ! J’ai intégré IBM où je rédigeais la documentation des logiciels que l’on développait. J’aimais bien travailler avec les développeurs. Le design commençait à se développer dans les entreprises et j’ai pu intégrer une équipe de design à sa création au sein de l’entreprise. J’étais surtout UX designer pour des applications métier.

\n

Tu es également très impliquée dans une association : Designers Éthiques

\n

Je les ai rejoint en 2019, à un moment où je me posais beaucoup de questions sur mon travail et où j’ai choisi de devenir designer indépendante. J’ai rejoint l’association en même temps qu’Anne Faubry, avec qui nous avons écrit un guide sur l’éco-conception de services numériques.

\n

Designers Ethiques organise des évènements (Ethics By Design et la Journée de l’écoconception), nous proposons des formations pour les designers, et nous faisons de la recherche sur différentes thématiques : l’écoconception, l’accessibilité et l’inclusion, le design systémique, les enjeux de design de l’attention, etc. Autant de sujets qui touchent à la responsabilité des designers dans la conception de services numériques.

\n
\n", "date_published": "2025-03-25T00:00:00Z" } , { "id": "https://dialog.beta.gouv.fr/blog/fr/itw-florimond-manca/", "url": "https://dialog.beta.gouv.fr/blog/fr/itw-florimond-manca/", "title": "Sous le capot de DiaLog - Entretien avec Florimond Manca", "content_html": "\n
\n

\n
\n

Derrière le service numérique, il y a une équipe. Jetez un oeil dans les coulisses de DiaLog avec Florimond, développeur sur DiaLog.

\n
\n
\n

DiaLog est une solution numérique qui permet de numériser la réglementation routière et la partager avec des réutilisateurs.

\n

À l’origine de DiaLog il y a un intrapreneur, Mathieu Fernandez-Vandewalle, rapidement accompagné d’une équipe de prestataires indépendants constituée d’une designer, de trois développeurs et d’un chargé de déploiement. DiaLog est également un projet de Beta Gouv - incubateur des startups d’État. Il répond à des critères techniques, éthiques et de conception particuliers.

\n

Prenons le temps d’échanger avec Florimond Manca pour comprendre ce qui se cache derrière ce produit. Florimond est membre de la Scop Fairness, en charge du développement informatique de DiaLog.

\n

\"Florimond\nUne startup d’État est créée pour concevoir des produits qui règlent un problème. Comment passe-t-on du problème au produit ?

\n

Au début de la construction du produit, l’équipe a passé un temps significatif à étudier ce qui s’appelle en ingénierie logicielle le domaine métier, c’est-à-dire les aspects du produit qui viennent directement du monde réel : ce qu’est un arrêté, qui le prend, pour quoi faire, à qui ça s’adresse… De ce domaine métier nous avons conçu un modèle de données, c’est-à-dire une représentation abstraite des entités en présence (arrêté, restriction, utilisateurs…) et de leurs relations. Par exemple, comment traduire une circulation alternée, une intersection, ou une période de validité en donnée ? Tout cela paraît évident dans le langage courant quand il s’agit d’imprimer des panneaux de signalisation et briefer des agents municipaux. Mais lorsqu’il s’agit de transmettre ces informations sous une forme compréhensible par des machines, c’est plus complexe. La terminologie, l’architecture des données, les champs... Il faut normer les choses tout en étant capable de déduire le sens des termes utilisés lorsque ça ne l’est pas. C’est aussi tout l’intérêt de DiaLog : éviter la double saisie et permettre aux collectivités de ne quasiment rien changer dans leurs habitudes de travail.

\n

Ensuite il faut également tenir compte des spécificités des réutilisateurs : nous avons défini une manière de présenter par exemple les périodes de validité d’un arrêté, Waze en a une autre, à nous de faire la correspondance pour que cela marche. L’essentiel est que cela soit le plus indolore possible pour les producteurs de données.

\n

En somme, on peut voir DiaLog comme un passe-plat entre bases de données (rires).

\n

Comment avez-vous abordé le projet DiaLog chez Fairness ?

\n

D’un point de vue technique, l’architecture est celle d’une application Web métier en PHP / Symfony. Nous y avons appliqué les méthodes d’architecture et de qualité pratiquées chez Fairness, à savoir l’architecture hexagonale couplée aux principes du Domain driven design (DDD), en plus des pratiques qui font office d’état de l’art (tests automatisés, CI/CD, etc). L’équipe se partage aussi bien des tâches côté frontend (interfaces utilisateur) que backend (base de données, logique métier…).

\n

Côté frontend, nous avons fait le choix particulier d’une approche dite HTML-first. Cette approche s'inspire des fondamentaux du Web : le rendu des pages Web est effectué côté serveur et JavaScript n’est utilisé que pour ajouter un peu d’interactivité en s’appuyant le plus possible sur les capacités natives des navigateurs modernes. Cela tend à s’opposer à l’approche SPA (Single Page Application), en vogue depuis une quinzaine d’années, qui est associée à des frameworks JavaScript imposants. Ceci nous a semblé judicieux à plusieurs titres : relative simplicité des interfaces de DiaLog ne justifiant pas d’outils conçus pour des interfaces hautement interactives ; réduction de la charge sur les ordinateurs et appareils utilisés par les agents conformément à nos standards d’écoconception ; enfin, réduction de la quantité de code à maintenir pour garantir la pérennité technique de DiaLog.

\n

Un projet comme celui de DiaLog s’insère aussi dans l’écosystème de la communauté beta.gouv.fr. L’infrastructure et certains outils sont mutualisés : hébergement, environnement de test, détection de problèmes en production (monitoring), DNS,... (lien vers le GitHub de beta.gouv). Cela nous permet de nous concentrer sur le produit.

\n

L’intégralité du code que nous produisons pour DiaLog est ouvert, conformément à la politique de l’État en la matière. Le code est accessible sur la plateforme GitHub et peut être réutilisé.

\n

Justement on parle de méthodes agiles pour les projets beta gouv, de quoi s’agit-il concrètement ?

\n

Les méthodes agiles s’opposent au classique “cycle en V” dans l’industrie. Dans l’approche “cycle en V”, des groupes de travail et experts définissent un cahier des charges et une feuille de route détaillée longtemps à l’avance. Le budget est prédéfini. Une consultation désigne un prestataire qui a la responsabilité d’exécuter le projet dans les délais, budget et spécifications requises parfois plusieurs années auparavant, sans que le produit n’ait été mis à aucun moment entre les mains des utilisateurs. Cette méthode peut se comprendre lorsque l’on fabrique des biens matériels car l’erreur a un coût très élevé. En développement informatique, cela a moins de sens.

\n

L’approche agile essaie au contraire de raccourcir le plus possible la boucle de feedback entre ce qu’on produit et les retours utilisateurs. On construit rapidement un produit simplifié, qui est mis le plus tôt possible entre les mains des premiers utilisateurs. Puis on le modifie en fonction de ce que l’on apprend des besoins et des usages, selon une approche d’amélioration continue. Le code de l’application DiaLog est ainsi mis à jour plusieurs fois par jour.

\n

Il faut prendre garde à la tension entre “aller vite” et “durer” que ces approches peuvent engendrer. Nous faisons régulièrement de courtes réunions pour nous mettre d’accord sur ce qui est le plus intéressant pour l’utilisateur. On cherche à faire bien du premier coup sans développer des prototypes inutiles. Nos produits doivent être économiques, avoir moins besoin de maintenance. Le logiciel doit être durable, et pour cela être plus facile à reprendre par d’autres personnes. Cela passe par la documentation et une architecture de code qui permette de facilement de s’y retrouver.

\n

En termes de méthode de travail, nous faisons chaque jour un daily, c’est-à-dire une petite réunion de 15 minutes pour partager ce qui a été fait, ce qui bloque et ce sur quoi nous allons travailler ce jour-là. Tous les 15 jours également un sprint planning de deux heures permet de passer en revue tous les chantiers en cours du projet. Des décisions sont prises, tout est consigné.

\n

Intéressons-nous maintenant au produit DiaLog. Il y a deux produits : une interface de saisie manuelle pour les collectivités qui ne disposent pas de leur propre solution de gestion de la documentation, et un produit “intégration” qui permet d’intégrer les données des collectivités directement depuis les outils qu’elles utilisent. Comment fait-on pour créer un produit qui réalise ces tâches d’intégration traditionnellement faites “à la main” ?

\n

Notre objectif est de proposer un système de flux dans lequel DiaLog récupérerait d’un côté les données auprès du producteur de données pour les mettre à disposition auprès des réutilisateurs au(x) format(s) attendu(s), dans l’idée d’une plateforme qui jouerait l’intermédiaire unique. Sur le papier c’est simple. Dans la réalité c’est beaucoup de “plomberie” (rires). Pour DiaLog, les producteurs de données sont des collectivités qui éditent un arrêté de travaux par exemple qui coupe la circulation dans une rue. Nos réutilisateurs sont par exemple les GPS routiers qui vont utiliser cette donnée pour modifier les itinéraires proposés et ne pas envoyer les voitures ou camions dans cette rue. Le lien entre les deux est fait par un modèle de données interne conçu en s’inspirant des standards européens.

\n

Notre travail est d’automatiser ce transfert de données pour qu’il soit le plus indolore possible pour la collectivité et le plus efficace possible pour les réutilisateurs. En matière de formats de données, nous en avons retenu deux pour l’instant : DATEX II (European standard for traffic and travel information) qui est la norme de référence européenne (voir : Directive STI), et CIFS (closure and incident feed specification), un format créé et utilisé par Waze. Cela permet aux collectivités d’être assurées que leurs données seront facilement réutilisables par différents types d’acteurs publics et privés, aujourd’hui et demain.

\n

Nous devons faire avec les différents types de solutions déjà utilisées par les collectivités locales pour saisir et stocker leur réglementation. Des contacts ont été établis avec la plupart des éditeurs sur le marché : Sogelink, Kadri, Berger-Levrault… afin d’examiner avec eux les meilleures manières d’exporter les données des collectivités depuis leurs solutions. Cela passe généralement par des APIs (interfaces de programmation) conçues justement pour pouvoir faire des requêtes “de machine à machine” dans les bases de données des collectivités. Par exemple, depuis août 2024 DiaLog utilise l’API fournie par l’éditeur Sogelink pour récupérer les données d’arrêtés de circulation auprès de la Métropole Européenne de Lille (MEL).

\n

La mise en place d’un tel dispositif nécessite une étape d’expérimentation avec l’API fournie par le producteur de données : vérifier la validité des identifiants, l’allure des données récupérables, et leur compatibilité avec le modèle de données interne à DiaLog. Quand tout fonctionne bien cette connexion prend quelques minutes. Nous proposons alors un rapport d’intégration à la collectivité qui lui permet de connaître, parmis tous les arrêtés dans la base, ceux qui sont compatibles avec les GPS pour permettre leur export. Une fois la connexion établie de l’autre côté avec les GPS, le flux est presque continu. Waze par exemple vient interroger la base de DiaLog toutes les 5 minutes.

\n

DiaLog n’est pas la seule solution à traiter de la donnée géographique. Comment t’assures-tu de sa compatibilité avec l’ensemble de l’écosystème numérique public ?

\n

Lorsque l’on crée un produit technique comme DiaLog, heureusement on ne part pas de zéro. Nous nous appuyons sur un certain nombre de référentiels et de services existants. Par exemple, la BD TOPO de l’IGN nous est indispensable puisqu’elle fournit les linéaires de routes, rues, chemins de l’ensemble du territoire. Pour connaître les adresses des bâtiments ou propriétés il y a la Base Adresse Nationale (BAN). DiaLog n’existerait pas sans ces solutions. Ces sources de données géographiques s’insèrent dans l’architecture technique de DiaLog d’une manière totalement transparente pour l’utilisateur. Par exemple, lorsqu’un arrêté définit une interdiction de circuler entre les numéros 70 et 76 rue Ange Blaize à Rennes, l’emplacement géographique de ces deux adresses est calculé à l’aide de la BAN, puis le tronçon de linéaire concerné est extrait de la BD TOPO.

\n

Au niveau plus technique, nous utilisons des solutions standard et connues dans le métier, notamment la base de données PostgreSQL et sa surcouche PostGIS qui fournit les outils pour traiter les données géographiques.

\n

Finalement, notre travail en tant que développeur ou développeuse consiste beaucoup à assembler différentes “briques” pour répondre au besoin de la manière la plus fiable et efficiente possible.

\n

Parlons pour finir de toi. Comment es-tu arrivé à ce métier ?

\n

Lors de mon cursus en école d’ingénieur généraliste, j’ai pu effectuer divers stages longs qui m’ont convaincu de me spécialiser en ingénierie logicielle. Au gré des expériences, cela m’a amené au développement web, au monde de l’open source et au développement d’une expertise dans le langage Python. DiaLog est mon premier projet en PHP / Symfony mais j’ai rapidement su prendre mes marques !

\n

Je n’ai pas de spécialisation particulière en géo-intelligence. Ce qui m’a intéressé avec DiaLog, c’est le lien avec le changement climatique, les infrastructures publiques et le fait de travailler pour le Ministère de la Transition Écologique. J’aime travailler sur des solutions qui règlent les problèmes quotidiens pour les gens. Contrairement à certaines de mes missions précédentes j’arrive à expliquer en quoi consiste DiaLog et en quoi cela pourrait changer leur quotidien (rires).

\n

C’est aussi notre engagement chez Fairness : promouvoir un numérique au service de l’intérêt général, qui ne cherche pas à extraire ou rendre captif mais à servir l’humain. Nous portons haut les engagements d’éco-conception et d’accessibilité de nos solutions. Cela colle avec les valeurs de BetaGouv.

\n

Nous sommes DiaLog, la solution de numérisation de la réglementation routière. Vous représentez une collectivité locale ou un acteur directement intéressé par DiaLog ? Prenez rendez-vous avec l’équipe directement ici.

\n
\n", "date_published": "2025-02-25T00:00:00Z" } , { "id": "https://dialog.beta.gouv.fr/blog/fr/pas-besoin-de-gps-sous-terre/", "url": "https://dialog.beta.gouv.fr/blog/fr/pas-besoin-de-gps-sous-terre/", "title": "Pas besoin de GPS sous la terre", "content_html": "\n
\n

\n
\n

Vous êtes-vous déjà demandé comment vos applications de navigation préférées pouvaient continuer à fonctionner sous un tunnel ou dans le métro ?

\n
\n
\n

\"GPS\nVous séchez ? Ne vous inquiétez pas, l’équipe de DiaLog, solution de numérisation de la réglementation routière, est là pour vous expliquer les dessous des apps de navigation. Commençons par celui sans qui rien ne serait possible : le smartphone.

\n

On s’est habitué à le voir partout : dans nos mains, sur les tables et même dans nos lits. Un utilisateur moyen le toucherait chaque jour plus de 2000 fois. Cette brique de 15 cm de diagonale cache encore pourtant quelques secrets. Nous savons déjà que le smartphone sert à appeler (parfois), envoyer et recevoir de messages, jouer et consulter des contenus. Mais l’essentiel est invisible pour nos yeux : ce sont les capteurs embarqués, de 10 à 20 selon les modèles, qui connectent littéralement l’appareil avec l’extérieur et avec nous-même.

\n

Combien de capteurs embarqués dans votre téléphone pouvez-vous citer ?

\n

Vous connaissez évidemment les caméras, le micro, l’écran tactile, le GPS, le capteur d’empreinte digitale et… ? Saviez-vous par exemple que la plupart des smartphones embarquent aussi un baromètre (pression atmosphérique), un magnétomètre (comme une boussole), un gyroscope, un accéléromètre et un capteur de mouvements ? Sans oublier pour les appareils derniers cris un LiDAR, un capteur Time of Flight pour la distance des objets visés et un détecteur infra-rouge pour la reconnaissance faciale.

\n

Même s’il reste discret, votre smartphone sait et “sent” énormément de choses.

\n

À celles et ceux qui envisagent après avoir lu ces lignes de retrouver le vieux 3310 dans le tiroir des parents, sachez juste que la plupart des données collectées le sont dans un “circuit fermé”. Elles ne “sortent” pas du téléphone et ont pour but principal d’améliorer l’expérience utilisateur. Si par exemple votre écran tactile ne s’éteignait pas automatiquement quand vous le collez à votre oreille, vos conversations commenceraient sans doute par un juron. Idem pour la connectivité au Wifi et au GPS qui est améliorée grâce aux données captées par les autres sensors. Lorsque ces données sortent de votre téléphone elles ne peuvent en principe pas être transmises à n’importe qui et dans n’importe quelles conditions.

\n

L’une des principales raisons du succès incroyable de l’internet mobile vient de la simplicité pour des tiers à créer des services qui fonctionnent sur un smartphone via les applications mobiles. Ce qui distingue d’ailleurs les applications des “sites mobiles” est la possibilité d’émuler directement un certain nombre de fonctionnalités de l’appareil. Quand vous ouvrez Google Maps, le GPS de votre appareil s’active automatiquement. Quand vous ouvrez Snap, c’est la caméra pointée sur votre visage,...En réalité l’application accède à tout un “bouquet” de services internes - capteurs bien sûr mais aussi fonctionnalités de paiement, d’authentification, de mémoire,.... Cet accès est contraint “nativement”. Chaque application passe sous le contrôle impitoyable des ingénieurs de Cupertino ou Mountain View avant d’être autorisée. Les accès aux fonctionnalités les plus sensibles peuvent être refusés s’ils ne contribuent pas à l’amélioration de l’expérience utilisateur ou représentent une intrusion trop profonde dans votre vie privée.

\n

C’est dans ce contexte que s’inscrit la “quête” des applications de mobilité pour garantir une continuité de service lors des trajets souterrains de leurs utilisateurs. Le GPS d’un appareil nécessite d’être connecté à trois satellites pour permettre une géolocalisation précise. Pas de GPS et votre véhicule apparaîtra comme “gelé” dans vos applis de navigation routière préférées. Et ne comptez pas sur elles pour vous dire s’il fallait sortir de préférence à St-Germain-en-Laye ou Poissy sous les tunnels de la Défense. Même problème dans le métro. Être prévenu par exemple de l’arrivée imminente dans la station à laquelle vous devez descendre permet d’éviter un torticolis ou tout simplement ne pas perdre un temps précieux. Difficile également de vous fournir un temps d’arrivée estimé optimum, ce qui est l’une des raisons principales du succès des applications comme Google Maps, Citymapper ou Transit.

\n

Dans un récent blogpost, l’équipe de Transit justement nous explique comment elle a cherché…et trouvé la solution à ce problème d’ingénierie. On est jamais mieux servi que par soi-même : leurs 4 ingénieurs ont recueillis les “signatures vibratoires” de leurs trajets en métro grâce au capteur de vibration et l’accéléromètre de leur smartphone. Une fois les données nettoyées, l’équipe identifie les “fréquences” des différentes phases d’un trajet - à quai, accélération, tunnel, décélération,...- et en déduit les étapes successives du voyageur. Le modèle créé permet ensuite de simuler les différentes stations où devraient être le voyageur. Ces simulations sont comparées avec les relevés manuels des membres de l’équipe qui ont littéralement faits des centaines de trajets annotés à Montréal et New York. Un dernier modèle mathématique, appelé “The Mixer”, évalue la prédiction du type de mouvement, la dernière localisation connue, le moment depuis lequel elle a été mise à jour, ainsi que l’horaire du train. “Résultat : une prédiction correcte de la localisation dans 90 % des cas. Ce modèle offre un suivi en souterrain qui permet de montrer la position sur la carte, de mettre à jour l’heure d’arrivée et d’avertir quand il est temps de descendre, le tout hors ligne et sans envoi de données aux serveurs de Transit”.

\n

Lire l’article sur le blog de Transit.

\n

À signaler que dès 2016 l’équipe de Snips (aujourd’hui dissoute) avait réalisé un travail comparable en utilisant le baromètre d’un smartphone. Grâce au bien connu Effet Venturi, la pression baisse quand le métro accélère et revient à son niveau normal quand le métro ralentit. Il suffisait alors de compter les stations et déterminer ensuite dans quel sens la rame roulait en chronométrant précisément les temps interstations. Après deux stations (ou plus si plusieurs stations successives ont le même temps inter-station) on sait à 90% dans quel sens on se dirige.

\n

Lire l’article de Snips.

\n

\"Mesures\nEt Waze dans tout ça ? L’entreprise a posé des balises, appelées beacon, dans certains tunnels pour permettre aux smartphones de “connaître” leur position plus précisément. Puis comme pour Transit et Snips, le modèle en déduit l’avancée du véhicule dans le tunnel.

\n

Lire l’article de Waze sur les balises.

\n

Des capteurs, des ingénieur·e·s, et vous serez à l’heure !

\n

J’espère que vous avez apprécié cette incursion derrière le rideau de vos outils du quotidien.\nNous sommes DiaLog, la solution de numérisation de la réglementation routière. Vous représentez une collectivité locale ou un acteur directement intéressé par DiaLog ? Prenez rendez-vous avec l’équipe directement ici.

\n

Stéphane Schultz - coach produit DiaLog

\n
\n", "date_published": "2024-11-22T00:00:00Z" } , { "id": "https://dialog.beta.gouv.fr/blog/fr/derriere-la-machine-equipe-dialog/", "url": "https://dialog.beta.gouv.fr/blog/fr/derriere-la-machine-equipe-dialog/", "title": "Derrière la machine - L'équipe de DiaLog", "content_html": "\n
\n

\n
\n

Rassurez-vous ! Il y a bien des êtres humains qui se cachent quelque part derrière cet écran. Nous sommes (à date d'écriture de ce post) même 7 à travailler sur DiaLog, réunis sur ce projet en particulier par l'envie de proposer un service public plus efficace, moderne, adaptés aux besoins du public et aux enjeux de transition écologique de nos mobilités. Comme pour toutes les startup d'Etat, vos contributions, avis et suggestions sont les moteurs de nos travaux, et comme il est plus facile de discuter avec un visage connu qu'avec un austère formulaire en ligne, nous vous proposons aujourd'hui de découvrir qui nous sommes en quelques minutes.

\n
\n
\n

Cela fait un an que nous essayons de vous familiariser avec l’univers de DiaLog : la réglementation routière, les solutions d’aide à la mobilité, l’ouverture des données et la transformation de l’administration publique. Vous êtes déjà plus de 400 à nous suivre sur LinkedIn et à lire ce blog : pas mal pour un début !

\n

Aujourd’hui exceptionnellement nous allons vous parler de nous. Celles et ceux qui conçoivent DiaLog et s’assurent de sa prise en main par les utilisateurs. Comme cela nous espérons que vous comprendrez mieux ce que nous faisons et ce qui nous anime.

\n

\"Logo\nSi vous avez raté le début, DiaLog est une startup d’État qui vise à intégrer les données de réglementation routière dans les services numériques (GPS, logiciel de transport,...).

\n

Une startup d’État est comme son nom l’indique une startup créée dans le giron de Beta Gouv, l’incubateur de services numériques de l’État. Comment nait et grandit une startup d’État ? Un intrapreneur, en l’occurence ici un ingénieur du Ministère de la Transition Écologique (DGITM), décide de consacrer temps et moyen à la création d’une solution numérique pour régler un problème d’intérêt général. Pour DiaLog le problème était : “comment s’assurer que la réglementation de circulation est bien accessible sur les services numériques utilisés par les professionnels et les particuliers ?”.

\n

Débute alors une phase d’investigation durant laquelle l’intrapreneur est accompagné par un coach produit qui va l’aider à “valider que le problème peut être résolu par le numérique en rencontrant des utilisateurs pour qualifier le problème et imaginer des ébauches de solutions”. En l’occurence nous avons travaillé avec les services de Rennes Métropole, de la Ville de Savenay et l’entreprise de transport IDEA en Loire-Atlantique, que nous remercions encore.

\n

Une fois cette première phase validée nous avons attaqué la phase de construction proprement dite : “Constituer son équipe et développer son produit en produisant la première version de la solution sur un terrain d’expérimentation”. C’est cette équipe que nous allons vous présenter ci-dessous.

\n

DiaLog achève en ce moment la phase de construction et débute la phase de déploiement (on recrute !), qui va s’accélérer dans le cadre des Jeux Olympiques de Paris puisque les communes concernées par les jeux verront leurs arrêtés saisis sous DiaLog et leurs données transmises aux services numériques.

\n

Mais revenons à l’équipe, elle est composée de (au 1er février 2024) :

\n

\n
\n\"Photo
\n
\n
\nMathieu Fernandez-Vandewalle - L’intrapreneur\n
\n
\nUn intrapreneur partage son temps entre des missions liées à son poste au Ministère et la direction de la startup. Il prend en charge les relations entre l’administration et l’équipe de la startup, l’apport de connaissances métier et réglementaires et sur l’écosystème public, la gestion du budget, les recrutements et le reporting hiérarchique.

\n

Depuis 2016 au Ministère de la Transition Écologique, d'abord à la gestion du réseau routier national puis en tant que Chef de Projets Innovation sur des projets comme CORIFER, les services en free floating, la conception de tableaux de bord sur la mobilité des français...
\n

\n
\nFormation : ENTPE et Mastère en Ingénierie INSA Lyon\n
\n
\n

\n

\n
\n
\nMathieu Marchois - L’architecte logiciel\n
\n
\nUn architecte logiciel est en charge de la structure du code applicatif et de la base de données. Au début du projet il met en place l’architecture et les interfaces afin de garantir leur bon fonctionnement lors du passage à l’échelle. Je me charge également de la transmission des savoir-faire.

\n

Co-fondateur de Fairness, une coopérative de services numériques qui existe depuis 2019. Notre mission est de concevoir des applications qui ont un impact positif pour la planète et les utilisateurs, plus performantes et plus sobres. La coopérative compte aujourd’hui 8 développeurs et 1 product manager.\n

\n
\nFormation : Master architecte logiciel INSTA après un BTS en informatique\n
\n
\n
\n\"Photo
\n

\n

\n
\n\"Photo
\n
\n
\nAurélie Baton - L’UX Designer\n
\n
\nUne designer UX fait de la recherche utilisateur et de la conception UX (expérience utilisateur) et UI (interfaces utilisateurs), des maquettes, de l’éco-conception. Je fais également de la formation et j’enseigne à Rouen. Je travaille avec Beta Gouv depuis octobre 2022.

\n

Aurélie est également membre de Designer Éthiques, une association qui favorise l’éco-conception par la recherche, l’organisation d’évènements, la publication d’un guide. Auparavant : 12 ans chez IBM en tant qu’UX designer.\n

\n
\nFormation : Master 2 à Paris en design de documentation\n
\n
\n

\n

\n
\n
\nLéa L. - La développeuse back end\n
\n
\nDéveloppeuse chez Fairness depuis août 2023 : c’est moi qui m’occupe de tout ce qui ne se voit pas derrière l’interface visible de DiaLog. Je suis passée par Le GRETA, un programme de reconversion d’un an. Auparavant je ne faisais pas du tout d’informatique : j’étais dans le secteur médical ! Mais je retrouve dans mon activité chez Fairness le côté intérêt général qui me plaît.\n
\n
\nFormation : Reconversion avec Le GRETA - Titre professionnel Développeur Web et Web Mobile\n
\n
\n
\n\"Placeholder\"
\n

\n

\n
\n\"Photo
\n
\n
\nFlorimond Manca - L’ingénieur logiciel et éco-concepteur web\n
\n
\nAprès une première expérience comme développeur dans le domaine du monitoring cloud, j'ai rejoint la coopérative Fairness en 2021. J'intègre dans ma pratique les enjeux du Numérique responsable : code, design et choix fonctionnels visant à réduire les impacts environnementaux et sociaux du numérique. Au quotidien, je définis et mets en oeuvre les meilleures solutions techniques en lien avec les objectifs définis avec le reste de l’équipe et dans une approche d'écoconception.\n
\n
\nFormation : Ingénieur Centralien - 3ème année de spécialisation en informatique\n
\n
\n

\n

\n
\n
\nJohan Richer - Le product manager\n
\n
\nMon rôle est de comprendre les besoins de l’utilisateur pour aider à orienter les produits dans la bonne direction. Au quotidien, je discute avec tous les membres de l’équipe pour synthétiser les inputs, prioriser et suivre le réalisé. Je ne code pas. Depuis 7 ans chez Multi (anciennement Jailbreak) qui rassemble 8 personnes développeurs et product owners dans une coopérative qui conçoit et développe des services publics numériques.

\n

Parmi mes activités associatives en lien avec le numérique : CartONG qui conçoit des cartographies pour l’humanitaire.\n

\n
\nFormation : études en relations internationales et géopolitique\n
\n
\n
\n\"Photo
\n

\n

\n
\n\"Photo
\n
\n
\nStéphane Schultz - le coach produit\n
\n
\nLe coach produit accompagne l’intrapreneur depuis le jour 1 jusqu’à la mise en orbite de la solution : il garantit le bon déroulement de la phase d’investigation, aide à la définition de priorités et au maintien des objectifs en matière de satisfaction usager et impacts environnementaux. Il prépare la stratégie de déploiement.

\n

Stéphane est également consultant (15marches) et auteur d’une newsletter hebdomadaire sur l’innovation. Auparavant il a travaillé chez un opérateur de transport.\n

\n
\nFormation : urbaniste\n
\n
\n

\n
\n", "date_published": "2024-03-14T00:00:00Z" } , { "id": "https://dialog.beta.gouv.fr/blog/fr/ouvertures-stephanschultz-mathieufernandez/", "url": "https://dialog.beta.gouv.fr/blog/fr/ouvertures-stephanschultz-mathieufernandez/", "title": "Ouverture(s)", "content_html": "\n
\n

\n
\n

Un nombre grandissant d’organisations, publiques ou privées, prennent part à des démarches visant à mettre à disposition de manière libre certaines ressources, qui pourront dès lors évoluer au gré de la créativité et de l’intelligence collective. Que ce soit par principe philosophique, pour se mettre en conformité avec la loi ou dans l’intention d’en retirer des bénéfices, ces ouvertures supposent - pour réellement fonctionner - bien plus que de simplement libérer l’accès des moyens internes. Par Mathieu Fernandez, intrapreneur et Stéphane Schultz, coach produit, Dialog.beta.gouv.fr.

\n
\n
\n

Lorsque l’on parle d’innovation ouverte, la discussion est souvent centrée sur des démarches comme “open data”, “open source”, “hackathon” ou encore “co-design”.

\n

Ces démarches agissent tels des pôles d’attraction pour certains ou au contraire un repoussoir pour d’autres. Au mieux ces derniers imaginent-ils une pause agréable dans leur (vrai) travail, durant laquelle l’organisation va s’efforcer d’avoir l’air innovant vis-à-vis de ses salariés, ses fournisseurs ou ses clients. Ils croisent les doigts en espérant que cela ne va pas leur demander trop de temps et d’énergie, et que le buffet sera correct. Ils sourient peut-être intérieurement en pensant au nombre de fois où leur organisation s’est montrée “fermée”, y compris en interne, en refusant de communiquer des données ou d’affecter des moyens sur un projet qui n’était pas “inventé ici et par nous”.

\n

Ces démarches ont toutes un point commun : l’ouverture. Et l’ouverture ne va pas de soi dans une organisation.

\n

Une métaphore que j’utilise souvent lorsque je présente une démarche d’innovation ouverte en atelier est celle de la location de courte durée de son propre logement. Un rapide sondage préalable montre une écrasante majorité de personnes ayant déjà loué le logement d’une autre personne et une infime minorité gens qui ont déjà loué leur propre logement à des inconnus.

\n

Je demande alors aux premiers d’imaginer qu’ils doivent louer leur logement le week-end suivant à des inconnus, moyennant paiement. Les réticences ne tardent pas à s’exprimer : “je dois cacher des choses d’abord”, “je dois réparer certains équipements”, et même plus rarement “que vont penser les voisins ?”.

\n

Viennent ensuite des questions plus rationnelles : “que se passe-t-il en cas de vol ou de dégradation ?” “comment faire avec les clés ?” “comment facturer le ménage ?” et de conclure parfois “mon logement n’est pas si intéressant que cela” en reportant le projet à plus tard. Vérification faite, la minorité qui avait affirmé louer son logement loue en réalité une chambre de bonne ou un studio meublé inoccupé le reste du temps.

\n

Ces arguments sont grosso modo ceux que vous entendrez de la part des personnes directement concernées par un projet d’ouverture des données, de hackathon ou de toute démarche nécessitant d’ouvrir des ressources à l’extérieur : “Ok pour ouvrir, mais uniquement à des proches ou seulement s’il s’agit de la chambre de bonne. Pas question de laisser des inconnus dormir dans le lit du grand, même s’ils paient”. Ils ne les exprimeront sans doute pas en ces termes car personne n’aime passer pour une organisation fermée ou pire, pour un professionnel fermé.

\n

Lire ici Palmarès des arguments anti open data par Open Data Canvas

\n

En résulteront au mieux des négociations qui conduiront à des démarches souvent hors sol, éloignées des métiers de l’entreprise, et dans lesquelles celle-ci n’ouvrira réellement que son porte-monnaie (et encore).

\n

\"Restitution

\n
Restitution du hackathon sur les aires de livraison © DiaLog
\n

Et si le sujet de l’ouverture de ses ressources n’était pas une question de stratégie a posteriori mais de conception a priori ?

\n

Pour filer la métaphore précédente, si vous passiez plus de temps à concevoir et équiper votre logement pour qu’il puisse être facilement utilisé par d’autres plus tard ? Si vous écriviez dès maintenant le “guide du visiteur”, en indiquant les choses à savoir, les règles à respecter, et aussi comment passer un bon moment dans votre ville ? Si vous équipiez votre logement avec des accessoires standards, robustes et faciles à remplacer ? Des accessoires dont tout le monde connaîtrait déjà le fonctionnement. Si vous commenciez par le louer à des proches, en prenant soin de bien recueillir leurs remarques et observer leurs comportements ?

\n

Cela vous permettrait d’améliorer votre capacité à louer votre logement tout en le rendant plus attractif. Louer ensuite à des inconnus serait une marche nettement moins haute à franchir.

\n

C’est ce que font les organisations qui se conçoivent comme “ouvertes” par design. Elles consacrent d’importants moyens à produire des ressources - outils, données, infrastructures, mais aussi des tutoriaux, kits de développement, interfaces... - pour permettre à d’autres acteurs de prospérer en les réutilisant. Elles privilégient l’utilisation de standards et quand ces standards n’existent pas elles contribuent à en créer et diffuser un nouveau.

\n

Attention il ne s’agit pas là nécessairement de gratuité et d’accès libre. Toutes les ressources ouvertes ne sont pas des communs et toutes les organisations ouvertes ne sont pas à but philanthropique.

\n

Google ou Amazon par exemple fournissent des ressources et places de marché à leurs développeurs ou leurs marchands et en tirent de très substantiels revenus. Leur modèle économique est même construit sur le succès de leurs réutilisateurs. Ces derniers deviennent à la fois le client et le produit, en améliorant l’offre globale de services dans un cercle vertueux. Pensez aux App Stores de Google ou Apple et à la marketplace d’Amazon. À l'inverse, une organisation à but non lucratif peut se comporter de manière rigoureusement “fermée” en concevant et délivrant des services qui ne peuvent ni être modifiés ni réutilisés par ses utilisateurs.

\n

Et pour une collectivité publique ?

\n

Le concept d’État-plateforme a été repris en France par Henri Verdier et Pierre Pezziardi dans leur ouvrage de 2017 “Des startups d’État à l’État-plateforme” (à retrouver dans la liste de ressources ci-dessous). Il reprend schématiquement les principes des plateformes numériques théorisés par l’éditeur Tim O’Reilly en 2010 :

\n\n

Que votre organisation soit publique ou privée, ces principes doivent devenir des choix par défaut, entretenus par une culture de l’ouverture qui prône le droit à l’expérimentation et le droit à l’erreur. Cela n’empêche pas bien évidemment d’y déroger, mais toute dérogation sera dès lors précédée d’un échange sur ses raisons stratégiques, techniques, managériales.

\n

Vous ne savez pas par où commencer ? Vous pouvez déjà lister toutes les ressources internes à votre organisation et vérifier qu’elles sont bien accessibles en interne par défaut à tous vos collaborateurs. Ensuite vous pouvez développer de bonnes pratiques comme la documentation de vos ressources et la possibilité pour tous de contribuer. Les lignes hiérarchiques et les silos managériaux se dissolvent ainsi pour céder la place à des logiques de projets : chacun collabore et contribue selon ses moyens pour l’aboutissement et l’enrichissement d’un projet. Enfin vous pouvez ouvrir tout ou partie de ces démarches à l’externe, en contrôlant toujours les différents niveaux d’accès et de contribution que vous autorisez.

\n

L’ouverture par nature : le projet des start-up d’Etat

\n

Dans le domaine des données de transport, la transition s’opère lentement vers des modèles plus ouverts. La prise de conscience des acteurs à ce sujet s’incarne dans la quasi systématisation des démarches “open data”, projets qui consistent dans leur majorité à exposer des données à l’aide de plateformes numériques.

\n

On peut juger que cette dynamique est encourageante, mais on peut aussi craindre qu’elle ait pour effet de nous coincer au milieu du gué : quel usage pouvons nous faire d’une ressource conçue de manière interne par une organisation, pour répondre à des besoins internes, lorsqu’elle nous est mise à disposition ? La fongibilité de ces données dans un ensemble d’information plus large, leur interopérabilité en langage technique, ne sera possible qu’au prix de fastidieuses corrections et transformations. Une dette que peu d’acteurs seront prêts à payer tant la rentabilité de cet investissement est difficile à entrevoir.

\n

Il est donc naturel de voir apparaître des projets tels que transport.data.gouv, dont le fonctionnement est d’aider les autorités organisatrices des transports (AOM) à franchir la marche suivante de l’ouverture de leurs données : standardiser et assurer la qualité des informations soumises au partage. Cet exemple est intéressant à plusieurs titres, et illustre notamment comment les systèmes ouverts échappent au contrôle de ceux qui les opèrent.

\n

Comme tout Point d’Accès National (“PAN” dans le jargon), la première mission de transport.data était d’ouvrir les données d’offre de transport en commun dans le standard NeTEx. Figure imposée, donc, qui pose son lot de difficultés quand on sait qu’en la matière le standard de référence est le GTFS, un standard américain développé par Google et l’autorité des transports de la ville de Portland.

\n

C’est dans ce contexte que la logique des start-up d’État prend toute son importance. Contrairement à un projet d’ouverture de données qui serait le fruit d’une commande politique dont la visée finale serait la mise en conformité de l’organisation à de nouvelles contraintes réglementaires, les start-up d’État sont pensées dans des logiques d’impact. “Le but final de transport.data c’est de remplir les bus”, pouvait-on ainsi lire dans une interview de l’équipe projet. Une fin qui justifie parfois de s’écarter du cahier des charges initial d’un projet, agilité qui est permise aux start-up d’État.

\n

\"La

\n
La page de data.gouv.fr sur le site de beta.gouv
\n

Ouvrir la réglementation de circulation : la longue route

\n

Les difficultés d’accès à la réglementation routière sont quotidiennement responsables d’aléas dont les conséquences s’échelonnent d’un simple timing contrarié à l’accident grave. Sur les plus d’un million de kilomètres de routes qui composent le réseau français, cette problématique est suffisamment prégnante pour pousser les autorités à agir, mais quels sont alors les leviers dont elles disposent ?

\n

L’ensemble des règles, permanentes ou temporaires, qui organisent les circulations étant religieusement consignées par les gestionnaires dans des arrêtés, suffirait-il de rendre ces documents accessibles ? Ce qui serait heureux dans la mesure où la loi oblige à les publier en ligne. Admettons.

\n

Cette conclusion se heurte malheureusement bien vite à une réalité : les arrêtés de circulation ne sont pas faits pour être lus. En tout cas, pas par le commun des mortels, l’information qu’ils comportent étant plutôt destinée aux forces de polices et aux professionnels chargés d’installer la signalisation en conséquence.

\n

Les arrêtés de circulation sont en effet un cas typique d’information “non ouvrable”, qui n’a pas été pensée dans une logique d’ouverture. Leur rédaction n’est que très peu contrainte, on y trouve parfois des tournures vernaculaires ou des références tout à fait locales (“mais oui, vous savez, la section de la rue entre le monument aux morts et le dépôt de bus!”) qui n’auront aucune résonance pour le lecteur lambda. Quel impact, dans ce contexte, pour la publication en ligne de ces documents ?

\n

Comme toutes les start-up d'État, DiaLog ne peut se contenter d’être un outil de plus au service de la dématérialisation. Trouver des solutions au problème suppose d’accompagner davantage nos utilisateurs et toute une catégorie d’acteurs publics. Nous devons les aider à réaliser le “dernier km” de leur démarche d’ouverture de données, en leur permettant de s’approprier les standards tout en garantissant leur qualité. Leur permettre de partager leur logement sans rien perdre en confort et en sécurité.

\n

C’est la mission que nous poursuivons chez DiaLog avec nos partenaires. Rejoignez-nous !

\n

Envie d’aller plus loin dans la compréhension de l’open data et de ses enjeux ?

\n

Merci à Sandrine Mathon, Céline Faivre, Claire Gallic, Jean-Marc Lazard, Simon Chignard, Samuel Goëta, Joël Gombin pour le partage de leurs références utiles :

\n

Les archives d'InternetActu par feu la Fing : lien avec des articles aussi bien sûr :

\n\n

Également les archives Gov US, sur l'open gov plan avec les V1 de 2010 (l'open data étant un des 3 "moyens" de l'open gov aux US) : lien

\n

Le blog LiberTIC de Claire Gallic : lien

\n

Le blog d’Henri Verdier : lien

\n

Le livre d’Henri Verdier et Pierre Pezziardi - Des startups d’État à l’État plateforme : lien

\n

Les livres de Simon Chignard - Open data et Datanomics : lien

\n

Le nouveau livre de Samuel Goëta : Les données de la démocratie : lien

\n

Le TED talk d’Hans Rosling : lien

\n

Et également un documentaire de la BBC à son sujet : lien

\n

Plan d'action G8 sur l’ouverture des données publiques : lien

\n

La conférence de Sébastopol : lien

\n
", "date_published": "2024-02-08T00:00:00Z" } , { "id": "https://dialog.beta.gouv.fr/blog/fr/itw-nicolas-berthelot-IGN/", "url": "https://dialog.beta.gouv.fr/blog/fr/itw-nicolas-berthelot-IGN/", "title": "La carto en commun - Interview de Nicolas Berthelot", "content_html": "\n
\n

\n
\n

De formation sociologue, Nicolas a travaillé auparavant dans une entreprise de Data intelligence puis chez transport.data (Beta Gouv).\nIl est aujourd’hui responsable de la Fabrique des Géocommuns à l’IGN (Institut national de l'information géographique et forestière), un incubateur qui accompagne depuis 2022 des intrapreneurs dans la construction de services publics numériques promouvant des communs géographiques. Il nous explique comment la Fabrique aide à transformer l'usage des données de l'IGN.

\n
\n
\n

Qu’est-ce que la Fabrique des Géocommuns ?

\n

C’est déjà l’incubateur de startups d’État de l’IGN (Institut national de l'information géographique et forestière). Il répond à un enjeu stratégique de changement des manières de faire à l’Institut. L’Institut a déjà connu deux révolutions :

\n

L’open data et la gratuité d’accès aux données, qui provoque un changement de modèle économique mais aussi un changement de lien avec les utilisateurs. Avant nous avions des clients, par exemple des sociétés privées, qui achetaient nos produits. Le fait de passer en open data avec licence ouverte amène une disruption de cette relation. La Fabrique des Géocommuns doit être un outil d’action dynamique de lien avec les usagers des services qui sont produits par l’IGN.

\n

Le deuxième chantier majeur est le fait qu’on n’est plus tout seul à être capables de produire des données géolocalisées. L’IGN a été pensé comme une grosse usine de production de données topographiques qui décrivent le territoire, qui ont été ensuite déclinées en cartes papier. Il faut imaginer que dans les années 90 les agents de l’IGN, ouvriers d’État, allaient sur le terrain pendant 3 mois pour numériser tous les éléments du territoire en mode “commando”, ils arrivaient à 100 et cartographiaient département par département.

\n

Le fait que les collectivités et d’autres administrations soient aussi capables de cartographier leurs bâtiments et leurs routes a motivé l’évolution. L’IGN s’est rendu compte qu’il n’était plus possible de fonctionner en mode “on est une usine de production, il faut qu’on produise en commun des ressources”. On doit plutôt se dire : “on a produit des référentiels de données qui sont super, on est capables sans doute de s’interfacer avec plein de canaux pour constituer un commun, ce qui suppose aussi de ne plus être tout le temps parfaitement au centre”.

\n

Ce n’est parfois pas évident ! Il y a plein de sujets sur lesquels on n’arrive pas encore à changer de paradigme.

\n

Du coup la Fabrique avait pour but de proposer des manières différentes de faire, en illustration et en accompagnement. La Fabrique n’a pas pour vocation de prendre tous les trucs de l’IGN et les passer à la moulinette des communs et des startups d’Etat. C’est plutôt de lancer des chantiers qui vont être des illustrations de manière autres de développer des produits de données géolocalisées.

\n

Est-ce que les projets incubés doivent nécessairement réutiliser les données de l’IGN ?

\n

On ne se pose pas trop de contraintes. La méthode est l’approche Beta Gouv : centrée sur l’utilisateur final, motivée par la résolution d’un problème réel, majeur et actionnable, puis nous faisons appel à un intrapreneur qui sera accompagné d’une équipe constituée pour l’occasion.

\n

Un agent de l’IGN peut candidater mais c’est aussi ouvert aux agents d’autres ministères qui veulent bosser sur des données géolocalisées. Par exemple, nous avons un agent du Cerema qui veut aider les EPCI à cartographier leurs zones d’activités en faisant une investigation à l’IGN pour voir comment on peut les aider. Potentiellement les sources de données ou les outils cartographiques qui seraient utilisés dans ce projet par le Cerema ne seraient pas forcément ceux de l’IGN.

\n

L’enjeu est plutôt d’avoir la méthode Beta Gouv en point focal, être centré utilisateur et se concentrer sur les usagers de la ressource. On s’est dit que ce n’était pas idiot de prendre cette méthode pour faire des communs : “comment entretenir des ressources avec des règles qui fassent que tous les gens qui alimentent la ressource ne se sentent pas lésés ?”.

\n

La stratégie c’est d’être centré sur les besoins, parce que de cette manière tu es capable de capter de la collaboration. Si les gens ont vraiment besoin de ton logiciel ou de ta base de données, à la fin ils sont en capacité de t’aider en partie sur le développement de la ressource auquel tu as contribué.

\n

Par exemple, le produit emblématique c’est Panoramax : le “Street View” libre avec plus de 100 contributeurs tiers, collectivités et personnes physiques bénévoles qui déposent des photos sur des espaces de stockage pour photo-cartographier le territoire. C’est vraiment le cas typique où on essaie d’inciter les gens à contribuer. La proposition de valeur pour les contributeurs est “on floute tes photos, on les héberge, on te permet de les visualiser et prochainement on lui permettra d’extraire la position de certains éléments visibles comme des panneaux”. En contrepartie, les gens donnent au public leurs photos.

\n

C’est vertueux car potentiellement sur un même espace plusieurs acteurs ont intérêt à mettre à jour ces bases de données. Se pose alors la question des bases de données routières. La cible principale de Panoramax est d’avoir une vision de où sont les panneaux de circulation, la signalisation verticale et horizontale, et potentiellement les détecter par l’intelligence artificielle, et les localiser dans l’espace.

\n

Avez-vous vocation à couvrir tout le territoire avec un produit comme Panoramax ?

\n

Ce qu’on essaie de développer avec les startups d’État c’est un service public qui a pour but de combler les trous que potentiellement le marché n’aurait pas tendance à combler. À Paris par exemple, les grandes plateformes privées passent déjà plus d’une fois par an pour mettre à jour leurs bases photographiques.

\n

En revanche, dans les territoires ultra-marins des contributeurs s’emparent de Panoramax pour couvrir des territoires qui ne sont absolument pas photo-cartographiés. Dans l’offre de service de la startup d’État, il y a de l’accompagnement à la production des données. Si tu équipes par exemple tes camions-poubelle avec des caméras qui coûtent 500€ tu peux faire une première couverture qui va permettre de localiser tes adresses.

\n

\"Capture

\n
Capture d'écran du site de Panoramax © Panoramax
\n

Est-ce que ces produits alimentent ensuite la base de données BDTopo ?

\n

Pour l’instant cela se développe de manière parallèle. Pour Panoramax les photos sont géolocalisées par GPS mais ne sont pas corrigées avec les données de BDTopo. Les informations qu’on va pouvoir extraire des photos avec des outils vont permettre à terme d’alimenter le référentiel routier de l’IGN. Le but est d’avoir une couverture totale du territoire.

\n

L’enjeu de l’IGN c’est que toutes les ressources qu'il développe (bases de données, BAN, BDTopo, BD Forêt,...) aient une garantie de qualité et puissent recevoir des contributions autres que celles d’agents IGN. Par exemple pour identifier une nouvelle route, une nouvelle école, ...

\n

C’est le cas dans le Gard et dans l’Hérault avec les SDIS (pompiers NDT), où il y a des entités avec lesquelles on institue une relation de confiance. Nous avons créé des guichets spécifiques pour les retours et les contributions de nos partenaires, par exemple “ici il y a une information qui n’est pas correcte par rapport à l’adressage”. Le but est de simplifier au maximum l’expérience de contribution de nos partenaires.

\n

C’est un grand chantier mené au travers de la Géoplateforme et avec son incarnation web cartes.gouv.fr, pour faciliter l’amélioration des référentiels par tous les usagers des produits de l’IGN. Ca dépasse largement la Fabrique, nous on s’interface par exemple en accompagnant la startup BAN qui développe la Base d’Adresse Nationale, qui a pour but de non seulement produire la BAN mais intégrer des retours par exemple de Here ou Tom Tom : ces gens font confiance à la base de données, il faut qu’ils puissent faire remonter les problèmes et à la fin on sera tous gagnants.

\n

Comment fonctionnent ces retours de réutilisateurs ?

\n

Cela dépend des interlocuteurs et des types de contribution.

\n

Sur Panoramax par exemple, les gens qui veulent alimenter ont juste besoin de créer un compte. Pour d’autres référentiels comme la BD Topo, nous sommes dans une démarche de conventionnement. Nous avons des délégués régionaux qui sont capables de rapidement élaborer des procédures qui permettent de faire du partage. Pour la Base Adresse Nationale, avec des entreprises comme TomTom ou Here on est beaucoup plus dans des logiques d’expérimentation.

\n

Comment se passe le déploiement et le passage à l’échelle des solutions expérimentées ?

\n

Le bon exemple c’est la BAN. Tout le monde nous disait que ça allait être extrêmement simple. Tu as un fichier .csv, tu as 10 000 points par commune, on est sur un objet simple. En réalité même si une adresse est plus simple qu’une route, ça a quand même été un enfer à réaliser, mais l’équipe y est arrivé.

\n

Elle a d’abord réalisé un POC (proof of concept, NDT) pour tester, en fournissant un outil aux communes qui leur permettait d’éditer, de manière simple mais normalisée, un référentiel d’adresses. L’outil permettait aussi de récupérer des données produites par d’autres moyens.

\n

\"Le

\n
Le site adresse.data.gouv.fr © Base Adresse Nationale
\n

Une fois créée la dynamique qui permet de faire remonter des données fiables sur l’adressage et un premier objectif de 20% du territoire atteint, il est possible de procéder par décret pour cadrer les choses. Au moment où le décret sort nous avions déjà 50% des communes couvertes et 70% de la population. La force de la loi permettra d’atteindre les 90%.

\n

C’est un schéma qui est sans doute le bon, à suivre pour les startups d’État qui font de l’expérimentation. On répond bien aux problèmes du terrain, et à partir de là des gens peuvent témoigner en faveur de la solution développée, puis ensuite mettre une dimension plus contraignante pour à la fin atteindre les 100%. Ça c’est le bon procédé, mais il ne marche que quand tu as réussi à attirer une adhésion énorme d’abord.

\n

Est-on capable de déterminer la date d’achèvement ?

\n

Ce n’est pas évident, on se pose les mêmes questions (rires).

\n

Prenons l’exemple du dernier arrivé Bat-ID (Référentiel National des Bâtiments), une des grosses startups de la Fabrique. Le principe est de faire l’équivalent de la BAN avec les bâtiments. Les bâtiments sont encore un peu plus compliqués que les adresses à intégrer dans un référentiel. Le cadastre a une définition qui n’est pas cohérente avec des réalités physiques, et ces définitions et représentations peuvent varier même au sein de l’État. Par exemple entre l'IGN et Bercy la représentation est différente : “nous on voit du ciel, eux ils voient du sol”. Au-delà de ça il y a encore d’autres acteurs comme les opérateurs de réseaux et télécoms qui vont parler en boîtiers, connexions, ...

\n

Il y a eu un travail de 2 ans pour poser des définitions et donc les jalons d’une première base. Il existe désormais une base de données de 44 millions de bâtiments avec des identifiants. Mais en réalité cette base nécessitera des corrections venant du terrain pour être suffisamment complète et fiable. Notre tactique pour y arriver est d’attirer les acteurs qui ont le plus d’agilité dans ce rôle d’expérimentateur, pour leur donner une forme d’avance sur le marché. L’année dernière, l’équipe a beaucoup travaillé avec les ADS (Autorisation de droits du sol) et les diagnostics DPE pour enclencher de premiers canaux de mises à jours de la base de données. En 2026 tu auras des dizaines de bases de données de l’État qui seront connectées au Référentiel National du Bâtiment.

\n

En quoi DiaLog pourrait être utile à la démarche des géo-communs ?

\n

Quand je suis arrivé à la Fabrique on m’a dit : “tu as 3 chantiers" :

\n\n

Chez data.gouv ma mission portait déjà sur le référentiel routier et cela avait été très difficile. Le sujet est tellement complexe avec un objet qui concerne des acteurs hyper hétérogènes qui ont une conception très différente de ce qu’est une route, on en est jamais sorti. Du coup quand je vois DiaLog je me dis que quand même, c’est le truc qui peut mettre le pied à l’étrier de la conception de ce Référentiel. Tu as la définition légale de ce qu’est une voie, qui peut permettre d’avoir un référentiel partagé qui donne envie à d’autres acteurs de s’en servir et contribuer.

\n

A l’IGN on a une vision de l’information routière très orientée services d’urgence car aujourd’hui nous participons au grand projet NexSIS avec l’ensemble des SDIS pour avoir un calculateur d’itinéraires fiable.

\n

Aujourd’hui, je pense que ce qui fait défaut à la puissance publique c’est de disposer d’un outil à l’image d’OpenStreetMap qui puisse permettre l’entretien de bases de données collaboratives. C’est la promesse de la Géoplateforme et la Fabrique aura alors pour rôle de fédérer des collectifs pour utiliser cette nouvelle infrastructure !

\n
\n", "date_published": "2024-01-25T00:00:00Z" } , { "id": "https://dialog.beta.gouv.fr/blog/fr/itw-benoit-queyron-transport-data/", "url": "https://dialog.beta.gouv.fr/blog/fr/itw-benoit-queyron-transport-data/", "title": "Ouvrir les données de transport - Interview de Benoît Queyron", "content_html": "\n
\n

\n
\n

Transport.data.gouv est également connu sous le nom de PAN, pour "Point d'Accès National" (aux données de transport). Benoît Queyron, chef de projet services numériques de mobilité à la DGITM, est depuis 2021 à la tête de l'équipe qui vous permet d'avoir accès aux horaires de transport, aux localisations des aires de covoiturage ou de bornes de rechargement dans vos applications smartphone préférées. Pour en arriver là, il aura fallu définir des priorités, connaître sa cible et savoir bien s'entourer : il nous partage la recette de ce succès dans notre premier billet de blog de 2024 !

\n
\n
\n

D’où vient l’idée de lancer transport.data ?

\n

Transport.data.gouv.fr est le Point d’Accès National (PAN) aux données de transport en France, l’existence de ce service relève d’une obligation juridique européenne. Ce type d’infrastructure numérique existe dans tous les états d’Europe à des stades de développement différents, mais pour tous les Etats la logique est la même : centraliser l’accès à la donnée de transport, proposer les données de l’offre de transport tous modes et toutes infrastructures.

\n

On ne s’étend donc pas sur le champ de la demande, la fréquentation ou la consommation électrique des bornes de recharge : Le PAN se concentre sur les horaires, les tarifs, les perturbations, les infrastructures comme les aménagements cyclables, stationnement vélo, aires de covoiturage, etc.

\n

Quelles sont vos priorités en matière de modes de déplacement ?

\n

Nous ne sommes pas encore exhaustifs et avons une stratégie de priorisation. Par exemple nous avons 98% des réseaux de transport français pour les horaires statiques, pour le temps réel et les perturbations nous en sommes à la moitié. 100% des aires de covoiturage sont disponibles. Pour le stationnement nous avons essentiellement la donnée sur les parc-relais.

\n

Transport.data reste concentré sur les données de mobilités durables. Le stationnement des voitures particulières ou le transport aérien ne sont pas notre priorité.

\n

\"Abribus

\n
Abribus pace de la gare à Angoulême © Arnaud Bouissou / Terra
\n

Quelles sont les cibles visées par votre service ?

\n

Nous voulions faciliter l’utilisation des données de déplacement par des calculateurs d’itinéraires. D’autres usages sont possibles, mais la cible prioritaire ce sont les solutions de navigation et celles et ceux qui les fabriquent : Maps, Hove, Cityway, Bing, Moovit, Transit, …

\n

Depuis 2017 nous avons poursuivi un objectif simple : mettre les horaires de bus de toutes les autorités organisatrices des mobilités (les villes et métropoles responsables de l’organisation des transports) sur le PAN, sans regarder les licences ou la qualité des données. Et aussi constituer un “CRM” de l’ensemble des acteurs du transport, car nulle part n’existait un simple annuaire permettant de joindre tous les acteurs de la donnée locale de transport. Maintenant c’est fait.

\n

Nous avons développé des solutions et des process pragmatiques pour récupérer les données auprès des producteurs :

\n\n

Par la suite nous avons commencé à standardiser nos process pour passer à l’échelle. De méthodes manuelles nous sommes passés à des outils plus automatisés entre les mains des producteurs de données.

\n

Pour les données statiques nous mettons à disposition un fichier de données classique, tandis que pour les données temps réel nous proposons un service de proxy aux collectivités : on met en cache leurs données et on redistribue ainsi à 40, 80, 100 utilisateurs. Cette méthode rassure les collectivités en particulier pour les données temps réel.

\n

Cela représente pour nous un coût modique en terme de serveurs. Cf. les statistiques détaillées du PAN : transport.data.gouv.fr/stats

\n

En quoi transport.data est différente des autres startups d’État ?

\n

Nous appliquons les mêmes méthodes que toutes les startups d’État. J’ai beaucoup appris des enseignements de beta.gouv (l’organisation en charge des startups d’État) notamment sur la conduite d’un projet numérique. Ce ne sont pas des choses que l’on apprend à l’École des Travaux Publics !

\n

Le projet transport.data suit donc de près les axes communs à l’ensemble des services numériques développés dans la communauté beta :\nChaque décision est justifiée par le besoin utilisateur, nous passons beaucoup de temps à étudier et comprendre ce besoin pour ne dépenser que le minimum d’énergie à valider ce que nous pressentons comme correct. Autre aspect important : nous fonctionnons en équipe de manière transverse et pluridisciplinaire, cela permet à chacun de bénéficier de points de vue différents sur la problématique à traiter.

\n

Sinon, tous les produits de beta.gouv sont différents. Transport.data a la particularité de mettre à disposition de la matière brute, formatée à destination d’une cible “calculateur d’itinéraires”. Là où d’autres produits mettront l’accent sur la mise à disposition d’un ensemble de services, nous préférons rester sur des formats simples en garantissant cependant la disponibilité et la qualité des données.

\n

De ce fait, le principal aspect serviciel de transport.data est dans l’accompagnement des collectivités territoriales dans l’ouverture des données et l’industrialisation de leur mise en qualité. Pour cela nous avons créé des outils (voir menu “outils”) pour vérifier et valider ses données.

\n

Aujourd’hui la startup est dans sa phase de “run” : sa phase de fonctionnement. L’accélération est achevée, on est dans la phase d’industrialisation. Il y a toujours des investissements et du développement, mais dans l’ensemble le produit est mûr.

\n

Qui sont les utilisateurs de transport.data ?

\n

Techniquement on parle plutôt de « réutilisateurs » des données puisqu’il s’agit d’entreprises qui vont télécharger les données du PAN pour les utiliser dans leurs applications d’aide à la navigation par exemple.

\n

L’une des spécificités est que chez transport.data nous considérons que l’open data ne doit pas imposer aux utilisateurs de s’authentifier et encore moins d’indiquer l’usage qu’il va faire des données qu’il télécharge. Si tu habites à Strasbourg et veux un GTFS à Avignon tu peux le télécharger sans créer de compte. C’est ça, pour nous, l’« open » dans open data. La contrepartie, c’est que nous ne connaissons pas toujours ces réutilisateurs…

\n

On ne les connaît pas tous mais on en connaît beaucoup : nous discutons avec 40 réguliers du PAN au moins une fois par semaine. Google Maps est le plus gros réutilisateur, il absorbe quasiment tous les jeux de données et les expose. C’est l’esprit et la lettre de l’article 122 de loi Climat et Résilience : permettre aux calculateurs d’itinéraires d’accéder aux données de transport public, et par là même permettre à des réseaux de taille et moyens à modestes d’être “exposés” sur des solutions grand public comme Google ou Moovit.

\n

Ces réutilisateurs « massifs » sont donc essentiels pour nous. Nous avons d’ailleurs (c’est en projet) récemment lancé des ateliers pour développer un espace utilisateur sur le PAN, soumis à authentification. L’accès aux données restera ouvert à tous sans authentification mais l’espace utilisateurs offrira des services utiles pour un profil de gros utilisateurs identifiés : des notifications de mise à jour, des suppressions, des rapports de validation.

\n

Le principe à retenir, c’est que la Loi d’Orientation sur les Mobilités (article 25) cible d’une part les autorités organisatrices en disant : “ouvrez vos données” et d’autre part les réutilisateurs comme les solutions de navigation en disant : “utilisez le PAN”.

\n

Aujourd’hui par exemple 120 réseaux de transport public sont exposés sur Google Maps.

\n

\"Affichage

\n
Affichage du trafic dans le poste d'aiguillage de la gare des Aubrais © Arnaud Bouissou / Terra
\n

Quels sont les liens entre DiaLog et transport.data ?

\n

Tout part d’un amendement au Parlement devenu ensuite l’article 122 sur la réglementation de circulation des Poids Lourds. En élaborant le décret d’application pour son dernier alinéa s’est posée la question du moyen d’action pour le mettre en œuvre. Cela demandait un métier semblable à ce que faisait déjà le PAN : récolter de la donnée

\n
\n

Rappel article L.122 al.4 : les services numériques d'assistance au déplacement sont tenus d'informer de façon complète les utilisateurs (...) des mesures de restriction de circulation visant les poids lourds prises par les autorités de police de la circulation en application de l'article L. 2213-1 du même code ou de l'article L. 411-8 du code de la route et concernant les itinéraires proposés, dans le cas des services numériques d'assistance au déplacement spécifiques aux véhicules lourds”.

\n
\n

Au sein de l’équipe transport.data nous nous sommes demandés si nous pouvions à 6 personnes créer une solution susceptible de récolter la donnée concernée par l’article L.122 alinea 4. et l’intégrer dans nos process.

\n

L’objectif était bien de disposer d’une brique supplémentaire sur le PAN mais pas de créer une nouvelle équipe au sein de transport.data. Ce qui a conduit à la création de la startup d’État DiaLog. Les premiers jeux de données DiaLog sont d’ailleurs référencés depuis la semaine dernière dans les données routières du PAN.

\n

Plus tard nous aurons ainsi une base de données par rue qui fournira les horaires de transport théoriques et en temps réel ainsi que la réglementation routière applicable, le tout mis à disposition via le point d’accès national !

\n
\n", "date_published": "2024-01-11T00:00:00Z" } , { "id": "https://dialog.beta.gouv.fr/blog/fr/politique-fret-itw-xavier-yves-valere/", "url": "https://dialog.beta.gouv.fr/blog/fr/politique-fret-itw-xavier-yves-valere/", "title": "Construire une politique nationale pour le Fret, interview de Xavier-Yves Valère", "content_html": "\n
\n

\n
\n

Xavier-Yves Valère est chef de la Mission Fret et Logistique de la DGITM (Direction Générale des Infrastructures de Transport et des Mobilités). Il travaille à concevoir la politique nationale visant à assurer le futur du transport de marchandises, un secteur qui traverse d'importantes transformations. Du rapport de 2021 sur la logistique urbaine durable aux Jeux Olympiques de 2024, comment se matérialisent ces mutations ? Et que signifient-elles pour l'avenir du fret ?

\n
\n
\n

Pourquoi DiaLog ? Pouvez-vous nous raconter la genèse de cette solution ?

\n

La pandémie a agi comme un révélateur pour de nombreux acteurs publics et privés de la nécessité de travailler sur les conditions de notre logistique urbaine : le fort développement du commerce en ligne, la mise en place des Zones à Faibles Émission (ZFE),... Les collectivités territoriales se posaient des questions et l’État qui avait largement décentralisé sa politique devait vérifier si les règles en vigueur étaient toujours adaptées.

\n

Trois personnes, Anne-Marie Idrac, (ancienne ministre des transports et du commerce extérieur, présidente de France Logistique), Anne-Marie Jean (élue strasbourgeoise et présidente du port autonome de Strasbourg) et Jean-Jacques Bolzan (élu toulousain président de la Fédération des Marchés de Gros) ont eu pour mission de vérifier si la politique publique de l’État en matière de logistique urbaine était toujours adaptée. J’ai eu la chance d’être désigné comme co-rapporteur de cette mission, ce qui m’a donné l’occasion de faire un tour de France des attentes des collectivités territoriales et des filières économiques.

\n

Un problème revenait très régulièrement : quand on est un livreur ou chargeur, la réglementation n’est pas toujours claire et son accès encore moins. Quand la collectivité est assez outillée, les acteurs économiques peuvent trouver l’information sur leurs médias en ligne, mais souvent l’information n’est pas facilement accessible. De leur côté, les collectivités territoriales nous ont dit que dans les ZFE manquaient des outils communs pour discuter à l’échelle d’un ensemble de communes et qu’ils avaient beaucoup de mal à faire prendre en compte leurs arrêtés dans les logiciels d’itinéraires.

\n

La mission a donc recommandé de mettre en place une solution numérique ad hoc, ce que le Gouvernement a acté à l’occasion du Comité Interministériel de la Logistique de 2021 en proposant la mise en place d’une base de données nationale et des services associés.

\n

\"Panneaux

\n
Panneaux de signalisation de zones à faibles émissions © Arnaud Bouissou / Terra
\n

Quelles sont les difficultés que rencontrent les acteurs de la logistique urbaine ?

\n

La mission en avait relevé de trois natures :

\n\n

Toutes ces difficultés n’étaient pas insurmontables, mais il nous fallait d’abord une bonne écoute client pour vérifier que nous avions bien compris la question dans toutes ses dimensions.

\n

Certains acteurs suggéraient de rendre obligatoire soit la transmission de l’information des maires aux GPS ou des GPS aux usagers mais ce qui nous manquait c’était surtout une solution techniquement viable.

\n

DiaLog a été créé pour répondre à ces besoins exprimés par les acteurs publics et privés et mettre en chantier un travail technique qui y réponde.

\n

Pourquoi avoir choisi le format de startup d’État pour DiaLog ?

\n

La réponse aux besoins des acteurs se trouvait dans un projet à la fois de transport, de solution numérique et de modernisation de l’administration. Nous avons saisi l’opportunité des dispositifs mis en place par la direction interministérielle du numérique (DiNum) pour créer DiaLog.

\n

En tant que projet numérique, la solution nécessitait une approche progressive par fonctionnalités afin d’aborder les sujets un par un. Dans la lignée du Point d’Accès National aux données - transport.data.gouv, DiaLog doit devenir la solution d’accès aux données routières. Face aux initiatives isolées des collectivités territoriales d’un côté et aux offres privées de l’autre, nous sentions que c’était le moment de structurer le marché et permettre un déploiement national des services sur le même modèle que transport.data.

\n

Notre objectif n’est pas de nous substituer aux solutions privées qui existent sur le marché, notamment les Transport Management Systems qui récupèrent la donnée relative aux poids lourds. Lorsque nous avons discuté avec les éditeurs de ces solutions, nous nous sommes aperçus qu’eux-mêmes avaient des difficultés à récupérer la donnée. Tout le monde appelait de ses vœux cette clarification et ces moyens.

\n

Quels changements une solution comme DiaLog pourra apporter aux différents usagers de la route ?

\n

Lors de nos rencontres les professionnels nous ont dit que lorsqu’il y a des travaux ou même un déménagement ils ont du mal à le savoir. Un livreur a également 80% de chance de trouver une aire de livraison occupée, ce qui lui impose de se garer en double file. Ces problèmes sont des petits accidents du quotidien qu’il est important de régler, sachant que comme je l’ai dit la transmission d’alertes permettrait aussi de mieux protéger les agents d’exploitation routière.

\n

Enfin, l’information transmise via DiaLog pourra aussi permettre de mieux planifier des décisions pour les collectivités locales : harmoniser entre communes des interventions sur la voirie, des règles de circulation ou de stationnement, mieux diagnostiquer à la bonne échelle l’offre de voiries.

\n

DiaLog peut être un outil efficace de planification et d’aide à la décision pour les décideurs publics et privés.

\n

Au-delà des poids-lourds, quelles sont les ambitions de DiaLog ?

\n

Ce qu’on arrive à faire pour les poids lourds va bénéficier à tous les usagers. Il y a bien sûr des enjeux propres à la logistique comme la connaissance des contraintes de circulation sur le poids, le gabarit ou les horaires de livraisons autorisées, mais le travail de traduction d’un arrêté de circulation en donnée exploitable par un GPS ouvre de nombreuses perspectives pour la suite car un(e) maire n’a pas toujours de prise sur les itinéraires proposés aux automobilistes dans les GPS. Il ou elle est obligé(e) de prévoir des aménagements de voiries pour éviter ce trafic “envoyé” par les GPS.

\n

Nous avançons en mode start-up, nous vérifions donc à chaque étape de développement que nous répondons à un besoin avec une solution adaptée. Nous nous sommes fixés une liste de besoins à adresser simplifier les livraisons, mieux faire connaître les restrictions sur les ouvrages d’arts (ponts, tunnel,...) et les barrières de dégel. Nous sommes très sensibles également à la sécurité des agents d’exploitation qui travaillent sur les routes. Nous souhaitons pouvoir aussi développer un module pour permettre à ces agents de transmettre des messages d’alerte aux usagers de la route en temps réel en cas d’intervention.

\n

\"Pose

\n
Pose de plots par un agent d'exploitation sur le chantier d'aménagement de la piste cyclable temporaire entre la Porte Maillot et La Défense © Arnaud Bouissou / Terra
\n

À court terme les Jeux Olympiques de Paris semblent également un champ d’application intéressant ?

\n

Les ressources d’une startup d’État doivent être proportionnées aux objectifs de politique publique qu’elle cherche à atteindre. Il est important de faire la preuve de ce qu’on apporte, et les Jeux Olympiques représentent un bel endroit pour la démonstration de l’apport de DiaLog.

\n

Les Jeux Olympiques forment un immense défi logistique. La DGITM a évalué que la demande de transport de marchandises allait être doublée : nous aurons 2 fois plus de demande de transport de marchandises pour les restaurants, les hôtels, activités, et celà simplement pour la logistique du quotidien en dehors même de la logistique propre à l’organisation des Jeux. Or nous savons déjà que nous n’aurons pas 2 fois plus de poids lourds et de chauffeurs. Ce boom de la demande va se passer à un moment où les conditions de circulation seront très dégradées autour des sites d’épreuves, durant les épreuves, parfois plusieurs jours de suite sur certains sites.,...

\n

La réglementation va être très dynamique pour limiter les restrictions dans le temps au strict nécessaire des épreuves. Il y a donc un enjeu énorme à pouvoir communiquer clairement sur les conditions de livraisons suivant les secteurs et les jours d’épreuves. Il est donc impératif que la solution DiaLog puisse être opérationnelle et permettre un accès aux informations depuis un logiciel de planification d’itinéraire.

\n

Comment est-ce qu’on discute avec les GPS (Tom Tom, Here, Waze,...) quand on est l’État ?

\n

L’État est responsable du respect de la réglementation nationale. Les GPS ont besoin d’homogénéité car leurs solutions sont par natures internationales. Ils ne vont pas faire un logiciel différent pour chaque ville ou chaque pays. Nous devons donc trouver les moyens de transférer la donnée publique de la manière la plus souple et efficace et cela nécessite un travail en amont avec chaque GPS.

\n
", "date_published": "2023-12-14T00:00:00Z" } , { "id": "https://dialog.beta.gouv.fr/blog/fr/art-122-itw-mathieu-fernandez/", "url": "https://dialog.beta.gouv.fr/blog/fr/art-122-itw-mathieu-fernandez/", "title": "L'article 122 de la loi "Climat et Résilience", interview de Mathieu Fernandez", "content_html": "\n
\n

\n
\n

Comment les GPS peuvent-ils contribuer efficacement à la lutte contre le déréglement climatique ? Mathieu Fernandez, chef de projets numérique au Ministère des Transports et intrapreneur de DiaLog commente l’article 122 de la Loi Climat et Résilience.

\n
\n
\n

Commençons par le texte en question :

\n
\nAprès l'article L. 1115-8 du code des transports, il est inséré un article L. 1115-8-1 ainsi rédigé :\nSelon des modalités définies par décret, les services numériques d'assistance au déplacement sont tenus d'informer de façon complète les utilisateurs des impacts environnementaux de leurs déplacements. En particulier, ces services :\n

1° Indiquent, le cas échéant, la présence et les caractéristiques des mesures de restriction de circulation en vigueur dans les zones à faibles émissions mobilité prévues à l'article L. 2213-4-1 du code général des collectivités territoriales ;

\n

2° Ne favorisent exclusivement ni l'utilisation du véhicule individuel, ni l'usage massif de voies secondaires non prévues pour un transit intensif ;

\n

3° Proposent aux utilisateurs un classement des itinéraires suggérés en fonction de leur impact environnemental, notamment en termes d'émissions de gaz à effet de serre ;

\n

4° Informent les utilisateurs des mesures de restriction de circulation visant les poids lourds prises par les autorités de police de la circulation en application de l'article L. 2213-1 du même code ou de l'article L. 411-8 du code de la route et concernant les itinéraires proposés, dans le cas des services numériques d'assistance au déplacement spécifiques aux véhicules lourds.

\n

Les services numériques mentionnés au premier alinéa du présent article sont ceux qui visent à faciliter les déplacements monomodaux ou multimodaux au moyen de services de transport, de véhicules, de cycles, d'engins personnels de déplacement ou à pied.

\n
\n

Mathieu Fernandez, vous êtes intrapreneur au sein du Ministère de la Transition Écologique, en charge du développement de la startup d’État DiaLog. Avant de nous parler de DiaLog, pouvez-vous nous raconter pourquoi l’État a souhaité encourager les solutions de navigation à mieux favoriser les déplacements les moins carbonés ?

\n

À la suite du mouvement des gilets jaunes, le Grand Débat National a permis d’affirmer une nouvelle fois l’urgence de freiner notre contribution au déréglement climatique. La Convention Citoyenne pour le Climat a ensuite formalisé une série de mesures répondant à cette obligation. La pandémie de covid-19 a elle démontré la fragilité de notre système face aux crises de grande ampleur. La loi Climat et Résilience vise à répondre à ces fortes tensions en agissant sur de nombreux secteurs : la consommation, la production et le travail, les mobilités, l’aménagement ou l’alimentation.

\n

Le secteur des mobilités est le premier secteur émetteur de gaz à effet de serre en France, et les mobilités routières y sont responsables de la grande majorité (+90%) des émissions. Ces dernières sont donc un sujet prioritaire de toute politique publique visant à freiner notre contribution au réchauffement climatique. La circulation routière est également d’une grande importance quand on parle de résilience. 9 tonnes de marchandises sur 10 transitent par la route en France, une circulation très intensive qui nécessite d'être encadrée par les gestionnaires d'infrastructure afin de garantir l'accès à des routes en bon état.

\n

Quelles sont les contraintes et obligations que l’article 122 introduit pour les solutions de navigation ? Dans quel objectif ?

\n

Je vous renvoie aux détails de chaque terme utilisé dans l’article, mais en résumé disons qu’il demande à ce solutions de mieux informer les utilisateurs de la route sur les ZFE, de veiller à ne pas favoriser exclusivement certains véhicules et certains itinéraires inadaptés, et de proposer des itinéraires ayant un moindre impact en terme d’émission de gaz à effet de serre.

\n

Il me semble qu’il y a également un paragraphe spécifique sur la réglementation poids lourds, c’est le créneau choisi par DiaLog pour ses premiers cas d’usage non ?

\n

L’article 122 dispose que les solutions de navigation “ Informent les utilisateurs des mesures de restriction de circulation visant les poids lourds prises par les autorités de police de la circulation en application de l'article L. 2213-1 du même code ou de l'article L. 411-8 du code de la route et concernant les itinéraires proposés, dans le cas des services numériques d'assistance au déplacement spécifiques aux véhicules lourds.”

\n

Dans la phase d’investigation de DiaLog, nous avons choisi de nous concentrer sur l’application de la réglementation poids lourds dans certaines villes, en prenant le cas particulier des arrêtés de travaux ayant un impact sur la circulation. Il faut garder à l’esprit qu’une agglomération comme Rennes va ouvrir et fermer plusieurs milliers de “chantiers” par an. Pouvoir communiquer efficacement vers les utilisateurs de la route, en premier lieu desquels les poids lourds, est crucial. Cela permet d’éviter des désagréments (camion bloqué, obligé de faire demi-tour) mais permet également de réduire les risques (camion empruntant une voirie ou une infrastructure inadaptée) et améliorer les conditions de travail des conducteurs. Lors de la phase d’investigation de DiaLog, nous avons constaté une grande convergence de vue des différents acteurs - services municipaux, transporteurs, chargeurs - sur l’utilité d’améliorer la connaissance des périodes, secteurs et impacts des travaux.

\n

\"Camions

\n
Camions circulant dans une rue d'Olliergues © Arnaud Bouissou / Terra
\n

Concrètement, qu’est-ce que DiaLog va apporter ?

\n

Nous avons essayé d’inclure DiaLog de la manière la plus fluide possible dans le parcours qu’emprunte la réglementation. Je m’explique : aujourd’hui la réglementation est produite par les communes ou regroupement de communes en prévision de travaux impliquant au moins une entreprise. Lorsque ces travaux ont un impact sur la circulation sur l’espace public, un arrêté est nécessaire pour en modifier temporairement ou définitivement les règles d’usage. Après avoir défini avec les services concernés les impacts qu’auront ces travaux, l’arrêté explicite ces impacts : type de modification, durée, localisation, type d’usage ou d’usagers concernés. Cet arrêté doit ensuite être publié pour avoir force exécutoire. Il va générer notamment une information temporaire ou permanente sous forme de panneaux, et éventuellement communication directe auprès des riverains et dans des médias.

\n

Et c’est là que DiaLog intervient. À l’aide d’une interface simple, DiaLog permet aux collectivités de transmettre par voie numérique les arrêtés qui ont un impact sur la circulation auprès des services numériques d’assistance au déplacement. Ceux-ci peuvent prendre en compte ces contraintes pour le calcul des itinéraires et la présentation des cartes de secteur qu’ils diffusent à leurs utilisateurs.

\n

DiaLog est-il déjà en service ? Où en êtes-vous pour le moment ?

\n

Nous sommes toujours en phase de test et de développement. DiaLog travaille par exemple avec les autorités du Grand Paris afin d’intégrer les arrêtés existants dans la perspective prochaine des Jeux Olympiques de Paris 2024. Des services numériques d’assistance sont également consultés et impliqués. Cette phase est importante car elle permet de tenir compte des besoins et contraintes des différents acteurs en matière d’expérience utilisateur, de fonctionnalités et d’organisation.

\n

Notre objectif est de disposer en trois ans d’un outil complet et fiabilisé, prenant en compte l’ensemble des règles d’usage de nos routes. Cette année nous construisons et testons le service, il s’agit véritablement de bâtir l’ensemble des fonctionnalités de DiaLog et de déterminer la meilleure manière de transmettre les données que nous recueillons à des tiers réutilisateurs. Cela nous permettra d’aborder l’année 2024 sur des bases solides afin d’une part de mettre le dispositif à l’épreuve, vérifier son fonctionnement en conditions réelles et quantifier son impact, et d’autre part de travailler à son déploiement notamment auprès des collectivités concernées par les Jeux Olympiques. Nous espérons ainsi améliorer significativement l’expérience des usagers et des professionnels de la route pendant les Jeux. Enfin 2025 sera encore davantage consacrée au déploiement du service, afin notamment de préparer l’arrivée d’obligations européennes sur l’ouverture des données de réglementation routière.

\n
\n", "date_published": "2023-11-30T00:00:00Z" } ] }