# DESCRIPTION INSTITUTIONNELLE DE LA SOLUTION
## Fonctionnement, architecture technique et technologies
### 1. Présentation générale
La solution est une plateforme numérique interactive destinée à accompagner les visiteurs au sein d'un espace événementiel, d'un salon, d'une exposition ou de tout autre environnement nécessitant une orientation et un accès simplifié à l'information.
Elle associe une interface vocale, un système de guidage basé sur une cartographie en graphe, un espace d'administration destiné aux organisateurs, une webthèque de ressources ainsi qu'une architecture de communication en temps réel.
L'objectif principal est de proposer une expérience de visite **simple, accessible, interactive et autonome, permettant au visiteur de rechercher un exposant ou un lieu, de se situer, de recevoir des indications de déplacement et d'accéder aux informations disponibles sans dépendre systématiquement d'une connexion Internet ou d'un moteur d'intelligence artificielle.
L'architecture a été conçue selon un principe fondamental : les fonctionnalités essentielles doivent rester opérationnelles indépendamment de la disponibilité d'un service d'intelligence artificielle distant.
La solution comprend notamment :
* 8 espaces fonctionnels côté visiteur ;
* 6 sections principales dans le back-office organisateur ;
* 11 outils WebMCP centralisant les actions disponibles ;
* 3 modes d'utilisation de l'intelligence artificielle ;
* une architecture serveur légère basée sur Node.js ;
* une communication temps réel reposant sur WebSocket ;
* une API REST destinée à la gestion des données ;
* un système de fonctionnement hors ligne reposant sur un service worker et une gestion séparée des contenus téléchargés.
---
# 2. Interface et interactions vocales
## 2.1. Une interface conçue autour de la voix
L'interface visiteur adopte une approche centrée sur l'interaction vocale.
À l'ouverture de l'application, l'utilisateur dispose d'un forme orbe 3D faisant office de bouton microphone principal. Cette interface réduit le nombre d'actions nécessaires et permet au visiteur d'interagir avec le système sans avoir à rechercher continuellement des commandes à l'écran.
Le fonctionnement est volontairement direct :
activation → commande vocale → interprétation → action → réponse vocale.
Les éléments graphiques complémentaires, notamment le titre ainsi que les commandes Silence, Répéter et Menu, restent disponibles mais ne constituent pas le mode d'interaction principal.
Cette conception est particulièrement adaptée aux situations dans lesquelles l'utilisateur est en déplacement et doit conserver son attention sur son environnement.
---
## 2.2. Traitement local des commandes
La reconnaissance vocale repose sur la Web Speech API.
Après reconnaissance, la commande est analysée par une grammaire française déterministe développée spécifiquement pour les fonctionnalités de l'application.
Cette architecture présente un avantage majeur : les commandes fonctionnelles ne nécessitent pas systématiquement de transmettre la demande à un serveur ou à un modèle d'intelligence artificielle.
Une partie importante des interactions peut ainsi être exécutée localement dans le navigateur, ce qui améliore la réactivité et permet au système de conserver ses fonctions essentielles dans des conditions de connectivité limitée.
La réponse de l'application est ensuite restituée à l'utilisateur par synthèse vocale.
---
# 3. Commandes et services accessibles par la voix
Le système vocal couvre sept catégories principales de commandes.
### Navigation
L'utilisateur peut demander à rejoindre un emplacement, par exemple :
> « Va à la cafétéria. »
Le système détermine alors l'itinéraire approprié à partir de la représentation cartographique de l'espace.
### Localisation et environnement
L'utilisateur peut demander sa position ou obtenir une description des éléments présents autour de lui.
Exemples :
> « Où suis-je ? »
> « Qu'est-ce qui m'entoure ? »
### Sites et espaces numériques
Le système permet également d'accéder aux différents sites ou espaces numériques associés aux exposants et aux événements.
Exemple :
> « Ouvre le métavers de Mobo. »
### Webthèque
La voix permet d'effectuer des recherches et d'accéder aux ressources disponibles dans la webthèque, notamment pour consulter ou télécharger des documents.
### Assistant intelligent
L'utilisateur peut interroger le système concernant son fonctionnement et le moteur d'intelligence artificielle éventuellement configuré.
### Paramètres
Les paramètres vocaux peuvent être modifiés directement par commande, notamment la vitesse de parole et la fréquence des rappels de distance.
Exemples :
> « Parle plus vite. »
> « Règle la vitesse à 5. »
> « Rappel toutes les 5 secondes. »
### Commandes immédiates
Des commandes de contrôle permettent notamment d'arrêter une annonce, de demander une répétition ou d'obtenir de l'aide.
---
# 4. Système de guidage vocal
Le guidage constitue l'une des fonctionnalités centrales de la solution.
Il est organisé autour de quatre étapes.
## 4.1. Annonce initiale
Lorsqu'une destination est sélectionnée, le système communique simultanément :
* la destination ;
* la distance ;
* la durée estimée ;
* la vitesse de déplacement de référence.
Par exemple :
> « Vous vous déplacez vers le stand Mobo. 85 mètres, environ 1 minute, à 4,3 kilomètres par heure. »
Cette présentation permet au visiteur de disposer immédiatement d'une estimation plus complète de son déplacement.
## 4.2. Suivi pendant le déplacement
Pendant le déplacement, l'application annonce régulièrement la distance restante.
La fréquence est configurée à 2 secondes par défaut et peut être ajustée entre 1 et 30 secondes.
Afin d'éviter les répétitions inutiles, une nouvelle annonce n'est produite que lorsque la valeur arrondie de la distance restante évolue.
## 4.3. Arrivée à destination
À l'arrivée, le système identifie le lieu et présente les informations pertinentes.
Selon le contexte, il peut notamment communiquer :
* le nom du stand ;
* l'identité de l'exposant ;
* son état d'ouverture ou de fermeture ;
* les interactions disponibles ;
* les informations complémentaires associées au lieu.
## 4.4. Interaction après l'arrivée
Une fois arrivé, le système demande à l'utilisateur :
> « Que voulez-vous faire ? »
Cette approche permet d'éviter de présumer l'action suivante et redonne le contrôle à l'utilisateur.
---
# 5. Principes d'ergonomie et d'accessibilité
Le système applique plusieurs règles destinées à garantir une expérience cohérente et accessible.
La parole de guidage ne doit pas être interrompue par un événement visuel ou une mise à jour réseau.
Par ailleurs, aucune conversation libre n'est proposée pendant le déplacement. Cette décision répond à un objectif fonctionnel : les annonces vocales doivent rester clairement audibles et constituer une véritable balise de navigation.
L'interaction conversationnelle intervient principalement à l'arrivée.
L'ensemble des annonces vocales est également associé à une région live, permettant leur restitution par les technologies d'assistance et notamment les lecteurs d'écran.
Enfin, les commandes vocales peuvent être reproduites au moyen d'un champ clavier. La voix constitue donc une modalité d'interaction privilégiée, mais ne représente jamais l'unique moyen d'accès aux fonctionnalités.
---
# 6. Interface visiteur
L'interface visiteur est organisée autour de huit espaces fonctionnels :
1. Guide
2. Sites
3. Webthèque
4. Assistant
5. Historique
6. Présence
7. WebMCP
8. Aide
L'interface s'adapte aux différents formats d'écran.
Sur mobile, le menu est présenté sous la forme d'un tiroir inférieur.
Sur les écrans plus larges, il est présenté sous la forme d'une colonne latérale repliable.
La navigation au clavier est prise en charge et la gestion du focus empêche celui-ci de rester positionné sur un élément qui n'est plus visible.
---
# 7. Back-office destiné aux organisateurs
Le back-office constitue l'espace de pilotage de la solution.
Il est organisé autour de six sections principales.
## 7.1. Tableau de bord
Le tableau de bord permet de suivre notamment :
* la présence des visiteurs ;
* l'historique des visites ;
* les sessions actives ;
* l'activité en temps réel.
## 7.2. Éditeur de carte
L'éditeur permet de construire et de modifier la représentation numérique de l'espace.
L'administrateur peut notamment :
* ajouter des nœuds ;
* relier des nœuds ;
* importer un plan ;
* modifier les libellés ;
* effectuer certaines corrections à l'aide de commandes vocales.
Les connexions entre les nœuds constituent les chemins utilisables par le système de navigation.
## 7.3. Gestion des exposants
Cette section permet de gérer les informations relatives aux exposants présents sur l'événement.
## 7.4. Gestion des stands
Elle permet de gérer les emplacements physiques et les informations associées à chaque stand.
## 7.5. Gestion des points d'intérêt
Les POI regroupent les principaux points d'intérêt du site, notamment :
* entrées ;
* sorties ;
* cafétéria ;
* sanitaires ;
* accueil ;
* autres emplacements stratégiques.
## 7.6. Webthèque
La webthèque centralise les ressources numériques destinées aux visiteurs.
Elle permet notamment de référencer, rechercher, ouvrir et télécharger les ressources disponibles.
---
# 8. Architecture de publication en temps réel
L'architecture distingue clairement les opérations de modification et la diffusion des changements.
Lorsqu'un organisateur modifie une donnée, celle-ci est enregistrée via l'**API REST**.
Le serveur génère ensuite une modification différentielle, ou delta JSON, qui est transmise aux clients connectés via WebSocket.
L'application visiteur applique automatiquement cette modification sans nécessiter de rechargement de la page.
Une modification de carte, d'exposant, de stand ou d'information peut ainsi être répercutée presque immédiatement auprès des visiteurs déjà connectés.
Cette architecture garantit une cohérence dynamique entre le système d'administration et les interfaces visiteurs.
---
# 9. Architecture technique
## 9.1. Interface utilisateur
L'interface est développée à partir des technologies Web natives :
* HTML ;
* CSS ;
* JavaScript ;
* modules ES.
Aucune chaîne de compilation n'est nécessaire pour exécuter la solution.
Ce choix réduit la complexité de déploiement et facilite la maintenance sur site.
Le code livré correspond directement au code exécuté par le navigateur.
## 9.2. Serveur
Le serveur repose sur Node.js.
L'architecture utilise notamment la bibliothèque `ws` pour assurer les communications WebSocket.
Le même processus peut assurer :
* le service des fichiers statiques ;
* l'API ;
* les communications temps réel.
Le serveur fonctionne notamment sur le port 8787.
Cette architecture permet de disposer d'une infrastructure compacte et facilement déployable sur un environnement local.
---
# 10. API REST et communications WebSocket
Les deux technologies répondent à des besoins différents.
L'API REST est utilisée pour les opérations de gestion des données : création, consultation, modification et suppression.
WebSocket est utilisé pour la diffusion des changements en temps réel.
Cette séparation permet de conserver une architecture claire tout en offrant une expérience dynamique côté visiteur.
---
# 11. Authentification et sécurité
L'authentification repose sur des jetons signés avec HMAC-SHA256.
Le format utilisé est :
`charge.signature`
Cette approche évite de dépendre d'un système classique de sessions persistantes côté serveur.
Les opérations sensibles peuvent être protégées par le rôle `admin`, notamment les opérations liées à la purge des sessions.
La solution applique également une politique stricte de validation des URL.
La fonction `safeUrl()` contrôle les adresses susceptibles d'être ouvertes par l'application.
En dehors du réseau local, l'utilisation de HTTPS est exigée.
Les protocoles `javascript:`, `data:` et `file:` sont explicitement refusés.
Ces mesures contribuent à réduire les risques liés à l'exécution de contenus ou d'adresses malveillants.
---
# 12. Système de cartographie et de navigation
La cartographie repose sur une structure de graphe composée de nœuds et d'arêtes.
Chaque nœud représente un emplacement ou un point d'intérêt.
Chaque arête représente une liaison praticable entre deux emplacements.
Le système utilise une recherche plein texte pour identifier les destinations et l'algorithme A pour déterminer les itinéraires.
Cette approche permet de considérer l'itinéraire comme un problème de recherche de chemin dans un réseau plutôt que comme une simple succession de coordonnées.
Elle est particulièrement adaptée aux environnements intérieurs, aux salons, aux foires, aux centres d'exposition et aux espaces événementiels.
---
# 13. Gestion des distances et de l'échelle
La représentation interne de la carte utilise une échelle commune définie par :
`UNITS_PER_M = 4`
Les fonctions `toMetres` et `toUnits` permettent de convertir les unités internes en mètres et inversement.
Cette normalisation garantit que la distance calculée par le système de navigation correspond à la distance annoncée vocalement au visiteur.
Elle permet également de conserver une cohérence entre la cartographie, la recherche d'itinéraire et le guidage vocal.
---
# 14. WebMCP : catalogue central des actions
La solution intègre 11 outils WebMCP regroupés dans `window.CercleMCP`.
Ces outils sont :
* `search_stand`
* `locate`
* `list_exhibitors`
* `describe_around`
* `contact_exhibitor`
* `list_sites`
* `open_website`
* `search_webtheque`
* `open_webtheque`
* `download_webtheque`
* `list_downloaded`
Ce catalogue constitue une source unique de vérité pour les actions disponibles dans la plateforme.
Une fonctionnalité développée sous forme d'outil peut ainsi être réutilisée par l'interface utilisateur et par le système d'intelligence artificielle.
Cette approche limite les divergences entre les capacités réellement disponibles dans l'application et celles exposées à l'assistant intelligent.
---
# 15. Architecture d'intelligence artificielle
La solution prend en charge trois modes d'intelligence artificielle.
Le premier, `none`, désactive le moteur d'IA et constitue le mode par défaut.
Le deuxième, `edge`, permet d'utiliser un moteur exécuté localement, notamment avec des solutions telles qu'Ollama ou llama.cpp.
Le troisième, `remote`, permet de connecter un moteur distant.
Cette architecture offre plusieurs niveaux de déploiement selon les contraintes techniques, de confidentialité et de connectivité de l'organisation.
Le fonctionnement de base de la plateforme ne dépend cependant pas de l'intelligence artificielle.
L'IA intervient principalement comme couche complémentaire destinée à améliorer la compréhension des demandes et la formulation des réponses.
Le catalogue WebMCP est automatiquement converti en schéma d'appel de fonctions lorsque le moteur d'IA est activé.
Il n'est donc pas nécessaire de maintenir séparément une liste des fonctions disponibles pour l'application et une autre pour le modèle.
---
# 16. Fonctionnement hors ligne
La solution intègre un mécanisme de fonctionnement hors ligne reposant notamment sur un Service Worker.
La gestion du cache distingue le shell de l'application et les ressources de la webthèque.
Cette séparation garantit qu'une mise à jour de l'application ne provoque pas automatiquement la suppression des ressources déjà téléchargées par les visiteurs.
Le système peut ainsi conserver un niveau de service important même lorsque la connectivité Internet est limitée ou momentanément indisponible.
---
# 17. Assurance qualité et validation
La solution a fait l'objet de 593 vérifications, comprenant :
* 467 vérifications automatisées côté Node.js ;
* 126 vérifications visuelles.
Le dispositif de validation comprend également des tests réalisés avec un navigateur réel afin de vérifier le comportement de l'interface et les éléments effectivement restitués vocalement.
Cette démarche permet de contrôler simultanément :
* la logique applicative ;
* les interactions utilisateur ;
* l'affichage ;
* les fonctionnalités vocales ;
* les comportements du navigateur ;
* certains aspects d'accessibilité.
---
# 18. Synthèse fonctionnelle et technologique
La solution constitue une plateforme numérique intégrée associant guidage vocal, cartographie interactive, gestion événementielle, administration centralisée, webthèque, communication temps réel, fonctionnement hors ligne et intelligence artificielle optionnelle.
Son architecture repose sur des technologies Web standards et légères afin de faciliter le déploiement, la maintenance et l'exploitation sur site.
Le choix d'une architecture dans laquelle l'intelligence artificielle demeure optionnelle constitue un élément important de la conception. Les fonctionnalités fondamentales — navigation, localisation, recherche, gestion des contenus et interactions principales — restent accessibles sans dépendre d'un modèle d'IA distant.
Le système WebMCP joue par ailleurs le rôle de catalogue central des actions disponibles. Les mêmes capacités peuvent ainsi être exploitées par l'interface, par les visiteurs et, lorsque cela est nécessaire, par un moteur d'intelligence artificielle.
Enfin, l'utilisation conjointe de REST et de WebSocket permet de distinguer clairement la gestion des données de leur diffusion en temps réel. Les modifications effectuées par les organisateurs peuvent ainsi être propagées rapidement aux visiteurs sans rechargement de l'application.
L'ensemble forme une architecture modulaire, légère, évolutive et adaptée aux environnements événementiels, avec une attention particulière portée à l'accessibilité, à l'autonomie, à la sécurité, à la simplicité d'exploitation et à la continuité de service.
Cette version peut servir directement de section “Présentation technique de la solution” dans un dossier institutionnel. Je peux aussi la transformer en version “cahier des charges professionnel”, avec Objectifs → Fonctionnalités → Architecture → Exigences techniques → Sécurité → Accessibilité → Critères de validation → Livrables.
