Le développement de jeux par IA chez Capcom s’intègre à RE Engine, malgré les réticences du secteur

Capcom a intégré sa stratégie de développement de jeux par IA à RE Engine, malgré une opposition croissante des développeurs à l’IA générative. Lors d’une conférence technique le 2 octobre, le programmeur Satoshi Ishida a présenté REX, le plan de l’entreprise visant à reconstruire progressivement son socle de production interne.

Cette proposition va plus loin que de laisser un chatbot générer des jeux finis. Capcom veut des systèmes logiciels que l’IA peut lire, modifier, tester et examiner aux côtés des développeurs humains. L’objectif affiché est un « avenir où nous créons des jeux avec l’IA ».

Cette distinction est importante, car Capcom fait ce pari alors que le secteur est profondément divisé. Les studios font face à des projets plus vastes, des cycles de production plus longs et des coûts d’assurance qualité élevés. Pourtant, de nombreux artistes, designers, scénaristes et programmeurs estiment que l’IA générative menace les emplois, la propriété créative et les conditions de travail.

Capcom place sa réponse au cœur du moteur utilisé pour Resident Evil, Monster Hunter et Street Fighter. Si REX fonctionne, l’assistance par IA deviendra une partie de l’infrastructure sous-jacente au développement, plutôt qu’une fonctionnalité visible ajoutée à l’approche de la sortie.

Le développement de jeux par IA chez Capcom commence sous la couche créative

Capcom repense son système de production autour de la compatibilité avec l’IA, sans annoncer une machine capable de générer des jeux complets.

Ishida a présenté ce plan lors de la Capcom Open Conference RE: 2026 à Tokyo. Capcom avait déjà identifié REX, abréviation de RE neXt Engine, comme la prochaine étape de son moteur propriétaire. La présentation d’octobre a donné à cette feuille de route une orientation plus claire vers l’IA.

Le calendrier était délibéré. Le développement de RE Engine a commencé en 2014, et cette technologie a été utilisée pour la première fois avec Resident Evil 7 en 2017. Selon la couverture originale de la conférence REX, Capcom l’a depuis utilisée pour plus de 27 titres.

Un moteur fournit les systèmes partagés servant à créer, exécuter, déboguer et publier des jeux. Il peut gérer les graphismes, l’animation, les données, la physique, les outils, la prise en charge des plateformes et d’autres fonctions techniques. Comme chaque équipe de production en dépend, une modification du moteur peut transformer le travail à l’échelle d’un studio.

Plus de 2 000 développeurs de Capcom utilisent désormais RE Engine, selon le rapport de la conférence. Parmi eux figurent des collaborateurs internationaux et des employés habitués à d’autres environnements de développement. Le système doit donc prendre en charge davantage de personnes, de projets et de méthodes de travail que ses concepteurs d’origine ne l’avaient prévu.

La taille des jeux crée un autre problème. Les sorties modernes regroupent d’immenses collections de personnages, d’animations, d’environnements, d’éléments d’interface et de configurations propres aux plateformes. Même une petite révision peut entraîner des traitements, conversions, validations et tests sur un vaste ensemble de données.

REX vise à résoudre ces goulets d’étranglement sans abandonner les fondations existantes de Capcom. La feuille de route du moteur de l’entreprise décrit une transition progressive qui ajoute de nouvelles technologies à RE Engine au lieu de le remplacer entièrement.

Cette approche progressive réduit les risques liés à la migration. Les équipes peuvent continuer à livrer des jeux tandis que les outils sous-jacents évoluent par étapes. Elle permet également à Capcom de tester des composants individuels en production avant de les généraliser.

La présentation publique a décrit plusieurs systèmes nommés au sein de REX. RE:Dox standardise la manière dont différents types de données sont représentés et traités. RE:UI remplace certaines parties du framework d’interface utilisé par les outils de développement internes.

RE:Log centralise les journaux techniques et les communications. RE:Flows convertit la logique visuelle des jeux en un langage de programmation standardisé. RE:Runtime modifie la manière dont le moteur traite de grands groupes d’objets et de personnages.

Ces composants ne sont pas tous des produits d’IA. Une grande partie du travail immédiat concerne la vitesse, l’utilisation de la mémoire, la cohérence des données, l’automatisation et une collaboration plus simple. Leurs structures communes préparent toutefois le moteur à une assistance machine plus poussée ultérieurement.

L’annonce de Capcom est donc avant tout une histoire d’infrastructure. L’entreprise réorganise les informations que les développeurs et les machines doivent comprendre avant de demander à l’IA d’effectuer un travail plus déterminant.

