Simuler un environnement d’exécution qui dit non : comment nous transformons le navigateur en bac à sable pour qu’il se comporte comme WeChat

Sun, 19 Jul 2026 00:00:00 GMT

Simuler un environnement d’exécution qui dit non : comment nous transformons le navigateur en bac à sable pour qu’il se comporte comme WeChat

Par Oleg Sidorkin, CTO et cofondateur de Cinevva

Nous avons récemment lancé un mode mini-jeu WeChat dans notre Créateur de jeux : un profil de compilation qui maintient les jeux générés par IA dans le sous-ensemble de la plateforme web capable de survivre à un portage vers l’environnement d’exécution de WeChat. Ce profil est un ensemble de règles de génération. Pas d’interface DOM, pas de Pointer Lock, audio en mp3 uniquement, pas de code dynamique. Le modèle les respecte comme les modèles respectent les règles, c’est-à-dire généralement.

« Généralement » ne suffit pas lorsque chaque violation est invisible dans le navigateur et fatale après l’export. Un jeu doté d’une barre de vie en HTML fonctionne parfaitement dans notre aperçu, puis affiche un écran vide sur WeChat, car les mini-jeux WeChat n’ont aucun DOM. Nous avons donc construit ce qui transforme ces règles en lois physiques plutôt qu’en suggestions : un bac à sable en mode strict qui force le navigateur lui-même à refuser ce que WeChat ne peut pas faire. Cet article explique son fonctionnement.

La décision fondamentale : simuler l’absence, pas la présence

L’approche évidente consisterait à émuler WeChat : implémenter wx.createCanvas, wx.onTouchStart, wx.setStorageSync, puis exécuter les jeux sur cette surface wx.* émulée. Nous avons choisi l’approche inverse, en raison de la structure de notre pipeline d’export.

En mode WeChat, les jeux sont toujours écrits à partir des API du navigateur. Lors de la mise en paquet, un adaptateur — selon l’approche standard de la communauté weapp-adapter — mappe ces API de navigateur vers wx.*. Nos jeux n’appellent donc jamais directement wx.* ; un émulateur wx testerait des chemins de code qui n’existent pas. Ce qui casse réellement un portage n’est pas l’absence de wx.* dans le navigateur. C’est la présence d’API de navigateur sans équivalent dans WeChat, utilisées discrètement pendant la génération. document.createElement('div'). requestPointerLock(). IndexedDB. Un fichier .ogg parfaitement décodé par Chrome qui ne le sera jamais sur WeChat pour iOS.

Le bac à sable simule donc l’absence. Tout ce que WeChat ne possède pas est supprimé, rendu inutilisable ou signalé dans l’aperçu, et le jeu se développe dès sa première image dans l’intersection des deux plateformes.

Son emplacement : un service worker qui était déjà là

