Assistant d'orientation IA pour les lieux

Un assistant d'orientation IA interprète une requête de navigation en langage naturel, détermine une destination à partir des informations fiables du lieu et fournit un guidage cartographique ou un itinéraire sans considérer la découverte, le calcul d'itinéraire et le positionnement comme une seule et même fonctionnalité. Un visiteur peut demander quelle entrée utiliser, comment se rendre au hall B ou où se trouvent les toilettes accessibles les plus proches. Le modèle de langage peut extraire ces informations sous forme d'intention analysable. Le système de gestion des lieux, le moteur de routage et toute infrastructure de positionnement restent les sources de référence pour la géométrie, la connectivité, l'accès et la localisation en temps réel.

Les sections suivantes abordent la résolution des destinations, la connectivité intérieure, l'accessibilité et les filtres d'accès, les sources d'origine, l'état partagé de l'orientation, l'adéquation publique actuelle de Kaleidr, les mesures et les modes de défaillance. Pour en savoir plus, consultez les ressources suivantes : Carte de lieux IA pour les événements, Comment créer un assistant IA cartographique, Cartes d'expérience client basées sur l'intelligence géolocalisée, Concierge IA pour les hôtels et Données de localisation privées pour les flux de travail cartographiques IA.

Principes fondamentaux de l'orientation par IA

La découverte n'est pas un itinéraire : Déterminer l'emplacement du Hall B ne revient pas à calculer un chemin continu jusqu'au Hall B.

L'itinéraire n'est pas un positionnement : Un itinéraire valide peut exister avant même que le produit ne connaisse la position du visiteur.

Un plan d'étage n'est pas un réseau : L'orientation en intérieur nécessite une topologie entre les espaces, les portes, les couloirs et les transitions d'étage.

L'accessibilité et l'accès sont des critères stricts : Les escaliers, les couloirs du personnel et les zones fermées doivent être exclus du graphe, et non pas simplement obtenir un score plus faible.

Le modèle de langage interprète l'intention : Les systèmes géospatiaux et de gestion des lieux calculent les itinéraires ; l'hôte valide les actions sur la carte.

Une architecture d'orientation par IA sépare la découverte de la destination, le calcul de l'itinéraire et le positionnement intérieur optionnel avant d'afficher une orientation validée sur la carte.

Qu'est-ce qu'un assistant d'orientation par IA ?

Un assistant d'orientation IA est une interface utilisateur qui indique à une personne où aller dans un lieu complexe et comment s'y rendre, en utilisant la conversation, le contexte cartographique et des données de géolocalisation fiables. Une recherche classique peut renvoyer le nom d'une salle. Une affiche statique peut montrer un plan du bâtiment. Aucune de ces solutions n'intègre l'origine, l'étage, les conditions d'accès, l'accessibilité, les fermetures en cours et l'itinéraire affiché dans une seule et même information. Les salles de conférence, les campus, les hôpitaux, les aéroports, les complexes hôteliers et les centres commerciaux génèrent ce type de requête complexe toutes les quelques minutes. Ce produit pratique affiche clairement la destination, l'itinéraire et l'étage sur la carte, évitant ainsi au visiteur de devoir les reconstituer à partir de la signalétique, de PDF et d'une fenêtre de chat dont la caméra est fixe.

La page IA spatiale de Kaleidr mentionne Navigation parmi les options cartographiques et décrit des itinéraires adaptés aux déplacements de l'utilisateur (AI Map Chat for Customer Discovery). Cette page fait autorité concernant le positionnement de Kaleidr en matière de navigation extérieure et touristique. Le guidage vocal en intérieur repose sur un contrat différent : informations sur la destination, réseau routable et, uniquement si le déploiement le permet, système de positionnement. L’intelligence de localisation côté client utilise toujours le processus Découvrir → Comparer → Agir. Découvrir récupère une destination éligible. Comparer permet de vérifier l’étage, les correspondances, l’accessibilité et l’accès. Agir consiste à mettre en évidence un point d’intérêt, à changer d’étage, à effectuer une demande d’itinéraire lorsqu’un routage existe ou à transmettre les informations au personnel.

La tâche doit être définie avant la pile d'applications. Un visiteur peut avoir besoin de l'entrée la plus proche de sa place. Un participant à une conférence peut avoir besoin d'un chemin entre la salle actuelle et la session suivante. Un passager d'un aéroport peut avoir besoin d'un salon accessible près d'une porte d'embarquement. Un utilisateur d'un campus peut avoir besoin de l'entrée du bâtiment la plus proche d'une salle de classe. Un visiteur d'un hôpital peut avoir besoin d'images depuis l'entrée publique. Chaque tâche modifie les candidats, les contraintes strictes, les transitions verticales et la nécessité d'une position en temps réel. Partir d'une simple « navigation IA intérieure » confond ces différences et risque de donner lieu à une affirmation selon laquelle le lieu ne peut pas prendre en charge le service.

