Un panel de 50 testeurs IA : utile ou théâtre ?

Le projet : un jeu de sushi en pixel art. Le principe tient en une phrase : on prépare les plats de trois clients pendant que des règles absurdes s’accumulent (« remplace le thon par le saumon », « sur l’assiette rouge, ajoute du riz »). Six modes, six langues, clavier, souris, tactile et trois familles de manettes. Beaucoup de surface, et aucun joueur sous la main pour la tester.

L’équipe a donc fait ce que beaucoup envisagent aujourd’hui pour leurs produits : confier le playtest à des agents IA. Neuf vagues en deux jours, jusqu’à un panel de 50 profils de joueurs, plus des bots qui jouent des milliers de parties. Cet article raconte ce que ça a donné, et répond à la question qui a traversé tout le dispositif.

1. La question : un panel simulé remplace-t‑il des joueurs ?

Un playtest sert à deux choses très différentes. D’abord trouver ce qui est cassé : un texte coupé, un bouton inatteignable à la manette, une règle impossible à respecter. Ensuite mesurer ce que ressent un joueur : est-ce qu’il comprend, est-ce qu’il s’amuse, est-ce qu’il revient.

La première tâche est vérifiable. La seconde ne l’est pas. Toute la question « utile ou théâtre » se joue sur cette frontière : un agent qui « joue » une grand-mère de 68 ans sur téléphone produit‑il un constat, ou une mise en scène plausible d’un constat ?

2. Comment le panel est construit

Le dispositif a grossi vague après vague : 6 profils sur 12 captures le premier jour, puis 8, 18, 24, et enfin un panel de 50 joueurs découpé en 5 groupes de 10 :

• A : novices et joueurs occasionnels, surtout sur tactile ;
• B : joueurs habitués à la manette (DualSense, Switch Pro, Steam Deck, 8BitDo…) ;
• C : compétitifs, speedrunners, tricheur avec les outils de développement ouverts ;
• D : accessibilité et streamers (photosensible, sourd, daltonien, streameur Twitch, créatrice TikTok) ;
• E : joueurs natifs de chaque langue, chargés de traquer les textes qui sonnent traduits.

Précision importante sur le chiffre : 50 profils, mais 5 agents. Chaque groupe est confié à un seul testeur qui incarne ses 10 profils l’un après l’autre. Ce n’est pas 50 regards indépendants, c’est 5 regards qui changent de chapeau.

Chaque agent reçoit le code, une quarantaine de captures d’écran par langue, les rapports précédents, et le droit de lancer des scripts et les tests. Il ne modifie aucun fichier du projet, sauf son rapport.

Et surtout, une règle, écrite en tête de la documentation QA :

- Chaque constat est prouvé : capture citée, fichier:ligne ou sortie de script.
  Sinon il est noté « ressenti ».
- Un cas n'est jamais « OK » par supposition.
- Les conventions de chaque plateforme font foi : un comportement « logique »
  mais contraire aux habitudes d'un joueur est un KO.

Cette règle change la nature de l’exercice. Sans elle, un agent qui joue un enfant de 9 ans écrit « l’enfant trouve le jeu trop difficile », et on ne peut rien en faire. Avec elle, il écrit que l’enfant doit lire 5 bulles de dialogue avant de jouer au premier niveau et 6 au deuxième, qu’il touche le ticket « pour voir » et sert une assiette incomplète, et il cite le fichier du guidage avec ses numéros de ligne.

Le rapport a un format imposé : un tableau des 10 joueurs (note sur 10, ce qui a plu, ce qui a bloqué, rejouerait ?), puis les problèmes triés par gravité, chacun avec reproduction, preuve et correction proposée.

Voici à quoi ressemble un constat du groupe manette, tel qu’il est écrit :

H1. Cuisine : ↑/↓ font sauter le curseur dans la même rangée
    quand il y a de 6 à 9 bacs (9 joueurs : tous ceux qui jouent à la manette)
- Reproduction : niveau 2-3 (7 bacs). Curseur sur le bac 3, appui sur ↓ :
  il va sur le bac 1.
- Preuve : ServiceScene.ts:397-398, (padBin ± BIN_COLS + bins) % bins.

Ce n’est plus un avis. C’est un ticket, avec une ligne de code coupable et un modulo de trop.

3. Ce que le panel a trouvé et corrigé

Les corrections se comptent par dizaines. Quelques-unes montrent ce que les profils apportent.

