Quatre objectifs, et aucun ne promet de fabriquer un Resident Evil en appuyant sur un bouton : efficacité du développement, performances du jeu, outils de production et assurance qualité. Présenté le 2 octobre 2026 à la Capcom Open Conference RE:2026, le projet REX mérite d’abord d’être lu comme un chantier d’ingénierie. Capcom veut faire évoluer le RE Engine par étapes, pas jeter son moteur et recommencer à zéro.
Ce qui retient mon attention n’est pas l’étiquette IA. C’est la place accordée aux formats de données, aux interfaces des outils et à la journalisation. Ces éléments font rarement une bande-annonce spectaculaire. Ils déterminent pourtant combien de temps une équipe passe à créer, puis combien elle en perd à convertir, vérifier et réparer. L’ambition de REX se situe là : rendre la production plus régulière, plus exploitable par les développeurs et, ensuite, par des systèmes d’assistance automatisée.
| Élément | Ce que Capcom annonce |
|---|---|
| Programme | REX Project, évolution progressive du RE Engine |
| Présentation | Capcom Open Conference RE:2026, le 2 octobre 2026 |
| Intervenant technique | Satoshi Ishida, programmeur chez Capcom |
| Objectifs | Efficacité du développement, performances, outils et assurance qualité |
| Orientation architecturale | Standardisation des données et du code, avec une unification autour de C++ |
| Rôle de l’IA | Assistance aux processus internes de développement |
| Contenus livrés | Capcom exclut les éléments visuels, sonores ou artistiques générés par IA dans ses jeux |
| Mesures disponibles | Aucun gain chiffré public sur les délais, les performances ou les bugs |
| Déploiement | Pas de calendrier public détaillé par composant, studio ou jeu |
La donnée décisive est la première : REX reste une évolution du RE Engine. Cela préserve les investissements existants, mais impose de moderniser un système utilisé en production. Le calendrier des transitions comptera autant que la qualité des nouveaux composants. Une architecture prometteuse peut devenir coûteuse si les équipes doivent entretenir durablement deux façons de travailler.
Le RE Engine s’est fait connaître avec Resident Evil 7 en 2017. Resident Evil 2 et Devil May Cry 5, sortis en 2019, ont ensuite montré qu’il pouvait soutenir des productions différentes. Cette continuité compte : un moteur propriétaire n’est pas seulement un système de rendu. Il rassemble des outils, des bibliothèques, des conventions et un savoir-faire accumulé par les équipes.
Capcom identifie trois difficultés auxquelles REX doit répondre. La taille des jeux rend les processus longs. L’augmentation des équipes exige des outils utilisables par davantage de personnes. L’intégration de l’IA nécessite enfin un environnement capable de soutenir ces nouveaux usages. Le dernier point attire les regards, mais les deux premiers justifient déjà une modernisation sans aucune fonction générative.
Un outil qui fonctionne pour quelques spécialistes peut devenir un obstacle lorsqu’il passe entre les mains de plusieurs métiers. Les conversions manuelles se multiplient, les erreurs deviennent difficiles à reproduire et les connaissances restent concentrées chez ceux qui connaissent les particularités du moteur. REX cherche à réduire ces frictions. C’est moins séduisant qu’une démonstration graphique, mais beaucoup plus proche du quotidien d’une production.
La démarche rappelle une constante de l’histoire des moteurs propriétaires : leur longévité dépend de leur capacité à renouveler leurs fondations sans perdre les compétences construites autour d’eux. Conserver le nom du moteur ne signifie pas conserver toutes ses décisions techniques. À l’inverse, annoncer une nouvelle appellation ne prouve pas qu’une rupture architecturale a eu lieu.
Le programme comprend plusieurs briques identifiées. Elles éclairent la direction technique de REX, sans constituer un calendrier de migration : Capcom ne détaille pas publiquement quels composants seront modernisés à chaque phase. Surtout, leur fonction principale n’est pas nécessairement liée à l’IA.
| Composant | Fonction annoncée | Enjeu de production |
|---|---|---|
| RE:Dox | Standardiser le traitement des données entre plusieurs formats | Réduire les incompatibilités et les conversions entre outils |
| RE:UI | Séparer l’apparence des outils de leur état fonctionnel | Faciliter leur évolution et leurs tests |
| RE:Log | Utiliser des identifiants et centraliser les enregistrements | Rendre les événements plus structurés et réduire les données à traiter |
| RE:Flows | Convertir des graphes de scripting visuel en code standard | Rapprocher la conception visuelle et l’implémentation |
| RE:Runtime | Réorganiser l’exécution autour du traitement par lots | Mieux gérer de nombreux personnages ou entités |
| RE:C++ | Fournir une couche d’exécution optimisée dans la modernisation du moteur | Soutenir la cohérence du code et du runtime |
RE:Dox traite un problème de circulation des données. Lorsqu’une information traverse plusieurs logiciels, chaque conversion constitue un endroit où elle peut être modifiée, mal interprétée ou rejetée. Standardiser ces échanges peut supprimer du travail répétitif. Cela rend également les données plus faciles à exploiter automatiquement, mais cette seconde propriété ne transforme pas le système en IA générative.
RE:UI s’attaque à une autre dépendance : celle entre ce qu’un outil affiche et ce qu’il fait. Séparer son apparence de son état fonctionnel permet, en principe, de tester davantage de comportements sans passer systématiquement par toute l’interface. Le bénéfice potentiel est une maintenance moins fragile. Il dépendra néanmoins de la qualité des interfaces internes et de la discipline avec laquelle elles seront utilisées.
RE:Log remplace une journalisation essentiellement textuelle par des événements identifiés. Pour un système automatisé, un identifiant stable est plus simple à classer qu’une phrase dont la formulation change. Pour les humains, il faudra conserver une restitution lisible et suffisamment de contexte. Une erreur parfaitement indexée, mais incompréhensible pour le programmeur qui doit la corriger, reste une erreur mal documentée.
Enfin, RE:Flows ne doit pas être confondu avec une génération créative par IA. Convertir un graphe visuel en code standard relève d’une chaîne de traduction logicielle. L’intérêt est de limiter la distance entre une logique assemblée visuellement et son exécution. La qualité du code produit, sa facilité de débogage et la possibilité de retrouver l’origine d’un comportement seront plus importantes que le simple fait de produire du code automatiquement.
En mars 2026, lors d’une réunion avec ses actionnaires, Capcom a indiqué qu’il n’intégrerait pas de contenus générés par IA dans ses jeux. L’entreprise a simultanément présenté l’IA comme une technologie susceptible d’améliorer l’efficacité du développement, en citant les graphismes, le son et la programmation. Ces deux positions ne sont pas contradictoires : assister un processus ne signifie pas générer son résultat artistique final.
La programmation mérite une précision particulière. Une assistance capable de proposer du code n’a pas le même rôle qu’un système produisant une texture, une illustration ou une voix livrée au joueur. La politique annoncée sur les contenus artistiques ne décrit donc pas, à elle seule, toutes les règles applicables au code assisté. Les catégories doivent rester distinctes si l’on veut comprendre ce que Capcom autorise réellement.
La formule présentant REX comme un moteur de jeu de la « génération IA » brouille cette distinction. Le mot génération peut évoquer une fabrication automatique du jeu, alors que le programme décrit surtout une infrastructure adaptée à l’assistance au développement. Rien ne permet d’en déduire un moteur autonome qui inventerait les niveaux, les personnages et leurs dialogues.
Une frontière reste peu détaillée : celle des prototypes, références temporaires et contenus non livrés. Capcom n’a pas publié le périmètre opérationnel complet de sa politique pour ces usages. Il faut conserver cette limite sans la transformer en accusation ni en garantie supplémentaire. L’engagement sur les contenus finaux est clair ; les règles de tous les espaces intermédiaires ne le sont pas encore.
Satoshi Ishida décrit une réorganisation autour d’un langage largement utilisé, avec une unification du code autour de C++. La logique est compréhensible : des conventions plus homogènes facilitent la lecture, les échanges entre équipes et l’exploitation par des outils automatisés. Pour un système d’assistance, un environnement régulier est moins difficile à interpréter qu’un ensemble de langages et de conventions disparates.
Mais comprendre une syntaxe ne signifie pas comprendre un moteur. Une fonction peut paraître correcte et violer une règle interne de gestion mémoire. Un changement peut réussir un test isolé et provoquer un problème de synchronisation ailleurs. En C++, la durée de vie des objets, les accès concurrents et les coûts cachés exigent une attention que la lisibilité du langage ne remplace pas.
Capcom envisage une assistance à l’analyse et à la production de certaines parties du code. Le détail des outils, des modèles et de leur intégration n’est pas publié. Il serait prématuré d’attribuer à REX un assistant précis ou un processus déjà généralisé. La standardisation prépare le terrain ; elle ne démontre ni la fiabilité des propositions ni leur conformité aux conventions internes.
Le bon indicateur ne sera donc pas le volume de code produit. Ce sera le temps nécessaire pour obtenir un changement relu, intégré, testé et maintenable. Une proposition rapide qui réclame une longue vérification peut simplement déplacer le travail. Ce déplacement compte dans le bilan, même lorsqu’il disparaît des démonstrations.
REX peut agir sur plusieurs temps morts : conversions de données, maintenance des outils, investigation des erreurs et passage d’une logique visuelle à une implémentation. Ces améliorations ont une valeur cumulative. Leur effet sur la date de sortie dépend toutefois d’une condition souvent négligée : elles doivent toucher les tâches qui bloquent réellement la production.
Un jeu n’avance pas comme une seule file de tâches interchangeables. La conception peut attendre une décision artistique ; une séquence peut dépendre d’une animation ; la validation finale peut attendre une correction difficile. Accélérer un outil utilisé en amont ne raccourcit pas automatiquement ces étapes. Si le goulet d’étranglement reste ailleurs, une partie du gain sera absorbée avant d’atteindre le calendrier général.
Capcom ne chiffre pas encore le gain attendu en jours ou en mois. Aucun résultat public ne compare un même projet réalisé avec le RE Engine actuel et avec l’ensemble de REX. On ne dispose pas non plus d’une mesure des temps de compilation, du taux de bugs ou du coût de validation. Promettre des sorties plus rapprochées dépasserait donc ce que le programme établit.
La transition aura elle-même un coût. Les équipes devront adopter les nouvelles conventions, adapter leurs outils et vérifier la compatibilité des données. La modernisation incrémentale évite une rupture immédiate, mais elle entraîne une coexistence entre systèmes anciens et nouveaux. Les passerelles nécessaires peuvent devenir un investissement temporaire raisonnable ou une charge persistante si leur retrait n’est pas organisé.
La question professionnelle à suivre est celle du bilan net : temps économisé sur les opérations récurrentes, moins temps consacré à la migration, à la revue et à la maintenance supplémentaire. C’est ce bilan qui permettra de juger REX. Pas une démonstration montrant seulement une tâche devenue plus rapide.
L’assurance qualité figure parmi les quatre objectifs de REX, et Capcom envisage l’IA pour assister la vérification des jeux. L’intégration concrète n’est pas détaillée. Il faut donc distinguer l’ambition d’automatiser davantage de validations d’une solution déjà opérationnelle, dont on connaîtrait les scénarios couverts et les résultats.
Un test automatisé est utile lorsqu’il vérifie une propriété précise et reproductible. Il peut confirmer qu’une action aboutit, mais pas nécessairement qu’elle est intéressante. Il peut détecter une anomalie, sans expliquer immédiatement sa cause. La qualité d’une campagne dépend aussi des situations qu’elle ne rencontre jamais : comportements inhabituels, enchaînements rares ou interactions entre systèmes.
Les faux positifs constituent un autre coût. Une équipe saturée d’alertes peu pertinentes doit consacrer du temps à les trier. À l’inverse, une erreur non détectée peut créer un sentiment de sécurité trompeur. Capcom ne publie encore ni taux de détection ni mesure de couverture. L’intérêt potentiel est réel, mais le nombre de tests exécutés ne suffit pas à mesurer la qualité obtenue.
Le traitement par lots annoncé pour RE:Runtime concerne notamment la gestion d’un grand nombre de personnages. Au lieu de multiplier certaines opérations isolées, cette approche regroupe des travaux compatibles. Elle peut limiter des surcoûts d’exécution et améliorer l’organisation du traitement. RE:C++ accompagne cette modernisation avec une couche d’exécution optimisée.
Ce principe n’a rien de spécifiquement génératif. Il relève de l’architecture d’exécution. Il implique aussi des compromis : le regroupement doit respecter les dépendances entre entités et les comportements qui nécessitent un traitement particulier. Une scène dense comprend bien davantage que le seul coût de mise à jour de ses personnages.
Aucune cible publique ne fixe un nombre maximal de personnages, un gain CPU ou GPU, une résolution ou une fréquence d’images. Aucun comportement propre à une plateforme ne peut être déduit de l’annonce. REX ne permet donc pas de promettre un mode 60 images par seconde ou de garantir l’amélioration d’un jeu existant. Ces conclusions nécessiteront des mesures sur des productions identifiées.
Capcom annonce vouloir ouvrir certains composants de REX pour contribuer à l’entraînement de systèmes d’IA. La portée de cette ouverture n’est pas détaillée : composants concernés, licences et modalités d’entraînement restent à préciser. Elle ne signifie pas que le RE Engine complet devient un moteur libre ou qu’une licence destinée aux studios externes est annoncée.
Pour les équipes, le sujet important sera la gouvernance des données. Capcom ne précise pas les modèles utilisés, leur hébergement ou leurs droits d’accès aux dépôts et aux ressources propriétaires. Une assistance interne doit pouvoir respecter des frontières entre projets, conserver une traçabilité des changements et protéger les informations qui ne doivent pas quitter leur environnement.
La dépendance à ces nouveaux outils mérite également d’être suivie. Si une opération devient indispensable au quotidien, sa disponibilité et son coût de maintenance entrent dans celui du moteur. C’est une préoccupation de longévité, pas une objection de principe à l’IA : une infrastructure de production doit rester exploitable pendant des années.
REX s’adresse d’abord aux équipes de Capcom. Pour les responsables techniques d’autres studios, l’intérêt est méthodologique : mettre de l’ordre dans les données, les interfaces et les conventions avant de multiplier les fonctions d’assistance. Ajouter de l’IA à une chaîne incohérente risque d’accélérer la circulation de ses erreurs plutôt que de les résoudre.
Pour les joueurs, aucun prix, abonnement ou équipement spécifique n’est annoncé. Il n’y a pas de décision d’achat à prendre sur cette base. Les exigences matérielles et les performances devront être examinées jeu par jeu. En octobre 2026, aucun titre commercial n’est officiellement identifié comme démonstrateur complet du programme.
Aucun lien officiel n’est établi entre Re-Legion et REX. Il ne faut donc pas attribuer à ce jeu une migration du moteur, un correctif ou une compatibilité particulière. Le sujet est ici le socle de production de Capcom, pas une nouvelle version de Re-Legion.
Le programme mérite une appréciation technique, pas une note de produit testé. Ses orientations peuvent être jugées aujourd’hui ; leurs résultats demanderont un déploiement et des mesures.
Ce qui m’intéresse dans REX, c’est la reconnaissance d’un problème structurel : des productions plus grandes exigent des outils plus cohérents, pas seulement davantage de puissance. Standardiser les échanges, rendre les erreurs exploitables et séparer les responsabilités des outils peut améliorer durablement le travail. Ces bénéfices restent pertinents même si les fonctions d’IA évoluent ou changent de fournisseur.
Accédez à des stratégies exclusives, des astuces cachées et des analyses pro que nous ne partageons pas publiquement.
Guide stratégique ultime Tech + Astuces pro hebdomadaires