Pourquoi la découverte, le routage et le positionnement doivent-ils rester séparés ?

La découverte de la destination détermine le lieu pertinent. Le calcul d'itinéraire détermine le chemin accessible à un visiteur. Le positionnement indique où se trouve le visiteur, à quel étage et, si le matériel le permet, dans quelle direction il est orienté. Ces trois couches peuvent coopérer. Aucune ne remplace les autres. Un plan d'étage peut afficher la salle 204 sans pour autant indiquer la connectivité des couloirs, les portes ouvertes, les transitions accessibles, la disponibilité des ascenseurs pour l'étage cible et une origine fiable. Les instructions de navigation détaillées, telles que « tournez à gauche dans dix mètres », nécessitent un itinéraire et une position en temps réel avec une précision et une orientation exploitables. Le modèle de langage peut coordonner la requête. Il ne peut cependant pas fournir de topologie manquante ni un point bleu.

Le modèle conceptuel Open Geospatial Consortium 2.0 Partie 1 est le schéma conceptuel OGC actuel pour les réseaux de navigation intérieure. La norme modélise les espaces et leurs subdivisions, les propriétés géométriques et sémantiques, les types de connectivité, ainsi que les réseaux de navigation logiques et métriques (OGC IndoorGML 2.0 Part 1 – Conceptual Model, OGC 22-045r5, publié le 26 juin 2025). Un produit final n'est pas tenu de sérialiser IndoorGML. Il doit néanmoins respecter la distinction suivante : la géométrie visuelle n'est pas un graphe de navigation. L’avis de publication du 28 août 2025 de OGC décrit les encodages de la partie 2 de IndoorGML 2.0 comme étant à venir (OGC Publishes IndoorGML 2.0 Part 1 Conceptual Model Standard). La norme IndoorGML 1.1 demeure une norme IndoorGML publiée, axée sur l’encodage (IndoorGML 1.1, OGC 19-011r4, 5 novembre 2020). Citez la partie 1 pour le contrat conceptuel ; ne considérez pas un encodage GML, JSON ou SQL IndoorGML 2.0] comme une norme d’implémentation publiée tant que la partie 2 n’existe pas en tant que telle.

Le format de données de cartographie intérieure (IMD) est une norme communautaire complémentaire OGC pour les archives de localisation intérieure utilisées pour l'orientation, la navigation et la découverte, incluant des notes de modélisation pour les aéroports, les centres commerciaux et les gares (Indoor Mapping Data Format, OGC 20-094, version 1.0.0, publiée le 18 février 2021). La norme IndoorGML 2.0 Partie 1 décrit IMDF comme fournissant un modèle complet à partir duquel les applications peuvent calculer des itinéraires, tandis que IndoorGML vise une approche unifiée par graphe spatial. Pour un assistant d'orientation IA, la leçon opérationnelle est plus restreinte : des données intérieures structurées doivent exister avant que la conversation ne promette la navigation.

L'orientation en extérieur est souvent plus simple car les réseaux routiers ou piétonniers, les API de routage et GNSS existent déjà. L'assistant peut ensuite géocoder une destination, demander un itinéraire à un fournisseur et afficher le résultat. Les flux sur les campus intérieurs et hybrides nécessitent généralement une infrastructure supplémentaire : état des étages, transitions verticales, accès contrôlé et une origine qui peut ne pas provenir du navigateur. Un parcours sur un campus peut relier un segment extérieur GNSS à l'entrée d'un bâtiment, puis à un graphe intérieur. La couche conversationnelle peut expliquer la transition. Les moteurs de routage restent responsables de chaque segment.

Comment la résolution de destination doit-elle fonctionner avant le routage ?

Le routage vers la chaîne brute « Hall B » constitue un défaut du produit. L'application doit résoudre un identifiant de destination stable, le bâtiment et l'étage avant l'exécution du moteur de routage. Les noms d'affichage sont contradictoires : « Porte 12 » et « Entrée 12 » sont des entités de types différents. Les identifiants de salle, de cabine et de session sont également contradictoires dans le langage courant pour la même raison que la carte des lieux IA sépare la géométrie de la superposition d'événements. Les enregistrements dactylographiés des bâtiments, étages, entrées, pièces, portails, guichets, toilettes, ascenseurs, escaliers, zones de stationnement et points d'information permettent de synchroniser la recherche, les cartes, les itinéraires, l'accessibilité et les analyses lorsque les libellés changent.

{
  "destinationId": "hall_b",
  "buildingId": "expo_center",
  "floorId": "floor_1",
  "type": "hall"
}

