Série : Apprendre à coder avec l’IA

Comment fonctionne RakuAI — de bout en bout

Le chemin de bout en bout, du scan téléphone à un monde spatial piloté par IA.

Scannez une pièce avec votre téléphone. Trente secondes plus tard, un splat gaussien 3D existe. Demandez maintenant à Claude — ou à ChatGPT, ou à Gemini — de l’interroger, de l’annoter, d’y déplacer des choses. C’est tout le pitch. Ce billet est le compte-rendu honnête de la façon dont chaque étape fonctionne réellement, de ce qui est en direct aujourd’hui, et de ce qui est encore bloqué sur des crédits GPU.

C’est un genre différent de billet pour le blog. Les billets habituels du samedi portent sur un problème précis résolu ou une semaine précise survécue. Celui-ci prend du recul vers le tableau complet — ce qu’est RakuAI, comment ses pièces se connectent, et ce qu’est réellement la douve défensive quand on la trace de bout en bout. C’est le billet que j’aurais aimé trouver la première fois que j’ai dû expliquer cela à un développeur partenaire qui voulait la vraie histoire, pas la version présentation commerciale.

La prémisse en une phrase

Vous scannez un lieu réel avec un téléphone. Le scan devient un splat gaussien 3D — une reconstruction photoréaliste faite de millions de minuscules ellipsoïdes transparents. Le splat est servi via un runtime qui l’expose comme des outils que tout LLM peut appeler. Le LLM peut interroger la scène, raisonner sur ce qu’elle contient, et — sous les bonnes permissions — la muter. Pas de licence de moteur de jeu. Pas d’intégration par fournisseur. Pas de verrouillage à un modèle.

C’est l’idée « Scannez-le. Puis parlez-lui. ». Voici comment fonctionne chaque pièce de cette chaîne.

Étape 1 : Capture — de la vidéo téléphone aux images brutes

Le point d’entrée est une application web progressive (PWA) sur rakuai.com/capture-app/. Elle tourne dans un navigateur mobile sans installation. L’utilisateur enregistre 30 à 60 secondes de vidéo, en marchant lentement autour du sujet — une pièce, un objet, un espace qui vaut la peine d’être préservé.

La PWA regroupe les images de la vidéo et les envoie à POST /api/v1/capture sur le backend, qui tourne sur Azure Container Apps à api.rakuai.com. Le backend est un service FastAPI — environ 9 500 points de terminaison REST — qui authentifie l’envoi, enregistre les métadonnées (nom de fichier original, type de contenu, horodatage de capture), et stocke le paquet d’entrée brut dans Azure Blob Storage.

Cette partie est en direct. Le chemin d’envoi fonctionne aujourd’hui, pour quiconque s’inscrit.

Étape 2 : Reconstruction — extraction de caractéristiques COLMAP vers nuage de points

Le backend envoie une tâche de reconstruction à un exécuteur de tâches Container Apps appelé recon-worker. La première chose qu’il fait est de faire tourner COLMAP — la bibliothèque de Structure from Motion — sur les images envoyées. COLMAP identifie les caractéristiques correspondantes entre images et calcule les positions de caméra, produisant un nuage de points 3D épars.

Cette étape est liée au CPU et ne nécessite pas de GPU. Elle fonctionne aujourd’hui.

Étape 3 : Entraînement du splat — Brush transforme un nuage de points en splat gaussien

C’est l’étape gourmande en calcul. Le travailleur de reconstruction alimente le nuage de points COLMAP et les images originales dans Brush v0.3.0, un entraîneur de Gaussian Splatting 3D. Brush ajuste des millions de petites gaussiennes 3D à la scène — chaque gaussienne est un ellipsoïde dans l’espace 3D avec une position, une orientation, une échelle, une opacité, et une couleur dépendante du point de vue. La sortie est un fichier .ply ou .spz stocké dans Azure Blob Storage aux côtés de l’entrée.

Honnêtement : cette étape nécessite un GPU. Le quota GPU sur Azure A10 est en cours d’examen. Les crédits AWS Activate sont en attente d’approbation (demandés le 28-05-2026). Tant que l’un des deux n’est pas arrivé, le travailleur de reconstruction en production retombe sur un backend simulé — l’architecture est câblée, le chemin GPU n’est pas encore en direct. C’est un accès anticipé, pas un produit grand public terminé.

Étape 4 : Le runtime MCP — 17 outils + environ 9 500 points de terminaison relayés

C’est la partie qui fait du splat un objet spatial vivant plutôt qu’un fichier statique.

Le runtime est un moteur C++ : 18 DLL natives, 30 738 fonctions exportées à travers des sous-systèmes pour la physique, le rendu, l’audio, le suivi, l’état multijoueur, et l’orchestration IA. Vert en CI sous Windows, Linux, et macOS depuis avril 2026.

Par-dessus le moteur, le serveur MCP expose deux surfaces :

17 outils natifs (5 en lecture seule + 12 de mutation) — le contrat typé que tout agent externe utilise pour interagir avec une scène. Les outils en lecture seule fonctionnent dans tout environnement. Les outils de mutation nécessitent des octrois de permission explicites et sont refusés par défaut en production.

