GitLab a Automatisé l'Intégralité du Cycle de Merge Request avec Developer Flow

Avec GitLab 19.0, l'agent IA Developer Flow ne se limite plus à l'écriture de code — il gère désormais tout le cycle de vie de la merge request : du traitement des remarques du relecteur et de la résolution des conflits de fusion jusqu'à la fusion finale. C'est l'étape suivante après le lancement de Developer Flow l'année dernière, qui ne savait alors que transformer une issue en MR prête.

Ce qui a changé dans GitLab 19.0

Selon le blog de GitLab, jusqu'à présent l'IA ne faisait qu'accélérer l'écriture du code, tandis que tout le travail entre l'ouverture d'une merge request et sa fusion restait manuel : désigner les relecteurs, traiter les retours round après round, démêler les conflits, effectuer un rebase avant la fusion — chaque étape exigeait l'attention du développeur. Le goulot d'étranglement s'est simplement déplacé, sans que les outils ne s'y adaptent.

Developer Flow avait été lancé l'année dernière et ne résolvait qu'une seule tâche — transformer une issue en merge request, en automatisant le travail préparatoire routinier entre la définition de la tâche et l'apparition du MR en relecture. Mais une fois le MR créé, le travail itératif qui suivait restait entièrement manuel.

La nouvelle version de Developer Flow comble précisément cette lacune : le même agent IA traite désormais les retours des relecteurs, élimine les conflits dans les branches à longue durée de vie, se repère dans du code inconnu et découpe en plusieurs parties les MR devenues trop volumineuses — le tout associé à une résolution autonome des conflits de fusion et à une fonction de rebase-et-fusion en un clic.

Comment l'agent s'intègre au travail sur une MR

Developer Flow peut être lancé à n'importe quelle étape du travail sur une tâche. Il existe trois points d'entrée : le bouton Generate MR directement sur l'issue, l'attribution du compte de service Duo Developer directement à l'issue ou à la MR, ou encore un nouveau déclencheur via une mention @ dans n'importe quel fil de discussion sur l'issue ou la merge request.

La différence clé par rapport à la version précédente est que l'agent reprend la conversation et poursuit le travail sur la même MR, au lieu d'en créer une nouvelle qu'il faudrait ensuite relire manuellement depuis le début. Combiné à la résolution autonome des conflits de fusion et à la fonction de rebase-et-fusion en un clic, cela réduit le volume de travail manuel sur toute la période entre l'ouverture de la MR et sa fusion finale.

Une nouvelle catégorie d'outils IA pour le développement

GitLab décrit Developer Flow comme faisant partie d'une nouvelle catégorie, encore en formation, d'outils IA pour le code. La première vague de ces outils accélérait l'écriture de la ligne de code suivante (autocomplétion), la seconde a offert aux développeurs une fenêtre de chat pour poser des questions. Ce qui apparaît aujourd'hui est fondamentalement différent : des agents qui participent au travail tout au long de son déroulement, et non à un moment fixe isolé.

Selon la formulation de GitLab, les développeurs peuvent désormais rester «au-dessus de la boucle» — déléguer des tâches et vérifier le résultat, pendant que l'agent s'occupe de l'exécution proprement dite : relectures, conflits, refactorisation des MR trop volumineuses et exploration de zones inconnues de la base de code.

Qu'est-ce que Developer Flow dans GitLab 19.0 ?

Developer Flow est l'agent IA de GitLab qui, dans la version 19.0, a étendu son périmètre de responsabilité de la création d'une merge request à l'ensemble de son cycle de vie : traitement des retours des relecteurs, résolution des conflits de fusion sur des branches à longue durée de vie, exploration de code inconnu et découpage des MR trop volumineuses en plusieurs parties. Il fonctionne en association avec la résolution autonome des conflits et le rebase-et-fusion en un clic.

En quoi la nouvelle version de

Developer Flow diffère-t-elle de celle de l'année dernière ?

Le lancement de Developer Flow l'année dernière n'automatisait qu'une seule étape — transformer une issue en merge request, c'est-à-dire la préparation routinière entre la définition de la tâche et l'apparition du MR en relecture. Le travail ultérieur sur un MR déjà créé restait entièrement manuel. Dans GitLab 19.0, le même agent continue de travailler sur le même MR même après sa création : il traite les remarques, élimine les conflits et participe à la finalisation jusqu'à la fusion.

Comment lancer Developer Flow sur une merge request ?

Il existe trois méthodes : cliquer sur le bouton Generate MR sur l'issue, attribuer le compte de service Duo Developer directement à l'issue ou à la merge request, ou mentionner l'agent via un déclencheur @ dans n'importe quel fil de discussion sur l'issue ou la MR. Dans tous les cas, l'agent reprend le contexte de la discussion et poursuit le travail sur le MR déjà existant, au lieu d'en créer un nouveau.