L'éligibilité doit être vérifiée à la même étape. Un salon physiquement connecté peut être interdit d'accès selon la catégorie de billet, la zone de sécurité ou sa réservation au personnel. Les espaces candidats doivent être autorisés et leur statut opérationnel vérifié avant toute comparaison spatiale et explication. Les polygones restreints doivent être filtrés avant la récupération afin que le modèle de langage n'ait jamais à « mémoriser » les couloirs privés. OWASP’s LLM01:2025 Prompt Injection décrit comment le texte utilisateur ou récupéré peut modifier le comportement du modèle, notamment son influence sur les fonctions connectées. La section OWASP Top 10 for LLM Applications 2025 répertorie LLM06:2025 Excessive Agency : les actions dommageables résultant d'une sortie de modèle inattendue ou manipulée lorsqu'un système se voit accorder trop de fonctionnalités, d'autorisations ou d'autonomie. Un assistant d'orientation doit proposer une destination et une action autorisée. L'application hôte doit exécuter le déplacement de la caméra, le changement d'étage ou la requête d'itinéraire après validation du schéma, de l'accès et de l'état du réseau.

L'ambiguïté est un résultat acceptable.« Entrée principale », « Entrée nord » et « Entrée VIP » sont toutes des interprétations valides. Le produit devrait afficher les candidats saisis sur la carte ou exiger une interaction plutôt que de deviner à partir de la similarité des chaînes de caractères. La recherche directe de destination doit rester fonctionnelle même en cas d'échec de la conversation. Un visiteur saisissant Hall B ne devrait pas avoir besoin d'engager la conversation. La recherche déterministe, les filtres, la carte et la conversation pour les questions complexes doivent partager les mêmes identifiants.

Pourquoi le guidage intérieur a-t-il besoin de connectivité et non d'un plan d'étage ?

La recherche de lieu met en évidence une géométrie. Le guidage intérieur calcule le trajet sur un graphe connecté : pièce → couloir → porte → escalier ou ascenseur → autre étage. Les polygones d'affichage et les nœuds de guidage peuvent être volontairement séparés. Un polygone de pièce peut être rattaché à un nœud de porte ; les arêtes des couloirs indiquent le trajet ; les arêtes des ascenseurs et des escaliers indiquent le changement d'étage, l'accessibilité et l'état de fonctionnement. Un plan d'étage raster avec une polyligne décorative ne constitue pas ce graphe. Le guide de plan du lieu établit la même distinction entre l'affichage d'une pièce et la définition d'un itinéraire détaillé.

Un plan d'un lieu à plusieurs étages est associé à son graphe de routage pour montrer que la navigation intérieure dépend d'une connectivité explicite entre les espaces, les portes, les couloirs, les ascenseurs et les étages.

L'état des différents étages doit être explicite. L'origine et la destination doivent inclure les identifiants du bâtiment et de l'étage. L'interface utilisateur doit indiquer les changements d'étage plutôt que de masquer la transition par une simple ligne 2D. Les arêtes verticales doivent être étiquetées : escaliers, ascenseurs, escalators, rampes, accessibilité, étages desservis et état (ouvert/fermé). Le moteur de routage utilise ces attributs. Le modèle de langage peut les expliquer une fois que le moteur a renvoyé les étapes structurées. Le flux privilégié est le suivant : moteur de routage → étapes structurées → formulation plus claire, plutôt que l'invention libre d'itinéraires. Les instructions relatives aux points de repère, telles que « continuez vers le hall central, puis prenez l'ascenseur est », restent utilisables même lorsque l'orientation par boussole est indisponible.

Les fermetures temporaires sont des informations opérationnelles et non des éléments de décoration cartographique. Une panne d'escalator, un couloir bloqué, une entrée fermée, un étage inaccessible ou un dysfonctionnement d'ascenseur doivent signaler la fermeture d'un itinéraire et forcer un recalcul. L'explication affichée au visiteur doit refléter la version actuelle de l'itinéraire. L'utilisation de données géométriques obsolètes dans un texte conversationnel pose un problème de sécurité dans les lieux publics, et non un problème de copie. Le recalcul d'itinéraire est géré par le moteur : lorsqu'une origine change ou qu'un itinéraire est fermé, l'itinéraire précédent devient invalide et un nouvel itinéraire est calculé. Demander au modèle de langage de modifier les coordonnées n'est pas la bonne approche.

Comment l'accessibilité, les règles d'accès et les fermetures filtrent-elles les itinéraires ?

L'accessibilité requise est une contrainte stricte d'itinéraire. Si le visiteur demande un itinéraire accessible, les escaliers peuvent être exclus. Un chemin entièrement accessible peut nécessiter un passage sans marche, un ascenseur fonctionnel, une entrée accessible et une largeur de porte enregistrée par le lieu. Intégrer l'accessibilité dans une pondération de préférence souple peut néanmoins faire apparaître un chemin inaccessible en premier. L'absence de données d'accessibilité n'autorise pas à créer un itinéraire entièrement accessible. Lorsque le système ne recense qu'une entrée accessible et un ascenseur, il convient de préciser que ces éléments figurent sur le plan, sans pour autant garantir la certification d'un parcours entièrement accessible. Les obligations légales en matière d'accessibilité relèvent de la compétence d'un avocat spécialisé et de l'exploitant du lieu ; cet article décrit le contrat de données.

