30 points à vérifier
avant de mettre votre
application en production.

1 — Accès et comptes

1. Faites la liste des personnes qui peuvent atteindre la production. Anciens prestataires inclus. C'est presque toujours plus long que prévu.
2. Retirez les accès des personnes qui ne travaillent plus sur le projet. Un accès oublié est le point d'entrée le moins coûteux pour un attaquant.
3. Activez l'authentification à plusieurs facteurs sur l'hébergeur, le dépôt de code, la base de données et la messagerie.
4. Supprimez les comptes partagés. Si trois personnes utilisent le même identifiant, aucune trace n'est exploitable en cas de problème.
5. Vérifiez à quel nom sont enregistrés le domaine et les services critiques. S'ils dépendent de l'adresse personnelle d'un tiers, corrigez-le avant tout le reste.

2 — Secrets et clés d'API

6. Aucune clé ni mot de passe dans le code. Ils doivent venir de variables d'environnement.
7. Vérifiez l'historique du dépôt, pas seulement la version actuelle. Un secret supprimé hier reste lisible dans l'historique — et doit donc être révoqué, pas seulement effacé.
8. Vérifiez ce qui part dans le navigateur. Tout ce qui est livré au navigateur est lisible par n'importe quel visiteur : aucune clé sensible ne doit s'y trouver.
9. Séparez les clés de test et de production. Et assurez-vous que celles de test ne peuvent rien faire de réel.
10. Sachez révoquer une clé en urgence. Si vous ne savez pas où cliquer, vous ne le saurez pas non plus le jour d'une fuite.

3 — Contrôle d'accès aux données

11. Les règles d'accès sont appliquées côté serveur. Masquer un bouton dans l'interface ne protège rien : la requête reste possible.
12. Testez avec deux comptes différents. L'utilisateur A peut-il, en changeant un identifiant dans l'URL, voir les données de l'utilisateur B ?
13. Si vous utilisez Supabase ou Firebase, vérifiez les règles de sécurité table par table. Ces règles ne sont pas actives par défaut, et c'est le défaut le plus fréquent sur cette architecture.
14. Vérifiez ce que renvoient vraiment vos API. Une réponse contient souvent plus de champs que l'écran n'en affiche.
15. Protégez les pages d'administration. Ne pas être listée quelque part ne rend pas une page inaccessible.

4 — Données personnelles

16. Listez les données personnelles que vous collectez réellement. Y compris celles collectées « au cas où ».
17. Supprimez ce dont vous n'avez pas besoin. La donnée que vous ne détenez pas ne peut pas fuiter.
18. Vérifiez que votre politique de confidentialité décrit ce que fait le produit. L'écart entre les deux est fréquent, et c'est lui qui pose problème en cas de contrôle.
19. Recensez les services tiers qui reçoivent ces données — hébergeur, envoi d'e-mails, analytics, modèles d'IA — et vérifiez où elles sont stockées.
20. Sachez répondre à une demande de suppression. Concrètement : quelqu'un demande l'effacement de son compte, que faites-vous, et en combien de temps ?

Sur ce volet, voir la conformité technique RGPD. Si votre application envoie des données à un modèle d'IA, voir aussi notre page sur l'AI Act.

5 — Sauvegardes et reprise

21. Les sauvegardes existent et sont automatiques. Une sauvegarde manuelle est une sauvegarde qu'on oublie.
22. Une restauration a déjà été testée. C'est le seul moyen de savoir qu'une sauvegarde fonctionne — beaucoup découvrent qu'elles sont vides le jour où ils en ont besoin.
23. Les sauvegardes ne sont pas au même endroit que la production. Sinon un même incident emporte les deux.
24. Vous savez combien de données vous perdriez en cas de restauration : une heure, un jour ?
25. Vous savez remettre en ligne la version précédente si un déploiement casse tout.

6 — Surveillance et mise à jour

26. Les erreurs sont enregistrées quelque part que vous consultez. Des journaux que personne ne lit n'apportent rien.
27. Vous êtes alerté quand le service tombe — par une sonde externe, pas par un client mécontent.
28. Vous savez si vos dépendances comportent des vulnérabilités connues, et vous les mettez à jour régulièrement.
29. Le site est servi en HTTPS, avec un certificat qui se renouvelle tout seul, et vous êtes prévenu avant son expiration.
30. Une adresse de contact permet de vous signaler un problème de sécurité. Sans elle, une personne bien intentionnée qui découvre une faille n'a aucun moyen de vous prévenir.

Comment utiliser cette liste

Elle n'est pas un référentiel de certification, et cocher les trente points ne rend pas une application inattaquable. C'est un filtre : il élimine les défauts les plus fréquents et les plus coûteux, ceux qui reviennent dans la quasi-totalité des audits.

Si vous butez sur plusieurs points sans savoir comment les vérifier, c'est généralement le signe qu'un regard extérieur ferait gagner du temps — voir l'audit de code et de sécurité. Et si votre application a été construite avec Lovable, Bolt ou Cursor, les points 11 à 15 méritent une attention particulière : voir l'audit sécurité Lovable et Supabase.