Ce que j’ai appris en construisant mon client SSH avec l’IA : la vitesse s’effondre exactement là où on ne l’attend pas. Quatre exemples réels.
L’icône qui n’était pas nette.
Trois allers-retours sur une icône de 13 pixels. Le problème ne venait pas du dessin, mais de la façon dont il était réduit à cette taille : le trait tombait juste en dessous d’un pixel de large. Flou garanti, invisible sur une capture d’écran mais gênant tous les jours à l’usage.
Le même défaut, découvert deux fois.
Un bouton dont la zone cliquable débordait sur toute la largeur de la barre d’outils. À l’œil, tout allait bien. Le système de mise en page faisait, par défaut, autre chose que ce que le code semblait dire. Corrigé une fois, puis retrouvé ailleurs deux jours plus tard.
Le bouton Annuler qui fermait l’application.
Annuler un transfert de fichier tuait le programme entier. La méthode d’annulation paraissait correcte, mais elle interrompait le travail à un endroit où la bibliothèque utilisée ne s’attendait pas à être interrompue. L’erreur ne remontait pas proprement : elle emportait tout avec elle.
Un plantage au message trompeur.
Ouvrir un menu faisait tomber l’application, avec un message d’erreur qui désignait deux éléments sans aucun rapport avec le vrai problème. La cause : une façon de déclarer un menu que l’outil accepte quand on l’écrit, et refuse quand on l’exécute.
Aucun de ces quatre problèmes n’a été résolu plus vite par l’IA.
Ils ont été résolus en lisant, en mesurant, et en comprenant ce qui se passait vraiment. C’est la part du travail que l’IA n’accélère pas.
Série « Ce que l’IA n’a pas fait à ma place » : 1 · 2 · 3 · 4