Trois itinéraires candidats sont filtrés selon l'accessibilité, les autorisations d'accès et l'état opérationnel actuel jusqu'à ce qu'il ne reste qu'un seul itinéraire valide.

La connectivité physique n'est qu'un critère d'éligibilité parmi d'autres. Les couloirs du personnel, les entrées VIP, les zones de sécurité, les zones à billetterie et les entrées des employés peuvent être praticables sur le graphe tout en étant interdits à ce visiteur. L'éligibilité d'un itinéraire repose sur la connectivité physique, les autorisations d'accès et l'état opérationnel. Les chemins restreints ne doivent jamais atteindre la couche conversationnelle avant l'application du contrôle d'accès. La séquence de sécurité est la suivante : authentification, détermination de l'accès, récupération des espaces autorisés, calcul d'un itinéraire autorisé, puis explication. Calculer un chemin traversant tous les espaces et masquer ensuite les étapes restreintes entraîne une fuite de topologie. Authentification de l'API cartographique traite des clés publiables et des clés serveur pour les Kaleidr surfaces qui relient la conversation à une carte hôte ; les règles d'accès au site restent gérées par les systèmes d'identité et de billetterie de l'hôte.

La gestion des itinéraires d'urgence et de sécurité est cruciale. Un assistant génératif ne doit pas inventer de voies d'évacuation, de procédures d'urgence ou de consignes de sécurité restreintes à partir de connaissances génériques. Utilisez les informations d'urgence approuvées par le site, les plans officiels, le personnel en direct et les alertes opérationnelles. Un système d'orientation peut afficher les emplacements des postes de premiers secours ou des sorties de secours lorsque ces informations sont officielles. Le guidage à haut risque relève du système opérationnel conçu à cet effet.

Quand le guidage a-t-il besoin d'un positionnement, et quand n'en a-t-il pas besoin ?

Chaque itinéraire nécessite une origine. Celle-ci peut provenir d'une sélection explicite sur la carte, d'un point de repère connu comme l'entrée principale, d'une dernière zone déclarée (« Je suis dans le hall A »), de la position d'un appareil extérieur ou de l'infrastructure de positionnement intérieure. L'origine manuelle doit rester disponible même en présence d'un positionnement automatique. La fiabilité repose sur les données. Un rapport de positionnement précis à quelques mètres peut guider le visiteur à l'échelle d'un couloir. Un rapport imprécis de plusieurs dizaines de mètres à l'intérieur d'un bâtiment peut entraîner la sélection d'un mauvais couloir ou d'un mauvais étage. Le système doit pouvoir indiquer que la position intérieure est incertaine et inviter le visiteur à sélectionner la zone actuelle. Un guidage fiable à partir d'une origine erronée est pire qu'une brève clarification.

Un guidage fiable à partir d'une origine imprécise est pire qu'une simple clarification. La spécification W3C Geolocation, une recommandation candidate datée du 26 mars 2026, n'autorise l'accès à la localisation de l'appareil qu'après une demande expresse et précise que l'API ne garantit pas sa position réelle. La géolocalisation par navigateur n'est pas représentée par un point bleu à l'intérieur d'un bâtiment. Les balises Bluetooth, le positionnement Wi-Fi, le positionnement visuel ultra-wideband et les systèmes spécifiques aux lieux constituent une infrastructure et non une fonctionnalité du modèle de langage. L'orientation est une condition supplémentaire pour les instructions « tourner à gauche ». Une carte peut afficher un itinéraire correct même sans cap. Lorsque le cap est indisponible, les indications de point de repère ou les informations relatives à la carte doivent remplacer les indications de boussole.

De nombreux lieux peuvent proposer un système d'orientation efficace sans suivi continu à l'intérieur. Le visiteur sélectionne un point de repère, le système calcule un itinéraire, les étapes fixes restent affichées sur la carte et le visiteur avance manuellement. Les centres de conférences, les campus, les complexes hôteliers et les musées ont souvent davantage besoin de ce type de système qu'un point bleu dynamique. Ce modèle réduit également les coûts liés à la confidentialité et à l'infrastructure. L'orientation peut créer un historique de déplacement détaillé : position intérieure actuelle, itinéraire, destinations récurrentes, lieu de travail, service médical ou participation à un événement. Le document NIST Privacy Framework (NIST.CSWP.01162020, 16 janvier 2020) considère la confidentialité comme un élément de gestion des risques d'entreprise : identifier les données collectées, pourquoi et pendant combien de temps. Il est préférable de privilégier le contexte temporaire d'origine, de destination et d'itinéraire plutôt qu'un profil de déplacement persistant. Données de localisation privées pour les flux de travail cartographiques d'IA couvre la même limite appartenant à l'hôte.

