Un plantage est le meilleur bug que vous puissiez avoir. Il se produit sous vos yeux, il arrête l’application, et vous le réparez l’après-midi même. Tous ceux qui construisent avec des générateurs d’IA ont une histoire sur un déploiement cassé ou un écran blanc, et c’est presque toujours une histoire avec une fin heureuse : trouvé, réparé, déployé.
La corruption de données ne fonctionne pas comme ça. Elle ne fait pas planter le système. Elle ne renvoie pas d’erreur. Elle écrit un mauvais chiffre dans une colonne de base de données et continue, et l’application continue de fonctionner exactement comme avant. Le bug dont vous devriez réellement avoir peur est celui qui ne vous dit jamais qu’il a eu lieu.
Pourquoi les plantages sont le dénouement chanceux
Quand quelque chose casse visiblement, vous obtenez un retour immédiat et une courte liste de suspects : le dernier prompt, le dernier déploiement, le dernier changement de code. Lovable, Bolt, et les générateurs similaires échouent ainsi constamment, et c’est agaçant mais gérable, car l’échec est bruyant.
La corruption silencieuse inverse tout le problème. Le bug et la découverte du bug peuvent être séparés par des mois, et durant cet intervalle, les données corrompues continuent de s’accumuler : elles sont copiées dans des rapports, additionnées dans des totaux, utilisées pour calculer une facture. Le temps que quelqu’un remarque que les chiffres sont faux, vous ne débuggez pas une seule erreur. Vous essayez de comprendre lesquels des milliers d’enregistrements créés depuis le déploiement du bug sont fiables et lesquels ne le sont pas, sans aucun log pour signaler la différence.
Les cas limites que personne ne prompt
Les modèles d’IA construisent pour le scénario que vous avez décrit. Un prompt comme “permettre aux utilisateurs de mettre à jour la quantité de leur commande” vous donne un bouton de mise à jour fonctionnel, testé contre exactement une chose : un seul utilisateur, sur une connexion stable, cliquant une fois. L’utilisation réelle ne reste pas dans cette boîte, et les lacunes apparaissent selon quelques schémas répétitifs :
- Éditions concurrentes. Deux personnes ouvrent le même enregistrement et sauvegardent les modifications à quelques secondes d’intervalle. Sans stratégie de verrouillage ou de résolution de conflit, celui qui sauvegarde en dernier écrase silencieusement les modifications de l’autre, sans avertissement pour aucun des deux utilisateurs.
- Coupure réseau en plein formulaire. Une soumission est envoyée, la connexion saute, et le client ne peut pas confirmer si le serveur l’a reçue. L’utilisateur voit un spinner, suppose que cela a échoué et renvoie le formulaire. Sans déduplication, on a maintenant deux enregistrements là où il ne devrait y en avoir qu’un.
- Le bouton de soumission double-cliqué. La version la plus banale du même problème. Une réponse lente plus un clic impatient et vous avez créé un paiement en double, une réservation en double, ou une ligne en double qui gonfle tous les comptes en aval.
- Saisie inattendue. Un champ de quantité qui accepte un nombre négatif, un champ de date qui accepte une valeur dans le passé, un champ de remise qui accepte plus de 100%. Aucun de ces cas ne fait planter l’application. Ils produisent simplement un enregistrement qui est mathématiquement absurde dès que quelqu’un le confronte à la réalité.
Aucun de ces modes de défaillance n’est exotique. C’est la friction ordinaire de vraies personnes utilisant une application sur de vrais réseaux, et un seul prompt ne demande presque jamais à l’IA de s’en protéger, car s’en protéger n’ajoute aucun progrès visible à une démo.
Quand le calcul est faux sur chaque transaction
La seconde variante de ce problème est encore plus discrète : une erreur d’arrondi ou de calcul qui est fausse d’une fraction de centime, à chaque fois, sur chaque transaction. Cela s’exécute proprement. Cela ne renvoie jamais d’exception. Le test unitaire, s’il en existe un, vérifie que le calcul renvoie un nombre, pas que le nombre est correct jusqu’à la dernière décimale sur dix mille exécutions.
C’est là que le test “ça marche”, auquel le vibe coding vous apprend à vous fier, devient activement dangereux. Un calcul de prix erroné de 0.3% ne rate pas la démo. Il rate la réunion de rapprochement six mois plus tard, quand la finance souligne que la somme de toutes les transactions individuelles ne correspond pas au chiffre d’affaires total, et que personne ne peut expliquer pourquoi sans examiner chaque enregistrement un par un.
Cet écart entre “la fonctionnalité marche” et “la fonctionnalité est correcte” est exactement ce que les tests automatisés sont censés intercepter dans le développement logiciel professionnel, et exactement ce qui manque quand un constructeur non technique est le seul à vérifier la sortie de l’IA. Vous pouvez confirmer visuellement qu’une page se charge. Vous ne pouvez pas confirmer visuellement qu’un calcul composé est précis au centime près sur une année de transactions.
Pourquoi “ça a l’air correct” est le mauvais test pour l’intégrité des données
| Ce que vous pouvez tester manuellement | Ce qui cause réellement la corruption |
|---|---|
| Le formulaire est-il soumis avec succès ? | Est-il soumis exactement une fois, même avec une connexion instable ? |
| Le tableau de bord affiche-t-il un total ? | Ce total est-il toujours correct après 10 000 lignes, ou une erreur d’arrondi s’accumule-t-elle ? |
| Un utilisateur peut-il modifier un enregistrement ? | Que se passe-t-il quand deux utilisateurs le modifient en même temps ? |
| La calculatrice renvoie-t-elle un nombre ? | Ce nombre est-il le bon nombre, vérifié par rapport à une source indépendante ? |
La colonne de gauche est ce qu’une démo, et la plupart des QA manuels, vérifient réellement. La colonne de droite est ce qui détermine si votre facturation, vos réservations ou vos rapports sont fiables au sixième mois. Le vibe coding optimise fortement la colonne de gauche et n’a aucun mécanisme naturel pour la droite, car la colonne de droite nécessite d’essayer délibérément de casser le chemin nominal, et pas seulement de confirmer qu’il fonctionne.
Ce qui rend cela pire qu’un bug : vous ne pouvez pas savoir quels enregistrements sont faux
Un crash a un rayon d’impact visible. Des données corrompues ont un rayon d’impact que l’on peut seulement deviner. Une fois qu’un bug de soumission en double ou une erreur d’arrondi est présent depuis des mois, il n’y a aucun marqueur sur les lignes affectées. Soit vous faites confiance à l’ensemble du jeu de données, que vous savez maintenant être peu fiable, soit vous l’auditez enregistrement par enregistrement, ce qui n’est pas réaliste pour une petite équipe sans temps d’ingénierie dédié dès que l’on dépasse quelques centaines de lignes.
C’est le coût réel du “fossé de confiance” lié au code généré : vous n’avez jamais été en position de vérifier que la logique était parfaitement étanche au départ, donc quand s’avère qu’elle ne l’était pas, vous n’avez aucun point de départ pour le nettoyage. Découvrir le bug n’est pas la fin du problème. C’est le début d’un problème bien plus difficile : déterminer jusqu’où remontent les dégâts.
Construire pour que les dommages ne s’accumulent pas
Vous ne pouvez pas éliminer tous les cas particuliers en étant plus prudent avec vos prompts. Ce que vous pouvez faire, c’est choisir où s’exécutent réellement les parties de votre application qui gèrent l’argent, les quantités ou les réservations.
Pour les projets personnels, les prototypes internes ou tout cas où un chiffre erroné est un inconvénient plutôt qu’un risque juridique, le code généré et les tests manuels sont un compromis raisonnable pour gagner en rapidité. Le calcul change dès que les chiffres alimentent une facture client, un calendrier de réservation ou un rapport validé par quelqu’un. À ce stade, la question n’est plus “est-ce que cela semblait correct quand je l’ai testé”, mais “qui vérifie que c’est toujours correct après dix mille transactions”.
Pour cette catégorie d’applications métier, structurez le chemin d’écriture pour qu’il ne dépende pas de la capacité de l’IA à gérer la concurrence et l’arrondi dès le premier (ou le cinquième) essai :
- Confiez les écritures critiques à une infrastructure testée, pas à du code généré récent. Softr gère la création d’enregistrements, les mises à jour et les calculs de regroupement (sommes, moyennes, comptages sur des enregistrements liés) via son propre moteur de base de données plutôt que par une logique générée par IA propre à chaque application. Un regroupement qui additionne les lignes d’une facture exécute le même calcul testé à chaque fois, au lieu d’une fonction sur mesure écrite une fois par une IA et jamais soumise à des tests de stress pour les dérives d’arrondi.
- Utilisez des permissions visuelles plutôt qu’une logique de concurrence écrite à la main. Les groupes d’utilisateurs et les restrictions de données au niveau de l’enregistrement de Softr régissent qui peut modifier quoi, ce qui réduit (sans éliminer) le problème d’édition concurrente en contrôlant l’accès au niveau de la plateforme plutôt qu’en dépendant d’un verrouillage codé sur mesure que l’IA a pu ou non penser à ajouter.
- Réconciliez les données indépendamment, selon un calendrier. Aucune plateforme, no-code ou autre, ne remplace l’habitude de vérifier périodiquement les totaux par rapport à une source externe : un relevé bancaire, le tableau de bord d’un processeur de paiement, un comptage manuel. C’est vrai que vous ayez construit sur du code généré par IA ou non, et c’est le seul moyen de détecter une erreur cumulative avant qu’elle ne s’installe depuis un an.
- Si vous restez dans le code, prévoyez du temps réel pour des tests adverses. Si vous êtes un développeur utilisant Cursor ou Replit pour construire ou étendre une application personnalisée, écrivez explicitement des tests pour les écritures concurrentes, les soumissions en double et les valeurs limites (nombres négatifs, zéro, dates extrêmes), car l’IA ne les générera pas à moins que vous ne le demandiez, et le fait que “ça compile” ne vous dit rien sur la correction du code sous charge.
Rien de tout cela ne fait disparaître le problème sous-jacent. Un logiciel qui touche à l’argent ou aux réservations aura toujours besoin de quelqu’un pour vérifier les calculs face à la réalité. Mais il y a une réelle différence entre une application où la logique d’écriture a été générée sur mesure par projet et jamais testée sous stress, et une autre où les opérations de base de données sont le même chemin de code testé sur lequel s’appuient toutes les entreprises de la plateforme. La première vous donne une nouvelle chance de vous tromper sur la concurrence et l’arrondi pour chaque fonctionnalité. La seconde ne supprime pas votre responsabilité de réconciliation, mais elle supprime le pari quotidien de savoir si cette fonction d’écriture particulière générée par IA gère correctement un double-clic.
Le constat honnête est que les crashs sont agaçants mais pardonnables. La corruption silencieuse est patiente. Elle attend que le volume de données soit suffisant et que le temps écoulé soit assez long pour que la correction coûte bien plus cher que ce que la prévention aurait coûté.
