J'ai fait un jeu sans coder. Mais ce n'est pas le vibe coding qui m'intéresse

Ces derniers jours, j'ai développé un jeu vidéo.

Enfin, « développé » est probablement le mauvais mot. Je n'ai pratiquement pas écrit de code moi-même.

J'ai décrit ce que je voulais. J'ai testé. J'ai refusé certaines propositions. J'ai signalé des bugs. J'ai arbitré des mécaniques. J'ai fourni des assets.

Et pendant ce temps, un agent IA modifiait directement le projet : fichiers, scripts, tests, images, musiques, scènes…

On pourrait facilement en tirer un article enthousiaste sur le vibe coding.

Et soyons clairs : c'est impressionnant. Mais après quelques jours à travailler comme ça, je pense que le sujet le plus intéressant est ailleurs.

Ce qui change vraiment n'est pas seulement que les modèles écrivent mieux du code. C'est qu'on commence à les connecter à des outils capables d'agir réellement sur leur environnement, et que la communauté commence à l'appliquer.

Pourquoi il vient nous parler de jeu vidéo ?

Je vais vous infliger un paragraphe digne des messages bullshit LinkedIn. Pardonnez-moi.

Lorsque je me suis lancé dans SOCLE AI, lors de l'un de nos premiers cafés, mon binôme, dont je tairai le nom, il se reconnaîtra ;), m'a demandé :

« Si SOCLE AI réussissait vraiment beaucoup, genre si tu avais beaucoup d'argent, tu ferais quoi ? »

Pendant que je réfléchissais, il a continué en rigolant :

« Te connaissant, tu ferais une équipe d’esport. »

Même si l'idée de faire de l'ombre à la KC me fait sourire, je préférerais probablement les rejoindre et les soutenir.

Je lui avais répondu trois choses.

• 01Faire un jeu vidéo dont le gameplay et l'univers me trottent dans la tête depuis des années.
• 02Trouver un moyen de mêler robotique et environnement, par exemple avec des outils de surveillance ou de protection de nos forêts.
• 03Et, beaucoup plus cliché, faire quelque chose autour des animaux : soutenir un refuge ou un projet de ce type.

Fin de la séquence émotion. Revenons au jeu vidéo.

Parce qu'au-delà du rêve de gamin, le jeu est aussi un formidable laboratoire pour parler d'intelligence artificielle. On peut y simuler rapidement des situations, répéter des milliers d'expériences et observer des comportements émerger.

Ce n'est d'ailleurs pas complètement étranger à l'intérêt actuel pour les simulations et les world models. Et surtout, dans mon cas, cela permettait de mettre dans un seul prototype plusieurs formes d'IA très différentes.

Je ne lui ai pas demandé « fais-moi un jeu »

Il y a un point essentiel qui disparaît souvent dans les démonstrations de vibe coding. Je n'ai pas ouvert un agent en écrivant :

« Fais-moi un jeu vidéo cool, un peu comme Space Invaders stp. »

Le jeu existait déjà dans ma tête. Depuis longtemps.

J'imaginais cet univers pendant mes temps perdus : son lore, ses peuples, ses dieux, ses règles et progressivement ses mécaniques.

Je savais notamment ce que je voulais faire de la boucle principale. Le joueur développe un village et construit son propre donjon. Mais surtout, ce donjon peut être attaqué quand le joueur n'est pas là. Ses défenseurs doivent donc être capables de combattre seuls.

Et je ne voulais pas qu’ils reposent uniquement sur un comportement du type :

si ennemi proche :
    attaquer
sinon :
    marcher vers ennemi

Je voulais que chaque défenseur puisse posséder son propre petit réseau de neurones. Un cerveau que le joueur pourrait construire, modifier puis entraîner.

Cette mécanique était là avant la première ligne de code. Le gameplay général aussi. Le lore aussi. Une bonne partie des premières boucles de progression également.

L'agent n'a donc pas inventé mon produit. Il m'a permis de transformer très rapidement une spécification qui existait déjà en quelque chose que je pouvais manipuler.

