Pourquoi une autre API cartographique?

Bonne question. D'abord la version la moins flatteuse.

Le monde n'a pas besoin d'un autre serveur de tuiles. Les tuiles vectorielles sont un problème résolu, et c'est Mapbox qui l'a résolu en 2014. Le géocodage est résolu deux fois, différemment, par Nominatim et Pelias. Le calcul d'itinéraires a été résolu par OSRM en 2010, puis de nouveau par Valhalla en 2015. Si unmap n'était qu'une quatrième implémentation de choses qui fonctionnent déjà, un haussement d'épaules serait la bonne réaction.

La question n'est donc pas de savoir si le monde a besoin d'une autre API cartographique. Elle est de savoir si un fond de carte est le genre de dépendance qu'on devrait louer.

Chaque affirmation ci-dessous porte sa source, parce qu'une conviction sans source n'est que du marketing.

Une carte est une opinion louée

Le volet tarifaire de cet argument a déjà été bien raconté, et il est de Cory Doctorow : les plateformes sont bonnes pour les utilisateurs jusqu'à ce que ceux-ci soient captifs, puis bonnes pour les clients commerciaux jusqu'à ce qu'ils le soient à leur tour, puis extraient de la valeur de tout le monde.¹ Les fournisseurs de cartes en réunissent les ingrédients habituels. SDK propriétaires, tarification par produit, conditions qui limitent ce que vous pouvez mettre en cache, et un coût de migration qui grimpe à chaque fonctionnalité que vous livrez.

Ce dont on parle moins, c'est que louer la carte, c'est louer ce qu'elle dit.

Le 27 août 2026, un décret présidentiel américain a renommé le lac Ontario en « Lake America » et ordonné au département de l'Intérieur de mettre à jour la base de données fédérale des toponymes.² En quelques jours, le Geographic Names Information System américain portait le nouveau nom et Google annonçait qu'il suivrait : « Lake America » pour les utilisateurs des États-Unis, « Lake Ontario » pour les utilisateurs canadiens, les deux pour tout le monde d'autre.³ La même séquence s'était déjà déroulée une fois, avec le golfe du Mexique, sous le décret 14172, en janvier 2025.⁴

Le lendemain, des sites canadiens se sont mis à l'afficher. La carte des pannes d'Hydro One, le localisateur de succursales de la LCBO, le repérage des gares de GO Transit, la liste des propriétés d'Infrastructure Ontario, la carte fédérale du logement et des infrastructures.⁵⁶ Hydro One a déclaré que le problème « provient d'un service cartographique tiers » et qu'elle travaillait avec son fournisseur.⁶ Metrolinx a désactivé sa carte.⁵

Personne, dans aucune de ces organisations, n'a tapé « Lake America ». Elles ont intégré une carte, comme tout le monde intègre une carte, et l'étiquette est arrivée toute seule. L'application grand public de Google montrait aux Canadiens le nom canadien; l'API intégrée, par défaut, non. La réponse de Google a été que les développeurs peuvent régionaliser une carte intégrée en définissant une région, et que « Lake Ontario » s'affiche quand celle-ci est réglée sur le Canada.⁵ Le correctif était donc un paramètre de configuration qu'on n'avait jamais demandé à ces équipes de choisir, et dont la valeur par défaut répondait à un autre gouvernement que leurs utilisateurs.

Ce qui en fait un problème logiciel plutôt qu'un problème de toponymie. Rien n'a changé du côté du client : aucun déploiement, aucune montée de version, aucune modification du fichier de verrouillage, aucune ligne dans aucun de ces dépôts. Toutes les autres dépendances que vous livrez sont épinglées à quelque chose, une version, une empreinte, un commit. Le fond de carte est la seule dont le contenu peut être remplacé à distance pendant que votre sortie de compilation reste identique octet pour octet, et vous l'apprenez par une capture d'écran.

Voici donc la nôtre. Les étiquettes d'un fond de carte unmap viennent d'OpenStreetMap et de Natural Earth, et les toponymes du géocodeur de la Base de données toponymiques du Canada, parmi d'autres sources ouvertes.⁷ Aucune de ces sources n'est la base fédérale américaine des toponymes, qui est le chemin qu'a emprunté ce changement. Récupérez /tiles/7/36/46 aujourd'hui et l'étiquette du plan d'eau indique Lake Ontario, avec Lac Ontario à côté dans la même tuile.

