La majeure partie de notre trafic de recherche n’a jamais été humaine

Par Oleg Sidorkin, CTO de Cinevva

Notre trafic de recherche organique augmente, et ce depuis le début de l’année. Cette partie est réelle. Mais début juillet, la courbe a bondi d’une manière qui ne correspondait à aucune de nos mises en production, et un bond sans cause apparente mérite qu’on lui consacre un après-midi.

Nous avons enquêté et découvert une flotte de Chrome headless arrivant avec un référent Google.

La forme compte davantage que le pic

Au printemps, la part de faux trafic a oscillé entre un tiers et deux tiers des sessions. C’est à peu près le bruit de fond auquel tout site web public doit s’attendre.

Fin juin, elle s’est mise à grimper et n’a pas cessé. Depuis la première semaine d’avril, les sessions réelles avaient été multipliées par environ 5,5 à la mi-juillet. Les sessions automatisées, par environ 18,6.

Pourquoi c’était difficile à voir

Nous surveillons ces chiffres de près, et tout mouvement inexpliqué déclenche une requête d’analyse. Si celui-ci a demandé une véritable investigation, c’est parce que nos lignes de session ne permettaient réellement pas de distinguer les deux populations.

L’engagement était déduit de l’horodatage last_activity_at de chaque session. Lors d’une visite sur une seule page, ce champ ne change jamais après sa première écriture.

Un bot qui charge une page puis repart produit donc la même ligne qu’une personne qui arrive sur un guide et le lit pendant cinq minutes. Taux de rebond, temps passé sur le site, engagement : tout était calculé à partir d’un champ qui ne contient aucune information pour les sessions d’une seule page. Ce n’est pas inhabituel. C’est le comportement par défaut de la plupart des systèmes d’analytics développés en interne, et c’est la première chose que je vérifierais dans le vôtre.

La solution a consisté à ne plus faire de déductions à partir de la ligne de session, mais à lire la balise de sortie, qui transmet depuis le client le temps réellement passé sur la page et la profondeur de défilement. Dès que nous avons remplacé les déductions par des données concrètes, les deux groupes se sont immédiatement séparés.

Cet écart prouve que le classificateur décrit un phénomène réel, plutôt que de qualifier de robots les visiteurs peu actifs.

Ce qui trahit réellement une flotte

L’agent utilisateur est le pire endroit où chercher, car c’est l’élément le moins coûteux à modifier. Le meilleur signal s’est révélé être la carte graphique.

Les navigateurs headless d’un centre de données n’ont pas de GPU. Ils se rabattent donc sur le rendu logiciel, et WebGL fournit sans hésiter la chaîne identifiant le moteur de rendu. SwiftShader, llvmpipe, Mesa OffScreen. Les vrais visiteurs ont de vrais GPU.

L’origine réseau nous a moins aidés qu’on pourrait le penser. Environ quatre sessions sur dix sortent par de véritables FAI grand public. Les proxys résidentiels ne coûtent plus cher, et toute règle supposant que les bots viennent d’AWS en manquera près de la moitié.

Les autres indices venaient d’impossibilités physiques dans les informations déclarées par le client. L’agent utilisateur de Chromium se termine toujours par un jeton Safari correspondant à son jeton AppleWebKit, figé à 537.36 depuis 2013, mais cette flotte produisait des fautes : Safari/537.35 et .38. Un agent utilisateur de téléphone revendiquait un écran de 1600x1200. Une autre variante déclarait un carré parfait de 1600x1600. Une autre encore indiquait 1200x3000, soit un écran d’ordinateur en mode portrait au format 2,5:1 que personne ne fabrique.

Chacune de ces configurations vient de l’émulateur de quelqu’un, et aucune n’apparaît si vous ne la cherchez pas.

La flotte s’est adaptée chaque fois que nous l’avons signalée

Le premier profil utilisait Chrome sous Linux, un référent Google, America/New_York et une résolution de 1920x1080. Nous avons écrit une règle.

Une variante est revenue en 800x600 sur UTC. Nous avons élargi la règle.

Puis une cohorte chinoise est apparue, utilisant des adresses résidentielles de China Mobile et Unicom avec des versions de navigateur figées, dont Chrome 99 de mars 2022 et la configuration d’émulation d’appareil par défaut de Chrome DevTools : un Nexus 5 de 2015 exécutant la version 2018 de WeChat. Ces sessions sortent par des FAI grand public, si bien que toutes nos règles réseau étaient inutiles contre elles.

Puis une variante américaine est apparue sur Cox et Comcast, avec un agent utilisateur Chrome 146 actuel et parfaitement plausible, en 1920x1080. Rien dans cette empreinte n’est incorrect et, prise individuellement, chaque session est impossible à distinguer de celle d’un vrai visiteur.

Notre dernier détecteur n’examine donc pas les sessions individuellement. Il regroupe les 48 heures précédentes par pays, agent utilisateur, taille d’écran et source de trafic, puis recherche des groupes d’au moins 20 sessions anonymes dont 95 % ou plus n’ont jamais lu pendant trois secondes ni fait défiler la page d’un seul pixel.

Les vrais visiteurs ne forment pas des groupes aussi homogènes. Vingt inconnus utilisant un navigateur et une résolution identiques, qui repartent tous sans rien lire, sont une seule machine dotée de vingt adresses. Toute personne du groupe qui a lu ou fait défiler la page reste considérée comme humaine, et les sessions associées à un vrai compte ne sont jamais signalées.

L’audit a aussi révélé l’erreur inverse

En retirant les faux visiteurs de nos chiffres, nous avons découvert de vrais visiteurs que nous avions écartés.

Une fois les temps de lecture réels obtenus, il s’est avéré que 34,2 % de ce que nous avions compté comme des rebonds humains correspondait à des personnes ayant lu pendant au moins 30 secondes ou fait défiler plus de la moitié de la page. Un tiers de ces « échecs » signifiait en réalité que le contenu fonctionnait. Des lecteurs chinois arrivant depuis Bing passaient cinq minutes sur un seul guide et étaient enregistrés comme des rebonds.

Les chiffres étaient faussés simultanément dans les deux sens, et les deux erreurs conduisaient à la même conclusion erronée. Ensemble, elles donnent l’impression que votre trafic est important et superficiel, alors qu’il est en réalité plus faible et plus engagé.

Le canal que nous avons payé était le plus fiable

30 derniers jours. Le trafic organique Google représentait 63,7 % de toutes les sessions pendant cette période.

Tous les réflexes liés à la croissance vont dans l’autre sens. On suppose que le trafic payant est celui où l’on se fait escroquer, et que le trafic organique est celui que l’on a mérité. Chez nous, c’était l’inverse.

Si nous avions réaffecté notre budget en fonction des chiffres de juillet, nous aurions retiré de l’argent au canal qui nous apportait réellement des humains pour produire davantage de contenu destiné à un scraper.

Pourquoi cela mérite un après-midi

Le chiffre lui-même n’est qu’un chiffre. Mais en aval, il détermine les prochaines pages que nous écrivons, les langues dans lesquelles nous investissons, la survie d’une campagne lors de son évaluation et si le trimestre paraît suffisamment bon pour continuer de la même manière. Tout cela peut être influencé par un inconnu disposant d’un parc de proxys bon marché.

Si vous gérez un petit site, examinez les chaînes identifiant vos moteurs de rendu GPU et vos balises de sortie avant de vous fier à votre propre courbe de croissance.

Et considérez nos chiffres comme un plancher plutôt que comme un verdict. Ici, « humain » signifie seulement « pas encore détecté » ; les règles ont été écrites à partir des empreintes que nous avons eu l’occasion d’observer, et nous ignorons toujours qui exploite cette flotte ou ce qu’elle cherche sur un site de création de jeux.

À lire également :

• Le piège des coûts fixes — un autre chiffre derrière lequel il s’est avéré qu’il n’y avait aucun amortisseur
• Pourquoi nous avons créé notre propre moteur WebGPU — le même argument en faveur de la maîtrise de la couche dont vous dépendez
• Guides — le contenu que cet audit était censé mesurer

Par Oleg Sidorkin, directeur technique de Cinevva

Le 25 juin, Tim Sweeney, PDG d’Epic, a qualifié l’obligation de divulguer l’usage de l’IA imposée par Valve sur Steam de « vraiment irresponsable ». Son argument était sans détour. Il faut sortir son jeu sur Steam pour que les gens puissent l’ajouter à leur liste de souhaits et, dès cet instant, « votre produit se retrouve marqué de cette lettre écarlate de l’IA, et une communauté de détracteurs cherche alors à tuer le jeu ». Sa conclusion : cette étiquette rend « beaucoup, beaucoup, beaucoup plus difficile pour un développeur de jeux d’avoir une chance de réussir ».

Le plus dérangeant, c’est que les données confirment cette crainte. Selon Game Oracle, les titres portant la mention d’utilisation d’IA générative ont reçu 53 % d’avis en moins que des jeux comparables qui ne l’affichaient pas. Les avis alimentent le moteur de recommandation, si bien que l’écart se creuse de lui-même. Moins d’avis signifie moins de visibilité, donc moins de joueurs, puis encore moins d’avis.

La contradiction que personne ne nomme

Voilà ce qui en fait le sujet du mois plutôt qu’une simple querelle. Sweeney a tenu ces propos huit jours après que sa propre entreprise a lancé l’initiative la plus ouvertement favorable à l’IA de toute l’histoire des moteurs de jeu. Lors du State of Unreal du 17 juin, Epic a dévoilé Unreal Engine 6 et publié la version 5.8 avec une prise en charge expérimentale des serveurs MCP, grâce à un plugin qui connecte directement à l’éditeur des LLM comme Claude et Gemini. La même personne dirige donc le plus grand moteur de jeu, lancé dans une course pour placer l’IA au cœur de la création, tout en attaquant la plus grande plateforme de vente parce qu’elle signale que l’IA a servi à concevoir ces jeux.

On peut parler d’hypocrisie, mais cette situation montre précisément où se trouve la tension. L’IA est la bienvenue au niveau des outils, où elle fait gagner du temps aux développeurs sans que personne en dehors du studio ne la voie jamais. Elle est sanctionnée au moment de la publication, lorsque la plateforme appose une étiquette et que la foule décide de sa signification. Même technologie, traitement opposé, et la frontière entre les deux correspond exactement au seuil de la plateforme de vente.

La solution de Sweeney vise la mauvaise cible