Et cette distinction me paraît fondamentale.

Plus l'exécution devient rapide, plus la spécification prend de la valeur

Pendant longtemps, une mauvaise spécification pouvait mettre du temps avant de se révéler vraiment mauvaise. Le développement prenait du temps. Plusieurs semaines pouvaient passer avant d'avoir suffisamment construit pour se rendre compte que la direction initiale posait problème.

C'est d'ailleurs notamment pour cela que l'on a rapproché Produit, développement et QA, avec des boucles de validation beaucoup plus courtes.

Pouvoir exécuter rapidement ne supprime donc pas le travail Produit. Au contraire. Cela augmente la valeur de questions très basiques :

• ▸Pour qui construit-on ?
• ▸Quelle est la boucle principale ?
• ▸Quelle mécanique apporte réellement quelque chose ?
• ▸Quelle fonctionnalité peut attendre ?
• ▸Qu'est-ce qui doit être automatisé ?
• ▸Qu'est-ce qui doit rester manuel ?
• ▸Et surtout : qu'est-ce qu'on refuse de construire ?

Sur le jeu, une partie importante de mon travail consiste précisément à écrire « non, pas maintenant ». Ou « ce n'est pas comme ça que je l'imaginais ». Ou encore « la mécanique fonctionne, mais elle n'est pas intéressante ».

L'IA accélère énormément l'exécution. Elle ne donne pas automatiquement une bonne direction.

Ce qui change vraiment : le modèle commence à agir

Prenons maintenant un très bon modèle de langage. Vous lui demandez :

« Analyse ces logs et corrige le bug. »

S'il n'a accès à rien, il peut produire une hypothèse. Il peut écrire un bout de code. Il peut vous dire quelles commandes lancer. Mais c'est encore à vous de prendre cette réponse et d'agir.

Donnons-lui maintenant quelques capacités :

• ▸lire les fichiers du projet ;
• ▸rechercher dans le code ;
• ▸modifier un fichier ;
• ▸lancer les tests ;
• ▸exécuter le programme ;
• ▸inspecter le résultat ;
• ▸utiliser Git ;
• ▸appeler une API ;
• ▸utiliser des outils disponibles sur la machine.

La même demande change de nature. L'agent peut rechercher les fichiers concernés, identifier une cause probable, modifier le code, lancer les tests, analyser l'erreur puis modifier son approche.

On passe de « produire une réponse » à « poursuivre un objectif à travers une succession d'actions ». C'est là que l'approche agentique devient réellement intéressante.

Le modèle raisonne, les outils agissent

Le modèle peut conclure : « il faudrait regarder le fichier de sauvegarde. » Mais sans outil, il ne peut pas le lire.

Il peut déterminer : « ces WAV devraient être convertis. » Mais sans console ni ffmpeg, il ne peut pas effectuer la conversion.

Il peut suggérer : « il faudrait lancer les tests. » Mais il ne connaîtra jamais leur résultat tant que quelqu'un ou quelque chose ne les aura réellement exécutés.

C'est notamment dans cette logique qu'intervient MCP, Model Context Protocol.

MCP : une prise standard, pas une baguette magique

On entend parfois que MCP est « ce qui permet à une IA d'accéder à votre ordinateur ». C'est un raccourci.

MCP est avant tout un protocole d'interconnexion. Il permet à un environnement agentique de découvrir et d'appeler de manière standardisée les outils et ressources qui lui sont exposés.

Ce sont ensuite l'application hôte, les permissions et les outils exposés qui déterminent ce que l'agent peut réellement faire. Cette nuance est importante : vous ne voulez justement pas que votre agent puisse tout faire.

Dans mon cas, l'agent pouvait travailler directement dans le projet Godot, écrire dans certains dossiers, lancer des commandes et utiliser les outils nécessaires à son travail. Et c'est ce qui a rendu l'expérience très différente d'un simple chatbot qui me rend du code à recopier.

Mais tout ne mérite pas d'être connecté

