Mises à jour du catalogue d'IA pour la gouvernance et les opérations

L'adoption de l'IA en entreprise échoue souvent non pas parce que la technologie n'est pas prête, mais parce que les administrateurs ne peuvent pas répondre à la question posée par leur équipe de sécurité : qu'est-ce qui s'exécute réellement dans notre environnement, et qui l'a mis en place ?

GitLab 19.1 intègre des déclencheurs basés sur des événements pour les flows de GitLab Duo, ainsi que les contrôles de gouvernance et la validation de configuration qui permettent de les exécuter en toute sécurité. Ensemble, ils donnent aux équipes d'entreprise la gouvernance et la fiabilité nécessaires pour exécuter des workflows IA en continu, sans attendre qu'un humain donne le feu vert.

Exécuter des flows automatiquement sur de vrais événements GitLab

Jusqu'à présent, chaque déclencheur de flow de GitLab Duo nécessitait une intervention humaine dans l'interface de GitLab : mention, attribution ou désignation d'un relecteur. Cela rendait difficile le pilotage programmatique des flows, leur intégration dans des pipelines de production ou leur déclenchement selon un calendrier défini. Pour les équipes qui gèrent des workflows de production à grande échelle, les limitations étaient les suivantes : l’absence de résumés automatiques de conflits, l’absence de vérifications de conformité sur les merge requests prêtes à être examinées, et l’absence de création d'incident en cas d'échec de pipeline. Aucun de ces workflows n'était possible sans qu'une personne initie manuellement un flow.

Grâce aux déclencheurs et aux nouveaux filtres d'événements de pipeline, les flows s'exécutent chaque fois que les conditions définies par votre organisation sont remplies, sans aucun transfert manuel. Le catalogue d'IA cesse d'être quelque chose que votre équipe utilise pour devenir quelque chose qui travaille pour votre équipe, en continu, en arrière-plan, pendant que les équipes de développement se concentrent sur les tâches qui nécessitent réellement un jugement.

C'est là que la valeur cumulée des workflows agentiques devient concrète. Lorsque les flows répondent automatiquement aux événements, les délais de transfert qui ralentissent aujourd'hui les boucles de rétroaction commencent à se réduire.

GitLab 19.1 inclut quatre nouveaux déclencheurs basés sur des événements :

• Conflit de merge détecté dans une merge request se déclenche dès qu'un conflit est détecté dans une merge request. C’est précisément à ce moment-là qu'un résumé automatique du conflit et des propositions de résolution s’avèrent les plus utiles, avant que le développeur n'ait commencé à examnier le problème et avant que le conflit ne s'aggrave. Auparavant, un développeur devait repérer le conflit, ouvrir la merge request et déclencher manuellement une revue. Désormais, le flow s'exécute dès que le conflit apparaît.
• Brouillon à prêt pour révision se déclenche lorsqu'un développeur marque une merge request comme prête. C'est le bon moment pour qu'une revue de conformité automatisée ou une liste de contrôle de préparation se déclenche automatiquement. Un flow qui nécessitait auparavant qu'un relecteur ou un responsable d'équipe initie manuellement une vérification avant le merge s'exécute désormais à chaque fois, dès que le signal est reçu.
• Merge request approuvée se déclenche lorsqu'une merge request est approuvée, déclenchant automatiquement les étapes post-approbation telles que les vérifications de préparation au déploiement, la journalisation de conformité ou les notifications de transfert, sans qu'un humain ait à s'en souvenir.
• Élément de travail créé se déclenche lors de la création d'un nouvel élément de travail. Cela ouvre la voie à des flows de classification immédiats, à l'attribution automatique de labels et à une logique de routage qui nécessite aujourd'hui soit un effort manuel, soit des configurations de webhook fragiles en dehors de GitLab.

Bien que les événements de pipeline ne soient pas une nouveauté, la possibilité de filtrer en fonction d’états spécifiques du pipeline, elle, est nouvelle. Vous pouvez désormais configurer un déclencheur pour qu'il se déclenche uniquement en cas d'échec, uniquement en cas de succès ou uniquement en cas d'annulation, plutôt que sur chaque changement d'état de pipeline. Cela vous permet de créer des incidents en cas d'échec et de promouvoir des artefacts en cas de succès, sans être alerté à chaque changement d'état de pipeline.

