GitLab lance l'orchestration d'agents : la commande /goal mène une tâche jusqu'à un CI au vert

GitLab cherche à supprimer les temps d'attente entre les étapes du développement. Lors de la conférence Transcend, l'entreprise a annoncé trois nouvelles fonctions d'orchestration d'agents dans Duo Agent Platform : les flux orientés objectif (goal-driven flows), l'intégration GitLab for Slack et les Custom Flows. Les flux orientés objectif nécessitent GitLab 19.3 et Duo CLI 9.17.0 ou une version plus récente. L'argument de GitLab est simple : l'IA a accéléré l'écriture du code, pas sa livraison. L'agent produit un correctif en quelques minutes, puis celui-ci attend des semaines la signature d'un relecteur, le traitement des alertes du pipeline, le triage des résultats de scan et un nouveau prompt manuel.

Un objectif plutôt que des étapes : comment fonctionne /goal

Les flux orientés objectif donnent à l'agent une ligne d'arrivée, et non la prochaine action à effectuer. Le développeur décrit la tâche et le critère d'achèvement, et le flux travaille jusqu'à atteindre le résultat. Revue, tests, contrôles de sécurité et validations s'enchaînent en une seule chaîne, sans arrêt entre les étapes.

Le lancement ressemble à ceci : `/goal Fix the checkout timeout. Continue until tests pass and CI is green.` La commande fonctionne dans Duo CLI, en mode headless via `duo run --goal` et dans Agentic Chat. La deuxième forme compte pour l'automatisation : on peut l'appeler depuis des scripts et des pipelines, sans session interactive.

Un autre point concerne le contrôle qualité. À chaque étape, un modèle distinct confronte le travail à l'objectif : l'agent ne s'évalue donc pas lui-même. On peut interrompre ou rediriger l'exécution à tout moment.

Slack et Custom Flows : démarrer là où on le demande

GitLab for Slack règle le problème du point d'entrée. La plupart des tâches naissent dans une discussion, pas dans le tracker. Il suffit de mentionner @GitLab dans un canal ou un fil et d'écrire, par exemple, « fix the failing pipeline » : un flux démarre et Duo diffuse sa progression directement dans le fil. Le même bot répond aux questions sur la base de code et transforme une conversation en issue. Le flux s'exécute sous les mêmes identity et politiques que n'importe quel autre flux dans GitLab : le contrôle d'accès reste donc du côté de la plateforme, et non de la messagerie.

Les Custom Flows couvrent un troisième scénario : l'équipe décrit elle-même une séquence d'agents en plusieurs étapes et la rattache à des événements GitLab, comme une mention, une affectation ou un pipeline. Les flux s'exécutent dans le CI/CD. Exemple donné par GitLab : un pipeline auto-réparateur analyse un test en échec, génère un correctif, le commit et prévient l'équipe. Sur les étapes sensibles, on peut placer des points de contrôle avec intervention humaine.

Tout cela relève d'un même modèle de gouvernance : identity, politiques et chaîne de preuves (evidence chain) sont communes à tous les flux. Pour les entreprises soumises à des audits, c'est sans doute le principal argument en faveur d'une approche de plateforme, face à une constellation d'agents externes. On peut étendre l'ensemble via l'AI Catalog, en connectant des agents et des outils externes grâce au client MCP et au serveur MCP. Les agents et flux de base couvrent déjà les étapes de la planification à l'analyse, dans l'interface de GitLab, les IDE et Duo CLI.

Disponibilité et premiers pas

Selon les conditions de lancement :

• flux orientés objectif : GitLab.com, Self-Managed et Dedicated, offres Premium et Ultimate ;
• versions minimales : GitLab 19.3 et Duo CLI 9.17.0 ;
• Custom Flows : déjà en disponibilité générale (GA) ;
• serveur MCP et GitLab for Slack : GA attendue plus tard ce mois-ci ;
• paiement : GitLab Credits, inclus dans l'abonnement Premium ou Ultimate.

Il est raisonnable de commencer petit. Vérifiez d'abord les versions de GitLab et de Duo CLI, activez Duo Agent Platform, puis lancez `/goal` sur une tâche étroite avec un critère d'achèvement sans ambiguïté, par exemple un test en échec dû à une erreur reproductible. La formulation de l'objectif décide de presque tout : un « CI au vert » se vérifie par une machine, « améliorer le code » non. Ensuite, transposez un processus manuel récurrent dans un Custom Flow, en gardant des points de contrôle humains sur le merge et sur la gestion des secrets. Mieux vaut prévoir la connexion à Slack après la GA, quand l'intégration sortira de l'accès anticipé.

La question principale reste ouverte : avec quelle fiabilité le modèle vérificateur distingue-t-il un objectif réellement atteint d'un pipeline formellement au vert ? Il vaut mieux le mesurer sur vos propres dépôts avant que les flux n'obtiennent le droit de faire avancer le code au-delà de la revue.