Test d'intrusion applicatif : le guide pour les startups tech

La plupart des startups font leur premier test d'intrusion pour une mauvaise raison : un client grand compte l'exige dans sa security review, la deadline approche, et il faut cocher la case. Le pentest devient une formalité commerciale, on prend le premier prestataire disponible, on reçoit un PDF que personne ne lit vraiment, et on repart.

C'est dommage, parce qu'un test d'intrusion bien mené est l'un des investissements les plus rentables pour une startup qui vend à des clients exigeants. Il vous dit, preuves à l'appui, ce qu'un attaquant réaliste ferait de votre produit aujourd'hui, et il vous donne un document solide à poser sur la table face à un client ou un investisseur. Encore faut-il savoir ce qu'on achète.

Voici ce qu'il faut comprendre avant de lancer le vôtre.

Un scan de vulnérabilités n'est pas un test d'intrusion

C'est la confusion la plus fréquente, et elle coûte cher.

Un scanner (Nessus, Burp en mode automatique, un scanner de dépendances) passe votre application au crible d'une base de signatures connues. C'est rapide, peu coûteux, et ça doit tourner en continu dans votre CI. Mais un scanner ne comprend pas votre logique métier. Il ne sait pas qu'un utilisateur du plan gratuit ne devrait jamais pouvoir accéder à la facturation d'un autre compte, ni qu'un identifiant de commande incrémental permet d'énumérer les commandes des autres clients.

Un test d'intrusion, c'est un humain qui pense comme un attaquant. Il enchaîne des failles anodines prises isolément pour en faire une compromission réelle. Les vulnérabilités qui font mal (les broken access control, les élévations de privilèges, les failles de logique métier) sont précisément celles qu'aucun scanner ne détecte, parce qu'elles dépendent de ce que votre application est censée faire.

Les deux sont complémentaires : le scanner couvre la surface en largeur et en continu, le pentest va en profondeur ponctuellement. Si un prestataire vous vend un « pentest » livré en 48 heures sans échange sur votre périmètre, vous achetez un scan déguisé.

Quand faire un test d'intrusion

Les bons déclencheurs, dans l'ordre où on les voit le plus souvent :

• Un client l'exige. Le cas classique. Un acheteur B2B conditionne la signature ou le renouvellement à un rapport de test récent. C'est légitime : il évalue le risque que vous représentez pour lui.
• Une exigence de conformité. ISO 27001 attend une preuve concrète de gestion des vulnérabilités techniques, et un pentest est le moyen le plus direct de la produire. Pour DORA, les tests de résilience réguliers, dont les tests d'intrusion, font partie du dispositif attendu.
• Avant une mise en production majeure. Nouvelle application, refonte d'authentification, ouverture d'une API publique : les moments où la surface d'attaque change en profondeur sont les bons moments pour tester.
• Après une levée de fonds ou en due diligence. Un investisseur ou un acquéreur veut savoir sur quoi il met son argent. Arriver avec un rapport de test et un plan de remédiation change la conversation.
• Après un incident. Pour comprendre l'étendue réelle du problème et vérifier qu'il ne s'agit pas de la partie émergée d'un défaut plus large.

Si aucun de ces cas ne vous concerne encore mais que vous manipulez des données sensibles, tester une fois par an reste un réflexe sain.

Comment se déroule un test d'intrusion applicatif

Chez Radome, nous réalisons ces tests en interne, sans les sous-traiter. Le déroulé tient en cinq temps. Vous n'avez pas besoin d'en maîtriser chaque détail technique : en connaître les grandes lignes suffit pour juger un prestataire et savoir ce que vous payez.

1. Le cadrage

Tout commence par la définition du périmètre, et c'est l'étape qui détermine la valeur du test. Une cible correspond à un périmètre cohérent : une application web, une API, ou une application mobile. Si votre produit combine une app web et une API, cela peut compter comme une ou deux cibles selon leur couplage.

On décide aussi du niveau d'information fourni au testeur :

• Boîte noire : le testeur part de zéro, comme un attaquant externe. Réaliste, mais une partie du temps sert à cartographier ce que vous connaissez déjà.
• Boîte grise : le testeur dispose de comptes applicatifs et d'une compréhension des rôles. C'est le meilleur rapport valeur/temps pour la plupart des applications SaaS, parce qu'il concentre l'effort sur l'exploitation plutôt que sur la reconnaissance.
• Boîte blanche : accès au code source en plus. Pertinent pour les composants les plus sensibles.

Pour un premier test sur une application métier, la boîte grise est presque toujours le bon choix.

2. L'exécution

