Un bot d’examen de demandes de fusion open source : LangGraph, Node.js et GitHub Webhooks

Les demandes de fusion s’accumulent dans presque toutes les équipes. Les ingénieurs seniors sont généralement les seuls à détecter les problèmes subtils : la requête N+1, le secret codé en dur, les cas limites non traités. Ce sont aussi les personnes les plus occupées, ce qui fait que les revues sont accélérées ou reportées, et dans un cas comme dans l’autre, quelque chose finit par passer.

Les outils de revue d’IA commerciaux sont souvent à source fermée ou chers, voire les deux à la fois. Une alternative consiste en un bot que une petite équipe peut mettre en œuvre sur ses propres dépôts, sans envoyer de code dans une boîte noire. La conception présentée ci-dessous est un bot open source qui surveille les nouvelles demandes de fusion sur GitHub, examine chacune d’elles à l’aide d’un agent LangGraph en plusieurs étapes et publie des retours précis au niveau de chaque ligne sous forme de commentaire sur la PR.

Que se passe-t-il lorsqu’une PR est ouverte

1. Un webhook GitHub transmet l’événement.
2. L’API GitHub, via Octokit, récupère la différence de code.

Un agent LangGraph examine l’étape par étape pour détecter des problèmes de sécurité, des problèmes de performance et des défis architecturaux.

Le bot publie un commentaire sur la PR contenant des retours qui ciblent des lignes spécifiques.

La revue est enregistrée dans une base de données, ce qui permet d’accumuler l’historique au fil du temps.

C’est l’approche étape par étape qui est essentielle. Une demande adressée à un LLM pour qu’il « examine ce code » donne généralement des commentaires vagues et génériques. En divisant la tâche en une vérification de sécurité, une vérification de performance et une vérification architecturale, on obtient des résultats plus précis, car chaque étape a une responsabilité bien définie.

La stack technologique

Base de données PostgreSQL pour l’historique des revues Intégration GitHub Octokit Webhooks Middleware Express avec vérification de signature

Cette stack reste proche de celle que la plupart des équipes Node.js utilisent déjà. Montrer un nouveau framework n’était pas l’objectif ; il s’agissait plutôt de quelque chose que les équipes puissent héberger et en qui elles aient confiance.

Flux et structure

Le pipeline démarre avec l’ouverture d’une PR, passe par un webhook vérifié pour atteindre l’agent, puis revient sous forme de commentaire :

GitHub PR opened
        │
        ▼
 Webhook (signed, verified)
        │
        ▼
 Express API ──► Fetch diff (Octokit)
        │
        ▼
 LangGraph Agent
   ├── Security check
   ├── Performance check
   └── Architecture check
        │
        ▼
 Post PR comment + save to PostgreSQL

Chaque vérification dans le flux LangGraph constitue un nœud distinct. Une équipe peut tester, ajuster ou désactiver une vérification sans affecter les autres, ce qui est utile lorsque seules les conclusions en matière de sécurité importent et que l’on ne souhaite pas de commentaires sur l’architecture pour chaque demande de modification.

Deux exemples de code à présenter

Tout d’abord, la vérification de la signature du webhook. Sans elle, quiconque connaît l’URL du webhook pourrait envoyer des événements falsifiés et déclencher des revues fictives :

function verifySignature(payload: string, signature: string) {
  const hmac = crypto.createHmac("sha256", process.env.GITHUB_WEBHOOK_SECRET!);
  const digest = "sha256=" + hmac.update(payload).digest("hex");
  return crypto.timingSafeEqual(Buffer.from(digest), Buffer.from(signature));
}

C’est minuscule, pourtant l’oublier est une erreur fréquente dans les outils basés sur des webhook.

Deuxièmement, le flux LangGraph est constitué de nœuds distincts plutôt que d’une seule instruction longue :

const graph = new StateGraph(ReviewState)
  .addNode("security", securityCheckNode)
  .addNode("performance", performanceCheckNode)
  .addNode("architecture", architectureCheckNode)
  .addEdge("security", "performance")
  .addEdge("performance", "architecture");

Chaque nœud reçoit la différence et ne renvoie que ses propres résultats, qui sont ensuite fusionnés en un seul commentaire. Cela facilite le débogage. Si la vérification des performances renvoie des résultats étranges, il suffit d’examiner un seul nœud, plutôt qu’un prompt gigantesque.

Ce qui a fonctionné

• Diviser l’analyse en vérifications distinctes concernant la sécurité, les performances et l’architecture a permis d’obtenir des retours clairement plus pertinents et spécifiques qu’avec un prompt combiné. C’était l’amélioration de qualité la plus significative dans tout le projet.
• Vérifier les signatures des webhook dès le début a signifié que la sécurité faisait partie de la conception, et non quelque chose ajouté ultérieurement.
• Conserver l’historique des analyses dans PostgreSQL, même sous une forme simple, a permis de mettre en évidence des schémas par la suite, tels que les types d’erreurs qui réapparaissaient constamment dans les PR.

Ce qui est resté difficile

• Les faux positifs font partie inévitable du processus. Les analyses basées sur des LLM signalent parfois des éléments qui ne constituent pas de problèmes, et les documents devraient l’indiquer clairement. La confiance compte plus qu’une liste de fonctionnalités impressionnante.
• Le coût s’accumule. Trois appels aux LLM par demande de modification sont plus précis qu’un seul, mais ils coûtent plus cher et prennent plus de temps. Une petite équipe doit trouver un équilibre entre la qualité de l’analyse et le budget qu’elle peut se permettre.
• Rendre les commentaires semblables à ceux écrits par une personne a nécessité plus d’itérations sur les prompts que la logique de LangGraph. Les commentaires doivent être courts, précis et référencer un numéro de ligne, car personne ne lit un essai d’IA de cinq paragraphes dans une discussion de modification.

Ce bot fait partie d’une série de petits projets open source qui appliquent l’orchestration des LLM avec LangChain et LangGraph à des problèmes concrets de flux de travail, tels que les questions-réponses sur des documents via RAG, les questions-réponses relatives aux politiques pour les services destinés aux citoyens, ou encore la transformation de notes vocales en histoires d’utilisateur Agile, plutôt que de créer des démos génériques. Il ne s’agit pas d’un produit final prêt à être déployé n’importe où. C’est un point de départ fonctionnel sur lequel une équipe peut s’appuyer pour l’adapter à ses propres besoins.

L’essayer localement

Le répertoire est facile à exécuter. Clonez-le, installez les dépendances et lancez le serveur de développement :

git clone https://github.com/Srameshgitnow/agentic-code-reviewer.git
cd agentic-code-reviewer
npm install
npm run dev

Le README décrit en détail l’installation complète, les variables d’environnement ainsi que la manière de connecter le webhook GitHub. Les retours concernant des faux positifs ou des idées pour l’algorithme LangGraph sont les types de rapports les plus utiles.