Agents d'IA et glab CLI : offrez un accès direct et structuré à GitLab

Lorsque les équipes utilisent GitLab Duo, Claude, Cursor et d'autres assistants d'IA, une part croissante du workflow de développement passe par un agent d'IA qui agit en votre nom : lecture des tickets, revue des merge requests, exécution des pipelines et livraison plus rapide du code. La plupart des équipes de développement utilisent déjà GitLab CLI (glab) depuis leur terminal pour interagir avec GitLab. Combiner les deux est l'étape logique suivante.

Le problème est que sans les bons outils, les agents d'IA naviguent à l'aveugle dans vos projets GitLab. Ils peuvent halluciner et inventer les détails d'un ticket qu'ils n'ont jamais vu, résumer une merge request à partir de données d'entraînement obsolètes plutôt qu'à partir de son état réel, ou vous obliger à copier manuellement le contexte depuis un onglet de navigateur pour le coller dans une fenêtre de chat avant de pouvoir commencer. Chacune de ces solutions de contournement est problématique : elle vous ralentit, introduit un risque d'erreur et limite considérablement ce que votre agent peut réellement accomplir pour vous. glab change la donne en offrant aux agents une interface directe et fiable à vos projets.

Avec glab, votre agent récupère directement ce dont il a besoin depuis GitLab, agit en conséquence et vous rend compte du résultat : vous passez ainsi moins de temps à transmettre des informations et plus de temps sur votre cœur de métier.

Dans ce tutoriel, vous apprendrez à utiliser glab pour offrir à vos agents d'IA un accès structuré et fiable à vos projets GitLab. Vous découvrirez également comment cette approche permet d'obtenir un workflow de développement plus rapide et plus performant.

Connecter votre agent d'IA à GitLab via le MCP

Pour démultiplier votre workflow d'IA, offrez à votre agent un accès natif à glab via le Model Context Protocol (MCP).

Le MCP est une norme ouverte qui permet aux outils d'IA de découvrir et d'utiliser des fonctionnalités externes au moment de l'exécution. Une fois connecté, votre assistant d'IA peut lire les tickets, commenter les merge requests, vérifier l'état des pipelines et écrire dans GitLab, le tout sans que vous ayez à copier quoi que ce soit depuis l'interface utilisateur ni à écrire le moindre appel d'API.

Pour commencer, exécutez :

       # Start the glab MCP server
 glab mcp serve

    

Une fois votre client MCP configuré, votre IA peut répondre à des questions telles que « Quel est le statut de mes merge requests ouvertes ? » ou « Y a-t-il des pipelines en échec sur la branche principale ? » en interrogeant directement GitLab, sans extraire des données de l'interface utilisateur Web ni s'appuyer sur des données d'entraînement obsolètes. Consultez la documentation complète de configuration pour découvrir les étapes de configuration avec Claude Code, Cursor et d'autres éditeurs.

Un détail important à connaître : glab ajoute automatiquement --output json lorsqu'il est invoqué via le MCP, pour toute commande qui le prend en charge. Votre agent reçoit des données propres et structurées sans que vous ayez à vous soucier des formats des données de sortie. Et comme glab utilise le SDK MCP officiel, il reste compatible à mesure que le protocole évolue.

Nous avons également soigneusement sélectionné les commandes accessibles via le MCP. Les commandes qui nécessitent une saisie interactive dans le terminal sont volontairement exclues, afin que votre agent ne se retrouve jamais bloqué à attendre des données d'entrée qui n'arriveront jamais. Seules les commandes qui fonctionnent de manière fiable dans le contexte d'un agent sont disponibles.

Intégrer votre IA dans la revue de code

La plupart des équipes de développement ont un backlog de merge requests en attente de revue. C'est l'une des tâches les plus chronophages du métier et l'un des domaines où l'IA peut être mise à contribution. Avec glab, votre agent ne se contente pas d'observer votre file d'attente de revue : il peut la traiter avec vous.

Voir précisément ce qui reste à traiter

Commencez par cette commande :

       glab mr view 2677 --comments --unresolved --output json

    

