Primes et paiements

Pourquoi c’est important

Les primes et les paiements nécessitent le module complémentaire VDP (49 $/mois). Ils donnent accès au pipeline de versement complet, au grand livre financier immuable et à la gestion des documents fiscaux décrits sur cette page.

Bien gérer les paiements est à la fois un enjeu de fidélisation des chercheurs et une obligation de conformité. Des virements PayPal manuels sans collecte de formulaires W-8BEN (hors US) ou W-9 (US) créent une exposition directe auprès de l’IRS pour votre entreprise. Chaque paiement à un chercheur constitue un événement fiscal déclarable, et l’absence de documentation fiscale transfère la responsabilité sur vous. Le pipeline de versement de Kit résout ce problème en conditionnant les paiements à une liste de vérification configurable incluant la vérification des documents fiscaux.

Le grand livre financier immuable est le principal artefact de preuve SOC 2 pour les contrôles financiers de votre programme de divulgation des vulnérabilités. Chaque approbation de prime, chaque versement et chaque action sur un document fiscal sont enregistrés avec l’acteur, l’horodatage et le montant. Les auditeurs peuvent vérifier la chaîne de traçabilité complète, de la résolution du rapport à la confirmation du paiement, en un seul export.

Grille des primes

La grille des primes associe les niveaux de sévérité CVSS à des fourchettes de montants. Configurez-la dans VDP > Paramètres du programme > Grille des primes. Lorsqu’un membre de l’équipe évalue un rapport avec une notation CVSS, la fourchette de prime suggérée est automatiquement extraite de la grille et pré-remplie dans le formulaire d’approbation.

Les fourchettes de primes sont affichées sur votre page publique de politique de divulgation afin que les chercheurs sachent à quoi s’attendre avant de soumettre un rapport. Cette transparence réduit les litiges et fixe des attentes claires.

Pour les programmes basés sur la reconnaissance uniquement, laissez tous les niveaux à 0 $. Les chercheurs verront « reconnaissance uniquement » sur la page de politique au lieu de montants en dollars.

Consultez Configuration de votre programme pour tous les détails de configuration de la grille.

Deux façons d’arriver à un montant

Il existe deux chemins vers une prime approuvée, et les deux se terminent par la même action irréversible.

Chemin	Fonctionnement	Quand l’utiliser
Approbation directe	Un administrateur saisit un montant et l’approuve. Une seule étape. Décrite ci-dessous.	Le montant est évident — un rapport de sévérité basse au bas de sa fourchette dans la grille, une découverte à la limite du doublon, tout ce dont personne ne discuterait.
Proposer, puis approuver	N’importe quel membre met un montant sur la table avec une justification. Les collègues donnent leur accord ou objectent avec des contre-montants. Un administrateur approuve ensuite.	Le montant est contesté, inhabituellement élevé, ou crée un précédent qu’on vous opposera au prochain rapport.

Les propositions sont consultatives et invisibles pour le chercheur : rien dans une proposition ne notifie le chercheur, n’écrit au grand livre ni ne déplace d’argent. Elles ne verrouillent rien non plus — un administrateur peut approuver directement à tout moment, qu’une proposition soit ouverte ou non. Voir Propositions de prime et vote d’équipe.

Approuver une prime

Les administrateurs peuvent approuver une prime à tout moment avant que le rapport n’atteigne le statut Payé. En bonne pratique, attendez que le rapport soit validé — idéalement résolu — afin que le montant reflète une vulnérabilité confirmée et évaluée.

Pour approuver une prime :

1. Ouvrez la page de détail du rapport
2. Cliquez sur Approuver la prime
3. Remplissez le formulaire d’approbation

Champ	Obligatoire	Description
Montant	Oui	Montant de la prime, pré-rempli à partir de la grille des primes selon le niveau de sévérité CVSS du rapport.
Devise	Oui	USD par défaut. Doit correspondre à la devise configurée pour votre programme.
Notes	Non	Notes internes visibles uniquement par votre équipe. Chiffrées au repos.

L’approbation nécessite une soumission explicite — aucun montant n’est engagé tant que vous n’avez pas enregistré le formulaire. Lors de l’approbation :

• Une entrée bounty_approved est ajoutée au grand livre immuable
• Le chercheur est notifié via le modèle d’e-mail Prime approuvée
• Toute proposition de prime ouverte sur le rapport est close comme remplacée, ses votes conservés pour la trace

Ce dernier point mérite attention si votre équipe utilise les propositions : approuver directement alors qu’une proposition est ouverte paie le montant que vous avez saisi, pas celui dont l’équipe discutait, et met fin à la délibération. Approuvez plutôt depuis l’onglet Prime du rapport quand vous voulez le montant proposé.

Révoquer une prime

