Vous corrigez un prix, un affichage, une règle. Deux semaines plus tard le problème est de retour, ailleurs. Ce n'est pas de la malchance, et ce n'est pas vous : c'est la façon dont le code a été écrit. Voici la mécanique, comment reconnaître que vous êtes dedans, et ce qui l'arrête.
Publié le
Un outil qui génère du code à partir d’une phrase ne construit pas un programme, il répond à la dernière phrase. Quand vous écrivez « le prix de cette boutique est faux », il cherche l’endroit le plus proche où toucher pour que ce prix-là devienne juste. Il ajoute une condition, un coefficient, une exception. Le symptôme disparaît. La cause, elle, n’a jamais été regardée, parce que personne ne lui a demandé de la regarder.
C’est pour ça que le problème revient : la correction a traité un cas, pas la règle. Le cas suivant, une autre boutique, une autre devise, un autre format de page, tombe à côté de la rustine. Et la rustine elle-même devient une source de bugs, parce qu’elle s’applique aussi là où elle ne devrait pas.
Sur le dernier produit que nous avons repris, un comparateur de prix de 64 boutiques construit par son fondateur avec un outil d’IA, l’historique des modifications montrait une trentaine de corrections de prix en trois mois. Devises, coefficients, formats. Presque chacune défaisait une correction précédente, parfois sur un autre fournisseur. Le fondateur n’avait rien fait de travers : il avait fait exactement ce que l’outil lui proposait.
On retrouve les mêmes causes d’un produit à l’autre, quel que soit l’outil qui l’a généré.
La rustine locale. Le correctif s’applique à l’endroit où le symptôme apparaît, pas à l’endroit où la donnée naît. Un prix faux se corrige à l’affichage au lieu de se corriger à la lecture. Le chiffre affiché devient juste, le chiffre stocké reste faux, et tout ce qui le lit ailleurs, un export, une alerte, un tri, reste faux aussi.
La logique dupliquée. Chaque écran, chaque fournisseur, chaque type d’utilisateur a reçu sa propre copie du même traitement, parce que c’est ainsi que le code a été produit, prompt après prompt. Corriger une copie ne corrige pas les autres. Sur le comparateur, 57 boutiques avaient chacune leur bloc de code pour lire un prix, alors qu’elles tournaient toutes sur la même plateforme de boutique en ligne.
Les constantes en dur. Un taux de change écrit dans le code, un coefficient de TVA par fournisseur, un seuil de rejet. Ils étaient justes le jour où ils ont été tapés. Le monde bouge, eux non. Un fournisseur passe ses prix en hors taxes, et c’est tout son catalogue qui devient faux d’un coup, sans qu’aucune ligne de code ait changé.
Les garde-fous empilés. Après chaque incident, une règle de plus : rejeter les prix au-dessus de tant, suspendre une source si trop de valeurs changent. Chacune a été réglée le jour de l’incident, sur l’incident. Ensemble, elles finissent par bloquer des données justes et laisser passer des fausses. Sur le comparateur, ces règles avaient suspendu 33 boutiques sur 64 sans que personne le voie, pendant trois semaines.
Vous reconnaissez votre produit ? Décrivez-le en quelques lignes. Nous vous disons par écrit si c’est une correction, une brique à refaire, ou rien du tout.
Décrire mon projetQuatre signes, et un seul suffit.
Le même bug revient à un autre endroit. Vous l’avez corrigé sur un fournisseur, il apparaît sur le suivant. Ce n’est pas un nouveau bug, c’est le même, dans une autre copie du même code.
Le bouton « corriger » de l’outil fait apparaître un problème que vous n’aviez pas. La correction a touché quelque chose que le symptôme ne montrait pas.
Vous n’osez plus toucher à une partie du produit. Vous savez qu’elle est fragile, vous ne savez pas pourquoi, et vous contournez.
Vos crédits partent en corrections. Sur les outils facturés à l’usage, la boucle a un prix visible : chaque tentative consomme, et le compte de ce mois-ci ressemble à celui du mois dernier.
Le coût des crédits et du temps se voit. Le coût qui compte est ailleurs : ce sont les décisions prises sur des données fausses pendant que le problème revenait.
Sur le comparateur, une boutique affichait un catalogue à plusieurs milliers de fois son prix réel. Les 33 boutiques suspendues n’avaient pas mis leurs prix à jour depuis trois semaines, et le site les affichait comme à jour. Des abonnés payaient pour comparer des prix dont la moitié étaient périmés. Aucun bug visible, aucune erreur à l’écran, aucun message. C’est le propre de ce type de panne : elle ne se voit pas dans un tableau de bord, elle se voit chez vos clients.
Ce que l'historique révèle
Le dépôt de code garde la trace de chaque modification. Le nombre de corrections sur la même zone en trois mois dit tout ce qu’il y a à savoir : au-delà de trois ou quatre, ce n’est plus un bug, c’est une conception. C’est la première chose que nous lisons dans un audit, avant même le code.
Prompter à nouveau ne l’arrête pas. Vous obtiendrez une rustine de plus, à un autre endroit.
Corriger à la main, une fois, proprement, l’arrête quand le bug est isolé et que le code autour est lisible. C’est le cas le moins fréquent, et il se reconnaît à l’historique : une seule zone, une ou deux corrections, pas de duplication.
Refaire la brique l’arrête quand la même zone a été corrigée cinq fois. On ne touche pas au reste du produit. Sur le comparateur, seule la chaîne de prix a été refaite, lue à la source dans sa vraie devise, avec des règles explicites par boutique et des contrôles avant toute écriture en base. L’interface, les comptes, les abonnements sont restés tels quels. Le fondateur ajoute ses fournisseurs seul depuis.
Ne rien faire est aussi une réponse, quand le produit sert encore à convaincre et que personne ne dépend de ce qu’il affiche. Un prototype qui casse devant trois testeurs coûte moins cher qu’une refonte. Le moment de changer arrive avec les premiers utilisateurs réels, ou le premier paiement encaissé.
Décrivez votre produit et ce qui revient. Nous vous disons si c'est une correction, une brique à refaire, ou rien du tout.