Cette commande renvoie l’intégralité de la merge request : métadonnées, description et toutes les discussions non résolues, sous la forme d'une charge utile JSON unique et structurée. Transmettez-la à votre IA afin que celle-ci dispose de tout ce dont elle a besoin : quels fils de discussion sont ouverts, ce que le relecteur a demandé et dans quel contexte. Plus de changement d'onglet, ni de copier-coller de commentaires individuels.

      {
  "id": 2677,
  "title": "feat: add OAuth2 support",
  "state": "opened",
  "author": { "username": "jdwick" },
  "labels": ["backend", "needs-review"],
  "blocking_discussions_resolved": false,
  "discussions": [
    {
      "id": "3107030349",
      "resolved": false,
      "notes": [
        {
          "author": { "username": "dmurphy" },
          "body": "This error handling will swallow panics — consider wrapping with recover()",
          "created_at": "2026-03-14T09:23:11.000Z"
        }
      ]
    },
    {
      "id": "3107030412",
      "resolved": false,
      "notes": [
        {
          "author": { "username": "sreeves" },
          "body": "Token refresh logic needs a test for the expired token case",
          "created_at": "2026-03-14T10:05:44.000Z"
        }
      ]
    }
  ]
}

    

Au lieu de lire chaque fil de discussion vous-même, vous demandez à votre agent « quels sont les éléments à corriger dans la merge request 2677 ? » et vous obtenez un résumé priorisé avec des suggestions de modifications, le tout à partir d'une seule commande.

Boucler la boucle de manière programmatique

Une fois que votre IA vous a aidé à traiter les retours, elle peut résoudre les discussions :

      # List all discussions — structured, ready for the agent to process
glab mr note list 456 --output json

# Resolve a discussion once the feedback is addressed
glab mr note resolve 456 3107030349

# Reopen if something needs another look
glab mr note reopen 456 3107030349

    

      [
  {
    "id": 3107030349,
    "body": "This error handling will swallow panics — consider wrapping with recover()",
    "author": { "username": "dmurphy" },
    "resolved": false,
    "resolvable": true
  },
  {
    "id": 3107030412,
    "body": "Token refresh logic needs a test for the expired token case",
    "author": { "username": "sreeves" },
    "resolved": false,
    "resolvable": true
  }
]

    

Les identifiants de notes sont directement visibles dans l'interface de GitLab et l'API, aucune recherche supplémentaire n'est nécessaire. Votre agent peut parcourir la liste complète, vérifier chaque correction et résoudre les discussions au fur et à mesure.

Communiquer plus efficacement avec votre IA

Même si vous n'exécutez pas de serveur MCP, utiliser glab pour fournir de meilleures informations à votre IA peut faire une différence considérable.

Pensez à la dernière fois que vous avez demandé à un assistant d'IA de vous aider à trier des tickets ou à déboguer un pipeline en échec. Vous avez probablement copié du texte depuis l'interface de GitLab pour le coller dans le chat. Voici ce avec quoi votre agent travaille réellement dans ce cas :

      open issues: 12 • milestone: 17.10 • label: bug, needs-triage ...

    

Comparez cela avec ce qu'il obtient via glab :

      [
  {
    "iid": 902,
    "title": "Pipeline fails on merge to main",
    "labels": ["bug", "needs-triage"],
    "milestone": { "title": "17.10" },
    "assignees": []
  },
  ...
]

    

Des données structurées, typées, complètes : aucune ambiguïté, aucune analyse syntaxique hasardeuse. C'est la différence entre un agent capable d'agir et un agent contraint de poser des questions complémentaires.

Si vous utilisez le serveur MCP, vous profitez automatiquement de cette approche : glab ajoute --output json pour toute commande qui le prend en charge. Si vous travaillez directement depuis le terminal, ajoutez simplement le flag vous-même :

      # Pull open issues for triage
glab issue list --label "needs-triage" --output json

# Check pipeline status
glab ci status --output json

# Get full MR details
glab mr view 456 --output json

    

La prise en charge des données de sortie JSON a été considérablement étendue dans les releases récentes. Elle couvre désormais le statut CI, les jalons, les labels, les releases, les planifications, les agents de cluster, les éléments de travail, les approbateurs de merge requests, les contributeurs aux dépôts, et bien plus encore. Si glab peut le récupérer, votre IA peut l'exploiter correctement.

Workflow concret

      $ glab issue list --label "needs-triage" --milestone "17.10"
--output json

    

      Agent: I found 2 unassigned bugs in the 17.10 milestone that need triage:
1. #902 — Pipeline fails on merge to main (opened 5 days ago)
2. #903 — Auth token not refreshing on expiry (opened 4 days ago)
Both are unassigned. Want me to draft triage notes and suggest assignees based on recent commit history?

    