Rejeter un rapport ayant une prime approuvée révoque automatiquement celle-ci. La fenêtre de rejet vous avertit avec le montant, l’approbateur et la date d’approbation, et le bouton de validation devient Rejeter et révoquer la prime de X $. Lors de la révocation :

• Une entrée bounty_revoked est ajoutée au grand livre immuable comme débit — les totaux approuvés et en attente du grand livre la soustraient. Les métadonnées de l’entrée enregistrent le motif du rejet, l’approbateur d’origine avec la date d’approbation, et le statut du versement à ce moment.
• L’e-mail de rejet envoyé au chercheur indique que la prime précédemment approuvée a été retirée et ne sera pas payée ; la procédure d’appel habituelle constitue son recours. Son portail affiche une mention « retirée » à la place de la carte de prime.
• Le karma accordé pour la prime est annulé par un événement karma « Prime révoquée ».

Deux garde-fous s’appliquent :

• Une prime dont le versement est Terminé ne peut jamais être révoquée — ce qui est payé reste payé.
• Un paiement en cours (versement En attente ou En traitement) bloque le rejet. Marquez d’abord le versement comme échoué, ou laissez-le se terminer. Seul un versement En traitement peut être marqué comme échoué — En attente est un état transitoire d’une fraction de seconde (voir Statuts de versement), pas un état sur lequel vous pouvez agir.

L’annulation d’un rejet ne rétablit pas la prime. Une fois le rapport à nouveau validé, approuvez manuellement une nouvelle prime — l’interface affiche un rappel.

Pipeline de versement

Accédez à VDP > Versements pour gérer les paiements. La file d’attente s’ouvre sur une série d’onglets, afin que vous voyiez toujours la part du travail qui vous concerne : Prêt, Bloqué, Au service financier, Payé, Échoué et Tous. Par défaut, vous arrivez sur l’onglet Prêt.

Quatre cartes de synthèse s’affichent en haut de l’écran :

• Prêt — les rapports avec une prime approuvée et sans versement encore créé, dont la liste de vérification est satisfaite et pour lesquels les fonds peuvent partir immédiatement.
• Bloqué — les rapports avec une prime approuvée et sans versement encore créé, dont la liste de vérification n’est pas encore satisfaite.
• En cours — les paiements déjà transmis au service financier et en attente de confirmation.
• Le plus ancien en attente — la prime approuvée impayée la plus ancienne encore en cours. Elle indique depuis combien de jours elle attend, le chercheur et le montant, et renvoie directement vers l’onglet contenant cette ligne pour que vous puissiez agir.

Les montants dans des devises différentes ne sont jamais additionnés. Chaque carte affiche les montants par devise : un programme qui paie en USD et en EUR voit les deux totaux côte à côte, plutôt qu’un chiffre combiné dénué de sens.

Les onglets Prêt et Bloqué sont les deux moitiés d’un même ensemble — les rapports avec une prime approuvée mais sans versement encore créé — répartis selon que la liste de vérification est satisfaite ou non.

Liste de vérification de disponibilité

Avant qu’un versement puisse être effectué, le chercheur doit satisfaire une liste de vérification. Les trois éléments sont configurables dans les paramètres de paiement de votre programme :

• Informations de paiement soumises — Le chercheur a saisi ses coordonnées de paiement (virement bancaire, PayPal ou autre méthode) via le portail chercheur
• Accord accepté — Le chercheur a accepté l’accord de participation de votre programme (si votre programme l’exige)
• Document fiscal vérifié — Le W-8BEN ou W-9 du chercheur a été téléchargé et vérifié par votre équipe (si votre programme exige des documents fiscaux)

Les éléments non activés dans les paramètres de votre programme sont automatiquement marqués comme satisfaits.

La liste de vérification dépend aussi du statut du rapport, contrôlé par Exiger un correctif vérifié avant le paiement dans VDP > Paramètres du programme > Paiements :

• Activé (par défaut) — La prime ne peut être versée qu’après que votre équipe a marqué le correctif du rapport comme vérifié. Vous ne payez jamais pour une faille non résolue, mais les chercheurs peuvent devoir attendre la mise en production du correctif.
• Désactivé (paiement à la validation) — Le paiement se débloque dès que le rapport atteint le statut Validé, la norme du secteur sur des plateformes comme HackerOne et Bugcrowd. Les chercheurs sont payés plus vite, et le paiement est dissocié de la clôture du rapport : le rapport reste ouvert après le transfert des fonds et se ferme automatiquement avec le statut Payé une fois qu’il est résolu (ou son correctif vérifié). Les rapports payés ne peuvent jamais être rejetés, et la vérification du correctif devient une étape d’AQ facultative — enregistrez-la avant la résolution du rapport, sinon elle ne sera pas suivie.

Le tableau de relance

