Guide de publication de cartes

La publication transforme une carte modifiable en une expérience stable que d’autres personnes peuvent ouvrir, intégrer ou utiliser dans un produit. Les principaux choix sont un lien de partage autonome, un Viewer intégré ou une intégration applicative plus poussée. Une carte en production exige aussi des règles d’accès, des domaines d’intégration autorisés, une version active, une mise en page mobile, des procédures de déploiement et de dépublication, ainsi que des mesures — pas seulement une URL.

Les sections suivantes abordent les modèles de publication, les contrôles d’accès et de domaine, la mise en page, la messagerie, les versions, l’analytique et les surfaces Kaleidr Studio et Viewer. Le contexte produit se trouve sur Kaleidr Studio. Pour le mécanisme d’intégration, consultez Comment intégrer une carte interactive. Pour la répartition des responsabilités entre builder et API, consultez Builder de cartes no-code ou API cartographique. Pour les montages SDK, consultez Qu’est-ce qu’un SDK cartographique d’IA ?.

Principes essentiels de publication

• Création ≠ publication : les brouillons évoluent ; une carte publiée requiert une surface de consultation stable.
• Choisir le couplage : le lien reste léger, l’intégration vit dans une page, l’intégration produit partage l’état applicatif.
• Contrôler l’hôte : domaines autorisés et vérification de l’origine font partie du contrat.
• Réserver l’espace : une intégration repliée est un défaut de mise en page, pas de carte.
• Versionner derrière un ID stable : mesurer, réviser, publier et revenir en arrière sans réécrire chaque page hôte.

Que signifie publier une carte ?

Créer et publier une carte sont deux étapes distinctes. Pendant la création, une équipe peut modifier lieux, couches, libellés, couleurs, tuiles, caméra, filtres, interactions et sources de données. La publication crée une surface de consultation : page autonome, intégration Web, localisateur SaaS, carte éditoriale ou vue interne en lecture seule. Un outil de création peut tolérer des brouillons. Une carte publiée doit offrir un accès, une mise en page, des performances, un comportement, un versionnement, une attribution et une surveillance prévisibles. Kaleidr Studio décrit actuellement la création comme Prompt → Process → Refine → Deploy et indique que les cartes terminées peuvent être publiées comme pages autonomes ou intégrées comme widgets (Studio).

Faut-il partager, intégrer ou connecter une carte publiée au produit ?

Trois modèles couvrent la plupart des lancements. Le lien de partage est le plus rapide pour les validations, campagnes et guides, car le site hôte demande très peu d’implémentation. Le Viewer intégré convient aux sites, landing pages, CMS et portails clients lorsque la carte accompagne le texte et un appel à l’action. L’intégration produit s’adresse aux SaaS, places de marché et flux personnalisés où filtres, enregistrements sélectionnés et état applicatif restent synchronisés avec la carte. Le bon choix dépend du rôle de la carte : contenu, expérience intégrée ou composante de l’état applicatif. Une carte peut commencer par un lien, puis devenir une intégration ou un composant produit.

La documentation développeur actuelle de Kaleidr décrit les cartes Viewer publiées comme protégées par un lien de partage et adressées par un identifiant de partage plutôt que par une clé API générale (Viewer Embed). Un share ID identifie une expérience publiée ; ce n’est pas un secret serveur et il ne faut pas le traiter comme tel. Studio indique actuellement qu’une carte peut être intégrée comme widget après publication. Chat peut s’attacher à une carte hôte existante, tandis que Viewer est conçu autour d’une expérience cartographique publiée (kaleidr.js).

Comment gérer mise en page, accès et messagerie en production ?

Définissez le contrat avant le lancement : accès public ou restreint, domaines autorisés, états brouillon, publié ou archivé, et présence éventuelle d’un instantané de données révisé sur la surface active. Les contrôles de domaine doivent utiliser des origines nues telles que https://www.example.com et https://app.example.com. La documentation Viewer actuelle décrit des domaines autorisés définis par l’éditeur pour les cartes publiées intégrées. Une page hôte protégée par connexion ne rend pas automatiquement privée une URL de carte accessible indépendamment ; les données métier privées exigent une architecture d’autorisation adaptée.