Aucune limitation de votre agent aux commandes intégrées

Les commandes natives de glab couvrent les workflows les plus courants, mais votre agent n'est jamais limité à celles-ci. Via glab api, votre agent dispose d'un accès authentifié à l'intégralité de la surface API REST et GraphQL de GitLab, en utilisant la même session, sans identifiants ni configuration supplémentaires.

Voilà ce qui change vraiment la donne. La plupart des outils en ligne de commande s'arrêtent à ce que leurs commandes mettent à disposition. Avec glab, si l'API GitLab le prend en charge, votre agent peut le faire. Il opère toujours depuis un contexte de confiance et authentifié.

Un exemple concret : récupérer la liste des fichiers modifiés dans une merge request avant de décider quels diffs extraire en intégralité :

      # Get changed file paths — lightweight, no diff content yet
glab api "/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/diffs?per_page=100" \
| jq '.[].new_path'

# Then fetch only the specific file your agent needs
glab api "/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/diffs?per_page=100" \
| jq '.[] | select(.new_path == "path/to/file.go")'

    

      "internal/auth/token.go"
"internal/auth/token_test.go"
"internal/oauth/refresh.go"

    

Pour tout ce que l'API REST ne couvre pas (epics, certaines requêtes d'éléments de travail, données inter-projets complexes), glab api graphql vous donne accès à l'interface GraphQL complète :

        glab api graphql -f query='
{
  project(fullPath: "gitlab-org/gitlab") {
    mergeRequest(iid: "12345") {
      title
      reviewers { nodes { username } }
    }
  }
}'

    

      {
  "data": {
    "project": {
      "mergeRequest": {
        "title": "feat: add OAuth2 support",
        "reviewers": {
          "nodes": [
            { "username": "dmurphy" },
            { "username": "sreeves" }
          ]
        }
      }
    }
  }
}

    

Votre agent dispose d'un point d'entrée unique et authentifié vers tout ce que GitLab met à disposition, sans besoin de jongler avec les tokens, sans clients API distincts ni surcharge de configuration.

Perspectives et retours

Deux améliorations en cours de développement renforceront encore davantage l'utilité de glab pour les workflows d'agents :

Texte d'aide adapté aux agents. Aujourd'hui, les données de sortie de --help sont rédigées pour des équipes devant un terminal. Nous avons décidé de les mettre à jour pour présenter l'alternative non interactive de chaque commande interactive, indiquer quelles commandes prennent en charge --output json et faire de l'aide une ressource utile aux agents qui découvrent les fonctionnalités au moment de l'exécution, pas uniquement aux équipes.

Meilleurs messages d'erreur lisibles par les machines. Lorsqu'un problème survient aujourd'hui, les agents reçoivent les mêmes messages d'erreur lisibles par les équipes que les utilisateurs du terminal. Nous avons décidé de modifier les messages pour que les erreurs en mode JSON renvoient des données de sortie structurées qui fournissent à votre agent les informations nécessaires pour gérer les échecs avec élégance, réessayer avec intelligence ou remonter le bon contexte vers vous.

Ces deux améliorations sont en cours de développement. Si vous utilisez déjà glab avec un outil d'IA, vous êtes exactement le public dont nous attendons les retours.

• Quelles frictions rencontrez-vous ? Des commandes qui ne fonctionnent pas correctement dans un contexte d'agent, des messages d'erreur non exploitables, des lacunes dans la couverture JSON ? Dites-nous tout.
• Quels workflows avez-vous débloqués ? Les cas d'utilisation réels nous aident à prioriser les prochains développements.

Rejoignez la discussion dans notre ticket : c'est là que nous mettons au point la roadmap dédiée à la compatibilité avec les agents, et c'est là que votre contribution aura le plus d'impact. Si vous avez identifié une lacune spécifique, ouvrez un ticket. Si vous avez une correction en tête, n'hésitez pas à apporter votre contribution. Consultez CONTRIBUTING.md pour vous lancer.

L'interface en ligne de commande GitLab a toujours eu pour vocation de donner aux équipes de développement un meilleur contrôle sur leur workflow. À mesure que l'IA prend une place croissante dans notre façon de travailler, nous avons pour objectif de faire de glab la meilleure interface possible entre vos outils d'IA et vos projets GitLab. Nous ne faisons que commencer, et nous serions ravis de développer les prochaines étapes avec vous.