Services
Audit Sécurité & Pentest
Vous n'avez pas besoin d'un simple scan automatique. Vous avez besoin d'une lecture claire de votre exposition réelle, de vos points de fragilité et des scénarios d'attaque les plus crédibles dans votre contexte. La majorité des incidents sérieux ne commencent pas par une attaque spectaculaire — ils commencent par une erreur de configuration, un accès trop large, une permission oubliée. J'évalue vos systèmes selon trois axes : analyse d'exposition externe, tests d'intrusion (infra interne, applicatif web/API/mobile, OWASP) et audit cloud (AWS, Azure, GCP). Chaque mission est cadrée selon votre organisation, votre maturité sécurité et vos priorités métier.
Quand c'est pertinent
Audit avant lancement d'une application exposée ou manipulant des données sensibles (santé, finance, RH)
Discuter de ce besoinRésultats attendus
Une lecture claire de votre exposition réelle : failles exploitables, leur gravité et leur portée opérationnelle — pas une liste brute de scanners.
Des preuves d'exploitation compréhensibles par la direction pour décider vite, et actionnables par vos équipes techniques pour corriger efficacement.
Un plan de remédiation priorisé par ordre d'impact métier, avec des recommandations concrètes et structurées.
Un rapport de retest pour confirmer que les failles corrigées ne sont plus exploitables et réduire le risque résiduel.
Périmètre d'intervention
Exposition externe : services, interfaces et configurations visibles depuis Internet — scan des IPs/domaines, cartographie des services, exploitation manuelle des cibles sensibles.
Systèmes internes : simulation d'un attaquant ayant accès réseau (VPN compromis, Wi-Fi, accès physique) — cartographie Active Directory, élévation de privilèges, accès aux données sensibles.
Applications web, APIs REST/GraphQL et mobiles (Android/iOS) : parcours d'authentification, flux à fort impact (facturation, administration, export) et logique métier selon l'OWASP.
Environnements cloud (AWS/Azure/GCP) : configurations IAM, buckets exposés, règles de firewall permissives, secrets dans les variables d'environnement — conformes aux benchmarks CIS.
Ce que vous obtenez (Livrables)
- Synthèse exécutive lisible par la direction : niveau de risque global, priorités et actions recommandées
- Rapport technique détaillé avec constats, preuves d'exploitation et niveau de criticité
- Plan de remédiation priorisé par impact métier avec recommandations concrètes et actionnables
- Atelier de restitution technique avec vos développeurs, équipes IT ou prestataires
- Rapport de retest après correction des failles prioritaires
Cas d'usage typiques
- Audit avant lancement d'une application exposée ou manipulant des données sensibles (santé, finance, RH)
- Validation du niveau de sécurité avant un déploiement client, un audit externe ou une certification
- Test d'intrusion interne pour évaluer les risques liés aux accès réseau (employés, VPN, Wi-Fi, accès physique)
- Audit de configuration cloud (AWS/Azure/GCP) pour détecter les surfaces d'attaque et les permissions excessives
FAQ
Quelle est la différence entre boîte noire, grise et blanche ?
En boîte noire, l'audit se fait sans information préalable — conditions d'un piratage réel. En boîte grise, quelques accès ou informations sont fournis, idéal pour tester les portails authentifiés. En boîte blanche, le périmètre et certains éléments internes sont partagés pour une analyse plus approfondie. Je recommande la boîte grise pour la majorité des missions.
Le rapport est-il compréhensible par la direction ?
Oui. La synthèse exécutive est conçue pour un lecteur non technique : niveau de risque global, priorités et actions recommandées. Le rapport technique détaillé avec les preuves d'exploitation est à destination de vos développeurs et équipes IT.
Faites-vous aussi des audits cloud ?
Oui, j'audite les environnements AWS, Azure et GCP : configurations IAM, services exposés, buckets S3 ouverts, règles de firewall permissives, secrets dans les variables d'environnement. Le rapport inclut des recommandations conformes aux benchmarks CIS.
Peut-on faire un retest après correction ?
Oui, et c'est fortement recommandé. Le retest vérifie que les failles corrigées ne sont plus exploitables et réduit le risque résiduel. Il peut être planifié à la livraison du rapport ou déclenché après vos correctifs.
On clarifie votre besoin avant de vendre une solution.
Décrivez le contexte, les contraintes et ce qui bloque aujourd'hui. Je vous réponds avec une lecture technique concrète.
Discuter de ce besoin