Tous les tests passaient. La revue de sécurité a trouvé quatre failles.

J'ai construit un site complet pour un salon de coiffure : trilingue, avec une vraie réservation en ligne, un agenda, des e-mails de confirmation, et une interface où le gérant change lui-même ses textes, ses prix et ses photos. Le tout sur un hébergement mutualisé à quelques euros par mois.

Avant de le mettre en ligne, j'ai demandé une revue de sécurité. Je pensais que ce serait une formalité : une centaine de tests automatiques au vert, plus de mille assertions, un relecteur indépendant qui avait validé la conception à 100/100, et des contrôles de sécurité qui tournent à chaque modification du code.

Résultat : aucune faille critique, mais une faille haute et trois moyennes.

C'est le sujet de cet article. Pas la rapidité — coder vite, les outils d'aujourd'hui le permettent à tout le monde. Ce qui change quelque chose, c'est ce qui se passe entre « ça marche » et « je le mets en ligne ».

Pourquoi les tests ne pouvaient pas les trouver

La phrase à retenir si vous n'en retenez qu'une :

Les tests vérifient que le site fait ce qu'on a prévu. Une revue de sécurité cherche ce qu'on n'a pas prévu.

Ce sont deux métiers différents, et le second ne se déduit pas du premier. Aucune des quatre failles n'était visible pour les tests, parce qu'aucune ne relevait d'un comportement attendu qui aurait mal fonctionné. Toutes relevaient d'un comportement correct, détourné de son usage.

Pour un site qui stocke des noms, des téléphones et des e-mails de clients, la revue n'est donc pas un supplément de confort : c'est le minimum avant la mise en ligne. Si vous faites construire un site qui prend des rendez-vous, c'est la question à poser à votre prestataire — pas « est-ce que c'est testé ? », mais « est-ce que quelqu'un a cherché à le casser ? »

Quatre leçons, sans mode d'emploi

Les failles ont toutes été corrigées avant la mise en ligne, chacune avec un test. Je décris ici le mécanisme, pas la marche à suivre — le code sert de base à d'autres projets.

Une protection peut se retourner contre celui qu'elle protège. Le blocage du compte après plusieurs mauvais mots de passe existe pour protéger le gérant. Tel qu'il était réglé, n'importe qui pouvait s'en servir pour l'enfermer dehors, procédure d'urgence comprise. La question à se poser devant chaque garde-fou : et si l'attaquant l'utilisait contre l'utilisateur ?

Un compteur qui lit, ajoute 1, puis réécrit, ne compte plus quand tout arrive en même temps. La limite de réservations par heure tenait parfaitement en test, et cédait dès que les demandes partaient simultanément. L'incrément doit se faire dans la base, en une seule opération. C'est une erreur de conception courante, invisible à la relecture, et que seul un test de simultanéité révèle.

Une étape à moitié faite peut laisser une porte ouverte. Un écran de changement de téléphone, abandonné en cours de route, pouvait laisser le compte sans sa double authentification — le mot de passe seul suffisait alors pour entrer. Toute procédure en plusieurs temps doit être pensée pour le cas où l'utilisateur ferme la fenêtre au milieu.

Pour un commerce local, la disponibilité et la réputation pèsent autant que la confidentialité. Un agenda qu'on peut saturer, ou un nom de domaine marqué comme expéditeur de courrier indésirable, coulent un salon aussi sûrement qu'une fuite de données. Tout champ recopié dans un e-mail envoyé à une adresse choisie par un inconnu est une arme potentielle. On y pense rarement quand on se concentre sur les injections de base de données.

Ce qu'il faut exiger d'une revue de sécurité

Qu'elle soit menée par un humain ou outillée, une revue utile ne ressemble pas à un audit de conformité. Voici ce qui a fonctionné, et ce que vous pouvez exiger :

