Le plan parfait qui s’écroule quand la sirène sonne
La sirène d’exercice hurle dans la mairie du bord de mer. Les bénévoles courent, chacun connaît le plan. Et puis ça coince: le trousseau n’est pas au bon crochet, la radio ne s’allume plus. Lire le plan, c’est rassurant. Le faire, c’est autre chose.
Beaucoup d’outils qui aident à écrire du code ont surtout appris en lisant des “plans”: du texte bien rangé, des habitudes, des exemples. Du coup ils peuvent proposer quelque chose qui a l’air propre, sans voir si ça marche quand on appuie sur le bouton, ni si ça rame ou gaspille la mémoire.
On se dit: “OK, on n’a qu’à refaire plus d’exercices.” Mais certains exercices ne peuvent pas vraiment se faire: matériel manquant, consignes floues. Les notes sont parfois incomplètes, copiées, ou pas comparables d’une équipe à l’autre. Et noter chaque micro-détail ralentit l’exercice.
Une idée simple change l’ambiance: une feuille de suivi standard, faite pour l’action. Ligne par ligne, on écrit ce qu’on a fait, avec quoi, et ce qui s’est passé. On note aussi des “points de passage”, comme “porte de l’abri verrouillée”. Même plan, mais une trace claire de ce qui arrive vraiment.
Après, on empile ces feuilles. Un classeur regroupe plein de suivis pour le même type d’exercice, venant de plusieurs équipes et versions du plan, avec des infos pratiques comme le temps et l’effort. Puis on empile encore selon les conditions: autre bâtiment, autre météo, autre matériel. Là, on voit quand ça casse.
Avec cette grande bibliothèque de suivis, les outils de code peuvent apprendre des plans écrits et des résultats réels. Leurs suggestions peuvent être confrontées à ce qui s’est déjà produit, pas juste à du texte qui “sonne bien”. Au tableau, la sirène retentit encore, mais cette fois les gestes suivent, sans surprise.