Lu par une personne, pas par un scanner.
L’analyse statique trouve des motifs. Elle ne peut pas voir qu’un contrôle d’autorisation manque sur un point d’accès, parce qu’il n’y a rien à détecter.
Nous lisons votre code source spécifiquement à la recherche de failles de sécurité : contrôle d’accès, authentification, traitement des données, secrets. Chaque constat est accompagné de son emplacement exact et d’une correction proposée. Nous nous concentrons sur là où se trouve le risque plutôt que de tout survoler, et nous convenons de ce périmètre avec vous.
Mis à jour novembre 2026
Les failles les plus graves sont en général une absence.
L’analyse statique repère bien les motifs dangereux — une requête non sécurisée, un algorithme faible. Elle remarque mal qu’un point d’accès sur quarante ne vérifie jamais que l’utilisateur est propriétaire de l’enregistrement demandé, parce qu’il n’y a pas de mauvais code à signaler. Il n’y a simplement pas de code.
Une personne qui lit avec cette intention les trouve, et c’est régulièrement la catégorie la plus dommageable. Une autorisation manquante, c’est ainsi qu’un client finit par voir les données d’un autre.
Elle se combine bien avec le test d’intrusion sans le remplacer. Le test montre ce qui est atteignable de l’extérieur ; la revue de code montre ce qui ne va pas à l’intérieur, y compris des chemins qu’un testeur n’atteindrait pas.
Ce que nous cherchons.
Autorisations manquantes
Des points d’accès qui vérifient qui vous êtes, mais jamais si l’enregistrement est le vôtre. Le constat grave le plus courant.
Gestion de l’authentification
Sessions, jetons, réinitialisation du mot de passe, expiration. Là où se concentrent les erreurs dommageables.
Secrets dans le dépôt
Clés et identifiants commités, y compris dans l’historique, où l’on oublie de regarder.
Traitement des entrées
Chemins d’injection, désérialisation non sûre, gabarits rendus avec des données utilisateur.
Données sensibles dans les journaux
Numéros de carte, jetons et données personnelles écrits dans des journaux que beaucoup de gens peuvent lire — un vrai sujet au regard du RGPD.
Risque des dépendances
Vulnérabilités connues, et paquets que plus personne n’entretient.
Usage de la cryptographie
Pas les algorithmes, en général corrects — la façon dont on s’en sert, qui l’est souvent moins.
Une correction par constat
Fichier, ligne et modification proposée. Pour que cela devienne une pull request plutôt qu’une discussion.
Revue de code, ou test d’intrusion ?
Ils trouvent des choses différentes. La plupart des équipes devraient faire les deux, et la revue est en général la moins chère.
| Revue de code sécurité | Test d’intrusion | |
|---|---|---|
| Point de vue | De l’intérieur — en lisant le code | De l’extérieur — en attaquant l’application |
| Contrôles d’autorisation manquants | Oui — son meilleur argument | Seulement là où ils sont atteignables |
| Secrets écrits en dur | Oui | Rarement |
| Code dangereux mais inatteignable | Oui | Non — on ne peut pas l’atteindre |
| Failles de configuration et de déploiement | En partie | Oui |
| Prouve l’exploitabilité | Non — montre la faille | Oui — démontre l’attaque |
| Exige l’accès au code source | Oui | Non |
Notre façon de lire.
Une autorisation absente sur un point d’accès. Aucun scanner ne la trouve, parce qu’il n’y a rien à trouver.
Notre fondateur a dirigé la technique d’une fintech de paiement. Le code proche de l’argent est lu en conséquence.
Fichier, ligne et modification proposée. Cela doit devenir une pull request, pas une discussion.
Quand faire une revue.
Avant de traiter de l’argent ou des données personnelles
Moins cher à trouver maintenant qu’après une fuite à notifier.
Vous avez hérité d’un code
Une acquisition, ou une reprise après une agence. On ne peut pas se fier à ce qu’on n’a pas lu.
Un test a trouvé quelque chose d’inquiétant
Si un contrôle d’autorisation manquait, vérifiez que les autres sont bien là.
Ce n’est pas pour vous si… rien n’est testé automatiquement
Si aucun test ne vérifie votre code, commencer par là fera plus de bien qu’une revue de sécurité. Nous vous le dirons.
Comment nous travaillons.
Nous repérons où se trouve le risque
Authentification, paiements, données personnelles. Nous lisons ces parties à fond plutôt que tout en surface.
Nous lançons les outils en arrière-plan
Ils attrapent les motifs évidents et libèrent la lecture pour ce qu’ils ne voient pas.
Nous lisons avec intention
En suivant le trajet des données et les endroits où un contrôle devrait être et n’est pas.
Nous vérifions chaque constat
Dans le code, avec le chemin montré. Personne ne devrait courir après un problème théorique.
Nous classons par impact réel
Ce que la faille permet vraiment dans votre application, pas un score de gravité générique.
Nous donnons une correction, pas une leçon
Fichier, ligne, modification proposée — pour que votre équipe ouvre une pull request plutôt qu’un débat.
Revue de code sécurisée
6 questions, avec leurs réponses. Vous en avez une autre ? Écrivez-nous.
Le scan trouve des motifs dangereux présents dans le code. Il ne peut pas trouver ce qui est absent — et un contrôle d’autorisation manquant, c’est exactement cela. Il n’y a pas de mauvais code à signaler, juste un point d’accès qui ne vérifie jamais que l’enregistrement appartient à celui qui le demande. C’est régulièrement de là que viennent les constats les plus graves, et il faut une personne.
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.