• Un changement de posture, pas une vérification. La consigne n'est pas « vérifie que c'est sûr » mais « trouve comment en abuser ». La question cesse d'être est-ce que ça marche pour devenir comment je le détourne.
• Un découpage par surface d'attaque. Qui regarde tout survole. Trois zones séparées — la connexion, la partie publique, l'administration et le déploiement — et chacune creusée pour elle-même.
• Des scénarios concrets, pas des bonnes pratiques. Pour chaque faille : le fichier, la ligne, les conditions, l'impact, la gravité, le niveau de confiance. Un rapport qui conseille « ajoutez un pare-feu » n'est pas un rapport.
• La preuve que le chemin est réellement atteignable. Sinon on croule sous les faux positifs. Un rapport m'a décrit une faille dans une fonction de restauration… qui n'existe pas.
• Un relecteur en lecture seule. Il rapporte, il ne corrige pas. La correction est un autre travail, avec ses propres tests.
• Le contexte métier. « Petit commerce, un seul gérant, données clients » : c'est ce qui fait penser à l'agenda saturé et au courrier indésirable, et pas seulement aux attaques de manuel.
• Une revue qui dit aussi ce qui reste. Trois points faibles ont été reportés, écrits noir sur blanc avec leur raison. C'est précisément ce qui permet de signer en connaissance de cause. Une revue qui ne trouve rien et ne reporte rien n'a pas été faite.

Et une règle de méthode : ne jamais croire un rapport sans le revérifier dans le code. Chaque constat a été relu avant correction.

Ce que les contrôles avaient déjà arrêté avant

La revue de sécurité est le dernier filet, pas le seul. Avant elle, neuf défauts ont été arrêtés avant la production, dont quatre graves — aucun par un utilisateur, tous par un contrôle ou une relecture. Ils sont listés un par un dans le compte rendu du dépôt. Les plus parlants :

Ce dernier mérite d'être noté : il a été trouvé avant qu'une ligne de code soit écrite. C'est ce que coûte vraiment une relecture de conception, et ce qu'elle rapporte.

Et les contrôles eux-mêmes ont été mis à l'épreuve : vingt-deux dérives ont été introduites volontairement dans le code, et chacune a fait passer son contrôle au rouge. C'est la vérification qu'on oublie toujours de faire — un contrôle qui ne peut pas échouer ne prouve rien. Même chose pour les correctifs des failles : pour chaque test ajouté, l'ancien code a été remis en place pour vérifier que le test devenait bien rouge.

Ce qui a raté quand même

La partie la plus instructive, et celle qui justifie de prendre le temps de vérifier soi-même.

Deux minutes après avoir lancé le site en local, la page de réservation affichait « Something went wrong ». La commande de lancement oubliait la clé de chiffrement. Les tests passaient tous — parce qu'ils fournissaient la clé eux-mêmes, et qu'aucun test ne lançait la commande que j'utilise réellement. Corrigé à la racine : une seule source de configuration pour les tests et pour le lancement local.

C'est le piège le plus courant de tous : une suite de tests verte prouve que le code marche dans les conditions des tests, pas dans les vôtres.

Avant de publier le dépôt, près de trois mille fichiers s'étaient retrouvés commités par erreur — dépendances, cache, images de test. Aucun secret parmi eux, mais rien à y faire. Nettoyé, puis revérifié sur un clone vraiment neuf, c'est-à-dire dans les conditions de quelqu'un qui découvre le projet.

L'architecture, qui ne se voit pas mais qui décide de la suite

C'est le point invisible sur une démonstration, et probablement le plus important pour vous.

Ce n'est pas un site vitrine avec un formulaire : c'est une application construite dès la première ligne en domaines métier séparés, avec les règles au centre et la technique autour. Quatre domaines indépendants — l'accès, la vitrine, l'agenda, les notifications. Au centre, des règles pures : pas deux clients sur le même fauteuil au même moment, annulation possible jusqu'à deux heures avant. Elles ne savent rien de la base de données, du web ni des e-mails. Autour, des adaptateurs interchangeables : on change de base ou de fournisseur d'e-mails sans toucher aux règles.

