Géo-communs ? Chiche !

Géo-communs ? Chiche !

Les communs numériques géographiques ont plus que jamais le vent en poupe.

L’IGN a récemment lancé une consultation publique portant sur les « géo-communs ». Cette initiative confirme l’engouement croissant pour les communs numériques, en particulier géographiques, porté autant par les acteurs publics, privés ou encore par les citoyens engagés, cette dernière décennie.

La lettre de mission à Bertrand Monthubert, nouveau président du CNIG (Conseil National de l’Information Géographique) va dans le même sens : « Est attendue une collaboration plus étroite entre l’État, des collectivités territoriales, des entreprises et des porteurs de ‘‘communs’’ numériques que peuvent être les acteurs de la société civile. »

Dans un monde de plus en plus régi par les grandes plateformes numériques, OpenStreetMap fait figure de référence et de « zone libre ». La plus grande plateforme de données géographiques libres au Monde est en effet riche d’une communauté hyper-active (dont le nombre de contributeurs, toujours en forte croissance, dépassera bientôt les 8 millions), d’un écosystème technique foisonnant, et d’une gouvernance ouverte et propice à la collaboration.

Afin de renforcer ce mouvement d’ouverture particulièrement vivace, il pourrait être envisageable d’unir nos efforts dans plusieurs projets qui nous paraissent relever de l’intérêt général. Les projets suivants font partie des pistes qui nous paraissent les plus prometteuses.

1. Un “street-view libre et ouvert”

La création d’informations géographiques de qualité nécessite de connaître la réalité du terrain qui est en constante évolution. Les « géants du numérique » ont très bien compris cela et collectent des vues immersives du terrain qui viennent compléter les vues aériennes. Depuis plus d’une dizaine d’années, différents acteurs sillonnent dans ce but les rues et les routes de France, sans mutualisation. Le coût est élevé, sûrement plus que les prises de vues aériennes et seules quelques multinationales peuvent se permettre une couverture exhaustive. À côté de cela, des milliers de contributeurs OpenStreetMap réalisent des prises de vues.

En 2014, Mapillary a été lancé, en se basant sur une licence ouverte (CC-BY-NC passée rapidement en CC-BY-SA pour les photos et ODbL pour les traces GPS correspondantes). La communauté OpenStreetMap est rapidement devenue la première pourvoyeuse de prises de vues. Mapillary a en retour alimenté la communauté OpenStreetMap avec des API d’accès, mais aussi des jeux de données tirés de ces images par intelligence artificielle en détectant automatiquement des objets sur celles-ci.

En 2020, le rachat de la société Mapillary par Facebook a posé question au sein de la communauté OpenStreetMap. En France, certains contributeurs bénévoles autant que professionnels sont maintenant réticents à partager leurs photographies avec un tel acteur.

Des alternatives existent, comme OpenStreetView, projet libre antérieur mais non maintenu, devenu OpenStreetCam lors de sa reprise par TeleNav, puis KartaView lors de sa reprise par Grab (un équivalent Singapourien d’Uber).

Le besoin d’un commun numérique non attaché à une structure commerciale dont la stratégie peut évoluer défavorablement se fait toujours ressentir.

Au-delà d’un usage grand public bien connu, ces vues immersives sont utilisées par de nombreux acteurs publics comme les services de secours pour préparer des interventions et sont aussi une mine d’informations fraîches pour mettre à jour les bases de données géographiques ou vérifier leur cohérence. Les collecteurs possibles sont nombreux (exemple original de la Ville de Redon qui a équipé ses camions de ramassage d’ordure pour ses prises de vues) et les réutilisateurs aussi.

En complément des photos ou comme un autre projet de commun, il est également envisageable d’imaginer une mutualisation des signalements terrain (appelés “notes” dans OpenStreetMap) permettant d’améliorer les données géographiques sous-jacentes.

2. Une base routière navigable enrichie

