Kelra Room,
de A à Z.

01 Présentation

Kelra Room est une couche logicielle qui transforme n'importe quelle dalle tactile de salle de réunion — module Windows OPS, Huawei IdeaHub, écran de constructeur générique — en un poste de salle unifié : planning, jointure de visioconférence en un geste, et tableau blanc collaboratif.

Le produit répond à un problème simple : un parc de salles n'est jamais homogène. Des écrans achetés à des années d'écart, des marques différentes, des télécommandes différentes. Chaque réunion commence par cinq minutes de dépannage. Kelra Room impose la même interface, les mêmes gestes et la même visio sur tout le parc, quel que soit le matériel dessous.

Ce qui compose une installation

Les principes de conception

Ce que Kelra Room ne fait pas

Pour cadrer une évaluation, autant être direct sur les limites de périmètre :

• Kelra Room ne remplace pas votre solution de visioconférence. Il détecte le lien Teams, Meet ou Zoom de l'invitation et l'ouvre en plein écran — la réunion reste chez son éditeur.
• Il ne pilote pas le matériel audio/vidéo de la salle (caméra, barre de son, contrôle de la dalle). Ceux-ci restent gérés par leurs pilotes Windows habituels.
• Il ne mesure pas la durée réelle des appels : les statistiques reposent sur les créneaux planifiés au calendrier (voir Exploitation).
• La console d'administration multi-sites hébergée est une option commerciale distincte ; un déploiement standard administre chaque serveur individuellement.

02 Fonctionnalités

Le cycle complet d'une réunion, de l'affichage du planning au compte-rendu envoyé aux participants.

Écran de salle

L'écran affiche en permanence l'heure, le nom de la salle, son statut et le planning du jour. Le statut est lisible depuis le couloir : vert quand la salle est libre, rouge quand elle est occupée, avec l'heure de libération ou le prochain créneau.

Rejoindre une visioconférence

Kelra Room analyse l'invitation de réunion et en extrait le lien de visio, quel que soit le format — corps HTML Exchange, description Google, lien collé à la main. Un bouton géant « Rejoindre la visio » apparaît dès qu'une réunion démarre.

Plateformes reconnues

Microsoft Teams · Zoom · Google Meet · Cisco Webex · Whereby · Jitsi Meet · Proton Meet · BlueJeans · GoTo Meeting · RingCentral · Livestorm.

La visio s'ouvre dans un vrai navigateur

Quand un participant appuie sur « Rejoindre », l'application lance Microsoft Edge en plein écran, dans un profil dédié et isolé. C'est un choix imposé par les plateformes elles-mêmes : Google et Microsoft refusent la participation depuis un navigateur embarqué dans une application. Edge est présent d'origine sur Windows — rien à installer.

Pendant l'appel, une barre flottante reste au-dessus de toutes les fenêtres, déplaçable, traduite dans la langue de l'écran. Elle porte deux actions volontairement distinctes :

• « Retour au kiosque » — ramène l'écran de salle devant sans toucher à la réunion, qui continue derrière, audio et caméra compris. C'est ce qui permet d'ouvrir le tableau blanc en séance puis de revenir à l'appel : le bouton devient alors « Retour à la visio ».
• « Quitter la visio » — termine réellement la réunion et revient à l'écran de salle. Couleur et zone différentes : c'est la seule des deux qui coupe l'appel.

Fermer la fenêtre soi-même déclenche le même nettoyage : aucune fenêtre ni processus ne s'accumule d'une réunion à l'autre.

Deux modes d'identité en réunion

Le mode se règle par salle dans la console. La connexion du compte de salle se fait une seule fois, à l'installation, depuis l'écran lui-même ; la session est conservée dans le profil de visio.

Réunion instantanée

Un appui crée à la volée une réunion Teams ou Google Meet dans le calendrier de la salle, réserve la salle pour une heure et ouvre l'appel. Disponible uniquement en mode « compte de salle » : un participant anonyme n'aurait ni annuaire ni possibilité d'inviter, et la salle risquerait de rester dans son propre hall d'attente.

