Test d’intrusion à Paris et en petite couronne : devis gratuit en 2 minutes

Un test d’intrusion, ou pentest, est une mission ponctuelle au cours de laquelle un auditeur tente d’exploiter les failles d’un périmètre défini, dans un cadre écrit et autorisé. Il ne se contente pas de lister les faiblesses supposées : il vérifie à la main lesquelles sont réellement exploitables, et jusqu’où elles permettraient d’aller en les combinant. Le résultat intéresse la direction autant que l’équipe technique, car il transforme une liste de risques théoriques en constats prouvés.

Test externe, test interne, test applicatif

Le test externe part d’internet et s’intéresse aux services exposés publiquement : accès distants, sites, messagerie, pare-feu. Le test interne se place dans le réseau, comme le ferait un attaquant qui a déjà franchi le périmètre ou pris la main sur un poste. Il examine l’annuaire, les droits accordés et les passages possibles d’un serveur à l’autre. Le test applicatif porte sur un site, un extranet ou un logiciel métier : authentification, gestion des sessions, droits selon le profil, contrôle des champs de saisie.

Boîte noire, boîte grise ou boîte blanche

Le niveau d’information transmis à l’auditeur change la nature du test. En boîte noire, il ne dispose que de ce qu’un inconnu verrait. En boîte grise, il reçoit des comptes de test ou une description partielle du système, ce qui permet d’aller plus loin dans le même temps. En boîte blanche, il accède à la documentation et aux configurations, ce qui sert surtout à vérifier une application ou une architecture en profondeur. Le bon choix dépend de la question à laquelle l’entreprise veut répondre.

Ce qui le distingue d’un scan

Un scan de vulnérabilités est un contrôle automatisé, répétable, qui relève la liste des failles connues. Le test d’intrusion est manuel et limité dans le temps. Les deux se complètent : le scan assure une surveillance régulière, le test vérifie ce qui compte réellement en enchaînant les failles. La gestion continue des vulnérabilités, qui corrige et contrôle au fil de l’eau, ne se confond donc pas avec cette mission ponctuelle.

Le besoin naît rarement d’une alerte. Il surgit le plus souvent à l’occasion d’un événement précis :

• Un client qui réclame un rapport : un donneur d’ordre demande la preuve qu’un test a été conduit avant de signer ou de renouveler un contrat.
• Une application ouverte sur internet jamais testée : un portail ou un site a été mis en ligne, parfois par étapes, sans contrôle de sécurité avant sa publication.
• Un extranet client sans regard extérieur : des utilisateurs externes accèdent à des informations, et personne n’a vérifié que les droits suivent bien chaque profil.
• Des résultats de scan impossibles à hiérarchiser : la liste des failles dépasse ce que l’équipe peut traiter, et personne ne sait lesquelles comptent vraiment.
• Une refonte du réseau ou de l’annuaire : la nouvelle architecture est en place, mais rien ne prouve qu’elle résiste à une tentative réelle.
• Un ancien rapport resté sans suite : les failles relevées ont été repoussées, et le document ne reflète plus l’état du système.
• Un assureur ou un auditeur qui pose la question : un questionnaire de cyber-assurance ou un audit demande des éléments sur les tests de sécurité réalisés.
• Une opération de rachat ou une levée de fonds : l’acquéreur ou l’investisseur demande un état des lieux technique, et la sécurité entre dans les vérifications préalables.

Dans chacun de ces cas, la mission sert à vérifier avant qu’un incident ne le fasse.

Une mission bien menée se prépare autant qu’elle s’exécute. Les trois temps ci-dessous suivent cet ordre.

Avant le test

Tout commence par la définition du périmètre : adresses concernées, applications, comptes, sites, exclusions, plages horaires acceptables et interlocuteurs à prévenir. Vient ensuite la convention signée par le responsable des systèmes, qui autorise le test, en fixe les limites et prévoit l’accord des hébergeurs ou des fournisseurs cloud lorsque certains systèmes leur appartiennent. Sans ce document, aucune tentative ne doit démarrer.