Pourquoi REX facilite la lecture du moteur par l’IA

REX considère le code et les données standardisés comme une condition préalable à une assistance IA utile.

Les systèmes d’IA rencontrent des difficultés lorsque les outils internes reposent sur des formats incohérents, des comportements non documentés ou du code spécialisé absent de leurs données d’entraînement. Les employés humains rencontrent bon nombre des mêmes obstacles. Les deux groupes bénéficient de systèmes qui suivent des schémas communs.

Capcom affirme que REX rapprochera davantage ses fondations de règles de programmation largement comprises. RE:Flows illustre cette stratégie. Les designers peuvent assembler visuellement le comportement du jeu tandis que l’outil traduit leur travail en code standardisé derrière l’interface.

L’avantage dépasse la simple commodité. Les outils de script visuel enregistrent souvent la logique dans des formats difficiles à réviser, fusionner ou déboguer. Traduire cette logique en code lisible rend la collaboration et l’analyse automatisée plus pratiques.

Un assistant IA pourrait à terme examiner cette sortie, expliquer une défaillance, proposer une modification ou générer un test. Le développeur définirait toujours le comportement attendu. La machine agirait sur une représentation technique cohérente.

RE:Dox applique une idée similaire aux données. Les jeux comportent de nombreux formats spécialisés, chacun avec ses propres règles et dépendances. Un modèle de données commun peut réduire le travail de conversion tout en permettant aux systèmes automatisés de suivre plus facilement les relations.

RE:Log crée la couche d’observation. Les journaux enregistrent les erreurs, les avertissements, les événements de performance et d’autres activités pendant le développement. La centralisation de ces enregistrements offre aux ingénieurs un historique consultable au lieu de disperser les éléments de preuve sur des machines individuelles.

Cet historique peut servir au diagnostic humain aujourd’hui et au diagnostic assisté par IA demain. Un modèle pourrait comparer une nouvelle défaillance à des incidents précédents, identifier les changements pertinents et suggérer des causes probables. Sa valeur dépendrait d’enregistrements précis et d’un accès contrôlé.

Capcom a déjà manifesté son intérêt pour les systèmes de connaissance institutionnelle. Son programme de conférence comprenait REAssistAI, une interface interne de grand modèle de langage permettant d’accéder à 10 ans de connaissances techniques accumulées. Ce projet se situe en dehors des cinq composants REX détaillés dans la présentation principale, mais il suit la même logique.

L’entreprise transforme en pratique l’historique du développement en contexte lisible par machine. Cette approche ressemble à une base de connaissances d’ingénierie spécialisée, où la documentation et les enregistrements restent reliés au travail technique quotidien.

RE:UI contribue par sa testabilité. Capcom a conçu le framework d’interface de sorte que les logiciels puissent examiner les composants sans qu’une personne ait besoin de surveiller l’écran. Cette séparation facilite l’exécution et la répétition de tests automatisés.

RE:Runtime s’attaque aux performances d’exécution. Plutôt que de gérer chaque objet séparément, le système regroupe le travail en blocs pouvant être traités plus efficacement. Il traduit également le code convivial pour les développeurs vers le langage RE:C++ orienté performance de Capcom.

Aucune de ces évolutions ne signifie que l’IA peut concevoir de manière indépendante un niveau convaincant de Resident Evil. Elles établissent une surface opérationnelle plus nette sur laquelle les outils automatisés peuvent agir. Capcom réduit d’abord l’ambiguïté qui rend le travail humain comme machine peu fiable.

C’est le mécanisme qui sous-tend l’affirmation plus large de l’entreprise. L’IA ne devient utile qu’après que le moteur a exposé le code, les données, les journaux, les tests et les flux de travail sous des formes que les logiciels peuvent interpréter de manière cohérente.

Le véritable conflit oppose l’assistance au remplacement

Capcom présente l’IA comme un partenaire de production, alors que de nombreux développeurs y voient une voie vers leur remplacement.

Les cas d’usage privilégiés par l’entreprise se concentrent sur le travail interne. Ishida a décrit un avenir dans lequel l’IA peut comprendre des programmes, créer du code, exécuter des sessions de test et vérifier les builds à la recherche de défauts. Ces tâches entourent le processus créatif, mais elles peuvent tout de même influencer qui réalise le travail.

