heygrc examine vos pull requests par rapport aux cadres de conformité que votre entreprise doit respecter, en s'appuyant sur le contexte propre à votre entreprise. La configuration prend environ trois minutes et suit une structure délibérée : installez l'application GitHub une fois, puis configurez tout le reste as code via une petite API REST, ce qui signifie que votre agent de codage peut effectuer la plupart des étapes pour vous.
Ce guide pratique couvre l'intégralité du flux, de l'installation à la configuration, en passant par la fréquence des revues, ainsi que la question que chaque ingénieur pose en premier : cet outil peut-il bloquer mes fusions ? Le contrat API exact et les payloads sont disponibles sur https://docs.heygrc.com/docs/setup-with-an-agent et https://docs.heygrc.com/docs/api-reference ; cette page en est la carte.
Étape 1 : installer l'application GitHub
L'installation d'une application GitHub est généralement une action réservée au propriétaire de l'organisation ou du compte, bien que dans certaines organisations, un administrateur de dépôt puisse l'installer pour les dépôts qu'il gère. Dans tous les cas, il s'agit de l'unique étape qu'aucun agent ou API ne peut effectuer à votre place. Depuis github.com/apps/heygrc, choisissez votre organisation ou compte, sélectionnez les dépôts que vous souhaitez faire examiner, puis installez. Vous pouvez commencer par un seul dépôt.
heygrc demande uniquement les autorisations minimales nécessaires : accès en lecture au code, aux métadonnées et aux problèmes, ainsi qu'accès en lecture et écriture aux Checks et Pull requests afin de pouvoir publier une revue et un statut. Il n'a jamais besoin d'un accès en écriture à votre code, et il ne pousse jamais de commits.
Étape 2 : configurer votre contexte et vos cadres as code
C'est la partie qui fait de heygrc un spécialiste plutôt qu'un linter générique. Vous décrivez votre entreprise, ce que vous construisez, les données que vous traitez, où vous hébergez, les obligations qui vous incombent, puis vous sélectionnez les cadres applicables. Cette configuration est envoyée à heygrc via un seul appel API. Comme il s'agit d'un simple appel REST, vous pouvez confier la tâche à votre agent de codage : demandez à Claude Code ou Cursor de configurer heygrc pour votre organisation avec votre contexte et vos cadres, et il effectuera l'appel.
Le profil de l'entreprise est un contexte libre, et plus il est pertinent, plus les revues sont précises. heygrc injecte votre profil et les connaissances liées à vos cadres sélectionnés dans chaque revue, de sorte qu'une modification de l'authentification, de la gestion des données, de la journalisation ou d'une dépendance est évaluée par rapport à vos contrôles spécifiques plutôt qu'à une checklist générique. Vous pouvez relire la configuration à tout moment.
Étape 3 : choisir la fréquence des revues
heygrc prend en charge trois modes de revue. En mode auto (par défaut), il examine chaque pull request lorsqu'elle est ouverte, rouverte ou mise à jour. En mode auto-once, il examine uniquement à l'ouverture ou à la réouverture, mais pas à chaque nouveau commit. En mode mention-only, il reste silencieux jusqu'à ce que quelqu'un commente une commande slash sur la pull request, ce qui est utile si vous souhaitez des revues à la demande plutôt qu'à chaque modification.
Vous définissez le mode par organisation, et vous pouvez le remplacer par dépôt. Les revues à la demande sont réservées aux personnes qui sont propriétaire, membre ou collaborateur du dépôt, de sorte qu'un commentateur occasionnel ne peut pas les déclencher.
heygrc bloque-t-il vos fusions ? Pas de son propre chef
heygrc publie sa revue sous forme de commentaires ainsi qu'un statut GitHub Checks, et ce statut est toujours neutre ou réussi, jamais un échec en cas de résultats. Il ne soumet jamais de revue de type request-changes. Par défaut, heygrc ne peut donc pas bloquer une fusion : il informe les personnes et les agents qui livrent le code, sans se placer entre eux et le bouton de fusion.
Il existe un paramètre qui peut changer cela, et il vous appartient, pas à heygrc. Si votre dépôt exige la résolution des conversations avant la fusion, GitHub lui-même exige que chaque fil de discussion non résolu, y compris les commentaires en ligne d'un bot, soit résolu au préalable. heygrc laisse des commentaires en ligne ancrés sur les lignes exactes d'un résultat, et ceux-ci sont des fils de discussion résolvables. Dans un dépôt avec cette règle activée, vous résolvez chaque résultat avant la fusion, ce qui, pour un flux de conformité, est souvent souhaitable : il s'agit d'une reconnaissance légère et enregistrée que l'équipe a vu et traité l'impact du contrôle. Si vous ne souhaitez pas cela, désactivez la règle de branche, et aucun commentaire de relecteur, qu'il provienne de heygrc ou d'un humain, ne bloquera une fusion.