Comment l'orientation conversationnelle doit-elle partager son état avec la carte ?

La conversation devient utile une fois qu'une destination ou un itinéraire est déjà affiché sur la carte. Les actions complémentaires, comme la localisation de toilettes sur le parcours actuel, une demande pour éviter les escaliers ou une entrée plus proche de l'origine sélectionnée, dépendent de l'état partagé, et non d'une seconde liste de résultats non officielle. La carte, la liste, les instructions et le chat doivent utiliser une seule et même fiche d'orientation : origine, destination, étage actif, identifiant de l'itinéraire, version de l'itinéraire, mode d'accessibilité et niveau de confiance de la position (si un système de positionnement est présent). La sélection d'une destination peut afficher un itinéraire. La modification du mode d'accessibilité peut invalider la version actuelle et demander un nouveau calcul. Les résultats de l'assistant doivent apparaître sur la même carte que celle utilisée par le visiteur.

Un état d'orientation partagé synchronise les requêtes conversationnelles, les données d'itinéraire, le contexte de l'étage, les informations sur le lieu et les actions validées sur la carte.

{
  "routeId": "route_north_to_hall_b",
  "originId": "entrance_north",
  "destinationId": "hall_b",
  "mode": "accessible",
  "activeFloorId": "floor_1",
  "routeVersion": 4
}

Les actions sémantiques doivent rester simples : définir l'origine, sélectionner une destination, afficher l'itinéraire, changer d'étage, mettre en évidence une transition, ouvrir une fiche de destination, effacer l'itinéraire, demander un nouvel itinéraire. L'hôte valide chaque charge utile par rapport aux identifiants, à l'accès et à la version du réseau en vigueur avant l'exécution de l'adaptateur de rendu. Une carte arbitraire JavaScript ne constitue pas un contrat de contrôle. Les autorisations pour ces actions relèvent de l'application et de l'infrastructure, et non du modèle de langage. Le guide de l'assistant compatible avec les cartes décrit l'état partagé de la carte et les actions validées pour ce transfert.

Les mises à jour opérationnelles doivent versionner à la fois le réseau et l'itinéraire. La fermeture d'un ascenseur peut invalider la version 4 de l'itinéraire sur la version 18 du réseau et nécessiter la version 5. Le versionnage permet de déboguer les itinéraires obsolètes. La validation avant l'application d'un itinéraire doit confirmer que l'origine, la destination, l'autorisation, la mise à jour de l'itinéraire, les fermetures et le mode de déplacement correspondent toujours. L'état du système d'orientation change rapidement dans les lieux publics. Une connexion hors ligne ou faible est également normale à l'intérieur des bâtiments. Mettez en cache la géométrie du lieu, les étiquettes, le dernier étage et le dernier itinéraire valide, le cas échéant. La recherche directe de lieux doit être possible même en cas de défaillance de la couche conversationnelle. Les indicateurs clés de performance (KPI) du tableau de bord d’analyse spatiale relèvent de la mesure du produit et non de l'évaluation du succès par le volume de conversations.

Comment Kaleidr s'intègre-t-il à une infrastructure de navigation existante ?

La documentation développeur actuelle de Kaleidr présente le Chat comme une couche conversationnelle rattachée à une carte déjà exécutée par l'hôte. Quickstart montre comment intégrer le Chat à une instance active de Mapbox, MapLibre, Google Maps ou Leaflet. Chat attach décrit la Tour de contrôle comme une navigation pilotée par le chat, des résumés de lieux et des marqueurs de lieux superposés à la carte hôte. Les clés publiables sont verrouillées à l'origine pour le navigateur ; les clés serveur restent hors page (Auth & Scopes). Les extraits de code doivent utiliser un espace réservé évident plutôt qu'une clé dynamique.

const handle = Kaleidr.mount("#chat", {
  product: "chat",
  publishableKey: "YOUR_PUBLISHABLE_KEY",
  map: myMap,
});

Ces interfaces prennent en charge la recherche de destinations en langage naturel, les conversations cartographiques, les réponses aux questions sur les lieux, les marqueurs en direct et les mises à jour de la caméra. L'hôte conserve la propriété du moteur de rendu, des données du lieu, du moteur de routage, de la topologie intérieure, du positionnement et du contrôle d'accès. La documentation publique de Kaleidr décrit le chat cartographique basé sur l'IA, les cartes publiées, les fonds de carte conçus et l'édition de cartes. Cette documentation ne décrit actuellement aucun moteur de positionnement intérieur dédié ni aucun produit de navigation intérieure spécialisé. Une architecture appropriée repose donc sur une interaction conversationnelle et cartographique sur Kaleidr, le routage ou le positionnement intérieur spécialisé restant du ressort du lieu ou du système de navigation lorsque le déploiement l'exige. Location Intelligence APIs and Map SDK est l'interface commerciale actuelle pour les API d'inférence, les systèmes de classement, l'analyse et le support au déploiement. Le classement et le routage intérieur restent des produits distincts ; il est inutile d'intégrer un itinéraire de navigation intérieure fictif dans le langage marketing.

