La plupart des équipes qui prennent les pull requests au sérieux font déjà passer chaque modification par un ou deux relecteurs. Un vérificateur de bugs comme Cursor Bugbot ou CodeRabbit lit le diff et demande si le code est correct. Un agent de sécurité le lit et demande s'il est sûr : une injection, une vérification d'accès défaillante, un secret divulgué. Les deux répondent à des questions réelles, et une modification sérieuse mérite les deux.
Il existe une troisième question que la relecture de code assigne rarement à un responsable : cette modification respecte-t-elle toujours les cadres de conformité sur lesquels votre entreprise est auditée ? Pas « est-ce un bug » et pas « est-ce une vulnérabilité », mais « touche-t-elle un contrôle dans SOC 2, ISO 27001 ou le RGPD, et les preuves sont-elles toujours valables après le déploiement ? » C'est une question différente de la correction et de la sécurité, et c'est celle pour laquelle heygrc a été conçu. Il s'ajoute aux deux autres sans remplacer l'une ou l'autre.
Correct, sécurisé, et pourtant un constat
Les trois questions sont indépendantes. Une modification peut être un bug sans être une vulnérabilité. Elle peut être une vulnérabilité sans être un problème de conformité. Et elle peut être un code propre et fonctionnel qui modifie tout de même un contrôle sur lequel vous serez audité. Ce dernier cas est celui qui a rarement un relecteur dans la pièce.
Voici le type de modification que nous entendons. Considérez-le comme illustratif : une ligne de code propre qui compile et s'exécute, et qui n'est ni le bug ni la vulnérabilité dans le diff.
export async function decideRefund(req: RefundRequest) { const score = await risk.score(req) if (score < 0.2) return { status: "rejected", reason: "auto" } return queueForReview(req)}La branche est un code propre et fonctionnel : elle retourne une décision et rien en elle n'est un bug ou une vulnérabilité. Mais elle prend une décision entièrement automatisée concernant une personne, refusant son remboursement, sans possibilité de révision humaine. Lorsqu'une décision de ce type produit un effet juridique ou tout aussi significatif, l'article 22 du RGPD accorde à la personne le droit de ne pas y être soumise et le droit d'obtenir une intervention humaine. Ce que cette modification a réellement déployé est une question de conformité à résoudre, et non un défaut à corriger.
Pourquoi la troisième question n'a pas de responsable
Un vérificateur de bugs et un agent de sécurité peuvent être intentionnellement aveugles aux cadres, et c'est leur force. Leurs règles sont universelles : une utilisation après libération est une utilisation après libération dans chaque dépôt, une requête non paramétrée est une injection partout. Les règles universelles expliquent pourquoi ces outils fonctionnent dès leur installation.
La conformité est l'inverse. Qu'une modification soit un constat dépend des cadres auxquels vous êtes lié, des contrôles que vous avez documentés et des éléments sur lesquels votre dernier audit s'est appuyé. Le même diff qui ne pose aucun problème pour une entreprise représente un écart de preuve SOC 2 CC7.2 pour une autre. Ce n'est pas quelque chose qu'une règle aveugle aux cadres peut porter seule, car le problème n'est pas une propriété du code. C'est une propriété de vos obligations, et il doit être lu à leur lumière.
Superposez les perspectives, ne choisissez pas entre elles
La conclusion n'est pas « ajoutez un autre outil ». C'est qu'une pull request est lue de manière la plus complète à travers trois perspectives, et non une seule : le code est-il correct, est-il sécurisé, respecte-t-il toujours nos cadres. Gardez votre vérificateur de bugs. Gardez votre agent de sécurité. Ils sont bons pour leurs questions, et heygrc ne cherche pas à y répondre. heygrc ajoute la troisième perspective, et la signale de la seule manière qui donne de la valeur à un constat de conformité : en citant le contrôle exact qu'il concerne.
L'exemple ci-dessus est illustratif, le type de modification qui soulève la troisième question, et non un incident spécifique. Mais la nature même de ces modifications est le point clé : celles qui modifient votre posture de conformité ne sont généralement pas les boguées ou les non sécurisées. Ce sont les modifications propres et apparemment correctes qui touchent discrètement un contrôle, ce qui est une chose différente à rechercher qu'un bug ou une vulnérabilité.