OmniScan AR — Graphe de connaissances spatial pour la maintenance industrielle

En bref

OmniScan AR est ce que je construis en ce moment : on pointe un smartphone ou un Meta Quest 3 vers une machine industrielle, il la reconnaît, ancre sa documentation et un jumeau 3D interactif autour d'elle, et répond aux questions posées à voix haute.

C'est un projet solo, planifié en trois phases de deux mois, découpées en sprints et suivies sur un tableau de projet GitHub public. Cette page décrit ce qui existe aujourd'hui et ce qui est prévu — et sépare bien les deux.

Le problème

En atelier, les techniciens de maintenance perdent du temps à chercher dans des manuels papier et des PDF la page qui concerne la pièce devant eux. L'information existe ; passer de cette machine, ce composant à ce paragraphe, c'est ça qui est lent.

C'est donc une recherche en forme de graphe — machine, composant, document, modèle 3D — avec une caméra comme requête. Et elle doit tourner sur deux appareils très différents : un téléphone, que chaque technicien a déjà en poche, et un casque, qui libère les deux mains.

Architecture

Déjà construit (phase 1) :

Un graphe de connaissances Neo4j — machines, composants, documents, modèles 3D et étiquettes de vision comme nœuds, une contrainte d'unicité sur chacun, et des données de départ pour développer.
Un backend FastAPI avec une couche d'accès au graphe et des schémas typés, qui renvoie tout le voisinage d'une machine en un appel : GET /api/v1/machines/{id}/subgraph.
Un service de vision YOLOv8 — un microservice FastAPI à part qui classe une image de la caméra, avec l'infrastructure prête pour affiner le modèle sur les machines cibles.
Les fondations du client Unity : AR Foundation initialisé, un client d'API typé pour les deux services avec des types de résultat explicites, et l'interface d'interaction que les versions téléphone et casque partageront.
Docker Compose lance la pile backend.

Prévu : la documentation ancrée en réalité augmentée sur le téléphone et en réalité mixte sur le Quest 3 avec suivi des mains ; le jumeau numérique interactif ; un assistant vocal sur une chaîne de recherche fondée sur le graphe ; et un back-office Next.js pour gérer les données de tous les appareils.

Décisions & compromis

Une seule base de code Unity pour le téléphone et le casque

Le pari central : le même client compilé pour iOS et Android et pour Quest OS, avec plus de 85 % de code partagé comme objectif. Le téléphone est le produit qu'une équipe de maintenance peut adopter demain ; le casque est l'offre premium. Deux applications, ce serait chaque fonctionnalité construite deux fois et qui diverge. La couche d'interaction est une interface dès le départ : le tactile et le suivi des mains sont deux implémentations d'un même contrat, pas deux bases de code.

Un graphe, parce que les questions sont des relations

« Où est le manuel de la pompe de cette ligne ? », c'est trois sauts : machine, composant, document. En relationnel, c'est une jointure qui grossit à chaque nouveau type de lien ; dans un graphe, c'est la requête naturelle. Renvoyer le sous-graphe d'une machine en une requête, c'est exactement ce dont la vue AR a besoin pour tout disposer autour de la machine d'un coup — et cela fondera l'assistant, pour que les réponses portent sur cette machine et pas sur les machines en général.

La vision comme service à part

Le modèle de reconnaissance sera réentraîné et remplacé plus souvent que tout le reste. Derrière son propre point d'entrée HTTP, affiner YOLOv8 sur de nouvelles machines ne touche jamais au client ni au graphe — l'application Unity dépend d'une forme de réponse, pas d'un modèle.

Ce qui résiste pour l'instant

Le périmètre. La vision complète — deux plateformes, vision par ordinateur, un graphe, de l'IA générative, un back-office — représente une année de travail pour une équipe, et je suis seul, avec des phases de deux mois. Livrer une tranche qui fonctionne à la fin de chaque phase, plutôt que toutes les couches à moitié construites, est la discipline dont tout le projet dépend.

L'autre difficulté : le projet vit dans l'espace physique. Un modèle de détection ne vaut que les photos sur lesquelles on l'a affiné, et une ancre qui dérive de dix centimètres place le manuel sur la mauvaise pièce.

Où en est le projet

Phase 1 sur 3. La pile backend, le graphe de connaissances, le service de vision et la couche réseau du client sont fusionnés, par des pull requests relues face à des tickets planifiés. Le client typé appelle déjà les deux services ; relier la reconnaissance au sous-graphe et ancrer le résultat en réalité augmentée sur un téléphone, c'est la boucle qui transforme ces pièces en produit.

La suite

Cette première boucle sur téléphone. Puis la version Quest 3 sur le même code, avec passthrough et suivi des mains ; le jumeau numérique interactif ; et l'assistant vocal fondé sur le graphe.