Mettre en production une version
Tester les parcours sensibles avant d’accueillir vos utilisateurs. Les scénarios peuvent inclure l’accès aux dossiers, les invitations et la séparation entre espaces clients.
Cybersécurité · 5 à 10 jours ouvrés selon périmètre
Pentest web & API, sur votre application.
Avant une mise en production ou après une évolution sensible, vérifiez ce qu’un attaquant pourrait exploiter. Je teste les rôles, les accès aux données et les parcours métier, puis votre équipe reçoit les preuves et les corrections à prioriser.
Boris · PNPT · HTB CWES · Restitution des résultats
Re-test des points convenus dans les 60 jours, selon la proposition.
TEST / 02Lecture technique
Session authentifiéeCompte commercial
GETRequête vers l’API
/api/documents/:idFichier de paie
Réservé aux RH
Réservé aux RH
Accès hors périmètre403 / refus attendu
Un accès se vérifie côté serveur, au-delà de ce que montre l’interface.
Démonstration fictiveConcrètement
Les questions auxquelles répondre.
Faire évoluer des rôles ou une API
Contrôler les nouvelles autorisations et les actions exposées. Le fait qu’un écran masque une fonction ne suffit pas à vérifier les accès côté serveur.
Répondre à une demande client
Un client ou partenaire attend une évaluation de sécurité. Définir avec lui les attentes, les tests utiles et les éléments du rapport partageables dans le cadre de confidentialité prévu.
Ce que vous recevez
Des constats exploitables.
Le périmètre et les livrables sont validés ensemble avant le démarrage.
Des risques confirmés
Les constats sont étayés par des vérifications et des preuves. Les résultats d’outils ne sont pas remis tels quels comme une liste de failles avérées.
Un rapport pour corriger
L’équipe technique retrouve les conditions du problème, les étapes de reproduction convenues et les recommandations. La direction dispose d’une lecture des priorités.
Une correction que l’on vérifie
Le re-test examine les points corrigés du périmètre convenu et consigne leur statut. Il ne vaut pas nouveau test complet de toute l’application.
Synthèse des risques pour la direction
Constats détaillés avec preuves reproductibles et limites
Recommandations et priorités de correction
Restitution avec vos interlocuteurs techniques
Re-test des failles corrigées dans les 60 jours, selon les conditions convenues
Déroulement
Un cadre de travail explicite.
Vous échangez directement avec Boris, qui cadre les tests, les réalise et restitue les constats à votre équipe.
Voir mon approche et mes certifications ↗Le cadrage précise les applications, API, rôles, données de test, exclusions et contacts de coordination. Je m’appuie sur OWASP WSTG et sur vos parcours réels : connexion, partage, export, administration ou changement de rôle. Les constats sont confirmés manuellement et, lorsque c’est autorisé, par des exploitations contrôlées. Le rapport fournit preuves, impact, recommandations et limites. Après correction, le re-test porte sur les points convenus.
Autorisation écrite, périmètre et règles d’engagement sont établis avant les tests. Un accord de confidentialité encadre la mission ; les modalités de restitution et de conservation des éléments sont fixées au cadrage.
Investissement : sur devis. Applications et API, rôles à tester, parcours métier, profondeur des vérifications et environnement déterminent la charge. Le premier échange précise ces éléments pour une proposition chiffrée.
Voir un exemple de rapport ↗Questions fréquentes
Le périmètre, au clair.
Questions / Réponses
07 points à éclaircir
Question 01 sur 07
Qu’apporte un pentest manuel par rapport à un scanner ?
Un scanner aide à repérer certains signaux. Le travail manuel vérifie les résultats et teste les relations entre rôles, données et parcours métier. Un changement d’utilisateur ou une règle de partage peut modifier l’impact d’un problème sans être correctement interprété par un outil seul.
Quels accès faut-il préparer pour tester une application ou son API ?
Selon la mission : comptes de test correspondant aux rôles, espaces clients séparés, documentation des API et données non sensibles. Le cadrage précise les éléments nécessaires, les autorisations écrites et les systèmes exclus. Les tests ne commencent pas sur un périmètre supposé autorisé.
Peut-on tester une application en production ?
Cela se décide au cadrage selon les risques et les contraintes de l’application. Nous convenons des horaires, limites, actions interdites et contacts à prévenir. Certaines vérifications peuvent être exclues ou déplacées vers une préproduction représentative. Une absence totale de perturbation ne peut pas être garantie.
Comment fonctionne le re-test dans les 60 jours ?
Vous indiquez les points corrigés, puis je vérifie ceux prévus au périmètre de re-test. Leur statut et les limites sont consignés. La fenêtre de 60 jours et les conditions exactes figurent dans la proposition ; les nouvelles fonctions peuvent nécessiter un autre périmètre.
Combien coûte un pentest web ou API ?
Le devis dépend des applications et API concernées, du nombre de rôles, des parcours métier et de la profondeur des tests. Les accès et l’environnement disponibles influencent aussi la charge. Le premier échange précise ces éléments avant une proposition chiffrée.
Que contient le rapport de pentest ?
Une synthèse des risques, les vulnérabilités confirmées avec leurs preuves, leur impact et les recommandations prioritaires. Le rapport précise le périmètre et les limites des tests. La restitution permet d’échanger sur les constats ; le re-test documente ensuite le statut des corrections convenues. Un exemple pédagogique est accessible sur le site.
Un pentest garantit-il que l’application est sécurisée ?
Non. Il décrit des vérifications sur un périmètre et à un moment donnés. Il aide à identifier des risques et à prioriser les corrections, sans garantir l’absence de toute faille. Une nouvelle fonctionnalité ou un changement d’accès peut nécessiter de nouveaux tests.
La prochaine étape
Parlons de votre application.
Précisons les accès à vérifier, les parcours sensibles et les résultats dont votre équipe a besoin.