Sécurité application web : 10 questions pour dirigeants

La semaine dernière, un fondateur m'a dit : « Mon développeur m'assure que c'est sécurisé. » J'ai posé 3 questions. Son dev n'a su répondre à aucune.

Ce n'est pas un cas isolé. En 15 ans d'audits de code, j'ai appris une chose : la majorité des dirigeants n'ont aucun moyen de vérifier ce qu'on leur dit sur la sécurité de leur application web. Et la majorité des développeurs sont sincères quand ils disent « oui c'est sécurisé » — ils ne pensent simplement pas aux mêmes choses que vous.

Ce qui suit, ce sont les 10 questions que je pose en début d'audit. Aucune ne nécessite de savoir coder. Les réponses — et surtout les non-réponses — vous diront exactement où vous en êtes.

Pourquoi « c'est sécurisé » ne veut rien dire

Imaginez que vous demandiez à votre garagiste : « Ma voiture est-elle en bon état ? » et qu'il réponde « Oui ». Sans détail. Sans ouvrir le capot. Vous seriez méfiant.

Avec la sécurité d'une application, c'est pareil. « C'est sécurisé » est une non-réponse. La sécurité ne se constate pas globalement — elle se vérifie point par point.

J'audite en moyenne 4 à 5 applications par mois. Sur les 12 derniers mois, plus de 8 sur 10 avaient au moins une faille critique. Dans chaque cas, le fondateur pensait que tout allait bien. Pas par négligence — parce qu'il n'avait pas les questions pour vérifier.

Le vrai problème n'est pas technique. C'est un problème d'asymétrie d'information. Votre dev sait (peut-être) ce qu'il fait. Mais si vous ne savez pas quoi lui demander, vous êtes aveugle.

Les 10 questions sécurité à poser à votre développeur

Avant de regarder une seule ligne de code, je pose ces questions. Les réponses me donnent déjà 80% du diagnostic.

1. « Les mots de passe sont-ils hashés ? Avec quoi ? »

Bonne réponse : « Oui, avec bcrypt » ou « argon2 ». Ce sont les standards actuels.

Red flag : « Oui bien sûr » sans précision. Ou pire : « MD5 » ou « SHA-1 ». Ces algorithmes sont cassés depuis des années.

Si votre base de données fuite — et statistiquement, ça arrive — des mots de passe mal protégés se craquent en quelques minutes. Avec bcrypt, ça prendrait des siècles.

Un fondateur m'a contacté après avoir découvert que son app — construite avec Lovable — stockait les mots de passe en clair. Pas hashés. En clair. Il l'a appris 6 mois après le lancement, quand un utilisateur curieux a inspecté les requêtes réseau.

2. « Un utilisateur peut-il voir les données d'un autre ? »

Bonne réponse : « Non, chaque requête vérifie que l'utilisateur a le droit d'accéder à cette ressource. »

Red flag : un silence, ou « normalement non ».

Le test est simple à comprendre : quand vous consultez votre profil ou une facture dans l'application, l'URL contient souvent un identifiant — un numéro, un code. Si on change ce numéro et qu'on accède aux données de quelqu'un d'autre, c'est une faille critique.

J'ai audité une fintech l'an dernier. En changeant un seul chiffre dans l'URL, on accédait aux factures de n'importe quel client. 2 300 clients exposés. Le correctif a pris 2 heures. Mais la faille était là depuis le premier jour.

3. « Que se passe-t-il si quelqu'un essaie 1 000 mots de passe en une minute ? »

Bonne réponse : « Le compte est bloqué temporairement après X tentatives » ou « On a un rate limiting. »

Red flag : « On n'a pas pensé à ça. »

Sans rate limiting, un attaquant teste des milliers de combinaisons par minute avec un script automatique. C'est l'attaque la plus basique qui existe — et elle fonctionne encore sur la moitié des apps que j'audite.

4. « Où sont stockés les secrets et les clés API ? »

Bonne réponse : « Dans des variables d'environnement, jamais dans le code. »

Red flag : « Dans le fichier de configuration » ou « Je ne sais plus. »

Les clés API, c'est ce qui permet à votre application de se connecter à des services tiers : paiement Stripe, envoi d'emails, stockage de fichiers. Si ces clés sont dans le code source, n'importe qui y ayant accès peut les utiliser. Et si votre code est sur GitHub en mode public — ce que j'ai déjà vu — elles sont accessibles au monde entier.

C'est d'ailleurs l'une des failles les plus fréquentes dans le code généré par IA. Les outils comme Lovable ou Bolt placent régulièrement les secrets dans le code côté client.

5. « Est-ce qu'on a des logs ? Qui accède à quoi, quand ? »

Bonne réponse : « Oui, on trace les connexions, les actions sensibles, les erreurs. »

Red flag : « On a les logs du serveur » (insuffisant) ou « Non, pas vraiment. »

Sans logs, vous êtes aveugle. Si un incident se produit — fuite de données, accès non autorisé — vous ne saurez pas quand c'est arrivé, comment, ni quelles données sont concernées. Et bonne chance pour expliquer ça à la CNIL.

6. « Que se passe-t-il si la base de données est volée ? »

Bonne réponse : « Les données sensibles sont chiffrées au repos, et on a des sauvegardes régulières testées. »

Red flag : « On a des sauvegardes » sans plus de détail. Ou « les données sont dans le cloud, donc c'est sécurisé ».

Deux choses distinctes ici. Le chiffrement : si quelqu'un vole votre base, peut-il lire les données en clair ? Les sauvegardes : si votre base est détruite par un ransomware, pouvez-vous restaurer ? Et surtout — a-t-on testé la restauration ? Une sauvegarde qu'on n'a jamais restaurée, ce n'est pas une sauvegarde. C'est un espoir.

