Date de publication : 18 septembre 2026
Temps de lecture : 7 min
GitLab 19.4 offre aux ingénieurs de plateforme une automatisation couvrant l'ensemble des outils MCP.

Les outils agentiques évoluent rapidement, bien au-delà de la simple complétion de code : ils exécutent désormais des pipelines, ouvrent des merge requests et trient les tâches pour le compte des équipes. Le Model Context Protocol (MCP) est devenu la norme permettant à ces agents d'interagir avec les outils existants d'une équipe. Résultat : les agents qui interviennent dans le pipeline de livraison logicielle d'une organisation ne se limitent plus à ceux que l'équipe de plateforme a elle-même choisis et configurés.
C'est précisément à ce niveau que l'automatisation se heurte généralement à des obstacles. Plus un agent peut réaliser de tâches, plus l'équipe de plateforme doit réfléchir à ce qu'il devrait être autorisé à faire sans demander l'autorisation au préalable, ce qui constitue un problème de gouvernance qui se résout généralement en restreignant les accès plutôt qu'en les élargissant. Si ce problème n'est pas traité, la situation ne s'améliore pas d'elle-même : les équipes finissent soit par brider leurs agents à quelques actions sûres en lecture seule, soit par tout ouvrir en espérant que tout se passe bien. Cependant, aucune de ces deux approches n'est évolutive.
La réponse de GitLab consiste à concilier un accès étendu aux outils et une gouvernance cohérente. Lorsque les ingénieurs de plateforme déploient des agents à l'échelle de leur organisation, qu'il s'agisse d'un flow GitLab ou d'un client tiers connecté via le serveur MCP de GitLab, ceux-ci doivent disposer du même accès à GitLab. Mais un accès plus large augmente les enjeux en matière de contrôle : c'est à un humain de décider quelles actions un agent peut effectuer de manière autonome et lesquelles nécessitent l'intervention d'un relecteur. Ainsi, les requêtes routinières en lecture seule s'exécutent rapidement, tandis que toute action d'écriture, de merge ou de suppression attend la validation du relecteur désigné par l'équipe.
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.
Avec GitLab 19.4, les équipes de plateforme peuvent automatiser davantage d'étapes du cycle de vie logiciel de bout en bout : un agent peut exécuter un pipeline, ouvrir et mettre à jour une merge request, ou classer une vulnérabilité, et pas seulement consulter ces éléments. Les actions en lecture seule s'exécutent sans intervention humaine par défaut, afin que les agents avancent au rythme du travail. Toute action d'écriture, de merge ou de suppression attend toujours la validation du relecteur désigné par l'équipe. Ainsi, l'élargissement du champ d'action des agents n'implique pas une extension de leurs capacités à agir sans supervision.
La gamme d'outils du serveur MCP de GitLab s'enrichit considérablement avec cette release, avec l'ajout d'outils CI/CD, de merge requests, d'éléments de travail, de vulnérabilités et de projets.
Découvrez ces outils du serveur MCP en action :
GitLab ajoute un ensemble substantiel de nouveaux outils au serveur MCP, offrant aux agents la couverture nécessaire pour mener à bien des tâches réelles de bout en bout.
save_pipeline exécute, relance, annule ou renomme un pipeline. get_job renvoie le job par défaut ; passer include: ["log"] ajoute la trace du job, paginée via byte_offset et byte_limit (512 Ko par page), ce qui permet à un agent de récupérer le log d'un build en échec et de diagnostiquer le problème directement.save_merge_request ouvre et met à jour une merge request. get_merge_request peut renvoyer des diffs, des conflits ou des approbations (un à la fois via le paramètre include), les diffs étant par défaut au niveau des statistiques, sauf si vous demandez detail: full_patch pour le texte du patch. list_merge_requests fonctionne au niveau du groupe. save_merge_request_review couvre l'ensemble du workflow de revue en un seul outil : publier un commentaire au niveau d'une ligne ou un commentaire général, répondre dans un fil de discussion ou le résoudre, soumettre une revue complète, déclencher une revue GitLab Duo, et approuver ou retirer une approbation. accept_merge_request fusionne une merge request immédiatement par défaut, ou attend que les vérifications soient passées lorsque vous passez strategy: merge_when_checks_pass (ou l'ajoute à un merge train avec add_to_merge_train_when_checks_pass).list_repository_tree permet d'explorer l'arborescence des fichiers. list_branches et list_tags répertorient les références, et list_releases permet d'inspecter les releases publiées. list_commits, get_commit et add_commit permettent d'interagir directement avec le contenu et l'historique des dépôts. fork_repository duplique un projet pour permettre à un agent d'effectuer des modifications sans affecter le dépôt d'origine.get_project et list_projects permettent de trouver et de lire les détails d'un projet. list_project_members liste les membres et leurs rôles. get_user récupère les informations d'un utilisateur pour les assignations et les mentions.get_work_item lit un élément en détail et couvre ce que faisait get_issue ; list_work_items effectue des recherches dans un groupe ou un projet ; save_work_item crée ou met à jour tout type d'élément de travail pris en charge, couvrant ce que faisait create_issue. Les tickets et les epics sont eux-mêmes des types d'éléments de travail. save_note permet d'ajouter un commentaire à un élément de travail ou à une merge request et peut répondre dans un fil de discussion existant. Il remplace create_merge_request_note et create_workitem_note.list_vulnerabilities liste les vulnérabilités d'un projet, filtrables par gravité et type de rapport, avec pagination par curseur. get_vulnerability renvoie les détails complets d'une vulnérabilité par son identifiant. save_vulnerability regroupe cinq actions d'écriture (ignorer, confirmer, revenir à l'état détecté, mettre à jour la gravité et créer un ticket lié) en un seul outil.Ces outils sont actuellement disponibles en version bêta. Ils marquent une première étape vers une plateforme où chaque agent, interne ou tiers, opère selon les mêmes règles de gouvernance et accède au même niveau de détail du contexte de GitLab. À mesure que de nouveaux outils et déclencheurs seront disponibles, ce modèle de gouvernance s'étendra avec eux, permettant aux ingénieurs de plateforme de configurer les garde-fous une seule fois plutôt que pour chaque nouveau client.
Prêt à l'essayer ? Commencez par consulter notre documentation sur les outils du serveur MCP et notre documentation sur la gouvernance des outils.
Les nouveaux outils du serveur MCP sont disponibles en version bêta pour les éditions gratuites, GitLab Premium et GitLab Ultimate, à l'exception des outils de gestion des vulnérabilités qui nécessitent GitLab Ultimate. Le déclencheur Merge request créée requiert GitLab Premium ou GitLab Ultimate ainsi que GitLab Duo Agent Platform activé. Consultez notre documentation sur les déclencheurs pour le configurer dans votre projet.
Vous êtes déjà sur GitLab Premium ou GitLab Ultimate et souhaitez utiliser le déclencheur Merge request créée ? Commencez par activer GitLab Duo Agent Platform et utilisez les GitLab Credits inclus dans votre abonnement.
Commencez votre essai gratuit
de 30 jours
Aucune carte de crédit requise.
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 commentairesCommencez à 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.