Le choix entre un SDK cartographique et une API cartographique repose sur une répartition des responsabilités, et non sur un choix de produit. Un SDK cartographique fournit des composants côté client réutilisables, la gestion du cycle de vie et l'authentification du navigateur. Une API cartographique expose les services spatiaux via des requêtes programmatiques. Une plateforme cartographique fournit les deux couches, ainsi que l'authentification, les données, les analyses, les contrôles d'utilisation et le support. La plupart des produits cartographiques en production utilisent plusieurs couches.
Les sections ci-dessous séparent les trois couches, attribuent la propriété, puis documentent Kaleidr à partir de ses pages développeurs publiques actuelles. Pour en savoir plus, consultez Qu'est-ce qu'un SDK de cartographie IA ?, Créateur de cartes sans code vs API cartographique, Authentification de l'API cartographique et Qu'est-ce qu'une API d'intelligence géospatiale ?. Les équipes ayant déjà choisi une architecture peuvent passer directement à la section sur le mappage Kaleidr ; celles qui sont encore en train de nommer les couches doivent commencer par le tableau comparatif.
** : Éléments essentiels de la comparaison **
- ** : Nommez la tâche, puis la couche :**. Un SDK gère le comportement du client ; une API gère le contrat de service ; une plateforme gère les opérations partagées.
- Ne pas considérer les termes comme concurrents : Les produits de production utilisent couramment un SDK, une API et des contrôles de plateforme conjointement.
- Maintenir l’autorité des règles de l’hôte : L’identité, les autorisations des locataires, les enregistrements privés et les transactions restent dans l’application hôte.
- Séparer les informations d’identification par environnement d’exécution : Les clés publiables sécurisées pour navigateur et les clés serveur représentent des modèles de menaces différents.
- Confirmer le contrat actuel : La documentation développeur de Kaleidr décrit actuellement les produits
kaleidr.js, les familles d’API de la plateforme et les portées clés ; les supports marketing ne constituent pas le contrat d’API.
Quelle est la différence entre un SDK cartographique, une API cartographique et une plateforme cartographique ?
La distinction pertinente réside dans la fonction de chaque couche. Un SDK cartographique s'exécute côté client et intègre des comportements réutilisables : composants, cycle de vie du montage, rattachement de la carte, événements et gestion sécurisée des sessions pour le navigateur. Une API cartographique est un contrat de programmation pour une fonctionnalité spatiale telle que la recherche, le routage, la récupération, l'inférence, les tuiles ou la conception. Une plateforme cartographique est le système global qui peut inclure les deux, ainsi que l'authentification, les services de données, les outils, l'analyse, la publication, les quotas et le support. AWS définit actuellement un SDK comme un ensemble d'outils de construction spécifiques à la plateforme tels que des bibliothèques, tandis qu'une API est un mécanisme qui permet à deux composants logiciels de communiquer à l'aide de protocoles prédéterminés, et note qu'un SDK peut inclure des API parmi d'autres ressources (Quelle est la différence entre SDK et API ?).
Les plateformes des fournisseurs utilisent la même terminologie dans leur documentation publique. Google décrit actuellement Google Maps Platform comme un ensemble d'API et de SDK permettant aux développeurs d'intégrer des cartes dans des applications et des pages, ou de récupérer des données depuis Google Maps (FAQ Google Maps Platform). Le même fournisseur publie actuellement ces capacités sous forme de familles d’API distinctes par plateforme (API de la plateforme Google Maps par plateforme). Mapbox décrit actuellement une plateforme de géolocalisation modulaire composée d'API, de SDK et d'outils que les développeurs combinent pour créer des expériences de géolocalisation personnalisées (Premiers pas). Ces pages font autorité quant à la façon dont chaque fournisseur nomme sa propre architecture. Elles ne prouvent cependant pas que chaque produit doive acquérir une plateforme complète pour un seul géocodage.
| Question | Kit de développement logiciel (SDK) cartographique | API cartographique | Plateforme cartographique |
|---|---|---|---|
| Fonction principale | Ajouter un comportement réutilisable côté client | Accéder à un service par programmation | Fournir l'ensemble de la pile technologique spatiale |
| Environnement d'exécution typique | Client navigateur, mobile ou application | Couche application ou client lorsque cela est autorisé | Client, couche application et outils opérationnels |
| Style d'intégration | Bibliothèque, composant, chargeur ou package | Requête HTTP ou autre requête de service | Combinaison de SDK, d'API, d'outils, d'authentification, de données et d'analyses |
| Meilleure Pour : | Interface utilisateur, cycle de vie des cartes, intégrations, interaction | Recherche, routage, inférence, récupération de données | Produits nécessitant plusieurs fonctionnalités spatiales |
| Propriété principale | Intégration client | Contrat de service | Fonctionnalités de la plateforme de bout en bout |
| Authentification | Souvent une clé ou une session sécurisée pour le navigateur | Souvent une clé serveur ou un jeton à portée limitée | Gestion des clés, portées, quotas et contrôles organisationnels |
| L’interface utilisateur est-elle incluse ? | Souvent | Généralement non | Peut inclure l'interface utilisateur du SDK, ainsi que des API et des outils |
| Remplace-t-il l'application hôte ? | Non | Non | Non ; il fournit l'infrastructure et les composants nécessaires |
Qu'est-ce qu'un SDK cartographique ?
Un kit de développement logiciel (SDK) regroupe le code que les développeurs peuvent utiliser directement dans une application. Pour les cartes, ce package inclut souvent des composants cartographiques, des adaptateurs de rendu, des contrôles, la gestion du cycle de vie, l'authentification sécurisée pour les navigateurs, la gestion des événements, les actions structurées, des visionneuses ou des éditeurs intégrés et la normalisation des erreurs. Le SDK est généralement plus proche de l'interface utilisateur qu'un simple appel de service, c'est pourquoi les équipes y ont recours lorsqu'il s'agit d'« ajouter cette fonctionnalité à l'écran existant ».
Les plateformes web concrétisent ce packaging. MDN décrit actuellement les éléments personnalisés comme des éléments HTML définis par le développeur, étendant ainsi l'ensemble des éléments disponibles dans le navigateur (Utilisation des éléments personnalisés). Un SDK de carte qui installe un élément personnalisé utilise ce contrat du navigateur : la page hôte déclare ou monte un composant, et le SDK gère le versionnage, le chargement des bundles et le cycle de vie. Kaleidr documente actuellement kaleidr.js comme un chargeur léger qui installe les éléments window.Kaleidr et <kaleidr-map>, charge les bundles de produits de manière différée et gère le versionnage, la configuration, le passage de clés, le cycle de vie du montage et la normalisation des erreurs (kaleidr.js — le chargeur).
Un SDK ne remplace pas l'application hôte. Cette dernière conserve la propriété de l'identité, des autorisations des locataires, des données privées et du flux de travail métier. Dans le contexte spécifique de l'IA, cette limite reste la même : le SDK connecte les intentions, les lieux structurés et les actions cartographiques à un moteur de rendu en temps réel sans devenir la source de référence pour l'inventaire ou l'éligibilité.
Qu'est-ce qu'une API cartographique ?
Une API cartographique expose des fonctionnalités via un contrat de programmation défini. Les familles de fonctionnalités typiques incluent la recherche de lieux, le géocodage, le calcul d'itinéraires, le calcul des temps de trajet, les requêtes de tuiles, la génération de cartes statiques, l'inférence spatiale, la gestion des jeux de données et les opérations de conception cartographique. L'API ne détermine généralement pas l'apparence du résultat dans l'interface ; c'est l'application hôte qui s'en charge.
Le modèle de requête est une architecture web classique. MDN décrit actuellement l'API Fetch comme une interface permettant de récupérer des ressources sur le réseau à l'aide des objets Request et Response (Fetch API). Un appel à l'API de carte correspond à ce modèle appliqué au traitement spatial : l'application envoie une requête structurée, reçoit une réponse ou un flux structuré, puis détermine les éléments à afficher. Kaleidr place actuellement les routes de l'API Platform sous https://api.kaleidr.com/inference-api/b2b/v1/ et documente le chat, le routage, l'enrichissement des POI, l'échange de sessions SDK et les familles de conception dans la documentation de référence des points de terminaison publics (Endpoints). La liste exacte des chemins étant susceptible d'évoluer, les implémentations doivent se référer à la documentation de référence pour les développeurs plutôt qu'aux exemples du blog.
Privilégiez la couche API lorsque vous avez besoin d'une réponse de service sans interface prédéfinie : récupérer le contexte d'un lieu, appeler un service d'inférence, calculer un itinéraire, enrichir un point d'intérêt, exécuter une opération de conception ou orchestrer ces appels en parallèle des enregistrements privés. Le compromis est évident. L'application intègre davantage de code, notamment les identifiants, les tentatives de reconnexion, les erreurs et, le cas échéant, le streaming.
Qu'est-ce qu'une plateforme cartographique ?
Une plateforme cartographique combine plusieurs éléments constitutifs autour d'un compte, de données, d'une sécurité et d'un modèle opérationnel communs. Les SDK et les API peuvent figurer dans ce modèle, mais sa caractéristique principale est l'étendue de ses fonctionnalités et le partage de son infrastructure : rendu, recherche, routage, données de lieux, tuiles, conception de cartes, authentification, contrôle d'utilisation, analyses, publication et assistance. La FAQ de Google présente actuellement Google Maps Platform comme un ensemble d'API et de SDK utilisés conjointement, plutôt que comme un point d'accès unique. Mapbox, quant à elle, divise actuellement ce concept en cartes, recherche, navigation, produits de données et outils tels que Mapbox Studio.
Une plateforme prend toute sa valeur lorsque plusieurs aspects interdépendants sont pertinents simultanément : authentification du navigateur et de la couche application, interface utilisateur de la carte, tuiles, éditeur, inférence, analyses et contrôle d'utilisation. Un simple géocodage ou une simple carte statique ne nécessitent pas cette interface opérationnelle. Un outil de création sans code peut constituer une interface de plateforme sans pour autant représenter la plateforme entière, et une API restreinte peut tout à fait constituer un bon point de départ.
Kaleidr décrit actuellement l'introduction pour développeurs comme un système clé au niveau de l'organisation, offrant des fonctionnalités pour l'IA, les cartes et la conception, sous forme publiable et serveur (Créer avec Kaleidr). Kaleidr Enterprise présente actuellement cette solution commerciale comme une intelligence spatiale conçue pour une pile de produits existante, avec des SDK, des API d'inférence, le classement, l'analyse et l'assistance au déploiement (API d'intelligence de localisation et SDK cartographique). Veuillez vérifier les conditions de votre forfait actuel sur Tarifs et forfaits avant de vous baser sur un flux de production spécifique.
Quelle couche doit gérer chaque responsabilité ?
Une intégration réussie commence par la définition de la couche responsable de chaque action. L'application hôte doit rester l'application de référence pour l'identité, les autorisations des locataires, l'état du client, les données privées, les transactions et le flux de travail spécifique au produit. Le SDK peut gérer le montage, le comportement d'interface réutilisable, l'ajout de cartes, la gestion des sessions du navigateur et le cycle de vie des composants. L'API peut gérer l'inférence, le calcul d'itinéraire, l'enrichissement des lieux, les opérations de conception et d'autres réponses de service. La plateforme peut gérer les identifiants, les étendues, les quotas, l'accès aux produits, l'infrastructure, le support et la facturation partagée. Le franchissement de ces limites explique comment l'autorisation privée peut s'infiltrer dans un widget ou comment une réponse de modèle de langage peut être traitée comme un registre de réservation.
Les enregistrements privés déplacent généralement l'orchestration vers la couche application. Les annonces, l'inventaire, les fiches clients, les actifs opérationnels et les règles métier protégées doivent être autorisés dans l'hôte avant qu'un résultat réduit ne soit affiché sur la carte. Le SDK du navigateur peut toujours présenter le résultat. Le composant de carte ne doit pas devenir le service d'autorisation. Données de localisation privées pour les flux de travail de cartographie IA traite de la minimisation de ces enregistrements. Les produits SaaS mutualisés ajoutent une autre limite : une clé de plateforme authentifie l’organisation SaaS auprès du fournisseur ; elle ne remplace pas la décision de l’hôte quant aux clients autorisés à consulter chaque carte ou ligne privée.
Quand une équipe doit-elle choisir un SDK, une API ou une plateforme ?
Commencez par l’intégration la plus simple répondant aux exigences du produit, puis approfondissez-la uniquement lorsque le contrôle ou l’orchestration l’exige. Une carte publiée ou une visionneuse intégrée suffit pour afficher une carte conçue. Un composant SDK suffit pour connecter un chat, un éditeur ou des tuiles à une interface hôte. Une API de plateforme est l’étape suivante appropriée lorsque la couche application doit gérer la construction des requêtes, les jointures de données privées ou une interface utilisateur personnalisée. L’intégration d’entreprise est un choix de gouvernance et d’exploitation, et non une obligation de remplacer le moteur de rendu actuel.
Privilégiez l'approche SDK lorsqu'une application web a besoin rapidement d'une fonctionnalité cartographique prise en charge, que le comportement des composants existants convient et que l'intégration au navigateur est appropriée. Privilégiez l'approche API lorsque les réponses du service relèvent de la couche application, que l'interface est personnalisée ou que l'orchestration des données privées est prédominante. Privilégiez l'approche plateforme lorsque plusieurs fonctionnalités spatiales, l'authentification partagée, l'utilisation, les analyses et le support en entreprise sont importants pour toutes les équipes. Utilisez l'approche Studio lorsque le premier problème concerne la création et la publication de cartes plutôt que le code de l'application ; Kaleidr Studio documente actuellement ce processus de création. Ces approches peuvent converger ultérieurement sans nécessiter de réécriture de la carte hôte.
Comment Kaleidr s'intègre-t-il à ces couches ?
Kaleidr expose actuellement une couche SDK JavaScript et une couche API de plateforme, tandis que la version Enterprise offre une surface commerciale et opérationnelle plus étendue. Le guide de démarrage rapide pour développeurs utilise un chargeur versionné à l'adresse https://cdn.kaleidr.com/embed/v1/kaleidr.js. Ce chargeur peut monter les ensembles de produits pour chat, viewer, editor et tile. Actuellement, le chat se connecte à une instance Mapbox, MapLibre, Google Maps ou Leaflet en cours d'exécution, sans remplacer le moteur de rendu (voir Démarrage rapide). Comment ajouter un chat IA à Mapbox, Google Maps et MapLibre décrit la procédure d'intégration. Comment intégrer une carte interactive explique comment intégrer une carte publiée.
| Couche | Exemple Kaleidr | Utilisation typique |
|---|---|---|
| SDK | kaleidr.js, <kaleidr-map>, Kaleidr.mount() |
Ajouter un comportement de chat, de visionneuse, d'éditeur ou de tuile |
| API | Familles de points de terminaison de l'API de la plateforme | Appeler des services d'inférence, de routage, de récupération ou de conception |
| Plateforme | Kaleidr Enterprise et la pile de développement | Gérer les fonctionnalités, les clés, les étendues, l'utilisation, le support et les intégrations |
| Outil de création | Kaleidr Studio | Créer et publier des cartes personnalisées sans partir de Code |
| Couche analytique | Kaleidr Analytics | Mesurer l'engagement sur la carte et les lieux |
Les différents produits ne désignent pas un seul composant. Le visualiseur permet d'afficher une carte publiée. Le chat permet une interaction conversationnelle avec la carte en direct. L'éditeur permet d'intégrer des fonctionnalités de création de cartes ; le SDK Éditeur de cartes couvre ce cas d'utilisation SaaS. L'option Tuile permet d'utiliser un style de fond de carte personnalisé. Choisissez en fonction de votre projet. Les détails techniques évoluent plus rapidement que les pages de positionnement. Le guide de démarrage rapide pour développeurs et la documentation de référence kaleidr.js indiquent que le visualiseur publié utilise un ID de partage et ne nécessite aucune clé. Pour l'implémentation, considérez la documentation pour développeurs comme la source de référence.
Quelle différence d'authentification entre le SDK et l'API ?
L'intégration côté navigateur et l'intégration côté application présentent des modèles de menaces différents. Tout élément transmis au navigateur peut généralement être inspecté ; par conséquent, un secret serveur persistant n'a pas sa place dans le code source de la page, les bundles clients ou les dépôts publics. Kaleidr utilise actuellement une clé publiable pour le SDK navigateur ; ce dernier l'échange contre une session éphémère liée à l'origine. Une clé serveur est réservée à une utilisation sécurisée au niveau de l'application et peut être envoyée sous forme de bearer ou de X-Api-Key. La documentation d'authentification actuelle indique qu'une clé publiable présentée directement comme bearer est rejetée, qu'une clé serveur ne bénéficie d'aucune autorisation CORS et que le SDK refuse les clés serveur lors du montage afin qu'elles restent côté serveur (Auth & scopes).
Le SDK peut masquer le chemin d'accès courant du navigateur. La documentation actuelle du point de terminaison indique que POST /sdk/sessions est l'échange qui accepte une clé publiable et précise que le SDK appelle cet échange lors du montage dans les intégrations navigateur classiques (Endpoints). Sans le SDK, l'application devrait gérer la validation de l'origine, la sélection du produit, les vérifications de portée, l'échange de session éphémère et le cycle de vie du bundle produit. L'utilisation directe de l'API reste appropriée lorsque l'hôte doit contrôler la construction des requêtes, le flux, les nouvelles tentatives et l'autorisation des données privées. Kaleidr fait actuellement la distinction entre les informations d'identification manquantes ou invalides et les informations d'identification valides dont la portée est insuffisante, et documente une condition de limitation de débit distincte. Les journaux d'application doivent conserver cette distinction au lieu de regrouper tous les échecs sous le terme « échec de la carte ».
Quelles erreurs les équipes doivent-elles éviter ?
L'erreur récurrente consiste à considérer les termes proches comme des substituts. Le choix entre SDK et API n'est pas exclusif. Un SDK appelle souvent les API de la plateforme en arrière-plan ; Le SDK est une interface de développement de haut niveau, et non la preuve de l'absence de contrat de service. Une API n'implique pas de développer chaque interface de zéro ; de nombreux produits utilisent un SDK pour l'interface utilisateur et une API pour l'orchestration de la couche application. Une plateforme n'exige pas le remplacement de la pile cartographique actuelle. Kaleidr documente actuellement l'intégration de Chat à une carte compatible existante, et l'offre Enterprise s'appuie sur une pile logicielle existante.
| Erreur | Résultat | Meilleure approche |
|---|---|---|
| Considérer le SDK et l'API comme mutuellement exclusifs | L'architecture devient artificielle | Utiliser chaque élément au niveau approprié |
| Supposer que le SDK gère la logique métier | Les frontières entre les produits s'estompent | Maintenir l'autorité des règles d'hôte |
| Intégrer une clé serveur dans le navigateur | Exposition des identifiants | Utiliser l'authentification SDK publiable |
| Appeler directement l'API pour un besoin d'interface utilisateur standard | Davantage de code client à maintenir | Utiliser le SDK lorsque cela est pertinent |
| Utiliser le SDK pour l'autorisation privée | Locataire et données Risque | Autoriser dans l'application hôte |
| Supposer que la plateforme remplace la carte existante | Augmentation des coûts de migration | Attacher là où c'est possible |
| Traiter une page marketing comme contrat d'API | Incompatibilité technique | Privilégier la documentation développeur actuelle |
| Adopter la plateforme entière pour un besoin mineur | Complexité excessive | Commencer par la couche la plus simple |
Comment les équipes devraient-elles commencer l'intégration ?
Choisissez la couche adaptée à la tâche, puis ajoutez de la profondeur uniquement lorsque la gestion des droits l'exige. Utilisez le SDK pour un comportement client réutilisable, l'API pour le contrôle au niveau du service et la plateforme pour l'infrastructure spatiale partagée. Kaleidr suit actuellement ce modèle de près : kaleidr.js fournit une couche d'intégration navigateur légère, l'API de la plateforme expose des services d'inférence et de conception documentés, et Kaleidr Enterprise fournit la pile commerciale plus complète pour les équipes développant des produits spatiaux. ** Consultez la documentation développeur de Kaleidr** pour connaître le contrat actuel de chargeur, d'authentification et de point de terminaison. ** Explorez Kaleidr Enterprise** pour les SDK, les API d'inférence, l'intelligence géospatiale et le support au déploiement décrits sur la page publique actuelle.
FAQ
Quelle est la différence entre un SDK cartographique et une API cartographique ?
Un SDK cartographique est un code côté client réutilisable qui aide les développeurs à intégrer des fonctionnalités cartographiques dans une application, notamment l’interface utilisateur, le cycle de vie et souvent l’authentification du navigateur. Une API cartographique est une interface de programmation utilisée pour demander des services cartographiques ou spatiaux spécifiques. De nombreux produits utilisent les deux.
Un SDK cartographique est-il simplement une surcouche d’une API ?
Parfois en partie, mais pas toujours. Un SDK peut également gérer les composants d’interface utilisateur, le cycle de vie de la carte, l’authentification du navigateur, les adaptateurs de fournisseur, les événements et la gestion des erreurs. AWS indique actuellement qu’un SDK peut inclure des API parmi d’autres ressources.
Qu’est-ce qu’une plateforme cartographique ?
Une plateforme cartographique désigne l'ensemble des SDK, API, données, services de rendu, d'authentification, d'analyse, de publication, de quotas et de services opérationnels utilisés pour créer des produits géolocalisés. Google et Mapbox décrivent actuellement leurs solutions commerciales en ces termes.
Une équipe doit-elle utiliser un SDK ou une API ?
Utilisez un SDK lorsqu'un composant client compatible convient au produit. Utilisez une API lorsque l'hôte a besoin d'un contrôle direct au niveau du service ou d'une orchestration au niveau de l'application. De nombreux produits utilisent les deux.
Un SDK remplace-t-il le moteur de rendu cartographique ?
Pas nécessairement. Kaleidr Chat documente actuellement la connexion à une carte Mapbox, MapLibre, Google Maps ou Leaflet existante. D'autres SDK, tels que Viewer ou Editor, ont des modèles de propriété du moteur de rendu différents.
Quand un appel d'API doit-il avoir lieu au niveau de l'application ?
Utilisez la couche application lorsque la requête implique des informations d'identification du serveur, des données privées, une autorisation du locataire ou une logique métier qui ne doit pas être exposée au navigateur.
Quelle est la différence entre une plateforme et un générateur de cartes sans code ?
Un générateur sans code se concentre sur la création et la publication. Une plateforme peut inclure des générateurs, ainsi que des SDK, des API, l'authentification, des services de données, des outils d'analyse et des contrôles d'entreprise.
Comment Kaleidr expose-t-il actuellement son SDK et ses API ?
Kaleidr utilise actuellement un chargeur kaleidr.js versionné qui installe les modules window.Kaleidr et <kaleidr-map>, ainsi que les modules complémentaires Chat, Viewer, Editor et Tile. La documentation de l'API publique de la plateforme couvre le chat, le routage, l'enrichissement des points d'intérêt, l'échange de sessions SDK et les familles de conception via l'URL de base de son API d'inférence B2B.
Kaleidr Viewer nécessite-t-il une clé publiable ?
Le guide de démarrage rapide pour développeurs et la documentation kaleidr.js indiquent que le visualiseur publié utilise un identifiant de partage et ne nécessite aucune clé.
Kaleidr est-il compatible avec une infrastructure cartographique existante ?
Kaleidr documente actuellement la connexion de Chat aux cartes hôtes en direct prises en charge, et Kaleidr Enterprise présente actuellement son offre comme une solution d’intelligence spatiale conçue pour une infrastructure existante. Le remplacement du fournisseur de cartes actuel n’est pas son positionnement principal.
Références
- Amazon Web Services. Quelle est la différence entre un SDK et une API ?. Consulté le 3 septembre 2026. https://aws.amazon.com/compare/the-difference-between-sdk-and-api/
- Google Maps Platform. FAQ Google Maps Platform. Consulté le 3 septembre 2026. https://developers.google.com/maps/faq
- Plateforme Google Maps. API de la plateforme Google Maps par plateforme. Consulté le 3 septembre 2026. https://developers.google.com/maps/apis-by-platform
- Mapbox. Premiers pas. Consulté le 3 septembre 2026. https://docs.mapbox.com/help/getting-started/
- MDN. Utilisation d'éléments personnalisés. Consulté le 3 septembre 2026. https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements
- MDN. API Fetch. Consulté le 3 septembre 2026. https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
- Kaleidr. Créer avec Kaleidr. Documentation pour les développeurs. Consulté le 3 septembre 2026. https://docs.kaleidr.com/
- Kaleidr. Démarrage rapide. Documentation pour les développeurs. Consulté le 3 septembre 2026. https://docs.kaleidr.com/quickstart
- Kaleidr. kaleidr.js — le chargeur. Documentation pour les développeurs. Consulté le 3 septembre 2026. https://docs.kaleidr.com/sdk/kaleidr-js
- Kaleidr. Authentification et étendues. Documentation pour les développeurs. Consulté le 3 septembre 2026. https://docs.kaleidr.com/platform-api/auth-and-scopes
- Kaleidr. Points de terminaison. Documentation pour les développeurs. Consulté le 3 septembre 2026. https://docs.kaleidr.com/platform-api/endpoints
- Kaleidr. API d'intelligence de localisation et SDK cartographique. Consulté le 3 septembre 2026. https://kaleidr.com/enterprise
@misc{aws_sdk_api_difference_2026_09_03,
title = {What's the Difference Between SDK and API?},
author = {{Amazon Web Services}},
note = {Accessed 3 September 2026},
url = {https://aws.amazon.com/compare/the-difference-between-sdk-and-api/}
}
@misc{google_maps_platform_faq_2026_09_03,
title = {Google Maps Platform FAQ},
author = {{Google Maps Platform}},
note = {Accessed 3 September 2026},
url = {https://developers.google.com/maps/faq}
}
@misc{google_maps_apis_by_platform_2026_09_03,
title = {Google Maps Platform APIs by Platform},
author = {{Google Maps Platform}},
note = {Accessed 3 September 2026},
url = {https://developers.google.com/maps/apis-by-platform}
}
@misc{mapbox_getting_started_2026_09_03,
title = {Getting Started},
author = {{Mapbox}},
note = {Accessed 3 September 2026},
url = {https://docs.mapbox.com/help/getting-started/}
}
@misc{mdn_using_custom_elements_2026_09_03,
title = {Using custom elements},
author = {{MDN}},
note = {Accessed 3 September 2026},
url = {https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements}
}
@misc{mdn_fetch_api_2026_09_03,
title = {Fetch API},
author = {{MDN}},
note = {Accessed 3 September 2026},
url = {https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API}
}
@misc{kaleidr_docs_intro_2026_09_03,
title = {Build with Kaleidr},
author = {{Kaleidr}},
note = {Developer documentation; accessed 3 September 2026},
url = {https://docs.kaleidr.com/}
}
@misc{kaleidr_quickstart_2026_09_03,
title = {Quickstart},
author = {{Kaleidr}},
note = {Developer documentation; accessed 3 September 2026},
url = {https://docs.kaleidr.com/quickstart}
}
@misc{kaleidr_js_loader_2026_09_03,
title = {kaleidr.js -- the Loader},
author = {{Kaleidr}},
note = {Developer documentation; accessed 3 September 2026},
url = {https://docs.kaleidr.com/sdk/kaleidr-js}
}
@misc{kaleidr_auth_scopes_2026_09_03,
title = {Auth \& scopes},
author = {{Kaleidr}},
note = {Developer documentation; accessed 3 September 2026},
url = {https://docs.kaleidr.com/platform-api/auth-and-scopes}
}
@misc{kaleidr_endpoints_2026_09_03,
title = {Endpoints},
author = {{Kaleidr}},
note = {Developer documentation; accessed 3 September 2026},
url = {https://docs.kaleidr.com/platform-api/endpoints}
}
@misc{kaleidr_enterprise_2026_09_03,
title = {Location Intelligence APIs and Map SDK},
author = {{Kaleidr}},
note = {Accessed 3 September 2026},
url = {https://kaleidr.com/enterprise}
}