Une review verte n'est pas un contrôle de merge

TL;DR

J’ai besoin d’une procédure terminée, d’un producteur connu et de preuves pour la révision actuelle avant qu’une review puisse influencer le merge. Une interface verte ne répond pas à ces questions ; je les rendrais donc explicites dans la politique de branche et ses cas de vérification.

Objet	Ce qu’il prouve
Commentaire de bot	Une identité a publié du texte sur une pull request
Exécution de workflow	Une automatisation nommée a atteint la conclusion enregistrée
Check ou statut GitHub	Un contexte a rapporté un état pour un commit
Check requis	La politique de branche exige un état accepté avant merge
Preuve de review exploitable	Fournisseur, SHA, périmètre, état d’exécution et publication correspondent tous

Une pull request peut sembler verte sans contenir de code review terminée. L’interface compresse commentaires, conclusions de workflows, états de checks et règles de branche en quelques couleurs. Ces objets ont des producteurs et des autorités différents.

Si une équipe traite tout signal vert ressemblant à une review comme preuve que la modification a été inspectée, un reviewer indisponible ou dont la review est périmée disparaît dans un parcours de livraison par ailleurs réussi. La correction commence par nommer les objets et rattacher chaque décision au commit actuel.

4 objets verts aux autorités différentes

Un commentaire de bot est du texte publié. Il peut contenir des constats, un résumé, un placeholder, un avis de limite de débit ou une erreur. Sa présence n’établit pas que la procédure de review déclarée est terminée.

Une exécution de workflow est l’exécution d’une automatisation. Une conclusion réussie signifie que les étapes du workflow ont satisfait sa propre politique de sortie configurée. Un workflow peut délibérément terminer avec succès après le timeout d’un reviewer optionnel.

Un check GitHub ou statut de commit est un état nommé associé à un commit. Il peut venir de GitHub Actions ou d’une autre intégration. Son nom et sa couleur ne révèlent pas toute la sémantique de son producteur.

Un check requis est sélectionné par la protection de branche ou un jeu de règles. Il a autorité sur le merge parce que la politique de branche exige un état accepté, pas parce que son nom contient « review ».

La documentation GitHub des branches protégées, vérifiée le 27 septembre 2026, précise que les checks de statut requis doivent être réussis, sautés ou neutres avant merge. Les administrateurs peuvent aussi lier un check requis à la GitHub App censée le produire. En mode strict, la branche doit être à jour avant merge ; le mode souple évalue le check requis sans cette obligation de mise à jour.

GitHub applique l’état et la source attendue configurés dans la politique de branche. Le responsable du repository doit s’assurer que les états acceptés de cette source ont le sens que l’équipe leur attribue. Un état sauté ou neutre peut satisfaire une règle de check requis sans fournir de review terminée.

Un score structurel parfait peut coexister avec un contrôle en échec

Sur une révision épinglée du cours de harness engineering de Walkinglabs, j’ai reproduit 3 cas le 26 septembre 2026. Le compte rendu d’évaluation liste les fixtures et runtimes. Un repository généré dont la commande de vérification était false a reçu 100/100 de l’évaluateur structurel. Une fixture shell distincte a réussi 7 contrôles critiques sur 7 et obtenu 9/71 au total, parce que les 2 outils comptent des choses différentes. Dans le code du cours sur maker-checker, étiqueté comme placeholder, le vérificateur lit l’approbation avec "approved" in review ; une review disant not approved passe donc. Aucun merge réel n’a été effectué.

Le cours est un support pédagogique et ces cas ne disent rien de la fréquence de tels défauts ailleurs. Ils montrent pourquoi le consommateur d’un verdict a besoin de ses propres tests d’échec. Un inventaire de fichiers indique si les composants attendus existent. L’acceptation exige encore un résultat exécuté, la révision pertinente, un producteur reconnu et l’autorité attribuée par la politique du repository.

Une réussite fonctionnelle peut encore ne pas respecter une contrainte de review