Notre aperçu dans l’éditeur suit un chemin de diffusion inhabituel qui a rendu cette fonctionnalité presque gratuite. Dans l’éditeur, les jeux ne sont pas servis depuis le réseau. Un service worker intercepte les requêtes /game/* et sert les fichiers depuis IndexedDB, ce qui permet à l’iframe d’aperçu de se recharger instantanément sans aller-retour réseau. Ce worker injectait déjà deux fichiers virtuels dans chaque page de jeu : un script de capture des erreurs qui transmet à l’éditeur les sorties de console et les plantages, ainsi qu’un inspecteur de scène en direct.

Le bac à sable est le troisième fichier virtuel, _wechat-strict.js, injecté dans le de la page immédiatement après le script de capture et avant l’exécution de tout code du jeu. Cet ordre est crucial à deux égards. Il doit s’exécuter après le script de capture afin que ses appels à console.error soient déjà interceptés et transmis à l’éditeur, mais avant les modules du jeu afin que les interdictions soient en place dès l’exécution de la première ligne de code.

L’activation tient en une seule ligne. L’état du bouton WeChat du créateur est conservé dans localStorage, et l’iframe d’aperçu partage la même origine que l’éditeur ; le harnais n’a donc qu’à lire directement l’indicateur :

try {
  if (localStorage.getItem('cinevva-gc-profile') !== 'wechat-minigame') return;
} catch (e) { return; }

Pour chaque jeu qui ne cible pas WeChat, le script se résume à une comparaison de chaînes et à un retour anticipé. Aucun indicateur de compilation, aucun aller-retour avec le serveur, aucun état à synchroniser avec le service worker.

La liste des interdictions et la classification à deux niveaux

Toutes les violations ne méritent pas la même réponse ; le harnais distingue donc deux niveaux. Les API qui n’existent pas sur WeChat lèvent une exception, car c’est ce qui se produit après l’export et qu’un plantage pendant la génération constitue un aperçu fidèle d’un plantage lors de la validation. Les éléments qui existent mais cassent plus tard déclenchent des erreurs de console bien visibles sans modifier le comportement, car les bloquer masquerait l’état réel du jeu à la personne qui travaille dessus.

Le niveau qui lève une exception : la création de tout élément d’interface HTML, via createElement comme via createElementNS — Three.js crée son canvas avec la variante NS, les deux chemins doivent donc utiliser le même filtre —, eval, new Function, requestPointerLock et l’enregistrement d’un service worker. Chaque exception indique la correction à apporter dans son message :

throw violate("document.createElement('" + tag + "') — Les mini-jeux WeChat n’ont pas de DOM. " +
  "Dessinez l’interface sur un canvas (canvas 2D hors écran -> THREE.CanvasTexture sur un quadrilatère en espace écran) " +
  "et gérez vous-même la détection des touchers.");

Le niveau de signalement : l’accès à indexedDB — qui renvoie undefined, exactement comme WeChat, en plus d’une erreur orientant vers localStorage —, l’audio dans tout format que WeChat pour iOS ne peut pas décoder — vérifié à trois endroits : le constructeur Audio, le setter src du prototype de l’élément multimédia et les URL récupérées —, les requêtes réseau vers toute origine autre que celle du jeu ou notre CDN de ressources — sur WeChat, elles nécessitent un domaine inscrit sur liste blanche et enregistré auprès de l’ICP —, ainsi que toute apparition de Tone.js.

Un audit après chargement s’exécute également peu après la stabilisation de la page : il parcourt le et signale tous les éléments HTML provenant directement du balisage du jeu plutôt que d’une création dynamique. Les HUD statiques échappent à un filtre sur createElement ; ce filtre ne suffit donc pas à lui seul.

Chaque signalement est dédupliqué par message et plafonné à cinquante par session. Un bug de boucle inversée qui crée une div à chaque image produit une seule erreur, pas un déluge qui noie l’information utile.

Les quatre exceptions qui nous ont le plus appris

Construire un bac à sable consiste surtout à décider de ce qu’il ne faut pas rendre inutilisable, et chaque exception que nous avons ajoutée est née d’une panne de nos propres outils pendant le développement.

Notre débogueur repose sur eval. L’outil execute_js du créateur, que l’IA utilise pour sonder le jeu en direct, évalue du code via le gestionnaire de messages du script de capture, qui appelle eval. Rendre eval naïvement inutilisable aurait privé l’IA de ses propres yeux. La solution : avant de le neutraliser, le harnais conserve la véritable fonction dans une propriété non énumérable, puis le gestionnaire du script de capture se rabat sur celle-ci :

Object.defineProperty(window, '__cinevvaRealEval', { value: window.eval, enumerable: false });
window.eval = function () { throw violate('eval() est interdit dans les mini-jeux WeChat.'); };
// script de capture, lors de la réception du message :
returnValue = (window.__cinevvaRealEval || eval)(e.data.code);

Le code du jeu qui tente d’utiliser eval échoue toujours. Pas le débogueur.

L’enregistreur crée lui aussi des éléments. Notre enregistreur de reels est injecté dans l’iframe du jeu sous forme de

Cinevva Blog

Simuler un environnement d’exécution qui dit non : comment nous transformons le navigateur en bac à sable pour qu’il se comporte comme WeChat

Simuler un environnement d’exécution qui dit non : comment nous transformons le navigateur en bac à sable pour qu’il se comporte comme WeChat

La décision fondamentale : simuler l’absence, pas la présence

Son emplacement : un service worker qui était déjà là

La liste des interdictions et la classification à deux niveaux

Les quatre exceptions qui nous ont le plus appris