Tableau blanc collaboratif

Un tableau blanc plein écran, partagé en temps réel, ouvert depuis l'écran de salle en un geste. Moteur Excalidraw, relais de scène hébergé sur votre serveur.

Broker multi-tenant — arbitrage des réservations

Cas d'usage : un bâtiment partagé par deux organisations, l'une sur Microsoft 365, l'autre sur Google Workspace. Les deux veulent réserver la même salle physique, chacune depuis son propre calendrier de ressource. Sans arbitrage, les deux acceptent — et deux réunions se présentent à la même heure.

Le broker de Kelra Room agrège les calendriers de toutes les organisations reliées à une salle et arbitre les invitations en attente :

• Premier arrivé, premier servi — les invitations sont traitées dans l'ordre de réception.
• Créneau libre sur l'ensemble des calendriers → l'invitation est acceptée, l'organisateur reçoit la confirmation habituelle.
• Conflit avec une réservation déjà acceptée, y compris sur l'autre organisation → l'invitation est refusée avec un motif, visible par l'organisateur dans la réponse.

Miroirs d'occupation

Un refus arrive après coup : jusque-là, le Room Finder d'Outlook et le sélecteur de salles Google annoncent la salle libre — ils ne lisent que leur propre calendrier. Dès qu'une réservation est acceptée, Kelra Room pose donc sur les autres calendriers de la salle un événement d'occupation neutre, intitulé « Réservé — autre organisation ». La salle apparaît occupée dans l'outil que l'utilisateur consulte réellement, avant toute tentative.

• Le sujet et l'organisateur ne franchissent jamais la frontière entre organisations. Le miroir ne porte qu'un titre neutre, que vous choisissez.
• Les miroirs sont réconciliés à chaque passe : réservation déplacée → miroir déplacé ; annulée → miroir supprimé.
• Ils n'apparaissent pas sur l'écran de salle, qui montre déjà la réunion d'origine, mais sont visibles et étiquetés dans la console.
• Le mécanisme est désactivable ; l'arbitrage, lui, continue de refuser les conflits.

Console d'administration

Une interface web servie par le serveur, accessible depuis n'importe quel poste du réseau autorisé. Neuf onglets :

Langue de la console : français et anglais. L'écran de salle en parle huit — il est vu par vos visiteurs, la console ne l'est que par vos équipes informatiques.

03 Architecture

Un serveur central, un écran par salle, et les appareils des participants qui rejoignent le tableau blanc. Rien d'autre.

Le serveur

Un service unique, livré sous forme de conteneur, qui rassemble quatre rôles :

Toutes les données persistantes — salles, écrans, organisations, licence, réservations arbitrées, logos — tiennent dans un seul volume : une base de données embarquée et un dossier de fichiers. Il n'y a pas de serveur de base de données externe à installer, à sauvegarder ou à mettre à jour.

L'écran de salle

Un exécutable Windows unique, qui embarque tout ce dont il a besoin. Il s'installe pour la machine entière — nécessaire, puisqu'en mode kiosque Windows l'écran tourne sous un compte dédié, distinct de celui du technicien qui installe. Trois emplacements sur la machine, qui survivent à une désinstallation : l'adresse du serveur, la bibliothèque de fonds d'écran, et la clé d'identification de l'écran. Une mise à jour n'oblige donc jamais à reprovisionner la salle.

Authentification, en résumé

04 Prérequis

Ce qu'il faut avoir en place avant l'installation, côté serveur, côté écran et côté réseau.

Serveur

Écran de salle

Calendriers

