Cybersécurité & pentest
Testez votre sécurité comme elle pourrait réellement être attaquée.
Un test d'intrusion ne produit pas une liste de vulnérabilités théoriques. Il vous dit ce qu'un attaquant obtiendrait sur votre périmètre, par quel chemin, et ce que cela coûterait à votre activité. Périmètre défini avec vous, autorisation écrite, rapport que vos équipes peuvent réellement utiliser.
Quand faire un test d'intrusion ?
Un pentest est utile quand il y a une décision à prendre, pas seulement une case à cocher.
Vous mettez en production une application exposée sur Internet et vous voulez savoir ce qu'elle laisse passer, avant vos utilisateurs.
Un client, un assureur ou un appel d'offres exige la preuve d'un test réalisé par un tiers.
Votre application a beaucoup évolué depuis sa conception et personne n'a revu la surface d'exposition depuis.
Vous avez ouvert une API à des partenaires et vous ne savez pas ce qu'elle expose au-delà de l'usage prévu.
Vous avez hérité d'une infrastructure, d'un code ou d'un prestataire précédent et vous manquez de visibilité.
Vous voulez savoir jusqu'où pourrait aller une personne déjà présente dans vos locaux ou connectée à votre réseau interne.
Ce que nous testons
Chaque type de test répond à une question différente. Le périmètre est défini avant la mission, pas découvert pendant.
Applications web
- Authentification, gestion de session, réinitialisation de mot de passe
- Contrôle d'accès : atteindre les données d'un autre compte, agir avec un rôle que l'on n'a pas
- Injections, traitement des entrées, désérialisation
- Logique métier : contournement de workflow, manipulation de montants ou de statuts
- Configuration exposée : en-têtes, cookies, CORS, messages d'erreur trop bavards
API et intégrations
- Jetons machine à machine : portée, durée de vie, révocation
- Autorisation par ressource et exposition d'objets non prévus
- Endpoints non documentés et anciennes versions laissées actives
- Limitation de débit, abus et énumération d'identifiants
- Échanges entre systèmes : webhooks, files de messages, connecteurs partenaires
Infrastructure externe
- Cartographie de la surface réellement exposée
- Services accessibles depuis Internet qui ne devraient pas l'être
- Configuration TLS, correctifs manquants, versions exposées
- Actifs oubliés : environnements de test, anciens serveurs, sauvegardes accessibles
Infrastructure interne
- Ce qu'obtient un poste simplement connecté au réseau interne
- Chemins de progression vers les comptes à privilèges élevés
- Segmentation réseau : ce qui est atteignable, depuis où
- Partages, comptes de service et secrets stockés en clair
Test sur site
- Segmentation depuis une prise réseau ou un poste invité
- Accès Wi-Fi et séparation effective des réseaux
- Ce qu'un intervenant externe présent dans vos locaux peut atteindre
- Scénarios convenus à l'avance, sans mise à l'épreuve de vos collaborateurs sans accord écrit
Mission Red Team
- Contrat distinct, scénario validé, objectif défini à l’avance
- Évalue votre détection et votre réaction, pas seulement vos vulnérabilités
- Suppose une maturité déjà en place : sans tests plus classiques au préalable, elle n'apporte rien
- Nous vous le disons franchement si ce n'est pas ce dont vous avez besoin aujourd'hui
Ce que vous achetez, selon le type de test
Les termes varient d'un prestataire à l'autre. Voici comment nous les employons, pour que vous sachiez ce qui est inclus avant de comparer deux devis.
| Type | Objectif | Profondeur | Intervention humaine | Scénario d'attaque | Livrable |
|---|---|---|---|---|---|
| Scan de vulnérabilités | Repérer les défauts connus | En surface, sans exploitation | Outil automatisé, relecture légère | Aucun | Une liste de constats à trier |
| Audit | Vérifier la conformité à un référentiel | Configuration, code, procédures | Revue documentaire et entretiens | Aucun | Les écarts par rapport au référentiel |
| Test d'intrusion | Savoir ce qu'un attaquant obtiendrait | Exploitation réelle, jusqu'à l'impact métier | Manuelle, guidée par votre métier | Chemins d'attaque sur un périmètre défini | Constats reproductibles et plan de correction |
| Mission Red Team | Évaluer la détection et la réaction | Objectif ciblé, discrétion recherchée | Manuelle, sur la durée | Scénario validé de bout en bout | Récit de l'intrusion et angles morts |
Ces définitions ne sont pas une norme : d'autres prestataires emploient les mêmes mots autrement. Comparez ce qui est réellement couvert, pas l'intitulé.
Comment se déroule une mission
Le cadre est posé avant la première requête. Aucun test n'est lancé sans autorisation explicite du propriétaire du système.
- 01
Cadrage
Ce qui doit être testé et pourquoi : environnements, applications, plages d'adresses, comptes de test, contraintes d'horaires et de charge.
- 02
Règles d'engagement
Périmètre, méthodes autorisées, fenêtres d'intervention, contacts d'urgence et conditions d'arrêt, écrits et signés. Ce document fait foi pendant toute la mission.
- 03
Autorisation
Le test démarre avec l'accord écrit du propriétaire du système. Si votre hébergeur ou votre infogérant doit être prévenu, nous le vérifions avant.
- 04
Reconnaissance
Cartographie de la surface réellement exposée. Cette étape révèle souvent des actifs que plus personne n'avait en tête.
- 05
Tests
Exploitation manuelle guidée par le contexte métier, outillée mais pas automatisée. Toute découverte critique vous est signalée immédiatement.
- 06
Rapport
Chaque constat avec son chemin de reproduction, son impact réel et la correction attendue. Priorisé par risque métier, pas par score brut.
- 07
Restitution et retest
Présentation aux équipes techniques et aux décideurs, puis vérification des corrections sur les points traités.
Nous ne testons jamais un système sans autorisation écrite de son propriétaire. Si le périmètre inclut des ressources hébergées chez un tiers, l'accord de ce tiers est vérifié avant le démarrage.
Ce que vous recevez
Un rapport n'a de valeur que s'il permet de corriger. Nous écrivons pour vos développeurs et vos administrateurs, pas pour justifier la mission.
- 01
Rapport technique
Chaque constat avec son chemin de reproduction, les preuves, la criticité et la correction attendue.
- 02
Synthèse pour décideurs
Ce qui est en jeu, en langage métier, utilisable en comité de direction ou face à un client.
- 03
Plan de correction priorisé
Ce qu'il faut traiter en premier, ce qui peut attendre, et ce qui relève d'un choix d'architecture plutôt que d'un correctif.
- 04
Restitution avec vos équipes
Un échange direct avec les développeurs et les administrateurs, pour que le rapport ne finisse pas classé sans suite.
- 05
Retest des correctifs
Vérification des points corrigés après votre passe de remédiation, avec mise à jour du statut de chaque constat.
- 06
Attestation de test
Le périmètre et la période du test, attestés — utile face à un client, un assureur ou un auditeur.
Les environnements que nous couvrons
La sécurité se teste là où le système vit, pas sur un schéma d'architecture.
Applications web et SaaS
Applications métier internes, portails clients, plateformes exposées sur Internet.
API et services
REST, GraphQL, services internes et intégrations avec vos partenaires.
Cloud et hébergement
Environnements cloud publics, hébergements dédiés et configurations hybrides.
Réseaux d'entreprise
Annuaires, postes de travail, serveurs internes, segmentation et accès distants.
Après le test
Un test d'intrusion ne vaut que par les corrections qui suivent. Nous pouvons nous arrêter au rapport, accompagner vos équipes, ou prendre la remédiation en charge.
Projet sur mesure
Nous prenons la responsabilité de l’ensemble : analyse, conception, développement, intégration, livraison et évolution.
En savoir plusConsultance & renfort d’expertise
Nos consultants rejoignent votre équipe pour apporter les compétences dont vous avez besoin : développement, analyse fonctionnelle, analyse technique, business analysis ou architecture.
En savoir plusPartenaire IT
Un interlocuteur durable pour maintenir, faire évoluer et connecter les logiciels et systèmes sur lesquels votre activité repose.
En savoir plus
Ce que la sécurité recoupe
Les sujets qui reviennent le plus souvent à côté ou à la suite d'un test.
Sécuriser applications et infrastructure
Vous devez démontrer un niveau de sécurité, ou vous avez un doute sur l’exposition réelle de vos applications.
Connecter des systèmes qui ne se parlent pas
Votre ERP, votre CRM et vos outils métier contiennent chacun une partie de la vérité, sans échange fiable entre eux.
Moderniser un logiciel métier
L’application fonctionne encore mais devient coûteuse à maintenir, difficile à faire évoluer et dépendante de quelques personnes.
Questions fréquentes
Un pentest peut-il casser la production ?
Le risque n'est jamais nul, c'est pour cela qu'il est traité dans les règles d'engagement : tests exclus, fenêtres d'intervention, conditions d'arrêt. Quand c'est possible, nous travaillons sur un environnement de pré-production représentatif. Quand le test doit avoir lieu en production, nous adaptons l'intensité et nous restons joignables pendant toute la mission.
Boîte noire, boîte grise ou boîte blanche ?
En boîte noire, nous partons sans information, comme un attaquant externe. En boîte grise, nous disposons de comptes utilisateurs : c'est ce qui permet de tester les contrôles d'accès et la logique métier, et c'est le mode le plus utile dans la majorité des cas. En boîte blanche, nous avons aussi le code et les schémas, ce qui donne la couverture la plus large à temps égal.
Combien de temps dure une mission ?
Cela dépend du périmètre, et le périmètre se définit avant de pouvoir annoncer une durée. Une application unique avec quelques rôles ne demande pas le même effort qu'un système d'information complet. Nous chiffrons après le cadrage, sur la base de ce qui doit réellement être couvert.
Un scan automatisé ne suffit-il pas ?
Un scan détecte les défauts connus : versions obsolètes, configurations par défaut, correctifs manquants. C'est utile et c'est souvent une première étape légitime. Mais un scanner ne comprend pas votre métier : il ne verra pas qu'un utilisateur peut consulter les commandes d'un autre client, contourner une étape de validation ou modifier un montant.
À quelle fréquence faut-il retester ?
Après chaque évolution significative de la surface exposée : nouvelle application, refonte, ouverture d'une API, changement d'hébergement. Beaucoup d'organisations retestent leur périmètre externe une fois par an, mais un rythme calendaire ne remplace pas un test déclenché par un changement réel.
Travaillez-vous avec nos équipes ou à leur place ?
Les deux sont possibles. Certains clients veulent uniquement le rapport et corrigent en interne. D'autres nous demandent d'accompagner leurs développeurs sur la remédiation, voire de la prendre en charge.
Parlons de votre périmètre
Un échange suffit à déterminer quel type de test correspond à votre situation — et à vous dire si c'est bien ce dont vous avez besoin maintenant.