Le testeur travaille votre application méthodiquement, en s'appuyant sur des standards reconnus comme l'OWASP (le Top 10 et, plus complet, l'OWASP Testing Guide). Concrètement : authentification et gestion de session, contrôles d'accès entre comptes et entre rôles, injections, exposition de données, configuration, logique métier propre à votre produit.

Et si votre produit embarque des fonctionnalités IA (un assistant conversationnel, une recherche augmentée, un agent), elles font partie de la surface à tester : un modèle mal cadré peut divulguer des données ou déclencher des actions non prévues. C'est un sujet assez vaste pour mériter son propre traitement, mais il obéit à la même logique que le reste.

L'objectif n'est pas d'accumuler des alertes, mais de démontrer un impact : qu'est-ce qu'un attaquant peut réellement obtenir, et par quel chemin.

3. Le rapport

C'est le livrable, et c'est là que se joue la différence entre un bon et un mauvais test. Un rapport exploitable comporte deux niveaux :

• Un rapport exécutif, lisible par un dirigeant : le niveau de risque global, les constats majeurs, ce qu'il faut décider.
• Une annexe technique détaillée : pour chaque vulnérabilité, la criticité (scorée en CVSS), les étapes de reproduction pas à pas, et une recommandation de correction actionnable, pas un lien générique vers une page OWASP.

4. La restitution

Un rapport qui atterrit dans une boîte mail sans explication finit rarement corrigé. Une session de restitution avec vos équipes technique et produit permet de prioriser ensemble, de lever les ambiguïtés et de transformer le document en plan d'action.

5. Le retest

Après vos corrections, un contre-test vérifie que les failles sont effectivement fermées, et qu'aucune correction n'en a introduit de nouvelle. Sans retest, vous ne savez pas si votre remédiation a fonctionné : vous l'espérez. Chez nous, il est inclus.

Ce que vous devez exiger

Quel que soit votre prestataire, tenez à trois choses :

1. Un vrai périmètre discuté, pas un tarif au forfait sorti sans échange. Le cadrage conditionne tout.
2. Des étapes de reproduction pour chaque vulnérabilité. Une faille que vos développeurs ne peuvent pas rejouer ne sera pas corrigée.
3. Un retest inclus. C'est le signe qu'on vous vend un résultat, pas un document.

Un rapport qui se contente de recracher la sortie brute d'un scanner, sans reproduction ni priorisation, ne vaut pas ce que vous l'avez payé, même s'il est épais.

Pentest et conformité : le même effort qui sert deux fois

Pour une startup qui vise une certification, le test d'intrusion n'est pas une dépense isolée. Il alimente directement la démarche de conformité.

• Pour ISO 27001, il fournit la preuve technique de gestion des vulnérabilités que les auditeurs attendent.
• Pour DORA, il s'inscrit dans le programme de tests de résilience opérationnelle exigé du secteur financier et de ses prestataires.
• Pour SOC 2, il renforce les contrôles liés à la gestion des vulnérabilités.

C'est aussi pour cela que nous réalisons les pentests en interne plutôt que de les sous-traiter : quand le test et l'accompagnement à la conformité sont portés par la même équipe, les constats du pentest nourrissent directement l'analyse de risques, et vous n'empilez pas les prestataires.

Combien de temps, quel budget

Un test d'intrusion applicatif se prépare et se livre en général sous 2 à 4 semaines, selon la disponibilité des accès et le nombre de cibles. Côté budget, nos tests démarrent à partir de 6 000 €, le tarif dépendant du nombre et de la complexité des cibles. Le détail est sur notre page tarifs.

Ce sont des ordres de grandeur : un périmètre restreint et bien préparé coûte moins cher et va plus vite qu'une application tentaculaire sans documentation.

Questions fréquentes

N'y a-t-il pas un conflit d'intérêt à vous confier le conseil et le test d'intrusion ?

C'est une question légitime, et la réponse tient en trois points. D'abord, un test d'intrusion n'est pas un audit de certification : nous ne délivrons aucun certificat, ce sont des organismes accrédités indépendants qui le font. Une faille reste une faille, que l'on vous accompagne par ailleurs ou non. Ensuite, le résultat d'un pentest est factuel et reproductible : chaque vulnérabilité est documentée avec ses étapes de reproduction, vous ou un tiers pouvez la rejouer et la vérifier. Enfin, réunir le test et l'accompagnement dans une même équipe technique joue surtout en votre faveur : les constats du pentest nourrissent directement votre analyse de risques et votre remédiation, sans handoff ni renvoi de responsabilité d'un prestataire à l'autre.

Aidez-vous les équipes à corriger les vulnérabilités ?

Oui. Ce qui fait la différence, ce n'est pas seulement de trouver des failles : c'est de comprendre en profondeur votre stack et la manière dont on construit un produit dans une startup ou une scale-up tech, avec ses contraintes de roadmap et ses arbitrages. La remédiation fait donc partie intégrante du travail. Au-delà du rapport, nous échangeons directement avec vos développeurs : comprendre la faille, choisir la bonne correction, éviter d'en réintroduire une autre au passage. L'objectif n'est pas de vous laisser avec une liste de problèmes, mais de vous aider à les refermer, puis de le confirmer au retest.

Le pentest, souvent une première étape

Beaucoup de nos accompagnements à la conformité commencent par un test d'intrusion. La demande vient rarement de nulle part : le plus souvent, une partie prenante (un client grand compte, un investisseur, un partenaire) attend un engagement concret sur la sécurité de l'information. Le pentest est la première réponse tangible que vous pouvez lui apporter : un livrable rapide, une valeur immédiate, une image nette de votre posture réelle. À partir de là, la question d'une démarche plus structurée, jusqu'à la certification, se pose souvent d'elle-même.

Mais un pentest n'engage à rien de plus qu'un pentest. Si vous avez juste besoin de répondre à un client, on fait le test, on vous livre un rapport exploitable, et vous décidez de la suite. Si vous voulez aller plus loin, on en parle.