Sa proposition consiste à supprimer l’étiquette. C’est s’attaquer au symptôme. L’étiquette n’est fatale que parce que Steam constitue un point de passage unique que franchissent quelques milliers de jeux chaque mois, où la mention « créé avec l’IA » devient un point de ralliement pour une foule qui bombarde les jeux d’avis négatifs et un signal que l’algorithme de recommandation prend discrètement en compte. Retirez l’étiquette, et la plateforme, la foule ainsi que l’algorithme demeurent. La sanction se déplace simplement vers un endroit où elle est plus difficile à mesurer.

La divulgation n’est pas le piège. Le goulet d’étranglement, si. Toute plateforme assez puissante pour donner de l’importance à une liste de souhaits l’est aussi suffisamment pour qu’une seule étiquette décide du sort d’un lancement. Les développeurs qui ont bâti toute leur distribution autour de ce point de passage découvrent qu’il a ses propres opinions.

Le navigateur ne distribue pas de lettres écarlates

Un jeu accessible par un lien n’a ni formulaire de divulgation, ni étiquette, ni foule réunie sur une même plateforme pour le classer comme « vrai jeu » ou « bouillie générée par l’IA » avant même que quiconque y joue. Le jugement a lieu là où il devrait : dans les trente premières secondes de jeu, et non dans un champ de métadonnées lu par l’algorithme avant même le chargement du jeu.

Soyons clairs sur ce que cela résout ou non : ceux qui détestent l’art généré par l’IA le détesteront toujours dans un onglet de navigateur. Le sentiment voyage. Ce qui ne voyage pas, c’est l’étiquette institutionnelle qui transforme ce sentiment en règle de tri, la case que lit un algorithme et autour de laquelle se coordonne une foule qui bombarde les jeux d’avis négatifs avant même que quiconque n’appuie sur « Jouer ». Supprimez-la, et la question se réduit de nouveau à la seule qui ait jamais été légitime : est-ce amusant ? Un jeu sur navigateur gagne son public de la même façon, que ses arbres aient été dessinés par un humain ou un modèle. C’est toute la différence entre une distribution que vous louez et une distribution que vous possédez.

Ce que cela signifie si vous créez un jeu

Sweeney a raison : la sanction liée à la divulgation est réelle et influencera les jeux qui seront créés. Il a tort de croire que la solution consiste à négocier la disparition de l’étiquette sur la plus grande plateforme de vente au monde. Ce combat ne se gagne pas : il ne reste qu’à attendre la prochaine politique. La bonne stratégie consiste à ne plus avoir besoin du point de passage qui imprime l’étiquette.

C’est exactement dans cette optique que nous avons conçu Cinevva. Des jeux créés et joués dans le navigateur, partagés au moyen d’un lien et jugés sur leur capacité à être amusants, non sur la manière dont ils ont été conçus. Les studios qui se battent à propos de l’étiquette IA se disputent de la place dans les rayons d’un magasin. Le pari le plus intéressant, c’est que ce magasin cesse d’être le seul à disposer de rayons. Lorsque votre jeu s’ouvre dans un onglet de navigateur, la lettre écarlate n’a plus aucun endroit où s’accrocher.

À lire aussi :

• Le partage 52/52 — l’adoption par les entreprises et le rejet par les développeurs atteignent le même chiffre, notamment à cause des règles des plateformes de vente
• Tout le monde veut désormais devenir le moteur de jeu de l’IA — la ruée vers la couche d’outillage qu’Unreal Engine 6 vient encore d’intensifier
• Les moteurs nativement conçus pour l’IA arrivent sur le marché — en mars, le MCP dans l’éditeur était encore une idée de startup ; il est désormais intégré à Unreal
• Pour les créateurs de jeux — publiez des jeux jouables accessibles par un lien, sans plateforme intermédiaire ni étiquette de divulgation

Par Oleg Sidorkin, CTO de Cinevva

Bungie vient de mettre fin au développement actif de Destiny 2 après neuf ans, avec des licenciements à la clé, et a réaffecté ses équipes à Marathon, un jeu qui a perdu plus de la moitié de ses joueurs simultanés au cours de son premier mois. Quelques semaines plus tôt, OpenAI avait fermé Sora après avoir englouti environ un million de dollars par jour pour seulement deux millions de dollars de chiffre d'affaires cumulé. Tout au long du printemps, les studios ont réduit leurs effectifs les uns après les autres. Il est facile de classer ces événements sous différentes rubriques : lassitude envers les jeux service, battage médiatique autour de l'IA, ralentissement économique. C'est pourtant le même échec sous trois déguisements.

Trois effondrements, une même structure

Chaque histoire repose sur la même ossature. Un projet très coûteux entraîne des coûts fixes très élevés. Le public se détourne. La structure de coûts, elle, ne peut pas suivre. Destiny 2 avait besoin de centaines de personnes produisant sans cesse du contenu, simplement pour maintenir sa position. Les coûts de Sora augmentaient avec chaque vidéo générée : sa popularité aggravait donc les pertes au lieu de les réduire. Un studio de 300 personnes travaillant sur un seul titre phare doit payer des salaires, que ce projet se porte bien ou non. Lorsque les revenus évoluent mais que les coûts ne peuvent pas s'adapter, le seul levier restant consiste à réduire les effectifs. Voilà pourquoi toutes ces histoires se terminent par des licenciements.

Le problème n'a jamais été le produit

L'erreur de Bungie n'est pas que Destiny 2 ait échoué. Le jeu a vécu pendant neuf ans et conquis un public fidèle. L'erreur a été de n'avoir pour seul successeur qu'un autre jeu service au budget à neuf chiffres. Quand Marathon a vacillé, aucun projet plus modeste ne pouvait prendre le relais. Sora n'était pas une mauvaise démo. C'était un modèle véritablement impressionnant, greffé sur un moteur économique qui sanctionnait son propre succès. Dans les deux cas, ce qui a été livré fonctionnait. Ce qui ne fonctionnait pas, c'était l'ampleur du pari derrière le produit. Un studio qui mise tout sur un titre gigantesque ne dispose d'aucun amortisseur. Le premier mauvais trimestre devient aussi le dernier.

La seule véritable défense, c'est un échec peu coûteux

Voici ce que les gros titres passent sous silence. Les studios et les outils qui survivent aux ralentissements ne sont pas ceux qui choisissent plus souvent les bons projets. Personne ne sait identifier les gagnants de façon fiable. Ce sont ceux pour qui un échec ne signifie pas la fin de l'entreprise. Si un jeu demande quelques semaines à une petite équipe, plutôt que plusieurs années à quelques centaines de personnes, un flop n'est qu'un mardi, pas un enterrement. Le calcul qui vient de mettre fin au développement de Destiny 2 suppose que chaque pari est colossal et que chaque perte est donc fatale. Réduisez suffisamment le coût d'une tentative et la logique s'inverse. Vous pouvez vous tromper la plupart du temps, ce qui est la seule manière honnête d'avoir parfois raison.

C'est pourquoi le piège des coûts fixes est structurel : ce n'est pas un problème propre à Bungie ou à OpenAI. Tout modèle qui exige des centaines de personnes, ou une puissance de calcul dont le coût augmente avec l'utilisation plus vite que les revenus, est fragile par nature. Il paraît solide jusqu'au moment où le public se déplace, et le public finit toujours par se déplacer.

Ce que cela signifie pour les créateurs

L'avenir n'est pas fait de jeux moins nombreux et plus imposants, portés par des équipes de mille personnes. Il repose sur bien davantage de jeux créés par de petites équipes et des individus, où tenter quelque chose ne coûte presque rien. Ce n'est pas de l'optimisme, c'est la direction indiquée par l'économie. Le public qui a quitté Destiny n'a pas disparu. Il s'est fragmenté entre des dizaines de jeux, et la prochaine vague qui saura le conquérir sera moins chère à produire, plus rapide à publier et plus facile à améliorer qu'un monolithe développé pendant dix ans.

C'est le pari que nous concrétisons chez Cinevva. Des jeux créés et joués dans le navigateur, où le coût d'une tentative est suffisamment faible pour qu'un échec n'emporte pas tout le studio avec lui. Les mécanismes économiques qui viennent de mettre fin au développement de Destiny 2 sont précisément ceux que notre plateforme a été conçue pour contourner. Les géants découvrent à leurs dépens que la taille sans amortisseur n'est qu'une exposition accrue au risque. Ceux qui l'intègrent les premiers pourront continuer à créer pendant le ralentissement, au lieu d'en être les victimes.

À lire également :

• Bungie met fin au développement de Destiny 2 — l'abandon, les licenciements et le pari Marathon
• Sora n'est plus — un million de dollars par jour pour deux millions de chiffre d'affaires cumulé
• Les licenciements dans l'industrie du jeu se poursuivent en mars 2026 — la contraction générale du secteur
• Les décombres des géants — l'occasion qui s'offre aux indépendants après l'effondrement
• Pour les créateurs de jeux — publiez des jeux jouables, accédez à la cagnotte des abonnements et recevez des rémunérations fondées sur le temps de jeu

Par Mariana Muntean, CEO de Cinevva

Chaque article sur la fin d’un jeu est écrit comme le récit d’une tragédie, et pour les personnes qui perdent leur emploi, c’en est une. Mais derrière se cache une seconde histoire, celle qui ne fait l’objet d’aucun communiqué de presse. Lorsque Bungie met fin au développement actif de Destiny 2, le studio ne se contente pas de supprimer une équipe. Il libère un public. Des millions de joueurs qui organisaient leurs soirées autour d’un seul jeu cherchent peu à peu le suivant. Ce n’est pas une perte pour le jeu vidéo. C’est une redistribution, et les petites équipes peuvent en capter une part plus importante qu’elles ne l’imaginent.

La fin d’un jeu est une migration

Lorsqu’un jeu-service arrive en fin de vie, ses joueurs n’arrêtent pas de jouer. Ils arrêtent de jouer à ce jeu. La communauté de Destiny n’a pas perdu l’envie de jouer entre amis. Elle a perdu la raison de continuer à le faire dans un lieu précis. Le même phénomène a suivi toutes les grandes fermetures précédentes. Le public se disperse vers ce qui semble nouveau, social et vivant. Pendant une décennie, les géants ont rassemblé ces joueurs dans une même pièce. Désormais, les portes s’ouvrent et les joueurs sont de nouveau disponibles.

Les joueurs en quête d’un nouveau foyer sont le public le moins coûteux à atteindre