C'est une promesse plus modeste que l'immunité, et nous préférons en tracer les limites plutôt que de vous laisser les supposer. Il n'existe pas de version épinglée des tuiles, et un nom peut encore bouger ici, parce qu'OpenStreetMap peut être modifié. Ce qui change, c'est que la modification a un auteur, un horodatage et un bouton d'annulation, que ce que vous avez mis en cache reste à vous pour le servir,⁸ et qu'un nom qui change sans entrée au changelog est le premier élément de notre propre liste des façons de nous prendre en défaut.

Il n'y a pas de carte neutre, seulement des choix divulgués et des choix tus

Ontarí'io est un mot iroquoien, d'origine wendate, et les sources ne s'entendent pas sur ce qu'il dit : lac aux eaux scintillantes, ou beau lac.⁹ Il est attesté depuis au moins 1641, ce qui le place avant les deux pays que cette eau touche. Les cartes françaises lui ont opposé le lac de Saint-Louis et le lac Frontenac de 1632 à 1712, et ont perdu. En seneca, le lac se nomme sga:nyodai:yoh, beau lac, et la Nation Seneca, l'une des six nations haudenosaunee, affirme que le changement de nom contrevient au Traité de Canandaigua de 1794,¹⁰ dont le troisième article fixe la frontière de la Nation « beginning on Lake Ontario ».¹¹

Quatre cents ans de désaccord, une revendication vivante fondée sur un traité, plusieurs autorités toponymiques ayant une légitimité réelle, et aucune traduction arrêtée du nom que tout le monde se dispute. Voilà un toponyme parfaitement ordinaire, et la carte a toujours dû en choisir un. Ce qui est nouveau, c'est que le choix se fait à l'intérieur de la configuration d'un fournisseur, par utilisateur, de façon invisible, puis qu'on le qualifie de neutre.

Rien n'est neutre. Les choses sont divulguées ou elles ne le sont pas.

Les noms sont des données, pas des étiquettes

Nos enregistrements de géocodage n'ont donc pas un nom. Ils en ont un ensemble, dans la même ligne, tous interrogeables. Extrait abrégé de la réponse en production pour Montreal :

{
  "id": "23491400",
  "layer": "locality",
  "names": {
    "en": "Montreal",
    "fr": "Montréal",
    "iu": "ᒧᕆᐊᓪ"
  }
}

lang= choisit lequel d'entre eux est rendu comme le name de l'enregistrement. Même enregistrement, même identifiant, même géométrie, choisi au moment de la requête plutôt qu'en compilant contre un autre jeu de données.¹²

Les étiquettes du fond de carte fonctionnent autrement. Là, lang= sélectionne parmi les balises name:* que les tuiles portent réellement, c'est-à-dire un ensemble fixe de langues prises en charge. Les noms autochtones n'en font pas partie et ne se demandent pas ainsi : ils voyagent sur l'entité elle-même comme nom supplémentaire, de sorte qu'Iqaluit arrive comme Iqaluit avec ᐃᖃᓗᐃᑦ à côté, et l'étiquette affiche les deux lignes quelle que soit la langue demandée.¹³ Les caractères syllabiques n'ont jamais eu besoin d'être activés. Ils avaient besoin de polices capables de les dessiner.

La recherche trouve les noms dans l'écriture où vous formulez la requête, parce que l'index textuel replie toutes les langues de l'enregistrement dans le même champ BM25 :

GET /geocode/search?q=ᐃᖃᓗᐃᑦ
→ Iqaluit · layer: locality · Nunavut

Cette requête retournait autrefois trois immeubles de bureaux sans rapport, dont la ville était Iqaluit alors que les caractères syllabiques ne correspondaient à rien du tout; un test d'intégration fixe désormais top.layer === "locality". Montréal et Montreal retournent le même enregistrement, et l'accent ne coûte rien à la graphie correcte : l'index replie les accents avant de calculer le score.

Ces noms viennent de la Base de données toponymiques du Canada, publiée sous la Licence du gouvernement ouvert,⁷ et de Who's On First, dont les fiches portent les licences des sources ouvertes dont elles proviennent. Les deux sont redistribuables avec attribution. Rien qui ait été moissonné auprès de communautés qui ne l'avaient pas publié.

Montrer l'écart

Le moteur gère les caractères syllabiques. Les données, souvent, ne les portent pas.

