Margit le Fell Omen lève sa canne. Il la tient en l’air une seconde et demie.
Vous avez déjà roulé. Votre pouce a devancé votre conscience sur le bouton B, parce que huit morts vous ont enseigné une chose : l’amorce de Margit cache deux enchaînements complètement différents, et seule l’amplitude d’oscillation de la pointe de sa canne permet de les distinguer. Mais cette fois, vous n’avez pas eu le temps de discriminer — vous avez roulé avant même de voir la canne. Le coup retardé de Margit s’abat exactement sur la dernière frame d’invulnérabilité de votre esquive. YOU DIED.
Neuvième mort. Vous fixez l’écran et commencez à remarquer une chose étrange : plus vous mourez, plus le comportement de Margit devient « lisible ». Pas parce qu’il faiblit — les données du boss ne changent pas d’une mort à l’autre — mais parce que votre cerveau est en train de compiler son répertoire gestuel en un jeu de règles : pointe avancée = ruée triple ; pointe relevée = marteau sacré ; distance supérieure à une corpulence = lancer de dagues. Ces règles sont peu nombreuses, chacune est nette, chacune correspond à une fenêtre de réponse bien définie.
C’est le paradoxe le plus contre-intuitif de l’IA chez FromSoftware : plus elle est simple, plus elle paraît intelligente.
Ce n’est pas de l’IA : c’est un automate à pile
En juin 2026, un article de rétro-ingénierie publié sur nega.tv a fait exploser Hacker News et Lobsters. Son contenu tient en une découverte déconcertante : le système d’IA des ennemis de FromSoftware — de Demon’s Souls à Elden Ring — ne repose ni sur un arbre de comportement, ni sur un planificateur GOAP, et n’a strictement rien à voir avec le deep learning. C’est, fondamentalement, un automate à pile (Pushdown Automaton, PDA), écrit en Havok Script — un dialecte Lua pour le jeu vidéo, aujourd’hui abandonné. La structure de données est plus rustique que celle de l’immense majorité des systèmes d’IA des AAA.
FromSoftware appelle l’unité de base de son IA un « Goal ». Un Goal, c’est une table de fonctions immuables, avec trois callbacks fondamentaux : activate (exécuté au premier lancement ou quand les sous-goals sont épuisés), update (chaque frame, retourne Continue/Success/Failure), interrupt (réponse aux événements extérieurs). Chaque Actor — NPC ou boss du jeu — maintient une pile de Goals. Pas un simple automate fini : un PDA avec pile.
Le runtime est d’une simplicité déconcertante : chaque frame, mettre à jour le Goal au sommet de la pile. Si le Goal courant doit dérouler un sous-comportement, il empile une série de Sub-Goals ; la frame suivante, c’est le plus haut qui s’exécute automatiquement. Goal terminé ? On le dépile. Si un Goal échoue, toute la chaîne de sous-goals saute, et le contrôle revient au Goal parent.
Prenons un CoolBossBattle. La fonction activate du boss contient un ensemble de candidats pondérés : à longue distance, rayon mortel poids 15, attaque sauté poids 65 ; à moyenne distance, coup au sol poids 5, enchaînement léger poids 60, enchaînement lourd poids 35. Les poids sont dynamiques : une attaque en cooldown voit son poids mis à zéro ; plus le boss perd de vie, plus certaines attaques dangereuses gagnent en poids. Chaque cycle de décision se résume à un tirage aléatoire pondéré, puis le Goal correspondant est poussé sur la pile.
Il n’y a pas de « planification ». Le boss ne prédit pas où vous serez dans trois secondes, ne construit pas de modèle du monde, ne fait pas de Monte-Carlo Tree Search. Il se contente de piocher une carte dans son paquet d’actions, selon quelques conditions explicites — distance, cooldown, santé, aléa.
Mais alors, pourquoi est-ce si dur ?
C’est le paradoxe fondateur de la philosophie FromSoftware : rendre le comportement ennemi prévisible, c’est rendre le combat plus difficile — pas moins.
Une confusion courante : « difficile = intelligent ». Mais remémorez-vous les moments où vous avez vraiment jeté la manette : les morts les plus frustrantes ne viennent presque jamais d’une intelligence ennemie trop élevée — elles viennent de votre incapacité à comprendre ce que fait l’ennemi. Quand le NPC semble agir de façon aléatoire, incohérente, ou carrément injuste, le joueur bascule instantanément du mode « je dois m’améliorer » au mode « ce jeu me baise ». L’apprentissage s’arrête. La frustration prend le relais.
FromSoftware fait l’inverse. Le répertoire de chaque boss est fermé. Chaque attaque a son animation d’amorce, ses frames actives, son temps de récupération fixes. Le boss n’« apprend » pas votre style — il répète inlassablement le même tirage aléatoire pondéré. Mais c’est précisément pour ça que vous pouvez l’apprendre. La différence entre la première et la neuvième mort, ce n’est pas que le boss s’est affaibli. C’est que votre cerveau a fait la rétro-ingénierie d’un système déterministe.
Sur Lobsters, icefox lâche une vérité brute : « Être plus malin que l’IA ennemie, c’est un des rares avantages que t’as dans Elden Ring. » Retournée, la phrase est encore plus vraie : FromSoftware a conçu l’IA pour qu’elle soit battable par la ruse — et c’est la condition d’existence de l’expérience de combat de la série.
La formulation d’ingénierie de cette philosophie tient en trois mots : prévisibilité = jouabilité. Le comportement émergent ne naît pas d’un algorithme décisionnel complexe, mais de l’explosion combinatoire de règles simples sous l’effet de comportements joueurs variés. L’attaque retardée est devenue iconique non pas grâce à une IA sophistiquée — juste quelques frames d’attente intercalées dans l’animation du Goal d’attaque. Mais du point de vue du joueur, ça se traduit par : « Apprends à compter les frames. »
Pourquoi les AAA qui foncent sur l’IA ML se plantent
Replacez l’approche FromSoftware dans le paysage actuel de l’IA des AAA, et le contraste devient presque comique.
Depuis dix ans, le récit dominant de l’industrie, c’est « rendons les NPC plus intelligents ». L’arbre de comportement s’est imposé comme standard de fait — Halo 2 en 2004 a été le premier à l’utiliser à grande échelle pour l’IA de combat, et les Halo suivants l’ont poussé à l’extrême. GOAP (Goal Oriented Action Planning) est resté mythifié depuis F.E.A.R. (2005), dont les ennemis savaient prendre à revers, sauter les barricades et crier « il recharge ! ». L’Utility AI a fait ses preuves dans Les Sims pour simuler des routines quotidiennes complexes. Chaque approche est plus sophistiquée que le PDA de FromSoftware — l’arbre de comportement a des nœuds de séquence, de sélection, des parallèles, des décorateurs ; GOAP nécessite une recherche A* dans l’espace des actions ; l’Utility IA attribue un score à chaque option.
Mais la complexité a un coût sous-estimé : la perte de contrôle. Plus le designer s’en remet à un planificateur générique pour assembler automatiquement des séquences comportementales, moins il peut prédire ce que fera le NPC dans une situation donnée. Le problème classique de GOAP, c’est « le planificateur qui décide de défoncer une porte avec une échelle au lieu de l’ouvrir ». La croissance d’un arbre de comportement s’accompagne de la malédiction de « l’arbre que plus personne ne comprend » — Damian Isla de Bungie le disait déjà au GDC il y a quinze ans : la complexité des BT de Halo 3 avait dépassé le seuil à partir duquel un designer ne peut plus comprendre la chaîne causale d’un comportement.
Pour FromSoftware, ce n’est pas un problème — parce qu’ils ne donnent tout simplement pas à l’IA la capacité de « planifier toute seule ». Chaque comportement de boss est chorégraphié frame par frame par les designers. L’animateur décide du nombre de frames d’anticipation et des frames actives. Le designer combat fixe les cooldowns et la distribution des poids. L’« intelligence » perçue par le joueur émerge de la superposition de ces trois couches artisanales — pas d’un algorithme qui improvise.
C’est une ligne de partage en philosophie de l’ingénierie. D’un côté : « donner à l’IA un cadre d’intelligence général et la laisser décider. » De l’autre : « donner aux designers une infrastructure assez simple et assez composable pour qu’ils puissent contrôler manuellement chaque décision de l’IA. » FromSoftware a misé sur la deuxième. Et gagné.
Le système d’interruption : le régulateur de difficulté caché
Au-delà de la pile de Goals et du tirage aléatoire pondéré, le système d’IA de FromSoftware a une troisième jambe : l’interruption.
Chaque Goal peut enregistrer un callback d’interruption. Quand un événement spécifique survient — le joueur utilise un objet, lance un sort, se tient dans une zone spatiale précise derrière le boss — l’événement remonte le long de la pile de Goals jusqu’à ce qu’un callback interrupt retourne true pour signaler « je prends en charge ». La prise en charge peut vider la pile de Goals courante, pousser immédiatement un nouveau Goal d’attaque, ou modifier l’état du Goal parent.
Voilà pourquoi le Bell Bearing Hunter s’élance presque à coup sûr quand vous buvez une fiole : son système d’interruption contient une règle — détection UseItem + 85 % de probabilité → vider l’action en cours, charger immédiatement. Vous croyez que le boss « lit vos inputs » ; en réalité, il répond à un callback événementiel en dur.
L’élégance du dispositif tient à ceci : il permet au designer de contrôler finement la réactivité du boss aux actions du joueur sans polluer la boucle décisionnelle de base. Le comportement courant du boss (distance moyenne → piocher dans la table d’attaques) et son comportement réactif (le joueur boit → l’interrompre immédiatement) empruntent deux canaux logiques indépendants.
Un commentateur HN demande : ce système peut-il gérer des scénarios plus complexes qu’un combat de boss à la Soulsborne ? La réponse de l’auteur de nega.tv : « on peut aller très loin ». Pour une raison simple : la complexité d’un framework PDA dépend du nombre et de la qualité des Goals, pas du framework lui-même. Vous voulez un monde ouvert où chaque villageois a un emploi du temps et un réseau social ? Il vous faudra des centaines de Goals et un orchestrateur sophistiqué. Vous voulez un combat de boss inoubliable ? Une dizaine de Goals et deux cents lignes de Havok Script suffisent.
Retour à l’essentiel : pourquoi le low-tech a gagné
Revenons à la question initiale : pourquoi la machine à états de FromSoftware donne-t-elle un meilleur résultat que l’IA de la plupart des AAA ?
La réponse n’est pas technique, elle est philosophique. FromSoftware n’a jamais traité l’IA comme un outil de « simulation d’intelligence ». Il l’a traitée comme un vecteur de transmission du design de combat. Le comportement du boss est un langage écrit par le designer à l’intention du joueur. Chaque attaque, chaque fenêtre de vulnérabilité, chaque « là, tu peux en placer une » est intentionnel. Quand l’IA devient trop complexe, trop imprévisible, ce langage se brise. Le joueur n’est plus en train « d’apprendre le combat », mais de « subir l’aléatoire ».
Il y a aussi des avantages d’ingénierie plus concrets. L’exécution d’un PDA est bien plus efficace que celle d’un BT — il suffit généralement de mettre à jour le Goal au sommet de la pile, sans reparcourir tout l’arbre depuis la racine. Le système de Goals de FromSoftware écrit le flux de contrôle en code impératif, avec un modèle de données réduit à l’extrême : chaque Actor dispose d’un tableau de floats, les Goals lisent et écrivent par index. Pas de Blackboard, pas de bus d’événements, pas d’arborescence complexe de nœuds condition/séquence/sélecteur. L’auteur insiste dans une mise à jour de son article : dans la plupart des AAA, on voit « des arbres de comportement à des dizaines de milliers de nœuds, avec des centaines de nœuds indépendants qui implémentent le flux de contrôle et les actions », alors que chez FromSoftware, le comportement d’un boss individuel est généralement « assez petit ».
Bien sûr, le PDA n’est pas une potion magique sans contrepartie. Écrire l’IA en Havok Script, c’est dire adieu aux éditeurs visuels de comportement — les designers doivent coder. La difficulté de débogage du système d’interruption croît exponentiellement avec la profondeur de la pile de Goals. Sans planificateur générique, chaque boss est un artisanat sur mesure, non réutilisable — mais pour FromSoftware, ce n’est pas un bug, c’est une feature.
La justesse d’un choix technique ne se mesure pas à son degré d’avancement, mais à son adéquation au problème à résoudre. Le problème de FromSoftware n’est pas « faire une IA plus intelligente », mais « faire des ennemis plus lisibles, plus apprenables, plus justes ». S’ils utilisent un PDA plutôt que GOAP, une machine à états plutôt que du deep learning, ce n’est pas par retard technologique — c’est parce que ce qu’ils veulent, c’est exactement ce que le low-tech peut leur donner.
Cet article s’appuie sur des informations publiques et des discussions communautaires. Si vous avez une expérience directe sur ce sujet, vos corrections et compléments sont bienvenus.