Le plus difficile dans le jeu vidéo n’est pas d’en créer un. C’est d’amener quelqu’un à l’essayer. Pour la plupart des petits studios, l’attention est le poste de dépense le plus coûteux. Pendant une courte période, un joueur qui quitte un jeu-service en fin de vie recherche activement son prochain jeu. Il dispose du temps qu’il y consacrait auparavant, d’un groupe d’amis cherchant ensemble un nouveau foyer et n’est plus fidèle à aucun jeu. C’est la combinaison la plus rare du secteur : des joueurs motivés, disponibles et qui arrivent en groupe. Vous n’avez pas à les arracher à quoi que ce soit. Le géant les a déjà laissés partir.

Ce que les géants ne peuvent plus faire

Voilà toute l’asymétrie. Un studio de mille personnes ne peut pas courir après un public fragmenté. Sa structure de coûts, le piège des coûts fixes dont nous avons parlé, ne fonctionne que s’il décroche un succès colossal. Douze jeux atypiques destinés à douze niches ne permettent pas de financer une masse salariale de cette ampleur. Ainsi, le moment précis où le public se fragmente est aussi celui où les géants sont le moins capables de répondre à ses attentes. C’est dans cette brèche que s’engouffrent les indépendants. Les petites équipes peuvent créer les jeux singuliers, ciblés et sociaux qu’une fraction de ce public recherche réellement, à un coût pour lequel une niche est largement suffisante.

Comment être présent à leur arrivée

Être dans les décombres au bon moment n’est pas une question de chance, mais de positionnement. Cela implique de sortir régulièrement des jeux plutôt que de tout miser sur un seul lancement. Cela signifie créer des jeux à un coût suffisamment bas pour en avoir un de prêt lorsque la migration commence, et non dix-huit mois après sa fin. Cela veut dire aller à la rencontre de ces joueurs là où ils se trouvent déjà, dans un onglet de navigateur, avec un jeu auquel ils peuvent accéder en un clic et inviter leurs amis.

C’est ce que nous construisons chez Cinevva. Un espace où les petites équipes publient rapidement des jeux jouables, se font découvrir grâce à des reels plutôt qu’à un budget publicitaire, et gagnent de l’argent grâce au temps de jeu plutôt qu’à un pic au lancement. Les géants enseignent à l’ensemble du secteur que la démesure est fragile. Le revers de cette leçon, c’est que leur public est à prendre, et que les mieux placés pour le capter sont ceux qui n’ont jamais eu besoin qu’il soit immense.

À lire également :

• Le piège des coûts fixes — pourquoi les géants sont fragiles dès le départ
• Bungie met fin au développement de Destiny 2 — neuf ans de public, de nouveau disponible
• Les licenciements dans l’industrie du jeu vidéo se poursuivent en mars 2026 — l’ampleur de la contraction
• Pour les créateurs de jeux — découverte par les reels, fonds d’abonnement et rémunération selon le temps de jeu

Par Oleg Sidorkin, CTO de Cinevva

Il y a deux mois, nous écrivions que le rendu dans le navigateur venait de connaître son meilleur mois, et nous pensions qu'il s'agissait d'un pic. Ce n'était pas le cas. C'était le début d'une tendance, et cette tendance va dans une direction claire. Le navigateur devient un environnement dans lequel on déploie un véritable jeu, et non plus un environnement vers lequel on porte un petit jeu.

Ce qui est arrivé depuis mars

Passons la liste en revue. Babylon.js 9 a introduit l'éclairage en clusters pour des milliers de lumières dynamiques, l'éclairage volumétrique et une refonte complète du Gaussian splatting. Three.js r184 a ajouté HTMLTexture, qui restitue un DOM interactif en direct sous forme de texture sur une surface 3D. PlayCanvas v2.17 a apporté le Gaussian splatting piloté par le GPU sur WebGPU, avec des harmoniques sphériques en f16 ainsi qu'un tri et une élimination hors champ effectués par le GPU. La version bêta de Godot 4.7 a ajouté des exports web wasm64 qui lèvent l'ancienne limite de mémoire de 4 Go, ainsi qu'une véritable sortie HDR et des lumières surfaciques. Chrome 146 a introduit un mode de compatibilité WebGPU fonctionnant sur OpenGL ES 3.1 et Direct3D 11, tandis que WebGPU lui-même a atteint le statut de recommandation candidate du W3C. N'importe laquelle de ces avancées aurait suffi à rendre un trimestre remarquable. Elles sont toutes arrivées en huit semaines environ.

« Suffisant pour une démo » est devenu « suffisant pour être déployé »

Les fonctionnalités qui viennent d'arriver ne sont pas des gadgets. L'éclairage en clusters permet d'éclairer une scène avec des milliers de lumières dynamiques sans faire s'effondrer la fréquence d'images. Le Gaussian splatting permet d'intégrer dans un jeu des environnements photoréalistes capturés, tout en conservant une fréquence d'images interactive. Le tri et l'élimination hors champ pilotés par le GPU font la différence entre une démo technique qui saccade et un jeu qui tient les 60 images par seconde. Ce sont les techniques qu'utilisent les moteurs natifs pour livrer des jeux AAA, et elles fonctionnent désormais dans un onglet. Le travail sur le mode de compatibilité est tout aussi important dans l'autre sens. Il permet à WebGPU de prendre en charge le matériel bon marché et plus ancien que possèdent réellement la plupart des joueurs, et pas seulement les machines de développement équipées d'un GPU haut de gamme.

C'est sur cette base que nous construisons, à la main

Nous ne tirons pas ces conclusions d'un communiqué de presse. Ces derniers temps, nous avons construit un monde ouvert fonctionnant dans le navigateur au fil de plus de soixante expérimentations exploratoires, depuis de premières versions rudimentaires du terrain jusqu'aux marching cubes sur GPU et au LOD en streaming. Nous avons retracé ce parcours dans une série complète et dans un article plus approfondi sur la méthodologie. Presque toutes les fonctionnalités ci-dessus correspondent à un problème auquel nous nous sommes confrontés de plein fouet. Quand l'éclairage en clusters arrive dans un moteur web grand public, c'est une partie de notre propre code que nous pouvons supprimer.

L'objection est morte, mais pas l'habitude

« On ne peut pas créer un vrai jeu dans un navigateur » a longtemps été vrai, puis a cessé de l'être pendant que l'essentiel de l'industrie regardait ailleurs, du côté de l'IA. Le plafond technique qui justifiait de déployer d'abord un client natif et de remettre une éventuelle version web à jamais a disparu. Il ne reste que l'habitude. Les moteurs, les studios et les chaînes d'outils reposent encore sur l'idée que le navigateur est une cible secondaire.

Cette idée reçue représente l'opportunité. Nous avons construit Cinevva en pariant que le navigateur deviendrait l'environnement par défaut pour déployer et découvrir des jeux, plutôt qu'une solution de repli. Ces deux derniers mois, la pile de rendu vient de donner raison à ce pari. Les studios qui feront évoluer leur vision en premier bénéficieront d'un canal de distribution sans aucune friction d'installation, avec un public à un clic de distance. Ceux qui attendront finiront par y porter leurs jeux, une fois que tous les autres y seront déjà installés.

À lire également :

• Le rendu dans le navigateur vient de connaître son meilleur mois — le pic que nous pensions exceptionnel
• Sortie de Babylon.js 9 — éclairage en clusters et Gaussian splatting
• Three.js r184 introduit HTMLTexture — le DOM en direct comme surface 3D
• PlayCanvas v2.17 ajoute le Gaussian splatting piloté par le GPU — le splatting WebGPU à grande échelle
• Godot 4.7 bêta — sortie HDR, lumières surfaciques et exports web wasm64
• Chrome 146 ajoute un mode de compatibilité WebGPU — WebGPU pour les GPU plus anciens
• Ce qu'il faut pour construire un monde ouvert dans un navigateur — notre propre parcours

Par Mariana Muntean, CEO de Cinevva

L’enquête State of the Game Industry de la GDC pour 2026 a mis en avant deux chiffres identiques. 52 % des entreprises de jeux vidéo déclarent utiliser l’IA générative en production et, dans le même temps, 52 % des développeurs estiment que l’IA générative a un impact négatif sur le secteur. Même pourcentage, lecture opposée de l’avenir.

Derrière cette symétrie se cache une autre fracture dont on parle moins. Seuls 36 % des répondants ont déclaré utiliser personnellement l’IA générative, alors que son adoption à l’échelle des entreprises est plus élevée. Les directions achètent des outils que de nombreux développeurs n’utilisent jamais. Cet écart indique où se situe le véritable débat. Il ne porte pas uniquement sur l’éthique. Il concerne aussi le contrôle du pipeline et la question de savoir si la personne devant le clavier pense que l’IA peut réellement faire son travail.

Le confort du travail manuel

Nombre de développeurs qui évitent l’IA ne sont pas naïfs. Leur raisonnement ressemble à ceci : mon travail est une succession de problèmes difficiles qui ne peuvent pas être réduits à un prompt dans un chatbot. Un concept original doit résister à l’épreuve de la modélisation. Un modèle doit résister au rigging. Le rigging doit résister à l’animation. L’animation doit résister aux sensations de jeu et à la conception des systèmes. À chaque passage de relais, le goût et les contraintes comptent. Un LLM capable d’écrire un paragraphe correct sur un personnage n’est pas la même chose qu’un maillage qui se déforme correctement, un rig contre lequel l’animateur n’aura pas à lutter, ou des mécaniques qui paraissent intentionnelles plutôt que brouillonnes.

Ce constat n’est pas faux au regard du fonctionnement actuel de la plupart des outils. Les modèles généralistes excellent dans les tâches isolées. Ils peinent à maintenir un même fil créatif entre plusieurs disciplines sans que vous deviez assembler les morceaux. Le sentiment d’être « à l’abri » en ne recourant pas à l’IA est donc en partie technique. Si votre travail consiste à faire le lien entre l’art conceptuel, la topologie, les poids de skinning, les machines à états et le langage de caméra, il est facile de croire que l’automatisation restera cantonnée aux tâches superficielles pendant des années.

Steam et les autres acteurs continuent de fixer des limites

Le même réflexe apparaît du côté de la distribution. Steam ne bloque pas systématiquement les jeux qui utilisent l’IA générative. Valve exige toutefois une divulgation claire lorsque du contenu créé par l’IA est proposé aux joueurs, avec un contrôle renforcé si le jeu génère du contenu en direct lors de son exécution. Les fiches doivent également respecter les règles relatives aux droits et à la sécurité. Ce n’est pas la même chose qu’un problème de topologie de maillage, mais c’est une raison supplémentaire pour laquelle les équipes considèrent l’IA comme risquée. Une grande boutique de jeux PC a transformé la question « pouvons-nous créer ceci ? » en « pouvons-nous le publier ici sans bataille autour d’un label ni mauvaise surprise lors de l’examen ? ».