• Une boîte de ressource (compte de salle) par salle physique, dans Microsoft 365 et/ou Google Workspace — celle que vos collaborateurs réservent déjà.
• Pour Microsoft : une inscription d'application dans votre annuaire, avec consentement administrateur. Pour Google : un projet Cloud avec l'API Calendar activée.
• Pour la réunion instantanée : une licence incluant Teams sur la boîte de la salle (Teams Rooms Basic, gratuite jusqu'à 25 salles, suffit) ou l'API Google Meet activée.

Réseau

La matrice complète, flux par flux, figure au chapitre 6.

05 Dimensionnement du serveur

Quatre paliers, du site pilote au parc de 500 écrans. Le dimensionnement est volontairement confortable : l'empreinte réelle est plus légère.

Palier 1 — jusqu'à 50 écrans

Déploiement pilote, bureau unique.

Charge estimée : ~1 requête/s, 50 connexions temps réel actives. Un VPS d'entrée de gamme ou un mini-PC en local convient parfaitement.

Palier 2 — 50 à 150 écrans

Site unique ou multi-sites modeste.

Charge estimée : 3 à 5 requêtes/s, 150 connexions temps réel, arbitrage du broker toutes les 60 s. Un VPS standard est idéal.

Palier 3 — 150 à 300 écrans

Campus ou multi-sites actifs.

Charge estimée : 5 à 10 requêtes/s, 300 connexions temps réel, broker sur plusieurs organisations. Serveur dédié ou VPS « CPU optimisé » recommandé, avec sauvegarde quotidienne automatisée.

Palier 4 — 300 à 500 écrans

Charge estimée à 450 écrans : ~15 requêtes/s en continu, 450 connexions temps réel permanentes, broker sur potentiellement des dizaines de salles multi-organisations. La RAM est le facteur dimensionnant principal.

Recommandations supplémentaires à ce palier :

• Serveur dédié (bare metal ou instance cloud compute-optimisée) plutôt qu'un VPS partagé.
• Sauvegarde quotidienne automatisée hors-site — un seul volume contient l'intégralité de l'état.
• Supervision de disponibilité sur le point de contrôle /health.
• TLS obligatoire.
• Onduleur ou redémarrage automatique du service (déjà configuré par défaut).

Récapitulatif

06 Matrice de flux réseau

Tous les flux, source par destination, à remettre telle quelle à votre équipe réseau ou sécurité.

1 · Écrans → Serveur (réseau interne)

2 · Poste d'administration → Serveur (réseau interne)

3 · Provisionnement & tableau blanc (réseau interne)

4 · Serveur → Fournisseurs de calendrier (sortant Internet)

4 bis · Quand cette sortie passe par un proxy

Sur un réseau fermé, les flux ci-dessus ne partent pas en direct : ils traversent un proxy d'entreprise, parfois doublé d'une inspection TLS. Deux points décident du succès de l'installation, et aucun des deux ne se devine.

Le proxy se déclare dans le bloc environment: du service server — et non dans le seul fichier .env, dont le contenu n'atteint pas le conteneur :

environment:
  HTTPS_PROXY: http://proxy.entreprise.local:8080
  HTTP_PROXY: http://proxy.entreprise.local:8080
  NO_PROXY: localhost,127.0.0.1,10.0.0.0/8

Derrière une inspection TLS (Zscaler, Netskope, Fortinet…), l'équipement présente un certificat signé par une autorité interne. Il faut la donner au serveur — monter le fichier, puis pointer son chemin dans le conteneur :

volumes:
  - /etc/ssl/certs/ca-entreprise.crt:/app/ca-entreprise.crt:ro
environment:
  NODE_EXTRA_CA_CERTS: /app/ca-entreprise.crt

Désactiver la vérification des certificats à la place reviendrait à ouvrir le trafic — jetons de calendrier compris — à quiconque se trouve sur le trajet. Kelra Room ne propose pas ce réglage.

5 · Serveur → Relais SMTP (sortant)

6 · Écrans → Plateformes de visioconférence (sortant Internet)

Ces flux partent du réseau de l'écran de salle, via le navigateur, et jamais du serveur.

Résumé des règles de pare-feu

07 Installation

Compter une demi-journée pour le serveur et la première salle, puis une dizaine de minutes par salle supplémentaire.

Serveur

Le serveur est livré sous forme de bundle de déploiement contenant l'image du service et son fichier d'orchestration. La mise en service tient en trois temps :

1. Déposer le bundle sur la machine Linux et renseigner le fichier de configuration .env — au minimum un secret d'administration long et aléatoire.
2. Démarrer le service. Il se relance automatiquement au redémarrage de la machine. Démarrage

   docker compose up server -d

3. Vérifier. L'API répond sur http://<IP_SERVEUR>:4001, la console sur http://<IP_SERVEUR>:4001/admin. Le point /health renvoie la version exacte déployée.

Chiffrement des échanges (TLS)

Le serveur sait servir la console et l'API en https sans composant supplémentaire. Trois modes, choisis dans le fichier .env :

L'autorité locale, en pratique

TLS_NAMES énumère les noms et adresses sous lesquels le serveur sera joint — par exemple 192.168.1.10,salles.interne,localhost. Ils sont inscrits dans le certificat : une adresse absente de cette liste sera refusée par le navigateur. L'autorité créée reste stable, et survit au renouvellement du certificat serveur : les écrans déjà déployés n'ont rien à refaire.

• Postes d'administration — l'autorité se télécharge sur /tls/ca.crt et s'installe une fois dans le magasin de certificats du poste ou du domaine. La console est ensuite servie sans avertissement.
• Écrans de salle — l'application Windows récupère l'autorité au premier contact avec le serveur et l'épingle. Elle refuse ensuite toute autorité différente : un serveur substitué en cours de route est rejeté, pas accepté en silence. L'empreinte est affichée au démarrage du serveur et journalisée par l'application au moment de l'épinglage — les comparer une fois vaut vérification.

Si l'adresse du kiosque est restée en http

C'est l'oubli le plus courant après une bascule. Une adresse restée en http:// face à un serveur qui écoute en HTTPS rendait l'écran inutilisable sans qu'aucun message ne désigne la cause : le lien du QR code aboutissait sur un 404 — souvent celui du proxy d'entreprise, qui semblait donc accuser l'application — et le compte à rebours de l'écran continuait de tourner pendant que la console répondait « Lien expiré ».

Trois garde-fous rattrapent l'oubli. Ils ne le remplacent pas.

• Le kiosque corrige l'adresse tout seul. Il interroge le serveur au démarrage, puis à nouveau depuis le navigateur de l'écran, et emploie le schéma réellement servi. La correction vaut pour la session en cours et n'est pas enregistrée.
• L'écran l'affiche, et le journal le répète. Un bandeau annonce la correction ; docker compose logs kiosk donne l'adresse configurée, celle employée, et la variable à corriger. Corriger OPENROOM_SERVER_URL reste nécessaire — sinon le décalage revient au prochain déploiement.
• Le serveur nomme la panne. Une requête en clair sur un port HTTPS n'aboutit à aucune réponse : le handshake échoue avant que l'application existe, et aucune redirection ne peut être renvoyée. docker compose logs server porte désormais une ligne [tls] ⚠ une requête en CLAIR est arrivée sur ce port.

Derrière un reverse proxy qui termine le TLS (Caddy, Traefik, Tailscale), le serveur écoute en clair alors que ses clients parlent en HTTPS. Il suit alors l'en-tête x-forwarded-proto, que ces proxys posent par défaut, et annonce bien https://. L'en-tête n'est consulté que lorsque le serveur n'assure pas lui-même le chiffrement : aucune requête forgée ne peut faire annoncer une URL en clair par un serveur chiffré.

Les autres voies

Écran de salle

Un installeur Windows unique, fourni par Kelra. Il embarque l'application, son service et son moteur d'exécution : rien d'autre à installer sur la machine, aucune couche de virtualisation.

Ce que fait l'installeur

• Installation par machine, dans Program Files — une élévation est demandée une fois. C'est nécessaire : en mode kiosque, l'écran tourne sous un compte dédié, distinct de celui du technicien.
• Au premier lancement, l'application inscrit son démarrage à l'ouverture de session. Neutralisable si vous pilotez le lancement par une stratégie Windows.
• L'application est déjà en plein écran, sans barre d'adresse ni onglets.

Premier lancement

1. Renseigner l'adresse du serveur sur l'écran de premier lancement, au doigt. Un bouton « Tester la connexion » valide l'adresse ; l'enregistrement n'est possible qu'après un test réussi, et une seule fois — un enregistrement modifiable à tout moment permettrait à n'importe quel poste du réseau de rediriger l'écran vers un serveur qu'il contrôle.
2. Provisionner l'écran : il affiche alors un QR code, valable 5 minutes et renouvelé automatiquement. Le scanner avec un téléphone (ou ouvrir l'URL affichée dessous depuis un poste ayant accès au serveur), choisir la salle dans la liste, valider. L'écran se configure seul dans les secondes qui suivent.
3. Régler l'horloge et le fuseau horaire de la machine — voir l'encadré ci-dessous.