Une base routière navigable permet de calculer des itinéraires en complétant les géométries du réseau de voirie par les règles de circulation que sont les sens uniques, les interdictions de tourner, les files de pré-sélection, les limites de poids, de vitesse autorisée, de dimensions, de type de trafic, etc.

C’est sûrement le domaine le mieux identifié où des données publiques manquent à l’appel alors qu’une forte demande existe.

La base nationale des limitations de vitesse, annoncée en octobre 2015 en comité interministériel de la sécurité routière, puis prévue par la Loi pour une République Numérique de 2016 est prévue depuis plus de 5 ans, mais celle-ci n’est à ce jour toujours pas disponible, sans que l’on sache clairement qui est chargé de la constituer, ni comment.

Cette base navigable ne doit pas se limiter à l’usage routier motorisé, mais inclure aussi le réseau cyclable, voire à terme piéton.

OpenStreetMap a ici semble-t-il une longueur d’avance avec un filaire de voirie déjà largement complété par des informations de navigabilité qui permet à plusieurs moteurs de calcul d’itinéraire de fonctionner et de fournir des services utiles au plus grand nombre.

À cette base navigable pourront s’ajouter deux autres types d’informations qui peuvent être des communs complémentaires liés :

  • les statistiques de trafic
  • l’état en temps réel

Là encore, l’absence de commun et d’anticipation sur ces besoins font que des géants du numérique sont devenus incontournables en proposant des services, dont Waze est le leader, basés sur la collecte massive de données des utilisateurs sans jamais en partager les données produites.

À terme, l’ensemble pourrait donc regrouper :

  • le filaire de voirie navigable,
  • une base des déplacements constatés (traces GPS), archivés mais aussi temps réel,
  • un complément du filaire avec les statistiques de trafic constaté (qui peut être issu des traces GPS et d’autres sources).

Toutes ces données seraient utiles, encore une fois, pour les services de secours, mais aussi pour de nombreuses analyses sur les déplacements, les transports, la proximité des services et bien sûr des réutilisations innovantes encore non imaginées à ce jour.

Conditions de succès