Les tests en fournissent un exemple clair. Un grand jeu exige des vérifications répétées sur les personnages, les environnements, les configurations matérielles et les actions des joueurs. Des agents automatisés peuvent exécuter des scénarios prévisibles pendant plus longtemps qu’un testeur humain.

Le programme de conférence de Capcom présentait séparément des tests autonomes évaluant à la fois la vidéo et l’audio. De tels systèmes peuvent aider à détecter plus tôt les défaillances reproductibles. Ils ne peuvent pas déterminer automatiquement si un combat paraît équitable, si une blague fonctionne ou si une séquence d’horreur crée la tension voulue.

L’assistance au code présente une division comparable. L’IA peut rédiger des implémentations routinières, rechercher de la documentation ou identifier des erreurs courantes. Les ingénieurs doivent toujours évaluer l’architecture, les performances, la sécurité, la maintenabilité et les conséquences d’une suggestion erronée.

Cette vérification humaine n’est pas une simple étape finale mineure. Les moteurs de jeu fonctionnent sous de fortes contraintes de mémoire et de temps sur plusieurs plateformes. Une réponse plausible d’un modèle peut néanmoins introduire des défaillances subtiles qui n’apparaissent que sous certaines charges.

Capcom a déjà expérimenté l’IA générative dans d’autres domaines. Google affirme que l’éditeur utilise Vertex AI et Gemini pour générer de vastes ensembles d’idées de décors et d’objets de jeu. Son projet d’IA Capcom a été présenté comme un moyen d’accélérer le brainstorming plutôt que d’intégrer directement des ressources générées aux jeux publiés.

Ce projet antérieur aurait traité une tâche particulièrement répétitive. Les équipes avaient parfois besoin de centaines de milliers d’idées d’arrière-plan pour développer un univers fictif cohérent. Les modèles pouvaient produire des candidats initiaux dans certaines contraintes, laissant aux employés le soin d’en évaluer la pertinence et la qualité.

REX élargit le périmètre, passant du brainstorming à la production technique. Il s’agit d’une escalade significative, même si Capcom maintient l’art généré par IA en dehors des jeux publiés. La génération de code, les tests automatisés et l’analyse des journaux influencent tous les calendriers, les effectifs et les responsabilités.

Le contexte social rend ces choix sensibles. L’enquête 2026 auprès des développeurs a recueilli les réponses de plus de 2 300 professionnels de l’industrie du jeu. Elle a constaté que 36 % utilisaient l’IA générative dans leur travail.

L’adoption ne s’est pas traduite par une approbation. Cinquante-deux pour cent ont déclaré que l’IA générative avait un impact négatif sur le secteur, contre 30 % un an plus tôt. Seuls 7 % considéraient son impact comme positif.

L’opposition était particulièrement forte parmi les travailleurs les plus proches de la production de jeux. Les réponses négatives atteignaient 64 % chez les artistes visuels et techniques, 63 % chez les professionnels du design et de la narration, et 59 % chez les programmeurs.

Ces résultats créent la tension centrale du développement de jeux par IA chez Capcom. La direction peut voir l’automatisation comme une protection contre l’augmentation des coûts de production. Les travailleurs peuvent considérer le même investissement comme une pression sur des fonctions déjà touchées par les licenciements.

Capcom n’a pas annoncé que REX supprimerait des postes. L’entreprise n’a pas non plus fourni de garanties d’effectifs liées au projet. Une lecture responsable se situe entre l’hypothèse d’une assistance inoffensive et l’affirmation d’un plan de remplacement automatisé.

La question décisive sera la manière dont Capcom mesure le succès. Si l’entreprise évalue REX à l’aune de délais d’attente réduits, d’une détection plus précoce des bugs et d’un moindre nombre de tâches répétitives, l’argument du partenariat gagne en crédibilité. Si la réduction des effectifs devient le principal résultat, la crainte du remplacement sera plus difficile à écarter.

Les questions de droit d’auteur, de sécurité et de fiabilité restent sans réponse

Un moteur lisible par machine ne permet pas de déterminer qui possède les données d’entraînement, qui approuve le code généré ou qui assume la responsabilité lorsque l’automatisation échoue.

Capcom reconnaît plusieurs de ces risques. Dans un dialogue avec les investisseurs publié par l’entreprise, celle-ci indique déjà utiliser l’IA pour la vérification des bugs et l’efficacité de RE Engine. Elle a également identifié le droit d’auteur, la sécurité des données et la formation des spécialistes comme des préoccupations persistantes.