Verrouiller Windows par-dessus

L'application est déjà verrouillée en plein écran. Le mode kiosque de Windows n'ajoute que trois choses : empêcher l'évasion vers le bureau, relancer l'application si elle se ferme, et interdire les autres programmes.

Supprimer les sollicitations du navigateur

À faire une fois par machine. Un écran de salle ne doit rien demander : on appuie sur « Rejoindre » et on est dans la réunion. L'application prépare déjà le profil de visio à chaque lancement — traduction désactivée, notifications et géolocalisation bloquées, caméra et micro accordés d'office aux plateformes connues, bannières de premier lancement écartées.

Reste une boîte de dialogue que seule une stratégie d'entreprise peut supprimer : « Ce site tente d'ouvrir Microsoft Teams ». La page web de Teams cherche à lancer l'application lourde, qui n'a pas à être installée sur un écran de salle. Une stratégie Edge bloquant les protocoles msteams:, msteams-enterprise:, zoommtg: et zoomus: l'élimine sans rien afficher — la procédure exacte est fournie avec le produit.

Ce qui subsiste : Teams affiche sa propre page « Comment voulez-vous rejoindre votre réunion ? » avec un bouton « Continuer sur ce navigateur ». Ce n'est pas une boîte de dialogue du navigateur mais le contenu de la page Microsoft — aucune stratégie ne l'atteint. Un clic reste donc nécessaire sur les réunions Teams. Des paramètres d'URL circulent pour la contourner, mais ils ne sont pas documentés par Microsoft : les câbler en dur ferait dépendre l'ouverture des réunions, sur tout un parc, d'un comportement modifiable sans préavis.