Et ce n'est pas qu'une intention affichée : un contrôle automatique refuse tout commit qui mettrait du code technique dans le cœur métier.

Pourquoi ça vous concerne : on peut ajouter des capacités une par une sans casser l'existant. Après la réservation, le même salon peut recevoir la gestion de stock, une carte de fidélité, la caisse, la facturation, le planning du personnel — chacune comme un nouveau domaine branché sur les autres par des interfaces claires. Vous évitez la refonte classique du jour où « le petit site » ne suffit plus.

Un progiciel de gestion reste plus que du code — comptabilité légale, facturation conforme, support. Mais la fondation technique, elle, est déjà prête à le porter. C'est la même logique de séparation entre ce qui est propre à un projet et ce qui se construit une fois pour toutes que je détaille dans la carte d'un produit déployé.

Ce que ça coûte à héberger

Le site tourne sur un mutualisé classique : PHP et MySQL, rien d'autre à administrer. Deux offres conviennent (tarifs relevés en octobre 2026, première année) :

• Une offre d'entrée, autour de 2 € par mois : un site, une base, une adresse e-mail. La base d'un salon pèse quelques mégaoctets. Suffisant pour une démonstration ou un lancement. Limite : un seul site, donc pas d'environnement de test — on déploie directement en production.
• Une offre intermédiaire, autour de 3,60 € par mois : plusieurs sites et bases. C'est celle que j'ai retenue, parce qu'elle permet un site de test à côté de la production : chaque mise à jour passe d'abord par le test, et la production ne la reçoit qu'une fois vérifiée.

Le conseil : l'entrée de gamme pour une démonstration, l'offre au-dessus dès qu'il y a de vrais clients qui réservent. Le code est le même, on passe de l'un à l'autre sans rien réécrire. Un comparatif de cinq hébergeurs et la procédure de mise en ligne pas à pas sont dans le dépôt.

Pour une startup : la démonstration devient le produit

C'est là que je vois le vrai changement. Une équipe qui doit montrer quelque chose à des clients ou à des investisseurs a deux options habituelles : une maquette jolie mais vide, qu'on jette ensuite, ou un développement complet avant de savoir si l'idée tient.

Il y a une troisième voie :

• Un produit qui fonctionne vraiment, pas une image : on réserve, on reçoit l'e-mail, le gérant modifie ses prix.
• Quelques euros par mois : on peut le laisser tourner pendant qu'on teste le marché, sans brûler de trésorerie.
• L'apparence est validée dès la démonstration et conservée ensuite : les retours des premiers utilisateurs portent directement sur le produit final, pas sur un brouillon.
• Le code n'est pas jetable : architecture par domaines, tests, décisions tracées.

Le risque se déplace. Il n'est plus de savoir si on peut le construire, mais si quelqu'un en veut — et c'est exactement la question qu'une démonstration doit trancher.

Ce que ça change pour vous

Si vous faites construire un site qui prend des rendez-vous ou stocke des données de clients, trois questions suffisent à juger le sérieux de ce qu'on vous livre :

• Est-ce que quelqu'un a cherché à le casser, et pas seulement vérifié qu'il marche ?
• Les contrôles qui protègent votre site ont-ils été mis à l'épreuve — a-t-on vérifié qu'ils savent dire non ?
• Ce qui reste en suspens est-il écrit quelque part, ou vous a-t-on seulement dit que tout était vert ?

Tout le projet est public et sous licence MIT : le code, les documents de conception, la revue de release signée, le compte rendu détaillé et les vidéos des huit parcours rejoués dans un vrai navigateur. La méthode qui encadre tout ça, je la décris dans l'article sur la fiabilité.

Si vous voulez qu'on regarde votre projet dans ces termes, parlons-en.