SWE-Gate extrait des contraintes de vrais commentaires de review de pull requests et synthétise 303 tâches de réparation dans 75 repositories Python, chacune avec des tests fonctionnels et de contraintes séparés. Un contrôle d’acceptation exige la même séparation, en testant à la fois la correction du bug et le comportement de compatibilité ou d’erreur qu’un reviewer demanderait. Le résultat du benchmark n’est pas une estimation du taux d’échec des PR de production.

Une preuve de review exige 5 attributs

Avant d’utiliser une review automatisée dans une décision de merge, établissez :

1. Identité du fournisseur. Quelle GitHub App, quel workflow, quelle CLI ou quel humain a produit l’enregistrement ?
2. SHA du commit. La review couvre-t-elle la tête actuelle, pas une révision antérieure ?
3. Périmètre et couverture. Quels fichiers, lots ou règles ont réellement été évalués, et lesquels ont été exclus ?
4. État d’exécution. La procédure s’est-elle terminée, a-t-elle échoué, été interrompue, dépassé le délai imparti ou fini dans un état inconnu ?
5. Publication de la sortie. Les constats normalisés ou le résultat explicitement sans constat ont-ils été joints à la pull request ou à un artefact conservé ?

Les 5 sont requis pour un enregistrement exploitable. Aucun ne prouve que le code est correct. Ils prouvent seulement qu’une procédure nommée s’est terminée sur une révision nommée, dans un périmètre déclaré, et a exposé son résultat.

Lier le résultat avant le début de la review

Considérons un scénario de concurrence : le contrôleur lance une review de la révision R1, un nouveau push crée R2, puis le reviewer termine. Son résultat couvre toujours R1. Lire la tête actuelle à la fin et étiqueter le résultat R2 inventerait une couverture que le reviewer n’a jamais eue.

Au lancement, figez le repository, les révisions de base et de tête, l’identité du reviewer, ainsi que les versions ou empreintes de la procédure et de la configuration chargée. Conservez ces liens avec la sortie. Vérifiez à nouveau la révision actuelle lorsque vous consommez l’enregistrement ; ne réécrivez pas son lien original. Gardez le résultat R1 comme historique et collectez des preuves pour R2. Ne réutilisez que ce qu’une évaluation explicite établit comme non affecté par la modification.

La même règle s’applique si la configuration du reviewer change pendant une exécution. Une nouvelle version du prompt ne décrit pas rétroactivement la procédure qui a produit l’ancien résultat.

Le guide de livraison de Pstack explicite cette frontière : un autre agent que l’auteur vérifie chaque modification sur la surface visible par l’utilisateur, et un ancien verdict est réexaminé quand le patch change. Il utilise git patch-id dans cette évaluation. L’identité du patch seule n’établit pas un comportement inchangé sur une nouvelle base ; les contrôles d’intégration ci-dessous s’appliquent donc encore. C’est une procédure de livraison documentée, pas la preuve que la politique de branche l’impose ou qu’une vérification précise a été exécutée.

Une politique de branche générique peut laisser la review consultative

Supposons un repository illustratif exigeant tests et secret-scan avant merge. Un fichier de configuration de reviewer est aussi présent, mais la politique de branche n’exige pas son résultat. Des checks requis réussis peuvent satisfaire cette politique tandis que l’exécution du reviewer reste UNKNOWN. Le fichier de configuration seul n’établit ni installation, ni exécution, ni autorité sur le merge.

Inspectez séparément la politique de branche effective et une exécution réellement terminée. Un commentaire indiquant que la review a été sautée ne peut pas remplacer cette dernière. Cet exemple décrit une configuration possible, pas l’état audité du repository d’un client ni une affirmation sur le comportement actuel d’un fournisseur.

Exécution, résultat et effet sur le merge sont des colonnes distinctes

Un workflow peut choisir de rester vert quand un reviewer consultatif est indisponible. Ce choix peut être raisonnable, car une panne de service n’a pas à arrêter toute modification à faible risque. L’erreur est de publier ce parcours dégradé comme si la review s’était terminée.

