Date de publication : 18 septembre 2026

Temps de lecture : 7 min

GitLab Duo CLI : de l'objectif à la réalisation

Décrivez le résultat souhaité et laissez GitLab Duo CLI se charger du travail tout en gardant le contrôle.

Les tâches complexes se heurtent à un obstacle à la fin de chaque échange : les équipes de développement savent déjà ce qu'elles cherchent à accomplir. Ce sont les allers-retours entre chaque étape qui ralentissent le travail. Sans définition préalable du critère de réussite, l'agent s'arrête et attend des instructions ou des précisions. Vous vous retrouvez alors à le relancer étape par étape, jouant en quelque sorte le rôle de son bouton « Continuer » jusqu'à ce que la tâche soit terminée.

Selon les équipes, ces allers-retours peuvent représenter quelques minutes d'échanges, ou bien la demande reste en attente jusqu'à ce que quelqu'un soit disponible pour s'en occuper. Ce mode de fonctionnement reste gérable pour des demandes simples et bien ciblées, mais il n'est pas adapté au type de travail ouvert sur lequel les équipes consacrent réellement leur temps : corriger les tests en échec, faire passer le build aux vérifications ou nettoyer les erreurs de lint dans un module.

Avec GitLab 19.4, GitLab Duo CLI intègre la commande slash /goal, un flow gouverné et orienté sur les objectifs qui prend en charge ce travail ouvert directement et s'exécute localement tout en vous laissant le contrôle.

GitLab Transcend revient en octobre

Les agents de codage accélèrent votre développement, mais vos revues de code, politiques de sécurité et cycles de release doivent suivre le même rythme. Notre événement Transcend, qui se tiendra le 6 octobre, montrera comment GitLab aide les équipes à combler cet écart et explorera les conditions nécessaires pour maintenir la vitesse de l'IA agentique tout au long du cycle de vie logiciel.

Inscrivez-vous dès maintenant au livestream !

Pourquoi les échanges pas à pas vous font perdre du temps

Il ne s'agit pas de rendre l'assistant plus intelligent. Les échanges pas à pas nécessitent que quelqu'un le fasse avancer : lire la réponse, décider de la prochaine instruction, l'envoyer, recommencer. Même un modèle performant attend à la fin de chaque étape qu'une personne le débloque. L'attention du développeur reste donc liée à la durée d'une tâche et non à la part qu'il doit réellement effectuer lui-même. C'est pourquoi l'assistance par IA a, jusqu'à présent, surtout modifié l'organisation du temps des équipes de développement plutôt que de leur en restituer une part significative.

Déléguez les tâches pour obtenir un résultat vérifié

Avec la commande slash /goal, vous décrivez le résultat souhaité et passez à autre chose. Personne n'a besoin de surveiller l'exécution : le travail se poursuit, est vérifié par rapport à ce que vous avez demandé et se termine, ou l'agent vous indique ce qu'il n'a pas pu résoudre. Vous retrouvez un résultat finalisé et un compte-rendu de ce qui a été vérifié, de la même manière que vous feriez le point sur une tâche que vous avez déléguée à un collègue, plutôt que de rester les yeux rivés sur la conversation jusqu'à ce qu'elle soit terminée.

Des simples prompts aux objectifs à long terme

Il vous suffit de nommer la tâche et de définir ce que « terminé » signifie. GitLab prend le relais, reste actif et concentré jusqu'à ce que cette ligne d'arrivée spécifique soit franchie.

      /goal Fix the failing tests. Ensure CI is fully green and the fix is reviewed by Duo Developer.

    

GitLab s'attelle ensuite au problème : il apporte des modifications et effectue des vérifications, en itérant si nécessaire. Un modèle distinct contrôle à chaque étape que le travail correspond à l'objectif que vous avez défini et détermine si la tâche est véritablement accomplie ou si une nouvelle itération est nécessaire, dans la limite d'un nombre configuré. C'est la différence entre un assistant qui répond à des questions et un assistant qui mène une tâche à son terme.

Une automatisation qui reste maîtrisée

Confier un objectif ne signifie pas pour autant perdre la visibilité sur son avancement. Vous pouvez arrêter une exécution de la commande slash /goal à tout moment et définir un nouvel objectif si les exigences changent. Une session en cours n'a donc jamais à aller jusqu'à son terme si elle s'écarte de la trajectoire prévue.

  • Interrompez l'exécution à tout moment si vous devez intervenir.
  • Définissez un nouvel objectif et relancez l'exécution si les exigences ont évolué.
  • Passez en revue ce que le vérificateur a contrôlé à la fin de chaque tour, pour comprendre pourquoi il a décidé de continuer ou de s'arrêter.

