Comment vérifier une modification qu'un assistant IA a faite à votre jeu avant de la garder ?

Comparez les fichiers modifiés à votre tâche, lisez le diff en partant des suppressions, lancez les vérifications vous-même, jouez la modification, puis seulement faites un commit.

Regardez quatre choses, dans cet ordre : quels fichiers ont changé, ce que le diff a retiré et ajouté, ce que disent les vérifications quand vous les lancez vous-même, et comment le jeu se joue là où la modification a atterri. Ne gardez la modification que si les quatre correspondent à ce que vous avez demandé, et gardez-la sous forme de commit. Si l'une d'elles ne correspond pas, annulez-la et redemandez avec une meilleure tâche. Le compte rendu de l'assistant vous dit où regarder ; ce n'est pas la vérification.

Pourquoi « terminé » ne suffit-il pas ?

Parce que c'est une affirmation, et que la preuve, c'est la modification elle-même. Un assistant peut dire qu'une fonction marche alors qu'il a seulement vérifié que le code se compile, ou qu'il a touché un fichier alors qu'une commande qu'il a lancée en a réécrit trois.

Une partie de tout cela n'apparaît même pas dans l'éditeur. La page de Visual Studio Code sur la vérification des modifications faites par l'IA indique que les modifications en attente sont déjà enregistrées sur le disque, que les changements faits par des commandes du terminal ou des scripts n'apparaissent pas dans sa liste de modifications, et que ses points de contrôle n'annulent ni les commandes du terminal ni les déploiements. C'est ce qu'on y lisait le 29 octobre 2026, mise à jour du 21 octobre. Quel que soit votre outil, la vue fiable est celle que donne le contrôle de version : chaque fichier qui diffère de votre dernier commit.

C'est pourquoi la première étape a lieu avant que l'assistant commence : enregistrez une version qui marche sous forme de commit. Sans lui, il n'y a rien à quoi comparer la modification, et nulle part où revenir.

Que regarder en premier ?

La liste des fichiers modifiés. Deux commandes la donnent :

git status
git diff --stat

git status nomme chaque fichier modifié et chaque nouveau fichier. git diff --stat ajoute combien de lignes chaque fichier a gagnées et perdues. Notez que git diff seul ne montre pas les fichiers nouveaux qui n'ont pas encore été ajoutés à Git ; git status les montre, alors lisez les deux.

Comparez maintenant la liste à votre tâche. Si vous avez écrit une tâche qui dit où va la modification et ce qui ne doit pas changer, cela prend quelques secondes.

Rien de tout cela n'est faux en soi. Mais chaque point est quelque chose que vous n'aviez pas prévu de vérifier, donc il passe en premier.

Comment lire le diff si vous n'êtes pas programmeur ?

Lisez-le comme une liste de lignes retirées (en rouge, marquées -) et de lignes ajoutées (en vert, marquées +), et commencez par les retirées. Une ligne qui disparaît est la modification la plus facile à manquer et la plus difficile à remarquer en jouant : une vérification qui empêchait le joueur de traverser les murs, la remise à zéro du score, une protection contre une sauvegarde vide.

Cherchez ensuite quelques motifs faciles à repérer sans connaître le langage :

• Des nombres qui ont changé : vitesses, vies, minuteurs, prix. Chacun devrait figurer dans votre tâche.
• Du code transformé en commentaires, ou un bloc entier supprimé et réécrit ailleurs.
• Une nouvelle fonction qui ressemble à une ancienne : le même travail fait deux fois, et les deux copies finiront par diverger.
• Le texte que voit le joueur : menus, indices, messages d'erreur. Est-il toujours juste et au bon endroit ?

Pour toute ligne que vous ne savez pas lire, demandez à l'assistant ce qu'elle fait et ce qui l'appelle. La question ne coûte rien, et une réponse qui ne correspond pas au code est déjà une trouvaille.

Quelles vérifications lancer vous-même ?

Celles que votre tâche a nommées, lancées par vous plutôt que rapportées. Si la tâche demandait un test, lancez les tests et lisez le résultat. Si elle demandait que la page se charge sans erreur, ouvrez le jeu avec la console du navigateur ouverte. Une vérification que vous avez vue passer vaut plus qu'une phrase qui dit qu'elle est passée.