L’onglet Bloqué est un tableau de relance : au lieu d’une simple liste de paiements bloqués, il regroupe les paiements bloqués par chercheur, afin que vous relanciez une personne une seule fois plutôt que de la relancer sur plusieurs lignes. Les soumissions anonymes, qui n’ont aucun chercheur associé, forment leur propre groupe « sans chercheur ».

Chaque groupe affiche :

• Le chercheur (ou « anonyme » pour le groupe sans chercheur)
• Combien de ses paiements sont bloqués
• Le total dû, par devise
• Les blocages en cause, sous forme de pastilles : Informations de paiement, Document fiscal et Accord
• Depuis combien de jours attend le paiement le plus ancien du groupe

Les groupes sont classés en mettant d’abord ceux dont la relance est due — les chercheurs que vous pouvez relancer dès maintenant remontent en tête —, puis, à égalité, par ancienneté d’attente la plus longue.

Chaque groupe indique aussi ce qu’une relance débloquerait réellement, sous la forme d’un chiffre « débloque N paiements / X $ ». Ce décompte est volontairement honnête : il ne compte que les rapports dont chaque élément requis restant relève de ce que le chercheur peut corriger lui-même (informations de paiement, document fiscal, accord). Un rapport encore en attente de vérification du correctif — une étape qui incombe à votre équipe — n’est pas compté, car écrire au chercheur ne le débloquera pas. Le chiffre reflète ce qu’une relance peut véritablement débloquer, sans vœu pieux.

Relancer un chercheur

Depuis l’onglet Bloqué, cliquez sur Relancer au niveau du groupe d’un chercheur pour lui envoyer un rappel par e-mail. La relance nécessite le module complémentaire VDP et l’autorisation de paiement (disburse).

Un seul e-mail par chercheur couvre d’un coup toutes ses lacunes actuelles — informations de paiement, document fiscal et chaque accord propre à un rapport — au lieu d’envoyer un e-mail distinct pour chaque blocage. Le chercheur reçoit une liste de tâches unique et complète.

Chaque blocage dans l’e-mail est un lien magique menant directement à la page concernée. Un seul clic authentifie le chercheur et l’amène exactement sur la page qui lève ce blocage : le formulaire d’informations de paiement, le téléversement du document fiscal ou l’accord du rapport concerné. Comme le jeton est sans état, le lien magique de connexion existant du chercheur reste valide — une relance ne l’invalide jamais.

Les relances sont limitées par un délai d’attente de 3 jours propre à chaque couple (compte, chercheur). Si vous avez déjà relancé ce chercheur pendant cette période, le bouton indique que le délai n’est pas écoulé au lieu de renvoyer un e-mail. Ce délai est propre à chaque locataire : la relance d’un client n’affecte jamais celle d’un autre, même pour un chercheur qui soumet des rapports à plusieurs programmes.

Le bouton Relancer n’apparaît que lorsque le chercheur peut réellement débloquer quelque chose. Les manques au niveau du rapport — approbation de la prime, validation et vérification du correctif — relèvent de votre équipe et ne font jamais l’objet d’une relance ; une relance n’est proposée que pour les éléments que le chercheur peut corriger lui-même.

Traiter un paiement

Kit n’exécute pas de virements bancaires ni d’appels API de paiement. Votre équipe gère le mouvement réel des fonds en dehors de Kit (virement bancaire, PayPal, crypto, etc.). Kit assure le suivi du cycle de vie :

1. Lorsque tous les éléments de disponibilité sont satisfaits, cliquez sur Initier pour faire passer le versement en traitement
2. Exécutez le transfert via votre prestataire de paiement
3. Revenez dans Kit et cliquez sur Marquer comme payé — saisissez la référence de transaction (par ex., identifiant de transaction PayPal, numéro de confirmation de virement)
4. Le versement passe au statut Terminé et le rapport passe à Payé (sur les programmes en paiement à la validation, un rapport payé avant sa résolution reste ouvert et se ferme automatiquement avec le statut Payé une fois qu’il y parvient)

Confirmation par l’équipe financière

Dans la plupart des entreprises, la personne qui planifie le paiement travaille au service financier, et non à la sécurité — elle surveille une boîte de réception comme [email protected] et n’a pas de compte Kit. Le relais vers le service financier comble cette lacune : Kit envoie par e-mail à votre équipe financière tout ce dont elle a besoin pour planifier le paiement, et elle le confirme elle-même via un lien sécurisé.

Activez-le en renseignant E-mail du service financier dans VDP > Paramètres du programme > Paiements. Laissez le champ vide pour continuer à enregistrer les paiements manuellement dans Kit.

Avec un e-mail financier configuré, cliquer sur Initier envoie également une demande de paiement à cette adresse, contenant :