D’autres gardiens sont allés plus loin. Games Workshop a interdit les créations générées par l’IA dans l’ensemble des propriétés Warhammer. Les Indie Game Awards ont retiré une nomination majeure en raison de l’utilisation de l’IA pendant le développement, même lorsque des fans affirmaient que le jeu publié n’en contenait pas. Des modérateurs de communautés ont démissionné à cause d’éléments de bande-annonce semblant avoir été créés par l’IA. Tim Sweeney d’Epic et Valve ont débattu publiquement de la question de savoir si les labels à la manière de Steam sont utiles ou nuisibles. L’important n’est pas de déterminer quel dirigeant a raison. L’important, c’est que les distributeurs et les détenteurs de propriété intellectuelle adoptent des positions divergentes. Un développeur qui reste entièrement manuel simplifie toute une dimension de ce conflit. L’absence de ressources génératives dans la version destinée aux joueurs signifie moins de choses à déclarer et à défendre lorsqu’un forum décide que votre illustration principale semble synthétique.

Nous avons approfondi les questions de confiance et d’étiquetage dans Controverse sur l’IA, confiance et économie post-IA, et nous expliquons en détail comment nous gérons les labels sur Cinevva dans notre Politique relative au contenu généré par l’IA.

Pourquoi cette sécurité est fragile

La même enquête montre que l’opinion évolue rapidement. Les avis globalement positifs sur l’impact de l’IA dans le secteur ont reculé. Les avis négatifs ont progressé. Les chiffres des licenciements et le soutien aux syndicats montrent que les gens ne sont pas sereins. Le tableau psychologique se divise donc à nouveau. Certains développeurs se sentent protégés parce que l’ensemble de la chaîne reste difficile à maîtriser. D’autres se sentent menacés parce que les studios investissent malgré tout dans l’efficacité, avec ou sans leur consentement.

Ces deux groupes ne parlent pas toujours de la même couche de la chaîne de production. Les dirigeants demandent souvent : « pouvons-nous produire davantage avec moins de ressources pour cette étape clé ? » Les artistes et les concepteurs demandent souvent : « ma spécialité existera-t-elle encore ? » Ces deux questions sont légitimes. La première favorise l’automatisation partielle. La seconde pénalise quiconque a supposé que sa partie du pipeline était trop spécifique pour être touchée.

Ce qui changerait réellement la donne

Si le secteur passe de générateurs ponctuels à des workflows connectés, dans lesquels un concept, un rig et une boucle jouable partagent un même contexte, l’argument « je suis à l’abri parce que mon travail est trop personnalisé » perd de sa portée. Non pas parce que le goût disparaît, mais parce que les fastidieuses jonctions entre les étapes cessent d’engloutir la moitié du calendrier. La menace qui pèse sur les workflows entièrement manuels ne vient pas d’un modèle unique capable de tout faire. Elle vient de la réduction du nombre de ruptures.

C’est dans cette direction que nous avançons chez Cinevva. Une création assistée par l’IA dans le navigateur, des outils qui s’alimentent mutuellement et un parcours menant d’un projet en cours à quelque chose que les joueurs peuvent réellement lancer et découvrir. Non pas pour permettre aux dirigeants de remplacer des équipes dans une feuille de calcul, mais pour qu’un petit groupe ou un développeur solo puisse maîtriser toute la chaîne, de l’idée au jeu publié, sans prétendre qu’un seul prompt remplace un artiste principal.

Les 52 % qui utilisent l’IA et les 52 % qui redoutent ses effets sur le secteur réagissent tous à des signaux réels. Les développeurs qui se sentent aujourd’hui en sécurité en se passant de l’IA avancent un argument solide fondé sur la complexité. La question reste de savoir combien de temps cet argument demeurera valable si la chaîne d’outils cesse de se rompre à chaque frontière entre disciplines.

À lire également :

• La GDC 2026 en chiffres — fréquentation, parts de marché des moteurs et fracture autour de l’IA
• Tout le monde veut désormais devenir le moteur de jeu de l’IA — la course aux plateformes derrière l’adoption
• L’open source a un problème de pollution par l’IA — le coût caché de la génération bon marché par l’IA
• Controverse sur l’IA, confiance et économie post-IA — chiffres de Steam, réactions des studios et confiance
• Politique relative au contenu généré par l’IA — la gestion des déclarations et des filtres par Cinevva
• Le vibe coding est la nouvelle game jam — quand l’expérimentation devient peu coûteuse
• Pour les créateurs de jeux — publiez des jeux jouables, accédez à la cagnotte des abonnements et recevez des paiements fondés sur le temps de jeu

Par Oleg Sidorkin, directeur technique de Cinevva

Pendant que l’industrie du jeu vidéo passait le mois de mars à débattre de l’IA à la GDC, la pile de rendu des navigateurs a accompli en quatre semaines l’équivalent de cinq années de progrès. Personne n’a organisé de conférence de presse. Personne n’a publié de prise de position provocatrice. Cinq événements distincts se sont produits et, ensemble, ils ont changé la définition même du « jeu dans le navigateur ».

Babylon.js fait progresser le rendu dans le navigateur depuis des années. La version 9.0 marque son plus grand bond en avant à ce jour.

Ce qui est sorti en mars 2026

Babylon.js 9.0 est sorti avec l’éclairage en clusters, une technique de rendu qui permet de gérer des centaines de lumières dynamiques dans une scène sans sacrifier les performances. Jusqu’à présent, cette fonctionnalité était réservée aux moteurs AAA. Cette version comprend également un éclairage volumétrique avec une diffusion réaliste de la lumière, des lumières surfaciques texturées pour créer des effets tels que des vitraux et des écrans LED, ainsi qu’un éditeur de particules basé sur des nœuds. Le tout fonctionne aussi bien avec WebGPU qu’avec WebGL 2.

PlayCanvas v2.17 a introduit le tri du splatting gaussien piloté par le GPU sur WebGPU. Le splatting gaussien, cette technique qui transforme des captures photogrammétriques en scènes 3D en temps réel, n’était encore qu’un article de recherche il y a deux ans. Il fonctionne désormais dans un moteur de navigateur avec une accélération GPU pour la passe de tri.

Three.js r183 a renommé son module PostProcessing en RenderPipeline. Cela peut sembler n’être qu’une modification mineure de l’API, mais le choix des termes compte. Le « post-traitement » est quelque chose que l’on ajoute à un projet amateur. Un « pipeline de rendu » est une infrastructure de production. L’équipe de Three.js signale ainsi que la bibliothèque est prête pour des architectures de rendu sérieuses et structurées.

Chrome 146 a ajouté le mode de compatibilité WebGPU, ce qui signifie que les anciens GPU ne prenant pas en charge l’ensemble complet des fonctionnalités de WebGPU peuvent désormais l’utiliser via un mode aux capacités réduites. La base d’appareils compatibles avec WebGPU vient de s’élargir considérablement.

Le W3C a publié WebGPU sous la forme d’un projet de recommandation candidate. Il s’agit de l’étape formelle précédant son adoption comme standard officiel du Web. WebGPU n’est plus expérimental. Il est désormais en voie de standardisation.

Pourquoi ce mois est différent

Chacune de ces sorties aurait été remarquable à elle seule. Le fait que les cinq aient eu lieu au cours du même mois crée un effet cumulatif.

Il y a cinq ans, un « jeu dans le navigateur » désignait un jeu casual en 2D, éventuellement agrémenté de quelques effets Canvas si vous étiez ambitieux. Il y a trois ans, il était possible de créer de la 3D basique au prix d’une optimisation minutieuse. Il y a un an, WebGPU a commencé à arriver dans les navigateurs en production et les possibilités ont commencé à s’étendre.

Mais mars 2026 marque le moment où l’écart entre le rendu natif et celui des navigateurs est passé de « considérable » à « se réduit rapidement ». L’éclairage en clusters nécessitait Unreal ou Unity. Le splatting gaussien nécessitait un laboratoire de recherche. Les pipelines de post-traitement de qualité professionnelle nécessitaient un moteur sur mesure. Ces trois technologies sont désormais disponibles dans des moteurs de navigateur open source que n’importe qui peut installer avec npm.

Three.js Water Pro fonctionnant sur WebGPU. Ceci est un navigateur.

Ce qui va se passer ensuite, selon moi

Depuis le début, Cinevva mise sur une distribution des jeux pensée en priorité pour le navigateur. Notre conviction a toujours été que l’écart en matière de rendu finirait par se combler, car la plateforme Web évolue plus rapidement que les moteurs natifs. WebGPU a pris plus de temps que je ne le pensais, mais cette convergence se produit désormais comme prévu.

L’effet concret concerne la distribution. Un jeu qui fonctionne dans un navigateur ne nécessite ni téléchargement, ni installation, ni processus d’approbation par une plateforme. Il se charge depuis une URL. Cela a toujours été l’avantage du navigateur, mais il n’a d’importance que lorsque la qualité du rendu est suffisamment bonne pour que les développeurs le choisissent réellement.

Nous avons désormais franchi ce seuil. Pas pour tous les jeux. Pas pour les jeux AAA en monde ouvert avec ray tracing. Mais pour une catégorie de jeux de plus en plus vaste comprenant de la 3D en temps réel, un éclairage dynamique, des systèmes de particules et des ressources photogrammétriques, le navigateur constitue une cible viable. Et contrairement aux plateformes natives, aucune commission de 30 % ne vous attend à l’arrivée.

La question n’a jamais été de savoir « si les navigateurs rattraperaient leur retard », mais « quand ». Mars 2026 a apporté la réponse.

À lire également :

• Babylon.js 9.0 : éclairage en clusters et splatting gaussien — l’analyse technique complète
• Chrome 146 introduit le mode de compatibilité WebGPU — élargissement de la base d’appareils compatibles avec WebGPU
• Le développement de jeux Web entre dans l’ère de WebGPU — comment nous en sommes arrivés là
• Comparatif des moteurs de jeux Web — Babylon.js, Three.js, PlayCanvas et les autres
• Bien démarrer avec WebGPU pour les développeurs de jeux — prise en main de la nouvelle API
• Technologies des mondes ouverts 3D dans le navigateur — l’architecture de rendu derrière les mondes dans le navigateur