Les profils d’accessibilité trouvent ce qu’un développeur ne voit pas. Dès la première vague, le streamer daltonien ne distingue pas la patience vert / rouge, ni le thon du saumon. Résultat : des formes sur les assiettes (rond, triangle, carré), une alerte clignotante sur la patience, des motifs différents pour les poissons. Le profil photosensible du panel relève un flash rouge plein écran à chaque erreur, sans limite de fréquence : les flashs sont désormais plafonnés (0,35 d’opacité au plus, jamais deux en moins de 0,4 s).

Les profils culturels apportent du contenu. Un ancien cuisinier de sushi fait remarquer qu’au Japon le rouge porte chance : « Le rouge porte malheur » devient « Gare au rouge ». Le groupe des natifs corrige une soixantaine de textes dans cinq langues.

Les profils les plus utiles sont ceux qui cherchent à casser. Bien avant le panel, en vague 4, un lien de défi contenait le score en clair (s=10000000) : les liens ne contiennent plus aucun score, mais le journal de la partie, que le jeu rejoue pour retrouver le vrai score. Dans le panel, le tricheur du groupe compétitif, outils de développement ouverts, a encore trouvé qu’une partie jouée par un bot parfait passe la validation. En vague 9, les liens sont versionnés, et un ancien lien affiche « ancienne version » au lieu d’un faux score.

Et les notes ? Le même panel, avec les mêmes profils, a été relancé après les corrections :

Le point sera repris plus loin : ce tableau est la partie la moins fiable de tout le dispositif.

4. La simulation déterministe : ce que les profils ne savent pas faire

À côté du panel, il y a des bots, lancés par npm run simulate. Ce ne sont pas des agents IA : ce sont des profils chiffrés qui jouent la vraie simulation du jeu, sans navigateur, sur tous les niveaux et tous les modes, avec une graine fixe. Un profil, c’est une poignée de paramètres :

{ id: "kid", label: "Enfant 9 ans", decide: 2.2, perItem: 1.1, perRule: 1.6,
  forget: (n) => 0.05 + 0.05 * n, peekChance: 0.6, peekDuration: 2.6,
  slip: 0.04, jitter: 0.35 },

Temps de lecture, temps par ingrédient, probabilité d’oublier une règle, habitude de consulter le carnet, erreurs de clic. Une deuxième série modélise des habitudes : un parent dans le métro distrait 3 s une fois sur huit, un joueur à motricité réduite qui rate 8 % de ses clics.

Ces bots ont servi à l’équilibrage. Avant les premières corrections, l’enfant et le senior échouaient aux boss (0 à 40 % de réussite), et le défi du jour faisait 0 % de réussite pour le joueur occasionnel. En vague 6, un bon joueur gagnait 31 % des parties du mode multijoueur à 30 chefs : après réglage, 13 %, rang médian 4^e.

Mais leur trouvaille la plus importante est venue d’un profil volontairement irréaliste : l’oracle, qui sert instantanément l’assiette exacte. En vague 5, sur 40 parties de service infini, l’oracle a perdu 119 vies. Toutes les 119 venaient du même bug.

Le mécanisme : sur un sashimi de thon, la règle « thon → concombre » suivie de « retirer le concombre » donne une assiette attendue vide. Or on ne peut pas servir une planche vide. Le client part fâché, la vie est perdue, quoi que fasse le joueur. Toutes les parties d’un joueur parfait se terminaient ainsi, au bout d’environ 190 secondes.

Aucun profil humain simulé ne pouvait le voir. Un joueur qui perd une vie pense qu’il s’est trompé. Il faut un joueur qui ne se trompe jamais pour prouver que c’est le jeu qui triche. La correction consiste à refuser toute règle qui rendrait une commande impossible :

export function emptiesAPlate(rules, options): boolean {
  for (const dish of availableDishes(options.ingredients, options.dishTypes))
    for (const customer of options.customers)
      for (const seat of SEAT_COLORS) {
        const size = applyRules(rules, dish.items, { customer, seat, dish: dish.type }).length;
        if (size === 0 || size > MAX_PLATE) return true;
      }
  return false;
}

En vague 6, l’oracle a rejoué tous les modes : service infini, mode 30 chefs, 365 défis du jour, les 20 niveaux d’histoire sur 10 graines, les nuits du mode roguelike. Résultat : 0 assiette vide sur plus de 37 000 commandes. Le même passage a vérifié les chaînes de règles affichées à l’écran sur 168 000 commandes aléatoires.

Et il a trouvé le bug voisin. La correction des assiettes vides n’empêchait pas l’empilement des règles « ajouter » : dans les dernières nuits du mode roguelike, des commandes demandaient 7 ou 8 ingrédients, pour une planche qui en accepte 6. Un joueur parfait perdait 7,5 % de ses parties, 18 % au niveau de difficulté maximal. D’où la deuxième condition, size > MAX_PLATE, dans la fonction ci-dessus.