• Le bénéficiaire (chercheur), le montant et la méthode de paiement — les adresses PayPal sont affichées en entier ; les numéros de compte bancaire sont masqués à l’exception des quatre derniers chiffres, les détails complets n’étant accessibles que derrière le lien de confirmation
• La référence du versement à inclure dans le libellé du paiement, afin que le rapprochement fonctionne dans les deux sens
• La traçabilité de l’approbation : qui a approuvé la prime et quand, et qui a initié le paiement
• Un lien sécurisé, valable 90 jours, qui permet deux actions : confirmer le paiement, ou signaler qu’il a échoué

La personne du service financier ouvre le lien, voit les détails complets du paiement, effectue le paiement via votre prestataire de paiement, puis saisit la référence de transaction et son nom pour confirmer. La confirmation finalise le versement exactement comme un Marquer comme payé interne : l’entrée du grand livre est écrite, le rapport passe au statut Payé, le chercheur est notifié automatiquement et votre équipe reçoit la notification de paiement effectué habituelle — où la personne du service financier ayant confirmé apparaît comme celle qui a marqué le versement comme payé. La confirmation enregistre qui a confirmé (nom et e-mail), quand et depuis où (adresse IP) — visible sur la ligne du versement sous la mention Confirmé par le service financier.

Si le paiement n’aboutit pas, la même page propose un lien Signaler un paiement échoué sous le formulaire de confirmation. L’échec est enregistré avec la même traçabilité — qui l’a signalé, quand et depuis où — et la ligne du versement l’affiche sous la forme Paiement rejeté · Signalé par…. Voir Quand un versement échoue.

Quelques détails utiles à connaître :

• Les réponses parviennent à un humain. L’adresse de réponse de l’e-mail est le membre de l’équipe qui a initié le paiement ; les questions du service financier arrivent donc chez quelqu’un qui a le contexte.
• Renvoi à tout moment. La ligne du versement indique quand et où la demande a été envoyée, avec un bouton de renvoi qui génère un nouveau lien.
• Le flux interne reste disponible. Si le service financier répond « fait, réf. #123 » par e-mail au lieu de cliquer, votre équipe peut toujours marquer le versement comme payé manuellement — le lien affiche alors un reçu « déjà enregistré ».
• Le lien expire avec le versement. Une fois celui-ci terminé ou échoué, le lien ne peut plus rien confirmer ni signaler ; il affiche uniquement l’état actuel. Un échec signalé via le lien présente au service financier son propre reçu — l’auteur du signalement, la date, la raison, et une ligne lui indiquant de ne pas retenter le paiement, car une nouvelle demande suivra.
• Une confirmation par le service financier compte comme l’intervention d’une seconde personne. Comme le paiement a été confirmé en dehors de votre équipe Kit, l’approbateur reçoit toujours la notification de confirmation, et le niveau « second regard » décrit ci-dessous ne s’applique jamais — quelqu’un d’autre que l’approbateur a déjà validé le paiement.
• Les annulations sont signalées quand elles viennent de votre équipe. Si une demande de paiement a été envoyée et que votre équipe marque ensuite le versement comme échoué depuis Kit, le service financier reçoit, depuis le même expéditeur personnalisé, un avis « Paiement annulé — ne pas payer » — pour que personne ne verse d’argent pour un versement que vous avez retiré. Lorsque le service financier signale lui-même l’échec via le lien, aucun avis n’est envoyé — c’est lui qui nous a prévenus, et son reçu indique déjà la suite.

Quand un versement échoue

Kit ne déplace jamais d’argent, il n’apprend donc jamais de lui-même qu’un transfert a été rejeté. Quelqu’un doit le dire, et marquer un versement comme échoué est précisément cette déclaration. C’est une écriture comptable : aucun fonds ne bouge, rien n’est remboursé, et la prime approuvée reste intacte — le montant intégral demeure réservé au chercheur.

Deux personnes peuvent l’enregistrer. Votre équipe utilise Marquer comme échoué sur la ligne du versement, ce qui nécessite l’autorisation de paiement (disburse). Le service financier utilise le lien Signaler un paiement échoué sur la page de confirmation, afin que la personne qui a le rejet bancaire sous les yeux puisse l’enregistrer sans repasser d’abord par votre équipe.

Les deux chemins posent la même question, avec les quatre mêmes réponses :

Raison	Effet pour le chercheur
Le destinataire ne peut pas recevoir de paiements pour le moment	Envoie un e-mail au chercheur pour lui demander des informations de paiement valides
Les coordonnées du compte ne correspondaient à aucun compte existant	Envoie un e-mail au chercheur pour lui demander des informations de paiement valides
Le paiement est parti, mais il nous a été retourné	Envoie un e-mail au chercheur pour lui demander des informations de paiement valides
Autre chose	Ne contacte personne — réservé au triage interne. Elle exige une note, car cette note sera le seul élément dont disposera votre équipe