Par Oleg Sidorkin, CTO de Cinevva

Trois moteurs de jeu apparus en mars présentent une architecture différente de tout ce qui appartient à la lignée Unity/Unreal/Godot. Ils n’ont pas d’éditeur visuel. Ils ne sont pas optimisés pour un humain naviguant dans des menus à coups de clics. Ils sont entièrement conçus pour permettre aux agents d’IA de lire, d’écrire et de contrôler l’état du jeu.

Ce n’est pas « Unity avec un onglet IA ». C’est une autre espèce de moteur.

L’IA transforme déjà les workflows de développement de jeux 3D. La couche moteur sera la prochaine.

Les trois moteurs

nAIVE Engine est open source, écrit en Rust et doté d’un rendu WebGPU. Son rechargement à chaud prend moins d’une seconde : moins de 200 ms pour les shaders, moins de 100 ms pour les scènes et moins de 50 ms pour les scripts. Les scènes, les pipelines et les matériaux sont définis en YAML, ce qui permet aux LLM de les lire et de les générer sans avoir à analyser de formats binaires. Il expose une interface de commande MCP qui permet aux agents d’IA de contrôler les fonctions du moteur via JSON-RPC. Il intègre nativement le Gaussian splatting et le rendu sans interface graphique pour les tests automatisés. Toute l’architecture part du principe que l’utilisateur principal peut être un agent d’IA, et non une personne munie d’une souris.

Arcane Engine est un moteur 2D axé sur le code. Son cœur est en Rust et ses scripts en TypeScript. Il n’a aucun éditeur visuel. Sa philosophie : « le code est la scène ». L’état du jeu est une base de données interrogeable plutôt qu’un arbre de scène. Il inclut un protocole intégré pour l’interaction avec les agents d’IA. Sous licence Apache 2.0.

Mirror Engine est en version alpha et privilégie le multijoueur, avec un système entité-composant. Le plus intéressant : il inclut une génération 3D par IA à partir de texte qui produit des Gaussian splats depuis des prompts textuels en environ 60 secondes. Scripts TypeScript et client « Mirror Lite » dans le navigateur.

Ces trois moteurs ne partagent ni base de code ni équipe, mais ils reposent sur la même thèse de conception : l’interface principale d’un moteur de jeu devrait être du texte structuré, et non une interface graphique.

Pourquoi cette architecture est importante

Les moteurs de jeu traditionnels ont évolué pour servir un humain assis à un bureau. Ils proposent une vue de la scène, un panneau de hiérarchie, un inspecteur et une timeline. Tout est conçu autour du clic, du glisser-déposer et du placement visuel des objets. Ce workflow est puissant. Mais il est également impossible à utiliser pour un agent d’IA.

Lorsque votre « utilisateur » principal est un LLM, vous avez besoin de primitives différentes. Du YAML plutôt que des formats de scène binaires. Un état interrogeable plutôt que des arbres de scène imbriqués. Des commandes fondées sur des protocoles plutôt que des clics de souris. Un fonctionnement sans interface graphique plutôt qu’un rendu dans une fenêtre.

C’est le même changement que celui survenu dans l’infrastructure lorsque le DevOps est passé des panneaux de contrôle graphiques à l’infrastructure en tant que code. La même chose se produit dans les moteurs de jeu, simplement vingt ans plus tard.

L’interface MCP de nAIVE en est l’exemple le plus clair. MCP (Model Context Protocol) devient le moyen standard par lequel les agents d’IA communiquent avec les outils. Lorsqu’un moteur prend nativement en charge MCP, tout agent d’IA compatible avec le protocole peut manipuler des scènes, ajuster des paramètres, exécuter des tests et itérer sur le gameplay sans intervention humaine. Ce n’est pas une fonctionnalité greffée sur un moteur traditionnel. C’est une relation fondamentalement différente entre le moteur et son utilisateur.

Le Gaussian splatting dans le développement de jeux. nAIVE et Mirror le considèrent tous deux comme une primitive de rendu de premier plan.

Vue d’ensemble

Ces trois moteurs ne sont pas le seul signal. Black Box de Meshy a fait la démonstration de mécaniques de jeu générées par IA pendant l’exécution. À la GDC, OpenAI a présenté un RPG tactique développé avec Phaser. La couche d’outils entre « l’IA génère quelque chose » et « cette chose s’exécute sous la forme d’un jeu jouable » s’amincit chaque mois.

Chez Cinevva, nous construisons ce pont depuis l’autre direction. Notre moteur gère le rendu, la physique et les interactions en temps réel, tandis que l’IA prend en charge la génération des ressources. L’approche diffère de celle de nAIVE ou d’Arcane, mais le pari sous-jacent est le même : le moteur de jeu de demain doit parler nativement le langage de l’IA, et non se contenter de l’ajouter sous forme de plugin.

Les éditeurs de moteurs traditionnels le savent eux aussi. Unity a présenté en avant-première des outils de création de jeux par IA à la GDC. Roblox a lancé la création de modèles 4D assistée par IA. Mais il existe une différence significative entre l’ajout de fonctionnalités d’IA à un moteur conçu pour les humains et la conception d’un moteur dans lequel l’IA constitue l’interface principale.

Ce qui, selon moi, va se passer ensuite

La plupart de ces moteurs ne survivront pas. C’est normal pour une nouvelle catégorie. Mais leurs principes de conception perdureront : définitions de scènes en YAML, protocoles MCP pour le contrôle par des agents, état de jeu interrogeable et fonctionnement sans interface graphique. Ces idées seront intégrées aux moteurs grand public d’ici deux ans.

Le moteur qui dominera cette nouvelle ère n’existe probablement pas encore. Mais son ADN architectural s’écrit en ce moment même, dans ces trois projets et quelques autres. La question n’est pas de savoir si les moteurs de jeu deviendront natifs pour l’IA. Elle est de savoir si cette transformation viendra des acteurs établis ou de nouveaux entrants ayant conçu leurs moteurs pour les agents dès le premier jour.

À lire également :

• Tout le monde veut désormais devenir le moteur de jeu de l’IA — la course aux plateformes qui a préparé le terrain
• Modèles d’IA générative open source de pointe — les modèles que ces moteurs intègrent
• Comparatif des moteurs de jeu web — la place des nouveaux moteurs dans l’écosystème au sens large
• L’open source a un problème de pollution par l’IA — le coût des contributions générées par l’IA

Par Oleg Sidorkin, CTO de Cinevva

Il y a deux semaines, j’écrivais que le vibe coding est la nouvelle game jam. L’idée était que les outils d’IA avaient fait disparaître la barrière entre l’idée et le prototype. Depuis, les faits ne montrent plus seulement que « les gens créent des prototypes », mais qu’« ils vendent leurs jeux ».

Ce n’est plus une jam. C’est une méthode de production.

Créer des jeux vidéo complets avec des agents d’IA. Le workflow multi-agents est le modèle qui passe à l’échelle.

Les jeux commercialisés en mars

Void Balls a été créé par BigDevSoon en 10 jours. Pas 10 jours passés à bricoler une démo. 10 jours pour créer un jeu comprenant 29 000 lignes de C# réparties dans 173 scripts, 88 fichiers de test, cinq types d’ennemis, 15 cartes de bonus et des combats de boss. Le workflow : 8 agents Claude Code en parallèle, chacun chargé d’un domaine différent. Architecture, implémentation, équilibrage du jeu, tests. Tous travaillant simultanément. Les éléments graphiques provenaient de Replicate et l’audio d’ElevenLabs.

Grumbulus a été créé par deux développeurs en deux soirées. 15 000 lignes de JavaScript natif, avec audio procédural et rendu en parallaxe, entièrement générées avec Claude Code. Aucun framework. Aucun moteur. Seulement une IA écrivant du JS standard.

CODEX MORTIS est sorti en accès anticipé sur Steam en se présentant comme le « premier jeu au monde développé à 100 % par l’IA ». Un bullet hell de survie nécromantique créé en trois mois, avec Claude Code pour les animations et les shaders, et ChatGPT pour les éléments graphiques. Du TypeScript pur avec PIXI.js et bitECS, le tout encapsulé dans Electron. La démo a attiré 10 500 joueurs, avec une durée moyenne de session de 71 minutes.

Catvivors est arrivé en accès anticipé sur Steam sous la forme d’un roguelite avec des chats, dans le style de Vampire Survivors. Son développeur solo, chercheur en IA, a créé l’ensemble du jeu avec Claude Code.

Le modèle qui compte vraiment

Chaque jeu est intéressant en soi. Le modèle reproductible l’est encore plus.

Le workflow de Void Balls mérite notre attention parce qu’il ne repose pas sur une seule personne saisissant des prompts. Il fait appel à huit agents d’IA en parallèle, chacun doté d’un rôle précis et travaillant simultanément sur la même base de code. Ce n’est pas du vibe coding. C’est du travail d’IA orchestré. L’agent d’architecture définit la structure. Les agents d’implémentation développent les fonctionnalités. L’agent d’équilibrage ajuste les courbes de difficulté. L’agent de test écrit et exécute les suites de tests. Un humain dirige huit exécutants.

C’est ce workflow qui passe à l’échelle. Non pas « demander à Claude de créer un jeu », mais « gérer une équipe d’agents Claude comme on gérerait une équipe de développeurs ». Le modèle d’agents parallèles permet de passer du prototype à un produit commercialisable en quelques jours plutôt qu’en plusieurs mois.

La chaîne complète a désormais fait ses preuves : génération de code + génération d’éléments graphiques + génération audio + moteur de jeu = produit commercialisable. Chaque couche dispose d’un outil performant. Claude Code pour la base de code. Replicate ou Midjourney pour les éléments graphiques. ElevenLabs pour l’audio. Choisissez votre moteur. L’intégration entre ces outils reste imparfaite, mais elle fonctionne.

Créer de zéro un FPS 3D en vibe coding en une heure. Sans Unity, sans Unreal, sans moteur.

Les limites réelles

Je vais parler franchement du plafond actuel, car je pense que l’engouement dépasse la réalité.

La durée moyenne de session de 71 minutes pour CODEX MORTIS est impressionnante pour une démo. Elle ne dit rien de la rétention au septième jour, ni de la volonté des joueurs de payer pour le jeu complet. Jusqu’ici, les jeux commercialisés sont principalement des roguelikes, des bullet hells et des auto-battlers. Ce sont des genres dont la variété procédurale et la profondeur mécanique proviennent de l’interaction entre les systèmes, et non de contenus conçus à la main.