Les déclencheurs Conflit de merge détecté dans une merge request et Brouillon à prêt pour révision sont activés par défaut, de sorte que les équipes bénéficient immédiatement de la valeur ajoutée dès la mise à jour vers la version 19.1.

Déclencheurs basés sur des événements

Une amélioration de l'expérience développeur arrive également dans la version 19.1. Pour les équipes de développement qui exécutent ces flows localement, les invocations répétées d'outils (installations npm, modifications de fichiers, refactorisations en plusieurs étapes) nécessitaient auparavant une nouvelle validation à chaque fois. Un nouveau niveau d'approbation basé sur des modèles (actuellement en version bêta) vous permet d'approuver toutes les utilisations d'un outil pour la session, afin que l'agent puisse itérer sans vous interrompre.

Découvrez les déclencheurs d'événements en action :

Empêcher les agents et flows d'IA non approuvés d'accéder à votre environnement

Un agent externe qui apparaît dans un espace de nommage lors d'un hackathon, ou un membre de l'équipe qui active un flow issu de la communauté sans revue de sécurité, suffit à bloquer un essai en entreprise. Pour les organisations réglementées, un contenu IA non validé n'est pas une préoccupation mineure, c’est un obstacle majeur.

Deux nouveaux paramètres donnent aux administrateurs d'instance et aux propriétaires de groupe principal une autorité directe sur ce qui s'exécute exactement.

• Désactiver les agents et les flows personnalisés empêche les utilisateurs de créer ou d'activer des agents et des flows personnalisés, en les limitant au contenu par défaut.
• Restreindre le catalogue d'IA à votre hiérarchie de groupe empêche les utilisateurs d'activer des éléments du catalogue d'IA provenant de l'extérieur de leur espace de nommage, y compris le contenu issu de la communauté et de tiers.

Ensemble, ces paramètres placent les agents et flows d'IA sous la même supervision administrative que celle qui régit déjà les autres fonctionnalités sensibles de la plateforme, afin que les administrateurs puissent ouvrir une utilisation large sans pour autant favoriser la multiplication des agents en environnement de production.

Détecter les erreurs de configuration des flows avant leur mise en production

Les flows basés sur des événements qui se déclenchent automatiquement rendent d'autant plus importante l'exactitude de la configuration au sein d'une entreprise. Qu'un flow soit mal configuré ou se déclenche trop souvent, il génère du bruit et des problèmes dans toute l'organisation.

GitLab 19.1 déplace la validation en amont. Lorsqu'un utilisateur enregistre ou met à jour un flow dans le catalogue d'IA, GitLab valide la configuration du flow auprès de GitLab Duo Workflow Service avant de l'enregistrer. En cas de problème (une entrée manquante, un paramètre d'outil inconnu, ou tout autre élément détecté par le validateur) des messages d'erreur structurés s'affichent dans l'interface avant l'enregistrement du flow. Les flows valides s'enregistrent et se déclenchent exactement comme avant.

Résultat : chaque flow du catalogue d'IA est correctement configuré avant que quiconque n'en dépende en production. Les problèmes de configuration apparaissent au moment de l'enregistrement, quand ils sont faciles à corriger, et non au milieu de la nuit quand un pipeline échoue.

Contrôler les modèles d'IA disponibles pour votre équipe

Une autre fonctionnalité de gouvernance est disponible en version bêta publique. Les administrateurs peuvent désormais configurer une liste d'autorisation de modèles d'IA approuvés et définir un modèle par défaut à l'échelle de l'organisation, plutôt que de choisir entre un modèle fixe ou une sélection sans restriction.

Cela permet aux organisations de se limiter aux fournisseurs conformes aux exigences de résidence des données ou préalablement approuvés, tout en préservant la flexibilité des utilisateurs finaux dans ce cadre. Cette première itération s'applique à GitLab Duo Agentic Chat, avec une couverture plus large sur d'autres surfaces à venir prochainement.

Construire sur une base prête pour la production

Grâce à ces mises à jour, les flows peuvent enfin fonctionner comme l'automatisation de production est censée le faire : en continu, de manière fiable, et sans attendre que quelqu'un appuie sur un bouton. Les administrateurs disposent de l'autorité de gouvernance pour contrôler exactement ce qui s'exécute dans leur environnement, et les équipes de développement reçoivent les retours de configuration au bon moment.

Commencez votre essai gratuit de GitLab Duo Agent Platform ou explorez notre documentation pour en savoir plus sur les agents, les flows et le catalogue d'IA.