Robotique humanoïde.

ROBONEX est un intégrateur suisse de robotique humanoïde en contexte B2B. L'entreprise réunit choix du robot, logiciel, données d'entreprise, mise en service sécurisée, monitoring, service et support dans une solution contrôlée. L'accent n'est pas sur l'effet de vitrine mais sur des cas d'usage mesurables, des limites d'exploitation claires et l'intégration aux processus existants du client.

ROBONEX ne livre pas seulement du matériel: il planifie, intègre et exploite des solutions de robotique humanoïde. Cela comprend l'analyse de cas d'usage, le modèle de données, les adaptateurs système, le concept de sécurité, l'UI tablette, le monitoring, les processus de service et une escalade claire vers l'humain. Un robot n'est recommandé que lorsque site, utilité, données, équipe d'exploitation et risque concordent.

ROBONEX se positionne d'abord comme Swiss Humanoid Robotics Integrator pour entreprises et sites suisses. La phase initiale cible des environnements contrôlables — accueil, retail, événements, campus et showrooms — en Suisse. Des projets avec lien UE peuvent être examinés mais exigent des clarifications supplémentaires en matière de protection des données, de contrats et d'exploitation.

Le ROBONEX AI Reception Desk V1 est une solution d'accueil humanoïde stationnaire avec tablette séparée. Le robot est assis ou debout à un poste fixe approuvé, dialogue avec les visiteurs, utilise des sources de données vérifiées, n'effectue que des gestes autorisés et oriente l'attention vers l'écran. La tablette affiche détails, cartes, étapes de trajet, codes QR et autres informations confirmées.

L'AI Reception Desk doit être traité comme logiciel DEMO avec pilote physique en préparation. Le statut production suit la revue du site, l'approbation sécurité, la validation des données, les tests d'intégration, le processus d'exploitation, le modèle de support et des critères d'acceptation documentés. Les textes publics ne doivent pas prétendre que chaque module tourne déjà en production chez des clients.

Non. La version 1 est volontairement stationnaire et ne se déplace pas de façon autonome dans le bâtiment. Le robot travaille à un poste fixe délimité et n'indique au plus que le premier segment légal d'un trajet. L'orientation complète, y compris carte, étapes, code QR et options d'accessibilité, est fournie sur la tablette indépendante.

Le robot gère l'accueil personnel, la voix, les gestes confirmés et des indications directionnelles simples. La tablette gère l'affichage précis: résultats de recherche, cartes, étapes, codes QR, formulaires, états d'erreur et informations longues. Cette séparation est voulue pour que l'écran reste utile si la voix, la gestuelle ou la connexion robot sont limitées.

Le focus initial est de-CH et anglais; d'autres langues sont approuvées par pilote. Le site est déjà structuré pour de-CH, en-CH et fr-CH afin d'adresser proprement les publics suisses. Pour le robot, la traduction seule ne suffit pas: qualité des données, prononciation, terminologie, phrases de repli et validation client comptent.

Les faits opérationnels proviennent de bases de données approuvées ou d'API contrôlées. Le modèle de langage ne doit pas inventer prix, horaires, promotions, étages, trajets, disponibilités ou confirmations de réservation. La réponse finale est composée à partir de données validées; si des données manquent, le système le dit clairement et propose contact, information sur tablette ou transfert humain.

L'orientation repose sur un graphe de nœuds et liaisons autorisés, pas sur une ligne droite. Le système tient compte des étages, passages publics, ascenseurs, escaliers, trajets accessibles et fermetures temporaires. Le robot n'affiche que le premier segment directionnel légal tandis que la tablette fournit le trajet complet avec étapes et code QR.

Non. Le modèle de langage ne contrôle pas directement le robot physique. Il ne génère pas de positions articulaires, couples, vitesses ou commandes de mouvement libres. L'application interprète la demande, récupère les faits dans les sources de données et produit un discours validé, des ScreenCommand pour la tablette et au plus une RobotCommand autorisée depuis l'allowlist.

Le robot ne peut exécuter que des actions approuvées d'une allowlist fermée. Exemples: WELCOME, SHOW_TABLET, POINT_LEFT, POINT_RIGHT, POINT_FORWARD, CONFIRM, GOODBYE, REST et STOP. Angles libres, gestes non testés, mouvements simultanés ou commandes de mouvement générées par l'AI ne font pas partie du contrat public ou technique V1.

En cas d'erreur le système ne déclenche pas de nouveau mouvement. Erreur de modèle, API, données ou connexion mène à un repli sûr: REST ou STOP, message clair sur la tablette, alerte technique et transfert vers un accompagnement humain. Le robot ne doit jamais faire comme si une information manquante était confirmée.

Par défaut aucun enregistrement audio ou vidéo brut n'est stocké. La reconnaissance faciale n'est pas prévue pour le MVP; une caméra peut au plus fournir un indice de présence anonyme ou lire des codes QR si approuvé dans le concept de site. Les données de session anonymes sont conservées brièvement puis supprimées après départ ou timeout.

Avant un pilote nous examinons rôles privacy, devoirs d'information, minimisation, rétention, accès, séparation des mandants, validation du site, processus de sécurité et repli humain. Le DSG suisse s'applique pour les clients suisses; le GDPR peut s'ajouter avec un périmètre UE. Obligations CE, normes, arrêt d'urgence et approbations sécurité propres au site sont clarifiées avec des spécialistes par projet.

Non. Pinnex, RechNex et Prorum doivent être traités comme cibles d'adaptateur CONCEPT tant qu'il n'existe pas de contrats API documentés, mapping, revue privacy et tests d'intégration. Les textes publics ne doivent pas les présenter comme connectés en production. Seul un adaptateur ayant passé tests et réception peut obtenir un statut supérieur.

ROBONEX intègre les systèmes clients via des adaptateurs séparés et validés plutôt que via des réponses libres du modèle. Un adaptateur exige contrat API, authentification, mapping, comportement d'erreur, timeouts, règles de retry, logging, revue privacy, tests et réception traçable. Les actions d'écriture comme les réservations exigent aussi une confirmation utilisateur claire et une réponse contrôlée du système cible.

Oui, ROBONEX peut examiner achat, location, déploiement événementiel et Robot-as-a-Service comme modèles distincts. La forme adaptée dépend de l'objectif, de la durée, du site, du besoin de supervision, du périmètre d'intégration, du niveau de service et du risque. Une présence courte en salon, un pilote de plusieurs mois et un accueil permanent ne se chiffrent donc pas de la même façon.

Un projet démarre par un use-case workshop sur site ou à distance. Ensuite nous définissons site, public cible, sources de données, intégrations, limites de sécurité, KPI du pilote, supervision, support et critères d'acceptation. Le prix ne provient pas d'une liste publique mais du matériel, du périmètre logiciel, de l'intégration, de l'exploitation, du niveau de service et de la durée d'engagement.

ROBONEX convient d'abord à des environnements d'information, d'accueil et de conseil contrôlés. Cela inclut centres commerciaux, hôtels, événements, accueil corporate, campus, retail premium et showrooms lorsque site, données et sécurité conviennent. Le format séparé AI briefing ou finance presenter est CONCEPT: sources curatées, étiquetage clair, approbation humaine et pas de conseil en investissement.