Environ 9 500 points de terminaison relayés — la surface FastAPI complète de raku-api, exposée via le relais MCP. N’importe quelle route du backend est accessible via le relais, donnant à un LLM accès à l’historique de capture, au statut des tâches, aux métadonnées de scène, et à toute la surface de requête du backend.

Le serveur MCP est hébergé sur api.rakuai.com sur Azure Container Apps. Le relais pour Claude Desktop, ChatGPT, et Gemini est en direct. Le serveur parle le transport stdio, journalise chaque appel dans une piste d’audit, et applique des limites de débit par session.

Étape 5 : Accès LLM multi-fournisseur — la vraie douve défensive

Tout modèle qui parle Model Context Protocol peut se connecter au runtime et appeler des outils contre une scène capturée sans intégration personnalisée. Claude, ChatGPT, Gemini, Copilot — le contrat est le même pour tous.

Le runtime écrit le contrat une fois. Les modèles s’adaptent au contrat. Quand un nouveau laboratoire de modèles livre un client MCP, il fonctionne contre le runtime sans aucun changement de code de notre côté.

Le runtime n’a aucune opinion sur quel modèle se trouve de l’autre côté. Il garde l’autorité sur la physique, les collisions, le score, le rendu, et l’état de scène. Le modèle apporte des requêtes et de l’intention. Aucun des deux côtés n’a besoin de savoir que l’autre existe sauf via la surface d’outils typée.

C’est la douve défensive : une capture honnête du monde physique, stockée comme une représentation 3D sans perte, interrogeable par tout LLM qui parle un protocole ouvert. Pas verrouillé à un modèle. Pas verrouillé à un cas d’usage. Pas verrouillé à un fournisseur matériel.

Ce qui est en direct aujourd’hui par rapport à ce qui est sur la feuille de route

En direct aujourd’hui : - PWA de capture téléphone, envoi vers Azure Blob - Extraction de caractéristiques COLMAP et nuage de points - Infrastructure backend (FastAPI environ 9 500 points de terminaison REST, magasin de tâches Redis, limites de débit sensibles au palier) - Runtime MCP avec 17 outils natifs + environ 9 500 points de terminaison relayés - Relais MCP hébergé pour Claude, ChatGPT, Gemini - Contrat d’outils multi-fournisseur (stdio, refus-par-défaut, journal d’audit complet) - Palier gratuit et palier Pro Bêta (Pro Bêta est à 0 $ pendant la période bêta)

Bloqué (accès anticipé — attendu sous quelques jours) : - Entraînement de splat GPU réel sur Azure A10 (quota en cours d’examen) - Entraînement de splat GPU réel sur AWS G5 (crédits Activate en cours d’examen)

Feuille de route (pas encore livré) : - Visionneuse de splat en direct dans la PWA de capture (le moteur de rendu de splat gaussien three.js est câblé ; la démo de bout en bout nécessite un splat entraîné) - Octrois de mutation en libre-service en production - Écosystème d’adaptateurs tiers (des adaptateurs de référence internes existent ; un large écosystème est sur la feuille de route)

Membre NVIDIA Inception depuis mai 2026.

Pourquoi « inférence-seule » n’est pas une limitation

Le runtime n’entraîne pas de modèles. Il ne fait pas de fine-tuning de modèles. Il n’exige pas que vous fassiez tourner un modèle à l’intérieur de lui. Le modèle que vous avez déjà — quel qu’il soit, où qu’il vive, quelle que soit sa licence — se connecte via MCP et pilote le runtime depuis l’extérieur.

C’est un choix d’architecture délibéré. Entraînement et inférence sont des préoccupations séparées. Le runtime est bon en physique spatiale, en gestion d’état déterministe, en synchronisation multi-utilisateur, et en rendu à faible latence. Le laboratoire de modèles est bon en raisonnement, génération, et langage. Le contrat MCP est la frontière entre les deux. Aucun des deux côtés n’a à faire le travail de l’autre.

Inférence-seule signifie aussi aucune exigence de résidence GPU pour servir. L’étape gourmande en calcul (entraînement du splat) est un coût unique par capture. Tout ce qui vient après est de la géométrie et des requêtes MCP — tourne sur les mêmes instances Azure Container Apps qui servent l’API.

Le récapitulatif honnête

Le pipeline est : vidéo téléphone → COLMAP → Gaussian Splatting Brush → Azure Blob → runtime MCP → n’importe quel LLM. Quatre des cinq étapes sont en direct. La cinquième (entraînement de splat GPU) est câblée et attend des crédits. La visionneuse pour boucler le cycle dans le navigateur est le prochain jalon.

Si vous voulez essayer la capture dès aujourd’hui, la PWA est sur rakuai.com/capture-app/. Si vous voulez piloter une scène via MCP depuis Claude Desktop, le guide est sur /developers/claude-desktop.html. Si vous voulez comprendre la surface d’outils complète, elle est sur /mcp.html.

Scannez-le. Puis parlez-lui.

← Tous les articles