Dans un groupe de quatre, chacun a écrit son module et n'a jamais lu…

1. Le code n'est pas perdu : il est dans le dossier partagé, lisible par tous. Ce qui est perdu n'est écrit nulle part :

• la commande qui lance le programme, et depuis quel répertoire ;
• l'ordre dans lequel les fichiers doivent être présents, et lesquels sont nécessaires ;
• les décisions prises sans être notées — pourquoi la grille est une liste de listes, pourquoi une saisie s'écrit 1 2 et non (1,2) ;
• la démonstration : quel enchaînement montrer, quel cas éviter.

Autrement dit, tout ce qui aurait dû être dans le README et dans le journal de bord.

2. Trois mesures, toutes gratuites :

• le README dès la première séance, complété au fil de l'eau — la rubrique « Lancer » suffit déjà à sauver la présentation ;
• le journal de bord, où les décisions sont notées avec leur raison ;
• une revue croisée : à chaque point d'étape, chacun lit le module d'un autre et lui pose deux questions. Une demi-heure, et plus personne n'est le seul à savoir.

3. La première. Écrire la commande de lancement coûte trente secondes, à la première séance, au moment où on la tape pour la première fois — et c'est exactement ce qui manque le jour de l'absence. Les deux autres mesures valent mieux sur la durée ; celle-là a le meilleur rapport entre trente secondes et une présentation sauvée.

Le nom du risque : on parle parfois du « facteur d'autobus » d'un projet — le nombre de personnes dont l'absence suffirait à l'arrêter. Ici il vaut $1$, ce qui est le pire cas possible. Le faire passer à $2$ ne demande aucun travail supplémentaire : seulement d'écrire ce qu'on sait déjà, au moment où on le sait.