GitLab Duo CLI est désormais disponible de manière générale avec GitLab 19.2. L'outil apporte l'agent GitLab Duo dans le terminal pour explorer un dépôt, modifier du code, analyser un pipeline en échec ou automatiser une tâche en plusieurs étapes. Il peut fonctionner dans une session interactive ou sans interface au sein d'un script et d'un runner.
Cette disponibilité générale ne transforme pas l'agent en administrateur autonome à qui confier un jeton illimité. Le terminal concentre le code source, les identifiants, les outils de déploiement et parfois l'accès à la production. Un essai utile doit donc commencer avec un périmètre réduit, des permissions minimales et une trace de chaque action.
La réponse rapide
| Usage | Niveau de prudence |
|---|---|
| Comprendre un dépôt en lecture seule | Bon point de départ. Vérifier les fichiers transmis au modèle. |
| Proposer un correctif local | Utiliser le mode plan, puis relire le diff avant application. |
| Diagnostiquer une CI | Autoriser seulement les projets et journaux nécessaires. |
| Exécution headless dans un runner | Ajouter limites de temps, environnement isolé et validation de sortie. |
| Déploiement en production | Ne pas donner un droit direct par défaut ; conserver une approbation humaine. |
GitLab documente Duo CLI pour les offres Premium et Ultimate, sur GitLab.com, GitLab Self-Managed et GitLab Dedicated. L'expérience généralement disponible demande Duo CLI 9.0.0 ou une version ultérieure.
Deux chemins d'installation
Le chemin le plus intégré passe par la commande GitLab glab. Une fois l'authentification configurée, glab duo cli lance l'expérience et réutilise le contexte GitLab. L'autre possibilité consiste à installer l'outil autonome duo, qui peut s'authentifier avec un jeton d'accès personnel.
Le premier choix réduit le nombre d'identifiants supplémentaires à gérer. Le second peut convenir à un environnement où glab n'est pas installé, mais il demande de créer, stocker et renouveler un jeton. Dans les deux cas, le secret ne doit jamais être placé dans le dépôt, dans un argument de commande visible par d'autres processus ou dans un journal de CI.
GitLab fournit /doctor pour vérifier la configuration et /mcp pour examiner les serveurs MCP disponibles. Ces diagnostics doivent faire partie du démarrage : un agent connecté au mauvais projet ou à un outil externe inattendu dispose d'un contexte différent de celui imaginé par l'utilisateur.
Mode plan avant mode build
En mode interactif, Duo CLI propose un fonctionnement de type conversationnel. Le mode plan explore le problème sans modifier les fichiers, puis le mode build peut réaliser les changements. Cette séparation est utile uniquement si l'équipe impose réellement une étape de lecture entre les deux.
Pour un pipeline en échec, une séquence raisonnable consiste à demander :
- l'identification du premier job défaillant et des symptômes observables ;
- les hypothèses classées avec les éléments qui les soutiennent ;
- un plan limité aux fichiers nécessaires ;
- un correctif sans commit ni push automatique ;
- les commandes de test et le diff final à relire.
L'agent peut se tromper sur la cause, proposer une dépendance inutile ou masquer un test au lieu de réparer le défaut. Le diff, les tests et la revue restent donc des contrôles indépendants, pas des formalités après une réponse convaincante.
Les sessions suivent le développeur
GitLab indique que les sessions peuvent être partagées entre Duo CLI, l'interface web et les extensions d'éditeur. Un diagnostic commencé dans un navigateur peut ainsi continuer dans le terminal avec le même contexte de conversation.
Cette continuité réduit les copier-coller, mais elle étend aussi la durée de vie du contexte. Une session ayant contenu un extrait sensible, une hypothèse devenue fausse ou des instructions propres à un incident peut influencer la suite. Il faut savoir quand créer une nouvelle session et éviter d'utiliser une conversation générale pour des projets ayant des niveaux de confidentialité différents.
Duo CLI prend en charge des instructions personnalisées comme chat-rules.md, AGENTS.md et SKILL.md. Ces fichiers peuvent documenter les commandes autorisées, les conventions du dépôt et les validations obligatoires. Ils restent du texte interprété par un modèle : les contrôles critiques doivent aussi exister dans les permissions du système et dans la CI.
Le mode headless change le niveau de risque
Le mode headless exécute un objectif sans conversation interactive, via une commande comme glab duo cli run --goal. Il devient possible d'intégrer l'agent à un script ou à un runner pour analyser un échec, préparer un rapport ou générer une proposition de correctif.
L'absence d'utilisateur devant le terminal supprime toutefois l'approbation immédiate de chaque outil. Avant un premier usage, il faut définir :
- un conteneur éphémère sans accès au socket Docker de l'hôte ;
- un jeton limité au projet et aux actions strictement nécessaires ;
- aucune variable de production si la tâche concerne seulement le code ;
- une durée maximale, une limite de coût et une taille de sortie ;
- un artefact contenant le rapport et le diff ;
- une règle interdisant commit, push, merge et déploiement automatiques ;
- une approbation humaine avant toute modification persistante.
Un agent headless ne doit pas hériter automatiquement de toutes les variables protégées du pipeline. L'isolation doit être définie par le job, pas seulement demandée dans le prompt.
MCP agrandit la surface d'action
Les connexions MCP peuvent donner à l'agent accès à d'autres outils et sources de données. Elles rendent possible un diagnostic combinant dépôt, ticket, documentation et observabilité. Elles augmentent aussi le nombre de systèmes capables d'être lus ou modifiés depuis une seule session.
Chaque serveur MCP doit être inventorié avec son propriétaire, son niveau de confiance, ses méthodes disponibles et les données auxquelles il accède. Un connecteur de documentation en lecture seule ne présente pas le même risque qu'un outil capable de modifier des tickets ou une infrastructure.
Le principe du moindre privilège s'applique à chaque couche : identité GitLab, jeton du runner, outils locaux et serveurs MCP. Désactiver une commande dans les instructions sans retirer l'autorisation technique laisse une protection fragile.
Administrer le déploiement sur une instance
Sur GitLab Self-Managed et Dedicated, les administrateurs peuvent activer ou désactiver Duo CLI au niveau de l'instance. La documentation indique que l'accès est activé par défaut. Une organisation qui ne souhaite pas l'introduire immédiatement doit donc vérifier explicitement sa configuration après le passage à GitLab 19.2.
Un pilote peut commencer avec quelques dépôts non critiques et des développeurs volontaires. Les mesures utiles ne sont pas le nombre de lignes produites, mais le temps jusqu'au diagnostic, le taux de correctifs acceptés sans reprise, les erreurs introduites, le nombre d'actions refusées et la consommation de crédits.
Il faut aussi préciser quelles données peuvent être envoyées au service et quels projets sont exclus. Les dépôts réglementés, les incidents actifs et les secrets historiques demandent une analyse spécifique des conditions de traitement et du modèle utilisé.
Une procédure de test en une semaine
Un essai court peut être structuré sans bouleverser la chaîne de livraison :
- sélectionner un dépôt de démonstration ou un service interne non critique ;
- configurer un compte et un jeton sans droit d'administration ;
- lancer
/doctoret examiner/mcp; - tester trois tâches répétables en lecture seule ;
- autoriser ensuite une modification locale avec revue obligatoire ;
- comparer le résultat à la résolution manuelle habituelle ;
- documenter les cas où l'agent doit s'arrêter et demander une décision.
Le mode headless ne devrait être ajouté qu'après cette phase interactive. Son premier objectif peut produire un résumé de pipeline ou classer des journaux, sans écrire dans le dépôt. L'automatisation d'un correctif vient plus tard, avec un artefact inspectable et une branche dédiée.
L'agent accélère une procédure, il ne la remplace pas
Duo CLI rapproche l'assistance IA du lieu où les développeurs rencontrent réellement les erreurs. Le contexte GitLab, les pipelines et le passage entre interface, éditeur et terminal peuvent réduire plusieurs ruptures de flux.
La valeur dépend néanmoins de la procédure qui entoure l'outil. Le mode plan, les permissions minimales, l'isolation du headless et la revue du diff doivent être traités comme des contrôles techniques. Avec ces garde-fous, l'agent peut accélérer le diagnostic et les tâches répétitives. Sans eux, il concentre dans une seule commande des pouvoirs que l'équipe avait jusque-là pris soin de séparer.
La discussion
Commentaires
Chargement des commentaires…