La semaine dernière j'ai audité une app construite avec Lovable. L'interface était clean, le parcours utilisateur fluide, le fondateur était fier de sa démo. Score d'audit : 34 sur 100. Sa réaction : "Mais ça marche sur mon écran."
Oui. Ça marchait sur son écran. Mais ça ne marchait pas en production.
Le problème
Avec les outils IA, tu peux construire en 48h ce qui prenait 3 mois. C'est génial. Mais la vitesse crée un faux sentiment de sécurité. Tu vois un produit qui a l'air fini, tu penses qu'il est prêt.
Le truc c'est que les études le confirment : les développeurs qui utilisent massivement l'IA pensent avoir créé du code de meilleure qualité qu'en réalité. C'est un biais cognitif. L'IA te donne un consensus, pas du discernement. Elle génère du code qui ressemble a du bon code. Mais ressembler et être, c'est deux choses différentes.
L'écart entre "ça marche" et "c'est prêt" est énorme. Et c'est dans cet écart que les problèmes se cachent.
Les 3 axes d'un audit sérieux
Quand j'audite une app, je regarde trois choses. Toujours les mêmes, dans le même ordre.
Sécurité
C'est le plus critique et c'est la que je trouve le plus de problèmes.
HTTPS partout, sans exception. Pas de secrets (clés API, mots de passe) dans le code client. Validation des inputs côté serveur, pas juste côté client. Protection XSS. Le taux d'échec sur le code IA pour le XSS : 86%. Protection CSRF sur tous les formulaires. Rate limiting pour éviter les abus. Audit des dépendances, parce que ton app importe des dizaines de packages et chacun est un vecteur d'attaque potentiel. Et surtout : pas de .env, pas de credentials dans le repo Git.
Point critique que personne ne te dit : les outils comme Cursor, Lovable et Bolt ne sont PAS sécurisés par défaut. L'IA génère du code fonctionnel, pas du code sécurisé. C'est toi qui dois ajouter la sécurité. Et si tu ne sais pas ce que ça veut dire, tu ne peux pas le faire.
Fiabilité
Ton app charge en combien de temps ? Si c'est plus de 3 secondes, tu perds la moitié de tes utilisateurs. C'est pas moi qui le dis, c'est Google.
Gestion d'erreurs : quand quelque chose plante, qu'est-ce qui se passe ? L'utilisateur voit un écran blanc ? Un message cryptique ? Ou un message clair qui l'aide ? Monitoring et logging : tu sais quand ton app plante ? Tu es prévenu avant tes utilisateurs ?
Et surtout : tu as testé sur de vrais appareils ? Pas juste ton MacBook avec Chrome. Un vrai téléphone Android avec une connexion 4G moyenne. C'est la que les apps vibecodées révèlent leurs faiblesses.
Les apps Bolt commencent a se dégrader a partir de 15-20 composants. Les apps Lovable génèrent parfois du code trop complexe pour des problèmes simples. Ce sont des patterns que je vois a chaque audit.
Expérience utilisateur
Accessibilité : est-ce que chaque image a un texte alternatif ? Est-ce qu'on peut naviguer au clavier ? Est-ce que les contrastes sont suffisants ? Ce n'est pas du bonus. C'est une obligation légale dans beaucoup de pays.
Responsive mobile : les boutons font au minimum 44x44 pixels pour être cliquables au doigt ? Les formulaires sont utilisables sur un écran de 5 pouces ? Le texte est lisible sans zoomer ?
Parcours utilisateur : est-ce que le chemin de A a B est logique ? Est-ce que les messages d'erreur aident l'utilisateur a comprendre quoi faire ?
La checklist minimum avant lancement
Voici ce que je vérifie systématiquement. Tu peux t'en servir comme point de départ.
Sécurité : HTTPS actif, secrets hors du code client, validation serveur des inputs, protection XSS et CSRF, rate limiting, dépendances a jour, pas de credentials dans le repo.
Performance : temps de chargement sous 3 secondes, images optimisées, bundle size raisonnable.
Données : backup automatique, chiffrement des données sensibles, conformité RGPD si tu as des utilisateurs européens.
Monitoring : alertes d'uptime, tracking des erreurs, analytics de base.
Mobile : testé sur vrais appareils, responsive, touch targets corrects.
Accessibilité : alt text sur les images, navigation clavier, contrastes suffisants, labels sur les formulaires.
Déploiement : rollback possible, variables d'environnement séparées entre dev et production.
Pourquoi tu ne peux pas le faire toi-même
Si tu as vibecodé ton app, tu ne comprends probablement pas 100% du code. C'est normal. C'est le principe même du vibecoding.
Mais ça veut dire que tu ne peux pas auditer ce que tu ne comprends pas. C'est comme relire son propre texte pour chercher les fautes. Tu ne les vois pas parce que ton cerveau complète automatiquement. Tu as besoin d'un regard extérieur technique. Quelqu'un qui sait lire le code, qui connaît les failles classiques, qui a vu assez d'apps pour reconnaître les patterns dangereux.
Ce n'est pas une question de compétence. C'est une question de perspective.
Tu veux un score sur 100 de ton app avant le lancement ? C'est exactement ce que je fais. julia@aj-ventures.com