Les lieux hybrides correspondent toujours à cette distinction. Les étapes en extérieur peuvent utiliser un fournisseur de routage. Les déplacements en intérieur peuvent utiliser un plan du lieu. Les superpositions d'événements permettent de modifier les stands et les sessions sans avoir à reconstruire les murs, comme l'explique l'article sur les plans de lieux. Les requêtes pour les hôpitaux et les aéroports échouent souvent d'abord en raison de problèmes d'identification de la destination et d'accès, et non de tracé d'itinéraire : « imagerie » et « le salon près de la porte 42 » relèvent de problèmes d'éligibilité avant d'être des problèmes de géométrie. Le modèle de langage peut interpréter la requête. Les données commerciales autorisées et les services géospatiaux fournissent toujours les informations nécessaires.

Comment les équipes doivent-elles évaluer un assistant d'orientation IA ?

Mesurez la performance de l'orientation, et non le volume des conversations. Le taux de résolution de destination, le taux d'absence de résultat, le taux de réussite des itinéraires, les corrections d'erreur d'étage, le taux de réacheminement, les refus d'accès, le temps de retour à un itinéraire, la confirmation de destination et l'abandon d'itinéraire indiquent si les visiteurs atteignent effectivement leur destination. Si le positionnement est disponible, ajoutez les événements hors itinéraire, les erreurs de confiance de localisation et les échecs de détection d'étage. Distinguez la découverte de la navigation : une destination résolue avec un itinéraire erroné constitue un défaut différent d'une recherche infructueuse. Les noms d'événements éditoriaux tels que « destination résolue », « itinéraire demandé », « itinéraire erroné », « étage changé » et « réacheminement » relèvent de l'analyse produit et non d'événements automatiques documentés Kaleidr Analytics.

L'évaluation doit prendre en compte les ambiguïtés, les chemins inter-étages, les zones fermées, les accès restreints, les données d'accessibilité manquantes et le repli en cas de faible connectivité. Vérifiez que la carte, la liste et les instructions vocales ou écrites affichent la même version de l'itinéraire. La latence doit être attribuée à chaque étape ; les équipes qui incriminent l'« IA » constatent souvent que la résolution des itinéraires ou de l'origine est prédominante. L'achèvement des tâches prime sur le nombre d'interactions. Un visiteur qui trouve le hall B par la recherche sans utiliser la messagerie instantanée a réussi. Une longue conversation qui se termine au mauvais étage, en revanche, n'en est pas une.

Quels modes de défaillance les produits d'orientation doivent-ils éviter ?

La défaillance récurrente consiste à fusionner trois systèmes en un seul paragraphe généré. Une image de plan est traitée comme un routeur. Le modèle de langage est traité comme un système de positionnement. Les étages disparaissent. L'accessibilité devient une priorité. Des zones restreintes apparaissent. Les instructions de navigation s'affichent sans orientation. La conversation devient obligatoire. L'historique des déplacements est conservé par défaut. Chaque ligne ci-dessous représente un défaut du produit et sa correction concrète.

Erreur	Résultat	Meilleure approche
Traiter une image de carte comme un réseau de navigation	Les itinéraires ne sont pas fiables	Connectivité du modèle
Traiter le modèle de langage comme un système de positionnement	L'origine devient peu fiable	Utiliser une source d'origine explicite
Ignorer les étages	Guidage vers le mauvais étage	Suivre l'étage dans un état partagé
Laisser le modèle inventer un itinéraire	Chemin non sécurisé ou obsolète	Utiliser le moteur d'itinéraire
Traiter l'accessibilité comme une préférence	Un itinéraire inaccessible peut être prioritaire	Utiliser des contraintes strictes
Ignorer les fermetures temporaires	Itinéraire obsolète	Mettre à jour l'état des arêtes et recalculer
Itinéraire traversant des zones restreintes	Fuite d'accès	Filtrer le graphe avant le calcul d'itinéraire
Promettre un guidage vocal sans orientation	Instructions trompeuses	Utiliser des points de repère ou une terminologie relative à la carte
Rendre la conversation obligatoire	La navigation de base échoue en cas d'échec de la conversation	Conserver une recherche déterministe
Conserver le déplacement par défaut	Risque pour la vie privée	Conserver le contexte temporaire de l'itinéraire

La navigation mobile nécessite des cibles larges, des étapes lisibles et une carte qui reste utilisable même lorsque le modèle ou un itinéraire coûteux expire. Mettre en cache la géométrie de base. Dégrader l'enrichissement de manière contrôlée. Conserver un chemin issu d'une recherche saisie pour le mettre en évidence même lorsque la conversation est indisponible.

