Publier des cartes sur votre site ou votre app : le résultat de mon exploration du marché

Tout à commencé par une position de principe : “je n'ai pas très envie de Google Maps pour deux raisons : d'une part j'ai envie de me démarquer de l'immense majorité (plus largement ne pas dépendre encore un peu plus de Google), d'autre part j'ai un peu peur des coûts prohibitifs si - on peut être ambitieux, non ? - mon site atteint une audience conséquente”.

Alors j'ai effectué un voyage (passionnant du reste, mais ce n'est pas le sujet) dans le monde du “web géographique”, et pour résumer très rapidement ce qui va suivre : j'ai d'abord très vite choisi l'open source pour toutes les briques nécessaires, puis, après un temps j'ai caressé l'idée… d'utiliser quand même Google Maps, et finalement, j'ai trouvé une solution (ou plutôt une combinaison de solutions) qui répond parfaitement à tout ce que je souhaitais.

Mon besoin était à la fois très commun (une solution souple du point du vue du développement et de “l'habillage”, la plus “libre” et la moins chère possible, des fonds de carte esthétiques, visuellement différents de ce qu'on voit partout, mais néanmoins lisibles), et un peu particulier (il me fallait créer un outil permettant à mes utilisateurs de tracer des parcours sur une carte).

Le tout pour un site (Iperiago, qui propose des parcours touristiques thématiques) HTML5 devant fonctionner à la fois sur PC/Mac, tablettes, smartphones, à la fois en “online” et (partiellement), en “offline”.

1) des données cartographiques libres

2) un beau rendu visuel pour pas trop cher

3) une API très souple et pérenne permettant de proposer, notamment, un outil extrêmement simple de tracé “à la main” d'un itinéraire

4) la possibilité (technique et contractuelle) de stocker localement (sur le terminal de l'utilisateur, pour une situation de mobilité sans connexion Internet) des fonds de carte

5) si possible, une prise en compte des écrans retina

J'ai, logiquement, très vite regardé comment utiliser les données OpenStreetMap. OpenStreetMap, vous savez, c'est un peu le Wikipedia de la donnée cartographique, c'est incroyablement complet, parfaitement libre et très fiable car enrichi par une large communauté. En passant, cela résolvait aussi le volet contractuel du point 4.

Ceci m'a amené logiquement vers OpenLayers (version 2.12 pour ceux que ça intéresse), une librairie JavaScript open source de bonne qualité et surtout très riche, qui très vite s'est avérée couvrir parfaitement le point 3 et (moyennant quelques adaptations que seule une libraire open source nous permettait d'effectuer) le volet technique du point 4.

OpenLayers est un peu complexe au premier abord, du moins par rapport à l'API Google Maps ou à des alternatives plus simples comme Leaflet, mais c'est la seule librairie qui propose des fonctions complètes couvrant mes besoins. De surcroît, je pouvais laisser de côté les fonctions d'OpenLayers que je n'utilisais pas, afin de ne pas alourdir le temps de chargement de mes pages. Parfait.

Les autres points (2 et 5) m'ont perturbé un peu plus. En particulier, le style des cartes OpenStreetMap par défaut est… moche, il n'y a pas d'autre mot. Je voulais autre chose. Je voulais aussi ne pas dépendre des serveurs OpenStreetMap et héberger mes propres fonds de carte, à partir des données OpenStreetMap, notamment dans l'optique du mode offline. Ceci a demandé plus de recherches et un peu plus de technique, mais s'est avéré tout à fait possible. Nous avons pu monter un serveur de “tuiles” (des “bouts” de fonds de carte, en quelque sorte) basé sur OpenStreetMap et disposant d'un rendu visuel “à nous”.

Ok, mais tout cela avait quand même quelques défauts : l'infrastructure technique s'alourdissait, ses mises à jour s'annonçaient problématiques, et esthétiquement, on pouvait faire mieux encore, beaucoup mieux. De plus, je n'avais pas accès à une couche aérienne/satellite. Je n'avais pas non plus accès à des fonctionnalités impressionnantes comme le Google Street View (qui se serait bien prêté à l'exploration virtuelle des parcours que nous proposons sur Iperiago). En revanche, tout ceci ne coûtait pas un centime.

