Pas de preuve. Pas de paiement.

Un modèle de rémunération au résultat nécessite une définition commune de ce résultat. Il peut s'agir, par exemple, d'une preuve décrite de façon concrète qu'une limite d'autorisation convenue n'est pas respectée dans les conditions fixées. Le niveau d'impact, de gravité et de reproductibilité jugé suffisant est fixé avant le début. Les constats déjà connus et les risques déjà acceptés sont eux aussi classés. Les deux parties savent ainsi si une preuve ultérieure relève de l'objectif convenu ou constitue seulement une observation supplémentaire.

Le montant fixe se rapporte à ce résultat défini par écrit et au périmètre de contrôle convenu. Si la preuve requise n'est pas apportée dans ce cadre, la rémunération au résultat du pentest n'est pas due. Un constat en dehors du périmètre ne crée pas automatiquement de droit à paiement. Des analyses supplémentaires, une correction ou de nouveaux tests ne sont commandés que par un accord distinct et explicite. Le modèle vise à créer une base économique claire, et non une attente indéterminée selon laquelle chaque anomalie technique constituerait déjà un succès.

Avant le début, les systèmes cibles, les points de départ autorisés, les comptes de test et la fenêtre temporelle sont consignés. Les droits sur des systèmes ou plateformes tiers doivent être clarifiés. Les interlocuteurs, les circuits de notification et les conditions d'interruption sont également convenus. L'incitation liée à la preuve d'un résultat ne change rien à ces règles. Un test ne doit ni être étendu unilatéralement à d'autres systèmes, ni être poursuivi avec des méthodes non autorisées, dans le seul but d'atteindre l'objectif défini.

Les preuves sont limitées au strict nécessaire pour l'évaluation. Lorsqu'un jeu de test préparé permet de montrer un impact, il n'est pas nécessaire d'utiliser pour cela des données d'autres clients. Les résultats sensibles sont partagés par des canaux convenus avec les interlocuteurs habilités. Pour les questions litigieuses relatives à l'évaluation, une procédure de contrôle commune est convenue au préalable. La décision sur le résultat peut ainsi être prise sur la base de critères et de documentation, plutôt que de devoir concilier, seulement à la fin, des conceptions différentes de la portée d'un constat.

Result as a Service convient à des objectifs qui peuvent être clairement délimités et démontrés. Cela peut inclure des questions définies dans un SaaS, des API, des logiciels legacy ou une infrastructure sous la responsabilité du client. Pour les applications d'IA, la variabilité des résultats et la pluralité des composants impliqués exigent des critères de preuve particulièrement précis. La pertinence du modèle pour votre projet est donc vérifiée avant tout engagement. Un état des lieux général, une couverture d'audit complète et un objectif de contrôle unique à rémunération au résultat sont des prestations différentes.

Un test qui n'aboutit pas à la preuve convenue ne signifie pas que le système est globalement exempt de vulnérabilités. La conclusion reste limitée au périmètre, à l'état et à la fenêtre temporelle testés. Même lorsque la preuve est apportée, elle n'est d'abord que le point de départ de la correction. La documentation technique doit permettre à votre équipe de comprendre la cause et l'impact, et de planifier la correction. Un nouveau test ultérieur peut vérifier de façon ciblée si la vulnérabilité concrète est corrigée dans la nouvelle version ; son périmètre est défini séparément.