L'IA comme système nerveux, pas l'IA comme usine

« Natif IA » est le mot le plus dilué du marché des moteurs en 2026. Voici la ligne architecturale qui sépare un panneau de chat d'un runtime où le modèle est dans la boucle à chaque frame - la ligne sur laquelle RakuAI est construit.

La plupart des moteurs de jeu et des runtimes d’informatique spatiale qui s’appellent « natifs IA » en 2026 veulent dire à peu près la même chose. Il y a un panneau de chat quelque part dans l’éditeur. Il y a un bouton qui demande à un modèle distant de générer un asset. Le modèle produit une chose. La chose est déposée dans un projet. Le runtime, qui existait avant que l’IA n’arrive, exécute la chose.

C’est le schéma usine. Une requête part. Un artefact revient. Le moteur est le consommateur.

RakuAI n’est pas construit de cette façon. L’IA n’est pas une station sur la chaîne de montage. C’est une primitive dans le runtime. Plus proche en esprit d’un système nerveux que d’une usine. Continuellement présente, dans la boucle à chaque frame, observant, décidant, réagissant. La retirer ne retire pas une fonctionnalité. Elle retire ce qui donne du sens au reste du moteur.

Si vous lisez un seul article sur ce que signifie réellement « natif IA » au niveau de l’architecture, je veux que ce soit celui-ci.

Deux schémas, dessinés

Voici le schéma usine, condensé à son minimum honnête :

# Factory: AI produces artifacts. The runtime consumes them.
def author_session(prompt: str) -> Asset:
    response = remote_model.generate(prompt)
    asset = parse(response)
    save_to_project(asset)
    return asset

Le cycle de vie est simple. L’humain tape. Le modèle produit. Le fichier atterrit sur le disque. Le runtime charge le fichier plus tard. Le modèle est un fournisseur de contenu. Le runtime ne lui parle plus jamais après que l’artefact est livré. Si le modèle passe hors ligne, vous avez toujours un moteur fonctionnel. Vous avez juste un endroit de moins pour acheter des assets.

Voici maintenant le schéma système nerveux :

# Nervous system: AI is wired into the simulation step itself.
def step(world, agents, dt):
    for agent in agents:
        observation = agent.senses.gather(world)        # what is around me
        intent      = agent.brain.observe(observation)  # AI is in the loop
        action      = agent.policy.choose(intent, dt)   # constrained by deterministic rules
        world.apply(action)
    return world

Cycle de vie différent. À chaque frame, chaque agent, le modèle contribue au prochain état du monde. Le modèle n’est pas un fournisseur. C’est un participant. Retirez-le et la simulation cesse d’être intéressante d’une façon qu’aucune bibliothèque d’assets ne peut compenser.

Ce sont deux architectures complètement différentes. Le choix que vous faites à cette couche contraint tout ce qui est au-dessus.

Ce que vous achète le schéma usine

L’honnêteté d’abord. Le schéma usine est réel, utile, et se déploie aujourd’hui. Il vous achète quatre choses.

Il vous achète de la vélocité sur le contenu. Générer un arbre, un bâtiment, une disposition de niveau, un morceau de dialogue. De vrais gains de productivité, et le schéma artefact-sur-disque est la façon la plus simple de les obtenir.

Il vous achète de l’indépendance de fournisseur. Parce que l’artefact vit sur le disque, vous pouvez échanger le modèle qui l’a écrit sans changer votre runtime. C’est une couverture qui vaut la peine d’être avoir.

Il vous achète une relecture déterministe. L’artefact est fixé une fois écrit. Deux joueurs dans le même niveau voient le même niveau.

Il vous achète un mode de défaillance propre. Si le modèle n’est pas disponible, le moteur tourne quand même. Vous créez juste moins de contenu.

Ce sont de vrais gains. Si votre produit est « des outils qui aident les humains à faire des jeux », le schéma usine est probablement le bon choix. Le coût est caché. Il ne se manifeste que quand vous essayez de faire quelque chose que le schéma usine ne peut pas faire.

Ce que le schéma usine ne peut pas faire

Le schéma usine ne peut pas créer un monde qui réagit au joueur de façons que l’auteur n’a pas prévues. Par construction, chaque artefact dans un moteur à schéma usine a été écrit avant que le joueur n’arrive. L’espace des comportements est le produit cartésien de la bibliothèque d’artefacts et de la logique scriptée du moteur. Grand espace, mais borné. Les frontières sont visibles en jouant en moins d’une heure.

Le schéma usine ne peut pas vous donner des PNJ qui raisonnent de façon significative sur un monde dans lequel ils n’ont pas été pré-scriptés. Branchez un système de dialogue piloté par LLM et vous obtenez une saveur de conversation localement convaincante et globalement inerte. Le PNJ dira de nouvelles choses. Le monde ne change pas en réponse. Le système de dialogue et la simulation sont deux trains sur des voies parallèles. Ils ne se rencontrent jamais.

