Loi Macron : deux ans plus tard, toujours pas de décret pour l’Open Data dans les transports
Un train, des rails
Le 17 août 2017 à 09h39
6 min
Droit
Droit
Deux ans après l'entrée en vigueur de la loi Macron, le décret censé participer à l'ouverture des données détenues par les transporteurs (horaires, arrêts…) n'a toujours pas été publié par le gouvernement – contrairement à ce qu'avait imposé le Parlement. De ce flottement juridique résulte une très lente marche des acteurs concernés vers l'Open Data.
Le 6 août dernier, la loi « pour la croissance, l'activité et l'égalité des chances économiques » soufflait ses deux bougies. Si l'exécutif aime à rappeler les réformes ainsi introduites pour les lignes d'autocar, les notaires,… il est généralement moins enclin à évoquer celle relative à l'ouverture des données de transport. L'objectif est pourtant loin d'être accessoire : améliorer l'accès des voyageurs aux informations clés détenues par les différents transporteurs.
Qu’il s’agisse de « services réguliers de transport public de personnes » (train, métro, bus, avion...) ou de « services de mobilité » – de type vélos en libre-service ou covoiturage –, l'article 4 de la loi Macron oblige en théorie les acteurs du transport à diffuser « librement, immédiatement et gratuitement » leurs données relatives à :
- Leurs arrêts
- Leurs tarifs publics
- Leurs horaires planifiés
- Leurs horaires en temps réel
- L'accessibilité aux personnes handicapées
- La disponibilité de leurs services
- Les incidents constatés sur le réseau
Le tout dans un « format ouvert », l'idée étant avant tout de fournir de la « matière première » à des développeurs qui souhaiteraient par exemple proposer un site ou une application permettant de calculer un itinéraire, en prenant en compte tous les modes de transport disponibles.
Un texte guère respecté
Problème : comme nous avons déjà eu l'occasion de le souligner, force est de constater que ces dispositions sont encore (très) loin d’être respectées par les principaux acteurs du transport !
Pour accéder aux horaires planifiés et en temps réel des TGV, par exemple, il faut passer par une API (laquelle est soumise à une inscription, ce qui n’est pas forcément très compatible avec un accès complètement « libre », tel que prévu par la loi Macron...). La gratuité est d’autre part limitée, puisqu’au delà de 150 000 requêtes par mois, il faut se tourner vers une offre payante proposée par la SNCF. Mêmes pratiques chez Air France : au-delà de 2 requêtes par seconde (ou 1 000 par jour), il faut négocier avec le transporteur pour un accès à son API.
Chez d'autres, il n'y a carrément aucun jeu de données de disponible, comme chez FlixBus par exemple. On pourrait également citer le cas de plusieurs lignes de bus gérées par les départements…
Le gouvernement dépasse de vingt mois le délai fixé par le législateur
Mais comment expliquer cette situation ? Quand on se replonge dans l’article 4 de la loi pour la croissance et l'activité, on remarque tout d'abord qu’aucune sanction n’est expressément prévue en cas de manquements. De plus, ses dispositions avaient vocation à être complétées par un décret en Conseil d'État – programmé par le législateur pour « au plus tard trois mois après la promulgation de la [loi Macron] ». Autant dire que cette échéance a été largement dépassée… De quasiment vingt mois à ce jour !
En dépit de nos multiples sollicitations, le précédent gouvernement s'est toujours montré très discret sur ce dossier. Après avoir sans cesse repoussé la date de publication du fameux décret, l'exécutif indiquait en mars dernier, au travers d'une réponse écrite au sénateur Jean Desessard, qu'il serait probablement pris « au courant du premier semestre 2017 ». Loupé, à nouveau, aucun texte n'ayant vu le jour à l'heure où nous publions cet article.
La rédaction de ce décret était pourtant terminée dès la fin 2015, puisque Bercy en avait notifié la Commission européenne…
Contacté par nos soins, le nouveau ministère des Transports (confié à Elisabeth Borne, ancienne numéro un de la RATP), n'a pas davantage répondu à nos questions.
Un texte d’apparence musclée, en réalité seulement subsidiaire
Cette situation semble finalement profiter aux acteurs du transport guère désireux d'offrir gratuitement leurs données, comme le dénonçait notamment la Cour des comptes début 2016. Et pour cause. Même si les dispositions de l'article 4 de la loi Macron sont belles et bien applicables (l'entrée en vigueur du texte n'étant pas conditionnée à la prise du décret), elles offrent rappelons-le une belle échappatoire aux transporteurs : les personnes qui y sont soumises sont « réputées remplir leurs obligations » dès lors qu'elles adhèrent à des codes de conduite, des protocoles ou des lignes directrices, « préalablement établis par elles et rendus publics » suite à leur homologation par l’exécutif.
En optant pour ces sortes de charte, les transporteurs sont autorisés à passer outre certains principes posés par la loi Macron... Un « délai raisonnable » peut par exemple être prévu avant la mise en ligne de données. Surtout, des « dérogations au principe de gratuité » sont permises pour les « utilisateurs de masse ».
En mars dernier, le gouvernement a ainsi homologué un premier code de conduite, élaboré par la RATP. La régie autonome se voit notamment autorisée à ériger des redevances (dont les fruits ne sont pas censés dépasser les coûts de mise à disposition des données) à l'encontre des internautes dépassant les 30 millions de requêtes par mois.
Pour résumer, les acteurs du transport ont aujourd'hui deux choix :
- Appliquer à la lettre l'article 4 de la loi Macron, avec un véritable Open Data
- Rédiger et faire homologuer une charte, avec de possibles dérogations aux grands principes de l'Open Data, tel la gratuité
Dans le premier cas, l'absence de décret précisant ces dispositions semble pouvoir justifier un certain retard dans leur mise en oeuvre. Dans le second cas, c'est l'assurance de bien plus de souplesse – et notamment l'assurance de pouvoir maintenir certaines redevances. Mais dans un cas comme dans l'autre, c'est le voyageur qui se retrouve pénalisé aujourd'hui.
Loi Macron : deux ans plus tard, toujours pas de décret pour l’Open Data dans les transports
-
Un texte guère respecté
-
Le gouvernement dépasse de vingt mois le délai fixé par le législateur
-
Un texte d’apparence musclée, en réalité seulement subsidiaire
Commentaires (36)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 17/08/2017 à 09h44
En Marche. Mais pas trop vite…
Le 17/08/2017 à 09h48
À reculons même … m’étonnerait pas un retournement de veste et que finalement le texte soit revue en profondeur " />
Le 17/08/2017 à 09h50
A Lyon, on attend toujours que ce soit fait pour les TCL et qu’ils soient enfin intégrés à Maps… encore qu’ils vont utiliser la dérogation des “utilisateurs en masse”
Le 17/08/2017 à 10h01
Pour les “utilisateurs en masse”, cela ne me choque pas particulièrement en fait :
Les chiffres annoncés restent importants.
Ils concernent donc une toute petite partie de la population, cad des editeurs de logiciels qui proposeraient des services de consultation de ces données mais sans stockage de ces données
=> typiquement, les apps de consultation “gratuite avec de la pub” qui vont requêter régulièrement les données de la SNCF en induisant une charge importante.
L’app est simple à faire et a peu couté en dev, la sncf héberge et fournit les données gracieusement … et l’éditeur gagne de l’argent sur la pub… sur de la dos de la SNCF qui supporte les frais.
Donc payer pour dépasser un “fair usage”, cela ne me choque pas.
Le 17/08/2017 à 10h03
TCL, toujours à la pointe pour pas faire le taff et emmerder le monde avec des grèves à répétition le jour du bac et du festival des lumières!
Le 17/08/2017 à 10h15
Le 17/08/2017 à 10h22
Le 17/08/2017 à 10h28
Il n’y aurait pas une erreur dans le tableau présenté ?
“les redevances venaient à accéder”, je ne connais pas cette expression. J’ai compris venaient à excéder.
Le 17/08/2017 à 10h44
Le 17/08/2017 à 10h53
Le 17/08/2017 à 11h03
12.000€ mensuels par client (calcul pour 30M) pour fournir en moyenne un peu moins d’une douzaine de requêtes par seconde (mettons 100req/s à la pointe, avec un facteur à la louche), on se mouche pas du coude à la RATP. Y’ s’offrent des serveurs plaqué or ? de la BP transit VIP ? Des ROC sapés en Armani/Breitling/Santoni ?
Ça ressemble à du péage “arme de dissuasion”, c’te grille tarifaire.
My2¢.
Le 17/08/2017 à 11h53
Heu les frais pour les gars, c’est pas grand chose. Dans 99% des cas, tu auras déjà des API internes qui permettent de récupérer les données. Faire une nouvelle API pour le grande public, ça prend pas longtemps si tu as déjà toute la mécanique derrière. Et pour le coup tu n’as besoin de le faire qu’une seule fois et c’est plié. Le seul coup qui peut s’étaler sur la durée, c’est payer la bande passante à l’hébergeur. C’est de mon point de vue le seul point qui pourrait justifier une version payante.
Le 17/08/2017 à 12h28
On vote des lois dont on se vante dans les médias pour se faire élire, puis on fait des arrangements en douce pour que les copains puissent violer ces lois: c’est la société du spectacle " />
Le 17/08/2017 à 12h31
Ultimatum à Mr N.Hulot: si vous ne libérez pas les data, on abandonne le métro et on passe au 4x4 diesel !
" />
Le 17/08/2017 à 12h44
Le 18/08/2017 à 17h20
PS : Je te rejoint sur le dernier §. Si t’as l’impression
que le troll au début, hésites pas sauter jusqu’à la fin directement ou on
tombera surement d’accord ;)
Y’a des solutions qui existent, certaine presque clef en
main, c’est vrai.Mais déjà, “si c’est bien pensé dès le départ” c’est
plus facile a dire qu’a faire, sachant que le besoin peut changer.
Donc coup de maintenance + évolutions.
C’est loin d’être rien (encore une fois, c’est de ça dont je
parle)
Mettre en place une API puplique =/= maintenir une API
puplique en place.
En plus, cela ajoute de l’inertie sur les projets internes :
encore plus de coûts.
Enfin, c’est loin d’être donné tout ça. D’après le lien de
Z-os, on parle de millions.
Les coûts c’est pas que la facture Amazon, y’a aussi tout ce
qui va autour.
“Tu vas pas me faire croire qu’un voyages-sncf ou qu’un
air France à pas déjà une archi solide pour gérer les demandes de tarifs en
temps réelles.”
Non en effet, c’est pas mon propos, et alors qu’elles est
pas faite que pour un usage classique, elle leur coute déja un bras.
“Après pour les horaires et prix de bus et les trains
régionaux, ils changent pas tous les 4 matins, pas besoin de pull toutes les 2
secondes. ”
Sur toute la france, toute les lignes + info en temps reel,
bah si il faut…
Encore plus si je fourni une app android qui va piocher
directement dans l’open-data de la sncf (pourquoi me faire chier a répliquer
leur DB, a part pour ajouter du lag et des erreurs ?) alors c’est plusieurs
millions de requêtes qui vont tomber en très peu de temps pour demander ces
infos qui ne changent pas.
“Donc je persiste et signe quand je dis que toutes les
boites de transports ont pour 99% déjà ce qu’il faut en place pour gérer des
requêtes”
Oui.
“et que faire une version de leur API à rendre
publique, c’est pas la partie la plus dure. ”
Non…
Rendre une API publique avec tout ce qui va avec ça peut
être bien plus compliqué que le soft de base…
Sans rentrer dans toute la mécanique SNCF, (car la, oui
c’est surement plus dure de gérer ça qu’une API publique) faire une API pour
recup’ c’est info en interne c’est facile. Rendre ça dispo ça l’est beaucoup
moins.
Dernier §
“Après il faut voir les contraintes qui viendront avec
le décret, mais ça m’étonnerait qu’on leur demande de pouvoir gérer 10k
requêtes secondes en gratuit […]”
C’est exactement ce dont je parle !
Dans l’état actuelle, y’a aucune info. Aucun cadre. Rien.
Si ça vient avec des limites raisonnables, alors je te rejoint totalement.
D’où le barème RATP qui n’est qu’un début et ne devrait pas
être fixé par l’intéressé…
En gros : diffuser « librement, immédiatement et
gratuitement » = pas possible. Faut
encadrer le truc. Et les règles devraient pas être fixées par les entreprises.
Le 19/08/2017 à 12h35
Je ne suis pas un grand connaisseur de la question, mais … Ne serait-il pas possible, pour les réutilisateurs de ces données, de les dupliquer sur un serveur à eux ?
Je m’explique.
J’ai l’impression, selon vos commentaires, qu’aujourd’hui, un client qui cherche les horaires (temps réel ou non) des transport à un point d’arrêt via l’appli d’un réutilisateur , cette appli se connecte directement à l’API du transporteur.
C’est-à-dire que si, en une minute, 50 personnes demandent les horaires à un même point d’arrêt, alors les serveurs du transporteur vont devoir fournir 50 fois la grille horaire. Et le réutilisateur devra sans doute payer pour 50 accès API. (Si l’accès lui est payant.)
Or, en une minute, les horaires ne varient pas de beaucoup. Pire : si la précision est de l’ordre de la minute, il y a de très fortes chances pour que les 50 réponses de l’API de l’exemple précédent soient toutes identiques.
Dans ce cas, mettre en place un serveur intermédiaire qui va interroger lui-même l’API du transporteur et mettre en cache (pour trente secondes ? une minute ? cinq minutes pour des points d’arrêts très peu desservis en période creuse ?) les réponses pour les recracher aux utilisateurs finaux permettrait d’économiser pas mal de requêtes API …
(Effet de masse oblige, j’imagine que les serveurs de la SNCF délivrent beaucoup plus souvent les horaires pour Paris Gare-de-Lyon que pour une gare située au fin-fond de la cambrousse et desservie que par un ou deux trains par jour. )
Le 21/08/2017 à 06h39
Messieurs, recentrons un peu le débat.
L’objectif est de fournir la donnée en format open source aux citoyens.
La problématique étant que l’accès à l’information sur les données des transporteurs (horaires, annulations, retards, …) sont communiquées au bon vouloir du prestataire, avec les problèmes qui en découlent : Information client erronée, biaisée volontairement, cachée, et j’en passe.
Une loi a été votée afin de mettre un terme à ces pratiques, est les sociétés de transports vont devoir mettre en place une solution d’accès à ces informations au tout venant.
Cette solution n’est pas contrainte par une technique propre comme suggéré plus haut (Accès via une API).
Cette mise en place devra faire partie d’un plan structuré en adéquation avec l’architecture du S.I de chaque entreprise.
Les méthodes sont pléthoriques : Repository, API, collections de données, et j’en passe.
Il ne manque qu’un décret d’application, mais les sociétés visées effectuent un blocus de masse
Pour revenir à une interrogation via API, plusieurs méthodes permettent de limiter l’accès aux BDD maîtres : API intermédiaire, actualisation en “delta”.
Il ne faudrait pas dramatiser la situation du côté des DSI de ces groupes. Leur urbanisation est déjà cohérente et ne nécessite que peu d’effort et d’investissement.
Plutôt que voir le problème avec un livrable complet dès le départ, autant prévoir plusieurs lots à l’avance avec benchmarking sur les phases de lancement en production.
Le 21/08/2017 à 09h18
C’est ce qu’on fait en général. Mais ça coûte des sous, voir vraiment beaucoup en fonction du nombre de client. Et au vue des prix type RATP, ça serait justement un accès directe par client qui serait facturé.
Si ces société sont obligées de fournir ces données gratuitement et en temps réel, pourquoi s’embêter avec avec sa propre infra ?
@smousse42 : Tu as raisons. Je répondais juste au “c’est pas chère” de Baradhur, mais on a vite dérivé.
Surtout que, au final, il a quand même raison. Car même si ça leur coûte 5M / an, je pense pas que ça soit la l’obligation financière légale la plus chère (impôt, taxe, toussa). Cela ne devrait pas représenter un gros trou dans leurs budgets. Puis bon, si il faut, il faut hein.
Le 21/08/2017 à 09h28
@Iste : Tout à fait d’accord. Comparé à l’effort financier demandé aux entreprises pour la mise en place de la DSN (déclaration sociale nominative auprès de l’URSSAF), cette loi c’est une paille…
Le 17/08/2017 à 12h45
Tu bluffes Martoni !
Le 17/08/2017 à 12h47
Ou alors je cherche une excuse plausible pour être déjà détenteur d’un 4x4 diesel… " />
Le 17/08/2017 à 13h02
Pour que les autres et des bosses et pas toi." />
Le 17/08/2017 à 13h12
oui, tout à fait. " />
Le 17/08/2017 à 14h04
Le 17/08/2017 à 15h26
C’est loin d’être aussi simple.
Une api, faut qu’elle tienne la charge aussi (c’est ce qu’on fait payer en général)
Puis y’a la maintenance du soft, les évolution, la gestion des accès…
C’est pas juste un petit apache quelque part, et je pense que le prix de la bande passante est le dernier de leurs soucis.
Perso je pense que c’est tout le principe de l’Open Data qui est a revoir. On peut pas demander a quelqu’un de fournir une API gratos a tout le monde. Ça peut revenir super chère. Faudrait que ça soit plus encadré.
Le 17/08/2017 à 19h27
Le 17/08/2017 à 21h40
clairement d’accord.
des données publiques libérées, c’est “normal” en soi.
Elles peuvent notamment servir ponctuellement pour nos besoins, même d’applications.
Après, fournir le service de ces données, ça n’est pas gratuit.
Donc un usage gratuit avec fair use réduit pour les besoins ponctuel,
un usage payant avec une qualité de service mise en place pour les besoins réguliers.
(genre avoir en temps “réel” les infos sur les places restantes dans les parkings/emplacements vélo genre velib-bicloo-cie/etc)
Le 18/08/2017 à 00h30
Tu viens juste de redir exactement ce que je viens de dire. Et pour bosser dans une equipe qui constuit et gere des API au quotidien, je te confirme que si, c’est aussi simple que ca. Le plus complique reste le model a penser correctement, le reste peut se faire en moins d’une semaine par une personne.
Le 18/08/2017 à 09h04
Ah part si tu l’as redis ailleurs et que je l’ai raté, faudra m’expliqué en quoi c’est la même chose…
Et, j’en fais aussi des API dans mon boulot. Je sais pas a qui tu rends dispo les tiennes, mais quand on doit gérer un nombre de clients extensible, créer l’API c’est de loin pas le souci.
C’est la mise a dispo qui prend du temps et de l’argent. (et pas qu’un peu)
Donc sortir un “Heu les frais pour les gars, c’est pas grand chose” soit tu sais pas de quoi tu parles, soit on a pas la même notion de “pas grand chose”.
C’était a cela que je répondais principalement.
Maintenant je veux bien plus d’info sur le genre de service que tu fourni, ça m’aiderai surement a comprendre ton point de vue, et du coup, tes messages.
Le 18/08/2017 à 09h07
Ou alors l’état se sort les doigts et propose lui même ce service a ses frais.
Les autres n’auront qu’a pousser a moindre coûts leur Data dedans, et le service sera Open.
Mais bon, faut pas rêver…
Le 18/08/2017 à 10h32
C’est pas forcément choquant. Comme dit plus haut, la RATP est une société privée (EPIC) rendant un service public. Il faut savoir que ces données valent de l’or et c’est pour ça que beaucoup d’entreprises les veulent. Il y a beaucoup de concurrence (Si tu savais ce que font les opérateurs mobiles des données qu’ils collectent sur toi (déplacements, etc…))…
Il faut maintenir une infrastructure (ce n’est pas uniquement l’API externe mais tous les mécanismes de collecte interne (lien avec les postes de commandes centralisés, les automatismes, etc…). C’est pas simple, c’est pas gratuit. Le problème de cette loi, c’est la perte de matière première au profit des majors du Web (google & co), sachant que ces dernières payent très peu d’impôts en France (la RATP et la SNCF payent leurs impôts… elles!) au regard du business qui y est généré. Ouvrir les données, oui, mais pas n’importe comment. En gros, je serai pour permettre par exemple aux instituts de recherche de les utilisers gracieusement, mais que toute exploitation commerciale soit rétribuée justement aux producteurs….
Le 18/08/2017 à 11h04
Un lien qui va dans ton sens :
http://www.silicon.fr/voyages-sncf-chasse-bots-ouverte-156708.html?inf_by=599690…
Le 18/08/2017 à 11h06
C’est bien ce que je disais : un péage dissuasif qui n’aura pour effet que de priver les “petits” créateurs (français ou autres) au profit des fameuses majors du web, pour lesquelles 144.000€/an sont une paille et qui pourront se permettre d’attendre (même) plusieurs années une hypothétique rentabilité, l’important pour eux étant de “truster” le paysage.
Tout l’inverse de la philosophie de l’Open Data. Non ?
Le 18/08/2017 à 13h06
Je ne maîtrise pas la grille tarifaire mais je connais bien la RATP… et on peut négocier avec elle :)
Enfin d’après tes chiffres, c’est pas avec 100requêtes par seconde que Google va faire du fric :) Je pense qu’il leur faut un chouilla plus.
Mais je suis d’accord avec toi. C’est d’ailleurs pour ça que la RATP et la SNCF ont freiné des 4 fers pour limiter ce qu’ils fournissent à google. L’état doit faire de la préférence nationale numérique :p
Le 18/08/2017 à 14h44
Encore une fois tu paraphrases ce que je dis. C’est le volume qui joue le plus sur une API, au delà des problèmes de sécurités. Mais de nos jours le scale, ça se gère facilement si c’est bien pensé dès le départ. MQ stateless + business services (container docker instancié) en fonction de la MQ pour le traitement des requêtes + RDS sur un amazon pour la bdd et voilà. C’est un exemple d’archi qui gère très bien ce genre de problème. Tu peux faire la même avec Azure ou google cloud.
Tu vas pas me faire croire qu’un voyages-sncf ou qu’un air France à pas déjà une archi solide pour gérer les demandes de tarifs en temps réelles. Après pour les horaires et prix de bus et les trains régionaux, ils changent pas tous les 4 matins, pas besoin de pull toutes les 2 secondes.
Donc je persiste et signe quand je dis que toutes les boites de transports ont pour 99% déjà ce qu’il faut en place pour gérer des requêtes et que faire une version de leur API à rendre publique, c’est pas la partie la plus dure.
Après il faut voir les contraintes qui viendront avec le décret, mais ça m’étonnerait qu’on leur demande de pouvoir gérer 10k requêtes secondes en gratuit. Même pas sur qu’on leur demande de produire des infos en temps réelle, ou un accès sans inscription préalable. Ca m’étonnerait aussi fortement qu’on leur impose une dispo élevé avec pénalité si ça marche pas. Logiquement ça devrait pas être trop lourd, donc gérable.