Utiliser la revue assistée par IA

Ce guide vous montre comment faire relire une pull request par des agents relecteurs, puis comment publier le résultat sur GitHub.

Lancer une revue IA

Ouvrez la PR et rendez-vous dans son onglet Aperçu
Ouvrez le menu ⋯ de la rangée d’actions et choisissez Ask AI

Cet élément n’apparaît que tant que la PR est ouverte — c’est une action d’avant-fusion. Le même bouton est proposé sous la forme Ask AI sur l’état vide de l’onglet Revue, avant qu’une revue n’existe.

Control Center démarre le pipeline pr_review fourni d’origine et ouvre l’onglet Revue de la PR pour que vous puissiez le suivre. Le pipeline :

Ouvre l’espace de revue propre à la PR, dont l’arbre de travail isolé contient la PR extraite à sa référence de tête
Déploie les relecteurs selon le niveau de revue de l’espace de travail — trois par défaut (les agents qa, architect et engineer fournis d’origine, en parallèle). Aucune détection de langage ni de domaine n’a lieu
Charge l’agent chef de file (le CEO) de consolider leurs remarques en un parcours
Finalise : trie les remarques en catégories de consensus et calcule le verdict. Quand l’association atteint awaiting approval, Publier sur GitHub apparaît dans l’onglet Revue

La profondeur de la revue relève du Niveau de revue de l’espace de travail — light (un relecteur), balanced (trois, la valeur par défaut) ou thorough (les cinq, en ajoutant les spécialistes sécurité et performance) —, défini dans Paramètres → Espace de travail → Général, sur la carte Règles de l’espace de travail. Un niveau plus léger consigne tout autant de remarques ; il en met simplement moins en avant.

Tous les relecteurs publient dans l’espace de revue unique de la PR, et c’est ce qui rend leurs remarques comparables. Voir Revue par IA pour comprendre comment les pièces s’assemblent.

pr_review n’est livré qu’avec un déclencheur manuel. Pour qu’il se lance à chaque PR publiée, ajoutez vous-même un déclencheur — voir Lancer des agents relecteurs. Vous pouvez aussi en démarrer une depuis GitHub même, sans déclencheur de pipeline : mentionnez le bot du serveur sur la PR ou ajoutez l’étiquette ai-review — voir Parler à Control Center depuis une PR GitHub.

Si une notification indique qu’une revue est déjà en cours pour cette pull request, c’est qu’une revue est déjà lancée ; restez dans l’onglet Revue ou ouvrez Pipelines pour la retrouver.

Lire les remarques

Les relecteurs consignent leurs remarques sous forme de nœuds de revue dans l’espace de revue. Chacun porte :

Champ	Description
Type	`bug`, `suggestion`, `recommendation`, `question` ou `ticket`
Priorité	P0 (critique) → P3 (détail)
Catégorie	`security`, `stability`, `data_integrity`, `correctness`, `performance` ou `maintainability`
Fichier et ligne	Où la remarque est ancrée
Code d’origine	Le code concerné par la remarque
Code suggéré	Le correctif proposé
Confiance	Le degré de confiance du relecteur
Statut	`open` → `consensus-ready` → `resolved` ou `dismissed`

Une remarque n’atteint consensus-ready qu’une fois confirmée par un relecteur pair. Un agent ne peut pas confirmer sa propre remarque, de sorte que l’avis d’un relecteur isolé n’est jamais validé à lui seul.

L’onglet Revue affiche la liste des remarques, filtrable par type et par statut, avec une bascule pour les remarques rejetées, à côté de l’artefact publié par l’agent de consolidation. La vue déterministe — cohortes, tableau de bord multi-axes, diffs de contrat et visuels — est calculée côté serveur, mais n’a aucune interface dans l’application ; voir Calcul de revue pour ce que produit cette passe.

Consulter le panneau des désaccords

Quand deux relecteurs ancrent des remarques au même fichier et à la même ligne mais les évaluent très différemment — des priorités séparées de deux niveaux ou plus, ou l’un qui parle de bug là où l’autre parle de suggestion —, un panneau de désaccord s’affiche au-dessus de la liste des remarques. Lisez-les en premier : c’est là que les avis des relecteurs divergent et que votre jugement compte le plus.

Lire le verdict

Quand l’agent chef de file finalise, il calcule un verdict :

Verdict	Signification
Ship	Rien de bloquant n’a été trouvé
Hold	Des problèmes à traiter avant la fusion
Block	Des problèmes critiques qui doivent être corrigés

Le verdict porte un score de confiance agrégé et un décompte des remarques par priorité.

Les axes de revue s’y ajoutent ensuite, et ils ne peuvent que le rendre plus sévère. Un axe soumis à verrou qui échoue force Block ; un axe soumis à verrou qui n’a pas pu aboutir (partial) ou qui n’a pas pu s’exécuter du tout (unavailable) force au moins Hold. L’absence de preuve ne lève jamais un verrou.

Publier la revue sur GitHub

La publication est une étape distincte, délibérément conditionnée par l’utilisateur. Le pipeline pr_review garde la revue dans Control Center ; il ne publie rien sur GitHub.

Dans l’onglet Revue, attendez que Publier sur GitHub apparaisse
Appuyez sur Publier sur GitHub

Control Center envoie une seule revue GitHub. Les remarques déjà résolues ou rejetées sont ignorées. Le bouton inclut toutes les remarques encore ouvertes et, sur Ship, soumet APPROVE. (L’outil MCP publish_review_to_github reste limité par défaut aux remarques confirmées par un pair et n’approuve pas, sauf si vous passez approve_on_ship.) Celles qui portent une ancre de fichier et de ligne deviennent des commentaires en ligne ; tout le reste est replié dans le corps du résumé, chacune avec une signature « — Control Center AI review » pour que la source soit sans ambiguïté. Un verdict Block est soumis comme REQUEST_CHANGES ; Hold comme COMMENT ; Ship comme APPROVE depuis ce bouton. Une notification affiche alors Publié. La revue est publiée sous l’identité applicative du serveur.

Si GitHub rejette une ancre en ligne parce que la ligne ne fait pas partie du diff, toute la revue est renvoyée avec chaque remarque repliée dans le corps, pour que rien ne disparaisse en silence.

D’autres pipelines intégrés publient, eux, directement sur GitHub : cross_review, pr_triage, ticket_to_pr et pre_merge_gate se terminent chacun par une étape de commentaire. Seul pr_review retient sa sortie à votre intention.

Lancer les relecteurs vous-même

Pour maîtriser quels rôles relisent la PR et quels fichiers chacun examine, utilisez l’outil MCP dispatch_reviewers dans un espace de revue existant, ou ajoutez des nœuds relecteurs à un pipeline. Les deux approches, avec la signature exacte de l’outil, sont décrites dans Lancer des agents relecteurs.