7. « Les données sont-elles validées côté serveur ? »

Bonne réponse : « Oui, toute donnée entrante est vérifiée côté serveur avant traitement. »

Red flag : « On valide dans le formulaire. »

La validation côté client — dans le navigateur — c'est du confort utilisateur. Ça empêche votre utilisateur de soumettre un email mal formé. Mais un attaquant ne passe pas par le formulaire. Il envoie directement des requêtes au serveur. Si le serveur ne vérifie rien, c'est porte ouverte.

Un client SaaS m'a montré fièrement ses formulaires : « On a de la validation partout. » Toute la validation était dans le navigateur. Le serveur, lui, acceptait n'importe quoi — y compris du code malveillant dans les champs texte.

8. « HTTPS est activé partout ? »

Bonne réponse : « Oui, sur toutes les pages, et les requêtes HTTP sont redirigées automatiquement. »

Red flag : « Sur la page de login, oui. »

HTTPS chiffre les échanges entre le navigateur et le serveur. Sans lui, quelqu'un sur le même réseau Wi-Fi peut intercepter ce qui transite — y compris les mots de passe.

Mais attention à un raccourci fréquent : HTTPS protège le transport, pas l'application. Avoir HTTPS ne signifie pas que votre app est sécurisée. C'est fermer la porte d'entrée à clé en laissant les fenêtres ouvertes. Nécessaire, insuffisant.

9. « Quand a-t-on mis à jour les dépendances pour la dernière fois ? »

Bonne réponse : « On fait une revue mensuelle et on applique les correctifs de sécurité dès leur publication. »

Red flag : « On n'y touche pas, ça marche. »

Votre application utilise des dizaines — parfois des centaines — de briques logicielles tierces. Quand une faille est découverte dans l'une d'elles, un correctif est publié. Si vous ne mettez pas à jour, vous restez vulnérable à une faille connue et documentée. Le genre que les attaquants automatisent en premier.

10. « On a un plan si quelqu'un découvre une faille ? »

Bonne réponse : « On a une procédure : qui est responsable, comment isoler, qui prévenir. »

Red flag : « On avisera le moment venu. »

Pas besoin d'un document de 40 pages. L'essentiel : qui est responsable ? Comment on isole la faille ? Qui on prévient — clients, CNIL si données personnelles ? En combien de temps ? La RGPD impose de notifier la CNIL sous 72 heures en cas de violation de données personnelles. Si vous n'avez aucun process, vous allez passer ces 72 heures à paniquer au lieu d'agir.

Comment interpréter les réponses

Vous n'avez pas besoin de tout comprendre techniquement. Repérez trois catégories.

Réponses précises : votre dev cite des technologies, des processus, des fréquences. Bon signe. Ça ne garantit pas que tout est parfait, mais ça montre que la sécurité est un sujet actif, pas un angle mort.

Réponses évasives : « Oui oui c'est géré », « Normalement c'est bon », « C'est le framework qui s'en charge ». Ce sont des zones grises. Le sujet n'a peut-être pas été traité — ou traité par défaut, sans vérification.

Pas de réponse : silence, changement de sujet, ou le classique « Personne ne ferait ça ». Un dev qui vous dit « personne ne ferait ça » quand vous évoquez un scénario d'attaque — c'est le plus gros red flag possible. Les attaquants font exactement « ça ». C'est littéralement leur métier.

Pour aller plus loin sur la lecture d'un diagnostic technique, j'ai écrit un guide complet pour comprendre un rapport d'audit quand on n'est pas développeur.

Quand passer à l'audit professionnel

Ces 10 questions sont un filtre, pas un audit. Elles vous donnent une première lecture. Voici quand passer à l'étape suivante :

• 3 réponses évasives ou plus → il y a probablement des angles morts sérieux
• 1 seul blanc sur les questions 1, 2 ou 6 → ce sont les plus critiques : mots de passe, accès aux données, protection de la base
• Vous traitez des données sensibles : paiement, santé, données personnelles. « Probablement sécurisé » n'est pas acceptable dans ce contexte
• Votre app a été codée par IA : les outils comme Lovable, Bolt ou Cursor produisent du code fonctionnel mais négligent systématiquement la sécurité

Un dernier point. J'ai croisé un fondateur qui payait 800 €/mois à un prestataire pour de la « maintenance sécurité ». En creusant, le prestataire ne faisait rien. Zéro mise à jour, zéro monitoring, zéro log. Le fondateur n'avait aucun moyen de vérifier — parce qu'il ne savait pas quoi demander. Ces 10 questions auraient suffi à s'en rendre compte dès le premier mois.

Votre checklist sécurité

Les 10 questions résumées. Pour chaque réponse obtenue, cochez la colonne correspondante :

Votre score :

• 8 à 10 réponses précises → vous êtes en bonne posture
• 5 à 7 → des zones grises à éclaircir, commencez par les rouges
• Moins de 5 → un audit s'impose, surtout si vous traitez des données utilisateurs

La sécurité de votre application web n'est pas un sujet que vous pouvez déléguer à l'aveugle. Vous n'avez pas besoin de savoir coder. Vous avez besoin de poser les bonnes questions. Ces 10 questions, n'importe quel dirigeant peut les poser lundi matin. Les réponses vous diront exactement où vous en êtes.

Si les réponses vous inquiètent — ou si vous n'en obtenez pas — je peux auditer votre application et vous donner un rapport clair, sans jargon, avec un plan d'action priorisé.