Adresses utilisées par les QR codes

Les URL partagées (QR du tableau blanc, QR de provisionnement) ne doivent jamais contenir localhost. L'écran détecte automatiquement son adresse locale, en écartant les cartes virtuelles. Si la détection choisit la mauvaise interface, l'adresse peut être forcée par configuration. Pensez à autoriser les ports concernés dans le pare-feu Windows, sinon les participants qui scannent le QR n'atteindront pas le tableau.

08 Configuration

Tout se règle depuis la console d'administration, sauf les prérequis à créer chez Microsoft et Google.

Console et comptes

La console s'ouvre sur http://<IP_SERVEUR>:4001/admin.

1. Première connexion — le serveur crée au premier démarrage un compte admin / admin. Un changement de mot de passe est imposé immédiatement, et tant qu'il n'est pas fait l'API entière refuse de répondre. Un couple d'identifiants par défaut connu est ce que les robots tentent en premier ; le verrou existe pour qu'un déploiement oublié ne reste pas ouvert.
2. Comptes nominatifs — onglet Comptes : un compte par administrateur. Tous ont un accès complet ; pour cloisonner plusieurs entités, déployez une instance par entité plutôt que de partager celle-ci.
3. Connecter une organisation — onglet Organisations : Microsoft 365 et/ou Google Workspace (sections suivantes).
4. Créer les salles — onglet Salles : nom, description, adresse du calendrier de ressource (par ex. salle-a@monentreprise.com), organisation, thème, logo.
5. Provisionner les écrans — par QR code depuis chaque écran, ou en créant l'appareil à la main dans l'onglet Appareils.