Créer une expérience de navigation conversationnelle

L'architecture fiable repose sur l'intention, la résolution de la destination, le routage autorisé, le calcul d'itinéraire, l'explication et une action validée sur la carte. Le positionnement intérieur est une couche optionnelle ajoutée ultérieurement, uniquement si le lieu dispose d'un système adapté. Kaleidr permet d'intégrer une IA spatiale conversationnelle à la carte déjà utilisée par le système hôte, tandis que la topologie du lieu et les routeurs spécialisés restent la référence pour la navigation intérieure.

Découvrez Kaleidr Enterprise pour consulter les API, les interfaces SDK et l’accompagnement au déploiement disponibles. Vérifiez les modèles d’intégration et les types de clés dans la documentation développeur de Kaleidr avant de définir un parcours d’intégration.

FAQ

Qu'est-ce qu'un assistant d'orientation IA ?

Un assistant d'orientation IA interprète les questions de navigation en langage naturel, détermine la destination souhaitée à partir d'enregistrements fiables et fournit un guidage cartographique ou routier. Le routage et le positionnement restent des systèmes distincts.

L'orientation IA est-elle la même chose que la navigation intérieure ?

Non. La conversation peut interpréter une requête de navigation. La navigation intérieure nécessite également un réseau de routage structuré et peut exiger un positionnement intérieur.

Une image de plan d'étage peut-elle servir au guidage vocal ?

Non, pas à elle seule. Un guidage fiable nécessite la connectivité entre les espaces, les portes, les couloirs, les escaliers, les ascenseurs et autres points de passage.

Qu'est-ce que IndoorGML ?

IndoorGML est une norme OGC pour les données spatiales et de navigation en intérieur. IndoorGML 2.0 Partie 1 est le modèle conceptuel actuel pour les espaces, la connectivité et les réseaux de navigation (OGC 22-045r5). OGC décrit les schémas d'encodage de IndoorGML 2.0 comme étant à venir en août 2025 ; IndoorGML 1.1 reste une version publiée axée sur l'encodage.

Qu'est-ce que IMDF ?

Le format de données de cartographie intérieure est une norme communautaire OGC (OGC 20-094, version 1.0.0) pour les archives de localisation intérieure utilisées pour l'orientation, la navigation et la découverte.

Kaleidr propose-t-il actuellement une géolocalisation en intérieur ?

La documentation publique actuelle de Kaleidr décrit l’IA spatiale, le chat cartographique, les cartes personnalisées, la publication et l’intégration aux cartes existantes. Elle ne documente pas de système de géolocalisation en intérieur dédié ; par conséquent, la géolocalisation en intérieur doit être considérée comme une fonctionnalité distincte, sauf si l’application hôte en intègre une.

Kaleidr est-il compatible avec une carte d’intérieur ?

Kaleidr peut intégrer une IA conversationnelle aux implémentations cartographiques existantes compatibles. L’application hôte reste responsable des données cartographiques, du réseau d’itinéraires et de la géolocalisation en intérieur.

Comment fonctionne l’orientation accessible ?

Les exigences d’accessibilité doivent être codées sous forme de contraintes d’itinéraire strictes, à l’aide de données de lieux vérifiées. L’assistant ne doit pas créer d’itinéraire accessible à partir d’informations incomplètes.

Un assistant cartographique IA peut-il rediriger un visiteur ?

L’assistant peut demander ou expliquer un nouvel itinéraire. Le moteur de routage principal doit recalculer l’itinéraire en fonction des conditions réseau et des règles d’accès actuelles.

Le système d'orientation doit-il suivre la position d'un utilisateur en continu ?

Uniquement lorsque le produit le nécessite et que l'utilisateur en est dûment informé ou a donné son consentement. De nombreuses applications d'orientation peuvent fonctionner avec un point de départ ou un repère sélectionné sans suivi permanent.

Références

