Vérifier son application avant de la mettre en ligne : les 23 failles qu'un audit a trouvées

La dernière semaine sert à écrire l'annonce, préparer les captures et prévenir les premiers clients. Deux relectures de sécurité commandées avant lancement, racontées l'une par son commanditaire, l'autre par le prestataire qui l'a menée, montrent ce que cette semaine devrait contenir en plus, et pourquoi la liste tient en cinq jours de travail ordinaire.

Le propriétaire d'une place de marché construite sans coder raconte sur Reddit (r/nocode, août 2026) que l'audit commandé avant sa mise en ligne a produit 23 constats sur quatre niveaux de gravité, dont un qui laissait l'acheteur fixer lui-même le prix des produits. Vérifier son application avant de la mettre en ligne demande une semaine et une liste.

Ce que deux relectures ont trouvé

Les trois premiers constats de la place de marché portent sur le prix fixé par l'acheteur au moment de payer, sur des contrôles d'accès absents et sur des données modifiables sans authentification. Une seconde relecture, décrite par un prestataire sur r/vibecoding (juillet 2026), a trouvé autre chose : chaque visiteur de la démonstration créait en silence une société, un espace de travail et un profil permanents dans la base qui servait la production, et cinq règles de sécurité donnaient un accès plus large que prévu. Son commanditaire attendait des milliers de faux comptes dans les heures suivant l'ouverture. Aucun de ces défauts ne se voit à l'écran, et aucun n'empêchait l'application de fonctionner. Les deux relectures ont été commandées avant l'ouverture au public ; celles qui ne sont pas commandées laissent l'application partir le jour prévu, avec les mêmes défauts et sans la liste qui les nomme.

Le chemin heureux et tout le reste

Un autre témoignage (r/vibecoding, août 2026) formule le doute que partagent la plupart des commanditaires : son auteur ne savait pas si ses points d'entrée vérifiaient les permissions du côté du serveur, ni si un utilisateur pouvait récupérer les données d'un autre en devinant un identifiant. Son prototype avait été mis en ligne en un week-end, pour un travail qu'il estimait auparavant à des mois. L'IA construit le parcours pour lequel on l'a briefée, celui du client qui fait ce qu'on attend de lui. Tout ce qui sort de ce parcours reste à décider, et c'est ce que les deux relectures ci-dessus ont facturé. Un prestataire de sécurité vend cette liste de cas que personne n'a commandés : les accès entre comptes, les montants modifiables, les états d'erreur et les suppressions.

Lire le code ne suffit pas

Replit a ajouté le 17 août 2026 des tests d'intrusion en boîte noire, qui attaquent l'application depuis son adresse publique sans lire son code, en complément de l'analyse du code lui-même (replit.com, août 2026). L'éditeur classe ses vérifications en trois niveaux, le premier gratuit, et écrit que les constats des deux approches se recoupent peu : il cite un tableau de bord d'administration laissé sans protection, trouvé depuis l'extérieur et manqué par la lecture du code. Cette annonce vaut surtout comme aveu utile pour celui qui commande un logiciel : demandez les deux, quel que soit l'outil qui a construit votre application.

Ce que Félix fait, et ce qu'il ne fait pas

Chez Maestro, la vérification vit à l'intérieur du travail : Constance relit le cahier des charges avant que la construction ne commence, Félix écrit les tests de chaque étape avant qu'elle ne soit construite, et une étape qui échoue à sa vérification repart en réparation. Ce dispositif attrape les règles oubliées et les régressions, et il oblige à écrire noir sur blanc qui a le droit de lire quoi, comme nous l'expliquions dans le test en deux minutes sur vos données clients. Personne, chez nous, n'attaque votre application depuis l'extérieur une fois qu'elle est en ligne. Nous ne sommes pas non plus à l'abri de nos propres défauts, et la clé qui était visible dans notre code l'a rappelé en août. Une relecture de sécurité commandée à quelqu'un dont c'est le métier reste une dépense à prévoir dans votre budget de lancement.

La liste de la semaine d'avant

Quatre passes tiennent dans cinq jours. Lundi, les droits : pour chaque écran et chaque donnée, écrivez qui peut lire et qui peut modifier, puis vérifiez le comportement avec deux comptes d'essai. Mardi, l'argent : refaites un achat en modifiant ce que vous pouvez modifier de votre côté (quantité, code de réduction, adresse de livraison) et regardez si le montant final reste celui du catalogue. Mercredi, la séparation : assurez-vous que les visiteurs de votre démonstration et vos données de test n'écrivent rien dans la base qui sert vos vrais clients. Jeudi, les états tristes : compte supprimé, paiement refusé, export demandé, mot de passe perdu. Vendredi, faites relire par quelqu'un d'extérieur, et gardez le rapport : à partir du 11 septembre 2026, votre logiciel a aussi des comptes à rendre.