Connecter Google Workspace

Côté Google Cloud

1. Créer un projet (ou en réutiliser un) sur la console Google Cloud.
2. Activer l'API Google Calendar. Pour la réunion instantanée, activer également l'API Google Meet.
3. Créer des identifiants OAuth 2.0 de type « Application Web » et noter l'identifiant client et le secret client.
4. Obtenir un jeton de rafraîchissement avec le compte ayant accès aux calendriers de ressource. Les portées nécessaires : lecture du calendrier, et création d'espaces Meet si la réunion instantanée est souhaitée. Pour l'arbitrage multi-organisations, la portée d'écriture complète du calendrier est requise.

Côté Kelra Room

Onglet Organisations → Nouvelle organisation :

« Vérifier et enregistrer » teste réellement les identifiants avant de les accepter. Le jeton de rafraîchissement reste valable tant que l'accès n'est pas révoqué ; le jeton d'accès est renouvelé automatiquement.

Connecter Microsoft 365

Côté Azure / Entra ID

1. Inscrire une application — Inscriptions d'applications → Nouvelle inscription. Comptes dans cet annuaire organisationnel uniquement ; aucune URI de redirection. Noter l'ID de locataire et l'ID d'application.
2. Choisir le moyen d'authentification — deux options, pour un fonctionnement identique. Secret client : Certificats et secrets → durée 24 mois → copier la valeur (et non l'identifiant) du secret. Certificat : charger un certificat public dans l'onglet Certificats de la même page. Le certificat est recommandé, et devient indispensable si votre politique interne interdit les secrets clients.
3. Accorder la permission Calendars.ReadWrite de type Application sur Microsoft Graph, puis cliquer Accorder le consentement administrateur. Une seule permission couvre l'affichage du planning, la réunion instantanée et l'arbitrage. La permission en lecture seule afficherait le calendrier mais ferait échouer la création de réunion.

Authentification par certificat — sans secret partagé

Beaucoup d'organisations interdisent les secrets clients par politique : un secret est une chaîne durable, recopiée dans un fichier de configuration, que rien ne distingue dans un journal d'audit. Avec un certificat, Kelra Room signe un jeton de courte durée avec une clé privée qui ne quitte jamais votre serveur ; seule la partie publique est déposée dans Entra.

Entra ne valide pas la chaîne de confiance d'un certificat d'authentification d'application : il enregistre la clé publique et retrouve le certificat par son empreinte. Un certificat auto-signé est donc un cas nominal, et un certificat délivré par votre PKI interne convient tout autant — avec l'avantage de votre gouvernance existante : inventaire, alertes d'expiration, révocation.

Sans PKI, l'utilitaire est embarqué dans l'image du serveur :

docker compose exec server node scripts/generer-certificat-entra.mjs kelra-room 2

Il produit un .cer — le certificat public, à charger dans Entra — et un .key, la clé privée, à renseigner dans la console d'administration et à ne transmettre à personne. L'empreinte affichée doit correspondre à celle qu'affiche le portail Azure après chargement.

Optionnel — accueillir les participants externes

Par défaut, Teams place les participants hors de votre annuaire en salle d'attente — or personne n'est connecté côté écran pour les admettre. Pour ouvrir automatiquement la salle d'attente sur les réunions instantanées, une permission supplémentaire (OnlineMeetings.ReadWrite.All) et une Application Access Policy Teams sont nécessaires. Sans cette configuration, la réunion instantanée fonctionne quand même : les participants internes entrent directement, seuls les externes doivent être admis.

Côté Kelra Room