Les questions de droit d’auteur dépendent du système et de ses données d’entrée. Un outil entraîné en interne à partir de code Capcom approuvé présente des risques différents de ceux d’un modèle public entraîné sur des dépôts inconnus. La présentation de la conférence n’a pas fourni de politique complète de gouvernance des modèles.

L’ouverture de technologies sélectionnées ajoute une autre complication. Capcom prévoirait de publier certaines parties de RE:Dox et RE:Log afin que les développeurs externes et les systèmes d’IA puissent les comprendre. Le code open source peut améliorer la documentation, les tests et l’interopérabilité.

Il peut aussi révéler des détails architecturaux nécessitant un examen attentif de la sécurité. Capcom doit séparer l’infrastructure réutilisable des systèmes propriétaires, des identifiants, des données de jeu et des informations de production non publiées. Un dépôt public ne suffit pas, à lui seul, à établir une utilisation sûre de l’IA.

Les fuites de données constituent une préoccupation plus immédiate sur le lieu de travail. Les développeurs pourraient exposer du code ou des ressources confidentiels si les prompts sortent d’environnements contrôlés. Les règles d’accès en entreprise, la journalisation, les limites de conservation et l’isolation des modèles compteront autant que les capacités des modèles.

La fiabilité constitue un risque distinct. Les grands modèles de langage produisent des résultats probables plutôt que des décisions d’ingénierie vérifiées. Ils peuvent inventer des API, négliger des contraintes de plateforme ou recommander un code qui compile mais se comporte incorrectement.

Les tests automatisés reflètent également les tests qu’ils reçoivent. Un agent peut accomplir à répétition un parcours scripté tout en passant à côté de comportements inattendus des joueurs. Il pourrait confirmer la stabilité technique sans reconnaître une conception déroutante, des problèmes d’accessibilité ou une rencontre peu intéressante.

REX pourrait réduire certains échecs en reliant la génération à l’exécution et à la validation. Un assistant qui écrit du code, le compile et lance des tests reçoit de meilleurs retours qu’un assistant travaillant à partir d’un prompt isolé. Il a néanmoins toujours besoin de critères d’acceptation définis par des humains.

La qualité créative reste plus difficile à formaliser. Les jeux de Capcom reposent sur le rythme, la direction artistique, la composition des niveaux, les performances et des attentes délibérément construites chez les joueurs. Ces qualités émergent de l’itération et du jugement, et non simplement d’un code valide.

Pragmata confère à cette annonce un contexte culturel inhabituel. Son récit de science-fiction explore une dépendance dangereuse à l’intelligence artificielle. La stratégie de production de Capcom n’est pas équivalente à cette fiction, mais le contraste met en évidence une question réelle.

L’entreprise demande aux développeurs de faire confiance à l’IA au sein du système utilisé pour créer ses propriétés les plus précieuses. Cette confiance doit reposer sur des garde-fous visibles, des résultats exacts et une responsabilité clairement établie. Un slogan sur la collaboration ne peut remplacer ces contrôles.

La plus grande question sans réponse concerne donc la gouvernance. Qui peut autoriser les modifications générées, et comment ces modifications sont-elles étiquetées ? À quelles données les modèles peuvent-ils accéder, et combien de temps sont-elles conservées ?

Capcom doit aussi déterminer si les réviseurs humains disposent de suffisamment de temps pour contester les résultats automatisés. L’assistance par IA peut accroître le volume de code proposé plus vite que les équipes ne peuvent l’inspecter de manière responsable. Une génération plus rapide ne garantit pas une production plus rapide.

Un programme crédible suivrait les défauts passés en production, les faux positifs, le temps de revue, les incidents de sécurité et l’expérience des employés. Capcom n’a pas encore publié ces mesures. En attendant, REX reste une orientation technique plutôt qu’une réforme de production éprouvée.

Trois signaux montreront si la stratégie d’IA de Capcom fonctionne

Les prochaines preuves devront venir d’outils opérationnels, de garde-fous divulgués et de résultats de développement mesurables.

Le premier signal sera la publication et l’adoption des composants de REX. Capcom affirme que la transition sera progressive, ce qui facilite l’évaluation des systèmes individuels. RE:Dox, RE:UI, RE:Log, RE:Flows et RE:Runtime devraient produire des changements observables avant l’arrivée de la vision plus large de l’IA.

Des éléments utiles comprendraient des temps d’itération plus courts, moins de gels des outils, un traitement des données plus rapide ou des tests automatisés plus fiables. Les démonstrations devraient présenter des conditions de production plutôt que des exemples limités en laboratoire.