Les assets donnent un bon contre-exemple. Une partie des sprites du prototype a été générée avec ChatGPT, et les quatre morceaux de musique avec Suno. Deux outils que je connaissais déjà, et pour lesquels je savais assez précisément ce que je voulais obtenir.

J'avais besoin de quelques sprites et de quatre musiques. Pas de quatre cents.

Je n'ai donc connecté ni l'un ni l'autre à mon environnement agentique. J'ai produit les images et les morceaux directement dans leur outil, téléchargé les fichiers et je les ai déposés dans le projet. À partir de là, l'agent pouvait prendre la suite : conversion des formats, découpe, nommage, organisation, intégration dans les différentes scènes…

La frontière est assez nette. La génération demandait mon œil : je regarde, je relance, je choisis. Tout ce qui vient après est mécanique, répétitif et vérifiable — donc exactement ce qu'un agent fait bien.

Pourquoi ne pas automatiser la première partie ? Parce que cela n’aurait probablement rien apporté. Une intégration supplémentaire signifie également :

• ▸des outils supplémentaires dans le contexte ;
• ▸des permissions ;
• ▸des dépendances ;
• ▸des cas d'erreur ;
• ▸de la maintenance.

Tout ça pour automatiser une poignée de générations que je pouvais lancer moi-même en quelques minutes.

J'ai donc utilisé une IA… pour développer une autre IA

Et c'est là que le projet devient particulièrement amusant. Parce que l'une des principales mécaniques du jeu repose elle-même sur une forme d'intelligence artificielle.

Mais pas un LLM. Pas même de l'IA générative. Un réseau de neurones entraîné par algorithme génétique.

Chaque défenseur peut avoir son propre cerveau

Le principe du donjon est simple. Vous le construisez. Vous y placez vos défenseurs. Puis un autre joueur peut venir l'attaquer alors que vous êtes hors ligne. Vos créatures doivent donc se débrouiller seules.

Mais au lieu de leur donner uniquement une IA scriptée, je voulais que le joueur puisse construire leur cerveau. L'idée est en partie inspirée de The Bibites, que je trouve fascinant dans sa manière de rendre visibles de petits réseaux neuronaux et de laisser émerger des comportements.

Chaque défenseur reçoit donc différents signaux :

• ▸la position de l'adversaire ;
• ▸sa distance ;
• ▸ses propres points de vie ;
• ▸la position de ses alliés ;
• ▸son poste assigné ;
• ▸le nombre d'ennemis autour de lui.

Et le réseau peut produire différentes actions :

• ▸avancer ;
• ▸reculer ;
• ▸se déplacer latéralement ;
• ▸attaquer ;
• ▸utiliser certaines capacités selon son rôle.

Entre les deux, le joueur construit son réseau. Il peut ajouter ou retirer des nœuds, changer l'architecture et donc influencer la manière dont son défenseur prend ses décisions.

Puis Darwin entre dans le donjon

Il faut maintenant trouver les bons paramètres du réseau. C'est là qu'intervient l'algorithme génétique.

Petit à petit, certains comportements émergent. Un défenseur apprend à charger immédiatement. Un autre garde ses distances. Un autre protège davantage une zone.

Et le joueur peut ensuite reprendre la main, modifier le réseau, relancer un entraînement ou choisir un individu qui n'est pas nécessairement celui ayant obtenu le meilleur score. Parce que la performance mathématique et le comportement que vous souhaitez ne sont pas toujours la même chose.

Une fonction de fitness est déjà une spécification

C'est probablement l'un des parallèles les plus amusants avec les agents modernes. Supposons que je récompense uniquement la survie de mon défenseur. Très rapidement, l'évolution peut découvrir une excellente stratégie : fuir le combat pendant douze secondes.

Mathématiquement, impeccable. Comme jeu vidéo, beaucoup moins.

On ajoute donc une pénalité lorsque le personnage reste trop loin. Puis les individus exploitent autre chose. On corrige. Puis encore autre chose.

La fonction de fitness finit par devenir une sorte de spécification formelle de ce que nous considérons comme un « bon » comportement.