Ce qui manque encore : des jeux narratifs complexes, des jeux de stratégie profonds et tout ce dont la conception des niveaux exige une intuition humaine du rythme et de l’arc émotionnel. Les genres que l’IA maîtrise bien sont ceux qui peuvent le plus facilement être systématisés. Ce n’est pas un hasard.

« Commercialisable » et « digne d’être acheté » ne signifient pas la même chose. Le niveau de qualité attendu d’un jeu gratuit sur navigateur et celui d’un jeu Steam à 15 $ ne sont pas comparables. Nous n’avons encore vu ni les données de rétention ni les chiffres d’affaires qui permettraient de déterminer si les jeux créés par l’IA peuvent faire vivre une activité durable, et pas seulement réussir leur lancement.

Ce qui va se passer ensuite, selon moi

D’autres jeux de ce type seront commercialisés. Leur qualité s’améliorera à mesure que les modèles d’IA progresseront et que les workflows multi-agents gagneront en maturité. Le premier véritable succès — un jeu principalement créé avec des outils d’IA, qui fidélise une communauté de joueurs et génère de vrais revenus — arrivera probablement avant la fin de l’année 2026.

Mais ce qui transformera l’industrie, ce n’est pas un jeu en particulier. C’est le fait que cette méthode de production existe désormais. Nous avons créé A Breaker Belt en trois jours, à deux. BigDevSoon a créé Void Balls en 10 jours, avec une personne et huit agents. Pour une catégorie croissante de jeux, le délai nécessaire pour passer de l’idée à un jeu commercialisable est passé de plusieurs années à quelques semaines.

Les studios qui devraient y prêter attention ne sont pas les géants du AAA. Ce sont les éditeurs de taille intermédiaire qui facturent 20 $ des jeux qu’un développeur solo peut désormais créer en un mois.

À lire aussi :

• Le vibe coding est la nouvelle game jam — le signal sur lequel s’appuie cet article
• A Breaker Belt : quand Snake rencontre Arkanoid, créé en vibe coding en trois jours — notre propre expérience du workflow basé sur l’IA
• Outils de programmation agentique par IA — Claude Code, Cursor et le développement multi-agents
• Game jams et hackathons — le format dont est issu le vibe coding

Par Oleg Sidorkin, CTO de Cinevva

NVIDIA a lancé le DLSS 5 à la GDC avec une promesse : une IA générative capable de reconstruire en temps réel l’éclairage, les matériaux et les ombres afin de donner aux jeux un rendu photoréaliste, sans pénaliser les performances. Puis les gens ont vu ce qu’elle faisait réellement aux visages des personnages.

Sur Internet, on a parlé de « yassification ». Grace Ashcroft, dans Resident Evil Requiem, est passée du visage émacié et marqué par les combats d’une survivante à un visage lissé et uniformisé, au point de ressembler à un autre personnage. Leon a subi le même traitement. L’IA a décidé que la direction artistique d’origine n’était pas assez bonne et l’a « corrigée ».

Présentation du DLSS 5 de NVIDIA avec Resident Evil Requiem. Les changements visuels ont immédiatement provoqué une levée de boucliers.

Ce que NVIDIA a lancé et ce que cette technologie fait réellement

Les versions 1 à 4 du DLSS étaient des technologies de mise à l’échelle. Elles effectuaient le rendu à une résolution inférieure et utilisaient l’IA pour reconstituer les pixels manquants. Les artistes les appréciaient parce qu’elles respectaient l’image source. La direction artistique restait intacte. L’IA ne faisait que rendre l’image plus nette.

Le DLSS 5 est fondamentalement différent. Il s’agit d’un système d’IA générative de vidéo à vidéo qui fonctionne sans accès aux ressources originales du jeu, à sa géométrie ni aux données de la scène. Il prend l’image 2D rendue et les vecteurs de mouvement, puis génère une nouvelle image avec un éclairage, des matériaux et des détails « améliorés ».

Le mot clé est « améliorés ». Améliorés selon le jugement de qui ? Celui de l’IA, pas celui de l’artiste.

NVIDIA l’a initialement présenté comme doté d’une « compréhension de la scène 3D ». L’entreprise a ensuite précisé qu’il fonctionnait uniquement à partir des données de l’image 2D. Cette distinction est importante. Le système n’améliore pas ce que les artistes ont créé. Il interprète une image plane et génère ce qui, selon lui, devrait s’y trouver. Lorsqu’il rencontre un visage présentant des imperfections intentionnelles, des cicatrices, de la crasse, des marques de stress ou une asymétrie, il a tendance à les lisser parce que ses données d’entraînement associent ces caractéristiques à une « qualité inférieure ».

C’est un problème de maîtrise créative

Les 52 % des développeurs qui ont déclaré à la GDC penser que l’IA nuit à l’industrie ne craignent pas tous de perdre leur emploi. Beaucoup s’inquiètent de perdre le contrôle sur l’apparence de leur travail lorsqu’il arrive jusqu’au joueur.

Le DLSS 5 donne une réalité concrète à cette crainte. Une IA se trouve désormais dans le pipeline de rendu, entre votre création finalisée et l’écran du joueur, et elle réécrit activement vos décisions artistiques. Le visage émacié que vous avez passé des semaines à perfectionner est lissé. L’éclairage sombre et évocateur que vous avez soigneusement équilibré est « corrigé » pour devenir plus photoréaliste. L’esthétique précise que vous avez choisie est généralisée pour correspondre à ce que le modèle considère comme « réussi ».

Digital Foundry a d’abord publié un aperçu positif, avant de diffuser un article de suivi intitulé « Pourquoi nous aurions dû attendre avant de publier notre analyse ». Même la presse technologique, habituellement prompte à saluer NVIDIA, a reconnu que cette version avait quelque chose de différent.

Larian Studios, le studio à l’origine de Baldur’s Gate 3, aurait abandonné certains outils de rendu génératif pour son prochain projet à la suite de la réaction négative des fans. Lorsqu’un studio qui vient de remporter le titre de jeu de l’année renonce à une technologie de rendu gratuite, la question de la maîtrise créative n’a plus rien de théorique.

Le retour de Digital Foundry sur le débat autour du DLSS 5 : « Nous aurions dû prendre davantage de temps. »

Le schéma est le même

J’ai écrit sur la pollution de l’open source par l’IA au début du mois. Le schéma est identique. Produire quelque chose coûte peu. Produire quelque chose de bon coûte toujours autant. Évaluer si quelque chose est bon coûte toujours autant.

Dans l’open source, ce sont des pull requests générées par l’IA qui semblent plausibles, mais introduisent des bugs subtils. Dans le rendu, ce sont des images générées par l’IA qui paraissent « meilleures », mais ne correspondent pas à l’intention de l’artiste. Dans les deux cas, l’IA remplace le jugement humain par une production fondée sur une moyenne statistique. Dans les deux cas, quelqu’un d’autre en paie le prix en temps et en maîtrise créative.

La différence, c’est qu’un mainteneur peut refuser une mauvaise pull request. Un artiste ne peut pas refuser le DLSS 5 si NVIDIA et l’éditeur se sont mis d’accord pour l’activer. Le GPU du joueur réécrit son travail en temps réel, sans qu’il ait son mot à dire.

Ce qui, selon moi, va se passer ensuite

NVIDIA lancera le DLSS 5 à l’automne 2026. De grands éditeurs, dont Capcom, Bethesda, Ubisoft et Warner Bros., ont déjà signé. La technologie s’améliorera et la « yassification » deviendra moins flagrante. La polémique s’apaisera parce que les gens finissent par s’habituer aux choses.

Mais la question fondamentale ne disparaîtra pas : lorsque vous ajoutez une IA générative au pipeline de rendu, qui a le dernier mot sur ce que voit le joueur ? Pour l’instant, la réponse est : les données d’entraînement de NVIDIA. Cela devrait inquiéter quiconque considère le jeu vidéo comme une forme d’art.

Cette distinction est importante pour notre manière d’envisager les outils d’IA dans l’ensemble de l’industrie. Une IA qui sert l’intention du créateur est un outil. Une IA qui passe outre l’intention du créateur est tout autre chose. Les versions 1 à 4 du DLSS étaient des outils. Le DLSS 5 est le premier exemple grand public d’une IA qui impose son propre jugement esthétique à l’œuvre d’autrui, au niveau matériel et sans demander la permission.

À lire également :

• L’open source a un problème de pollution par l’IA — le même schéma dans un contexte différent
• La GDC 2026 en chiffres — les données de l’enquête sur l’opposition des développeurs à l’IA
• Controverse autour de l’IA, confiance et économie post-IA — la question plus générale de la confiance
• Les modèles d’IA générative open source de pointe — les modèles qui alimentent le rendu génératif

Par Oleg Sidorkin, CTO de Cinevva

Andrej Karpathy a inventé le terme « vibe coding » en février 2025 pour désigner la création de logiciels qui consiste à décrire ce que l’on veut et à laisser l’IA se charger de l’implémentation. Un an plus tard, le dictionnaire Collins en a fait son mot de l’année. Les recherches sur ce terme ont bondi de 6 700 % ce printemps-là.

Pour la plupart des logiciels, le vibe coding permet de créer des prototypes plus rapidement. Pour le développement de jeux, il signifie quelque chose de plus précis. La barrière entre « idée étrange » et « prototype jouable » s’est effondrée.

A Breaker Belt : la rencontre de Snake et d’Arkanoid, créé en vibe coding en trois jours avec le moteur Cinevva

Ce qui a réellement changé

Les game jams existent parce que le développement de jeux prend trop de temps pour la plupart des expérimentations. Vous disposez de 48 heures, d’un thème et de toute l’énergie que vous pouvez tirer de la caféine et de l’adrénaline. Cette contrainte stimule la créativité. Impossible de créer quelque chose d’ambitieux, alors on crée quelque chose d’étrange. Certains des meilleurs jeux de l’histoire ont commencé comme des projets de game jam.

Le vibe coding produit un effet similaire, mais supprime la pression artificielle du temps. Lorsqu’il suffit de décrire une mécanique, une ambiance ou un comportement pour obtenir un prototype fonctionnel en quelques minutes plutôt qu’en quelques jours, on peut tester des idées que personne n’aurait accepté de financer. L’économie de l’expérimentation a changé.