Kaleidr. AI Map Chat for Customer Discovery. Accessed 27 August 2026. https://kaleidr.com/ai
Kaleidr. Auth & Scopes. Kaleidr Developer Docs. Accessed 27 August 2026. https://docs.kaleidr.com/platform-api/auth-and-scopes
Kaleidr. Chat attach. Kaleidr Developer Docs. Accessed 27 August 2026. https://docs.kaleidr.com/sdk/chat-attach
Kaleidr. Introduction. Kaleidr Developer Docs. Accessed 27 August 2026. https://docs.kaleidr.com/
Kaleidr. Location Intelligence APIs and Map SDK. Accessed 27 August 2026. https://kaleidr.com/enterprise
Kaleidr. Quickstart. Kaleidr Developer Docs. Accessed 27 August 2026. https://docs.kaleidr.com/quickstart
National Institute of Standards and Technology. NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0. NIST.CSWP.01162020. 16 January 2020. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf
Open Geospatial Consortium. IndoorGML 1.1. OGC 19-011r4. 5 November 2020. https://docs.ogc.org/is/19-011r4/19-011r4.html
Open Geospatial Consortium. Indoor Mapping Data Format. OGC 20-094. Version 1.0.0. 18 February 2021. https://docs.ogc.org/cs/20-094/index.html
Open Geospatial Consortium. OGC IndoorGML 2.0 Part 1 – Conceptual Model. OGC 22-045r5. 26 June 2025. https://docs.ogc.org/is/22-045r5/22-045r5.html
Open Geospatial Consortium. OGC Publishes IndoorGML 2.0 Part 1 Conceptual Model Standard. 28 August 2025. Accessed 27 August 2026. https://www.ogc.org/announcement/ogc-publishes-indoorgml-2-0-part-1-conceptual-model-standard/
OWASP Gen AI Security Project. LLM01:2025 Prompt Injection. Accessed 27 August 2026. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
OWASP Gen AI Security Project. OWASP Top 10 for LLM Applications 2025. Accessed 27 August 2026. https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf
W3C. Geolocation. W3C Candidate Recommendation Snapshot, 26 March 2026. Accessed 27 August 2026. https://www.w3.org/TR/geolocation/

@misc{kaleidr_wayfinding_ai_2026_08_27,
  title  = {AI Map Chat for Customer Discovery},
  author = {{Kaleidr}},
  note   = {Accessed 27 August 2026},
  url    = {https://kaleidr.com/ai}
}

@misc{kaleidr_auth_scopes_2026_08_27,
  title  = {Auth \& Scopes},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/platform-api/auth-and-scopes}
}

@misc{kaleidr_chat_attach_2026_08_27,
  title  = {Chat attach},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/sdk/chat-attach}
}

@misc{kaleidr_docs_intro_2026_08_27,
  title  = {Introduction},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/}
}

@misc{kaleidr_enterprise_wayfinding_2026_08_27,
  title  = {Location Intelligence APIs and Map SDK},
  author = {{Kaleidr}},
  note   = {Accessed 27 August 2026},
  url    = {https://kaleidr.com/enterprise}
}

@misc{kaleidr_quickstart_wayfinding_2026_08_27,
  title  = {Quickstart},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/quickstart}
}

@techreport{nist_privacy_framework_2020,
  title       = {NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0},
  author      = {{National Institute of Standards and Technology}},
  number      = {NIST.CSWP.01162020},
  institution = {National Institute of Standards and Technology},
  year        = {2020},
  month       = jan,
  url         = {https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf}
}

@techreport{ogc_indoorgml_1_1,
  title       = {IndoorGML 1.1},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 19-011r4},
  institution = {Open Geospatial Consortium},
  year        = {2020},
  month       = nov,
  url         = {https://docs.ogc.org/is/19-011r4/19-011r4.html}
}

@techreport{ogc_imdf_1_0_0,
  title       = {Indoor Mapping Data Format},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 20-094},
  institution = {Open Geospatial Consortium},
  year        = {2021},
  month       = feb,
  note        = {OGC Community Standard, version 1.0.0},
  url         = {https://docs.ogc.org/cs/20-094/index.html}
}

@techreport{ogc_indoorgml_2_0_part1,
  title       = {OGC IndoorGML 2.0 Part 1 – Conceptual Model},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 22-045r5},
  institution = {Open Geospatial Consortium},
  year        = {2025},
  month       = jun,
  url         = {https://docs.ogc.org/is/22-045r5/22-045r5.html}
}

@misc{ogc_indoorgml_2_0_announcement_2025_08_28,
  title  = {OGC Publishes IndoorGML 2.0 Part 1 Conceptual Model Standard},
  author = {{Open Geospatial Consortium}},
  year   = {2025},
  month  = aug,
  note   = {Accessed 27 August 2026},
  url    = {https://www.ogc.org/announcement/ogc-publishes-indoorgml-2-0-part-1-conceptual-model-standard/}
}

@misc{owasp_llm01_prompt_injection_2025,
  title  = {LLM01:2025 Prompt Injection},
  author = {{OWASP Gen AI Security Project}},
  note   = {Accessed 27 August 2026},
  url    = {https://genai.owasp.org/llmrisk/llm01-prompt-injection/}
}

@misc{owasp_llm_top10_2025,
  title  = {OWASP Top 10 for LLM Applications 2025},
  author = {{OWASP Gen AI Security Project}},
  note   = {Accessed 27 August 2026},
  url    = {https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf}
}

@misc{w3c_geolocation_2026_03_26,
  title  = {Geolocation},
  author = {{W3C}},
  note   = {W3C Candidate Recommendation Snapshot, 26 March 2026; accessed 27 August 2026},
  url    = {https://www.w3.org/TR/geolocation/}
}