Ce ne sont pas les créatures qui se rebellent contre leur créateur. Elles optimisent simplement le critère qu'on leur a donné.

Combien de fois me suis-je retrouvé devant un développeur junior très fier de me montrer une fonctionnalité techniquement conforme mais complètement absurde à l'usage ? « Ce n'était pas spécifié. » Et parfois… il avait raison.

Faire fonctionner un jeu n'est pas faire un bon jeu

Tout cela étant dit, est-ce que cinq jours avec un agent font de moi un studio de jeu vidéo ? Évidemment non.

Faire fonctionner un prototype n'a quasiment rien à voir avec produire Baldur's Gate 3 ou Clair Obscur: Expedition 33. Ce qui fait la qualité de ces jeux n'est pas qu'un développeur ait réussi à programmer :

player.attack(enemy)

C'est l'accumulation de milliers de décisions.

• ▸Le rythme d'une animation.
• ▸La réaction d’un personnage pendant un dialogue.
• ▸Une caméra qui bouge exactement au bon moment.
• ▸Le poids d'un impact.
• ▸L'écriture. Le sound design. La direction artistique.
• ▸La musique, et une pensée particulière pour le travail de Lorien Testard et Alice Duport-Percier sur Clair Obscur.
• ▸Une interface qui vous donne l’information sans vous la jeter au visage.
• ▸Un environnement qui attire naturellement votre regard.
• ▸Une réaction prévue pour une décision que 2 % des joueurs seulement prendront.
• ▸Le travail de motion capture, les transitions, le rythme général. De la même manière un petit clin d’œil pour Estelle Darnault et son formidable travail.

Cette accumulation de détails représente un travail colossal effectué par de nombreux métiers. Et l'IA ne le fait pas disparaître.

La difficulté n'est pas dans le nombre de lignes de code

C'est peut-être l'une des erreurs fondamentales lorsque l'on parle d'IA dans la création. On confond facilement le coût d'implémentation d'un produit et la difficulté de créer un bon produit.

Or la qualité des meilleurs jeux réside surtout dans leur densité de choix pertinents. Baldur's Gate 3 est remarquable notamment parce qu'une quantité presque absurde de situations ont été anticipées. Clair Obscur possède une identité parce que sa direction artistique, sa musique, sa mise en scène, son gameplay et son rythme semblent parler la même langue.

Les technologies génératives pourront accélérer énormément de choses : le code, le prototypage, les concepts, certains assets, les tests, la localisation, peut-être demain une partie de l'animation.

Mais il faudra toujours qu'une personne finisse par regarder le résultat et se demander : « est-ce que c'est bien ? » Et c'est probablement la question la plus chère de toutes.

Mon jeu marche. Et pourtant il est parfois cassé.

À un moment du prototype, j'appuyais sur la touche d'attaque. Les tests passaient. L'événement était envoyé. Les dégâts étaient bien infligés.

attaque = OK
dégâts  = OK
tests   = OK

À l'écran : rien.

Le personnage utilisé à cet instant précis ne possédait pas l'animation attendue et le mécanisme visuel de secours ne se déclenchait pas.

Du point de vue du système, tout fonctionnait. Du point de vue du joueur, l'attaque était cassée. Il m'a fallu quelques secondes en lançant le jeu pour le voir.

Et cela risque de rendre les joueurs encore plus exigeants

C'est là où je pense que l'impact des outils agentiques pourrait devenir intéressant pour l'industrie du jeu vidéo.

Cela fait des années que les joueurs entendent « faire un jeu est extrêmement compliqué ». Et c'est vrai. Je dirais même que le niveau de détail nécessaire pour réaliser certains jeux est probablement sous-estimé.

Mais parallèlement, nos moyens de production progressent. Si les agents permettent :

• ▸d'écrire plus vite ;
• ▸de produire davantage de tests ;
• ▸d'automatiser des tâches répétitives ;
• ▸de prototyper une mécanique en quelques heures ;
• ▸de fabriquer plus facilement des outils internes ;
• ▸de détecter davantage de régressions ;
• ▸d'accélérer une partie de la production d'assets ;