Broker multi-organisations

Permissions

Relier une salle à ses organisations

1. Onglet Broker → Relier un calendrier : choisir la salle, l'organisation, et saisir l'adresse de la boîte de ressource dans cette organisation. Chaque organisation a la sienne pour la même salle physique.
2. Recommencer pour la seconde organisation. Tant qu'une salle n'a qu'un calendrier relié, le broker n'a rien à arbitrer et le signale.
3. Synchroniser force un relevé immédiat et rend compte des réservations vues, des décisions prises et des erreurs rencontrées.
4. Réservations déplie ce que le broker a vu et décidé pour cette salle : acceptée, refusée avec le motif et l'organisation concurrente, en attente, annulée.

Une salle n'accepte qu'une connexion par organisation, et un calendrier de ressource ne peut être relié qu'à une seule salle d'une même organisation — la console refuse explicitement les doublons, qui rendraient l'arbitrage contradictoire.

Réglages du broker

La synchronisation couvre une fenêtre allant de 1 jour en arrière à 60 jours en avant. Retirer une connexion nettoie ses miroirs avant de la supprimer.

Envoi d'emails et export PDF

Le téléchargement du PDF fonctionne sans configuration. L'envoi par email nécessite un relais SMTP, déclaré côté serveur :

Le SMTP sert à deux usages : l'envoi du compte-rendu PDF en fin de réunion, et l'envoi du lien du tableau blanc aux participants — utile pendant une visio, quand les participants distants ne peuvent pas scanner le QR affiché dans la salle.

Apparence des écrans

Les changements d'apparence sont appliqués au prochain chargement de l'écran.

09 Exploitation

Sauvegarde, mise à jour, supervision et statistiques d'usage.

Sauvegarde

Tout l'état du serveur tient dans un seul volume : la base de données (salles, écrans, organisations, licence, réservations arbitrées) et les logos téléversés. Sauvegarder ce volume suffit.

Ne s'y trouvent pas, et sont à sauvegarder séparément : le fichier de configuration .env (secrets des organisations, secret d'administration, SMTP) et votre bibliothèque de fonds d'écran.

La base n'utilise pas de journal d'écriture différée : une copie à froid, service arrêté quelques secondes, est propre et suffisante. Pour une sauvegarde quotidienne, planifiez-la en dehors des heures de réunion. Une copie à chaud fonctionne dans l'immense majorité des cas mais peut capturer une écriture en cours — acceptable comme filet de sécurité, à proscrire pour une migration.

Migration vers un autre serveur

Restaurer l'archive sur la nouvelle machine et y recopier la configuration suffit. La licence continue de fonctionner : elle est stockée en base et n'est liée à aucun matériel. L'ancre de la période d'évaluation est également préservée — restaurer une sauvegarde ne redonne pas 30 jours d'essai. Pensez à reporter la nouvelle adresse du serveur sur les écrans si elle change.

Mise à jour

Un script de mise à jour fourni récupère la nouvelle version, reconstruit l'image et redémarre le service. Il refuse de partir si un fichier influant sur le déploiement a été modifié localement, plutôt que de l'écraser en silence.

Côté écran, la mise à jour consiste à réinstaller l'exécutable fourni. Adresse du serveur, clé d'appareil et fonds d'écran survivent à la réinstallation : une mise à jour n'oblige jamais à reprovisionner une salle.

Savoir ce qui tourne

Version et empreinte de build sont visibles à cinq endroits : bannière de démarrage du serveur, point /health, barre latérale de la console (y compris avant connexion), panneau de diagnostic de l'écran — qui affiche les deux versions, la sienne et celle du serveur qu'il interroge — et journal de l'application Windows. Un écran à jour parlant à un serveur périmé se voit ainsi immédiatement.

Supervision

Le point de contrôle /health est public et sans authentification : il se branche directement sur votre supervision (Uptime Kuma, Grafana, Zabbix…). Il renvoie l'état du service, sa version et son empreinte de build.