Nous avons créé A Breaker Belt en trois jours. Deux personnes, par intermittence, sans période de crunch. Snake rencontre Arkanoid. 50 vagues. 23 types de briques. Une musique réactive. Une narration par IA. Des effets sonores synthétisés en temps réel. Le tout publié sur le Web, les appareils mobiles et les PC. Un projet de cette ampleur aurait normalement demandé plusieurs mois à une équipe de huit ou neuf personnes. Ce mélange étrange, qui aurait fini par mourir dans un document de brainstorming, a finalement vu le jour le temps d’un long week-end.

Voilà ce que le vibe coding apporte réellement aux jeux. Il ne crée pas automatiquement d’excellents jeux. Il rend les expérimentations peu coûteuses.

Les chiffres derrière la tendance

Les investissements montrent à quel point le secteur prend ce phénomène au sérieux. Cursor a levé 2,3 milliards de dollars lors d’un tour de série D. Lovable a levé 330 millions de dollars, pour une valorisation de 6,6 milliards. On estime que 25 % des start-up de la promotion hiver 2025 de Y Combinator reposaient sur des bases de code générées à 95 % par l’IA.

Dans le développement de jeux en particulier, Three.js est désormais la principale bibliothèque utilisée pour les jeux Web créés en vibe coding, avec 2,7 millions de téléchargements npm par semaine. Des plateformes comme Cinevva et Phaser, ainsi qu’une liste croissante d’outils d’IA, conçoivent des environnements de développement dans lesquels la description de l’intention devient la principale donnée d’entrée.

Karpathy lui-même est déjà passé au concept suivant. Il l’appelle « ingénierie agentique » : des agents d’IA écrivent eux-mêmes le code au lieu de répondre aux prompts d’un humain. « Il y a là un art, une science et une expertise », a-t-il écrit. Le domaine évolue plus vite que son vocabulaire.

Ce qui ne change pas

Les limites sont bien réelles, et il est important de les reconnaître honnêtement. À mesure que les projets grandissent, la gestion du contexte devient le principal goulot d’étranglement. Les performances des modèles d’IA se dégradent lorsque votre projet devient si complexe que l’ensemble de son contexte ne tient plus dans une seule fenêtre. Le code obtenu est souvent suffisamment bon pour fonctionner, mais pas pour être maintenu. Et quand quelque chose casse, déboguer une complexité générée par l’IA que personne ne comprend entièrement devient un défi à part entière.

Il y a aussi la question du goût. Une IA peut générer très rapidement un jeu fonctionnel sur le plan mécanique. Elle ne peut pas vous dire si le jeu est amusant. Si la courbe de difficulté semble juste. Si la musique correspond à l’ambiance. Si le rythme maintient l’intérêt ou finit lentement par ennuyer. Cette capacité de jugement, ce qui distingue un prototype d’un jeu qui mérite d’être joué, nécessite toujours un humain qui se soucie du résultat.

Les game jams fonctionnent parce que la pression du temps oblige à prendre des décisions difficiles sur ce qui compte vraiment. Le vibe coding supprime cette pression, mais pas la nécessité de faire des choix. Les meilleurs jeux créés en vibe coding viendront de personnes qui savent ce qu’elles veulent, et non de celles qui acceptent tout ce que l’IA leur renvoie.

Ce qui va se passer ensuite, à mon avis

Davantage de jeux qui ne devraient pas exister verront le jour. Certains seront terribles. D’autres seront brillants. Le rapport ne changera peut-être pas, mais le volume, si. Et dans ce volume, on trouvera des jeux qui n’auraient jamais pu être créés auparavant. Des genres qui n’ont pas encore de nom. Des mélanges que personne n’aurait financés. Des projets personnels réalisés par une seule personne parce que les outils ont enfin cessé de lui faire obstacle.

C’est depuis toujours la promesse de meilleurs outils. Non pas que tout devienne meilleur, mais que davantage de choses puissent exister. L’énergie d’une game jam, ce « essayons simplement et voyons ce que ça donne », n’est plus limitée à une fenêtre de 48 heures. Nous sommes mardi après-midi et vous avez une idée. Jeudi, elle est jouable.

Le moteur de Cinevva est gratuit. Il ne manque peut-être que trois jours à votre étrange idée de jeu pour voir le jour.

À lire également :

• A Breaker Belt : la rencontre de Snake et d’Arkanoid, créée en vibe coding en trois jours
• Nous ne pensions pas créer une station de radio
• Outils de code à IA agentique — Claude Code, Cursor et GitHub Copilot pour le développement de jeux
• Game jams et hackathons — le format original de création de jeux en 48 heures
• Comparatif des moteurs de jeux Web — les moteurs adaptés aux workflows assistés par l’IA

Par Oleg Sidorkin, CTO de Cinevva

Le Steam Next Fest n'est pas qu'un événement. C'est aussi un jeu de données. En février 2026, plus de 2 200 jeux y ont participé avec des démos, des bandes-annonces et l'espoir d'obtenir des ajouts aux listes de souhaits. Les résultats sont tombés, et ils confirment une réalité que les développeurs indépendants ressentent sans toujours la dire à voix haute.

Le Next Fest récompense les jeux qui ont déjà un public. Si vous partez de zéro, le festival ne suffira pas à changer la donne.

Les jeux indépendants qui se sont démarqués au Steam Next Fest de février 2026

Les chiffres

presskit.gg a analysé les données, et les différents niveaux révèlent des écarts assez saisissants :

Le jeu médian a obtenu 460 ajouts aux listes de souhaits. Et ce, avec une démo disponible, une page de boutique en ligne et la promotion active de l'événement par Steam. Quatre cent soixante ajouts pour une semaine entière de visibilité dédiée sur la plus grande plateforme de jeux PC au monde.

La dynamique s'autoalimente. L'invisibilité aussi.

Les jeux de niveau Diamant avaient presque tous déjà plus de 10 000 ajouts aux listes de souhaits avant le festival. Ils avaient bénéficié de la couverture de créateurs de contenu avant même son lancement. Leur visuel de capsule était immédiatement compréhensible, même sous forme de miniature. Ils avaient fait le travail marketing avant de se présenter.

Et les jeux arrivés avec moins de 1 000 ajouts ? Pour la plupart, ils n'en ont gagné que quelques centaines de plus. Le festival a amplifié ce qui existait déjà. Il n'a pas créé une dynamique à partir de rien.

Ce phénomène n'est pas propre au Next Fest. On le retrouve partout dans les systèmes de découverte. YouTube recommande les vidéos qui fonctionnent déjà bien. Spotify met en avant les morceaux qui comptent déjà des écoutes. Partout, les algorithmes des boutiques récompensent l'engagement en générant encore plus d'engagement.

Si vous avez déjà une dynamique, le Next Fest agit comme un multiplicateur. Sinon, ce n'est qu'un certificat de participation.

Le genre compte plus que vous ne le pensez

Les jeux en coopération ont surperformé dans toutes les catégories. Les créateurs de contenu veulent jouer avec leurs amis en direct. Cette dynamique sociale génère des extraits, qui génèrent des vues, qui génèrent à leur tour des ajouts aux listes de souhaits. La boucle de jeu sociale alimente la boucle des réseaux sociaux.

Les jeux de survie et de fabrication sont restés performants, même si, du point de vue des développeurs, le genre semble saturé. Les joueurs veulent toujours ce type de jeux. L'offre n'a pas dépassé la demande.

Les jeux narratifs et les visual novels ont rencontré davantage de difficultés. Le format du Next Fest joue contre eux. Le parcours rapide des démos favorise les jeux dont le concept est immédiatement lisible visuellement. Il faut comprendre de quel type de jeu il s'agit en quelques secondes, rien qu'en voyant son visuel de capsule et, éventuellement, dix secondes de gameplay. Les jeux centrés sur l'histoire ont besoin d'un contexte que les miniatures ne peuvent pas fournir.

Les roguelikes pouvaient encore tirer leur épingle du jeu, mais seulement grâce à une forte différenciation. Si votre argument est « c'est un roguelike avec une particularité », cette particularité doit être visible au premier coup d'œil.

Pourquoi nous suivons ces données de près

Ces données sont importantes pour nous, car Cinevva a précisément été conçu pour résoudre le problème qu'elles mettent en évidence. Notre système de découverte centrée sur les reels montre du véritable gameplay, et non des captures d'écran soigneusement sélectionnées. Vous faites défiler des extraits, repérez quelque chose qui a l'air amusant et commencez immédiatement à y jouer dans votre navigateur.

Nous ne cherchons pas à remplacer Steam ni à concurrencer le Next Fest. Les données nous montrent que ces plateformes fonctionnent très bien pour les jeux qui bénéficient déjà d'une certaine visibilité. La question qui nous intéresse est la suivante : qu'advient-il des 2 000 autres jeux ? Ceux qui sont réellement bons, mais qui ne disposaient pas déjà d'un public en arrivant ?

Ces jeux ont besoin d'une voie de découverte qui ne dépende pas d'une dynamique préexistante. D'un endroit où un joueur peut tomber par hasard sur un jeu qu'il n'aurait jamais trouvé dans une boutique, simplement parce qu'il en a vu cinq secondes et que cela a éveillé son intérêt. C'est ce vide que nous cherchons à combler.

Le guide stratégique du Steam Next Fest que nous avons publié plus tôt cette année couvre les aspects tactiques. Cet article porte sur la conclusion structurelle à en tirer. Sur la plus grande plateforme de jeux PC, la découverte repose de plus en plus sur un système où les plus visibles le deviennent encore davantage. Si c'est le seul système disponible, de nombreux excellents jeux resteront invisibles.

À lire également :

• Données du Steam Next Fest de février 2026
• Guide stratégique du Steam Next Fest — des tactiques pour tirer le meilleur parti du Next Fest
• Conception de jeux en coopération — les jeux en coopération surperforment régulièrement lors des festivals
• Comment lancer votre jeu sur itch.io — une autre voie de découverte pour les jeux de moindre envergure

Par Oleg Sidorkin, directeur technique de Cinevva

Rémi Verschelde est l’une des personnes qui assurent le bon fonctionnement de Godot. Ce n’est ni un projet secondaire ni un passe-temps. C’est l’œuvre de sa vie. Il maintient le moteur depuis une époque où la plupart des gens n’en avaient jamais entendu parler, examinant les contributions, fusionnant les correctifs et veillant à ce que l’outil dont dépendent des millions de développeurs fonctionne réellement.

Le mois dernier, il a décrit la situation actuelle du processus de contribution de Godot comme « épuisante et démoralisante ».