alors une conséquence me paraît assez logique : le niveau d'exigence va augmenter avec eux.

Un jeu vendu 70 ou 80 euros avec des sauvegardes corrompues, des fonctionnalités absentes, une interface cassée ou des mécaniques manifestement terminées à moitié sera progressivement plus difficile à justifier uniquement avec « vous savez, développer un jeu est compliqué ». Parce que les moyens disponibles pour gérer cette complexité augmentent eux aussi.

Et surtout, le joueur pourra comparer. Avec cet indépendant qui a eu une excellente idée. Avec ce AA qui possède beaucoup plus d'identité. Avec un petit studio qui aura réussi à consacrer les gains de productivité non pas à sortir plus vite, mais à polir davantage.

Paradoxalement, rendre la création plus accessible pourrait donc augmenter la valeur du talent, du goût et de la finition.

Et exactement la même chose va arriver dans le logiciel professionnel

Remplaçons simplement « joueur » par « utilisateur ».

Pendant longtemps, une entreprise pouvait expliquer : « il faudra trois mois pour faire le prototype. » Demain, son client aura peut-être lui-même utilisé un agent pour produire quelque chose de vaguement fonctionnel dans la journée.

Cela ne signifie évidemment pas qu'une application industrielle doit maintenant être livrée en vingt-quatre heures. Il reste juste…

• ▸la sécurité ;
• ▸l'intégration ;
• ▸les migrations ;
• ▸la stabilité ;
• ▸les tests ;
• ▸la conformité ;
• ▸l'UX ;
• ▸la maintenance ;
• ▸l'exploitation.

Bref, quasiment tout. ^^'

Mais le rapport psychologique au délai va changer. L'utilisateur tolérera probablement de moins en moins une interface médiocre, des bugs évidents, des parcours inutilement compliqués ou des releases qui cassent l'existant.

Le coût apparent de la production logicielle va diminuer. Et en miroir, la valeur du run, de la fiabilité et de l'industrialisation pourrait remonter.

Et c’est justement là que les agents deviennent difficiles à industrialiser

Revenons maintenant à nos agents. Pourquoi ne pas simplement leur donner accès à tout ? Parce qu'un agent n'est pas une API.

Prenons un agent commercial disposant de quatre outils :

search_crm()
read_email()
update_opportunity()
send_email()

On lui demande :

« Regarde où en sont mes prospects et relance ceux qui en ont besoin. »

Très séduisant. Sauf qu’il faut maintenant définir :

• ▸Qui doit être relancé ? Après combien de temps ?
• ▸Une opportunité perdue doit-elle être contactée ?
• ▸L'agent peut-il envoyer directement le message, ou seulement préparer un brouillon ?
• ▸Peut-il modifier le CRM ?
• ▸Que se passe-t-il s'il appelle deux fois le même outil ?
• ▸Que fait-on lorsqu'un service externe retourne une erreur ?
• ▸Et surtout : que se passe-t-il lorsqu'il se trompe ?

On retrouve immédiatement les vieux sujets de l'ingénierie logicielle : permissions, idempotence, transactions, validation, logs, rollback, authentification, gestion des erreurs.

Avec une différence importante : au milieu du système se trouve désormais un composant probabiliste.

La contrainte devient une fonctionnalité

Dans un logiciel traditionnel, une fonction comme :

sendInvoice(customer_id)

possède un comportement relativement prévisible.

Un agent peut décider d'appeler un outil. Puis un deuxième. Puis de rechercher davantage d'informations. Ou de ne pas prendre le chemin auquel vous pensiez.

Cela signifie que la conception des outils est extrêmement importante. Un outil comme :

execute_sql(query)

offre beaucoup de liberté. Un outil comme :

get_customer_orders(customer_id)

beaucoup moins. Et selon le problème que l'on cherche à résoudre : moins de liberté peut produire un meilleur système.

