PREUVE / Feuillet de consultation

Prix d’un pentest SaaS : comparer des devis de même périmètre

Mis à jour le 1er octobre 2026

Comparer une prestation définie

Le prix d’un pentest SaaS dépend du travail convenu, pas du seul nombre de pages de l’application. Deux devis peuvent porter le même intitulé et couvrir des prestations différentes. Une API authentifiée, plusieurs organisations clientes et des fonctions d’administration demandent un cadrage distinct d’une interface publique. Avant de chercher un montant, faites décrire les actifs, les rôles et les parcours que le cabinet devra examiner. Demandez un chiffrage sur cette même base à chaque candidat.

Une direction commerciale a souvent besoin d’un document transmissible au client ; le CTO attend des constats reproductibles pour corriger. Inscrivez ces deux livrables dans la consultation. Une restitution technique sans synthèse partageable peut déclencher du travail supplémentaire. À l’inverse, une simple lettre de réalisation ne permet pas toujours de comprendre les limites du test. La langue du rapport, la réunion de restitution et la vérification des corrections doivent apparaître comme des lignes identifiables.

Séparer charge du cabinet et charge interne

La préparation mobilise vos équipes : inventaire, création des comptes, données fictives, disponibilité d’un référent et stabilisation de l’environnement. Ces tâches ne deviennent pas gratuites parce qu’elles ne figurent pas sur le devis du cabinet. Distinguez la charge facturée de la capacité de vos développeurs. Le temps entre réception du rapport et correction dépend notamment de vos arbitrages produit. Il ne doit pas être absorbé dans une promesse commerciale de remise immédiate d’un rapport sans réserve.

Demandez si la facturation est forfaitaire ou liée à une charge estimée. En cas de forfait, faites préciser les hypothèses qui déclenchent une modification : application supplémentaire, nouveau rôle, indisponibilité des accès ou changement de version pendant l’audit. Pour une prestation à la charge, vérifiez la procédure d’accord avant dépassement. Le choix du modèle de facturation ne dispense pas d’une description des tests autorisés ni des livrables attendus.

Lire les options et exclusions

Le retest mérite une ligne séparée même lorsqu’il est inclus. Quels constats sont revérifiés ? Combien de passages sont prévus ? Jusqu’à quelle date les corrections peuvent-elles être présentées ? Un retest ciblé sur une anomalie ne remplace pas un examen complet après refonte. La consultation doit éviter que le prix initial soit comparé à une offre qui inclut un suivi plus large, puis que le budget augmente au moment de répondre au client.

Les exclusions ont une incidence sur la valeur de la preuve. Une offre qui écarte les API ou l’isolation entre organisations ne répond pas nécessairement à une demande d’audit du SaaS. La revue de code, le mobile, le cloud et les tests de charge ne sont pas automatiquement inclus. Faites préciser les limites sans exiger des actions destructives. Un devis doit aussi expliquer les modalités d’interruption et la façon de documenter une fonctionnalité qui ne peut pas être testée.

Construire une grille budgétaire

Utilisez une ligne par actif et une colonne par candidat. Relevez le nombre de rôles, les environnements, la méthode, la langue, le format de restitution, les conditions de retest et les coûts de déplacement éventuels. Ajoutez une colonne « hypothèses ». Elle permet de distinguer une vraie différence de prix d’une différence de couverture. Demandez une clarification écrite lorsque deux descriptions ne sont pas comparables plutôt que d’attribuer arbitrairement une meilleure note au devis le plus court.

N’inscrivez pas de fourchette de marché non documentée dans votre dossier achat. Votre budget doit résulter d’offres réelles et d’un périmètre accepté. Conservez la version de la consultation remise à chaque prestataire, puis rattachez les réponses à cette version. Si le client change la preuve attendue, réévaluez les offres avant commande. Une synthèse anglaise ou un contre-test demandé tardivement peut modifier la prestation et le calendrier, même lorsque l’application elle-même n’a pas changé.

Exemple de décision sans tarif fictif

Supposons une consultation pour une application et son API avec des comptes de test appartenant à deux organisations fictives. Une offre couvre uniquement l’interface ; une autre inclut l’API, la séparation des organisations et un rapport amendé après correction. Ce scénario est un exemple de lecture, pas un devis réel. Demandez au premier candidat une variante alignée sur la deuxième couverture avant de comparer. Vous évitez ainsi d’acheter un document qui ne répond pas à la clause client.

Présentez l’arbitrage au décideur avec le coût externe confirmé, la charge de préparation interne et les risques de décalage. Le commercial doit connaître la date de restitution envisagée et les conditions qui la rendent possible. Le CTO doit disposer d’une capacité de correction identifiable. Lorsque ces informations manquent, formulez une demande de clarification au cabinet : aucun prix publié ici ne remplace un devis propre à votre application.