Qualité et fiabilité du code

Ces chiffres ne sont pas ceux de départ. Le premier passage de tests de mutation sur le module le plus gros et le plus difficile (l'interpréteur Python, ~2500 lignes) a donné 75,65 % — soit près d'un quart des défauts injectés délibérément passaient totalement inaperçus. Combler cet écart jusqu'à 100 % a nécessité sept passages consécutifs, chacun refermant une partie du reste tout en faisant apparaître de nouveaux cas limites — y compris des erreurs de méthodologie commises pendant le processus de vérification lui-même.

De vrais bugs de l'application trouvés et corrigés (pas seulement des lacunes de tests) — mis au jour précisément grâce à ce processus rigoureux : le score d'une leçon était indûment abaissé après une erreur corrigée (une seule erreur plafonnait le score maximal possible, même si l'apprenant se corrigeait immédiatement à la reprise) ; le test de niveau accordait à tort les succès « Sans Faute » et « Sans Pitié » pour des leçons sautées, non réellement accomplies ; et trois bugs ponctuels de l'interpréteur lui-même (division entière, arrondi de l'opérateur de reste, comparaison de bool avec int).

Une erreur de méthodologie a été détectée et corrigée en cours de route : une vérification intermédiaire (remplacer le texte d'une ligne entière au lieu de muter aux coordonnées exactes de Stryker) a surestimé le nombre de mutants réellement « équivalents » (c'est-à-dire impossibles à corriger) — sur 35 hypothèses de ce type, une seule s'est confirmée. Corrigé en passant à une vérification précise, au niveau des coordonnées, pour chaque cas individuel.

Les 5 derniers mutants (comparaison de chaînes utilisée par le tri des listes) n'ont cédé ni à une preuve d'équivalence, ni à un test écrit via l'interface publique habituelle — l'algorithme de tri natif de JavaScript effectue des comparaisons redondantes qui masquent un résultat erroné sur une seule paire. Résolu en testant directement la fonction de comparaison interne, en contournant entièrement le comportement imprévisible de l'algorithme de tri tiers.

En résumé : aucun chiffre de ce rapport n'est peint d'avance. Chacun est le résultat d'un travail itératif et vérifié — y compris le fait d'admettre et de corriger ses propres erreurs en chemin. C'est précisément pour cela que ces chiffres sont dignes de confiance : l'app ne se contente pas de bien se comporter sur les exemples vérifiés — le filet de sécurité des tests qui l'entoure détecte réellement les régressions futures, au lieu d'exister seulement sur le papier.

Pourquoi « 2797 sur 2797, 100 % » est brièvement devenu « 3373 sur 3374, 99,97 % » avant de revenir à 100 % : après avoir atteint 100 % une première fois (ci-dessus), l'interpréteur a reçu de nouveaux sujets de curriculum — itération directe (for x in iterable: sans range()), __str__/__eq__, @staticmethod/@classmethod, dictionnaires/ensembles/compréhensions/générateurs — des centaines de lignes nouvelles qui n'étaient jamais passées par des tests de mutation. Plutôt que de laisser cette croissance non vérifiée (et de continuer à afficher discrètement un « 100 % » périmé), elle a été soumise à Stryker avec la même rigueur que le reste : 32 nouveaux tests de régression, chacun écrit contre un mutant survivant précis (en lisant d'abord le code autour, en confirmant logiquement pourquoi les tests existants le manquaient, et seulement ensuite en écrivant le test) — pas du remplissage de couverture. Tout le reste ayant changé depuis le passage précédent de tests de mutation (17 août) a aussi été vérifié : le parseur (nouvelle grammaire pour ces mêmes nouveaux sujets) et le planificateur de répétition espacée (un nouveau seuil précédant l'entrelacement) — déjà tous deux à 100 % sans travail supplémentaire nécessaire. Il restait donc exactement un mutant non résolu, et c'est là que le rapport indiquait brièvement « 3373 sur 3374, 99,97 % », avec une explication de pourquoi c'est plus honnête qu'un « 100 % » fabriqué : une fonction de résolution de variable locale (Scope.tryGet) comportait une vérification qui, en théorie, pouvait compter dans deux scénarios distincts, mais l'un d'eux s'est révélé mathématiquement impossible compte tenu de tous les points d'appel réels de l'app — et l'autre, réellement atteignable, était déjà couvert par un test dédié. Marquer les deux mutants de cette ligne « équivalents » avec un seul commentaire aurait été le chemin le plus rapide vers « 100 % » — c'est précisément pour cela que ça n'a pas été fait à ce moment-là : l'outil ne peut désactiver la vérification de mutation que pour une ligne entière, pas pour un mutant précis, donc ce raccourci aurait aussi balayé la couverture du scénario qui compte vraiment.

Ce qui a changé ensuite — et pourquoi il s'agit d'un 100 % authentique, pas d'un contournement : plutôt que de se contenter de 99,97 % ou de supprimer discrètement le reste, la question suivante a été de savoir si cette ligne était, dès le départ, du code mort. Un traçage plus poussé de chaque appel à tryGet() dans l'app (il y en a exactement un) et de chaque endroit d'où la valeur qu'elle protégeait pouvait provenir a montré que oui : la ligne était réellement inatteignable dans n'importe quel état réel du programme, pas seulement difficile à tester. Elle a été supprimée purement et simplement. Ce n'est pas un raccourci : supprimer du code réellement mort ne fait perdre aucune couverture réelle (contrairement à la suppression du mutant par un commentaire, qui aurait aussi jeté la couverture réelle, déjà vérifiée, du mutant jumeau) — le mutant que cette ligne générait a simplement cessé d'exister avec elle. La suite de tests complète (1035 tests à l'époque) a confirmé que le comportement n'avait pas changé d'un iota. Le passage suivant de Stryker a donné un authentique 100,00 %. La leçon de ce petit détour dans le rapport lui-même : accepter de montrer un chiffre honnête juste en dessous de 100 % s'est révélé être le chemin le plus rapide vers un vrai 100 %, pas plus lent que de camoufler l'écart dès le départ.

D'où vient la croissance de 3371 à 3694 et de 9655 à 9710 (1er septembre 2026) : le cours s'est agrandi — un nouveau 17ᵉ module, « Import, modules et gestion de fichiers », a ajouté une exécution réelle (pas seulement une reconnaissance de syntaxe) d'import/open()/with face à un système de fichiers virtuel simulé, et une nouvelle section « Astuces » (15 cartes « avant → après » expliquant pourquoi la forme la plus courte fonctionne de la même manière). Les deux ajouts sont passés par la même rigueur que le reste de l'app : interpreter.ts et parser.ts ont été soumis de nouveau aux tests de mutation (respectivement +238 et +36 mutants, tous détectés), le nouveau lifehacks-engine et manage-lifehacks ont été amenés de zéro à 100 % (2 lacunes de tests réelles corrigées, pas masquées), les 15 cartes (30 extraits de code) ont été vérifiées face à CPython, tout comme les 2 nouveaux exercices du module 17 fondés sur des boucles. Le même jour, le dernier retard de traduction a aussi été comblé : la section « Astuces » et les 434 nouvelles clés du module 17 ont été traduites en espagnol, en français, en allemand et en portugais dès leur ajout, si bien que les 6 langues du cours sont maintenant à 100 % de parité de contenu (12 214 clés chacune) — c'est précisément pour cela que le nombre de comparaisons de localisation est passé de 58 635 à 61 070.