 On sait utiliser tous les outils. Théoriquement, on est capable de créer des jeux tout seuls. Ils sont très moches, ils ne fonctionneront pas très bien. Il ne sera peut-être pas très très fun, mais on peut faire un jeu. Je m'appelle Michael Troger et je suis l'EDTE. Je m'appelle Geoffrey Avoyard et je suis testeur outil ADTE. Moi, je suis Marie et je suis l'associé-quide de l'ADTE. Ça veut dire Debug & Test Environment. Ça consiste à tester tous les outils qui sont produits en internaquantique et s'assurer à leur bonne livraison à tous les développeurs. Ce qu'on appelle outils, ce sont les logiciels créés par la R&D de Quantic Dream pour ce qu'on appelle les équipes de production qui créent le jeu pour comment parler. En fait, c'est tous les outils Quantic Dream. Donc, c'est B2R, Popcorn, Encyclop, tout ce qui est les plugs Maya, donc des outils supplémentaires par dessus Maya. Et tous les outils qu'on ne vous a pas encore présentés comme Lime ou Finalize, par exemple. Toutes la tout le chaine de Quantic y passe par nous. Tout, tout, tout, tout. On travaille tout le monde. L'ADTE, ce n'est pas du tout un QA dans le sens où on teste absolument pas le jeu, on teste vraiment les logiciels qui permettent de le faire. Et le QA est vraiment un test le jeu, à proprement parler. Une fois qu'il est passé par les équipes de production qui ont fait le jeu, eux étaient vraiment, vraiment le jeu final. Pour moi, je suis arrivé sur R&D et sur R&D, en fait, il n'y avait pas d'ETE, il y avait des tests routiques qui étaient intégrés au QA. Et à un moment, la décision était prise de faire une équipe dédiée à ça, en fait, parce qu'il y a beaucoup, beaucoup de logiciels faits par la R&D à Quantic, du coup, il faut quand même des gens dédiés uniquement à ça. L'intérêt principal dans un tel service c'est qu'on permet aux équipes qui produisent le jeu d'avoir des outils stables et d'avoir des outils dans lesquels ils ont confiance et de pouvoir continuer à produire même quand il y a des énormes changements de tech parce qu'en fait, on les teste en amont et on leur livre quelque chose qui est extrêmement utilisable. Par exemple, on a fait un changement de tech complet pendant des trois, on a changé l'intégralité des outils quasiment et il y a eu zéro jour d'arrêt de production parce que tout a été testé en amont, en fait. Je pense que c'est un vraiment imparique qu'ils ont fait ici d'avoir un service de test de routiers intégré à l'entreprise directement. Et c'est un choix, je pense, qui a été payant, vraiment. L'intégralité du process de la DTE, ça commence par ce dont ont besoin les équipes qui produisent le jeu. Ils ont besoin de correctifs pour les bugs, de nouvelles fitures, de nouvelles choses pour permettre d'avancer le jeu, en fait. Donc ils font les demandes à la production. Nous, on va consulter la production. Eh, vous avez besoin de quoi ? À ce moment-là, la production nous fait une liste de ce dont ils ont besoin. Nous, on récupère la liste, on la met dans les outils. On vérifie que ça ne casse pas l'intégralité de la touch-chain. C'est quand même mieux. Une fois qu'on a bien vérifié que les nouvelles fitures étaient bien là, qu'elles ne cassaient rien, que personne n'avait rien cassé à droite en tapant à gauche, on livre les outils dans ce qu'on appelle une SP. Ce qu'on appelle un service pack, c'est un ensemble de fitures et de correctifs pour les équipes de production. C'est nous qui décidons en accord avec les équipes de production de ce qu'on met dedans. On crée une version des outils avec ça. On la teste, on la livre. Et il y en a une tous les 15 jours. À peu près. Modulo. Modulo, les bugs. Ça consiste d'abord à reproduire un bug, j'ai retrouvé un, pour le reproduire si on a déjà vu qu'on n'a pas encore les steps ou la manière exacte de déclencher ce bug. Ensuite, ça consiste à l'entrée d'Angira, qui est la base de données qu'on utilise pour traquer tous les bugs, qui recense tous les bugs que j'ai rentrés personnellement et qui sont triés par outils, par équipes, par sévérité, par priorité. Un jeu comme des trois, en termes de bugs, outils, plusieurs milliers, en termes de bugs au total, avec les bug-jeux, avec les bug-outils, on était largement dessus des 10 000 bugs. Pour travailler à la DTE, ce qui est bien, c'est d'être curieux. C'est vraiment un bric gourou, bien sûr, ce genre de choses, mais être curieux, c'est très important. Il faut vraiment avoir le réflexe de, tiens, qu'est-ce que ça va faire si je fais ça ou si je fais pas ça. Vu qu'on a beaucoup d'outils à tester, beaucoup de versions de ces outils, il faut réussir à garder une idée de qu'est-ce qui est fonctionnel sur quel outil, sur quel version de cet outil et de derrière savoir si ça va servir de cet outil, au moins de manière à produire le même travail que les développeurs d'arrêt. Alors nous, l'avantage, c'est qu'on travaille absolument avec tout le monde. On travaille avec toute la R&D, on travaille avec toute la production et on travaille avec toutes les équipes de production, donc on est en contact permanent avec les artistes, avec les caméramen, avec les gens qui sont scriptes, avec l'intégralité de la R&D, toutes les équipes, etc. On voit absolument tout le monde. Théoriquement, on est capable de créer des jeux tout seuls. Ils sont très moches. Donc je m'en rends pas très bien. Il sera peut-être pas très très fun, mais on peut faire un jeu.