Réservez hauteur et largeur pour empêcher le repli de l’intégration. La spécification HTML recommande un title d’iframe concis afin que les technologies d’assistance puissent nommer le contexte de navigation imbriqué (HTML Standard) ; l’exigence normative d’un nom déterminable par programme pour les cadres figure dans WCAG 4.1.2. Chargez paresseusement les intégrations hors écran via loading="lazy" ; le standard HTML définit ces attributs et web.dev recommande de différer les iframes hors écran pour réduire le trafic et le travail initial. Une carte principale visible immédiatement doit au contraire faire partie de l’expérience critique. Conservez une solution textuelle — noms de lieux, adresses ou liste — pour que la page fonctionne si le Viewer échoue.

La communication entre origines doit passer par un canal contrôlé. window.postMessage() est le mécanisme standard entre fenêtres et iframes (HTML Standard). Validez event.origin pour les messages entrants et indiquez une origine cible précise pour les sortants ; n’utilisez pas "*" par défaut. La documentation Viewer décrit une interface de messages kaleidr-embed:* pour les comportements pris en charge. Les états du Viewer et de l’hôte doivent rester distincts : la carte publiée gère caméra et sélection dans le Viewer ; la page hôte gère navigation, formulaires et conversion.

// Published Viewer mount: share ID, not a server key
Kaleidr.mount("#published-map", {
  product: "viewer",
  shareId: "YOUR_SHARE_ID"
});

Comment versionner, mesurer et restaurer les cartes publiées ?

Enregistrer un brouillon ne revient pas à publier une version active. Conservez des identifiants stables pour les lieux et l’intégration afin que les pages hôtes ne cassent pas lorsque le contenu change. Versionnez derrière cet ID : modifier un nouveau brouillon, contrôler la qualité des données et l’affichage mobile, publier, vérifier la production, puis restaurer en cas d’échec. Ne mesurez pas seulement les chargements. Les signaux utiles comprennent carte prête, sélection de lieu, CTA et erreurs ; considérez ces noms comme des recommandations éditoriales sauf si le produit les documente comme événements automatiques. Séparez l’analytique de création de celle du Viewer pour ne pas polluer les entonnoirs de production avec les essais de brouillon.

Testez les échecs : domaine bloqué, share ID non publié, réseau lent et absence de solution textuelle. Domaines de production, Content Security Policy, attribution et sûreté des liens sortants font partie de la même livraison. Les pages CMS ont besoin d’un conteneur réservé et d’un instantané validé. Les produits SaaS doivent coupler la carte à l’état applicatif. Les pages marketing doivent proposer un parcours de conversion qui ne dépend pas uniquement de la carte. Les cartes temps réel et 3D imposent davantage de contraintes de performance et de repli ; ne les publiez que si la page hôte peut en supporter le coût.

Quelles erreurs de publication éviter ?

Verdict final

La publication réussit lorsque l’équipe traite la carte active comme une surface produit, non comme un export. Choisissez partage, intégration Web ou intégration produit selon le couplage requis avec le contenu hôte et l’état applicatif. Ajoutez ensuite le contrat de production : accès, domaines autorisés, espace réservé, messagerie avec origine validée, versions, mesures et restauration. Kaleidr Studio publie actuellement des pages autonomes et des widgets intégrables ; Kaleidr Viewer adresse une carte publiée par share ID. Cette séparation accélère la création, tandis que la page hôte reste responsable de la conversion, de l’accessibilité et de la discipline de livraison.

Publier avec Kaleidr Studio

Créez, révisez et déployez une carte comme page autonome ou widget intégrable, puis montez les intégrations Viewer publiées là où le site hôte en a besoin. Ouvrez Kaleidr Studio pour publier et consultez la documentation développeur pour les share IDs Viewer, les domaines autorisés et les montages SDK.

FAQ

Qu’est-ce que la publication de cartes ?

C’est la transformation d’une carte modifiable en expérience stable que d’autres peuvent ouvrir, intégrer ou employer dans un produit, avec des contrôles d’accès, de mise en page, de version et de mesure.

Quelle différence entre lien de partage et intégration ?

Le lien ouvre la carte publiée sur sa propre page. L’intégration place cette carte dans la mise en page d’un site ou produit hôte.

Quand préférer l’intégration produit ?

Lorsque filtres, enregistrements sélectionnés ou état du flux doivent rester synchronisés avec la carte plutôt que simplement entourer un Viewer autonome.

Kaleidr Viewer nécessite-t-il une clé API ?

La documentation actuelle décrit les cartes Viewer publiées comme protégées par lien de partage, non par clé API. Vérifiez la documentation avant déploiement, car les modèles d’accès peuvent évoluer.

Un share ID est-il une clé API ?

Non. Il identifie une expérience publiée. Une clé API serveur autorise des opérations privilégiées et doit rester secrète.

Dois-je charger paresseusement une carte intégrée ?

