AI-Codereview-Gitlab : brancher une revue de code LLM sur vos Merge Requests

Le problème : la revue arrive après la fusion

GitLab déclenche un webhook quand on pousse du code, mais il ne lit pas le code à votre place. Le README résume l'ambition en une phrase : « 帮助开发团队在代码合并或提交时，快速进行智能化的审查 ». Autrement dit, l'outil s'insère au moment où la décision de fusionner se prend, pas après. C'est ce positionnement qui le distingue d'un linter : un linter applique des règles écrites à l'avance, ici le modèle juge le diff et rédige un commentaire en langage naturel. Le public visé est une équipe qui utilise GitLab en self-hosted, avec un ou plusieurs dépôts actifs, et qui veut un retour automatique sans écrire de règles. Le projet est en Python, sous Apache-2.0, et la dernière version publiée listée est la 1.5.1 (juin 2026).

Ce qui se passe entre le webhook et la note

Le README décrit un flux court. L'URL à renseigner dans GitLab est http://{your-server-ip}:5001/review/webhook, avec les événements Push Events et Merge Request Events cochés, et rien d'autre. Le service reçoit l'événement, extrait le diff, l'envoie au fournisseur LLM configuré, puis republie le résultat dans la note de la Merge Request ou du commit concerné. La documentation précise la priorité du jeton : le GITLAB_ACCESS_TOKEN de conf/.env est utilisé en premier, et le Secret Token transmis par le webhook ne sert que si la variable est absente. C'est un détail d'exploitation qui compte, parce qu'un jeton de projet mal choisi peut limiter la portée des commentaires publiés. Le rendu final est visible dans les captures fournies (mr.png, note.jpg), mais je ne les ai pas ouvertes : je ne peux donc pas décrire la mise en forme exacte des commentaires.

Le mode agentic, ses garde-fous et sa facture

C'est la partie qui sort du lot. La variable REVIEW_STRATEGY accepte deux valeurs. diff_only, la valeur par défaut, analyse uniquement le diff. agentic donne au modèle des outils : read_file et un shell en sandbox, ce qui lui permet d'explorer un clone local du dépôt avant de conclure. Le README annonce trois protections sur le shell : liste blanche et liste noire de commandes, vérification des chemins hors périmètre, et un délai d'expiration de 30 secondes. Par défaut, seules des commandes de lecture sont autorisées (ls, cat, grep, find, git log). Les listes se modifient via AGENT_SHELL_ALLOWLIST et AGENT_SHELL_BLOCKLIST. Deux réglages accompagnent le mode : REPO_CACHE_DIR (par défaut data/repo_cache/) et AGENT_MAX_ITERATIONS (20 par défaut). Le point de conception que je trouve le plus solide est ailleurs : si le clone, le fetch, l'appel LLM ou un outil échoue, le système retombe automatiquement sur diff_only. Une revue dégradée reste donc produite, jamais rien. La documentation chiffre le prix de ce confort : 10 Mo à 2 Go par projet cloné, au moins 50 Go de disque conseillés, environ 500 Mo de mémoire au pic par session, 5 000 à 50 000 tokens par revue (3 à 10 fois diff_only) et 30 secondes à 5 minutes de latence. Ce ne sont pas des chiffres que j'ai mesurés : ils viennent du README.

Démarrage : deux chemins, une seule configuration

En Docker, la séquence du README tient en trois commandes : git clone du dépôt, cp conf/.env.dist conf/.env, puis docker-compose up -d. La vérification se fait sur deux ports : http://your-server-ip:5001 doit répondre « The code review server is running. » et http://your-server-ip:5002 doit afficher le Dashboard. En local, il faut Python 3.10 ou plus, pip install -r requirements.txt, puis deux processus séparés : python api.py d'un côté, streamlit run ui.py --server.port=5002 --server.address=0.0.0.0 de l'autre. Les clés du fichier .env qui déterminent le comportement sont LLM_PROVIDER (zhipuai, openai, deepseek ou ollama), la clé API correspondante comme DEEPSEEK_API_KEY, SUPPORTED_EXTENSIONS et GITLAB_ACCESS_TOKEN. Le README donne un exemple explicite : SUPPORTED_EXTENSIONS=.java,.py,.php,.yml,.vue,.go,.c,.cpp,.h,.js,.css,.md,.sql. La mention « 未配置的文件类型不会被审查 » est à prendre au sens strict : tout ce qui n'est pas listé passe sous le radar, sans avertissement. Une équipe qui versionne du Terraform en .tf et oublie de l'ajouter n'aura aucune revue sur ces fichiers, et rien ne le lui signalera.

Les styles de revue, entre outil et gadget

