Toute pratique importante en ingénierie finit par recevoir un nom. Celle-ci s'appelle la revue de conformité pour les pull requests : examiner chaque modification par rapport aux cadres de conformité que votre entreprise doit respecter, et identifier le contrôle spécifique concerné, directement dans le diff, avant la fusion. heygrc est notre solution dans cette catégorie, mais la catégorie dépasse tout produit, et elle mérite son propre argumentaire.
Les catégories se divisent, et la revue de code se divise maintenant
Les pratiques ne convergent pas vers un seul outil capable de tout faire ; elles se spécialisent. La revue de code s'est déjà divisée une première fois : la revue de justesse (est-ce que cette modification fonctionne) et la revue de sécurité (est-ce que cette modification est sûre) posent des questions différentes, répondues par des relecteurs différents, dotés de connaissances différentes, sur la même pull request. Personne n'attend d'un linter qu'il détecte une injection, et personne n'attend d'un scanner de sécurité qu'il repère une erreur d'indexation.
La conformité est la troisième division. Savoir si une modification affecte un contrôle audité n'est ni une question de justesse ni une question de sécurité : une modification peut être correcte, sûre, et pourtant élargir un chemin d'accès que SOC 2 CC6.1 surveille, ou supprimer un journal que ISO 27001:2022 A.8.15 exige de conserver. C'est une question différente, qui nécessite des connaissances différentes, mais sur le même diff. Lorsqu'une question est posée suffisamment souvent en ses propres termes, elle devient une catégorie.
Pourquoi cette catégorie existe aujourd'hui et pas il y a cinq ans
Deux courbes se sont croisées. La première : l'assistance par IA augmente la quantité de code produite par les équipes, alors que l'attention humaine par modification n'a pas suivi le même rythme. Les équipes qui livrent avec des agents fusionnent plus de modifications, plus rapidement, avec moins de lecture humaine par ligne que ce que la pratique supposait initialement.
La seconde : la surface de conformité des mêmes bases de code s'accroît. Davantage d'entreprises adoptent SOC 2 et ISO 27001 plus tôt ; le RGPD a été rejoint par DORA, NIS 2 et l'EU AI Act ; et les obligations résident de plus en plus dans le code, dans les limites de conservation, les chemins d'accès, les journaux et le comportement des modèles. Plus de modifications, moins de lecture humaine, plus d'obligations par modification : la lecture de conformité a besoin d'automatisation au niveau du diff pour être effectuée de manière cohérente.
Ce qu'est la catégorie, et ce qu'elle n'est pas
Un relecteur de conformité pour les pull requests examine la modification par rapport aux cadres sélectionnés par votre entreprise et ancré chaque constat dans le contrôle spécifique concerné, avec un niveau de détail permettant de vérifier ou de contester. Il s'exécute là où la revue de code a déjà lieu, et il informe plutôt qu'il ne bloque : les constats sont des commentaires de revue et un statut de vérification, pas un blocage de fusion.
Ce n'est pas une plateforme GRC (elle ne gère pas votre programme de conformité ni ne collecte vos preuves), ce n'est pas un audit (c'est un indicateur avancé sur les mêmes obligations que l'audit mesure), et ce n'est pas une certification (une revue est une lecture, pas un badge). Ces outils conservent leurs rôles. Cette catégorie existe pour le seul rôle qu'aucun d'eux ne couvre : la question de conformité, posée pour chaque diff, alors que la modification est encore peu coûteuse à corriger.