Généralement si elle est sous la ligne de flottaison ou secondaire. Si elle constitue l’interaction principale, chargez-la dans l’expérience critique et optimisez son démarrage.

Comment rendre une carte iframe accessible ?

Donnez à l’iframe un title concis, fournissez un HTML environnant utile, prenez en charge le clavier et proposez des informations textuelles ne nécessitant pas de déplacer la carte.

Deux pages interorigines peuvent-elles communiquer avec la carte ?

Oui, si l’intégration le permet. window.postMessage() offre une messagerie contrôlée. Utilisez une origine cible précise et validez celle des messages entrants.

Puis-je publier des données métier privées dans une intégration ?

Seulement si l’architecture de publication et d’autorisation est conçue à cette fin. La connexion à la page hôte ne rend pas automatiquement privée une URL de carte autonome.

Une carte publiée doit-elle être versionnée ?

Oui si des changements peuvent toucher clients, intégrations, rapports ou flux métier. Le versionnement sécurise fortement restauration et débogage.

Kaleidr Studio peut-il publier sans code ?

Oui. La page Studio actuelle indique que les auteurs créent et affinent visuellement les cartes, puis les publient comme pages autonomes ou widgets intégrables.

Références

• Kaleidr. Design Custom Maps, Powered by Spatial AI. Kaleidr Studio. Consulté le 19 août 2026. https://kaleidr.com/studio
• Kaleidr. kaleidr.js Loader. Kaleidr Developer Documentation. Consulté le 19 août 2026. https://docs.kaleidr.com/sdk/kaleidr-js
• Kaleidr. Viewer Embed. Kaleidr Developer Documentation. Consulté le 19 août 2026. https://docs.kaleidr.com/sdk/viewer-embed
• WHATWG. HTML Standard — Lazy loading attributes. Consulté le 19 août 2026. https://html.spec.whatwg.org/multipage/urls-and-fetching.html#lazy-loading-attributes
• WHATWG. HTML Standard — The iframe element. Consulté le 19 août 2026. https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-iframe-element
• W3C. Understanding Success Criterion 4.1.2: Name, Role, Value. WCAG 2.2. Consulté le 19 août 2026. https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html
• WHATWG. HTML Standard — Posting messages. Consulté le 19 août 2026. https://html.spec.whatwg.org/multipage/web-messaging.html#posting-messages
• web.dev. Lazy load images and iframe elements. Consulté le 19 août 2026. https://web.dev/learn/performance/lazy-load-images-and-iframe-elements

@misc{kaleidr_studio_publish_2026,
  title  = {Design Custom Maps, Powered by Spatial AI},
  author = {{Kaleidr}},
  note   = {Kaleidr Studio; accessed 19 August 2026},
  url    = {https://kaleidr.com/studio}
}

@misc{kaleidr_viewer_embed_2026,
  title  = {Viewer Embed},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Documentation; accessed 19 August 2026},
  url    = {https://docs.kaleidr.com/sdk/viewer-embed}
}

@misc{kaleidr_js_loader_2026,
  title  = {kaleidr.js Loader},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Documentation; accessed 19 August 2026},
  url    = {https://docs.kaleidr.com/sdk/kaleidr-js}
}

@misc{whatwg_iframe_2026,
  title  = {HTML Standard -- The iframe element},
  author = {{WHATWG}},
  note   = {Accessed 19 August 2026},
  url    = {https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-iframe-element}
}

@misc{wcag_412_2026,
  title  = {Understanding Success Criterion 4.1.2: Name, Role, Value},
  author = {{W3C}},
  note   = {WCAG 2.2; accessed 19 August 2026},
  url    = {https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html}
}

@misc{whatwg_lazy_loading_2026,
  title  = {HTML Standard -- Lazy loading attributes},
  author = {{WHATWG}},
  note   = {Accessed 19 August 2026},
  url    = {https://html.spec.whatwg.org/multipage/urls-and-fetching.html#lazy-loading-attributes}
}

@misc{whatwg_postmessage_2026,
  title  = {HTML Standard -- Posting messages},
  author = {{WHATWG}},
  note   = {Accessed 19 August 2026},
  url    = {https://html.spec.whatwg.org/multipage/web-messaging.html#posting-messages}
}

@misc{webdev_lazy_iframe_2026,
  title  = {Lazy load images and iframe elements},
  author = {{web.dev}},
  note   = {Accessed 19 August 2026},
  url    = {https://web.dev/learn/performance/lazy-load-images-and-iframe-elements}
}