Un test au vert ne prouve que ce qu'il teste. Si un fichier de tests a changé dans le même diff, lisez cette partie : un test qui attendait un score de 0 après un redémarrage et qui attend maintenant ce que le code renvoie ne vérifie plus rien.

À quoi jouer avant de garder la modification ?

D'abord à la modification elle-même, telle que votre tâche l'a décrite. Puis un court parcours dans le reste du jeu, le même à chaque fois, car une modification à un endroit en casse souvent un autre :

1. lancez le jeu depuis une page neuve ;
2. utilisez chaque commande une fois, au clavier et sur téléphone si le jeu a des commandes tactiles ;
3. pause, défaite, redémarrage ;
4. sauvegardez, rechargez la page, chargez.

Le parcours prend quelques minutes et attrape ce que les tests couvrent rarement : un bouton qui ne répond plus, un écran dont on ne peut pas sortir, une sauvegarde qui ne revient pas. Si la modification a ajouté une touche ou un écran, vérifiez qu'ils marchent aussi au toucher ; c'est la règle que nous suivons pour KittenGalaxy depuis que nous lui avons ajouté des commandes tactiles.

Comment garder la modification, ou la jeter ?

Pour la garder, faites un commit, avec un message qui dit ce qui a changé dans les mots du joueur : « chaque vague 10 % plus rapide, jusqu'à deux fois la vitesse de départ ». Une tâche, un commit. Plus tard, quand quelque chose casse, vous trouverez quelle modification l'a fait et annulerez exactement celle-là.

Pour la jeter, revenez à votre dernier commit. Dans Git, git restore . remet les fichiers que Git suit déjà dans l'état de votre dernier commit, sauf si les modifications ont été indexées avec git add ; les fichiers créés par l'assistant ne sont pas supprimés par cette commande, alors relancez git status et supprimez-les à la main. Les éditeurs qui ont leur propre annulation ou leurs points de contrôle peuvent faire de même, dans les limites qu'ils décrivent. Écrivez ensuite une meilleure tâche : dites ce qui n'a pas marché, et ajoutez une vérification qui l'aurait détecté.

Il est tentant de garder une modification presque juste et de corriger le reste dans la tâche suivante. Ne le faites que si vous pouvez nommer ce qui ne va pas et que c'est petit. Une modification que vous ne comprenez pas ne devient pas plus claire une fois la suivante construite dessus. C'est ainsi que les jeux faits avec des assistants échappent à tout contrôle, et c'est pourquoi un petit premier jeu reste plus facile à faire fonctionner.

Une autre IA peut-elle faire la vérification ?

Elle peut lire le diff avec vous : expliquer des lignes, signaler des vérifications retirées, demander à quoi sert une nouvelle fonction. Cela aide, surtout si vous ne lisez pas le code. Mais elle ne peut pas décider si le jeu fait toujours ce que vous vouliez, car vous seul le savez, et elle ne peut pas jouer à votre place. Servez-vous-en comme d'un second lecteur, jamais comme d'une approbation.

Questions fréquentes

Combien de temps doit prendre une vérification ? À peu près aussi peu que la modification est petite. Si lire le diff prend plus de temps que d'écrire la tâche, la tâche était sans doute trop grande ; découpez la suivante.

Faut-il Git pour cela ? Il faut un moyen de voir ce qui a changé et de revenir en arrière. Git est le moyen habituel, et il est gratuit ; la plupart des éditeurs et des assistants fonctionnent avec.

Et si la modification est juste mais que le code semble brouillon ? Gardez-la si elle marche et que vous la comprenez, et écrivez une tâche à part pour ranger, avec les mêmes vérifications. Ne mélangez pas le rangement avec une nouvelle fonction.

Faut-il vérifier les modifications des images, des sons et des fichiers de niveaux ? Oui, en regardant et en jouant plutôt qu'en lisant le diff. La liste des fichiers modifiés vous dit quand même lesquels regarder.

Quand d'autres peuvent-ils y jouer ? Quand le parcours ci-dessus passe sur une page neuve et qu'un inconnu peut finir le jeu sans votre aide. Vous pouvez alors le proposer à HeapPlay.