La première partie est ici.

Résumé de l’épisode précédent :

Le marché de la mobilité peut se décrire sous la forme de 4 strates de services superposées : l’infrastructure, les règles, les véhicules et les services au voyageur.

Cette architecture ressemble à celle des outils numériques que vous utilisez au quotidien : les infrastructures de communication, les operating systems, les devices (PC, smartphones,…) et enfin les logiciels. À la grande différence que, contrairement aux smartphones, l’internet de la mobilité n’existe pas encore : absence de standards, de connectivité, d’interfaces, stratégie de fermeture…Un automobiliste des années 50 qui débarquerait dans nos villes ne serait pas perdu. Malgré les nombreuses promesses technologiques, la mobilité est encore construite autour des capacités et limites physiques de la personne au volant (ou au guidon, ou à pied) : ce qu’elle peut voir, mémoriser, son temps de réaction,…

Conséquence de ces blocages, c’est par le voyageur que les plateformes numériques sont entrées dans le marché de la mobilité.

1. Google, acteur de la ville depuis 2004

Google lance Maps, une solution de cartographie numérique, début 2005. Après avoir “indexé le web”, l’entreprise de Moutain View s’attaque à l’indexation du monde physique. L’internaute peut désormais visualiser, mémoriser, voire visiter le lieu recherché sans quitter sa recherche en ligne.

L’investissement de Google pour son produit phare est énorme : la cartographie est agrémentée de photos à 360 degrés, vues aériennes haute définition et satellites. Dès le départ, le service n’est pas conçu comme une application stand alone, mais comme une couche de services : des APIs sont ouvertes pour permettre à des sites tiers d’intégrer ces cartes et les utiliser en “fonds de plan”. Le service sera également ouvert aux développeurs tiers et aux contributeurs pour compléter et améliorer les informations. L’acquisition de Waze en 2013 apportera une communauté étendue de contributeurs. Les données en temps réel “crowdsourcées” auprès de dizaines de millions d’automobilistes permettent de réaliser des cartographies dynamiques que l’on croyait réservées à la science-fiction.Si l’un des objectifs de Google Maps était de guider les automobilistes, le transport public y fut intégré à l’origine. Google Transit fut d’abord un projet interne de tripplanner (service de recherche d’itinéraires et choix de mode de transport). Les réseaux de bus n’avaient pas de données facilement intégrables ? Qu’à cela ne tienne, Google inventa le Google Transit Feed Specification, un format de données qui deviendra un standard mondial sous l’acronyme “GTFS”, le G de General prenant la place d’un Google devenu trop visible.

La force de Google est là : maîtriser la plateforme, les contenus, les canaux et les standards. Rien n’est plus simple que de créer une carte avec ses solutions. La barrière à la sortie est élevée également, car quitter Google suppose de changer de standard et se couper de son “écosystème”. Cette situation lui donne un avantage compétitif très fort, bien au-delà de sa position dominante dans la recherche sur le web.

2. Si la donnée ne vient pas à toi, crée ta donnée

La conquête des couches suivantes – véhicules, règlementation et infrastructure – s’est révélée beaucoup plus difficile. Les constructeurs automobiles, bien briefées par le précédent de Nokia, ont bloqué l’accès à leurs véhicules (voir première partie). Le changement de ce côté sera lent, sans doute impulsé par la Chine. L’action conjointe des autorités chinoises et de géants comme Didi Chuxing devrait changer le paradigme de l’automobile : ce ne seront plus les constructeurs qui définiront le cahier des charges des véhicules, mais les opérateurs de mobilité partagée.

Lire Comment Didi va bouleverser la possession de la voiture et la manière de les fabriquer

Et les villes ? On aurait pu croire que l’arrivée de ces solutions dans leur champ d’action soit bien accueillie. Mais pour des raisons à la fois stratégiques – ne pas dépendre d’un fournisseur dont on ne maîtrise rien – et techniques – la mauvaise qualité des données produites – les villes ont réagi comme les constructeurs auto. La “peur de Google” a même limité l’ouverture des données publiques et d’intérêt général, limitation qui a en premier lieu pénalisé…les entreprises françaises.

D’où un changement récent de stratégie des géants du web. Les villes ne veulent pas ouvrir leurs données ? Nous les reconstituerons, puis…les ouvrirons aux villes.

Démonstration :

“Nous voulons que les développeurs, les associations, les villes,…utilisent cette information pour construire, tester et apprendre” dit Stephen Smyth, CEO de Coord dans un article récent “un marché prospère de la mobilité a besoin de données ouvertes”. Coord est une filiale de Sidewalk Labs, elle-même filiale de Google (j’espère que vous suivez). Coord se décrit comme “une nouvelle plateforme basée sur le cloud destinée aux entreprises de transport à la demande”.

La proposition de valeur est claire : “un peu de code qui intègre tous les services de mobilité comme les taxis, autopartage, covoiturage, vélos partagés, aussi bien que les transports publics traditionnels. Moyennant paiement, Coord fournit aux développeurs de ces entreprises accès à des données approfondies, standardisées exposées sous forme d’APIs”.

Concrètement, les développeurs peuvent intégrer dans leurs propres solutions des informations comme celles-ci :

Pratique si vous êtes, par exemple, une entreprise dont les véhicules doivent se garer fréquemment. Exactement le type de services que l’on attendrait des villes et de leurs concessionnaires.