Un profil simulé dit ce qu’il ressent. Une simulation déterministe dit ce qui est vrai. Il faut les deux, et ne jamais confondre l’un avec l’autre.

Le rapport de la première vague l’écrivait déjà : les bots modélisent la vitesse et la mémoire, pas le plaisir.

5. Les limites : ce qu’un vrai joueur verrait

C’est ici que le théâtre guette. Plusieurs signaux, tous tirés des rapports eux-mêmes, montrent où le dispositif s’arrête.

Les agents jugent des captures, pas une partie. En vague 2, pour photographier l’écran de résultat, le script de capture forçait la défaite. Sept testeurs sur huit ont signalé un bug : « renvoyé alors qu’il restait des cœurs ». Le jeu n’avait rien. Les testeurs ont jugé fidèlement une image fausse. Un vrai joueur n’aurait jamais vu cet écran.

Le ressenti physique reste un ressenti. Le joueur Switch du panel manette « sert la place de droite au lieu d’ajouter, par réflexe » : l’agent l’a lui-même noté « ressenti ». Le joueur de jeux de combat relève une image de latence et des appuis trop brefs perdus, mais sur une manette simulée : personne n’a tenu la manette.

Le matériel réel surprend. Le constat le plus concret sur les manettes n’est pas venu du panel. C’est un cas réel : une manette PlayStation dont le bouton ○ arrivait comme bouton 0 et ✕ comme bouton 1, si bien que ○ validait les menus et prenait l’ingrédient. Le groupe manette avait vérifié la convention sur une manette simulée, qui se comportait comme prévu. D’où un écran de réglage des touches, ajouté après coup. De même, la musique « bip bip » des débuts ou les bandes noires autour du jeu sont venues de retours directs, pas du panel. Et le document d’analyse sur la viralité le note lui-même : le partage vidéo sur iOS reste à tester sur un appareil réel.

Les notes ne mesurent pas la satisfaction. Revenons au tableau. Pour la vague 9, chaque agent avait reçu la liste de ce qui avait changé depuis le panel, « à vérifier en priorité », et ses propres rapports précédents. Il notait donc en sachant ce qui avait été corrigé pour lui, avec sa note précédente sous les yeux. La hausse dit que les corrections répondent aux constats. Elle ne dit pas qu’un humain s’amuserait davantage.

Les agents se marchent dessus. Le testeur du groupe novices a arrêté sa session de navigateur parce que d’autres changeaient les onglets ; celui du groupe manette a refait ses mesures sur une copie figée, parce que le code bougeait en parallèle.

Enfin, la limite la plus simple : aucun agent ne décide de fermer le jeu au bout de deux minutes parce qu’il s’ennuie. Le « rejouerait ? » du tableau est une estimation, pas un comportement.

6. Le cas éthique : des bots présentés comme des joueurs

Le mode multijoueur fait s’affronter 30 chefs sur la même partie ; le dernier debout gagne. Sauf que les 29 adversaires sont des bots, les mêmes que ceux de la simulation, qui jouent la même graine que le joueur. Le commentaire du code le dit sans détour :

/**
 * "Service 30": 30 chefs play the same seed at the same time; the last one standing wins.
 * The 29 opponents are simulated bot players on that very seed (same customers, same rules),
 * so their pace is believable.
 */

Le code le dit. L’écran, lui, raconte autre chose : « Recherche d’adversaires… 12/30 », un salon qui se remplit, « 30/30 prêts », « {name} a quitté le salon ». Et le jeu fonctionne hors ligne.

Le plus inconfortable, c’est le chemin qui y a mené. En vague 4, un retour des testeurs simulés jugeait les pseudos des bots « peu crédibles ». La correction : 27 modèles de pseudos et des vocabulaires par région, inspirés de vrais pseudos de forums. Le panel avait demandé plus de réalisme, le projet l’avait livré.

Puis le groupe des compétitifs du panel de 50 a classé le sujet en problème haut. Son joueur de battle royale « découvre que les 29 “joueurs” sont des bots présentés comme de vrais joueurs ». Le rapport propose une correction, au texte près : « 29 chefs IA · tous en Normal · le carnet ne met pas en pause ». En vague 9, même constat, même proposition : « Les bots se présentent toujours comme des joueurs ». La synthèse des vagues retient que deux groupes du panel jugent le procédé trompeur.

Le document d’analyse sur la viralité du jeu le déconseillait aussi : « Pas de bots déguisés en humains », en citant les polémiques de grands jeux multijoueurs et les règles européennes sur les pratiques trompeuses. Il proposait une alternative : des fantômes de vraies parties.