Pendant le test

L’auditeur explore d’abord la surface visible, puis tente d’exploiter les failles retenues, en veillant à ne pas perturber la production. Un interlocuteur joignable pendant toute la mission permet de traiter immédiatement un incident. Les essais susceptibles de gêner l’activité sont écartés ou reportés à une fenêtre convenue. Il est utile de prévenir l’infogérant ou l’équipe de supervision, afin qu’une alerte produite par le test ne soit pas prise pour une attaque réelle.

Après le test

Le rapport distingue deux documents : une synthèse pour la direction, qui résume le niveau de risque et les décisions à prendre, et un détail technique pour les équipes, qui décrit chaque faille, sa preuve d’exploitation, sa gravité et la correction recommandée. Une fois les corrections appliquées, un contre-test vérifie qu’elles tiennent. C’est cette étape qui donne au rapport sa valeur : un document sans correction ne protège personne.

Les offres emploient souvent le même vocabulaire et se distinguent surtout par ce qu’elles précisent. Quatre points méritent une attention particulière.

La clarté du périmètre écrit. Une offre qui décrit ce qui sera testé, ce qui ne le sera pas et les techniques exclues montre que le cadre a été réfléchi. Une offre vague sur les adresses ou les applications laisse le rapport incomplet, sans que personne ne le remarque.

La méthode annoncée. Une démarche sérieuse distingue le test externe, interne et applicatif, explique le niveau d’information fourni à l’auditeur et précise comment les failles sont classées et prouvées. Un rapport qui ne montre aucune preuve d’exploitation est difficile à faire corriger.

Les livrables et le suivi. L’entreprise doit pouvoir comparer avant de choisir : synthèse de direction, détail technique, restitution orale, éventuel contre-test. Un prestataire qui ne sait pas expliquer précisément ce qu’il remettra laisse l’entreprise découvrir le contenu du rapport après paiement.

La qualification de l’auditeur. Lorsque le contexte l’exige, la qualification PASSI délivrée par l’ANSSI constitue un repère. Il est utile de vérifier si l’auditeur la détient, sur la liste publiée par l’ANSSI, sans en faire une condition dans tous les cas.

Tester sans autorisation écrite. Un accord verbal ne protège ni l’auditeur ni l’entreprise, car une tentative mal cadrée peut toucher un système qui n’était pas prévu. Parade : une convention signée, avec périmètre, dates et contacts.

Un périmètre trop étroit. Un test limité à quelques adresses produit un rapport rassurant mais trompeur, puisqu’un attaquant choisit la porte la plus simple. Parade : inventorier avant de cadrer, et écrire les exclusions noir sur blanc.

Oublier les services hébergés chez un tiers. L’hébergeur ou le fournisseur cloud a ses propres règles, qui s’appliquent aux activités d’audit. Parade : vérifier ces règles avant de fixer le calendrier.

Un rapport sans suite. Le document est classé, les failles restent ouvertes, et le test ne sert qu’à rassurer sur le papier. Parade : planifier les corrections avec des responsables désignés, puis un contre-test.

Une alerte prise pour une attaque réelle. Les équipes qui surveillent le réseau, non prévenues, déclenchent une réponse à incident inutile et coûteuse en temps. Parade : prévenir l’infogérant avant le démarrage.

Quelques questions permettent de comparer les propositions sans être spécialiste.

• Le périmètre et l’autorisation écrite sont-ils formalisés avant le moindre essai ? Il faut savoir qui signe côté entreprise, et quels systèmes sont exclus.
• Quelle qualification de l’auditeur l’entreprise peut-elle vérifier, et comment ? La réponse doit pouvoir être contrôlée sur une source publique.
• Le rapport distingue-t-il la synthèse de direction du détail technique ? Chaque faille doit être accompagnée de sa preuve, de sa gravité et de sa correction recommandée.
• Un contre-test est-il inclus, ou prévu après les corrections ? Son périmètre doit être écrit, car il conditionne la valeur réelle de la mission.