La plupart des équipes qui prennent les pull requests au sérieux font déjà passer un ou deux réviseurs sur chaque modification. 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 si le code est sûr : une injection, une vérification d'accès défaillante, un secret divulgué. Tous deux répondent à de vraies questions, et une modification sérieuse mérite les deux.
Il existe une troisième question que la revue de code attribue rarement à un responsable : cette modification respecte-t-elle toujours les cadres de conformité auxquels votre entreprise est soumise ? 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 valides après le déploiement ?' C'est une question différente de la justesse et de la sécurité, et c'est celle pour laquelle heygrc est conçu. Elle s'ajoute aux deux autres sans les remplacer.
Correcte, sécurisée, 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 qui sera audité. Ce dernier cas est celui qui a rarement un réviseur 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 de même importance, l'article 22 du GDPR 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 livré est une question de conformité à résoudre, et non un défaut à corriger.
Pourquoi la troisième question n'a pas de propriétaire
Un vérificateur de bugs et un agent de sécurité peuvent être intentionnellement aveugles aux frameworks, et c'est là 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 immédiatement.
La conformité est l'inverse. Qu'un changement soit un constat dépend des frameworks auxquels vous êtes lié, des contrôles que vous avez documentés et de ce sur quoi votre dernier audit s'est appuyé. Le même diff qui n'est rien pour une entreprise est un écart de preuve SOC 2 CC7.2 pour une autre. Ce n'est pas quelque chose qu'une règle aveugle aux frameworks peut gérer 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 par rapport à elles.
Superposez les lentilles, 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 lentilles, et non une seule : est-elle correcte, est-elle sécurisée, respecte-t-elle toujours nos cadres. Gardez votre vérificateur de bugs. Gardez votre agent de sécurité. Ils sont bons dans leurs domaines, et heygrc ne cherche pas à répondre à leurs questions. heygrc ajoute la troisième lentille, et la rapporte de la seule manière qu'une découverte de conformité vaille quelque chose, en citant le contrôle exact qu'elle concerne.
L'exemple ci-dessus est illustratif, le type de changement qui soulève la troisième question, et non un incident spécifique. Mais la forme est l'essentiel : les changements qui modifient votre posture de conformité ne sont généralement pas ceux qui sont bogués ou non sécurisés. Ce sont ceux qui semblent propres et corrects, mais qui touchent discrètement un contrôle, ce qui est une chose différente à rechercher qu'un bug ou une vulnérabilité.