Vérifié le 2026-09-08 sur dix grandes communautés du Nunavut et du Nunavik, une requête écrite en caractères syllabiques résout la communauté elle-même pour sept d'entre elles. ᑲᖏᕿᓂᖅ retourne Rankin Inlet. ᐃᓄᒃᔪᐊᒃ retourne une adresse située dans Inukjuak plutôt qu'Inukjuak. ᐅᖅᓱᖅᑑᖅ et ᐃᖃᓗᒃᑑᑦᑎᐊᖅ ne retournent rien du tout, parce que ces deux enregistrements ne portent leur nom inuktitut qu'en transcription latine. Chacune de ces requêtes, vous pouvez la refaire avec la clé de démonstration.

C'est un manque de sources plutôt qu'un manque du côté de la requête, ce qui est le meilleur des deux problèmes : rien dans le chemin de recherche n'a à changer, et dès qu'une ligne reçoit une valeur en inuktitut, la cuisson suivante du corpus la reprend. Mais sept sur dix, ce n'est pas de la « prise en charge de l'inuktitut », et nous n'allons pas l'appeler ainsi. Si une page de fonctionnalité ici ne vous dit pas à quelle fraction des lignes elle s'applique, c'est un défaut et vous devriez le signaler.

Pouvoir partir facilement, c'est tout l'enjeu

L'extraction exige la captivité. Les conditions ne peuvent devenir pires que les solutions de rechange que si atteindre ces solutions coûte cher, et le coût de sortie est quelque chose qu'un fournisseur construit exprès : un SDK propriétaire, un format de tuiles que seul son moteur de rendu lit, une couche d'interface que vous importez à l'exécution et ne pouvez pas bifurquer. La réponse n'est donc pas de promettre que nous resterons bons, parce que cette promesse n'a aucun mécanisme d'exécution. La réponse, c'est de garder la sortie assez peu coûteuse pour que la promesse n'ait pas d'importance.

C'est pourquoi l'étoile polaire est une carte fonctionnelle en moins de soixante secondes, et pourquoi le SDK tient en deux instructions après l'installation. Être rapide à démarrer et être rapide à partir sont la même propriété; on ne remarque laquelle on utilise qu'au moment de sortir.

npm i @unmap/sdk

Des formats standards de bout en bout. Des tuiles vectorielles Mapbox sur une simple URL z/x/y et des documents de style que lit n'importe quel moteur de rendu conforme à la spécification MapLibre, de sorte que la carte que vous avez construite est une carte que les tuiles d'un autre fournisseur peuvent remplir. Les itinéraires reviennent en LineString GeoJSON et les isochrones en FeatureCollection.¹⁴ Le moteur de rendu est MapLibre GL, pas une bifurcation, et unmap.map est l'objet carte de MapLibre lui-même plutôt qu'une façade, donc chaque événement, source, couche et contrôle de MapLibre vous reste accessible, que nous ayons pensé à l'exposer ou non. OpenStreetMap et des données gouvernementales ouvertes en dessous, pour que les données ne partent pas avec nous. Mettez en cache ce que vous récupérez aussi longtemps que vous le voulez, même après avoir annulé, ce qui est une condition contractuelle et non une faveur.⁸

L'interface se copie au lieu de s'importer. unmap add map écrit le composant dans votre propre components/ui/, en code source que vous pouvez modifier, depuis un registre en JSON plat à registry.unmap.dev/r/<item>.json que l'outil shadcn lit, et tout le reste aussi. Du code que vous possédez ne peut pas être dégradé par nous plus tard, et c'est la seule version de « nous ne nous emmerdifierons pas » qui porte son propre mécanisme d'exécution.

Ce que nous n'offrons pas, c'est l'archive elle-même. Il n'existe aucun téléchargement du fichier de tuiles mondial, et la mise en cache permissive de ce que vous récupérez n'est pas la même chose, alors nous n'allons pas appeler cela de la portabilité. Si vous jugez que nous nous sommes dégradés, nous aimerions que votre migration soit ennuyeuse.

La profondeur est une preuve, pas un territoire

Nous sommes conçus à Calgary et conçus pour le Canada dans le détail. Les toponymes autochtones sont dans l'index de recherche aujourd'hui, et la profondeur canadienne est le genre de travail qui s'étend à des jeux de données comme les descriptions officielles des terres et les restrictions routières saisonnières, plutôt qu'à d'autres pays.

C'est une preuve de méthode, pas une revendication de couverture. Le Canada reste la limite du géocodage, des itinéraires et des jeux de données détaillés ; le fond vectoriel est mondial, et c'est là que nous acceptons de faire le travail ingrat que les plateformes mondiales traitent comme secondaire. Un drapeau sur la page d'accueil ne prouve rien. Des caractères syllabiques dans l'index de recherche, oui.

Obtenir une clé → · Forfait gratuit, sans carte.