Pour les lignes de reviewers, le tableau reprend les états d’exécution, résultats et causes d’arrêt définis dans la partie 3. La ligne de test déterministe décrit un résultat de contrôle séparé : un test peut terminer son exécution et échouer sur son assertion sans produire de résultat de reviewer.

Les états sauté et neutre exigent le même examen. GitHub accepte les deux pour un check requis, et aucun ne prouve qu’une review a été exécutée.

L’action suivante relève de 3 groupes. Décision possible signifie que les preuves requises sont exploitables et que les constats ont reçu les décisions demandées par la politique ; cela ne signifie pas merge automatique. Correction requise signifie qu’un défaut confirmé exige une modification et une nouvelle évaluation des preuves. Preuves incomplètes signifie que le contrôleur doit récupérer les preuves manquantes ou escalader. Il ne doit pas demander à l’auteur de réparer du code simplement parce qu’une review a expiré.

Le statut montré aux utilisateurs doit préserver l’état de review et l’effet sur le merge. Advisory reviewer unavailable; deterministic checks passed est exact. Review passed ne l’est pas.

Le repository mesuré dans la partie 7 suit ce schéma. Son check de review IA reste vert par conception, son résumé indique que la review est consultative et ne décide jamais de la possibilité de merger, et un avertissement nomme une review indisponible ou incomplète, tandis que la CI déterministe décide seule.

Refuser par défaut à la mesure des preuves

Les contrôles déterministes aux comportements d’échec stables sont de bons candidats aux checks requis. Tests, vérifications de types, scanners de secrets et validateurs de politiques peuvent bloquer lorsque leurs assertions explicites échouent ou que leur sortie est invalide.

Un reviewer LLM a d’autres modes d’échec. Il peut émettre des faux positifs, omettre des défauts, être en désaccord avec un autre reviewer ou ne pas pouvoir inspecter le contexte requis. Faire de chaque constat du modèle un arrêt automatique peut transférer l’autorité à un classificateur non calibré et encourager les contournements quand le bruit augmente.

Utilisez une décision en 2 étapes :

1. Le reviewer publie des constats structurés et un état d’exécution explicite pour la tête actuelle.
2. Une politique déterministe vérifie si l’exécution est exploitable et si chaque constat d’une classe bloquante configurée a reçu une décision enregistrée d’un humain autorisé.

Si la disponibilité de la review est obligatoire pour une classe de risque, bloquez le merge des modifications de cette classe pour tout état d’exécution autre que COMPLETED. Si le reviewer est consultatif, laissez le parcours de merge continuer en montrant l’état dégradé. Ne rapportez jamais une indisponibilité comme un contrôle réussi.

Vérifier la combinaison qui sera intégrée

Une review de la tête actuelle est une preuve nécessaire pour cette PR, mais ne couvre pas toutes les interactions avec d’autres modifications. Consignez la révision de base, la base de merge, la révision candidate d’intégration et l’ensemble exact des révisions de PR testées ensemble. Lorsque la base ou cet ensemble change, invalidez le résultat d’intégration précédent et relancez les contrôles et la classification de risque affectés. Réutiliser une review individuelle exige une évaluation explicite de ce qui reste non affecté.

Dans un exemple construit, une PR change un producteur de données et une autre son consommateur. Les deux passent les contrôles sur l’ancienne base, mais divergent sur le sens d’un champ une fois combinées. Tester une branche combinée temporaire couvre cet état enregistré ; merger ensuite les PR séparément peut produire un état différent.

Plan-execute : exécuter plus de 20 agents sur une migration illustre cette règle avec 24 branches d’agents. Sa migration est un exemple construit, pas une exécution enregistrée : le coordinateur merge les branches prêtes une par une et relance le contrôle qualité après chaque merge, parce qu’une branche qui passait seule peut encore casser le build après l’arrivée des autres.