Pour un démarrage, cela suffisait amplement, mais quelque chose nous disait qu'à moyen terme, cela ne suffirait pas. C'est à ce moment que nous avons envisagé d'utiliser tout de même Google Maps, du moins à titre d'attente. L'idée n'a pas tenu très longtemps.

De fait, nous sommes finalement parti sur une “troisième voie” comme on dit : à savoir des données OpenStreetMap et la librairie OpenLayers, mais un rendu visuel propriétaire offrant toutefois à la fois une vue carte et une vue satellite/aérienne, en version retina et non retina, ainsi que des tuiles hébergées mais contractuellement téléchargeables localement, le tout pour une somme relativement modique. Nous avons choisi MapBox qui répondait à tous ces critères.

Je n'ai pas d'intérêt dans la société MapBox, je raisonne en utilisateur qui doit faire certains choix et compromis, et ce service est celui que je conseillerai dans des cas similaires au mien, cas que je considère tout de même relativement générique. CloudMade est aussi intéressant à explorer. Et il va de soi que Google Maps est un très bon service, là n'est pas la question, et pour de petits volumes ne coûtera rien et offrira encore plus (j'ai en revanche du mal à trouver des avantages concurrentiels à une solution comme Bing). Une solution entièrement gratuite comme celle que nous avions mis en place au premier abord est également tout à fait acceptable. Tout dépend, finalement, du niveau d'importance de la cartographie dans votre service.

Revenons brièvement à MapBox qui a d'abord attiré notre attention par son aspect visuel, mais surtout par le fait que le service ait été choisi en 2012 par Foursquare en remplacement de Google Maps, l'argument principal ayant été le coût. LeMonde.fr a fait le même choix en avril 2013. Pas anodin.

La morale de l'histoire est la suivante : la plongée dans le “web géographique” est techniquement plus complexe qu'il n'y paraît, mais elle vaut le coup à plusieurs titres : comprendre les possibilités offertes et imaginer ainsi des services encore plus intéressants, bien analyser les différentes offres, gratuites ou payantes, et finalement limiter la dépendance excessive de son service à des services tiers.

L'outsider

Avantages : Simple à mettre en place, riche en fonctionnalités (dont geocoding - recherche de position à partir d'adresse, et vice versa - et routing - calcul d'itinéraires), pérenne et solide

Inconvénients : Stockage local impossible, pas de version retina clé en main, coûts importants pour de très gros volumes, pas d'avantage concurrentiel évident par rapport à Google Maps

Le leader

Avantages : Très simple à mettre en place, très riche en fonctionnalités (dont geocoding et routing), pérenne et solide

Inconvénients : Dépendance supplémentaire au géant Google, manque de personnalité, coûts importants pour de très gros volumes, stockage local impossible, pas de version retina “clé en main” (il faut la coder)

Le choix intéressant

Avantages : Basé sur OpenStreetMap, indépendant de l'API, très beau rendu visuel avec une importante personnalisation, coûts raisonnables même en grand volume, stockage local possible sans ambiguité (attention, il faut le coder), version retina possible

Inconvénients : Propriétaire, pas de fonction de geocoding propre (mais il est possible d'utiliser celle d'OpenStreetMap) ou de routing

Le spécialiste de l'itinéraire

Avantages : S'ajoute aux données open source OpenStreetMap, indépendant de l'API, beau rendu visuel (dont une variante existe sous licence open source), fonction de routing, stockage local possible sans ambiguité

Inconvénients : Pas de couche satellite à des niveaux de zoom élevés en France, pas de version retina clé en main

Le socle open source

Avantages : Gratuit, ouvert, fiable, stockage local possible, indépendant de l'API, fonctions de geocoding disponibles

Inconvénients : Rendu visuel pauvre, pas de couche satellite ni de version retina clé en main, nécessité pratique d'héberger son propre serveur de tuiles ou d'utiliser un tiers