L’e-mail envoyé pour les trois premières raisons nomme la raison dans les termes du chercheur, rappelle que le montant intégral lui reste réservé et contient un lien magique qui le mène directement à sa page de paiement. Il ne cite jamais la note : ce que le service financier ou votre équipe a saisi — un message d’erreur du portail bancaire, une référence interne — reste au sein de votre équipe.

Les soumissions anonymes n’ont aucun chercheur enregistré : aucun e-mail n’est donc possible, quelle que soit la raison choisie.

Ce que voit votre équipe. La ligne passe dans l’onglet Échoué de la file d’attente et porte toute l’histoire : une pastille Paiement rejeté avec la raison, Signalé par… quand le service financier l’a enregistré, la note saisie, Nouvelles informations demandées au chercheur une fois cet e-mail parti, et Nouvelles informations de paiement enregistrées une fois qu’il a répondu. La chronologie du rapport enregistre l’échec avec le code de raison uniquement — la note n’apparaît jamais dans la chronologie. Le grand livre reçoit une entrée disbursement_failed, portant elle aussi le code seul.

Remise en file. Une nouvelle tentative est manuelle et réservée à votre équipe — le chercheur ne peut pas la déclencher. Le bouton Réessayer figure sur la ligne échouée et reste une action secondaire jusqu’à ce que le chercheur fournisse de nouvelles informations ; il devient alors l’action principale. C’est un signal de disponibilité, pas un ornement : réessayer avant cela ne fait que renvoyer le paiement vers le même compte mort.

Réessayer émet une nouvelle demande de paiement, avec une nouvelle référence et un nouveau lien. L’ancien lien de confirmation est mort, et le détail de l’échec quitte la file avec la tentative à laquelle il appartenait — le grand livre en garde la trace. Cela précise la notion de référence décrite plus haut : une référence identifie une tentative, pas la prime ; le rapprochement d’une prime payée à la deuxième tentative se fait donc sur la deuxième référence.

stateDiagram-v2
    state "En traitement" as Processing
    state "Échoué" as Failed
    state "Le chercheur met à jour ses informations de paiement" as Updated
    state "En traitement (nouveau versement)" as Retried

    [*] --> Processing: Initier
    Processing --> Failed: Marqué comme échoué par votre équipe ou par le service financier
    Failed --> Updated: Chercheur prévenu par e-mail — trois premières raisons uniquement
    Updated --> Retried: Réessayer
    Retried --> [*]: Marquer comme payé

    note right of Retried
      Réessayer ne ressuscite pas le versement échoué.
      Il en démarre un nouveau, donc l'ancienne
      référence et l'ancien lien sont morts.
    end note

Notifications de paiement effectué

Lorsqu’un versement est marqué comme payé, Kit en informe votre équipe. Cela referme la boucle entre le moment où l’argent est autorisé et celui où il part : la personne qui a approuvé la prime apprend qu’elle a été payée sans avoir à surveiller la file d’attente.

Il existe trois niveaux de notification, et leurs différences sont voulues. Deux sont purement informatifs. Le troisième ne l’est pas.

Niveau	Qui la reçoit	Quand elle se déclenche	Désactivable ?
Confirmation	Le membre de l’équipe qui a approuvé la prime	À chaque paiement effectué, sauf s’il l’a lui-même marqué comme payé	Oui
Second regard	Vos administrateurs du programme, sauf la personne qui a marqué le paiement comme effectué	Une seule personne a approuvé, ajusté et payé la même prime, et le montant a sensiblement augmenté	Oui
Incohérence du grand livre	L’approbateur et tous les administrateurs du programme, sauf la personne qui a marqué le paiement comme effectué	La prime enregistrée sur le rapport et son historique dans le grand livre ne concordent plus	Non

Confirmation est le cas ordinaire, celui que vous verrez presque à chaque fois. L’approbateur reçoit une note brève : qui a marqué la prime comme payée, pour quel montant, quand, et la référence de transaction si elle a été saisie. Si la prime a été ajustée entre-temps, la note indique l’approbation initiale et, séparément, le montant auquel elle a été ajustée ainsi que l’auteur de l’ajustement — les chiffres se recoupent ainsi d’un simple coup d’œil. Lorsque la même personne a à la fois approuvé et finalisé le paiement, rien n’est envoyé : personne n’a besoin qu’on lui signale sa propre action. Si l’approbateur n’est plus membre de votre compte, la confirmation part vers vos administrateurs du programme, afin que la boucle se referme malgré tout. Rien n’exige d’action ici. C’est un reçu.

Second regard comble la seule faille que laisse ouverte le niveau Confirmation. Comme un paiement finalisé par son propre approbateur n’envoie rien, une seule personne pourrait sinon approuver une petite prime, l’augmenter, puis se la verser sans que personne n’en soit averti. Ce niveau rétablit cette visibilité : lorsque l’approbation, chaque ajustement et le paiement ont tous été effectués par la même personne et que le montant final est sensiblement supérieur à celui approuvé au départ, Kit en informe vos autres administrateurs du programme.

