GitLab 19.4 veut industrialiser l’IA agentique dans les équipes DevSecOps

GitLab 19.4 entend répondre à une question très concrète pour les entreprises : comment confier davantage de travail aux agents IA sans perdre la maîtrise des autorisations, des validations, du choix des modèles ou des dépenses ? Publiée le 17 septembre 2026, cette version associe exécution d’objectifs par des agents, options de modèles moins coûteuses, contrôle de consommation et automatisation via le Model Context Protocol (MCP). 15

Avec /goal, le développeur délègue un résultat plutôt qu’une suite d’actions

La principale nouveauté est la commande /goal de GitLab Duo CLI, disponible en bêta publique. Au lieu de guider l’agent étape après étape, le développeur peut lui confier un objectif ouvert dans un flux agentique gouverné, exécuté localement. 5

GitLab indique qu’un modèle distinct vérifie la progression de l’agent par rapport à l’objectif défini. L’exécution s’arrête lorsque l’objectif est atteint ou lorsqu’une limite d’itérations est atteinte. Il est aussi possible de mettre l’exécution en pause, de modifier ou de réorienter l’objectif, puis de la relancer. 5

L’enjeu est de laisser l’agent mener un travail en plusieurs étapes sans écarter le développeur de la boucle. Celui-ci peut intervenir si le contexte, le besoin ou la voie d’implémentation évolue.

Trois modèles open-weight, administrés de façon centralisée

GitLab Duo Agent Platform prend désormais en charge trois modèles open-weight hébergés par GitLab : Kimi K3, MiniMax M3 et GLM 5.3. Ils s’ajoutent aux options de modèles dites « frontier » déjà proposées et sont pris en charge dans GitLab Duo Agentic Chat ainsi que dans d’autres fonctions agentiques compatibles. 12

GitLab présente ces modèles comme un moyen d’ajuster coût, latence et niveau de capacité selon la tâche :

• choisir des modèles moins coûteux pour les tâches routinières ou à fort volume ;
• réserver les modèles les plus onéreux aux tâches complexes qui le justifient ;
• définir des modèles par défaut au niveau de l’organisation, plutôt que de laisser ce choix à chaque utilisateur. 510

Selon GitLab, ces modèles open-weight hébergés peuvent offrir jusqu’à quatre fois plus d’appels par GitLab Credit que certains modèles frontier comparables. Il s’agit toutefois d’une affirmation du fournisseur, fondée sur son propre cadrage et ses propres tests, et non d’un benchmark indépendant. Les équipes ont donc intérêt à évaluer qualité et coût sur leurs cas d’usage réels. 510

Les propriétaires de groupes et les administrateurs peuvent définir les modèles par défaut pour Agentic Chat, les agents, les flux et les fonctionnalités, tout en contrôlant les modèles accessibles aux équipes. Ces paramètres peuvent s’appliquer aux sous-groupes et aux projets. 15

Visibilité sur les coûts et plafonds par utilisateur

L’augmentation de l’usage des agents implique aussi de suivre la consommation. Avec la version 19.4, les capacités de visibilité sur les coûts passent en disponibilité générale : les administrateurs peuvent fixer des plafonds par utilisateur, tandis que les développeurs peuvent consulter leur propre consommation de GitLab Credits. 5

La version ajoute également des exports d’usage au niveau des événements facturables, via des liens de téléchargement sécurisés, pour les abonnements Flex comme hors Flex. Les équipes de plateforme peuvent ainsi rattacher la consommation d’IA agentique à des utilisateurs ou à des services avant la réception des factures. 5

Concrètement, une organisation peut tester ou étendre ses workflows agentiques tout en fixant des limites de consommation et en organisant leur suivi.

Les outils MCP ouvrent GitLab aux agents externes

GitLab 19.4 introduit aussi, en bêta publique, des outils de serveur MCP GitLab. Le MCP est un protocole permettant à des clients et agents compatibles d’accéder à des outils et à des contextes. Dans ce cas, les agents tiers peuvent interagir avec des workflows GitLab pour notamment :

• déclencher des pipelines ;
• examiner les traces de tâches en échec ;
• gérer des merge requests, de la revue à la fusion ;
• rechercher et mettre à jour des éléments de travail ;
• trier des vulnérabilités. 5

L’argument central de GitLab est la continuité de la gouvernance : ces outils MCP utiliseraient les mêmes réglages de groupes et de projets que les outils internes de Duo Agent Platform, au lieu d’imposer une couche de politiques distincte pour les agents tiers. 5

Les réglages d’approbation par défaut visent à conserver un contrôle humain : les outils en lecture seule sont réglés sur « Toujours autoriser », tandis que les actions d’écriture et de suppression sont réglées sur « Toujours demander ». 5

Pour les organisations qui évaluent des intégrations agentiques, la question ne se limite donc pas à savoir si un agent peut accéder aux pipelines CI/CD, aux merge requests ou aux workflows de sécurité. Il faut aussi vérifier que ses actions respectent les permissions et les mécanismes de validation déjà en place.

Intégration Slack, meilleure visibilité des sessions et ajouts communautaires

La mise à jour comporte plusieurs fonctions complémentaires :

• Une intégration expérimentale de GitLab Duo Agent Platform à Slack permet aux utilisateurs Premium et Ultimate de mentionner @GitLab dans un fil pour rechercher dans GitLab, ouvrir une issue ou poser une question sur un projet. GitLab précise qu’elle exploite le contexte du fil et du canal récent, s’exécute sur un runner CI/CD et publie la réponse dans Slack. 5
• Un panneau de détails des sessions repensé affiche le statut, les horodatages et l’utilisateur à l’origine de la session. Il distingue aussi l’événement qui a lancé une session agentique du travail produit par celle-ci. 5
• Des contributions de la communauté apportent des outils MCP pour les métadonnées et membres de projets, les listes de branches de dépôts, les listes de merge requests entre groupes et la récupération de sessions Duo antérieures. La recherche sémantique a également été regroupée dans un seul outil. 5

Vers un déploiement de l’IA agentique à l’échelle de l’organisation

GitLab ne présente pas 19.4 comme une simple accumulation de fonctions IA. Son positionnement consiste à permettre aux développeurs de déléguer des objectifs plus larges, tout en laissant aux responsables de plateforme la maîtrise des modèles disponibles, des validations pour les actions sensibles, des plafonds d’usage et du suivi de consommation. 15

Autrement dit, GitLab cherche à faire de l’extension de l’automatisation agentique une décision opérationnelle gouvernée : sélectionner les charges de travail, autoriser certains modèles et outils, appliquer les règles d’accès existantes et surveiller les dépenses associées. La promesse devra être éprouvée par chaque équipe, en particulier pour les fonctions encore en bêta publique, mais l’orientation est nette : GitLab construit ces fonctions pour un déploiement administré dans les équipes DevSecOps, et non seulement pour des sessions de codage assisté individuelles. 5