Cette combinaison, soit un agent capable de travailler de façon autonome vers un résultat défini sans qu'un superviseur humain ait besoin de suivre chaque étape de près, avec des points de contrôle humain clairs, est ce qui fait de cette fonctionnalité un pas vers une automatisation pratique plutôt qu'une simple nouveauté.

Premiers pas

La commande slash /goal est disponible dès maintenant en mode interactif. Pour l'utiliser, exécutez :

      /goal <task>. <done when...>

    

Par exemple :

      /goal Fix the failing tests in spec/models/user_spec.rb. Continue until all tests pass locally and CI is green.

    

Découvrez la commande slash /goal en action dans cette démonstration :

Au plus près des équipes de développement

La valeur d'un flow orienté sur les objectifs dépend des interfaces par lesquelles les équipes de développement peuvent y accéder. /goal est lancé en premier dans l'interface de ligne de commande (CLI), car une grande partie de ce travail itératif et pratique s'effectue déjà dans le terminal, mais la capacité sous-jacente n'est pas limitée à un seul client. Les équipes de développement doivent pouvoir déléguer un objectif depuis les outils qu'elles utilisent déjà, sans avoir à basculer vers une interface distincte pour accéder à cette automatisation.

Un agent GitLab Duo Slack arrive prochainement. Il permettra aux équipes de développement d'interagir avec GitLab Duo Agent Platform dans des conversations directement dans Slack. Mentionnez @GitLab dans n'importe quel canal ou fil de discussion pour poser des questions sur votre code source, déclencher un flow d'agent ou créer un ticket GitLab à partir de la conversation, sans avoir besoin d'un outil, d'un onglet ou d'une syntaxe de commande distincte. GitLab Duo affiche la progression en temps réel dans le fil de discussion, de sorte que l'ensemble de l'échange (question, traitement et résultat) reste là où la conversation se déroule déjà.

Commencez à déléguer vos tâches récurrentes

/goal est désormais disponible dans GitLab Duo CLI et marque une première étape vers le transfert du processus décisionnel lié à une tâche, notamment quand un objectif est atteint et quand il faut poursuivre, hors d'un client unique et vers un workflow gouverné que chaque surface GitLab peut invoquer. À mesure que cette même capacité s'étend à Slack, les corrections et les vérifications itératives que votre équipe effectue déjà manuellement deviennent des flows gouvernés et orientés sur les objectifs, sans que vos équipes de développement aient à changer leur environnement de travail.

Prêt à essayer la commande slash /goal ? Commencez par consulter la documentation sur les commandes slash de GitLab Duo CLI.

/goal nécessite GitLab 19.3 ou une version ultérieure, ainsi que GitLab Duo CLI 9.17.0 ou une version ultérieure. La fonctionnalité est disponible sur GitLab.com, GitLab Self-Managed et GitLab Dedicated, sur les niveaux GitLab Premium et GitLab Ultimate.

/goal fait partie de GitLab Duo Agent Platform. Vous devrez donc l'activer pour utiliser cette fonctionnalité et d'autres capacités agentiques. Vous pouvez y accéder grâce à un essai gratuit de GitLab Duo Agent Platform. Sur l'édition Gratuite, vous pouvez vous inscrire en suivant ces étapes.

Vous utilisez déjà GitLab Premium ou GitLab Ultimate ? Commencez par activer GitLab Duo Agent Platform et utilisez les GitLab Credits inclus dans votre abonnement.

Cet article de blog contient des déclarations de nature prospective au sens de la Section 27A du Securities Act de 1933, telle que modifiée, et de la Section 21E du Securities Exchange Act de 1934. Bien que nous pensions que les attentes reflétées dans ces déclarations sont raisonnables, elles sont soumises à des risques, incertitudes, hypothèses et autres facteurs connus et inconnus qui peuvent entraîner des résultats ou conséquences sensiblement différents. De plus amples informations sur ces risques et autres facteurs sont incluses sous la rubrique « Facteurs de risque » dans nos documents déposés auprès de la SEC. Nous ne nous engageons pas à mettre à jour ou à réviser ces déclarations après la date de publication de cet article de blog, sauf si la loi l'exige.

Donnez-nous votre avis

Cet article de blog vous a plu ? Vous avez des questions ou des retours ? Donnez votre avis en créant un nouveau sujet sur le forum de la communauté GitLab.

Faites-nous part de vos commentaires

Commencez à développer plus rapidement dès aujourd'hui

Découvrez ce que votre équipe peut accomplir avec la plateforme d'orchestration intelligente pour le DevSecOps.