Dans le dossier d'un groupe, la veille de la présentation

jeu.py            jeu_v2.py         jeu_final.py
jeu_final2.py     jeu_marche.py     jeu_camille.py
jeu_final_OK.py

1. Impossible à dire. Les noms ne portent aucune information vérifiable : « final », « OK », « marche » sont des opinions, datées d'un moment qu'on ne connaît pas. Le seul recours est de les lancer tous et de regarder — c'est-à-dire de refaire, la veille au soir, le travail de contrôle qu'on croyait fait. La date de modification donne le plus récent, ce qui n'est pas le même que le meilleur : jeu_final2.py peut être une tentative abandonnée.

2. Trois impossibilités, et chacune coûte cher :

• savoir ce qui a changé entre deux versions, donc où chercher un défaut apparu ;
• revenir en arrière proprement : si jeu_final_OK.py est cassé, quelle version reprendre, et qu'y perd-on ?
• travailler à plusieurs : jeu_camille.py est une branche parallèle que personne ne sait fusionner. Les modifications de Camille sont soit perdues, soit à recopier à la main.

3. Un seul fichier jeu.py, et l'historique ailleurs. Deux façons de faire, l'une minimale, l'autre correcte :

• à défaut d'outil : une copie du dossier entier à chaque fin de séance, dans un répertoire nommé par la date et non par une opinion — 2026-02-03/ —, accompagnée d'une ligne de journal de bord ;
• avec un outil de versionnage : un dépôt, une validation à chaque fin de séance avec un message qui dit ce qui a changé. L'historique est alors complet, daté, annoté, et l'on peut revenir à n'importe quel état. C'est l'objet des exercices supplémentaires.

Le symptôme à reconnaître : final2, finalOK, vraiment_final. Ces noms apparaissent toujours au même moment — quand on a peur de perdre une version qui marche. C'est une peur légitime : c'est la réponse qui est mauvaise.