Un check d’intégration peut aussi avoir une sémantique plus étroite que son nom le suggère. La documentation GitHub de CodeRabbit, vérifiée le 14 octobre 2026, indique qu’il publie un check pour le commit synthétique du groupe de merge sans relancer la review. Ce check ne démontre donc pas que la modification combinée a reçu une nouvelle review du modèle. Inspectez séparément les tests d’intégration et la couverture de review.

Les files de merge GitHub exécutent les checks requis sur un groupe de merge temporaire qui inclut la branche cible et les modifications en file. La CI doit gérer ce groupe, notamment l’événement merge_group avec GitHub Actions. Un check vert sur la PR seule n’établit pas cette couverture d’intégration. Ces contrôles ne couvrent encore que leurs propriétés encodées ; la responsabilité des comportements sensibles reste une partie de la politique de review.

Tester le contrôle dans les deux sens

Un exemple adjacent inspectable est Agents Shipgate, dont la documentation, vérifiée le 14 octobre 2026, limite le verdict aux changements détectables par analyse statique dans les capacités des agents. Son mode consultatif peut terminer avec succès tout en rapportant une modification bloquée ; bloquer la CI exige une politique explicite. La release publiée distingue aussi les fixtures construites de sa qualification incomplète sur un historique réel. Cela illustre pourquoi le rapport, le code de sortie et la règle de merge installée exigent des contrôles séparés. Cela n’établit ni les permissions à l’exécution ni la justesse d’une PR applicative ordinaire, et je ne l’ai pas exécuté pour cet article.

L’étude de 246 repositories de harnais pour Marmelab par François Zaninotto recommande de tester les cas où un comportement doit se produire et ceux où il ne doit pas. Pour cette politique de review, voici des fixtures proposées, pas des résultats GitHub enregistrés :

Exécutez la fixture autorisée ainsi que celles qui sont rejetées. Une politique qui bloque toute modification peut réussir une suite composée seulement de tests négatifs. Vérifiez la décision de branche configurée séparément du parseur : une bonne décision locale ne prouve pas que GitHub l’exige.

Vérifier la tête actuelle avant merge

Exécutez cette checklist après le dernier push :

• Consigner le repository, le SHA de base et le SHA de tête actuel
• Lister chaque check requis et sa GitHub App source attendue
• Confirmer que chaque résultat requis est rattaché à la tête actuelle
• Distinguer les conclusions réussies, sautées, neutres, échouées, annulées et expirées
• Pour chaque reviewer IA, vérifier l’identité du fournisseur, le SHA couvert, le périmètre déclaré, l’état d’exécution et la sortie publiée
• Marquer les preuves de review manquantes ou périmées UNKNOWN
• Confirmer que tous les constats bloquants ont reçu une décision et ont un responsable nommé
• Consigner qui, ou quelle politique, a autorité sur le merge
• Relancer la checklist si la tête change

Une capture d’écran de checks verts ne suffit pas. Conservez la réponse API ou l’artefact d’audit qui lie noms, sources, conclusions et SHA à la règle de branche inspectée à ce moment-là.

Pas encore démontré : hormis le check consultatif observé dans la partie 7, les exemples ci-dessus sont construits. Avant d’affirmer que ce contrôle fonctionne dans un repository, conservez un graphe daté des checks, la règle de branche effective, une review terminée liée à ses entrées, et des fixtures d’intégration autorisées et rejetées, y compris un push pendant la review.

La partie 5, Transformer les commentaires de review récurrents en contrôles testés, traite un autre échec : un retour de review peut être valide et arriver à temps, mais se répéter parce qu’aucun contrôle durable ne l’absorbe.

---

YSNK

(Vous devriez maintenant savoir)

• Un commentaire, une exécution de workflow, un check et un check requis sont des objets différents
• Une preuve de review exploitable exige fournisseur, SHA, périmètre, état d’exécution et publication
• Une review d’une révision antérieure reste une preuve historique après un nouveau push
• L’échec consultatif doit rester visible sans se faire passer pour une review réussie
• Chaque décision de merge doit être recalculée pour la tête actuelle