Un plantage est le meilleur bug qui puisse vous arriver. Il se produit devant vous, il arrête l’application, et vous le corrigez l’après-midi même. Tous ceux qui développent avec des générateurs IA ont une histoire de déploiement cassé ou d’écran blanc, et c’est presque toujours une histoire qui finit bien : trouvé, corrigé, livré.
La corruption de données ne fonctionne pas ainsi. Elle ne plante pas. Elle ne génère pas d’erreur. Elle écrit un mauvais chiffre dans une colonne de base de données et poursuit sa route, et l’application continue de tourner exactement comme avant. Le bug qu’il faut vraiment craindre est celui qui ne vous dit jamais qu’il s’est produit.
Pourquoi le plantage est la version chanceuse
Quand quelque chose casse de façon visible, vous obtenez un retour immédiat et une courte liste de suspects : le dernier prompt, le dernier déploiement, la dernière modification de code. Lovable, Bolt et les générateurs similaires échouent constamment de cette manière, et c’est agaçant mais gérable, parce que l’échec fait du bruit.
La corruption silencieuse inverse complètement le problème. Le bug et sa découverte peuvent être séparés de plusieurs mois, et dans 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 jour où quelqu’un remarque que les chiffres ne collent pas, vous ne déboguez plus une simple erreur. Vous essayez de déterminer lesquels, parmi des milliers d’enregistrements créés depuis la mise en ligne du bug, sont fiables et lesquels ne le sont pas, sans aucun journal pour signaler la différence.
Les cas limites que personne ne demande dans un prompt
Les modèles d’IA construisent pour le scénario que vous avez décrit. Un prompt du type « laisser les utilisateurs modifier la quantité de leur commande » vous donne un bouton de mise à jour fonctionnel, testé pour exactement une chose : un seul utilisateur, sur une connexion stable, cliquant une fois. L’usage réel ne reste pas dans ce cadre, et les failles apparaissent selon une poignée de schémas récurrents :
- Modifications simultanées. Deux personnes ouvrent le même enregistrement et enregistrent leurs modifications à quelques secondes d’écart. Sans stratégie de verrouillage ou de résolution de conflit, la dernière personne à enregistrer écrase silencieusement les modifications de l’autre, sans aucun avertissement pour personne.
- Une coupure réseau en plein formulaire. Un envoi part, la connexion vacille, et le client ne peut pas confirmer si le serveur l’a reçu. L’utilisateur voit une roue de chargement, suppose que ça a échoué, et renvoie le formulaire. Sans déduplication, il y a désormais deux enregistrements là où il n’en fallait qu’un.
- Le bouton d’envoi cliqué deux fois. 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 décomptes en aval.
- Une 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 %. Rien de tout cela ne fait planter l’application. Cela produit simplement un enregistrement mathématiquement absurde dès que quelqu’un le confronte à la réalité.
Aucun de ces cas n’est un mode de défaillance exotique. C’est la friction ordinaire de vraies personnes utilisant une application sur de vrais réseaux, et un simple prompt ne demande presque jamais à l’IA de s’en protéger, parce que s’en protéger n’ajoute aucun progrès visible à une démo.
Quand le calcul est faux sur chaque transaction
La deuxième variante de ce problème est encore plus discrète : une erreur d’arrondi ou de calcul qui se trompe d’une fraction de centime, à chaque fois, sur chaque transaction. Elle s’exécute proprement. Elle ne déclenche jamais d’exception. Le test unitaire, s’il en existe un, vérifie que le calcul renvoie un nombre, pas que ce nombre est exact à la dernière décimale sur dix mille exécutions.
C’est là que le test « ça fonctionne », sur lequel le vibe coding vous entraîne à vous appuyer, devient réellement dangereux. Un calcul de tarification qui se trompe de 0,3 % n’échoue pas pendant la démo. Il échoue lors de la réunion de rapprochement six mois plus tard, quand la finance fait remarquer que la somme de toutes les transactions individuelles ne correspond pas au chiffre du revenu total, et que personne ne peut expliquer pourquoi sans reprendre chaque enregistrement un par un.
Cet écart entre « la fonctionnalité marche » et « la fonctionnalité est correcte » est précisément ce que les tests automatisés sont censés détecter dans le développement logiciel professionnel, et précisément ce qui manque quand un créateur non technique est le seul à vérifier ce que produit l’IA. On peut confirmer visuellement qu’une page se charge. On ne peut pas confirmer visuellement qu’un calcul cumulatif est exact au centime près sur une année de transactions.
Pourquoi « ça a l’air bon » 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 s’envoie-t-il correctement ? | S’envoie-t-il exactement une fois, même sur une connexion instable ? |
| Le tableau de bord affiche-t-il un total ? | Ce total reste-t-il 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, c’est ce qu’une démo, et la plupart des tests manuels, vérifient réellement. La colonne de droite, c’est ce qui détermine si votre facturation, vos réservations ou vos rapports seront fiables au sixième mois. Le vibe coding s’optimise fortement pour la colonne de gauche et n’a aucun mécanisme naturel pour la colonne de droite, parce que celle-ci exige d’essayer délibérément de casser le scénario idéal, pas seulement de confirmer qu’il fonctionne.
Ce qui rend cela pire qu’un simple bug : impossible de savoir quels enregistrements sont faux
Un plantage a un périmètre de dégâts que l’on peut voir. Des données corrompues ont un périmètre de dégâts que l’on peut seulement deviner. Une fois qu’un bug de double envoi ou une erreur d’arrondi est en production depuis des mois, aucune marque n’indique les lignes concernées. Soit vous faites confiance à l’ensemble des données, dont vous savez désormais qu’il est peu fiable, soit vous les auditez enregistrement par enregistrement, ce qui, au-delà de quelques centaines de lignes, n’est pas réaliste pour une petite équipe sans temps d’ingénierie dédié.
C’est le vrai coût du « déficit de confiance » qui accompagne le code généré : vous n’avez jamais été en mesure de vérifier que la logique était étanche dès le départ, donc quand il 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 dégâts ne s’accumulent pas
Vous ne pouvez pas éliminer tous les cas limites en soignant davantage 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 des projets personnels, des prototypes internes, ou tout ce où un chiffre erroné est une gêne plutôt qu’un risque, le code généré et les tests manuels sont un compromis raisonnable pour aller vite. Le calcul change dès que les chiffres alimentent une facture client, un calendrier de réservations ou un rapport que quelqu’un valide officiellement. À ce stade, la question n’est plus « est-ce que ça avait l’air bon quand je l’ai testé », mais « qui vérifie que c’est toujours juste après dix mille transactions ».
Pour cette catégorie d’applications professionnelles, structurez le chemin d’écriture pour qu’il ne dépende pas de la capacité de l’IA à bien gérer la concurrence et les arrondis dès le premier (ou le cinquième) essai :
- Confiez les écritures essentielles à une infrastructure testée, pas à du code généré tout frais. Softr gère la création d’enregistrements, les mises à jour et les calculs de rollup (sommes, moyennes, décomptes sur les enregistrements liés) via son propre moteur de base de données plutôt que via une logique générée par IA propre à chaque application. Un rollup qui additionne les lignes d’une facture exécute le même calcul testé à chaque fois, au lieu d’une fonction sur mesure qu’une IA a écrite une fois et jamais testée sous contrainte pour une dérive d’arrondi.
- Utilisez des permissions visuelles plutôt qu’une logique de concurrence écrite à la main. Les User Groups et les Data Restrictions au niveau des enregistrements de Softr déterminent qui peut modifier quoi, ce qui réduit (sans l’éliminer) le problème des modifications simultanées en contrôlant l’accès au niveau de la plateforme plutôt qu’en dépendant d’un verrouillage codé sur mesure qu’une IA a pensé, ou non, à ajouter.
- Faites un rapprochement indépendant, selon un calendrier régulier. Aucune plateforme, no-code ou pas, ne remplace l’habitude de vérifier périodiquement les totaux par rapport à une source extérieure : un relevé bancaire, le tableau de bord d’un prestataire de paiement, un comptage manuel. Cela vaut que vous ayez construit sur du code généré par IA ou non, et c’est le seul moyen de repérer une erreur cumulative avant qu’elle n’atteigne un an d’ancienneté.
- Si vous restez dans le code, prévoyez du vrai temps pour des tests adversariaux. Si vous êtes développeur et utilisez Cursor ou Replit pour construire ou étendre une application personnalisée, écrivez explicitement des tests pour les écritures simultanées, les envois en double et les valeurs limites (nombres négatifs, zéro, dates extrêmes), parce que l’IA ne les génèrera pas sans qu’on le lui demande, et « ça compile » ne dit rien sur la fiabilité sous charge.
Rien de tout cela ne fait disparaître le problème de fond. 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 vraie différence entre une application dont la logique d’écriture a été générée sur mesure pour chaque projet et jamais testée sous contrainte, et une autre dont les opérations de base de données essentielles suivent le même chemin de code testé sur lequel s’appuie chaque entreprise de la plateforme. La première vous offre une nouvelle occasion de mal gérer la concurrence et les arrondis à chaque nouvelle fonctionnalité. La seconde ne vous dispense pas de votre responsabilité de rapprochement, mais elle élimine le pile ou face quotidien sur la capacité de cette fonction d’écriture générée par IA à gérer correctement un double clic.
Pour être honnête, les plantages sont agaçants mais indulgents. La corruption silencieuse, elle, est patiente. Elle attend que le volume de données soit assez élevé et que le temps écoulé soit assez long pour que la corriger coûte bien plus cher que ce qu’aurait coûté la prévenir.