Nous cherchons les faiblesses de votre application avant que quelqu'un de moins bien intentionné ne s'en charge. Le cadre est simple et non négociable : nous intervenons à la demande du propriétaire du système, avec une autorisation écrite, un périmètre nommé adresse par adresse et une fenêtre d'intervention fixée dans le contrat. Aucun test destructeur. C'est un exercice contractuel, pas une attaque, et il vous laisse un document utile pour votre analyse de risque, pour préparer un audit ISO 27001 ou pour répondre au client qui réclame des garanties avant de signer.
Nous concentrons l'effort sur ce qui est réellement attaqué : authentification, contrôle d'accès, traitement des données entrantes et composants venus de l'extérieur. Méthode OWASP, guides WSTG et ASVS.
Contournement de la page de connexion, politique de mots de passe, procédure de réinitialisation, durée de vie et invalidation des sessions, configuration de l'authentification multifacteur, solidité de la fédération d'identité quand vous en utilisez une.
Un transporteur ouvre un espace client à cent donneurs d'ordre : peut-on afficher la lettre de voiture d'un autre client en modifiant un identifiant dans l'adresse ? Un utilisateur standard atteint-il l'écran d'administration en le demandant directement ? C'est le défaut le plus courant des portails B2B, et le plus discret.
Injection SQL, exécution de script dans le navigateur, dépôt de fichier piégé, modification d'un prix ou d'une quantité dans la requête envoyée au serveur, manipulation des identifiants de session.
Les points d'entrée utilisés par une application mobile sont souvent moins gardés que le site : autorisation vérifiée côté serveur ou seulement dans l'écran, limitation du débit, secrets et jetons stockés en clair sur le téléphone.
Bibliothèques portant des vulnérabilités publiées, mode de débogage resté actif, en-têtes de sécurité absents, sauvegardes et fichiers de configuration accessibles, interface d'administration ouverte sur Internet.
Chaque constat avec un score CVSS, la marche à suivre pour le reproduire et une recommandation de correction, plus une synthèse de deux pages compréhensible par une direction non technique. Les bulletins du CERT-FR pertinents sont cités quand ils existent.
La durée dépend de la taille de l'application et du périmètre retenu ; la date de remise du rapport figure au contrat. Nous intervenons depuis des adresses IP connues à l'avance, que vous pouvez placer en liste d'autorisation et suivre dans votre supervision.
Autorisation écrite signée par le propriétaire du système, liste précise des adresses et des fonctions concernées, fenêtre d'intervention, contacts d'urgence des deux côtés. Si l'application est hébergée chez un tiers, nous obtenons également son accord avant de commencer.
Cartographie de la surface exposée : points d'entrée, technologies, sous-domaines oubliés, API publiques, environnements de recette restés accessibles.
Travail manuel appuyé sur des outils comme Burp Suite, en mode prudent, sans action susceptible d'interrompre le service ou d'altérer vos données.
Constats hiérarchisés, restitution en visioconférence avec vos développeurs, puis vérification des points traités une fois vos correctifs en ligne.
Un rapport de test d'intrusion ne se diffuse pas en pièce jointe à toute l'entreprise. Il décrit pas à pas comment exploiter chaque faiblesse : tant que les correctifs ne sont pas déployés, il est plus dangereux que les failles elles-mêmes. Nous le transmettons par un canal chiffré à une liste nominative de destinataires, et nous vous conseillons de le traiter comme un document confidentiel jusqu'au contre-test.
Oui, parce qu'il s'agit d'un travail sur commande. Nous intervenons uniquement à la demande du propriétaire du système, avec une autorisation écrite et un contrat qui nomme le périmètre et la fenêtre. Nous ne testons jamais le système d'un tiers, même si l'on nous assure en avoir le droit, tant que le document n'est pas signé par le propriétaire réel. Faire relire cette autorisation par votre conseil juridique est une bonne habitude.
Nous travaillons avec précaution et sans test destructeur, mais le risque zéro n'existe pas. C'est pourquoi nous préférons une copie de l'environnement. Si le périmètre doit inclure la production, nous exigeons une fenêtre convenue, une sauvegarde fraîche et vérifiée, et un contact joignable pendant toute l'intervention.
Un scanner compare votre système à une base de signatures connues et repère très bien les composants périmés. Il ne verra pas les défauts de logique : accès aux documents d'un autre client, cumul de remises interdit, étape de validation que l'on peut sauter. Ces découvertes demandent un humain. Un test sérieux combine les deux approches.
Non, et nous ne le promettons pas. Vous recevez un rapport qui indique le périmètre, la méthode, les dates et les constats, puis une attestation de contre-test après correction. C'est ce document que vous présentez à un auditeur, à un client exigeant ou dans le cadre de votre analyse de risque.
Au moins une fois par an, et après chaque changement important : nouveau module de paiement, ouverture d'une API à des partenaires, changement d'hébergeur, refonte de l'authentification. Pour les organisations concernées par NIS2, ce rythme s'inscrit naturellement dans la gestion des risques attendue par l'ANSSI.
Décrivez l'application et indiquez si un environnement de recette existe. Nous fixons le périmètre et la fenêtre, l'autorisation est écrite dans le contrat.
Votre demande nous est parvenue
Vous recevrez une réponse sous un jour ouvré. Si vous signalez une panne qui immobilise vos équipes, elle passe en priorité.
Cette ville ne figure pas dans la liste. Vérifiez l'orthographe ou choisissez la grande ville la plus proche : nous travaillons à distance, cela ne change rien au périmètre de nos prestations.