Le README propose quatre tons : 专业型, 讽刺型, 绅士型 et 幽默型, avec des exemples de commentaires sarcastiques ou humoristiques. C'est un choix assumé, et il faut le prendre au sérieux dans les deux sens. Dans une petite équipe qui accepte l'ironie, un commentaire acerbe peut être lu. Dans un contexte où les revues servent de trace écrite, ou dans une organisation où les échanges sont archivés, publier automatiquement une remarque du type « 这段 if-else 比我的相亲经历还曲折 » dans une note de Merge Request est un risque social, pas un détail de configuration. Je n'ai pas trouvé dans le matériel fourni d'indication sur le style par défaut ni sur la façon de le changer par projet. C'est une lacune de documentation réelle : avant d'activer la revue sur un dépôt partagé, il faut la tester sur un dépôt personnel pour voir ce que le modèle produit avec le style retenu.

Push IM et Dashboard : la partie qui vieillit le plus vite

Les notifications passent par des webhooks de groupe. Pour DingTalk, il faut créer un robot personnalisé dans le groupe, récupérer son URL, puis renseigner DINGTALK_ENABLED=1 et DINGTALK_WEBHOOK_URL. WeCom et Feishu suivent le même schéma, avec les détails renvoyés à doc/faq.md, que je n'ai pas. Le Dashboard Streamlit affiche l'historique des revues ainsi que des statistiques par projet et par développeur. Le README vend aussi un générateur de rapport quotidien à partir des commits GitLab, GitHub et Gitea. Ce dernier point mérite un avertissement : chaque fournisseur de messagerie fait évoluer ses webhooks et ses limites de débit, et chaque API GitLab évolue aussi. Ces intégrations sont la surface la plus susceptible de casser lors d'une mise à jour, et le coût de maintenance se concentre là, pas dans le cœur de la revue.

Ce que le projet ne fait pas, et à quoi le comparer

Trois limites ressortent du matériel. D'abord, la revue est déclenchée par webhook : sans accès réseau entrant depuis GitLab vers le service, rien ne fonctionne, et le README le dit lui-même en conseillant un déploiement sur un serveur exposé si le réseau interne est contraint. Ensuite, le périmètre est GitLab, plus GitHub et Gitea pour les commits du rapport quotidien, mais pas pour la revue elle-même d'après ce que décrit le README. Enfin, le mode agentic suppose de cloner les dépôts et de faire tourner un shell, même restreint : sur une instance GitLab centrale avec des dizaines de dépôts, la consommation de disque et de tokens devient le facteur limitant, pas la qualité du modèle. Comme alternative, il faut regarder du côté des analyseurs statiques exécutés en CI, par exemple un job qui lance un linter ou un outil d'analyse de flux dans le pipeline. La différence d'approche est nette : un linter produit un résultat déterministe, reproductible et gratuit à l'exécution, mais il ne détecte que ce pour quoi ses règles ont été écrites, et il ne rédige pas de commentaire contextuel. Ici, le modèle peut repérer une incohérence de logique qu'aucune règle n'exprimerait, au prix d'un résultat variable, d'un coût par revue et d'une latence de plusieurs minutes en mode agentic. Les deux ne s'excluent pas : un linter en CI et cette revue en webhook couvrent des angles différents.

Licence, maintenance et ce qu'il faut vérifier avant d'adopter

Le dépôt est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec obligation de conserver les mentions de copyright et le texte de licence, et une clause de brevets. Le README renvoie par ailleurs vers une version Pro installable via un script curl et vers d'autres projets du même auteur (Entire Dashboard, Site Guard). Ce découpage open source / Pro est une donnée à intégrer : certaines fonctions peuvent rester du côté payant, et le README ne précise pas lesquelles. Sur la maintenance, le dépôt n'est pas archivé et la dernière version listée date de juin 2026, mais je ne dispose d'aucune information sur le rythme des correctifs, la couverture de tests ou la politique de compatibilité entre versions. Le coût de mise à jour se concentre sur trois zones : les API des fournisseurs LLM, les webhooks des messageries, et le schéma des événements GitLab. Avant de généraliser le déploiement, testez le mode agentic sur un dépôt de taille moyenne et relevez vous-même la consommation de tokens et le temps de réponse, plutôt que de vous fier aux fourchettes du README. Et si vous activez le shell, relisez AGENT_SHELL_ALLOWLIST avant d'élargir quoi que ce soit.

Conclusion éditoriale

À adopter si vous hébergez déjà GitLab, que vos diffs portent sur des fichiers texte et qu'un token par revue reste dans votre budget. À éviter si vous cherchez une revue multi-forges avec gestion fine des permissions, ou si vos dépôts dépassent la centaine de gigaoctets en mode agentic. Avant de déployer, vérifiez deux choses concrètes : que SUPPORTED_EXTENSIONS couvre bien vos extensions réelles, et que la variable GITLAB_ACCESS_TOKEN est renseignée dans conf/.env, puisque la documentation indique qu'elle prend le pas sur le Secret Token du webhook.

Sources officielles

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. sunmh207/AI-Codereview-Gitlab on GitHub