Au moment de la rédaction de cet article, le texte du salon n’a pas changé. La documentation range le sujet dans les « points connus restants », avec une mention « chefs IA » présentée comme possible. Le constat est prouvé, la correction est rédigée, il manque une décision, et cette décision revient à l’équipe, pas au panel.

C’est peut-être la meilleure démonstration de ce que vaut le dispositif. Il a vu le problème, il l’a argumenté, il a même écrit le correctif. Il ne peut pas l’imposer. Et il a montré une symétrie inattendue : le jeu fait passer des bots pour des humains, et à l’inverse il ne sait pas distinguer un humain d’un bot. Les points connus le reconnaissent : un bot à réaction parfaite peut obtenir de très gros scores « vérifiés » en service infini, car le rejeu prouve qu’une partie a eu lieu, pas qu’un humain l’a jouée.

7. Ce qui se transpose aux produits d’entreprise

Rien de ce qui précède n’est propre au jeu vidéo. Remplacez « joueur » par « utilisateur », « manette » par « lecteur d’écran » et « règle impossible » par « combinaison de paramètres métier qui bloque un dossier », et le dispositif s’applique tel quel à une application de gestion.

Quand le moteur du jeu a été extrait dans un framework réutilisable, la méthode de QA a fait partie de l’extraction, au même titre que le rendu ou l’audio : consignes du panel, format du rapport, plan de test, simulation par profils. Trois choses me semblent transposables telles quelles.

La règle de preuve. Un retour d’agent sans capture, sans fichier:ligne ni sortie de script est étiqueté « ressenti ». C’est elle qui transforme un panel simulé en générateur de tickets exploitables. Sans elle, on obtient des avis plausibles, et un avis plausible coûte plus cher qu’aucun avis, parce qu’on le croit.

Les profils aux marges. Le gain ne vient pas de l’utilisateur moyen : votre équipe le simule déjà dans sa tête. Il vient du daltonien, du photosensible, du lecteur non natif, du clavier AZERTY, du tricheur. Ce sont les profils qu’on oublie, et ceux qu’un agent tient le plus volontiers parce qu’on les lui décrit précisément.

L’oracle. Un utilisateur parfait, qui ne se trompe jamais, est le meilleur détecteur d’impossibilités. Si lui échoue, ce n’est pas l’utilisateur qui a tort. Dans un logiciel métier, c’est le dossier qu’aucune saisie correcte ne permet de valider.

8. Alors, utile ou théâtre ?

Les deux, et la frontière est nette.

Utile pour tout ce qui se prouve : textes coupés, conventions de manette, navigation, accessibilité vérifiable, failles de triche, règles impossibles, équilibrage chiffré. Sur ce terrain, neuf vagues en deux jours ont produit des dizaines de corrections, et chaque constat arrive avec sa reproduction. Le projet finit avec 358 tests sur 358 au vert, une compilation TypeScript propre, et une liste de points restants honnête.

Théâtre pour tout ce qui se ressent : le plaisir, l’ennui, l’envie de revenir, la sensation d’une manette en main. Les notes sur 10 donnent une forme de rigueur à quelque chose qui n’en a pas. À mon sens, elles valent comme indicateur de couverture (« ce groupe a encore des problèmes »), jamais comme une mesure de satisfaction.

Le panel simulé ne remplace pas des joueurs. Il fait en sorte que les premiers vrais joueurs ne perdent pas leur temps sur des bugs qu’une machine pouvait trouver.

Les leçons

• Imposez la preuve. Capture, fichier:ligne ou sortie de script ; sinon « ressenti ». C’est la règle qui fait toute la différence entre un rapport et une rédaction.
• Comptez les regards, pas les profils. 50 profils joués par 5 agents, c’est 5 points de vue. Le chiffre du titre impressionne plus qu’il ne renseigne.
• Doublez le panel d’une simulation déterministe. Les profils trouvent l’illisible, les bots trouvent l’impossible. Le bug le plus grave du projet n’était visible que par un joueur parfait.
• Méfiez-vous de ce que voient les agents. Ils jugent les captures qu’on leur donne. Une capture fausse produit un constat faux, unanime et bien argumenté.
• Ne lisez pas les notes comme une satisfaction. Un testeur qui connaît la liste des corrections et sa note précédente n’est pas un échantillon.
• Gardez du matériel réel et des humains. La manette aux boutons inversés ne se simulait pas ; un vrai joueur l’a trouvée.
• Ne faites pas passer une IA pour un humain. Ni dans un jeu, ni dans un support client. Le panel l’a vu ; un utilisateur le verrait aussi, et plus durement.