La mise en œuvre de communs numériques nous semble souvent mal appréhendée. Il nous paraît utile de rappeler les conditions de mise en œuvre utiles au succès d’un commun numérique :

  1. une communauté ouverte, à la gouvernance horizontale, où les règles sont claires et s’appliquent à tous. La seule barrière à l’entrée est celle du respect de ces règles et en particulier la licence qui doit favoriser l’extension du commun (l’ODbL a bien sûr notre faveur).
  2. un commun agile : pas de grand plan initial mais une idée de départ paraissant souvent utopique avec une adaptation au fur et à mesure du chemin parcouru.
  3. community first : même en ayant un objectif final de production de données, l’approche adoptée doit se focaliser sur la communauté avant tout. Animer ses membres et produire des outils pour faciliter son implication doivent être des sujets centraux.
  4. la publication sous licence libre des briques logicielles produites et l’amélioration itérative et agile, centrée sur l’utilisateur. D’une manière générale, les “principes pour un développement numérique” (voir https://digitalprinciples.org/fr/principles) nous paraissent des bonnes pratiques à suivre.
  5. une réalisation portée par une équipe interne à chaque participant, afin d’en maîtriser véritablement la réalisation. L’engagement dans un commun doit être direct car peu délégable ou externalisable.
  6. la création de véritables services utiles basés sur le commun. C’est peut-être le point le plus important et le véritable indicateur de succès. Par exemple, le succès de la Base Adresse Nationale est ainsi mesurable en mesurant le nombre d’appels à son API de géocodage.

On oublie bien souvent qu’au-delà de tous les principes, les communs numériques sont avant tout une implication de tous les jours, à l’exemple de la communauté OpenStreetMap. Il est d’ailleurs toujours utile de découvrir les nombreux outils de communication utilisés par la communauté française et internationale.

Il semble enfin utile de rappeler l’incroyable effet levier que permet la plateforme OpenStreetMap pour les communs numériques liés aux données géographiques.

Lettre ouverte : L’ODbL : La licence par excellence pour l’Open Data dans le transport

Lettre ouverte : L’ODbL : La licence par excellence pour l’Open Data dans le transport

De récentes réflexions proposent la création d’une nouvelle licence spécifique au transport lors de la publication des données open data, comme le prévoit la LOM.

L’association OpenStreetMap France considère que cette proposition, bien que légitime dans ses objectifs, mènerait nécessairement à une fragilisation du cadre juridique de publication et d’utilisation des données ouvertes en France.

La licence ODbL, actuel standard contractuel reconnu au niveau national autant qu’international, doit demeurer le socle de notre stratégie collective de collaboration et non pas être remplacée par une licence exotique instaurant de nouvelles barrières d’utilisation.

Licence de réutilisation vs CGU

Les licences ont pour but de définir les règles de réutilisation concernant des données, un contenu ou du code source (soumis à une propriété intellectuelle), là où les CGU (Conditions Générales d’Utilisation) définissent les règles d’accès à un service.

En instaurant un “principe d’identification du réutilisateur” la “Licence Mobilité” impose une déclaration d’utilisation des données.

Elle mélange ainsi des concepts très différents et intègre des clauses qui relèvent des CGU pour accéder et utiliser un service et non pas pour la seule réutilisation des données, objet habituel et exclusif d’une licence.

Pour des besoins légitimes de régulation d’usages de services (tels que des API), la “licence Mobilité” impose à tous les réutilisateurs potentiels des contraintes qui n’ont plus de rapport avec le besoin légitime initial comme l’authentification ou l’intégration du paiement éventuel directement dans la licence.

L’authentification obligatoire

Par ailleurs, inclure cette obligation dans la licence limite très fortement les réutilisations indirectes des données. Ce frein à la réutilisation relève uniquement des CGU, comme l’atteste sa référence.

Si un concédant met en place un accès authentifié, celui-ci s’imposera-t-il en cascade ?

Il ne serait pas possible par exemple d’inclure ces données dans OpenStreetMap car aucune traçabilité des réutilisateurs n’est ni prévue ni souhaitable.

Il ne serait pas possible de publier directement ces données sur un portail open data sans qu’un système d’authentification soit prévu et conforme ; quid d’une entreprise étrangère non inscrite à l’INSEE et dépourvue de N° SIREN ? Ne pourrait-elle pas avoir accès aux données ?

Cette authentification en cascade, en plus de brider l’innovation, limiterait aussi les possibilités d’archivage et de miroir par des acteurs tiers.

Dans le cas où il n’y aurait pas d’authentification en cascade, il n’est nul besoin d’aborder le sujet dans la licence de réutilisation des données car les réutilisateurs ne voulant pas s’authentifier accéderons à des sources secondaires (miroir, archives, portail tiers, etc).

Ainsi, l’ajout de nouvelles contraintes, même si elles peuvent apparaître comme “mineures” lors de leur rédaction entraîne d’importants effets de bord négatifs en cascade.

Les compensations financières

Cette compensation est explicitement prévue en lien avec un service de fourniture des données (typiquement une API).

Une fois de plus, cette mention doit figurer dans les Conditions Générales d’Utilisation d’un service, auquel d’ailleurs la licence fait à nouveau référence et pas dans les règles de réutilisation des données en elles mêmes.

Incompatibilité avec l’ODbL

Il n’est pas possible de republier des données sous licence ODbL sous cette nouvelle licence car de nouvelles obligations sont imposées au réutilisateur. La licence ODbL interdit formellement cet ajout dans sa clause 4.8 : « You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. »

Les AOM (Autorités Organisatrices de Mobilités) devront donc préalablement vérifier qu’aucune source ODbL n’aura été utilisée dans les données qu’elles souhaiteront publier sous “Licence Mobilités” et à l’avenir ne pourront plus non plus s’appuyer sur ces sources ODbL.

Il s’agit donc d’une rupture inconciliable avec l’écosystème établi, créant de facto une nouvelle branche “mi-open-data” indépendante.

Compatibilité avec la stratégie de mobilité

Cet article de la licence fait référence :

  • au “livre II du Code des Transports”, qui concernent le transport de marchandises ;
  • aux “Schémas directeur d’aménagement, de développement durable et d’égalité des territoires” (SRADDET).

En quoi ces schémas s’appliquent à d’autres acteurs que les collectivités ?

Détournement de l’esprit du règlement européen et de la LOM

Le règlement européen 2017/1926 et la LOM ont été créé avec un objectif très clair : l’ouverture des données se fait au service de l’intérêt général. Évoquer l’intérêt général pour justifier l’ouverture des données est un détournement de l’esprit de ces textes.

Le risque de balkanisation des licences

Les auteurs de la “Licence Mobilités” remarquent à raison que “la multiplication des licences étant à l’évidence un obstacle à la réutilisation des données, la nécessité de converger vers une « licence-type » a rapidement émergé.”

Nous ne pourrions pas être plus d’accord. La création d’une licence supplémentaire “franco-française” et exotique semble néanmoins aller dans le sens inverse du but visé.
Illisible et incompatible avec les acteurs étrangers, notamment en Europe, une nouvelle licence ne pourrait qu’affaiblir le cadre législatif existant et réduire les réutilisations par le flou juridique qu’elle amène.

Ce flou se manifeste sur au moins deux points:

  • la référence à des CGU
  • la référence à la stratégie de mobilité de chaque AOM

Ces deux éléments étant spécifiques à chaque AOM, la “Licence Mobilités” au lieu de proposer un cadre unique facilitant la réutilisation des données, ouvre au contraire la porte à une multiplication des règles par leurs adaptations locales.

Ne pas pénaliser les plateformes ouvertes

Au-delà des questions juridiques, les acteurs publics (AOM, administration centrales et locales) devraient considérer l’impact du choix de la licence avec le plus grand soin.

Cette proposition de licence est en effet compatible en l’état avec l’usage des acteurs dominant du monde du transport (Google Maps en tête) mais deviendrait incompatible avec les producteurs actuels de données ODbL (dont OpenStreetMap).

Que deviendraient les données existantes des transporteurs et entreprises du transport déjà publiées en ODbL ? Ces données seraient incompatibles avec la “licence Mobilités”. Il ne serait plus non plus possible d’intégrer des données ODbL provenant de source externes à l’AOM.

L’usage de l’ODbL est bien plus large que le monde du transport : c’est le standard mondial des données ouvertes. C’est le socle de projets citoyens d’importance majeure, dont OpenStreetMap est le fer de lance.
Adopter la “licence Mobilité” incompatible avec l’ODbL, c’est aussi se couper de ce riche écosystème ouvert et favoriser les acteurs dominants.

Conclusion

Nous considérons que la “licence Mobilités”, si elle était adoptée en l’état, entraînerait une rupture de neutralité de traitement entre les différents acteurs. Elle mènerait à un affaiblissement du cadre juridique général et exclurait et affaiblirait durablement l’écosystème open data et en particulier le projet OpenStreetMap.

Nous appelons en conséquence tous les acteurs du transport à continuer à utiliser la licence ODbL, socle et standard de la politique open data dans le secteur du transport.

Nous suggérons au groupe de travail ayant produit la “licence Mobilité” de ré-orienter leurs travaux vers la rédaction de CGU standardisées pour les acteurs du transport. Ces CGU seraient les plus à même de couvrir les problématiques qui ne relèvent pas de la réutilisation de données mais de la fourniture d’un service (tel qu’une API).