La cause : les demandes de fusion générées par l’IA. Beaucoup de demandes.

Godot compte actuellement 4 681 demandes de fusion ouvertes sur GitHub. Une part croissante des nouvelles soumissions provient de personnes qui ont saisi une consigne, obtenu du code et l’ont envoyé sans comprendre ce qu’il fait. À première vue, le code paraît souvent plausible. Il se compile. Les noms de variables sont cohérents. Puis un mainteneur passe vingt minutes à découvrir qu’il introduit un bug subtil, casse un cas limite ou résout un problème qui n’existe pas.

Le temps passé à rejeter de mauvaises demandes de fusion n’est pas consacré à examiner les bonnes.

L’ironie s’écrit toute seule

Les outils d’IA sont censés rendre les développeurs plus productifs. C’est la promesse. C’est pour cela que des entreprises lèvent des milliards afin de les concevoir. Et à l’échelle individuelle, ils y parviennent. J’utilise des outils d’IA tous les jours. Toute notre plateforme utilise l’IA pour la création de jeux, la génération musicale, les modèles 3D et bien plus encore. Je ne suis pas opposé à l’IA.

Mais il existe un effet à l’échelle du système dont personne ne parle dans les présentations destinées aux investisseurs. Lorsque l’IA rend la génération d’une contribution extrêmement facile et que le coût de sa soumission tombe à zéro, tandis que celui de son examen reste exactement le même, on obtient un problème de pollution.

Les personnes qui soumettent ces demandes de fusion ne sont pas malveillantes. La plupart souhaitent sincèrement contribuer. On leur a expliqué que les outils d’IA leur permettaient de contribuer à l’open source sans expertise approfondie. Et ces outils leur permettent effectivement de générer quelque chose qui ressemble à une contribution. Mais ce n’en est tout simplement pas une.

Verschelde a reconnu qu’utiliser l’IA pour détecter les demandes de fusion générées par l’IA serait « horriblement ironique ». Il a raison. Combattre les productions de l’IA par la détection automatisée est une course aux armements que personne ne peut gagner.

Ce que cela nous apprend vraiment

Créer quelque chose ne coûte désormais presque rien. Créer quelque chose de bon coûte toujours autant.

C’est la leçon qui se manifeste partout, pas seulement dans l’examen du code open source. On l’observe dans le développement de jeux, la production musicale et la création de contenu. L’IA a abaissé le plancher. La contribution minimale viable, le jeu minimal viable ou l’article de blog minimal viable peuvent désormais être générés en quelques secondes. Mais le plafond n’a pas bougé.

Les personnes qui maîtrisaient déjà leur métier sont maintenant plus rapides. L’écart entre « avoir créé quelque chose » et « avoir créé quelque chose qui mérite le temps de quelqu’un » est en réalité plus grand qu’auparavant, car le volume de productions médiocres a explosé tandis que le nombre de personnes capables d’en évaluer la qualité n’a pas changé.

Les règles de contribution de Godot imposent de déclarer toute assistance par l’IA. Les gens les ignorent. On pourrait durcir les règles, mais leur application exige précisément le même temps d’examen humain que l’on cherche à économiser.

La véritable solution est ennuyeuse

La principale demande de Verschelde concerne le financement. Embaucher davantage de mainteneurs. Davantage d’humains pour examiner le travail. Ce n’est pas une solution technique, mais organisationnelle. Et c’est probablement la seule qui fonctionne.

Les projets open source tirent la même leçon que nous tous : l’IA ne supprime pas la nécessité du jugement humain. Elle l’accroît. Plus le contenu généré par l’IA afflue dans un système, plus il faut de personnes capables de distinguer ce qui paraît juste de ce qui l’est réellement.

Nous y réfléchissons constamment lorsque nous concevons les outils de Cinevva. L’objectif n’a jamais été de supprimer le jugement humain de la création de jeux. Il s’agit de permettre aux personnes créatives de concentrer leur jugement sur ce qui compte : est-ce que cela procure la bonne sensation, est-ce que cela fonctionne, est-ce que quelqu’un y prendrait plaisir ? Les tâches ingrates sont prises en charge. Le goût, lui, ne s’automatise pas.

Godot trouvera une solution. Le moteur est trop important et sa communauté trop forte pour qu’il en soit autrement. Mais le phénomène auquel ils sont confrontés ne va pas disparaître. Chaque projet open source, chaque plateforme créative et chaque système acceptant des contributions du public devra répondre à la même question : comment gérer un monde où produire quelque chose ne coûte presque rien, mais où l’évaluer a toujours un coût ?

À lire également :

• Outils de programmation agentique par IA — utiliser les outils de programmation par IA de manière responsable
• Modèles d’IA générative open source de pointe — les modèles open source à l’origine de cette évolution
• Controverse autour de l’IA, confiance et économie post-IA — la question plus large de la confiance envers l’IA dans le travail créatif
• Comparatif des moteurs de jeux web — Godot et les autres moteurs concernés par cette tendance

Par Oleg Sidorkin, CTO de Cinevva

En février 2026, les événements suivants se sont produits en l’espace d’environ trois semaines.

Le PDG de Unity a déclaré publiquement que l’entreprise présenterait à la GDC une démonstration de génération de jeux à partir de prompts. Roblox a lancé un outil de création 4D qui génère des objets interactifs à partir de texte. Moonlake AI a ouvert la bêta de son Generative Game Engine, soutenu à hauteur de 30 millions de dollars par Nvidia, Jeff Dean et le cofondateur de YouTube. Phaser Editor v5 a été lancé avec une IA directement intégrée à l’éditeur de scènes via MCP. Et au moins une demi-douzaine de startups dont je n’avais jamais entendu parler sont apparues sur Product Hunt avec une variante de « décrivez un jeu, nous le construirons ».

Le vice-président de Roblox chargé de l’IA présente leur modèle de fondation Cube et la création 4D

Ce n’est pas une plainte. C’est une observation sur le calendrier.

Il y a deux ans, lorsque nous présentions ce que fait Cinevva, des investisseurs de Sequoia, Pear, Draper et de dizaines d’autres sociétés nous affirmaient que le marché n’existait pas. La création de jeux B2C ? Les développeurs indépendants ne paient pas pour des outils. On ne peut pas simplifier le développement de jeux sans en sacrifier les possibilités. L’éventail habituel d’objections déguisées en analyse de marché.

Aujourd’hui, les plus grands noms du jeu vidéo dépensent des centaines de millions dans une course visant à créer des variantes de ce dont ils disaient que cela ne pourrait jamais fonctionner.

Ces outils ne font pas la même chose

Voici ce qui compte et ce que la plupart des articles passent sous silence. La « création de jeux par IA » est une catégorie générique qui masque des produits fondamentalement différents.

Les outils de génération de démos à partir de texte produisent quelque chose d’impressionnant dans un tweet. Vous saisissez un prompt, obtenez une création jouable et partagez le GIF. Le résultat est bien réel, mais il s’agit d’une démo. Passer de cette démo à un jeu auquel quelqu’un aurait envie de jouer pendant une heure est un tout autre problème. Moonlake et certaines des startups les plus récentes se situent dans cette catégorie. Elles cherchent à produire l’étincelle initiale.

Les outils de copilote IA s’intègrent à un moteur existant et vous aident à travailler plus vite. C’est ce que fait Phaser Editor v5 avec MCP. Ziva fait de même pour Godot. Ils ne remplacent pas le processus de développement, ils l’accélèrent. Vous devez toujours comprendre ce que vous construisez. L’IA se charge des tâches répétitives.

La création par IA native d’une plateforme, c’est ce que fait Roblox avec la 4D. L’IA est intégrée à l’environnement d’exécution. Les objets ne se contentent pas d’avoir la bonne apparence : ils se comportent correctement, car le modèle de génération comprend les systèmes physiques et interactifs de la plateforme. En contrepartie, vous êtes prisonnier de cette plateforme.

Les moteurs de jeu IA full-stack tentent de tout prendre en charge, du concept à la publication. C’est ce que Unity promet de présenter à la GDC. C’est ce que nous construisons chez Cinevva depuis des années. Décrivez ce que vous voulez, améliorez le résultat par itérations, puis publiez sur le Web, les appareils mobiles, les ordinateurs et Steam. Le jeu que vous créez par prompt est celui que vous publiez.

Phaser Editor v5 intègre l’IA via MCP pour fournir une assistance au niveau des scènes

L’écart entre la démo et la publication

Tous les outils de ce secteur peuvent générer quelque chose qui fonctionne. Cette partie est rapidement devenue facile. Le plus difficile, c’est tout ce qui vient après. Le jeu est-il agréable sur téléphone ? Gère-t-il les cas limites ? Pouvez-vous ajuster la musique, la courbe de difficulté et le rythme ? Pouvez-vous le publier sur cinq plateformes à partir du même projet ? L’IA comprend-elle ce qui rend réellement un jeu amusant, par opposition à ce qui rend une capture d’écran séduisante ?

Certaines de ces annonces donneront naissance à de véritables produits. D’autres obtiendront une levée de fonds, produiront de jolies démos, puis disparaîtront discrètement lorsque la partie « publier un vrai jeu » se révélera plus difficile que la partie « générer un prototype ».

Ce qui, selon moi, est réellement en train de se passer

La validation du marché que nous n’avons pas pu obtenir lors d’une réunion sur Sand Hill Road vient désormais de l’industrie elle-même. Lorsque Unity et Roblox misent leurs feuilles de route sur la création par IA, ils confirment l’objectif vers lequel nous travaillons : les outils doivent s’adapter à la manière dont pensent les personnes créatives.

La course ne consiste pas à savoir qui fera la première annonce. Il s’agit de savoir qui proposera un produit que les gens utiliseront réellement pour créer des jeux dont ils seront fiers. Aujourd’hui, des milliers de personnes le font sur Cinevva. A Breaker Belt a été créé par deux personnes en trois jours. Cinevva Radio compte 362 morceaux créés par la communauté. Voilà la différence entre promettre de bâtir l’avenir et déjà y vivre.

La concurrence est une bonne chose. Elle prouve que le marché existe. Nous le savons depuis un certain temps.

À lire également :

• Comparatif des moteurs de jeu Web — comparaison des moteurs traditionnels pour la publication sur le Web
• Modèles d’IA générative open source de pointe — les modèles d’IA qui alimentent la génération de jeux
• Outils de code à IA agentique — la couche de copilote IA qui accélère le développement
• A Breaker Belt — un jeu créé en trois jours avec des outils d’IA