Le schéma usine ne peut pas adapter l’expérience aux coordonnées GPS réelles de l’utilisateur réel se tenant à un endroit physique réel. Ce dernier point est celui qui me tient le plus à cœur. Si vous construisez de l’XR ancrée dans le monde réel, où l’expérience se produit à un endroit spécifique sur Terre, vous ne pouvez pas pré-écrire chaque interaction possible. Le monde est trop grand. Les contextes trop variés. Le chemin du joueur trop imprévisible. Soit vous réagissez dans la boucle, soit vous livrez une brochure touristique.

C’est la raison structurelle pour laquelle RakuAI n’est pas une usine.

Ce que « système nerveux » achète, concrètement

Trois choses, par ordre d’intérêt croissant.

Un : des PNJ qui observent avant de parler. Quand le cerveau d’un agent tourne à chaque frame, voit le monde dans lequel se trouve réellement le joueur, et décide quoi faire en fonction de ce qu’il voit, le résultat est qualitativement différent d’un arbre de dialogue avec un LLM boulonné. L’agent peut réagir à la pluie. À l’heure du jour. Au fait que le joueur se tient devant lui depuis quatre-vingt-dix secondes sans rien faire. Rien de tout cela n’est dans le dialogue. Tout cela est dans la simulation, et le modèle lit la simulation directement.

Deux : des expériences qui se reforment autour du lieu où elles se produisent. Le moteur lui-même interroge le modèle. Étant donné ce terrain, cette météo, cette heure du jour, cet ensemble de points d’intérêt à proximité, à quoi devrait ressembler la prochaine rencontre. L’expérience n’est plus un enregistrement. C’est une fonction du contexte réel du joueur. Deux joueurs dans des villes différentes jouant la même expérience .raku obtiennent des sessions de jeu différentes, et les deux sont cohérentes.

Trois : des comportements qui émergent de l’architecture. C’est celui qui m’a surpris quand il a commencé à se manifester. Quand l’IA est une primitive, quand chaque système du moteur peut l’appeler et avoir ses décisions façonnées par elle, les systèmes commencent à interagir de façons qu’aucun auteur de sous-système unique n’a conçues. Un agent qui observe le terrain influence le système de pathing. Le pathing influence le comportement de foule. Le comportement de foule devient une entrée pour l’observation du prochain agent. Des boucles se forment. Certaines sont intéressantes. Les intéressantes sont la raison pour laquelle quiconque s’est donné la peine de cette architecture en premier lieu.

Le coût, payé d’avance

L’architecture a un prix, et il n’est pas petit.

Vous payez pour l’inférence sur l’appareil. L’IA qui tourne sur le chemin critique de la simulation ne peut pas faire un aller-retour réseau à chaque frame. Cela signifie que les poids du modèle vivent sur l’appareil. Cela signifie de la quantification, du batching, une budgétisation mémoire soigneuse, et une histoire de déploiement qui contemple le matériel du joueur. RakuAI est construit autour de cette contrainte. Petits modèles, sur l’appareil, près de la boucle chaude. La contrainte est réelle et architecturale.

Vous payez pour la discipline de fiabilité. Un modèle qui hallucine à l’intérieur d’une usine de contenu produit un arbre bizarre. Un modèle qui hallucine à l’intérieur de l’étape de simulation produit un monde bizarre. Les contrats entre la couche modèle et la couche déterministe doivent être conçus, validés, et audités. Ce n’est pas une réflexion après coup. C’est le travail.

Vous payez pour une observabilité que vous n’obtenez pas gratuitement avec les moteurs traditionnels. Quand l’IA est un participant à chaque frame, vous devez voir ce qu’elle fait, quand, avec quelles entrées, produisant quelles sorties. Logging. Traçage. Relecture. Toutes les choses que vous construiriez pour n’importe quel système distribué, sauf qu’elles vivent maintenant dans la boucle de simulation.

Ces coûts sont la raison pour laquelle la plupart des moteurs choisissent le schéma usine. Le schéma usine est authentiquement moins cher à construire. Il est aussi authentiquement moins intéressant, d’une façon qui ne devient visible qu’après avoir passé du temps à l’intérieur d’un moteur qui a fait l’autre choix.

Si vous construisez un jeu, une expérience XR, ou tout autre système interactif et que vous vous demandez si la question de l’IA est « quel modèle j’intègre » ou quelque chose de plus profond, la réponse est que c’est quelque chose de plus profond. Vous pouvez le sentir la première fois que vous essayez de faire faire au schéma usine quelque chose pour lequel il n’a pas été construit.

Dimanche après-midi, le genre de billet qui voulait être écrit. Retour au moteur demain.