Scaffolder
D'un ticket GitLab à une merge request relue
Deux commentaires sur un ticket pilotent tout le parcours. /spec demande à un agent
de publier un plan d'implémentation. /code lui demande d'écrire la modification,
de lancer les tests, de corriger ce qui échoue et d'ouvrir une merge request. Un second agent
relit cette merge request. Un humain valide le plan et fusionne — aucune étape ne s'en
passe. Un n8n auto-hébergé planifie, sérialise et rend compte de chaque exécution.
Il tourne en production sur gitlab.com pour nos propres dépôts.
La boucle
Un ticket, sept étapes. Trois d'entre elles sont des décisions humaines.
Un ticket
Un ticket GitLab ordinaire décrit la modification. Rien de particulier.
Plan
/specVous décidezUn commentaire
/spec, avec des notes facultatives, demande à l'agent de lire le dépôt et de publier un plan sur le ticket : les fichiers à modifier, l'approche et le plan de test. Pas satisfait ? Commentez/specà nouveau ; le dernier plan l'emporte.Construction
/codeVous décidezQuand le plan est bon,
/codelance la construction. L'agent écrit la modification sur sa propre branche en suivant le plan validé.Tester et corriger
La commande de test du projet s'exécute. Quand un test échoue, l'agent lit la sortie et corrige le code, jusqu'à trois tentatives. Si les tests échouent encore, le ticket reçoit un commentaire avec un extrait du journal au lieu d'une merge request.
Merge request
Des tests au vert poussent la branche et ouvrent une merge request qui ferme le ticket. Le lien est publié sur le ticket.
Revue IA
Un agent de revue distinct prend en charge les nouvelles merge requests en quelques minutes. Il publie des commentaires en ligne et un verdict sur la justesse, la sécurité et le style. Une revue approfondie avec un modèle plus grand est disponible à la demande.
Fusion
Vous décidezUn humain lit la modification et la revue, puis fusionne. Rien ne fusionne tout seul.
Ce qu'il fait
Deux commandes, aucun nouvel outil
Tout se passe dans les commentaires des tickets et merge requests GitLab que votre équipe utilise déjà. Un petit formulaire web publie les mêmes commandes depuis un téléphone.
Les tests décident, pas le modèle
Le code doit passer la commande de test du projet avant qu'une merge request existe. Pour les dépôts dont les tests ont besoin d'une base de données ou d'autres services, les tests tournent dans GitLab CI.
Écrit par un agent, relu par un autre
Le relecteur est un agent distinct avec son propre prompt : une passe rapide sur chaque nouvelle merge request, une passe approfondie à la demande. Les très gros diffs sont marqués comme ignorés, pas relus à moitié.
Sur vos propres runners
Les agents tournent dans des conteneurs sur votre propre hôte ou sur des runners GitLab auto-hébergés, en sortant uniquement. Les secrets arrivent aux conteneurs par nom de variable, jamais dans les définitions de workflow ni dans les journaux. Une seule tâche lourde à la fois.
Comment il est construit
Deux agents et un orchestrateur. L'agent de construction est écrit en Python, avec LangGraph pour les étapes et Claude Code en mode headless pour l'écriture. L'agent de code est interchangeable : Claude Code par défaut, OpenCode ou Codex CLI si votre organisation travaille avec d'autres modèles. Le relecteur est un second agent. n8n les relie. Le panneau de contrôle n'est pas joignable depuis Internet : il interroge GitLab au lieu de recevoir des webhooks, et des réactions et labels sur GitLab indiquent ce qui est pris en charge, terminé ou en échec — sans base de données supplémentaire.
- Interroger GitLabnouvelles commandes et merge requests
- Choisir une voieconteneur local ou GitLab CI
- Lancer l'agentplanifier, coder, tester, corriger
- Rendre comptecommentaire, notification push, tableau de bord
Voie locale
L'agent tourne dans un conteneur sur l'hôte. Le dépôt cible ne demande aucune configuration. Idéal pour les projets dont les tests n'ont besoin que du code.
Voie CI
n8n déclenche un pipeline GitLab et le suit jusqu'au bout. Les dépôts dont les tests ont besoin de Postgres ou d'autres services utilisent la CI qui exécute déjà ces tests.
Ce qui le distingue de Claude dans GitLab
L'agent Claude Code de GitLab et l'intégration GitLab CI/CD d'Anthropic transforment une mention en une modification. Scaffolder ajoute un plan que vous validez avant toute ligne de code, une boucle de tests, un relecteur distinct et un seul planificateur pour l'ensemble. Il fonctionne aussi sur n'importe quel GitLab, y compris une Community Edition auto-hébergée sur vos propres serveurs, sans licence Premium ou Ultimate.
Ce qui quitte votre infrastructure
Le contexte du prompt, y compris le code source que l'agent lit, part chez le fournisseur du modèle. C'est le prix d'un modèle hébergé. Avec OpenCode et un modèle auto-hébergé (Ollama, vLLM ou llama.cpp), même cela reste chez vous. L'orchestration, le dépôt de référence, les secrets et les journaux restent sur votre propre infrastructure, et rien n'est ouvert au trafic entrant. Po11y, Prometheus et Grafana sur le même hôte montrent chaque exécution.
Nous construisons cette boucle pour votre équipe
Scaffolder tourne en production sur gitlab.com. Nous le construisons volontiers pour votre organisation sur la plateforme Git que vous utilisez déjà : GitLab (gitlab.com ou auto-hébergé), GitHub (github.com ou Enterprise Server), Atlassian Bitbucket (Cloud ou Data Center), Azure DevOps, Gitea ou Forgejo. Nous l'installons sur vos runners, adaptons les prompts de plan et de revue à votre code et à vos conventions, et montrons à vos développeurs comment écrire des tickets qu'un agent peut construire. Parlez-nous de vos dépôts.
Nous contacter