doc-locale/fr-fr/releases/19/gitlab-19-0-released.md
Le 21 mai 2026, GitLab 19.0 a été publié avec les fonctionnalités suivantes.
Nous souhaitons également annoncer le Contributeur notable de ce mois-ci : Norman Debald !
Nous sommes ravis de saluer Norman, un contributeur de niveau 3 avec plus de 40 améliorations fusionnées dans GitLab depuis son arrivée en mai 2022.
<!-- Copy this template, and paste it into the doc section where it belongs: Primary feature, Agentic Core, Scale and Deployments, or Unified DevOps and Security. Update all the information as needed. ### Feature explanation here {{< details >}} - Tier: Free, Premium, Ultimate - Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated - Links: [Documentation](../../ci/yaml/_index.md), [Related issue](https://gitlab.com/groups/gitlab-org/-/work_items/17754) {{< /details >}} Now write 125 words or fewer to explain the value of this improvement. Use phrases that start with, "In previous versions of GitLab, you couldn't... Now you can..." Use present tense, and speak about "you" instead of "the user." -->{{< details >}}
{{< /details >}}
Dans les versions précédentes de GitLab, vous ne pouviez définir des instructions de revue personnalisées pour GitLab Duo qu'au niveau du projet. Les équipes travaillant sur de nombreux projets dans le même groupe devaient dupliquer les mêmes instructions dans chaque projet.
Vous pouvez désormais configurer des instructions de revue personnalisées partagées pour un groupe entier et ses sous-groupes.
Sélectionnez un projet dans votre groupe à utiliser comme modèle. Lorsque GitLab Duo effectue une revue de code, il combine le fichier .gitlab/duo/mr-review-instructions.yaml au niveau du groupe avec toutes les instructions définies dans le projet individuel.
Le flow Code Review et GitLab Duo Code Review prennent tous deux en charge les instructions personnalisées au niveau du groupe.
{{< details >}}
{{< /details >}}
Auparavant, les types d'éléments de travail pouvaient être soit un Ticket, soit une Tâche. Vous pouvez désormais configurer des types d'éléments de travail personnalisés dans un projet pour correspondre à la façon dont votre équipe planifie et suit le travail.
Vous pouvez créer ou renommer des types en User Story, Bug ou Maintenance. Chaque élément de travail s'affiche avec son nom de type et une icône unique. Les nouveaux types prennent en charge les champs personnalisés et les cycles de vie de statut, et apparaissent dans vos vues enregistrées et vos tableaux des tickets. La configuration des types dans le groupe principal (GitLab.com) ou l'organisation (GitLab Self-Managed) se propage à tous les projets.
Vous pouvez également contrôler les types disponibles pour chaque projet. Activez ou désactivez un type sur tous les projets à la fois, ou laissez les projets individuels gérer leur propre visibilité de type. Lorsque vous désactivez un type dans un projet, les éléments de travail existants ne sont pas affectés.
{{< details >}}
{{< /details >}}
Dans les versions précédentes de GitLab, le GitLab Secrets Manager n'était disponible que pour un groupe fermé de bêta-testeurs. La plupart des équipes s'appuyaient sur des services externes tels que HashiCorp Vault ou AWS Secrets Manager.
Le GitLab Secrets Manager est désormais disponible en bêta ouverte pour les clients Premium et Ultimate sur GitLab.com et GitLab Self-Managed. Lorsque le GitLab Secrets Manager est activé, les propriétaires de projets et de groupes peuvent stocker, récupérer et référencer des secrets CI/CD dans GitLab. Les secrets sont limités à un projet ou un groupe et ne sont accessibles qu'aux jobs de pipeline qui les demandent explicitement.
Pendant la bêta ouverte, le GitLab Secrets Manager suit la politique de support bêta et peut ne pas être prêt pour une utilisation en production.
Pour partager vos commentaires, consultez le ticket 598100.
{{< details >}}
{{< /details >}}
GitLab Duo Developer prend désormais en charge plusieurs méthodes de déclenchement : assignez-le à un ticket, sélectionnez Generate MR, ou utilisez @mention dans n'importe quel fil de discussion de ticket ou de merge request pour transformer les retours, les éléments de la liste de tâches et les questions de conception en modifications de code, merge requests de suivi ou résumés de recherche.
Avec AGENTS.md et agent-config.yml configurés, GitLab Duo Developer exécute vos tests et vérifications avant de faire un commit. Après qu'un administrateur de groupe principal ou d'instance active le flow Developer, GitLab ajoute automatiquement des déclencheurs de mention et d'assignation aux projets éligibles.
{{< details >}}
{{< /details >}}
L'analyseur de dépendances basé sur SBOM de GitLab est désormais disponible en disponibilité générale. Les projets Maven, Gradle et Python disposent désormais d'une visibilité complète sur les vulnérabilités dans l'ensemble de leur arbre de dépendances, y compris les packages vulnérables introduits de manière transitive, et pas seulement ceux déclarés directement.
L'analyseur inclut désormais la résolution automatique des dépendances pour les projets Maven, Gradle et Python. Lorsqu'un fichier de verrouillage ou un graphe de dépendances résolu n'est pas présent, l'analyseur invoque automatiquement des outils pour résoudre le graphe de dépendances transitif complet avant l'analyse. La résolution des dépendances est activée par défaut et nécessite peu ou pas de configuration supplémentaire au-delà de l'inclusion du modèle Dependency Scanning v2.
Pour les projets où la résolution des dépendances n'est pas possible, l'analyseur bascule vers l'analyse de manifeste. Il analyse pom.xml, requirements.txt, build.gradle et build.gradle.kts pour identifier les dépendances directes. L'analyse de manifeste garantit que les équipes disposent toujours d'un point de départ pour la couverture des vulnérabilités, même pour les projets sans fichiers de verrouillage ou de build.
L'analyse de manifeste est activée par défaut et renvoie uniquement les dépendances directes. Pour une couverture transitive complète, activez la résolution des dépendances ou fournissez manuellement un fichier de verrouillage de dépendances ou un export de graphe.
{{< details >}}
{{< /details >}}
À partir de GitLab 19.0, GitLab Duo Core passe à la facturation basée sur l'usage. Les suggestions de code dans le Web IDE et les IDE de bureau consomment désormais des GitLab Credits.
GitLab Duo Chat évolue également. Pour les utilisateurs de GitLab Duo Core, Chat est désormais agentique et fonctionne sur GitLab Duo Agent Platform. Pour utiliser GitLab Duo Chat dans l'interface GitLab ou les IDE de bureau, activez GitLab Duo Agent Platform pour votre instance ou votre groupe principal.
{{< details >}}
{{< /details >}}
Vous pouvez désormais filtrer les résultats de recherche de code exacte par dépôt. Avec la syntaxe repo:, vous pouvez définir directement la portée de votre requête de recherche sur des dépôts ou des modèles de dépôts spécifiques sans avoir à accéder aux projets individuels.
Par exemple, rechercher def authenticate repo:my-group/my-project renvoie des résultats uniquement depuis ce dépôt. Vous pouvez également utiliser des chemins partiels ou des modèles pour correspondre à plusieurs dépôts.
{{< details >}}
{{< /details >}}
Vous pouvez désormais configurer des flows et des agents externes pour s'exécuter sur l'événement Merge request ready.
Lorsqu'une merge request en brouillon est marquée comme prête pour la revue, GitLab Duo exécute automatiquement le flow ou l'agent externe.
Pour configurer un déclencheur, accédez à IA > Déclencheurs dans votre projet.
Cette fonctionnalité est protégée par le feature flag merge_request_ready_flow_trigger, désactivé par défaut.
{{< details >}}
{{< /details >}}
Claude Opus 4.7 est désormais disponible dans GitLab Duo Agent Platform. Opus 4.7 apporte des améliorations significatives pour les tâches complexes à plusieurs étapes qui nécessitent un raisonnement soutenu, le suivi précis des instructions et une auto-vérification avant de présenter les résultats. Cela inclut les flows prenant en charge les pipelines CI/CD, la revue de code, la résolution de vulnérabilités, et plus encore.
{{< details >}}
{{< /details >}}
GitLab Duo Agent Platform Self-Hosted est désormais compatible avec les modèles Gemini. Les modèles Gemini prennent en charge plusieurs flows, notamment le flow Code Review, le flow SAST Vulnerability Resolution, le flow Fix CI/CD Pipeline, et plus encore.
{{< details >}}
{{< /details >}}
GitLab Duo Agent Platform prend désormais en charge des modèles open source supplémentaires pour les déploiements auto-hébergés, notamment Devstral 2 123B, GLM-5.1-FP8 et d'autres. Cela permet aux clients d'alimenter des workflows agentiques dans divers environnements, y compris les déploiements hors ligne et à accès réseau restreint.
{{< details >}}
{{< /details >}}
Avant que GitLab Duo Agentic Chat puisse utiliser un outil en votre nom, votre approbation est requise. Chaque invocation d'outil nécessite une approbation distincte.
Désormais, vous pouvez approuver un outil de confiance une seule fois pour toute une session et simplifier vos workflows.
Les administrateurs contrôlent si l'approbation d'outil pour les sessions est disponible. Les paramètres suivants se propagent de l'instance au groupe, puis au projet :
Les groupes et sous-groupes peuvent modifier le paramètre, sauf si un administrateur le définit sur Toujours désactivée.
Le paramètre par défaut est Désactivé(e) par défaut, ce qui garantit que chaque invocation d'outil nécessite une approbation explicite, à moins qu'un administrateur ne le modifie.
{{< details >}}
{{< /details >}}
Dans les versions précédentes de GitLab, vous deviez résoudre les conflits de merge manuellement dans l'interface GitLab ou depuis la ligne de commande, même pour les cas simples.
Désormais, GitLab Duo peut analyser de manière autonome les conflits de merge, modifier les fichiers en conflit, créer un commit et pousser vers la branche source. Déclenchez la résolution des conflits depuis la page Résoudre les conflits ou directement depuis le widget de merge request. Une fois terminé, GitLab Duo publie un commentaire de résumé afin que les relecteurs puissent voir ce qui a changé.
GitLab Duo respecte les règles de protection des branches et n'effectue pas de push forcé vers les branches protégées.
Cette fonctionnalité est en bêta et est protégée par le feature flag mr_ai_resolve_conflicts, désactivé par défaut.
{{< details >}}
{{< /details >}}
Les propriétaires de groupe principal peuvent désormais restreindre le catalogue d'IA pour n'afficher que les agents et flows appartenant aux projets de leur hiérarchie de groupes. Cela empêche les agents, les agents externes ou les flows qui ne font pas partie de cette hiérarchie d'être visibles ou activés par un utilisateur de ce groupe.
{{< details >}}
{{< /details >}}
Les utilisateurs du niveau Free sur GitLab Self-Managed peuvent désormais accéder à toute la puissance de GitLab Duo Agent Platform, sans abonnement Premium ou Ultimate requis. Choisissez votre montant de crédits mensuel, engagez-vous sur une durée annuelle et obtenez un accès instantané aux outils de développement alimentés par l'IA. Les crédits se renouvellent automatiquement chaque mois, afin que votre équipe dispose toujours de ce dont elle a besoin pour développer plus rapidement et plus intelligemment.
{{< details >}}
{{< /details >}}
Les administrateurs peuvent désormais définir des politiques réseau centralisées pour les flows distants de GitLab Duo Agent Platform directement dans les paramètres. Les administrateurs de groupe principal sur GitLab.com, et les administrateurs d'instance sur GitLab Self-Managed et Dedicated, peuvent configurer des listes de blocage et des listes d'autorisation de domaines à l'échelle de l'organisation que les projets héritent automatiquement. Un paramètre supplémentaire contrôle si les projets peuvent étendre la liste des domaines approuvés avec des entrées personnalisées. Les politiques sont appliquées au moment de l'exécution sur tous les flows distants, offrant aux équipes de sécurité et de plateforme une couche de gouvernance cohérente pour les sorties réseau des agents.
{{< details >}}
{{< /details >}}
La version minimale prise en charge de PostgreSQL est désormais la version 17. Si vous utilisez PostgreSQL 16 inclus dans le package, mettez à niveau le serveur PostgreSQL inclus avant d'installer GitLab 19.0.
{{< details >}}
{{< /details >}}
Ubuntu 20.04 a atteint la fin du support standard en mai 2025. À partir de GitLab 19.0, les packages Linux ne sont plus fournis pour Ubuntu 20.04. GitLab 18.11 est la dernière release avec des packages pour cette distribution. Avant de mettre à niveau vers GitLab 19.0, migrez vers Ubuntu 22.04 ou un autre système d'exploitation pris en charge.
{{< details >}}
{{< /details >}}
La prise en charge de Redis 6 est supprimée dans GitLab 19.0. Si vous utilisez un déploiement Redis 6 externe, migrez vers Redis 7.2 ou Valkey 7.2 avant la mise à niveau. Le Redis inclus dans le package Linux utilise Redis 7 depuis GitLab 16.2 et n'est pas affecté.
{{< details >}}
{{< /details >}}
Mattermost inclus est supprimé du package Linux dans GitLab 19.0. Si vous utilisez actuellement Mattermost inclus, consultez Migration du package Linux vers Mattermost Standalone pour obtenir des instructions de migration. Les clients n'utilisant pas Mattermost inclus ne sont pas impactés.
{{< details >}}
{{< /details >}}
La prise en charge du package Linux pour les distributions SUSE prend fin dans GitLab 19.0, ce qui affecte openSUSE Leap 15.6, SUSE Linux Enterprise Server 12.5 et SUSE Linux Enterprise Server 15.6. GitLab 18.11 est la dernière version avec des packages Linux pour ces distributions. Pour continuer à utiliser les distributions SUSE, migrez vers un déploiement Docker de GitLab.
{{< details >}}
{{< /details >}}
Spamcheck est supprimé du package Linux et du chart Helm GitLab dans GitLab 19.0. Les clients n'utilisant pas actuellement Spamcheck ne sont pas impactés. Si vous utilisez Spamcheck inclus, vous pouvez le déployer séparément en utilisant Docker. Aucune migration de données n'est requise.
{{< details >}}
{{< /details >}}
Gateway API avec Envoy Gateway devient la configuration réseau par défaut dans le chart Helm GitLab dans GitLab 19.0, remplaçant NGINX Ingress qui a atteint sa fin de vie en mars 2026. Si la migration vers Envoy Gateway n'est pas immédiatement réalisable, vous pouvez réactiver explicitement le NGINX Ingress inclus, qui reste disponible jusqu'à sa suppression prévue dans GitLab 20.0. Cette modification n'affecte pas le NGINX utilisé dans le package Linux, ni les instances de chart Helm utilisant un Ingress géré en externe ou un contrôleur Gateway API.
{{< details >}}
{{< /details >}}
Les charts Bitnami PostgreSQL, Bitnami Redis et MinIO inclus sont supprimés du chart Helm GitLab et de l'opérateur GitLab dans GitLab 19.0 sans remplacement. Ces composants étaient destinés uniquement aux environnements de preuve de concept et de test et ne sont pas recommandés pour une utilisation en production. Si vous exécutez une instance avec l'un de ces services inclus, suivez le guide de migration pour configurer des services externes avant de mettre à niveau vers GitLab 19.0.
{{< details >}}
{{< /details >}}
Pour les organisations gérant un grand nombre d'utilisateurs via SCIM, le déprovisionnement des membres du groupe pouvait expirer et renvoyer des erreurs 500. Les requêtes SCIM DELETE et PATCH renvoient désormais immédiatement une réponse de succès. La suppression des membres est gérée de manière asynchrone, de sorte que les fournisseurs d'identité et les clients SCIM reçoivent des réponses de succès cohérentes.
{{< details >}}
{{< /details >}}
La remédiation automatique pour les dépendances est désormais disponible en tant qu'expérience dans GitLab 19.0. Lorsque l'analyse des dépendances détecte une dépendance Ruby vulnérable avec un correctif connu, GitLab ouvre automatiquement une merge request pour la mettre à jour vers une version sûre sans intervention humaine. Seuls les projets Ruby sont pris en charge dans l'expérience.
Après chaque pipeline, GitLab identifie la vulnérabilité de la plus haute gravité avec un correctif ou une mise à niveau de version mineure disponible. GitLab génère la modification du fichier manifeste et ouvre une merge request via un compte de service. La merge request passe ensuite par le workflow standard de revue et d'approbation de votre projet.
Pendant l'expérience, jusqu'à trois merge requests de remédiation automatique peuvent être ouvertes par projet à la fois.
Pour partager vos commentaires ou demander à participer à l'expérience, laissez un commentaire sur l'epic 600511. Pour activer l'expérience sur votre projet, un membre de l'équipe GitLab doit activer le feature flag dependency_management_auto_remediation pour votre projet.
{{< details >}}
{{< /details >}}
GitLab 18.11 a introduit des profils de configuration de sécurité pour SAST et la détection des secrets. Désormais, l'analyse des dépendances est également disponible avec le profil Dependency Scanning - Default. Ce profil vous offre une surface de contrôle unifiée pour appliquer une couverture SCA standardisée à tous vos projets sans modifier un seul fichier de configuration CI/CD.
Le profil active deux déclencheurs d'analyse :
{{< details >}}
{{< /details >}}
L'analyse des dépendances GitLab utilisant SBOM génère désormais automatiquement un graphe de dépendances (gradle.graph.txt) pour les projets Gradle. Auparavant, l'analyse des dépendances Gradle nécessitait que vous génériez manuellement un graphe de dépendances dans le cadre de votre build. Désormais, lorsqu'un fichier de graphe n'est pas disponible, l'analyseur en génère un automatiquement, supprimant cette étape manuelle pour les projets Java et Kotlin utilisant Gradle.
{{< details >}}
{{< /details >}}
Les entrées CI/CD disposent désormais d'une meilleure prise en charge des tableaux. Utilisez l'opérateur d'index de tableau [] pour accéder à des éléments spécifiques dans les entrées CI/CD de type tableau. Cette amélioration offre des capacités d'interpolation d'entrées CI/CD plus flexibles et plus puissantes dans vos configurations de pipeline, vous permettant de référencer directement des éléments individuels d'un tableau sans étapes de traitement supplémentaires.
{{< details >}}
{{< /details >}}
Auparavant, vous ne pouviez sélectionner qu'une seule valeur lors de la sélection des options d'entrée CI/CD dans l'interface, ce qui limitait la flexibilité pour les pipelines avec des options plus complexes.
Désormais, lorsque vous exécutez un pipeline avec des entrées CI/CD depuis l'interface, vous pouvez sélectionner plusieurs valeurs dans une liste déroulante et les valeurs sélectionnées sont combinées dans un tableau, par exemple ["option1","option2"]. Cela facilite le redémarrage de services sur plusieurs instances, la création de plusieurs images Docker, l'exécution de tests avec plusieurs combinaisons de tags ou toute opération sur plusieurs cibles dans une seule exécution de pipeline.
{{< details >}}
{{< /details >}}
Lorsque vous gérez un composant CI/CD dans le catalogue CI/CD GitLab, les détails d'utilisation sont essentiels pour gérer les mises à niveau, appliquer la conformité et communiquer les changements non rétrocompatibles. Vous devez savoir quels projets utilisent vos composants CI/CD et quelles versions ils utilisent. Auparavant, ces informations n'étaient pas disponibles, ce qui rendait difficile la notification des bons mainteneurs, la planification des dépréciations en toute sécurité ou la garantie que les projets restent à jour avec les derniers correctifs de sécurité.
La vue des détails d'utilisation des composants CI/CD dans la page des ressources du catalogue affiche désormais exactement quels projets utilisent chaque composant CI/CD, la version qu'ils exécutent et s'ils disposent de la dernière version ou d'une version obsolète. Les projets utilisant des versions plus anciennes sont mis en avant, afin que vous puissiez prioriser la communication, encourager l'adoption des correctifs de sécurité et assurer une mise à niveau en douceur dans toute votre organisation.
{{< details >}}
{{< /details >}}
Dans les versions précédentes de GitLab, vous ne pouviez pas modifier le maximum de 20 pipelines parallèles dans un merge train, ce qui vous forçait soit à surcharger vos runners, soit à abandonner complètement les merge trains. Vous pouvez désormais configurer la limite de pipelines parallèles par merge train pour équilibrer la charge des runners et le débit de fusion. Vous pouvez définir la limite par projet ou à l'échelle de l'instance. Définir la limite à 1 signifie que chaque merge request s'exécute une à la fois, par rapport à une branche cible propre.
Merci à Norman Debald (@Modjo85) pour cette contribution communautaire.
{{< details >}}
{{< /details >}}
Dans les versions précédentes de GitLab, le titre par défaut d'une nouvelle merge request provenait de la branche source ou du premier commit, et vous ne pouviez pas imposer une convention de nommage cohérente dans votre projet.
Vous pouvez désormais configurer un modèle de titre de merge request par défaut par projet. Les modèles prennent en charge des variables pour la branche source, la branche cible, le sujet du premier commit, l'identifiant du ticket lié, le titre du ticket et une version lisible par l'homme du nom de la branche source. Par exemple, le modèle Resolve %{issue_id} "%{issue_title}" produit des titres tels que Resolve 123 "Fix login bug". Vous pouvez toujours modifier le titre avant de créer la merge request.
{{< details >}}
{{< /details >}}
L'en-tête X-Gitlab-Token existant envoie un secret statique en texte clair, rendant les webhooks susceptibles d'être interceptés et rejoués.
Vous pouvez désormais ajouter un jeton de signature à n'importe quel webhook. GitLab utilise le jeton de signature pour calculer une signature HMAC-SHA256 sur :
GitLab envoie ensuite le résultat dans l'en-tête webhook-signature avec les en-têtes webhook-id et webhook-timestamp, conformément à la spécification Standard Webhooks.
Vous pouvez recalculer la signature pour confirmer que les requêtes proviennent bien de GitLab et que la charge utile n'a pas été modifiée. En validant également l'horodatage, vous pouvez rejeter les requêtes rejouées.
Merci à Van Anderson et Norman Debald pour leurs contributions communautaires !
{{< details >}}
{{< /details >}}
Dans les versions précédentes de GitLab, vous ne pouviez utiliser un jeton de job CI/CD (CI_JOB_TOKEN) que pour pousser vers le même dépôt où le pipeline s'exécute. Les pushs entre projets nécessitaient un jeton d'accès personnel ou un jeton de déploiement.
Vous pouvez désormais utiliser un jeton de job pour pousser vers un autre projet lorsque :
Cette fonctionnalité est protégée par le feature flag allow_push_to_allowlisted_projects, désactivé par défaut dans GitLab 19.0. Demandez à votre administrateur de l'activer.
{{< details >}}
{{< /details >}}
GitLab utilise désormais Mermaid version 11 pour le rendu des diagrammes en Markdown.
Auparavant, GitLab prenait en charge Mermaid version 10. Avec cette mise à niveau, vous avez accès à tous les nouveaux types de diagrammes, améliorations de syntaxe et corrections de bugs introduits dans Mermaid 11, notamment un rendu amélioré pour les organigrammes, les diagrammes de séquence et plus encore.
{{< details >}}
{{< /details >}}
Dans les versions précédentes de GitLab, vous deviez attendre que l'onglet Modifications charge tous les fichiers avant de pouvoir commencer la revue, ce qui ralentissait les grandes revues.
Vous pouvez désormais utiliser Rapid Diffs pour revoir les merge requests avec un chargement initial plus rapide, un défilement plus fluide et des interactions plus réactives entre les fichiers. Rapid Diffs utilise la même technologie qui alimente déjà la page des commits.
Rapid Diffs est en bêta. Certaines fonctionnalités de l'expérience de diff classique ne sont pas encore disponibles. Vous pouvez revenir à tout moment.
Regardez la vidéo de présentation et partagez votre expérience dans le ticket de retour.
{{< details >}}
{{< /details >}}
Nous publions également GitLab Runner 19.0 aujourd'hui ! GitLab Runner est l'agent de build hautement évolutif qui exécute vos jobs CI/CD et envoie les résultats à une instance GitLab. GitLab Runner fonctionne en conjonction avec GitLab CI/CD, le service d'intégration continue open source inclus avec GitLab.
job_executionFF_SCRIPTS_TO_STEPSSignatureDoesNotMatch lors du téléchargement du cache S3amd64, arm64, arm et armhf dans GitLab Runner 18.9.0 et versions ultérieuresLa liste de toutes les modifications se trouve dans le CHANGELOG de GitLab Runner.