« Sensiblement supérieur » s’apprécie au regard des paramètres de votre propre programme, et non d’un seuil fixe :

• Sur un programme qui utilise une grille des primes, le montant est jugé sensiblement supérieur dès qu’il dépasse le maximum déclaré pour le niveau de sévérité évalué du rapport. Une variation à l’intérieur de la fourchette que votre grille autorise déjà relève de la routine et ne déclenche rien.
• Sur un programme discrétionnaire sans grille, le montant est jugé sensiblement supérieur lorsqu’il a au moins doublé et qu’il a augmenté d’au moins le Paiement minimum de votre programme. La valeur par défaut de Kit, 50 $, s’applique si vous avez fixé ce plancher à zéro. Les deux conditions doivent être réunies : ni 500 $ → 550 $ ni 6 $ → 12 $ ne déclenchent quoi que ce soit, contrairement à 6 $ → 600 $.

Ce critère connaît une exception. Si un rapport porte un ajustement enregistré avant le 5 juin 2026, son total approuvé ne peut pas être reconstitué à partir du grand livre (voir Lire les entrées d’ajustement) : Kit ne peut donc pas juger si le montant a sensiblement augmenté. Un paiement mené de bout en bout par une seule personne sur un tel rapport déclenche la notification « second regard » quel que soit le montant, avec une formulation qui indique seulement qu’aucune deuxième personne n’est intervenue — elle n’affirme jamais une hausse qu’elle n’a pas pu mesurer.

Les baisses ne déclenchent jamais cette notification, et pas davantage le travail courant mené par une seule personne — une coquille corrigée, un petit complément. C’est délibéré. Beaucoup de programmes n’ont qu’un seul administrateur actif qui prend légitimement en charge chaque paiement de bout en bout, et une notification à chaque correction habituerait tout le monde à ignorer la seule notification qui ne doit jamais l’être. Pour ces paiements, le grand livre et la chronologie du rapport font foi.

La formulation est factuelle, non accusatoire : qui a approuvé quoi, qui a ajusté à quel montant, qui a payé, et un lien vers le rapport. Il s’agit de demander à un collègue de jeter un œil à la piste d’audit — ce n’est ni un constat d’anomalie, ni une accusation contre la personne qui a fait le travail.

Une conséquence à anticiper : si votre programme ne compte qu’un seul administrateur et que c’est cette personne qui a marqué le paiement comme effectué, ce niveau n’a plus personne à prévenir et n’envoie rien. Le grand livre et la chronologie constituent alors votre seule trace — une bonne raison de nommer un deuxième administrateur du programme.

Incohérence du grand livre est le niveau qui signale un véritable problème. Il se déclenche lorsque le montant de la prime enregistré sur le rapport ne correspond plus à la somme de son historique dans le grand livre. Dans Kit, tous les chemins écrivent la prime et son entrée de grand livre ensemble — approuver, ajuster et révoquer déplacent les deux d’un même mouvement — cela ne peut donc pas se produire en usage normal. Une incohérence signifie que les données sous-jacentes ont été modifiées en dehors de l’application.

Ce niveau ne peut pas être désactivé. Il ignore les préférences de catégories d’e-mails et ne comporte aucun lien de désabonnement : un signal portant sur l’intégrité de votre trace financière ne doit pas pouvoir être réduit au silence. Il part vers l’approbateur et vers tous les administrateurs du programme, afin que l’incohérence soit toujours visible par quelqu’un d’autre que la personne qui a finalisé le paiement.

Si vous en recevez une, contactez le support — n’essayez pas de rapprocher les montants à la main. Traitez-la exactement comme une violation d’intégrité du grand livre.

Comment ces niveaux vous parviennent :

• Les notifications dans l’application arrivent toujours, pour les trois niveaux et pour chaque destinataire de la liste. L’icône en forme de cloche n’est pas affectée par les préférences d’e-mail.
• Les e-mails de confirmation et de second regard relèvent de la catégorie Activité programme de sécurité dans les Préférences d’e-mail et de notifications, et ils sont mis en pause pendant le mode congés.
• Les e-mails d’incohérence du grand livre ignorent cette catégorie mais respectent tout de même le mode congés. C’est la diffusion à tous les administrateurs du programme qui garantit que l’alerte atteint quelqu’un pendant l’absence de l’approbateur.

Statuts de versement

Statut	Signification
En attente	La ligne de versement existe mais n’a pas encore été initiée. Initier crée la ligne et la fait avancer dans le même geste : En attente est donc un état transitoire d’une fraction de seconde, pas un état de file — une prime qui attend la liste de vérification n’a aucun versement du tout et se trouve dans l’onglet Bloqué
En traitement	Votre équipe a initié le transfert en dehors de Kit
Terminé	Fonds confirmés reçus ; référence de transaction enregistrée — le rapport se ferme avec le statut Payé dès que son cycle de vie le permet
Échoué	Le transfert n’a pas abouti. Pour trois des quatre raisons d’échec, Kit a déjà demandé de nouvelles informations au chercheur — ne lui écrivez pas une seconde fois. Remettez le versement en file avec Réessayer une fois les nouvelles informations enregistrées

