Deux choses reviennent systématiquement quand on génère du code. Il faut les traiter explicitement, sinon personne ne le fera.
1. La duplication du code est le comportement par défaut.
Dans mon projet : deux composants quasi identiques faisant le même travail, quatre boutons portant chacun une copie du même bloc de mise en forme, la même gestion d’erreur recopiée à trois endroits. Tout fonctionnait mais tout était une dette technique. Une passe de nettoyage : 211 lignes en moins, zéro changement de comportement.
2. La sécurité n’est pas offerte.
J’ai fait auditer le code sur six domaines en parallèle : 34 problèmes remontés dont un critique.
Le critique : un serveur de fichiers malveillant pouvait écrire n’importe où sur mon disque. L’application faisait aveuglément confiance au nom de fichier annoncé par le serveur. Un nom bien choisi, un clic sur « Télécharger », et un programme se retrouvait déposé dans le dossier de démarrage de Windows, exécuté à ma prochaine ouverture de session.
Le détail qui résume tout : la vérification existait déjà dans le code. Elle était simplement appliquée du mauvais côté : là où les fichiers venaient de mon propre disque, pas là où ils venaient du serveur. Du code plausible, faux exactement là où ça compte.
Autre exemple : le mot de passe copié dans le presse-papiers n’était jamais effacé. Or Windows synchronise le presse-papiers vers votre compte et vos autres appareils.
Et le meilleur pour la fin.
Quatre tests échouaient. Réflexe naturel : corriger le code. Mais le code était juste ! C’étaient les tests qui étaient faux. Ils comparaient deux textes d’une façon qui, dans certains cas, considère que des caractères invisibles n’existent pas. Le test affirmait donc trouver quelque chose qui n’était pas là.
Si je l’avais cru, j’aurais affaibli une protection qui fonctionnait parfaitement.
C’est le vrai enseignement de cet audit : un test qui échoue n’a pas toujours raison, encore faut-il savoir lequel des deux se trompe.
Série « Ce que l’IA n’a pas fait à ma place » : 1 · 2 · 3 · 4