L’activité open source apportera un autre indicateur. Le code public, la documentation, l’historique des problèmes et les contributions externes peuvent révéler si les technologies REX sélectionnées sont suffisamment matures pour être examinées. Ils peuvent également préciser quelles parties restent internes.

Le deuxième signal sera la politique de gouvernance de Capcom. L’entreprise a reconnu les préoccupations liées au droit d’auteur et à la sécurité, mais cette reconnaissance ne définit pas des règles opérationnelles. Les développeurs doivent savoir quelles données les modèles utilisent et quelles décisions exigent une approbation humaine.

La communication devrait distinguer l’automatisation conventionnelle de l’IA générative. Un système qui regroupe des objets d’exécution n’est pas équivalent à un modèle qui génère du code source. Les réunir sous une même étiquette d’IA rend moins précise à la fois l’évaluation technique et la discussion sur le travail.

Capcom devrait également expliquer si le code généré reçoit une provenance identifiable. Les réviseurs ont besoin d’un enregistrement indiquant quel modèle a produit une modification, quel contexte il a reçu et quel employé l’a approuvée. Cet enregistrement devient important lorsque des défauts apparaissent plus tard.

Le troisième signal sera ce qui arrivera aux équipes de production et aux calendriers. Capcom fait face à des besoins d’investissement croissants à mesure que les jeux deviennent plus sophistiqués. Ses propres rapports indiquent que l’entreprise souhaite améliorer ses rendements tout en continuant d’accroître ses ventes.

Si REX élimine l’attente et le travail répétitif, les équipes devraient disposer de davantage de temps pour la conception, l’optimisation et les tests centrés sur les joueurs. Ce résultat appuierait l’affirmation de Capcom selon laquelle l’IA agit comme un partenaire.

Si les calendriers continuent de s’allonger tandis que les charges de travail s’intensifient, l’argument d’efficacité s’affaiblit. Il en va de même si l’adoption de l’IA s’accompagne d’une diminution des recrutements de débutants ou du rétrécissement des équipes de test sans de meilleures données de qualité.

Le sentiment du secteur restera un contrepoids utile. L’enquête GDC montre que l’utilisation et l’acceptation peuvent évoluer dans des directions opposées. Les développeurs peuvent adopter des outils parce que leurs employeurs l’exigent tout en continuant d’en remettre en question la valeur.

Le comportement des concurrents compte également. Unreal Engine est le moteur principal de 42 pour cent des développeurs dans l’enquête de 2026, tandis que Unity représente 30 pour cent. Leurs outils d’IA établissent une référence externe pour la plateforme interne de Capcom.

Capcom n’a pas besoin que REX gagne le marché des moteurs, car l’entreprise ne vend pas RE Engine comme produit commercial généraliste. Elle doit toutefois faire en sorte que ses outils internes rivalisent avec les fonctionnalités accessibles aux studios utilisant de plus grandes plateformes externes.

Le contrôle de son moteur donne un avantage à l’entreprise. Capcom peut connecter directement les outils d’IA à ses formats de données, ses systèmes de compilation, son infrastructure de test et son historique technique. Elle n’a pas besoin d’attendre la feuille de route d’un fournisseur tiers.

Ce contrôle concentre également la responsabilité. Capcom ne peut pas reprocher à un fournisseur de moteur externe des flux de travail peu fiables ou des garde-fous insuffisants produits par REX. L’entreprise est responsable de l’architecture, de la mise en œuvre et des conséquences sur le lieu de travail.

L’interprétation la plus crédible du développement de jeux par IA chez Capcom n’est ni la créativité autonome ni le simple marketing. Il s’agit d’un effort à long terme visant à rendre l’environnement technique du studio compréhensible à la fois par les personnes et les machines.

Cet effort commence par une ingénierie peu spectaculaire : des données standardisées, un code lisible, des journaux centralisés, des interfaces plus rapides et des tests reproductibles. L’IA devient la couche suivante, et non l’intégralité de la fondation.

Pour les développeurs, la question immédiate n’est pas de savoir si un modèle peut créer un jeu complet. Elle est de savoir si l’IA peut éliminer des frictions mesurables sans affaiblir la responsabilité, le jugement ou les conditions d’emploi.

Surveillez les publications de REX, les garde-fous de Capcom et les résultats vécus par les équipes de production. Ces signaux détermineront si « créer ensemble » décrit une collaboration productive ou une formulation plus douce pour désigner le transfert du travail loin des personnes.