Si un versement échoue, le grand livre enregistre une entrée disbursement_failed portant le code de raison — la note saisie en est délibérément tenue à l’écart. Le service financier ne reçoit un e-mail d’annulation que lorsque votre équipe a marqué l’échec et qu’une demande de paiement lui avait déjà été envoyée ; un échec qu’il a signalé lui-même n’envoie rien. La remise en file est un Réessayer manuel sur la ligne échouée, qui devient l’action principale de la ligne une fois que le chercheur a fourni des informations valides. Voir Quand un versement échoue pour la boucle complète.

Documents fiscaux

Les chercheurs téléchargent leurs documents fiscaux via leur portail. Les chercheurs basés aux États-Unis soumettent un W-9 ; les chercheurs hors US soumettent un W-8BEN. Les documents sont stockés avec chiffrement au repos.

Votre équipe examine les documents téléchargés dans VDP > Documents fiscaux :

Statut	Action
En attente	Document téléchargé, en attente de votre examen
Vérifié	Vous avez confirmé que le document est valide — l’élément de disponibilité est satisfait
Rejeté	Vous avez rejeté le document — le chercheur est notifié et peut télécharger à nouveau

La vérification comme le rejet sont enregistrés dans le grand livre à des fins d’audit. Les événements liés aux documents fiscaux sont associés au rapport le plus récent du chercheur ayant reçu une prime, pour le contexte du grand livre.

Le grand livre

Accédez à VDP > Grand livre pour consulter la piste d’audit financière immuable. Le grand livre fonctionne en ajout uniquement : les entrées ne peuvent être ni modifiées, ni altérées, ni supprimées.

Chaque entrée enregistre :

• Type d’entrée — Ce qui s’est passé
• Montant — Montant en centimes et devise
• Acteur — Le membre de l’équipe ayant effectué l’action. Les entrées enregistrées depuis l’extérieur de votre équipe — un paiement confirmé, ou un échec signalé, via le lien du service financier — n’ont aucun utilisateur Kit derrière elles et s’affichent comme Système. C’est attendu, pas une lacune : le nom de la personne du service financier est conservé dans la traçabilité chiffrée du versement et affiché sur la ligne de la file sous la mention Signalé par…
• Horodatage — Date et heure de création de l’entrée
• Référence du rapport — Le rapport de vulnérabilité associé

Chaque entrée enregistre l’un des types suivants :

Type d’entrée	Quand il est créé
bounty_approved	Un membre de l’équipe approuve un montant de prime pour un rapport
bounty_adjusted	Un membre de l’équipe corrige le montant de la prime avant l’envoi du paiement. Le montant enregistré est la variation, non le nouveau total — voir Lire les entrées d’ajustement
bounty_revoked	Un rapport avec une prime approuvée est rejeté ; la révocation compte comme un débit dans les totaux du grand livre
disbursement_initiated	Un membre de l’équipe fait passer le versement en traitement
disbursement_completed	Un membre de l’équipe marque le versement comme payé avec une référence de transaction
disbursement_failed	Un versement est marqué comme échoué. L’entrée porte l’un des quatre codes de raison fixes ; la note en texte libre est délibérément tenue à l’écart du grand livre — voir Quand un versement échoue
tax_document_submitted	Un chercheur télécharge un document W-8BEN ou W-9
tax_document_verified	Un membre de l’équipe vérifie un document fiscal comme valide
tax_document_rejected	Un membre de l’équipe rejette un document fiscal ; le chercheur est notifié et peut le télécharger à nouveau

Filtrez le grand livre par identifiant de rapport, type d’entrée ou plage de dates pour affiner les résultats. Utilisez l’export du grand livre dans Métriques et exports pour générer des dossiers de preuve SOC 2.

Lire les entrées d’ajustement

bounty_adjusted est le seul type d’entrée dont le montant est une variation, et non un total. Toutes les autres entrées enregistrent une valeur absolue — la prime approuvée, la somme versée, le montant révoqué. Un ajustement n’enregistre que la différence apportée par la correction, positive ou négative.

Cette distinction compte au moment du rapprochement. Une prime de 6 $ corrigée à 600 $ enregistre un montant bounty_adjusted de 594 $ : c’est l’ampleur de la correction, et non une seconde prime de 594 $. Lue comme un total, une simple correction de coquille peut passer pour un trop-payé.

Kit signale donc explicitement les ajustements partout où ils apparaissent, pour que vous n’ayez jamais à deviner quelle lecture s’applique :