Statistiques d'usage

Onglet Statistiques, sur 7, 30 ou 90 jours : réunions tenues, durée moyenne, participants en moyenne, heures occupées, répartition par jour, par salle et par plateforme de visioconférence.

Les chiffres portent sur ce déploiement. Un client multi-sites exploitant un serveur par site n'a pas de vue consolidée — c'est l'objet de la console d'administration hébergée, proposée en option.

10 Sécurité & données

Ce qui est stocké, où, et ce qui ne sort jamais de votre réseau.

Où vivent les données

Aucune télémétrie n'est émise vers Kelra. Un déploiement sans connexion Internet fonctionne, à ceci près qu'il ne peut évidemment pas lire de calendrier hébergé ni ouvrir de visioconférence.

Contrôles d'accès

• Écrans — clé d'appareil unique, obtenue par QR code, jamais inscrite dans un fichier de configuration ni dans le code servi au navigateur. Révocable instantanément depuis la console : l'écran repasse alors sur son écran de provisionnement.
• Administrateurs — comptes nominatifs, changement de mot de passe imposé au premier accès, journal d'audit attribué à chaque auteur.
• Participants au tableau blanc — accès par lien de session ; le relais de l'écran de salle ne transmet que les routes strictement nécessaires au tableau, et la console d'administration reste hors de portée du réseau des invités. Toute route refusée est journalisée.
• Écran de premier lancement — l'adresse du serveur ne peut être enregistrée qu'une fois, et seulement après un test de connexion réussi, pour qu'aucun poste du réseau ne puisse rediriger un écran vers un serveur qu'il contrôle.

Sur le franchissement des frontières entre organisations

Dans un déploiement multi-organisations, seule l'occupation d'un créneau traverse la frontière. Le sujet de la réunion, l'organisateur et la liste des participants ne sont jamais répliqués : le miroir posé sur l'autre calendrier ne porte qu'un titre neutre, que vous choisissez.

Composants tiers

Kelra Room intègre des composants open source, chacun conservant sa propre licence — notamment le moteur de tableau blanc Excalidraw, sous licence MIT. La liste exhaustive des composants et de leurs licences est fournie avec le produit et régénérée à chaque version.

11 Dépannage

Les symptômes les plus fréquents et leur cause réelle. Le panneau de diagnostic de l'écran répond à la plupart de ces questions sans quitter la salle.

12 Licences & tarifs

Une licence perpétuelle par écran, sans abonnement obligatoire. L'administration hébergée est une option, pas un péage.

Tarifs HT. Dégressif à partir de 20 écrans.

Fonctionnement de la licence

Licence du logiciel

Kelra Room est distribué sous Business Source License 1.1 — le même modèle que MariaDB, HashiCorp ou Sentry :

• Le code source est fourni, auditable et modifiable.
• L'usage non-production est libre : développement, test, démonstration, évaluation.
• L'usage en production requiert une licence commerciale, vendue par écran, au-delà d'une période d'évaluation de 30 jours par déploiement.
• Chaque version bascule automatiquement en Apache License 2.0 quatre ans après sa publication — un déploiement n'est jamais bloqué, quoi qu'il advienne de l'éditeur.

Le texte de la licence, fourni avec le produit, fait foi ; le résumé ci-dessus ne s'y substitue pas. Les composants tiers conservent leurs propres licences.

13 Support

Avant de nous écrire, trois éléments accélèrent nettement le diagnostic.

1. Le panneau de diagnostic de l'écran — une photo suffit. Il donne l'adresse IP, la passerelle, l'état du serveur, la sortie Internet, l'état de chaque calendrier, l'horloge, et les deux versions (écran et serveur).
2. La version exacte du serveur, lisible dans la barre latérale de la console ou sur le point /health — version, empreinte de build et date.
3. Ce qui a changé récemment : mise à jour, changement d'adresse de serveur, modification de permissions côté Microsoft ou Google, intervention réseau.