Trouvez-le avant quelqu’un d’autre.
Un test qui produit un rapport de scanner n’est pas un test. Nous menons de vraies attaques contre votre application et vous montrons ce qui a réellement fonctionné.
Nous essayons de pénétrer votre application web ou votre API comme le ferait un attaquant, puis nous vous disons ce qui a marché, sa gravité et comment le corriger. Un contre-test après vos corrections fait partie de la mission. Nous ne détenons aucune qualification ni certification : si votre contexte l’exige, il vous faut un prestataire qualifié.
Mis à jour novembre 2026
Un scan automatique n’est pas un test d’intrusion, même si beaucoup sont vendus comme tels.
Les scanners trouvent des motifs connus. Ils ne remarquent pas qu’en changeant un chiffre dans une adresse, on voit la facture d’un autre client, ni que la réinitialisation du mot de passe peut viser le compte de quelqu’un d’autre. Ce sont ces constats qui comptent, et il faut une personne pour les trouver.
Un vrai test est donc surtout manuel, et vise votre logique métier autant que vos bibliothèques. Les constats utiles tiennent en général à la façon dont votre application fonctionne plutôt qu’à ce avec quoi elle a été construite.
Et le rapport doit être utilisable. Cinquante constats classés par un score de gravité générique ne font pas un plan. Ce qu’il vous faut : corrigez ces trois-là cette semaine, ces cinq ce trimestre, et voici pourquoi le reste peut attendre.
Ce que nous testons.
Authentification et sessions
Connexion, réinitialisation, jetons, expiration. Là où se trouvent d’habitude les constats les plus graves.
Contrôle d’accès
Un utilisateur peut-il atteindre les données d’un autre en changeant une valeur ? La faille sérieuse la plus fréquente, de loin.
Logique métier
Remises appliquées deux fois, quantités négatives, étape sautée. Les scanners ne les trouvent jamais.
Injections et traitement des entrées
SQL, commandes, gabarits. Mieux qu’avant, toujours à vérifier.
Les API en particulier
Souvent moins protégées que l’interface web, et de plus en plus la porte d’entrée.
Envoi et stockage de fichiers
Ce qu’on peut envoyer, où cela atterrit, et qui peut le lire ensuite.
Configuration
Interfaces d’administration exposées, identifiants par défaut, messages d’erreur trop bavards, stockage laissé public.
Un contre-test après correction
Il fait partie de la mission. Un rapport qu’on ne peut pas vérifier n’est que la moitié du travail.
Scan, test ou audit.
Les trois sont appelés tests d’intrusion. Ils ne coûtent pas et ne livrent pas du tout la même chose.
| Scan automatique | Test d’intrusion | Audit complet | |
|---|---|---|---|
| Trouve les vulnérabilités connues | Oui | Oui | Oui |
| Trouve les failles de logique métier | Non | Oui — la partie précieuse | Oui |
| Enchaîne de petites failles | Non | Oui | Oui |
| Examine le code source | Non | Parfois | Oui |
| Faux positifs | Nombreux | Rares — vérifiés à la main | Rares |
| Ordre de grandeur | Quelques heures | Quelques semaines | Plus long |
| Adapté à | Une vérification continue | Avant un lancement, ou chaque année | Secteurs réglementés, ou avant une acquisition |
Notre façon de travailler.
Périmètre et autorisation écrits avant de commencer. Sans exception.
Les failles de logique métier sont là où se trouvent les dégâts, et aucun scanner ne les trouve.
Nous ne sommes ni qualifiés PASSI ni certifiés CREST. Si un client ou un régulateur l’exige, nous vous le dirons avant de chiffrer.
Quand tester.
Avant un lancement
Surtout pour tout ce qui traite des paiements ou des données personnelles.
Un client vous l’a demandé
De plus en plus courant dans les ventes aux grands comptes. Vérifiez s’il exige un prestataire qualifié : nous ne le sommes pas.
Après un changement important
Nouveau parcours de paiement, nouvelle authentification, refonte majeure.
Ce n’est pas pour vous si… vous avez déjà une liste de failles non corrigées
Corrigez-les d’abord. Un test ne ferait que les retrouver. Et si une qualification PASSI est obligatoire dans votre cas, adressez-vous à un prestataire qualifié.
Comment nous travaillons.
Nous fixons le périmètre par écrit
Ce qui est inclus, ce qui ne l’est pas, et quand. Tester sans autorisation écrite, nous ne le faisons pas.
Nous cartographions l’application
Chaque point d’entrée, chaque rôle, chaque endroit où circulent les données.
Nous testons à la main
Les scanners tournent en arrière-plan. Les constats qui comptent viennent d’une personne qui essaie.
Nous vérifions tout
Chaque constat reproduit et confirmé. Personne ne devrait passer une semaine sur un faux positif.
Nous classons par risque réel
Ce qu’un attaquant pourrait réellement faire chez vous, pas un score générique. Trois urgences valent mieux que cinquante lignes.
Nous testons de nouveau après vos corrections
Confirmer la correction fait partie du travail, pas d’une vente additionnelle.
Tests d’intrusion
6 questions, avec leurs réponses. Vous en avez une autre ? Écrivez-nous.
Un scanner recherche des motifs connus et produit une longue liste pleine de faux positifs. Un test d’intrusion, c’est surtout une personne qui essaie de casser votre application précise — c’est ainsi qu’on trouve les failles de logique métier, en général les plus graves. Si un devis paraît bon marché et rapide, vous achetez probablement un scan avec une couverture de rapport.
Sept catégories. Quarante-cinq services.
Décrivez-nous votre projet. Franchement.
Ce que vous voulez construire, ce qui vous bloque, et le budget si vous l’avez. Nous répondons sous un jour ouvré, et nous vous dirons honnêtement si nous ne sommes pas les bonnes personnes.