• Chronologie du rapport — affiche « Prime ajustée à 600 $ USD », soit le total obtenu : le chiffre visible sur le rapport est donc la prime elle-même.
• Page du grand livre — affiche la variation avec un signe explicite : +594 $ pour une hausse, -594 $ pour une baisse. Un + en tête signifie « le montant a varié de cette valeur ».
• Export CSV du grand livre — contient la variation, une colonne indiquant si ce montant est une variation ou une valeur absolue, et une colonne donnant le total auquel l’ajustement a abouti.
• Export PDF du grand livre et dossier PDF du rapport — impriment la variation signée suivie du total qu’elle a produit, sous la forme +$594 USD -> $600 USD.
• Slack, là où votre programme publie les événements de paiement — un paiement effectué sur une prime ajustée indique l’approbation initiale et le total ajusté, plutôt que la variation seule.

Pour reconstituer la prime actuellement approuvée à partir du seul grand livre, partez de l’approbation, ajoutez chaque ajustement enregistré ensuite, puis retranchez toute révocation. C’est cette somme que Kit compare au montant enregistré sur le rapport lui-même (voir Notifications de paiement effectué).

Les ajustements enregistrés avant le 5 juin 2026 sont antérieurs à ce dispositif : ils portent un montant absolu et ne conservent aucune trace du total qu’ils ont produit. Kit les signale différemment plutôt que de deviner — la chronologie affiche « Prime ajustée de », le CSV indique un type de montant unknown et la colonne du total obtenu reste vide. Une entrée ancienne n’est jamais présentée comme quelque chose qu’elle ne peut pas prouver.

Intégrité du grand livre

Une vérification d’intégrité quotidienne s’exécute automatiquement pour vérifier la cohérence du grand livre. Elle parcourt chaque entrée dans l’ordre chronologique et suit un solde courant : les crédits (bounty_approved, bounty_adjusted) l’augmentent, les débits (disbursement_completed, bounty_revoked) le diminuent. Si le solde courant devient négatif, l’entrée en cause est signalée comme une violation.

Ce solde courant est un contrôle de solvabilité, et il ne se calcule pas comme le total approuvé décrit dans Lire les entrées d’ajustement. Le solde courant soustrait aussi les versements terminés, car l’argent déjà sorti ne doit plus être compté comme dû. Le total approuvé, lui, ne les soustrait pas : payer une prime ne change rien à ce qui a été approuvé. Servez-vous du solde courant pour savoir si les comptes du programme sont cohérents dans le temps, et du total approuvé pour savoir ce qui est actuellement approuvé sur un rapport.

Toute violation est signalée au système de surveillance des erreurs de Kit (APM) afin que l’équipe d’ingénierie puisse l’examiner — aucun e-mail n’est envoyé aux administrateurs du compte. Contactez le support si vous suspectez un écart dans le grand livre — ne tentez pas de le résoudre manuellement.

Checklist

• Configurez les niveaux de la grille des primes avec des fourchettes min/max appropriées à votre tolérance au risque
• Définissez les exigences de disponibilité au paiement (documents fiscaux, accord) dans les paramètres de paiement de votre programme
• Renseignez un e-mail du service financier afin que les demandes de paiement parviennent à l’équipe qui planifie réellement les paiements
• Communiquez les fourchettes de primes sur votre page de politique de divulgation avant que les chercheurs ne soumettent leurs rapports
• Vérifiez la file d’attente des versements chaque semaine pour les paiements en attente
• Consultez l’onglet Échoué de façon délibérée — un versement rejeté ne déclenche ni e-mail ni notification dans l’application
• Choisissez Autre chose avant de rejeter un rapport dont le versement est encore en cours, afin que le chercheur ne se voie pas demander des informations pour une prime que vous retirez
• Nommez au moins deux administrateurs du programme, afin qu’un paiement mené de bout en bout par une seule personne parvienne tout de même à un regard indépendant
• Convenez en équipe des cas où une prime passe par une proposition plutôt que directement à l’approbation — Kit ne l’impose pas
• Lisez les montants bounty_adjusted du grand livre comme des variations, et non comme des totaux, lors du rapprochement d’un export
• Traitez une notification d’incohérence du grand livre comme une affaire à confier au support, et non comme quelque chose à corriger à la main
• Examinez et vérifiez rapidement les documents fiscaux téléchargés pour débloquer les paiements des chercheurs
• Exportez le grand livre trimestriellement comme preuve SOC 2 via Métriques et exports

Et ensuite ?

• Propositions de prime et vote d’équipe — décider d’un montant en équipe avant qu’il ne devienne de l’argent
• Métriques et exports — KPI du tableau de bord, exports de preuves SOC 2 et karma des chercheurs
• Le portail chercheur — comment les chercheurs soumettent leurs informations de paiement et documents fiscaux