Ceux qui me connaissent savent pourtant à quel point j'aime les architectures modulaires. Donc prenez la gravité de cette phrase à sa juste valeur. ;)

L'autonomie n'est pas un objectif produit

On entend beaucoup : « il faut que l'agent soit autonome. » Je ne suis pas vraiment d'accord. L'autonomie est une propriété du système. Pas nécessairement une finalité produit.

Prenons trois actions :

• 01rechercher une facture ;
• 02préparer un email à un fournisseur ;
• 03virer 50 000 € au fournisseur.

Techniquement, les trois peuvent être exposées comme des outils. Mais leur coût d'erreur n'a absolument rien à voir.

Il est donc parfaitement cohérent de laisser l'agent retrouver automatiquement la facture. De le laisser préparer l'email. Puis d'exiger une validation humaine avant le virement. Le fameux Human in the Loop.

Ce n'est pas une IA moins avancée. C'est probablement simplement une meilleure architecture.

Et si l'agent agit, il faut pouvoir reconstruire ce qu'il a fait

C'est également pour cela que chez SOCLE nous accordons beaucoup d'importance à l'observabilité des workflows agentiques.

Quand un utilisateur demande « mets à jour ce dossier client » et que l'agent répond « c'est fait », cela ne suffit plus vraiment. Il faut pouvoir reconstruire :

• ▸quels documents ont été consultés ;
• ▸quels outils ont été appelés ;
• ▸avec quels paramètres ;
• ▸quelles données ont été modifiées ;
• ▸quelles validations ont eu lieu ;
• ▸quelles erreurs ont été rencontrées.

Parce qu'un système capable d'agir mais incapable d'expliquer son chemin devient extrêmement difficile à mettre sérieusement en production.

J'ai déjà refusé des projets dans lesquels une décision algorithmique pouvait avoir un impact concret sur un utilisateur alors même que personne n'était capable d'expliquer ou de reconstruire correctement la décision.

Au-delà même du sujet moral, la question est assez simple : que répond-on lorsqu'un utilisateur conteste la décision ?

Ce n'est plus seulement du prompt engineering

Pendant plusieurs années, les discussions autour des LLM ont énormément porté sur le prompt. Quel prompt ? Quel modèle ? Quelle température ? Quelle taille de contexte ?

Ces questions existent toujours. Mais la valeur se déplace progressivement autour du modèle.

Le harness, c'est tout ce qui encadre le modèle. Ce qu'il voit. Les outils qu'il peut appeler. La mémoire qu'il conserve. Les permissions dont il dispose. La manière dont son travail est vérifié. Les moments où il doit demander une validation. Et tout ce qui permet ensuite d'observer son comportement.

MCP facilite l'interconnexion avec les outils. A2A permet d'organiser certains échanges entre agents. Mais ni l'un ni l'autre ne remplace la conception de l'ensemble.

Et c'est précisément pour cela que chez SOCLE nous préférons parler d'écosystèmes d'agents plutôt que d'un modèle ou d'un agent isolé.

Les modèles commencent à avoir des mains

Finalement, c'est probablement ce que je retiens le plus de cette expérience. Pendant longtemps, nous avons surtout évalué les IA sur leur capacité à parler. Puis à raisonner. Maintenant, nous commençons à leur donner :

• ▸un terminal ;
• ▸un système de fichiers ;
• ▸des APIs ;
• ▸un navigateur ;
• ▸un CRM, un ERP, des outils métier ;
• ▸et parfois d'autres agents.

Je trouve cela beaucoup plus structurant que de savoir quel modèle vient de gagner quelques points sur le dernier benchmark.

Et la question des prochaines années ne sera donc probablement pas simplement « quel est le meilleur modèle ? », mais « quel système avons-nous construit autour de lui ? »

Quels outils ? Quelles permissions ? Quelle mémoire ? Quels tests ? Quelle observabilité ? Quelle place pour l'humain ?

Et surtout : quelle spécification ?

Parce que sur ce point, les agents n'ont rien changé. On peut désormais construire énormément plus vite. Mais encore faut-il savoir ce que l'on veut construire.