On distingue mieux leur ambition : construire le meccano de la mobilité en fournissant briques, outils et interfaces aux développeurs du monde entier. Si vous voulez comprendre jusqu’où peut aller cette stratégie, suivez l’exemple d’Amazon qui a développé ce type d’architecture dans les domaines du retail et de la logistique.

Lire notre article sur Amazon, l’Empire invisible

La force des entreprises comme Google est de penser d’abord “réutilisation” (par des tiers, des développeurs, des chercheurs) : “nous voulons aider les développeurs à travailler sur de nombreuses villes avec une seule intégration” (Coord, précité). Plutôt que de chercher l’information dans de multiples bases de données sous des formats pénibles à harmoniser, les développeurs trouvent une seule API avec laquelle ils travailleront mieux et plus rapidement. Cette culture du developer first se retrouve aussi dans la capacité à intégrer très tôt les réutilisateurs dans l’amélioration de leurs solutions, quand elles ne sont carrément par exposées en open source. Concrètement, des adaptations peuvent être réalisées par le développeur qui intègre la solution, adaptations qu’il est encouragé à partager avec le reste de la “communauté”.

[mise à jour 30/05 : je viens de trouver cet outil très intéressant qu’Uber met à disposition des chercheurs et développeurs pour utiliser des données cartographiques : lien ]

En résumé, ces entreprises créent des services “prêts à consommer” là où l’open data des villes propose des ingrédients en vrac, sans plats ni assiettes ni couverts. Mais pourquoi donc les villes ne produisent-elles pas ce type de services ?

3. Ville et startups, d’abord un problème de culture

Je passe beaucoup de temps dans mon métier de consultant à expliquer aux startups BtoC pourquoi elles n’arriveront pas à conquérir des marchés publics de transport. En parallèle, j’essaie d’expliquer aux collectivités et aux opérateurs pourquoi il est si difficile de travailler avec des startups.

J’ai tenté de résumer dans le tableau ci-dessous les principaux “points d’achoppement” entre ces deux acteurs. Et encore, je ne parle pas réglementation, seuil de marchés publics et délais de décision.

Il faudrait évidemment un livre entier pour expliciter et nuancer chaque élément.

Si vous êtes une startup, ne retenez que ces quelques points clés :

• la ville est “produite” par les collectivités, c’est à dire des techniciens et des élus
• habitués à travailler avec des spécialistes
• pour des réalisations et des bénéfices locaux
• avec des mécanismes de création, décision et production qui privilégient la prévision, la maîtrise et le contrôle
• pour un coût / une recette connu(e), prévisible et analysable.

Si vous êtes une collectivité, voici quelques indices :

• les startups développent des produits, pas des services sur commande
• elles sont habituées à travailler en écosystème, pas pour un seul client
• leur produit n’est jamais fini, toujours en révision
• leur marché est global, pas local
• leur rentabilité ne se calcule pas marginalement sur chaque marché.

Je vous invite à lire mon article :  Startups et Transport Public : je t’aime moi non plus pour aller plus loin.

Les choses bougent cependant. Des collectivités évoluent, s’interrogent et cherchent le meilleur de tirer parti du numérique sans rien lâcher de leurs exigences de transparence, maîtrise et protection des citoyens.

4. Pour une empathie de la donnée

Ouvrir ses données n’est que le début. Surtout quand ouvrir les données consiste à créer un simple portail *maville.opendata* avec des formats exotiques, des licences contraignantes et peu d’assistance aux valeureux réutilisateurs qui s’y frotteront.

La clé est d’inverser le processus habituel de décision en vous demandant :

• quelles sont les ressources qui peuvent objectivement intéresser des tiers  ?
• en quoi ces tiers peuvent-ils contribuer à la réalisation de mes objectifs ?
• quelles relations avez-vous établies préalablement avec ces tiers ?
• quelles sont les limites dans la réutilisation que je souhaite imposer à ces tiers ?
• en quoi ces limites contribuent-elles à améliorer la créativité et l’innovation ?

La question des ressources est primordiale. Devenir une ressource pour les autres est au coeur de la stratégie des entreprises du numérique, comme j’ai tenté de le démontrer dans ce long article. Conquérir la confiance et la loyauté des tiers est essentiel. Ce n’est pas avec des voitures volantes ou autonomes que les “nouveaux entrants” détrôneront les constructeurs automobiles et les opérateurs de transport. C’est avec “un écosystème tout entier” comme le constatait avec dépit le CEO de Nokia en 2011 : des outils, des tutoriaux, des mentors, des applications, des interfaces,…

En s’appliquant méthodiquement et patiemment à reconstituer le meccano de la mobilité, les “géants” et futur géants du web prennent la place de celles et ceux qui n’ont pas voulu ou pas su comprendre cette nouvelle logique. Aux villes maintenant de se prendre en main pour changer leur manière de produire des services à l’ère numérique.

La première partie est ici

Si vous avez aimé cet article, vous pouvez le partager

Post-liminaire : je m’aperçois que je n’ai pas parlé d’Open Street Map, de Apollo.auto ni de la Fabrique des Mobilités, qui sont pourtant à mes yeux des alternatives intéressantes aux plateformes privées. Ce sera pour un prochain article !

Précision : 15marches a participé au projet d’intégration du covoiturage dans l’application Vianavigo.