Ton appli marche. Ça ne prouve pas qu’elle est sûre.

72 contrôles. C’est la grille publiée le 6 octobre par In Data Veritas pour vérifier la sécurité d’une application créée avec l’IA. Signée Frédéric Paillon et Augustin Garcia.

La phrase de départ mérite d’être affichée au-dessus de ton écran : une application qui fonctionne en démonstration n’a pas prouvé qu’elle est sûre.

Le piège du parcours réussi

Quand tu crées un outil en vibe-coding, tu testes ce qui doit marcher. Tu remplis le formulaire. Il s’envoie. Tu te connectes. Ça marche. Tu es content.

Le problème : la sécurité, c’est tester ce qui ne doit pas marcher.

• Un utilisateur peut-il voir les fichiers d’un autre ?
• Une page d’administration est-elle accessible en tapant directement son adresse ?
• Un compte suspendu peut-il encore se connecter avec une ancienne session ?
• Deux demandes envoyées en même temps peuvent-elles consommer un crédit qui n’existe qu’une fois ?

Aucun de ces cas n’apparaît quand tu fais ta démo. Tous peuvent coûter cher.

5 failles décrites dans l’article

Le bouton caché

Masquer un bouton ne protège rien. Si la fonction existe côté serveur, quelqu’un peut l’appeler directement. La règle : chaque action est vérifiée côté serveur, pour chaque personne, à chaque fois.

Le voisin qui voit tes fichiers

Être connecté ne donne pas le droit de tout lire. Chaque document, chaque champ, chaque opération doit vérifier : cette personne a-t-elle le droit, sur cet objet précis ?

Le cache qui mélange les clients

Exemple fictif cité par l’article : un outil de rédaction utilisé par 2 entreprises. Le cache sert le résultat de l’une à l’autre. Chaque écran, testé seul, paraissait correct.

La facture qui s’envole

Les services payés à l’usage, modèles d’IA, e-mails, SMS, peuvent générer des dépenses sans plafond. L’article distingue 4 limites à poser : débit, volume, simultanéité, budget.

L’injection par document

Si ton appli utilise l’IA, un document importé ou une page web peut contenir des instructions cachées. La protection doit reposer sur des contrôles techniques. Pas sur une consigne polie donnée au modèle.

« Demande à l’IA de vérifier » ne suffit pas

Point important pour les non-développeurs. Demander à l’IA de « jouer un auditeur hostile » ne fait pas d’elle un auditeur. Elle n’a pas accès à ton hébergement. Elle ne connaît pas forcément toutes tes routes. Elle partage les hypothèses du projet qu’elle a elle-même écrit.

Un audit utile produit des preuves : quels fichiers ont été lus, quelle version, quels tests ont réellement tourné.

L’article propose 4 statuts pour chaque contrôle :

• PASS : exigence satisfaite, avec preuve ;
• FAIL : problème établi ;
• UNKNOWN : pas assez d’éléments ;
• N/A : non applicable, avec justification.

Et une règle : un UNKNOWN sur un point critique se traite comme un problème, avant d’ouvrir au public.

Pourquoi on travaille sur un harnais

C’est exactement pour ça qu’on forme au vibe-coding sur Hypervibe, le harnais conçu par Flavien Chervet.

Un harnais, c’est l’ensemble des règles, outils et garde-fous qui entourent l’IA quand elle code. Au lieu de laisser le modèle improviser, le harnais lui impose des étapes. Dans Hypervibe, la sécurité n’est pas une option qu’on pense à demander à la fin :

• une commande dédiée audite la sécurité du projet : secrets exposés, routes non protégées, validation des données, dépendances vulnérables ;
• les clés d’accès vivent dans un coffre-fort, jamais en clair dans le code ;
• un contrôle bloque l’enregistrement d’un secret dans l’historique du projet ;
• les déploiements en production ne partent pas sans ton accord.

Ça ne remplace pas un expert en sécurité pour une application sensible. L’article le dit, on le répète. Mais ça change le point de départ : tu ne pars plus d’une page blanche avec un modèle qui veut te faire plaisir.

Ta mini-check-list avant d’ouvrir ton outil

Même pour un outil interne à 5 utilisateurs.

• Crée 2 comptes de test. Avec le premier, crée des données. Avec le second, essaie de les voir.
• Tape les adresses directement. Toutes les pages réservées à l’administrateur, depuis un compte normal.
• Suspends un compte de test. Vérifie qu’il ne peut plus rien faire.
• Pose un plafond de dépense chez chaque fournisseur payant : IA, e-mail, SMS. Vérifie-le sur le compte réellement utilisé.
• Lance l’audit de sécurité de ton harnais et lis le rapport en entier.
• Écris qui fait quoi en cas d’incident : qui corrige, qui paie, qui prévient les utilisateurs.

Et le budget ?

L’article insiste sur un risque que les créateurs d’outils oublient : l’argent. Une requête dont la réponse s’est perdue peut déjà avoir été facturée. Un formulaire sans limite peut être appelé 10 000 fois dans la nuit.

Les bons réflexes :

• vérifier les droits de l’utilisateur avant chaque appel payant ;
• réserver une enveloppe bornée par utilisateur ou par jour ;
• comparer chaque semaine la consommation prévue et la consommation réelle.

Les plafonds des fournisseurs n’ont pas tous la même portée ni le même délai. Vérifie-les un par un.

Ce qu’on retient

Le vibe-coding t’a donné la vitesse. Il ne t’a pas dispensé de la prudence.

« Ça marche » est le début des tests. Pas la fin.