Chapitre 1 – Le besoin initial : accélérer les POC
OpenGate est né d’un besoin concret et opérationnel : accélérer la création de proof of concept (POC) pour des expériences de réalité mixte et augmentée. Dans un contexte d’expérimentation rapide comme celui de Metagate, chaque journée était une course contre la montre. Les idées étaient nombreuses, les appareils XR comme le Meta Quest 3 de plus en plus performants, mais il manquait un outil léger, dynamique et centralisé pour orchestrer l’accès aux contenus et la gestion des données. L’objectif était clair : développer davantage d’expériences en moins de temps, avec plus de contrôle et de possibilités d’itération.
À cette époque, l’outil le plus flexible et immédiat à disposition était Google Sheets. Une feuille partagée, modifiable en temps réel et facilement lisible par Unity, suffisait pour gérer les premiers tests avec des assets multimédias (images, 3D, sons) et des liens dynamiques. Il suffisait d’insérer une URL, de mettre à jour un paramètre ou de modifier une coordonnée pour que l’expérience dans le casque s’adapte instantanément. Une solution no-code qui permettait à l’équipe créative et aux développeurs de travailler ensemble sans structure superflue.
En parallèle, nous développions de petites API dans Google Apps Script, directement reliées aux feuilles. Ces scripts permettaient d’automatiser la gestion des lignes, d’extraire des données spécifiques, de générer des jetons d’accès ou même de modifier en temps réel la configuration d’une expérience MR. Chaque API était un petit outil conçu pour un objectif précis : accélérer le test d’une scène, d’un personnage ou d’une mécanique interactive. C’est ainsi qu’est née une micro-infrastructure agile, légère mais incroyablement puissante.
Cette approche, bien que conçue comme une solution temporaire, s’est immédiatement révélée efficace. L’équipe pouvait gérer plusieurs projets XR simultanément, avec une configuration centralisée permettant d’intervenir à distance sur des expériences déjà chargées dans les casques. Il suffisait d’ouvrir une feuille et de modifier une valeur pour transformer l’environnement numérique en temps réel. Pour une startup comme Metagate, constamment en mouvement entre événements, expositions et démonstrations, cette souplesse était essentielle.
Cependant, les limites étaient évidentes. L’approche basée sur Google Sheets n’offrait pas une véritable évolutivité. Il n’existait aucun système structuré pour le contrôle des accès, l’intégration d’avatars, la gestion de scènes complexes ou l’interopérabilité avec les plateformes NFT. De plus, le code lié aux feuilles était écrit de manière fragmentée, souvent avec des solutions de « vibe coding » : rapides et créatives, mais difficiles à maintenir à long terme.
C’est précisément à ce moment-là qu’est née l’idée de transformer ce système provisoire en quelque chose de plus solide, modulaire et évolutif.
Chapitre 2 – Les premiers tests avec les alpha-testeurs
Une fois la micro-infrastructure basée sur Google Sheets et les API opérationnelle, il était temps de la tester sur le terrain. Nous avons alors impliqué les premiers alpha-testeurs : artistes, développeurs, commissaires et utilisateurs avancés déjà proches de la communauté Metagate. L’objectif était de comprendre si ce système léger et dynamique pouvait réellement simplifier la création et l’utilisation d’expériences en réalité mixte.
Les retours furent immédiatement encourageants. Les alpha-testeurs apprécièrent la possibilité de modifier les contenus à la volée, sans devoir recompiler le projet Unity. Il suffisait de mettre à jour un lien dans une feuille pour que l’expérience dans le casque s’adapte en temps réel. Cela ouvrait de nouvelles possibilités pour les ateliers en direct comme pour les tests avant événement.
Certains utilisateurs, sans aucune expérience en programmation, parvenaient déjà à faire apparaître des assets 3D, des images et des vidéos simplement en collant un lien dans une cellule. L’aspect no-code de la solution s’est révélé déterminant pour favoriser la collaboration entre des profils très différents.
À ce stade, il n’existait pas encore de véritable UI : l’interface était la feuille elle-même. Mais cela suffisait pour révéler le potentiel de l’approche. Nous avions le sentiment d’avoir trouvé une nouvelle manière, directe et partagée, de composer des expériences XR. La mise en place de l’expérience de mixed reality se faisait manuellement et physiquement dans le monde réel ! Une nouvelle manière de concevoir un « builder », à mi-chemin entre physique et numérique, pleinement dans l’esprit de la mixed reality.
Cet enthousiasme donna l’impulsion décisive pour imaginer quelque chose de plus structuré. Le système fonctionnait, mais pour évoluer il devait sortir de la feuille et devenir une véritable plateforme. OpenGate, qui n’avait pas encore de nom, était sur le point de naître pour de bon.
Chapitre 3 – GPT-o3, vibe coding et vacances de Noël
C’est pendant les vacances de Noël que quelque chose d’inattendu se produisit. Marco Pizzini, issu d’une formation économique et sans formation informatique, commença par curiosité à expérimenter avec GPT-o3. L’idée était simple : comprendre si l’IA pouvait aider à écrire du code afin d’étendre et de renforcer le système que nous utilisions déjà.
Ce qui suivit fut une période de « vibe coding » pur : un échange continu entre intuitions, prompts génératifs et code immédiatement mis en pratique. Chaque nouvelle fonctionnalité, de l’intégration de nouveaux types d’assets à la gestion des identifiants utilisateurs, était construite avec l’aide de l’IA. L’absence de règles rigides, combinée à la flexibilité du système existant basé sur Sheets et des API légères, rendit cette période extrêmement fertile.
En peu de temps, de véritables composants produit commencèrent à émerger : un premier login, une gestion basique des avatars, une première idée de cloud. Tout restait artisanal, mais cela fonctionnait. Et surtout, l’ensemble avait été construit transversalement par une personne non technique, soutenue par une intelligence artificielle.
C’est alors que nous avons compris : si GPT nous permettait d’aller aussi loin, alors OpenGate pouvait réellement être accessible à tous.
Le défi était lancé : jusqu’où pouvions-nous aller uniquement avec GPT, au moins pour la partie web-app ?
Chapitre 4 – La webapp commence à prendre forme
Après les premières expérimentations et les tests réussis, il était naturel de vouloir transformer cet ensemble de feuilles et de scripts en quelque chose de plus solide. C’est ainsi qu’est né le premier prototype de la webapp OpenGate, développé avec Flutter et Supabase. L’objectif était clair : créer un hub central pour gérer les assets, les utilisateurs et les fonctions interopérables entre différentes expériences de réalité mixte.
Les premières fonctions migrées furent les plus utilisées : le cloud pour charger des assets multimédias, l’interface permettant de connecter des wallets Web3 comme Metamask et WalletConnect, et l’intégration avec Ready Player Me pour créer et enregistrer des avatars 3D. À cela s’ajouta un système basique de gestion d’assistants IA avec OpenAI, associés aux avatars.
La force de cette approche résidait dans la continuité avec l’application pour casques XR, qui continuait entre-temps à lire les Google Sheets. Mais il était désormais possible d’accéder aux mêmes données et contenus directement depuis la webapp, unifiant ainsi l’écosystème.
L’architecture, encore embryonnaire, devenait progressivement modulaire. Chaque bloc – cloud, NFT, IA, avatar – était pensé comme un composant indépendant mais connectable. La véritable mission d’OpenGate commençait à se dessiner : devenir un pont modulaire entre les mondes numériques.
Chapitre 5 – Adieu Google Sheets
La transition de Google Sheets vers la webapp fut plus rapide que prévu. Bien qu’essentiels durant les premiers mois, leurs limites devenaient évidentes : accès peu sécurisé, structure fragile, difficulté à gérer des contenus complexes ou plusieurs scènes. Avec l’arrivée du backend Supabase et d’un frontend Flutter fonctionnel, la webapp prit le relais.
La migration fut nette. Les mêmes champs que dans les feuilles furent d’abord reproduits dans la base de données, puis l’application du casque commença à lire directement depuis Supabase. En parallèle, chaque nouvel utilisateur était enregistré sur la webapp et non plus via Google. Le résultat fut un système plus évolutif, sécurisé et cohérent.
En peu de temps, Google Sheets fut complètement supprimé de l’application. Ce qui était né comme un outil provisoire avait été remplacé par une véritable infrastructure intégrée, prête à évoluer. C’était le signe qu’OpenGate devenait plus qu’une expérimentation : un projet doté d’une vision, d’utilisateurs et d’un réel potentiel de croissance.
Chapitre 6 – Le brainstorming sur l’interopérabilité
Une fois la webapp consolidée, une question cruciale s’est posée : que pouvions-nous réellement en faire maintenant ? C’est à ce moment-là qu’eut lieu un brainstorming déterminant. Réunis autour d’une table – réelle ou virtuelle – nous avons commencé à réfléchir au véritable potentiel d’OpenGate : devenir un pont entre les plateformes, un outil d’interopérabilité entre différents mondes.
Il ne s’agissait plus seulement de charger des assets ou de les faire apparaître en réalité mixte. L’idée était bien plus ambitieuse : permettre aux utilisateurs d’emporter avec eux leurs contenus, avatars et données d’un métavers à l’autre, d’une expérience à l’autre, tout en conservant une cohérence narrative et identitaire. NFT, avatars Ready Player Me, assistants IA, assets cloud… tout devait pouvoir être réutilisé partout.
À ce moment-là, OpenGate commença à se définir comme une véritable infrastructure de connexion. Plus seulement un builder de Mixed Reality, mais une couche transversale, un point de jonction. Une interface d’interopérabilité compatible avec les logiques XR, gaming, Web3 et culture numérique.
Ce fut un changement de paradigme. De simple support opérationnel pour Metagate, OpenGate commençait à se dessiner comme un produit autonome, avec une mission claire : créer une continuité entre les écosystèmes numériques qui vivent encore aujourd’hui en silos, mais laissent la porte ouverte à des solutions de ce type que personne n’a jusqu’ici pleinement exploitées.
Chapitre 7 – Restructuration évolutive et nouvelle UI pour l’application sur casque
Une fois clarifiée la vision d’OpenGate comme infrastructure modulaire et interopérable, nous avons compris que le maillon faible était précisément l’application sur casque. Toujours liée à l’ancienne logique de Google Sheets, elle était devenue un empilement de correctifs, de tests rapides et de code écrit « à la volée ». Elle fonctionnait, mais restait fragile, difficile à maintenir et surtout peu évolutive.
Un nouveau brainstorming commença alors, centré cette fois sur la manière de nettoyer et refondre l’UI de l’application XR. Initialement conçue pour des tests rapides, l’interface s’était chargée avec le temps de structures inutiles, d’étapes non optimisées et de logiques héritées d’une période où chaque élément était hard-codé ou lu directement depuis Google Sheets.
Nous voulions au contraire une UI conçue pour les utilisateurs finaux, pas seulement pour les développeurs : fluide, modulaire, cohérente et facilement navigable en mixed reality. L’objectif était de créer une structure réutilisable dans plusieurs projets, avec des composants adaptables à différents types d’expériences, des expositions aux jeux collaboratifs.
En parallèle, nous avons commencé à séparer logiquement les modules de l’application : assets, IA, multiplayer, NFT, cloud. Chaque bloc devait fonctionner de manière autonome tout en communiquant avec les autres. C’était le début de la véritable transformation d’OpenGate en système XR flexible.
Chapitre 8 – La sélection à BeFuture et l’aide de KNOBS
Au moment de cette restructuration et de cette remise à plat générale, une nouvelle marqua un tournant : OpenGate fut sélectionné parmi les projets lauréats de BeFuture. Le programme, consacré à l’innovation et à l’expérimentation, nous apporta deux éléments fondamentaux : crédibilité et ressources. Nous avions enfin la possibilité concrète de remettre de l’ordre dans le code et de rendre la plateforme plus sûre, stable et prête pour la production.
Grâce aux fonds obtenus – qui seraient disponibles dans les mois suivants – il devint possible de planifier précisément les prochaines étapes, cette fois avec une vision claire et un plan d’action partagé. Nous avons notamment commencé à échanger avec l’équipe de KNOBS afin de définir un parcours de refactoring technique, d’amélioration de la conformité et de sécurisation de la webapp.
L’objectif était ambitieux : nettoyer l’ensemble du backend, modulariser le code, intégrer des contrôles de sécurité, renforcer le login, optimiser les API et garantir la robustesse du système dans le temps. Mais rien de tout cela n’était encore opérationnel : tout était encore en phase de définition et de conception.
Entre-temps, le travail se poursuivait en parallèle sur la partie la plus visible : l’application sur casque, qui devait accueillir les premières versions publiques prévues pour l’été. Le véritable travail technique rendu possible par BeFuture allait commencer peu après.
Chapitre 9 – Deux trajectoires : nouvelle UI en développement, ancienne UI adaptée au Meta Store
Pendant les mois de printemps, OpenGate avançait sur deux trajectoires parallèles. D’un côté, Daniele travaillait sur la nouvelle UI/UX de l’application sur casque : une refonte complète, propre et modulaire, pensée pour offrir une interaction fluide et intuitive aux utilisateurs finaux. Le design était construit de zéro, avec une attention particulière à la clarté des parcours, à l’évolutivité et à la cohérence visuelle.
Mais nous avons décidé de ne pas attendre la nouvelle interface avant de confronter la plateforme au monde réel. En parallèle, Paolo et Giada se sont donc concentrés sur une autre priorité : nettoyer et adapter l’ancienne UI, chargée des structures accumulées pendant la période Google Sheets, afin de la rendre au moins publiable sur le Meta Store.
L’objectif était pragmatique : sortir le plus vite possible, même avec une version limitée, afin de tester la procédure de soumission, d’affronter d’éventuels blocages techniques ou bureaucratiques et de commencer à comprendre les règles de publication de Meta, souvent opaques et complexes. C’était une confrontation contrôlée avec la réalité, utile pour anticiper les futurs problèmes et préparer les versions suivantes. Réduire le risque.
OpenGate effectuait ainsi son premier saut hors du laboratoire : pas encore parfait, mais réel.
« Si ton premier produit ne te fait pas un peu honte, c’est que tu l’as lancé trop tard ! » Cit.
Chapitre 10 – Première version gratuite en juin et test à ATLAS MEET
En juin arriva le moment de la première version publique d’OpenGate. Même si l’UI restait une solution de fortune, ajustée juste assez pour passer la soumission au Meta Store, nous avons décidé de publier gratuitement la première version. L’objectif n’était pas encore d’acquérir des utilisateurs, mais de tester la robustesse technique et le comportement de la plateforme dans un contexte réel.
L’occasion idéale fut l’ATLAS MEET, événement organisé par le MEET Digital Culture Center à Milan, auquel nous avons été invités pour la deuxième année consécutive par Maria Grazia Mattei. Pour l’événement, nous avons lancé une Call for Artists, permettant de charger très rapidement des contenus sur le casque et de les visualiser en réalité mixte.
Ce fut un test important à tous points de vue : la gestion du cloud fonctionnait bien, le système tenait et nous pouvions réellement « spawner » des assets sans écrire de code. Ce fut aussi l’occasion de recueillir des retours directs sur le terrain : ce qui fonctionnait, ce qui ne fonctionnait pas, ce qui manquait de clarté et ce qui pouvait être amélioré.
Cette première sortie publique représentait un moment symbolique : OpenGate n’était plus un projet interne ni un prototype, mais une plateforme XR prête à rencontrer son public.
Chapitre 11 – Deuxième version en juillet et test au Broletto di Novara
En juillet arriva la deuxième version d’OpenGate, avec cette fois une avancée importante : la première version de la nouvelle UI, fruit du travail des mois précédents. Elle n’était pas encore définitive, mais suffisait à proposer une expérience plus fluide, cohérente et moderne que la version précédente, conçue uniquement pour franchir l’étape de publication sur le store.
Pour la tester, l’invitation au Broletto di Novara fut déterminante, grâce à la collaboration avec Andrea Barbara Romita et au soutien de Marta Ballara. Dans un contexte artistique et culturel, nous avons présenté OpenGate comme un outil no-code permettant de gérer des contenus numériques en réalité mixte, avec une démo interactive accessible à différents publics.
L’expérience fut extrêmement utile : le nouveau parcours d’interaction simplifiait réellement l’utilisation de l’application, la rendant plus accessible même aux personnes n’ayant jamais utilisé de casque XR. Les fonctions cloud, avatar et IA commençaient à coexister dans une interface unifiée.
Chapitre 12 – Troisième version en août : multiplayer, scènes et monde persistant
La troisième version d’OpenGate, publiée en août, marque un véritable tournant. C’est la première version réellement structurée et complète de l’application sur casque, avec certaines des fonctions les plus attendues : système multi-scènes, multiplayer synchronisé et persistance des objets dans le monde réel.
Les utilisateurs peuvent désormais naviguer entre différentes scènes, chacune avec son environnement, ses règles, ses contenus et sa mise en page. Chaque scène est conçue pour être modifiable en temps réel et surtout réutilisable, avec des configurations enregistrées dans le cloud. Mais la grande nouveauté est que, pour la première fois, ce qui est placé dans l’espace mixte – assets, objets, éléments – reste enregistré et synchronisé même après redémarrage, rendant l’expérience persistante et partagée.
Le multiplayer permet à plusieurs utilisateurs de se retrouver dans la même scène et de voir les objets au même endroit, ouvrant la voie à la collaboration, aux jeux et aux expositions interactives multi-utilisateurs. C’est le premier pas concret vers un espace XR collectif.
La version est en ligne depuis quelques jours et nous sommes maintenant dans une phase d’observation active : nous voulons comprendre comment les utilisateurs se serviront de ces outils, quels contenus ils créeront et où cette nouvelle forme de présence numérique augmentée nous conduira.
Chapitre 13 – Sécurisation et évolutivité du backend avec KNOBS
Avec la troisième version enfin en ligne, il était temps d’aborder un point crucial : la sécurisation du backend. Jusqu’alors, le code avait été écrit de manière progressive et fonctionnelle, souvent en suivant le rythme des besoins créatifs et des tests continus. Même si la structure tenait, il était évident qu’un travail technique ciblé était nécessaire pour garantir fiabilité et évolutivité.
C’est à ce stade que KNOBS entra concrètement en jeu. Son travail consista en une correction ciblée du code existant, afin de consolider ce qui fonctionnait déjà tout en le protégeant contre de futurs problèmes.
Les priorités étaient claires : protection des clés API, amélioration de la sécurité des accès, gestion centralisée des variables sensibles et surtout préparation d’une structure plus solide permettant de tester les mises à jour en toute sécurité et d’accueillir un nombre croissant d’utilisateurs et de contenus.
Inscrivez-vous à la newsletter pour profiter de tous les avantages !
Pour voir les vidéos de nos expériences, suivez-nous sur Instagram, YouTube et Twitter.
Retrouvez nos liens sur Linktree ou contactez-nous !
Par Marco Pizzini