Grâce à ce partenariat, GitLab Duo Agent Platform automatise l'orchestration du développement logiciel et la gestion du contexte du cycle de vie via son intégration à Vertex AI sur Google Cloud, qui alimente la couche de modèles pour les appels d'agents. Les équipes continuent de travailler sur les tickets, les merge requests, les pipelines et les workflows de sécurité, tandis que l'inférence suit la posture Google Cloud qu'elles ont déjà définie.

Les avancées des modèles Vertex AI de Google Cloud élargissent les possibilités d'utilisation de GitLab Duo Agent Platform pour les clients Google Cloud. Ces derniers bénéficient d'un plan de contrôle DevSecOps alimenté par l'IA dans GitLab, soutenu par une infrastructure d'IA en constante évolution dans Vertex AI, ainsi que par les options de déploiement et d'intégration flexibles de GitLab Duo Agent Platform. Cette combinaison permet des workflows agentiques plus performants et mieux gouvernés, opérant à l'échelle de l'entreprise.

Des agents qui interviennent tout au long du cycle de vie

De nombreux outils d'IA se concentrent sur une seule tâche : accélérer la génération de code. GitLab Duo Agent Platform va plus loin. La plateforme orchestre des agents d'IA sur l'ensemble du cycle de vie du développement logiciel (SDLC), de la planification à la livraison en passant par les contrôles de sécurité, et ce pour de nombreuses équipes travaillant sur de multiples projets et releases. À cette échelle, les assistants d'IA pour le code sont indispensables à l'innovation continue, mais ne suffisent pas à eux seuls.

Les assistants de codage à usage unique ont rarement une vision complète de l'état d'un projet. Le backlog, les merge requests en attente, les jobs en échec et les résultats de sécurité sont disponibles dans GitLab, mais une fenêtre de chat distincte dans un assistant de codage n'hérite pas de cette vue d'ensemble du SDLC. Ce manque se traduit par des transferts manuels, des explications répétées à une IA dépourvue de contexte, et des équipes de gouvernance qui tentent de cartographier les flux de données entre des outils qui n'ont jamais été conçus comme un système unifié.

GitLab Duo Agent Platform contribue à combler ce fossé en exécutant des agents et des flows sur les mêmes objets que ceux utilisés quotidiennement par les équipes d'ingénierie. Vertex AI fournit ensuite les modèles et services que ces agents sollicitent lorsque Google Cloud est votre environnement d'inférence de référence, la passerelle d'IA (AI-Gateway) de GitLab gérant les accès afin que les administrateurs disposent d'une cartographie claire des connexions. Par exemple, l'agent Planner analyse les backlogs, décompose les epics en tâches structurées et applique des frameworks de priorisation pour aider les équipes à décider de ce qu'elles doivent développer ensuite. L'agent Security Analyst trie les vulnérabilités, détaille les risques en langage clair et recommande des mesures correctives par ordre de priorité. Des flows intégrés connectent ces agents au sein de processus de bout en bout, sans que les équipes de développement aient à gérer chaque transfert manuellement.

Agentic Chat dans GitLab Duo Agent Platform offre une expérience unifiée pour les équipes de développement. Elles formulent des requêtes en langage naturel pour obtenir des réponses contextuelles basées sur un raisonnement multi-étapes qui s'appuie sur l'état complet d'un projet : ses tickets, ses merge requests, ses pipelines, ses résultats de sécurité et son code source. GitLab servant de système d'enregistrement pour le SDLC avec un modèle de données unifié, les agents GitLab Duo opèrent dans un contexte de cycle de vie qui échappe aux assistants d'IA autonomes et spécifiques à un outil.

Amplifiés par Vertex AI

GitLab Duo Agent Platform est conçue pour offrir une flexibilité en matière de modèles, en attribuant différentes capacités à différents modèles en fonction de ceux qui offrent les meilleures performances pour une tâche donnée. Ce choix architectural porte ses fruits sur Google Cloud, où Vertex AI joue le rôle d'environnement géré pour les modèles de base et les services associés, offrant un vaste écosystème de modèles et une infrastructure gérée qui contribuent à repousser encore plus loin les capacités de la plateforme.

Les dernières générations de modèles d'IA disponibles via Vertex AI apportent des améliorations significatives en matière de raisonnement, d'utilisation des outils et de compréhension des contextes longs par rapport aux versions précédentes. Des propriétés sur lesquelles s'appuient les agents de GitLab sur de nombreux projets et équipes disposant de codes sources volumineux et complexes. Des fenêtres de contexte plus longues et une intégration plus riche des outils dans les modèles sous-jacents élargissent ce que les agents peuvent accomplir en une seule action, ce qui est particulièrement important pour des charges de travail telles que l'analyse approfondie du backlog ou le contrôle de sécurité d'un monorepo.

Vertex AI Model Garden, avec son accès à un large éventail de modèles de base, offre aux clients la flexibilité nécessaire pour effectuer ces choix en fonction des performances, des coûts et des exigences réglementaires, plutôt que d'être contraints par un fournisseur unique.

Par ailleurs, les clients de GitLab peuvent utiliser Bring Your Own Model (BYOM) pour GitLab Duo Agent Platform, afin que les fournisseurs et les passerelles approuvés s'intègrent là où votre modèle de sécurité l'exige. L'article sur GitLab Duo Agent Platform Self-Hosted et BYOM décrit le fonctionnement de cette configuration. Grâce à cette option de déploiement, les clients accèdent à un plus large éventail d'options de modèles qu'ils peuvent adapter à leur processus de développement logiciel : le bon modèle pour le bon workflow, avec les bonnes mesures de protection.

Pour GitLab, la décision de s'appuyer sur Vertex AI a été motivée par le besoin d'une fiabilité de niveau entreprise et d'une gamme de modèles inégalée. Vertex AI et Model Garden prennent entièrement en charge les aspects les plus complexes de l'hébergement des grands modèles de langage (LLM), ce qui signifie que la livraison rapide de versions, la robustesse de la sécurité et la rigueur de la gouvernance sont intégrées de façon transparente dans l'intégration. Au-delà de l'offre de modèles Gemini, Vertex AI offre un accès mondial à faible latence à un vaste catalogue de modèles tiers et open source.

Combiné à l'approche de pointe de Google Cloud en matière de confidentialité des données et de protection des modèles, Vertex AI s'est imposé comme le choix évident pour alimenter l'expérience développeur nouvelle génération de GitLab.

En intégrant Vertex AI Model Garden à son backend, GitLab renforce considérablement sa plateforme DevSecOps sans en répercuter la complexité sur les utilisateurs. Les équipes de développement n'ont pas à évaluer ni à gérer les LLM sous-jacents ; elles bénéficient au contraire d'un workflow simplifié et assisté par l'IA pour construire leurs applications.

GitLab gère entièrement l'orchestration cloud, permettant aux équipes de développement de se concentrer pleinement sur l'écriture d'un code de qualité, tandis que Vertex AI alimente les fonctionnalités qui les accompagnent.

Ce que cela signifie pour les clients Google Cloud

GitLab Duo Agent Platform fournit déjà des agents d'IA qui opèrent sur l'ensemble du cycle de vie logiciel au sein d'un système d'enregistrement unique et gouverné. Sur Google Cloud, la plateforme favorise une innovation rapide à mesure que Vertex AI continue de faire évoluer les couches de modèles et d'infrastructure.

Pour les clients Google Cloud, cette intégration se traduit par une livraison logicielle rationalisée tout en maintenant une gouvernance d'entreprise stricte. Pour les équipes d'ingénierie de plateforme, cela signifie normaliser les modèles Vertex qui alimentent les suggestions, les analyses et les corrections dans GitLab, plutôt que de répertorier des dizaines d'outils côté client. Les programmes de sécurité en bénéficient lorsque les agents proposent et valident des correctifs au même endroit où les équipes trient déjà les résultats, réduisant ainsi les changements de contexte et les tâches qui s'échapperaient autrement vers des canaux non gérés.

Du point de vue de l'économie et des politiques cloud, orienter l'inférence des agents vers Vertex depuis GitLab maintient l'utilisation à proximité des accords et contrôles déjà en place sur Google Cloud, ce qui contribue à éviter les dépenses redondantes et les chemins parallèles qui contournent les processus d'approvisionnement.

Vertex AI étant un fournisseur d'infrastructure sous-jacente de GitLab Duo Agent Platform, les organisations peuvent considérablement accroître la productivité de leurs équipes de développement sans les contraintes et les risques liés à la gestion de chaînes d'outils d'IA fragmentées. Les équipes restent alignées au sein d'un système d'enregistrement unique et sécurisé, ce qui leur permet de construire des applications plus rapidement et de livrer en toute confiance.

La collaboration entre GitLab et Google Cloud se construit depuis 2018. Aujourd'hui, elle représente l'une des collaboration les plus complètes pour les organisations qui souhaitent passer d'expérimentations en matière d'IA à un développement logiciel agentique entièrement gouverné sur Google Cloud. À mesure que les deux plateformes continuent d'évoluer, GitLab en élargissant son orchestration d'agents et son contexte développeur, et Vertex AI en repoussant les limites des capacités des modèles et de l'infrastructure des agents, la valeur ajoutée pour les clients communs ne cessera de croître.

Commencer un essai gratuit de GitLab Duo Agent Platform pour découvrir la puissance de GitLab et Vertex AI sur Google Cloud.

Cette année, l'évaluation se distingue pour une raison précise : Omdia a élargi ses critères d'évaluation et, pour la première fois, les outils de développement d'IA ont été notés sur leur capacité à couvrir l'ensemble du cycle de vie logiciel, et non plus uniquement le codage. Cette évolution reflète la direction prise par l'évolution de l'IA et a bouleversé le classement des fournisseurs.

Téléchargez le rapport complet Omdia Universe.

À propos d'Omdia Universe

Omdia Universe positionne les fournisseurs selon deux axes : la Capacité de la solution, ainsi que la Stratégie et l'exécution, en distinguant trois niveaux : Leaders (les plus performants sur les deux axes, recommandés pour toute liste de présélection), Challengers (périmètre fonctionnel plus restreint ou maturité moins avancée) et Prospects (fournisseurs en phase de démarrage ou à positionnement adjacent).

Ce qui a changé dans l'évaluation de cette année

L'élargissement des critères d'Omdia reflète une réalité à laquelle les professionnels sont déjà confrontés. Les outils de codage basés sur l'IA ont considérablement augmenté la productivité des équipes de développement, et des applications qui nécessitaient autrefois plusieurs semaines de développement peuvent désormais être prototypées en un temps record. Toutefois, cette accélération au stade du codage ne se traduit pas automatiquement par une livraison plus rapide. Les backlogs de revue s'allongent. Les résultats de sécurité s'accumulent. Les déploiements nécessitent toujours une coordination entre des équipes qui utilisent des outils qui n'ont pas été conçus pour fonctionner ensemble.

Omdia a ainsi mis en lumière cette dynamique : les outils qui se démarquent sont ceux qui gèrent les tests, la sécurité, le déploiement et l'orchestration, pas uniquement la génération de code. Ce constat a motivé la décision d'élargir les critères d'évaluation et a permis de distinguer les Leaders des Challengers.

L'autre évolution majeure de ce rapport concerne la manière dont Omdia a traité l'IA agentique. L'évaluation 2026 a pondéré les capacités agentiques comme une dimension d'évaluation actuelle, et non comme une considération future. Cela inclut la capacité d'une plateforme à coordonner plusieurs tâches de manière autonome, à orchestrer les transferts entre agents spécialisés et à accompagner les équipes à différents stades d'adoption de l'IA agentique.

Les scores de GitLab

GitLab a obtenu les meilleurs scores de sa catégorie dans trois domaines :

Étendue de la solution : 100 %. Couverture de l'ensemble du SDLC au sein d'une seule plateforme, de la planification et des exigences jusqu'au déploiement et à la gestion des tickets. Cela inclut des phases du cycle de vie que la plupart des outils d'IA pour le codage ne couvrent pas. Par exemple, des agents préconfigurés tels que l'agent Planner et l'agent Security Analyst étendent l'assistance d'IA à la planification de sprint, au classement des vulnérabilités et aux recommandations de remédiation : autant d'étapes du cycle de vie où la livraison se retrouve réellement bloquée.

Stratégie et innovation : 88 %. Différenciation grâce à une orchestration de bout en bout, une architecture axée sur la confidentialité sans entraînement sur les données privées, et une prise en charge multi-modèles via des partenariats avec Anthropic, Google et AWS. Les équipes peuvent sélectionner les modèles adaptés à leurs charges de travail et à leurs exigences en matière de données. L'approche de la plateforme en matière de contexte unifié, où les agents collaborent entre les tickets, les merge requests, les pipelines et les résultats de sécurité sans perdre l'état, illustre l'innovation architecturale reconnue par Omdia dans cette catégorie.

Fonctionnalités principales : 82 %. Ce score reflète une couverture approfondie des étapes du cycle de vie où les équipes d'ingénierie passent la majeure partie de leur temps. Le code est généré à partir du contexte en temps réel de l'IDE et du code source, testé selon les dimensions unitaire, d'intégration et de sécurité, et revu avec une priorisation intégrée. L'automatisation DevOps prend en charge le CI/CD, GitOps et l'analyse des causes profondes pour les échecs de pipeline. Le tableau de bord d'impact de l'IA offre aux équipes une visibilité mesurable sur les délais de cycle, la fréquence de déploiement et les domaines où l'IA fait réellement progresser la productivité des équipes.

GitLab a également obtenu une reconnaissance de premier plan pour ses Fonctionnalités avancées (80 %) et l'Exécution fournisseur (88 %).

L'évolution du rôle des développeurs et des agents d'IA

L'une des conclusions les plus significatives du rapport d'Omdia porte sur l'évolution du rôle du développeur logiciel aux côtés de ces outils. Les équipes de développement sont de plus en plus composées d'ingénieurs en IA et de leurs agents d'IA, les ingénieurs assurant la supervision et la direction de l'IA agentique. Étant donné que l'IA génère la majeure partie du code, le rôle des équipes se déplace désormais vers la vérification du respect des exigences technologiques, le contrôle de la qualité, la mise en place de garde-fous appropriés, la conception de pipelines de production autonomes et la médiation entre les objectifs métier et l'utilisation de l'IA agentique tout au long du cycle de développement logiciel.

Cette évolution a des implications sur la façon dont les organisations évaluent leurs investissements en matière d'IA. Une équipe qui a automatisé la génération de code mais qui gère encore manuellement la revue, les tests et le déploiement n'a pas encore véritablement accéléré son innovation logicielle. Le gain de productivité lié à un codage plus rapide s'amplifie lorsque le reste du cycle de vie peut suivre le rythme. Il se réduit dans le cas contraire, et les goulots d'étranglement se déplacent en aval.

La conformité aux exigences des entreprises comme prérequis

Un point notable dans la manière dont Omdia a structuré son évaluation cette année : les contrôles et les garde-fous d'entreprise ne constituent plus une catégorie bonus. Les certifications de conformité, la flexibilité de déploiement et l'architecture axée sur la confidentialité sont désormais des attentes de base pour les plateformes classées Leader, et non des caractéristiques distinctives. Les organisations des secteurs réglementés et celles soumises à des exigences de souveraineté des données considèrent désormais ces facteurs comme des critères d'entrée.

La position de GitLab sur ces aspects met en évidence sa différenciation unique sur le marché : une plateforme certifiée SOC 2 et ISO 27001, une conception axée sur la confidentialité sans entraînement sur les données privées des clients pour ses capacités d'IA agentique, une prise en charge du déploiement auto-géré dans le cloud et sur site (y compris les environnements air-gapped), ainsi qu'une prise en charge des modèles d'IA auto-hébergés. Sa mise à disposition sous forme d'application SaaS monolocataire via GitLab Dedicated, avec l'autorisation FedRAMP Moderate via GitLab Dedicated for Government, renforce son leadership en matière de flexibilité de déploiement.

Le rapport d'Omdia a reconnu ces éléments non pas comme une liste de fonctionnalités, mais comme la preuve de la maturité de la plateforme pour les organisations où le niveau d'exigence en matière de conformité est le plus élevé : services financiers, secteur public, santé et autres secteurs réglementés qui ne peuvent faire aucun compromis sur la résidence des données ou l'auditabilité.

Évaluez votre niveau de maturité en matière de développement logiciel

Pour les équipes qui évaluent activement leur stratégie de développement avec l'IA, la recommandation d'Omdia est claire : GitLab doit figurer en tête de liste.

Pour la plupart des responsables techniques, la vraie question n'est pas de savoir quel outil d'IA génère le meilleur code, mais si le code généré peut être mis en production avec le plus haut niveau de qualité, de sécurité et de performance. Ce code doit être compris, gouverné et maintenu par les équipes logicielles qui en sont responsables. Avec GitLab, la vitesse de codage se traduit par une accélération de l'innovation.

Si vous souhaitez évaluer la maturité de votre organisation en matière de bonnes pratiques et d'évolution du développement logiciel, passez notre test et obtenez votre score personnalisé sur les thématiques suivantes : IA, DevOps et Sécurité.

Téléchargez le rapport complet Omdia Universe.

Dans ce guide, nous explorons les différents types d'analyse de conteneurs proposés par GitLab, vous expliquons comment les activer et vous partageons les configurations les plus courantes pour bien démarrer.

Qu'est-ce que l'analyse des conteneurs ?

Les vulnérabilités de sécurité présentes dans les images de conteneurs constituent un risque tout au long du cycle de vie applicatif. Les images de base, les paquets de systèmes d'exploitation et les dépendances applicatives peuvent tous receler des vulnérabilités activement exploitées par des attaquants. L'analyse des conteneurs permet de détecter ces risques en amont, avant qu'ils n'atteignent l'environnement de production, et propose des pistes de remédiation le cas échéant.

L'analyse des conteneurs est un élément essentiel de l'analyse de la composition logicielle (SCA), qui vous aide à comprendre et à sécuriser les dépendances externes dont vos applications conteneurisées dépendent.

5 types d'analyses de conteneurs dans GitLab

GitLab propose cinq approches distinctes d'analyse de conteneurs, chacune répondant à un objectif précis dans votre stratégie de sécurité.

1. Analyse des conteneurs dans le pipeline

• Fonctionnement : analyse les images de conteneurs lors de l'exécution du pipeline CI/CD afin de détecter les vulnérabilités avant le déploiement
• Cas d'utilisation idéal : contrôles de sécurité en amont (shift-left) pour bloquer les images vulnérables avant qu'elles n'atteignent la production
• Disponibilité : version gratuite de GitLab, GitLab Premium et GitLab Ultimate (avec des fonctionnalités supplémentaires dans GitLab Ultimate)
• Documentation

GitLab utilise le scanner de sécurité Trivy pour analyser les images de conteneurs et rechercher de vulnérabilités connues. Lors de l'exécution du pipeline, le scanner examine vos images et génère un rapport détaillé.

Activer l'analyse des conteneurs dans le pipeline

Option A : merge request préconfigurée

• Accédez à Sécurisation > Configuration de la sécurité dans votre projet.
• Repérez la ligne « Analyse de conteneurs ».
• Sélectionnez Configurer avec une merge request.
• Une merge request intégrant la configuration nécessaire est automatiquement créée.

Option B : configuration manuelle

• Ajoutez le contenu suivant à votre fichier .gitlab-ci.yml :

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

Configurations courantes

Analyser une image spécifique :

Pour analyser une image spécifique, remplacez la variable CS_IMAGE dans le job container_scanning.

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_IMAGE: myregistry.com/myapp:latest

Filtrer par seuil de gravité :

Pour n'afficher que les vulnérabilités dépassant un certain niveau de gravité, remplacez la variable CS_SEVERITY_THRESHOLD dans le job container_scanning. Dans l'exemple ci-dessous, seules les vulnérabilités d'un niveau de gravité Élevé ou supérieur seront affichées.

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_SEVERITY_THRESHOLD: "HIGH"

Consulter les vulnérabilités dans une merge request

L'affichage direct des vulnérabilités détectées par l'analyse des conteneurs au sein des merge requests rend les revues de sécurité plus fluides et plus efficaces. Une fois l'analyse des conteneurs configurée dans votre pipeline CI/CD, GitLab affiche automatiquement les vulnérabilités détectées dans le widget Sécurité de la merge request.

• Accédez à n'importe quelle merge request et faites défiler jusqu'à la section « Analyse de sécurité » pour obtenir un résumé des vulnérabilités nouvellement introduites et existantes détectées dans vos images de conteneurs.
• Cliquez sur une vulnérabilité pour accéder à des informations détaillées, notamment le niveau de gravité, les paquets affectés et les recommandations de remédiation disponibles.

Cette visibilité permet aux équipes de développement et de sécurité de détecter et de traiter les vulnérabilités des conteneurs avant qu'elles n'atteignent la production : la sécurité devient une composante à part entière du processus de revue de code plutôt qu'un contrôle distinct.

Consulter les vulnérabilités dans le rapport de vulnérabilités

Au-delà des revues dans les merge requests, GitLab met à disposition un rapport de vulnérabilités centralisé, qui offre aux équipes de sécurité une visibilité complète sur l'ensemble des résultats de l'analyse des conteneurs dans votre projet.

• Accédez à ce rapport via Sécurité et conformité > Rapport de vulnérabilités dans la barre latérale de votre projet.
• Vous y trouverez une vue agrégée de toutes les vulnérabilités de conteneurs détectées dans vos branches, avec des options de filtrage permettant de trier les vulnérabilités par gravité, statut, type de scanner ou image de conteneur spécifique.
• Cliquez sur une vulnérabilité pour accéder à sa page dédiée.

Les détails de la vulnérabilité indiquent précisément les images et couches de conteneurs concernées pour faciliter la traçabilité jusqu'à la source du problème. Vous pouvez assigner des vulnérabilités à des membres de l'équipe, modifier leur statut (détectée, confirmée, résolue, rejetée), ajouter des commentaires pour faciliter la collaboration et associer des tickets connexes pour suivre la remédiation.

Ce workflow transforme la gestion des vulnérabilités, autrefois cantonnée à des tableurs, en une composante intégrée de votre processus de développement, garantissant que les résultats de sécurité des conteneurs sont suivis, priorisés et résolus de manière systématique.

Consulter la liste des dépendances

La liste des dépendances de GitLab fournit une nomenclature logicielle complète (SBOM) qui répertorie chaque composant de vos images de conteneurs afin d'offrir une transparence totale sur votre chaîne d'approvisionnement logicielle.

• Accédez à Sécurité et conformité > Liste des dépendances pour consulter l'inventaire de tous les paquets, bibliothèques et dépendances détectés par l'analyse des conteneurs dans votre projet.
• Cet affichage répertorie les éléments qui s'exécutent réellement dans vos conteneurs, des paquets du système d'exploitation de base aux dépendances applicatives.

Vous pouvez filtrer la liste par gestionnaire de paquets, type de licence ou statut de vulnérabilité afin d'identifier rapidement les composants qui présentent des risques de sécurité ou des problèmes de conformité. Chaque entrée de dépendance affiche les vulnérabilités associées pour traiter les problèmes de sécurité dans le contexte des composants logiciels réels, plutôt que comme des résultats isolés.

2. Analyse des conteneurs pour le registre

• Fonctionnement : analyse automatiquement les images envoyées vers le registre de conteneurs de GitLab (GitLab Container Registry) avec le tag latest
• Cas d'utilisation idéal : surveillance continue des images du registre, sans déclenchement manuel du pipeline
• Disponibilité : GitLab Ultimate uniquement
• Documentation

Lorsque vous effectuez un push d'une image de conteneur avec le tag latest, le bot de politique de sécurité de GitLab déclenche automatiquement une analyse sur la branche par défaut. Contrairement à l'analyse dans le pipeline, cette approche fonctionne conjointement avec l'analyse continue des vulnérabilités pour surveiller les nouveaux avis de sécurité publiés.

Activer l'analyse des conteneurs pour le registre

1. Accédez à Sécurisation > Configuration de la sécurité.
2. Faites défiler jusqu'à la section Analyse des conteneurs pour le registre.
3. Activez la fonctionnalité.

Prérequis

• Rôle de Chargé de maintenance ou supérieur dans le projet
• Le projet ne doit pas être vide (au moins un commit sur la branche par défaut est requis)
• Les notifications du registre de conteneurs doivent être configurées
• La base de données de métadonnées des paquets doit être configurée (activée par défaut sur GitLab.com)

Les vulnérabilités apparaissent sous l'onglet Vulnérabilités du registre de conteneurs dans votre rapport de vulnérabilités.

3. Analyse multi-conteneurs

• Fonctionnement : analyse plusieurs images de conteneurs en parallèle au sein d'un même pipeline
• Cas d'utilisation idéal : architectures de microservices et projets avec plusieurs images de conteneurs
• Disponibilité : version gratuite de GitLab, GitLab Premium et GitLab Ultimate (actuellement en version bêta)
• Documentation

L'analyse multi-conteneurs utilise des pipelines enfants dynamiques pour exécuter des analyses simultanées afin de réduire considérablement le temps d'exécution global du pipeline lorsque plusieurs images doivent être analysées.

Activer l'analyse multi-conteneurs

1. Créez un fichier .gitlab-multi-image.yml à la racine de votre dépôt :

scanTargets:
  - name: alpine
    tag: "3.19"
  - name: python
    tag: "3.9-slim"
  - name: nginx
    tag: "1.25"

2. Incluez le template dans votre fichier .gitlab-ci.yml :

include:
  - template: Jobs/Multi-Container-Scanning.latest.gitlab-ci.yml

Configuration avancée

Analyser des images depuis des registres privés :

auths:
  registry.gitlab.com:
    username: ${CI_REGISTRY_USER}
    password: ${CI_REGISTRY_PASSWORD}

scanTargets:
  - name: registry.gitlab.com/private/image
    tag: latest

Inclure les informations de licence :

includeLicenses: true

scanTargets:
  - name: postgres
    tag: "15-alpine"

4. Analyse continue des vulnérabilités

• Fonctionnement : crée automatiquement des vulnérabilités lors de la publication de nouveaux avis de sécurité, sans nécessiter l'exécution de pipeline
• Cas d'utilisation idéal : surveillance proactive de la sécurité entre les déploiements
• Disponibilité : GitLab Ultimate uniquement
• Documentation

L'analyse traditionnelle ne détecte les vulnérabilités qu'au moment où elle est effectuée. Mais que se passe-t-il lorsqu'une nouvelle vulnérabilité et exposition commune (CVE) est publiée le lendemain pour un paquet analysé la veille ? L'analyse continue des vulnérabilités résout ce problème en surveillant la base de données d'avis de GitLab et en enregistrant automatiquement les vulnérabilités lorsque de nouveaux avis affectent vos composants.

Fonctionnement

1. Votre job d'analyse des conteneurs ou d'analyse des dépendances génère une SBOM CycloneDX.
2. GitLab enregistre les composants de votre projet à partir de cette SBOM.
3. Lors de la publication de nouveaux avis, GitLab vérifie si vos composants sont concernés.
4. Les vulnérabilités sont automatiquement créées dans votre rapport de vulnérabilités.

Points importants

• Les analyses s'exécutent via des jobs en arrière-plan (Sidekiq), et non via des pipelines CI.
• Seules les alertes publiées au cours des 14 derniers jours sont prises en compte pour la détection de nouveaux composants.
• Les vulnérabilités utilisent « GitLab SBoM Vulnerability Scanner » comme nom de scanner.
• Pour marquer des vulnérabilités comme résolues, vous devez toujours exécuter une analyse basée sur un pipeline.

5. Analyse opérationnelle des conteneurs

• Fonctionnement : analyse les conteneurs en cours d'exécution dans votre cluster Kubernetes selon une cadence planifiée
• Cas d'utilisation idéal : surveillance de la sécurité après déploiement et détection des vulnérabilités au moment de l'exécution
• Disponibilité : GitLab Ultimate uniquement
• Documentation

L'analyse opérationnelle des conteneurs comble l'écart entre la sécurité au moment du build et la sécurité à l'exécution. Grâce à l'agent GitLab pour Kubernetes, cette approche analyse les conteneurs réellement en cours d'exécution dans vos clusters pour détecter les vulnérabilités qui apparaissent après le déploiement.

Activer l'analyse opérationnelle des conteneurs

Si vous utilisez l'agent GitLab pour Kubernetes, vous pouvez ajouter le contenu suivant à votre fichier de configuration de l'agent :

container_scanning:
  cadence: '0 0 * * *'  # Daily at midnight
  vulnerability_report:
    namespaces:
      include:
        - production
        - staging

Vous pouvez également créer une politique d'exécution des analyses qui impose une analyse selon un planning défini par l'agent GitLab pour Kubernetes.

Consulter les résultats

• Accédez à Opération > Clusters Kubernetes.
• Sélectionnez l'onglet Agent et choisissez votre agent.
• Sélectionnez ensuite l'onglet Sécurité pour consulter les vulnérabilités du cluster.
• Les résultats apparaissent également sous l'onglet Vulnérabilités opérationnelles dans le rapport de vulnérabilités.

Renforcer la posture de sécurité avec les politiques de sécurité de GitLab

Les politiques de sécurité de GitLab vous permettent d'appliquer des normes de sécurité cohérentes dans l'ensemble de vos workflows de conteneurs, grâce à des contrôles automatisés pilotés par des politiques. Ces politiques intègrent la sécurité en amont en intégrant les exigences directement dans votre pipeline de développement afin de garantir que les vulnérabilités sont détectées et traitées avant que le code n'atteigne l'environnement de production.

Politiques d'exécution des scans et des pipelines

Les politiques d'exécution des scans automatisent le moment et la manière dont l'analyse des conteneurs s'exécute dans vos projets. Définissez des politiques qui déclenchent des analyses de conteneurs sur chaque merge request, planifiez des analyses récurrentes de votre branche principale, et plus encore. Ces politiques assurent une couverture complète sans que les équipes de développement aient à configurer manuellement l'analyse dans le pipeline CI/CD de chaque projet.

Vous pouvez préciser les versions de scanner à utiliser et configurer les paramètres de scan de manière centralisée pour garantir la cohérence dans toute votre organisation tout en vous adaptant aux nouvelles menaces qui pèsent sur la sécurité des conteneurs.

Les politiques d'exécution des pipelines offrent des contrôles flexibles pour injecter (ou remplacer) des jobs personnalisés dans un pipeline en fonction de vos besoins en matière de conformité.

Ces politiques permettent d'injecter automatiquement des jobs d'analyse des conteneurs dans votre pipeline, de faire échouer les builds lorsque les vulnérabilités de conteneurs dépassent votre seuil de tolérance au risque, de déclencher des contrôles de sécurité supplémentaires pour des branches ou des tags spécifiques, ou encore d'imposer des exigences de conformité pour les images de conteneurs destinées aux environnements de production. Les politiques d'exécution des pipelines agissent comme des garde-fous automatisés pour appliquer vos normes de sécurité de manière cohérente dans l'ensemble de vos déploiements de conteneurs, sans intervention manuelle.

Politiques d'approbation des merge requests

Les politiques d'approbation des merge requests imposent des contrôles de sécurité : les approbateurs désignés examinent et valident les merge requests contenant des vulnérabilités de conteneurs.

Configurez des politiques qui bloquent le merge lorsque des vulnérabilités de gravité critique ou élevée sont détectées, ou qui exigent l'approbation de l'équipe de sécurité pour toute merge request introduisant de nouveaux résultats liés aux conteneurs. Ces politiques empêchent les images de conteneurs vulnérables de progresser dans votre pipeline tout en préservant la vélocité de développement pour les changements à faible risque.

Choisir la bonne approche

Pour une approche complète en matière de sécurité, combinez plusieurs approches : l'analyse dans le pipeline pour détecter les problèmes pendant le développement, l'analyse des conteneurs pour le registre afin d'assurer une surveillance continue et l'analyse opérationnelle pour la visibilité en production.

Lancez-vous dès aujourd'hui

Activez l'analyse dans le pipeline pour commencer à appliquer des mesures de sécurité dans les conteneurs :

1. Accédez à Sécurisation > Configuration de la sécurité dans votre projet.
2. Cliquez sur Configurer avec une merge request pour lancer l'analyse des conteneurs.
3. Fusionnez la merge request.
4. Votre prochain pipeline inclura l'analyse des vulnérabilités.

Ajoutez ensuite des analyses supplémentaires en fonction de vos exigences de sécurité et de votre abonnement GitLab.

La sécurité des conteneurs n'est pas une tâche ponctuelle, mais un processus continu. Grâce aux capacités complètes d'analyse des conteneurs de GitLab, vous pouvez détecter les vulnérabilités à chaque étape du cycle de vie de vos conteneurs, du build à l'exécution.

Pour en savoir plus sur la façon dont GitLab peut contribuer à renforcer votre posture de sécurité, consultez la page sur les solutions de sécurité et de gouvernance de GitLab.

Bien que les assistants IA pour le code aient accéléré la productivité individuelle des équipes, ils fonctionnent souvent en marge du workflow de développement global. Ce manque d'intégration oblige les développeurs à basculer constamment entre différents outils, à traduire manuellement les suggestions de l'IA en code exploitable et à consacrer un temps précieux à des tâches répétitives qui pourraient être automatisées.

GitLab Duo Agent Platform résout ce problème en offrant une intégration transparente avec des modèles d'IA externes comme Claude d'Anthropic, Codex d'OpenAI et bien d'autres encore.

En créant des agents externes au sein de GitLab Duo Agent Platform, les organisations peuvent personnaliser les capacités de l'IA selon leurs besoins, workflows et normes spécifiques, directement dans l'environnement GitLab qu'elles connaissent. Les agents comprennent le contexte de votre projet, respectent vos normes de code et peuvent accomplir de manière autonome des tâches complexes en plusieurs étapes, de l'idée initiale au code prêt pour la production.

Regardez cette démonstration vidéo et suivez les étapes ci-dessous pour vous lancer :

Cas d'utilisation concrets

Voici trois cas d'utilisation qui illustrent comment les agents externes transforment le cycle de vie du développement :

1. De l'idée au code

En partant d'un projet vide et d'une description détaillée du ticket, l'agent externe (dans ce cas, Claude) prend en charge l'intégralité du développement de l'application. Le titre du ticket correspond à l'application souhaitée et la description énumère ses spécifications.

L'agent lit le contexte (informations du projet, ressources associées, etc.), analyse les exigences détaillées dans le ticket, génère une application web Java full stack avec les composants d'interface utilisateur appropriés, implémente la logique métier avec les taux d'intérêt indiqués et crée une merge request comprenant l'ensemble du code prêt à être révisé.

L'application générée inclut des classes Java backend, des fichiers HTML/CSS/JavaScript frontend et la configuration du build en fonction des spécifications du ticket d'origine. Les équipes peuvent ensuite tester l'application localement, vérifier les fonctionnalités et continuer à itérer avec l'agent par le biais d'une conversation en langage naturel.

2. Revue de code

L'assurance qualité ne se limite pas à la génération de code. Dans le deuxième cas d'utilisation, le même agent externe effectue une revue de code complète de l'application qu'il a créée. En mentionnant l'agent dans un commentaire de la merge request, les équipes reçoivent une analyse détaillée comprenant les points forts du code, les problèmes critiques, les préoccupations de priorité moyenne, les améliorations mineures, les évaluations de sécurité, les notes de test, les métriques du code et les recommandations accompagnées d'un statut d'approbation. Ce processus de revue automatisée garantit la cohérence et détecte les problèmes potentiels avant qu'ils n'atteignent la production. Il permet aussi de libérer les développeurs expérimentés pour qu'ils se concentrent sur les décisions architecturales plutôt que sur les inspections routinières du code.

3. Création d'un pipeline pour construire une image de conteneur

Le dernier cas d'utilisation se concentre sur une lacune courante : l'automatisation du déploiement. Lorsque la merge request ne dispose pas de pipeline CI/CD, les équipes peuvent simplement demander à l'agent externe d'en créer un. L'agent génère une configuration de pipeline complète qui construit l'application, crée un Dockerfile au moyen d'images de base adaptées à la version Java du projet, construit une image Docker et la déploie dans le registre de conteneurs intégré de GitLab. Le pipeline s'exécute automatiquement et suit les étapes de build, de création d'image Docker et de déploiement dans le registre sans configuration ni intervention manuelle.

Résumé

Avec ses agents externes, GitLab Duo Agent Platform représente un changement fondamental dans la manière dont les organisations abordent le développement logiciel. En remédiant à l'isolation des outils d'IA et à la fragmentation des workflows, les agents externes offrent une automatisation intelligente directement dans les plateformes que les équipes utilisent déjà. Plutôt que de traiter l'IA comme un assistant de codage séparé, GitLab Duo Agent Platform intègre de manière transparente des modèles externes comme Claude dans votre workflow GitLab, pour que les agents puissent comprendre le contexte complet du projet, respecter les normes de l'organisation et gérer en toute autonomie des tâches complexes à chaque étape du SDLC.

La proposition de valeur est claire : les équipes de développement accélèrent les délais de livraison, maintiennent une qualité de code cohérente, réduisent le travail répétitif et libèrent les ingénieurs expérimentés afin qu'ils se concentrent sur l'innovation plutôt que sur les tâches routinières. De la génération de code prêt pour la production basée sur des descriptions de tickets à la réalisation de revues de code approfondies et à l'automatisation des pipelines de déploiement, les agents externes deviennent des collaborateurs de confiance qui comprennent les besoins et normes spécifiques de votre organisation.

Découvrez comment votre équipe peut livrer plus rapidement et maintenir une qualité de code supérieure sans changer de contexte tout au long du cycle de vie du développement logiciel. Essayez GitLab Duo Agent Platform dès aujourd'hui. Ensuite, consultez notre article « Démarrer avec GitLab Duo Agent Platform : le guide complet ».

Cet article de blog est un résumé de notre démo animée par Chloé Cartron (Senior Solutions Architect) et Benjamin Skierlak (Customer Success Engineer, EMEA) lors du Forum InCyber 2026.

Les équipes sécurité applicative font face à une équation de plus en plus difficile à résoudre avec un volume croissant de code, de failles et de contraintes réglementaires, sans pour autant voir leurs effectifs augmenter. L'intelligence artificielle est souvent présentée comme la solution miracle, mais encore faut-il l'intégrer de façon structurée et maîtrisée dans les processus existants.

Découvrez dans cet article comment l'orchestration d'agents d’IA au sein d'une plateforme DevSecOps unifiée transforme le quotidien des équipes AppSec, de la gestion du backlog de vulnérabilités jusqu'à la génération de rapports de conformité.

🎯 Essayez GitLab Duo Agent Platform dès aujourd'hui !

Le paradoxe de l'IA dans le développement logiciel

L'intelligence artificielle a profondément transformé la façon dont les équipes de développement conçoivent et produisent leurs applications. IDE, CLI, assistants de code ou encore générateurs d'applications : il est désormais possible de produire des milliers de lignes de code par jour. Une vélocité sans précédent, mais qui dissimule un problème structurel majeur.

Car plus le code s'écrit vite, plus la surface d'attaque s'étend, et les équipes sécurité n’augmentent pas proportionnellement, puisqu’en moyenne 4 personne sont dédiées à la sécurité pour 100 développeurs. Résultat, les backlogs de vulnérabilités s'accumulent, les délais de remédiation s'allongent, et la conformité devient un chantier sans fin.

C'est ce que nous appelons le paradoxe de l'IA : la vitesse, seule, n'est pas un avantage si elle engendre une dette de sécurité incontrôlable.

La réponse ne réside donc pas dans un ralentissement du développement, mais dans un changement de paradigme : utiliser l'IA non plus seulement pour écrire du code, mais pour orchestrer la sécurité à chaque étape du cycle de vie logiciel.

Une plateforme unifiée pour mettre fin à la fragmentation des outils

La fragmentation des outils d’IA constitue l'un des problèmes structurels les plus répandus au sein des équipes AppSec. À chaque changement d'outil, le contexte se perd, et des agents d’IA qui ne partagent pas de contexte commun reproduisent la fragmentation des outils.

C'est pourquoi l'approche de GitLab repose sur un modèle de données unifié où le code, les pipelines, les issues, les merge requests et les résultats de scan coexistent dans un seul et même environnement. Les agents disposent ainsi d'une vision complète du cycle de développement, ce qui leur permet de prendre des décisions mieux informées, à chaque étape.

Cette architecture ouvre également la voie à de nouvelles formes de collaboration. En plus des agents d’IA disponibles par défaut sur GitLab, les équipes peuvent également créer et publier des agents dans un catalogue d’IA, ce qui les rend réutilisables d'un projet à l'autre. Ils s'intègrent également avec des agents externes, et peuvent opérer en parallèle au sein de flows multi-agents, traitant plusieurs tâches simultanément. Une flexibilité qui permet à chaque organisation de construire progressivement un écosystème d'automatisation aligné sur ses propres besoins.

Mais qu'est-ce que cela signifie concrètement pour une équipe AppSec au quotidien ? Découvrons ensemble trois cas d’usage applicables pour vous aider à accélérer le traitement et la correction des vulnérabilités et à informer votre organisation sur vos efforts en matière de sécurité et de conformité.

Trois cas d'usage concrets pour les équipes AppSec

1. Trier et prioriser le backlog de vulnérabilités

Toutes les équipes sécurité connaissent ce défi : générer un rapport de vulnérabilités et se retrouver face à des dizaines, voire des centaines d'alertes. La question n'est pas « y a-t-il des risques ? » mais « lesquels traiter en priorité ? »

Prenons l’exemple d’une équipe AppSec chargée d’analyser le backlog de vulnérabilités, d’identifier les risques et de prioriser la résolution à travers l’ensemble des applications de l’organisation.

Pour cela, accédons au rapport de vulnérabilités, un tableau de bord qui offre une vue d'ensemble sur la posture sécurité d'une application. Les vulnérabilités qui y figurent sont identifiées par un ensemble de scanners de sécurité exécutés systématiquement dans les pipelines CI/CD et regroupés en un seul endroit : SAST, DAST, analyse des dépendances, analyse des conteneurs, détection des secrets, etc.

Face à un grand nombre de risques identifiés, l'enjeu est de distinguer rapidement ce qui représente un danger réel et urgent de ce qui peut être traité ultérieurement. C'est ici que l'IA apporte une première valeur ajoutée, puisque certaines vulnérabilités sont automatiquement signalées comme de potentiels faux positifs.

En plus des scanners de sécurité qui analysent la base de code, une analyse intelligente complémentaire à l’aide de l’IA est effectuée sur chaque vulnérabilité dans le contexte global du projet.

Pour en savoir plus sur ces potentiels faux positifs, nous allons interroger l’agent Security Analyst de GitLab Duo en lui demandant « Pourquoi les secrets sont-ils identifiés comme potentiels faux positifs ». L’agent va effectuer une analyse intelligente dans le contexte pour déterminer s’il y a un réel risque ou non et partager ses retours à l'équipe AppSec.

Dans notre cas, il n’existe aucun risque puisque ce sont des secrets d’exemple. Nous allons donc demander à l'agent d'écarter ces vulnérabilités en masse en passant le statut à « dismissed » de toutes les vulnérabilités générées par le scanner de détection des secrets et identifiées comme faux positifs, puis d'ajuster les règles de détection pour affiner les futurs scans.

L'étape suivante consiste à identifier les risques réels prioritaires. En posant la question « Quelles vulnérabilités posent le plus grand risque pour la production ? », l'agent analyse l'ensemble des vulnérabilités, génère des rapports de priorisation avec l'impact estimé et propose un plan d'action recommandé.

Pour chaque vulnérabilité critique, il est possible d'obtenir une explication détaillée : sa localisation, le scanner qui l’a identifié et les recommandations de remédiation.

En cliquant sur le bouton AI vulnerability management > Explain with AI, nous allons demander à l'IA de nous aider à obtenir une meilleure compréhension du risque en nous donnant une explication avec des recommandations et des préconisations.

Une fois les priorités établies, l'agent peut confirmer les vulnérabilités critiques et créer automatiquement une issue pour chacune d'entre elles, permettant de tracer la remédiation. En quelques minutes, le backlog de vulnérabilités critiques et de nombreuses vulnérabilités de sévérité moyenne est réduit à un nombre maîtrisé de risques effectivement triés et assignés.

Une fois les risques identifiés, encore faut-il les corriger, et le faire rapidement. C'est là qu'intervient la génération automatique de merge requests correctives.

Depuis un ticket lié à une vulnérabilité, la fonction « Generate MR with Duo » lance un flow agentique qui récupère le contexte de l’issue, du projet et des informations connexes, puis génère automatiquement une merge request contenant le correctif. Chaque modification suggérée par GitLab Duo suit un processus rigoureux : passage par le pipeline CI/CD et revue de code obligatoire avec approbation par un pair pour valider le changement de code.

Cette création de merge requests correctives peut être également automatisée via des flows agentiques, permettant de passer à l'échelle en générant systématiquement des propositions de correction pour chaque vulnérabilité confirmée.

Note : la fonction « Generate MR with Duo » ne se limite pas aux vulnérabilités, elle s’applique aussi à d'autres cas d'usage comme le développement de fonctionnalités à partir d'une spécification ou la résolution de bugs.

2. Collaborer avec les développeurs pour prévenir l'introduction de nouvelles vulnérabilités

Le deuxième enjeu est d'empêcher l'introduction de nouveaux risques le plus tôt possible dans le cycle de développement logiciel. Lorsqu'un développeur ouvre une merge request pour implémenter une nouvelle fonctionnalité, un ensemble de vérifications automatiques s'exécutent comme la revue de code automatique de GitLab Duo qui permet de fournir des premiers retours sur la qualité des changements apportés.

Cependant, il arrive qu’une merge request se retrouve bloquée par une règle de sécurité définie au niveau de l'organisation. Ces règles déterminent le seuil critique à respecter. Au-delà d'un certain niveau de risque (par exemple, des dépendances critiques), le merge est bloqué et une validation par un expert sécurité est requise.

L'expert AppSec, sollicité pour faire une revue et donner son avis, doit alors se familiariser rapidement avec le changement et comprendre la vulnérabilité dans son contexte. Plutôt que de passer un temps considérable à analyser manuellement le code, les discussions et les tickets associés, ce dernier peut faire appel à GitLab Duo pour obtenir un résumé contextuel sur les aspects liés à la sécurité : modifications du code, discussions, issues associées et failles problématiques.

Sur la base de cette analyse, l’expert AppSec demande à l'agent de publier sa recommandation directement en commentaire sur la merge request, en taguant l'auteur de la merge request. Le développeur dispose ainsi immédiatement des préconisations de remédiation et comprend pourquoi la merge request est en échec.

Ce processus permet une collaboration fluide et rapide entre les équipes chargées de la sécurité et du développement, réduisant considérablement le temps nécessaire pour contextualiser un risque et communiquer les actions correctives.

3. Générer des rapports de conformité et d’audit

Le dernier cas d'usage répond à un besoin récurrent : donner de la visibilité au management et aux auditeurs sur la posture sécurité et la conformité des applications. Dans GitLab, un projet peut être associé à un framework de conformité (par exemple, la norme ISO 27001), indiquant qu'il est soumis à un ensemble de règles spécifiques auquel il doit se conformer.

En demandant à l'agent Security Analyst de générer un résumé de l'état actuel de l'application en matière de sécurité et de conformité, celui-ci produit un rapport complet comprenant : une évaluation globale des risques, une analyse détaillée des vulnérabilités (y compris celles déjà triées et confirmées), des indicateurs de progression, une priorisation des actions restantes et des retours spécifiques par rapport à la norme de conformité applicable.

Ce rapport, généré en quelques minutes, permet de démontrer l'amélioration continue et de partager un état des lieux clair et structuré, là où ce travail aurait traditionnellement nécessité un effort manuel considérable.

À travers ces trois cas d'usage, GitLab Duo permet aux équipes AppSec d'accélérer de façon significative la priorisation des risques, l'assignation et la réalisation des corrections, la collaboration avec les développeurs et la production de rapports de conformité. Des tâches qui prenaient habituellement des heures se réalisent désormais en quelques minutes, tout en maintenant les exigences de qualité, de traçabilité et de validation humaine à chaque étape.

L'équipe AppSec devient chef d'orchestre

Ce changement de paradigme est fondamental. Les équipes sécurité ne sont plus un goulot d'étranglement que l’on vient solliciter en dernier recours. Elles deviennent les architectes des workflows que les agents exécutent, tout en gardant la maîtrise de bout en bout.

Concrètement, cela se traduit par trois responsabilités clés :

• Définir les règles : quelles politiques de sécurité s'appliquent, à quel seuil bloque-t-on une merge request, quels frameworks de conformité sont requis ?
• Choisir les workflows : quels agents activer, pour quels types de vulnérabilités, avec quelles automatisations ?
• Garder le contrôle : toutes les actions des agents restent auditables et les validations humaines sont maintenues aux étapes critiques.

En déléguant l'exécution aux agents, les experts sécurité se concentrent sur la stratégie et peuvent couvrir un périmètre toujours plus large, sans avoir besoin de multiplier les effectifs. C'est la réponse concrète au paradoxe de l'IA : la vitesse du développement augmente, mais la sécurité suit le rythme grâce à une orchestration maîtrisée.

Déployer l'IA en toute souveraineté

Adopter l'IA dans un contexte de sécurité soulève légitimement des questions sur la maîtrise des données. Pour y répondre, GitLab propose plusieurs modèles de déploiement adaptés aux exigences de chaque organisation :

• GitLab Self-Managed : hébergé dans votre propre infrastructure, pour un contrôle total.
• GitLab.com : une offre SaaS entièrement gérée par GitLab.
• GitLab Dedicated : un SaaS dédié, déployé dans la région de votre choix.

Quel que soit le modèle retenu, les organisations conservent la maîtrise de leurs données. Elles peuvent choisir leurs propres grands modèles de langage (LLM) et disposent d'options air-gapped avec des LLM auto-hébergés, garantissant qu'aucune donnée n'est retenue par les fournisseurs d'IA. La souveraineté n'est pas une contrainte à gérer après coup : elle est intégrée dès la conception. Pour en savoir plus, consultez notre documentation.

En résumé

L'orchestration d'agents d’IA au service des équipes sécurité répond à un problème concret : faire plus avec les mêmes équipes, sans sacrifier la qualité ni le contrôle.

Les trois enseignements clés à retenir :

• L’IA sans gouvernance crée autant de risques qu’elle en résout : accélérer le développement sans intégrer la sécurité en amont amplifie l’exposition. La vitesse seule n’est pas un avantage si elle génère une dette de sécurité.
• Le contexte unifié est la clé de l’orchestration agentique : des agents qui ne partagent pas de contexte reproduisent la fragmentation des outils. Avec le modèle de données unifié de GitLab, les agents peuvent agir avec une vision complète du cycle de vie.
• L'équipe AppSec orchestre, les agents exécutent : avec les bons garde-fous et les bons agents, les équipes sécurité couvrent un périmètre qui grandit en permanence. En déléguant l’exécution, elles se concentrent sur la stratégie.

🎯 Prêt à accélérer votre sécurité applicative ? Essayez GitLab Duo Agent Platform dès aujourd'hui !

Comment passer d'une IA expérimentale et fragmentée à une IA véritablement industrialisée, gouvernée et intégrée à l'ensemble du cycle de développement logiciel ? C'est la question centrale à laquelle GitLab répond avec GitLab Duo Agent Platform, en offrant à ses clients toute la flexibilité dont ils ont besoin en termes d’hébergement des modèles, pour répondre à leurs contraintes opérationnelles.

Découvrez dans cet article comment l'orchestration intelligente des agents d'IA peut transformer l’ensemble du cycle de développement logiciel, à travers deux cas d’usage concrets avec AWS Bedrock comme backend LLM.

🎯 Essayez GitLab Duo Agent Platform dès aujourd'hui !

L'IA en entreprise : de l'expérimentation à la gouvernance à grande échelle

En 2025, près de 88 % des organisations utilisaient déjà l'IA dans au moins une fonction métier, selon une enquête de McKinsey. Un chiffre qui illustre un basculement majeur : l'IA n'est plus un sujet d'expérimentation isolée. Elle est devenue un enjeu de production, de gouvernance et de gestion des risques à l'échelle de l'entreprise.

Sur les deux dernières années, l'utilisation de l'IA générative s’est intensifiée, entraînant dans son sillage une multiplication d'outils, de modèles et de preuves de concept. Une complexité croissante qui soulève une question de fond : qui utilise quel modèle, avec quelles données, et sous quel niveau de sécurité et de conformité ? Face à ce manque de visibilité, les entreprises réclament désormais davantage de traçabilité, de contrôle et de gouvernance sur leur utilisation de l’IA.

Le paradoxe de l'IA dans le développement logiciel

Dans la chaîne de développement logiciel, un paradoxe s'est installé : l'IA a certes accéléré la phase de codage, mais toutes les autres étapes du cycle de développement logiciel restent des goulots d'étranglement. Spécifications, revues de code, tests, sécurité, déploiements, surveillance… autant d'étapes qui n'ont pas encore pleinement profité des avantages de l’intelligence artificielle.

C’est dans ce contexte que s'inscrit la stratégie de GitLab : passer d’une approche fragmentée de l’IA à une plateforme unifiée où le code, la sécurité et la conformité ainsi que l’IA coexistent au même endroit.

GitLab : de l’approche DevSecOps à l’orchestration intelligente

GitLab a transformé sa plateforme, d’une simple plateforme CI/CD pour gérer étape par étape le cycle de vie logiciel à une plateforme d'orchestration intelligente qui unifie à la fois le DevSecOps et l'IA.

L'objectif n'est plus seulement d'automatiser chaque étape individuellement, mais de permettre aux équipes d'orchestrer leurs agents d’IA pour livrer des logiciels plus vite, de manière plus sécurisée, et avec une gouvernance renforcée depuis une plateforme unique.

Une intégration adaptée à vos besoins

L'approche de GitLab s’adapte à vos contraintes existantes :

• Intégration à vos workflows existants : projets, pipelines, outils.
• Exploitation de votre contexte métier : les agents GitLab s'appuient sur votre code et votre contexte pour être immédiatement opérationnels sur vos applications.
• Respect de vos règles de sécurité et de conformité : politiques d'accès, localisation des données.
• Maîtrise totale de votre infrastructure : avec des modèles auto-gérés ou hébergés sur AWS, vous avez la possibilité d'utiliser les modèles de votre choix, tout en conservant vos données et votre contrôle. Et si vos contraintes l'exigent, vous pouvez également basculer sur AWS European Sovereign Cloud, voire fonctionner en environnement totalement isolé d'Internet.

Pour illustrer concrètement ces capacités, intéressons-nous aux deux cas d'usage suivants.

GitLab Duo Agent Platform et AWS Bedrock en pratique

Les deux cas d'usage présentés ci-dessous s'appuient sur une instance GitLab déployée sur AWS, avec AWS Bedrock comme backend LLM. Les modèles ont été préalablement configurés dans GitLab pour alimenter les différentes fonctionnalités de GitLab Duo Agent Platform : suggestion de code, GitLab Duo Agentic Chat, explication de code, etc.

Cas d'usage 1 : utilisation de l’agent Security Analyst

Les scans SAST et SCA sont essentiels, mais ils génèrent souvent un volume important de vulnérabilités, difficiles à classer, prioriser et traiter efficacement. C'est là qu'intervient l'agent Security Analyst de GitLab. Cet agent d’IA spécialisé joue le rôle d'un analyste sécurité augmenté :

• Il se connecte aux résultats des scans de sécurité.
• Il analyse les vulnérabilités et estime leurs niveaux de risque.
• Il priorise les éléments critiques et propose des plans de remédiation.

Les bénéfices sont mesurables : moins de bruit pour les développeurs, un gain de temps pour les équipes AppSec, et une réduction observable du volume de vulnérabilités en production.

La sécurité n'est pas le seul domaine où les agents d’IA font la différence. Le cas d'usage suivant montre comment cette même logique d'orchestration peut transformer le quotidien des équipes de développement avec l’aide de plusieurs agents spécialisés.

Cas d'usage 2 : de la user story à la merge request avec des agents d’IA

Transformer une user story en code fonctionnel, accompagné de tests et d’une documentation, est un processus long et variable d'un développeur à l'autre.

Pour faciliter le travail des équipes, GitLab propose un flow “Développeur” qui orchestre simultanément plusieurs agents d’IA à partir d’un simple ticket :

1. Un agent propose le plan de développement et génère le code.
2. Un agent effectue les tests.
3. Un agent rédige et met à jour la documentation.

Ce flow de bout en bout permet de gagner un temps précieux entre l’idée et le développement, tout en standardisant les pratiques et en garantissant la conformité avec les contraintes de l'entreprise.

L'IA comme levier industriel

L'enjeu n'est pas d'avoir plus d'IA, mais de faire en sorte que les équipes et les agents d’IA collaborent ensemble à l'échelle de l'entreprise. Avec GitLab et son approche d’orchestration intelligente, les équipes DevSecOps alignent leurs workflows, leurs règles de sécurité et leurs modèles pour faire de l’IA un véritable avantage compétitif.

🎯 Prêt à accélérer votre développement logiciel ? Essayez GitLab Duo Agent Platform dès aujourd'hui !

Ressources complémentaires

• GitLab Duo Agent Platform : le guide complet
• Démarrer avec GitLab Duo Agent Platform
• Démarrer avec GitLab Duo Agentic Chat
• GitLab Duo Agent Platform : comprendre les agents
• Comprendre les flows : workflows multi-agents
• Découvrir le catalogue d'IA : créer et partager des agents et des flows
• Surveiller, gérer et automatiser les workflows d'IA
• Intégrer le Model Context Protocol
• Personnaliser GitLab Duo Agent Platform : règles, prompts et workflows

Cette approche fonctionne, mais devient vite fastidieuse. Si vous avez déjà souhaité que le navigateur de dépôt ressemble davantage à votre IDE qu'à une série de fils d'Ariane, l'arborescence de fichiers de GitLab 18.9 est faite pour vous.

Fonctionnement de l'arborescence de fichiers

L'arborescence de fichiers ajoute un panneau repliable et redimensionnable à côté de vos vues de fichiers et de répertoires, de sorte que la structure de votre projet reste visible pendant que vous lisez et naviguez dans le code. Ainsi, vous n'avez plus besoin de cliquer sur retour pour savoir où vous vous trouvez.

Cette fonctionnalité affiche les fichiers et répertoires de votre projet dans une arborescence à côté de la liste des fichiers et du contenu des fichiers, ce qui vous permet de voir la structure et le code en même temps.

Si vous avez déjà utilisé une arborescence de fichiers dans un IDE ou une plateforme Git, elle devrait vous sembler familière :

Navigation avec une vue structurée

Développez et repliez les répertoires et basculez entre les fichiers tout en gardant une vue claire de votre position dans la hiérarchie du dépôt. Lorsque vous accédez directement à un fichier imbriqué, l'arborescence développe les répertoires parents et met en surbrillance le fichier actuel afin que vous ne perdiez pas le contexte. L'arborescence se synchronise également avec votre position actuelle : lorsque vous sélectionnez un fichier dans la zone de contenu principale, l'arborescence se met à jour en conséquence.

Filtrage par nom de fichier

Après avoir ouvert l'arborescence, appuyez sur F pour ouvrir la boîte de dialogue de recherche globale. Saisissez une partie d'un nom de fichier pour y accéder directement depuis la liste de résultats, chaque résultat affichant ses répertoires parents afin que vous sachiez où vous vous trouvez.

Navigation axée sur le clavier

L'arborescence implémente le modèle de vue arborescente ARIA du W3C, ce qui vous permet de naviguer parmi les fichiers et répertoires à l'aide du clavier et des touches fléchées, ainsi que des touches Entrée, Espace, Début, Fin et des touches de caractères. Ce type de navigation est plus accessible pour les utilisateurs de lecteurs d'écran et pour toute personne qui préfère utiliser un clavier.

Réactivité sur tous les écrans

Sur un ordinateur, l'arborescence s'affiche côte à côte avec votre liste de fichiers et votre code. Sur les écrans plus petits, elle se transforme en panneau latéral gauche que vous pouvez ouvrir lorsque vous en avez besoin. Sur mobile, l'arborescence est masquée afin que la vue du code puisse occuper tout l'écran.

Conception pour les dépôts volumineux

Pour les dépôts avec de nombreuses entrées, l'arborescence utilise la pagination afin que vous puissiez charger davantage d'éléments selon vos besoins sans surcharger la page. L'expérience reste fluide à mesure que votre projet se développe.

Découvrez l'arborescence de fichiers en action

Michael Friedrich, Principal Developer Advocate chez GitLab, présente la nouvelle arborescence de fichiers dans GitLab. Découvrez comment cette fonctionnalité facilite la navigation dans les dépôts volumineux, comme si vous travailliez dans votre IDE. La démonstration utilise le projet GitLab Tanuki IoT Platform, que vous pouvez explorer vous-même pour tester l'arborescence de fichiers dans un véritable dépôt.

Essayez l'arborescence de fichiers dès aujourd'hui

L'arborescence de fichiers est disponible dès maintenant sur GitLab.com et a été publiée dans la version 18.9 pour GitLab Self-Managed et GitLab Dedicated.

Voici comment y accéder :

1. Ouvrez n'importe quelle vue de fichier ou de répertoire de dépôt dans votre projet (/<project>/-/tree/<branch>).
2. Dans le coin supérieur gauche, sélectionnez l'icône d'arborescence de fichiers ou appuyez sur Shift+F pour activer/désactiver l'arborescence de fichiers.
3. Appuyez sur F pour filtrer les fichiers par nom ou extension, commencez à saisir du texte, puis utilisez les touches fléchées et Entrée pour accéder directement au fichier souhaité.

Perspectives

L'équipe Source Code de GitLab a conçu l'arborescence de fichiers en plaçant l'accessibilité, les performances à grande échelle et la cohérence entre les différents écrans au cœur de ses exigences. Ces principes continueront de guider nos prochains développements, et vos retours nous aideront à façonner les futures itérations.

Aidez-nous à améliorer l'arborescence de fichiers

Partagez vos retours sur l'arborescence de fichiers dans notre ticket.

Vous souhaitez en savoir plus sur l'arborescence de fichiers ? Consultez la documentation.

Si la sécurité se limitait au scan de code, peut-être. Mais la sécurité des entreprises n'a jamais reposé uniquement sur la détection des failles.

Les organisations ne se demandent pas si l'IA peut détecter des vulnérabilités. Elles se posent trois questions bien plus complexes :

• Le produit que nous nous apprêtons à livrer est-il sûr ?
• Notre posture de risque a-t-elle suivi le même rythme d'évolution continue que les environnements, les dépendances, les services tiers, les outils et les infrastructures ?
• Comment pouvons-nous gouverner un code source de plus en plus généré par l'IA et des sources tierces, dont nous restons pourtant responsables ?

Ces questions nécessitent une réponse au niveau de la plateforme : la détection révèle les risques, mais c'est la gouvernance qui détermine la suite des opérations.

GitLab est la couche d'orchestration conçue pour gouverner le cycle de vie logiciel de bout en bout. Elle offre aux équipes l'application, la visibilité et la traçabilité nécessaires pour suivre le rythme du développement assisté par l'IA.

La confiance dans l'IA repose sur une gouvernance solide

L'identification de vulnérabilités et la suggestion de correctifs des systèmes d'IA s'améliorent rapidement. Cette avancée significative est bienvenue, mais l'analyse n'implique pas de responsabilité.

L'IA ne peut pas appliquer les politiques de l'entreprise ni définir seule les risques acceptables. C'est aux équipes d'établir les limites, les politiques et les garde-fous dans lesquels les agents opèrent, en instaurant une séparation des tâches, en garantissant des pistes d'audit et en maintenant des contrôles cohérents dans des milliers de dépôts et d'équipes. La confiance placée dans les agents ne vient pas uniquement de leur caractère autonome, mais d'une gouvernance clairement définie.

Dans un monde agentique, où les logiciels sont de plus en plus écrits et modifiés par des systèmes autonomes, la gouvernance gagne en importance. Plus les organisations accordent d'autonomie à l'IA, plus la gouvernance doit être solide.

La gouvernance n'est pas un frein, mais une base qui rend le développement assisté par l'IA digne de confiance à grande échelle.

Les LLM lisent le code, les plateformes comprennent le contexte

Un grand modèle de langage (LLM) évalue le code de manière isolée. Une plateforme de sécurité des applications comprend le contexte. Cette différence est fondamentale, car les décisions en matière de risque sont prises en contexte :

• Qui est à l'origine de la modification ?
• Quelle est l'importance de l'application pour l'entreprise ?
• Comment l'application interagit-elle avec l'infrastructure et les dépendances ?
• La vulnérabilité existe-t-elle dans du code réellement accessible en production, ou est-elle enfouie dans une dépendance qui ne s'exécute jamais ?
• La vulnérabilité est-elle réellement exploitable en production, compte tenu de la façon dont l'application s'exécute, de ses API et de son environnement ?

Les décisions en matière de sécurité dépendent de ce contexte. Sans lui, la détection génère des alertes parasites qui ralentissent le développement au lieu de réduire les risques. Avec lui, les organisations peuvent classer rapidement les vulnérabilités et gérer les risques en toute efficacité. Le contexte évolue en permanence au même titre que les logiciels, ce qui signifie que la gouvernance ne peut être ponctuelle.

Les scans statiques ne suivent pas le rythme des risques dynamiques

Le risque logiciel est dynamique. Les dépendances changent, les environnements évoluent et les systèmes interagissent d'une façon qu'aucune analyse ne peut à elle seule entièrement prévoir. Un scan sans vulnérabilité à un moment donné ne garantit pas la sécurité au moment de la release.

En entreprise, la sécurité repose sur une assurance continue : des contrôles intégrés directement dans les workflows de développement qui évaluent les risques au fur et à mesure que les logiciels sont créés, testés et déployés.

La détection apporte des informations, la gouvernance instaure la confiance. C'est la gouvernance continue qui permet aux organisations de livrer en toute sécurité à grande échelle.

Gouverner l'avenir agentique

L'IA transforme la façon dont les logiciels sont créés. La question n'est plus de savoir si les équipes utiliseront l'IA, mais avec quelles mesures de sécurité elles pourront la déployer à grande échelle.

Aujourd'hui, les logiciels sont autant assemblés qu'écrits à partir de code généré par l'IA, de bibliothèques open source et de dépendances tierces qui couvrent des milliers de projets. Gérer ce qui est déployé en tenant compte de toutes ces sources représente la partie la plus difficile et la plus importante de la sécurité des applications, et c'est la partie pour laquelle aucun outil destiné aux développeurs n'a été conçu.

En tant que plateforme d'orchestration intelligente, GitLab est conçue pour répondre à ce problème. GitLab Ultimate intègre la gouvernance, l'application des politiques, les scans de sécurité et l'auditabilité directement dans les workflows où les logiciels sont planifiés, développés et livrés, afin que les équipes de sécurité puissent gouverner au rythme de l'IA.

L'IA accélére considérablement le développement. Les organisations qui tireront le meilleur parti de cette technologie ne seront pas seulement celles qui disposent des assistants les plus intelligents, mais celles qui instaureront la confiance grâce à une gouvernance solide.

Pour découvrir comment GitLab aide les organisations à gouverner et livrer du code généré par IA en toute sécurité, contactez notre équipe.

Ressources complémentaires

• Intégration de l'IA dans l'approche DevOps pour une sécurité renforcée
• Sécurité et IA : tout savoir sur le framework de GitLab
• Démarrer avec GitLab Duo Agent Platform : le guide complet

Cet article de blog est un résumé de notre webinaire sur GitLab Duo Agent Platform en action animé par Chloé Liban (Solutions Architect) et Chloé Cartron (Senior Solutions Architect). Pour visionner le replay, cliquez ici.

Les équipes de développement n'ont jamais écrit autant de code aussi vite. Les outils d’IA se multiplient (IDE, CLI, assistants au code, générateurs d’applications), et pourtant, dans la plupart des organisations, le gain de productivité réel reste difficile à mesurer.

La question n'est plus « Faut-il adopter l'IA ? » mais « Comment en tirer un vrai avantage sur l'ensemble de la chaîne de production logicielle ? ».

C'est ce que nous explorons dans cet article, avec des exemples concrets d'utilisation de GitLab Duo Agent Platform : de l'idée à la fonctionnalité déployée, en passant par la revue de code, le débuggage et la sécurisation, étape par étape.

Essayez GitLab Duo Agent Platform dès aujourd'hui !

Le « Paradoxe de l'IA » pour la livraison logicielle

Le développement assisté par l'IA rend les équipes de développement plus rapides que jamais. Mais comment les équipes peuvent-elles égaler cette vitesse dans le reste du cycle de développement logiciel ?

Dans notre rapport sur L'ère du développement intelligent, les professionnels du DevSecOps s’accordent à dire que l’IA leur a permis de gagner en productivité : automatisation des tâches répétitives, tests/assurance qualité, génération de code, etc.

Cependant, si le développement s'avère plus rapide avec l’IA, le manque de qualité, de sécurité et de rapidité dans les 80 % restants du cycle de développement logiciel accompagné d’une fragmentation de la chaîne d'outils freinent l’innovation logicielle.

GitLab nomme ce phénomène le paradoxe de l'IA.

En adoptant une approche d’orchestration intelligente, les équipes de développement passent d'un workflow linéaire où chaque étape attend la précédente, à une exécution parallèle où des agents d’IA spécialisés traitent plusieurs tâches simultanément, tout en conservant la main sur les décisions.

Les trois principes de l’orchestration intelligente

Cette orchestration intelligente repose sur trois principes architecturaux qui vous permettent de garder le contrôle tout au long du cycle du développement logiciel : les workflows, le contexte et les garde-fous.

• Les workflows : ce sont les équipes logicielles qui définissent les règles pour les agents d’IA. Elles décident du contexte d’intervention de l’agent, du flow à suivre et des exigences de conformité à respecter.
• Le contexte : le modèle de données unifié de GitLab maintient un contexte organisationnel complet, contrairement aux outils fragmentés qui le perdent d’un système à l’autre.
• Les garde-fous : des options de déploiement flexibles avec des règles de sécurité et de conformité personnalisées, adaptées à vos contraintes, pour un contrôle total sur vos données et vos workflows.

Ces garde-fous s'appuient sur quatre options de déploiement, selon vos exigences réglementaires et d'infrastructure :

• GitLab Self-Managed : instance hébergée sur site ou dans le cloud,
• GitLab.com : SaaS mutualisé,
• GitLab Dedicated : SaaS dédié dans la région de votre choix,

Découvrons maintenant comment utiliser GitLab Duo Agent Platform tout au long du cycle de développement logiciel.

Comment créer une fonctionnalité avec GitLab Duo Agent Platform ?

Accélérer l'ensemble de la chaîne de production logicielle est un objectif partagé par toutes les organisations. Avec GitLab Duo Agent Platform, vous pouvez planifier les tâches, déléguer la conception et l'implémentation du code à un agent, automatiser la revue de code, valider les pipelines de build et de test, débugger avec l'IA, et garantir la sécurité et la conformité du code.

Pour illustrer cette démarche, construisons ensemble une nouvelle fonctionnalité pas à pas dans une application.

1. Création et planification des tâches

Démarrons avec un projet vide comportant un seul ticket ouvert « Create a web app application for a Certificate of Deposit calculator in Java » pour un projet d’application bancaire web en Java, intégrant un calculateur de dépôt.

Dans ce ticket, la description liste en détail les exigences de cette application.

Nous allons d’abord enrichir ce ticket avec un plan d'implémentation détaillé : une liste de besoins et des tâches structurées, chacune dotée d'un titre et d'une description. Cette action sera réalisée via GitLab Duo Chat.

Une fois ces tâches créées, nous les planifions à l'aide de l’agent Planner. Disponible par défaut dans GitLab, cet agent spécialisé assiste les équipes dans les workflows de gestion de projet et de planification.

Il consulte le ticket et l’ensemble des tâches, puis produit un rapport complet : estimation du temps passé par tâche, facteurs de risque, chaîne de dépendances et recommandations pour démarrer chaque tâche.

📌 Pour découvrir l'ensemble des agents disponibles dans GitLab (par défaut, personnalisables ou externes), accédez au Catalogue d'IA via la section Explorer dans la barre de recherche.

2. Réalisation des tâches de développement

Pour cette étape, nous utilisons le flow agentique « Issue to merge request » conçu pour accélérer le prototypage et le développement de notre fonctionnalité.

Depuis le ticket initial, cliquez sur le bouton Generate MR with Duo. Cette action lance un agent qui analyse le ticket et génère l’application. Vous pouvez suivre sa progression via Automatisation > Sessions dans la barre latérale gauche.

Avec le flow « Issue to merge request », vous simplifiez le processus de conversion des tickets en merge requests actionnables. Ce flow analyse la description et les exigences du ticket, crée une merge request en brouillon liée au ticket d’origine, élabore un plan de développement basé, génère une structure de code ou une implémentation, puis met à jour la merge request avec les modifications correspondantes.

Notre application Java est maintenant créée.

3. Accélération de la revue de code

La revue de code génère souvent des ralentissements dans le cycle de développement, à la fois pour les équipes qui sont en attente d’une revue de leur code et doivent changer de contexte, mais également pour les relecteurs qui doivent s’occuper de cette revue et prendre du temps à analyser l’ensemble des changements apportés.

GitLab Duo Agent Platform permet d'accélérer cette étape de deux façons :

• Assigner GitLab Duo comme relecteur via la barre latérale droite de la merge request.
• Utiliser l'action rapide /request_review en commentaire en taguant @GitLabDuo.

Une fois assigné, l’agent inspecte les modifications apportées dans la merge request, détecte les erreurs, les problèmes de style ou de qualité et partage des suggestions de correction. Le développeur peut ensuite interagir avec la revue effectuée par GitLab Duo, poser des questions et apporter des précisions, comme il le ferait avec un collègue.

Pour les équipes qui souhaitent aller plus loin, il est possible de configurer une revue automatique de GitLab Duo sur chaque merge request, à l'échelle d'un projet ou d'un groupe entier, et de personnaliser les instructions via un fichier de configuration pour respecter les normes de votre organisation.

4. Correction et optimisation des pipelines

Une fois les modifications apportées au code, nous devons nous assurer que le pipeline CI/CD s'exécute avec succès en incluant le build, les tests et le déploiement.

En cas d'échec, sollicitez GitLab Duo dans le chat avec la requête « Peux-tu diagnostiquer et corriger ce pipeline en échec ? ». GitLab Duo examine le contexte, le pipeline, les messages d’erreur et les fichiers du dépôt, puis identifie l’origine du problème, et crée un commit de correction avec les modifications nécessaires pour débloquer le pipeline en échec et le relancer.

Si GitLab Duo Agent Platform permet de corriger un pipeline en échec rapidement en économisant un temps précieux, nous pouvons également le solliciter pour optimiser un pipeline existant.

Pour cela, créez un ticket du type « Recherche d'améliorations de pipeline », ouvrez une nouvelle branche avec une merge request, puis demandez à GitLab Duo : « Peux-tu améliorer le pipeline de ce projet ? ». A partir de cette requête, GitLab Duo examine les fichiers du dépôt, identifie le fichier de pipeline et propose des améliorations à apporter.

5. Sécurisation du code avant la mise en production

Avant de déployer notre application en production, assurons-nous que l’ensemble des changements effectués sont conformes aux attentes en matière de sécurité et de conformité.

Accédons au rapport de vulnérabilités dans Sécurisation > Rapport de vulnérabilités depuis la barre latérale gauche du groupe, dans lequel vous pouvez retrouver l’ensemble des vulnérabilités.

Pour prioriser les vulnérabilités les plus urgentes, posez la question suivante à GitLab Duo : : « Quelles sont les vulnérabilités les plus urgentes à traiter dans le cadre du projet [URL du projet] ? ».

Une fois les priorités identifiées, rendez-vous dans le rapport de vulnérabilités du projet en question et utilisez l'agent Security Analyst avec la requête : « Crée un calendrier pour traiter tous les résultats de sécurité élevée ». L’agent analyse l’ensemble des vulnérabilités du projet et génère un calendrier de résolution structuré semaine par semaine, avec des actions rapides prioritaires à réaliser dans les 24 premières heures et des notes de gestion des risques. Ce plan permet de planifier et de prioriser le travail des équipes, tout en allouant les bonnes ressources.

L’agent peut également intervenir sur une vulnérabilité spécifique. Il fournit des informations détaillées sur la nature de la vulnérabilité, propose des approches de remédiation, détaille les étapes de validation, ainsi qu’une liste de contrôle et de tests des recommandations complémentaires et crée ensuite une merge request avec les corrections nécessaires.

Prêt à accélérer votre cycle de développement ?

Nous avons passé en revue la façon dont vous pouvez tirer parti de l'IA agentique dans votre cycle de vie de développement logiciel. De la planification à la sécurisation, GitLab Duo Agent Platform amplifie le travail de vos équipes en déléguant les étapes intermédiaires à des agents spécialisés, pour que vos équipes se concentrent sur ce qui compte vraiment : la conception, l’orchestration et la validation.

🎯 Vous souhaitez en savoir plus sur GitLab Duo Agent Platform ? Visionnez le replay de notre webinaire et essayez gratuitement la plateforme d'orchestration intelligente de GitLab.

Ces fonctionnalités permettent de gagner du temps et d'économiser des efforts :

• En éliminant la configuration répétitive des filtres pour les workflows courants
• En garantissant la cohérence dans la façon dont les équipes visualisent et évaluent le travail
• En facilitant les rapports standardisés et les vérifications de statut

Que sont les éléments de travail ?

Auparavant, les epics et les tickets se trouvaient sur des pages séparées, ce qui obligeait les utilisateurs à naviguer d'une page à l'autre. La liste des éléments de travail combine désormais les epics, les tickets et d'autres éléments de travail dans une liste unique et unifiée, afin que les équipes n'aient plus à basculer entre les pages selon les éléments de travail.

Cette liste servira également de base pour des fonctionnalités de planification plus approfondies à venir. Le regroupement de tous les types d'éléments de travail en un seul endroit ouvre la voie à des vues hiérarchiques (comme une vue table), qui faciliteront la visualisation des relations et de la structure entre les epics, les tickets et d'autres éléments en un coup d'œil.

Au-delà des vues de liste et d'éléments classés selon une hiérarchie, nous prévoyons également de consolider d'autres workflows courants, comme les tableaux, dans cette expérience unifiée. Toutes vos vues de planification essentielles seront disponibles en un seul endroit et pourront être partagées avec votre équipe via des vues enregistrées, sans besoin de naviguer dans différentes parties du produit.

Vous vous demandez peut-être quels sont ces « éléments de travail », et s'il s'agit de tickets. Le terme « ticket » ne correspond pas à notre vision future. Vous pourrez bientôt entièrement configurer vos types d'éléments de travail, y compris leurs noms, pour qu'ils correspondent à la planification de votre organisation. Limiter l'expérience à une terminologie legacy irait à l'encontre de cette flexibilité. Les «  éléments de travail » constituent la base d'un modèle que vous pouvez personnaliser.

Qu'est-ce qui a conduit à cette évolution vers les éléments de travail ?

En 2024, nous avons partagé notre vision d'une nouvelle expérience de planification Agile dans GitLab, alimentée par le framework des éléments de travail. Cet article décrivait le problème principal : les epics et les tickets sont des expériences séparées et créent des frictions pour les équipes qui s'attendent à une fonctionnalité cohérente entre les objets de planification. Le framework des éléments de travail a permis d'apporter une solution : une architecture unifiée conçue pour offrir plus de cohérence et de nouvelles fonctionnalités au sein des outils de planification de GitLab. La liste des éléments de travail et les vues enregistrées constituent une étape de ce parcours.

Que sont les vues enregistrées ?

Les vues enregistrées permettent aux utilisateurs de sauvegarder et de revenir à des configurations de liste personnalisées, avec filtres, ordre de tri et options d'affichage. L'objectif est de rendre les vérifications quotidiennes plus efficaces et de prendre en charge des affichages cohérents et standardisés du travail au sein d'une équipe.

Perspectives

Pour comprendre pourquoi nous effectuons ces changements, il convient d'abord de rappeler notre objectif.

Nous avons pour objectif non seulement d'offrir une liste d'éléments de travail, mais aussi une expérience de planification qui vous permet de passer facilement entre différents types de vues (liste, tableau, table et plus encore) tout en conservant votre portée de filtre actuelle.

Associez cette fonctionnalité aux vues enregistrées, et vous pouvez créer une vue dédiée pour chacun de vos workflows : planification d'itération, raffinement du backlog, planification au niveau du portefeuille avec des vues de table imbriquées, et plus encore.

Chaque vue est prête à l'emploi et cohérente dans la façon dont elle filtre et affiche le travail, et elle peut être partagée avec votre équipe. Ce framework prépare également le terrain pour des fonctionnalités plus puissantes à l'avenir, notamment la prise en charge complète des swimlanes pour tout attribut d'élément de travail dans les tableaux.

Nous savons que les changements apportés aux outils que vous utilisez quotidiennement peuvent être perturbants. Les workflows que vous avez conçus autour des listes d'epics et de tickets existantes auront désormais un design différent, et nous en sommes conscients.

Cette orientation a été mûrement réfléchie et reflète des années de retours des utilisateurs, un investissement architectural significatif dans le framework des éléments de travail et la conviction profonde qu'une expérience unifiée servira mieux les équipes à long terme. Nous nous attendons à ce que la transition nécessite certains ajustements, et nous continuerons à itérer en fonction de vos retours.

Donnez votre avis

Nous vous encourageons à essayer ces nouvelles fonctionnalités. N'hésitez pas à nous faire part de votre expérience avec la liste des éléments de travail et les vues enregistrées dans ce ticket. Vos retours nous aideront à améliorer davantage ces fonctionnalités.

Voici les nouveautés :

• La détection des faux positifs pour les tests statiques de sécurité des applications (SAST) est désormais en disponibilité générale. Ce flow utilise un grand modèle de langage (LLM) pour le raisonnement agentique afin de déterminer la probabilité qu'une vulnérabilité soit un faux positif et permet ainsi aux équipes de sécurité et de développement de se concentrer en priorité sur la correction des vulnérabilités critiques.
• La résolution des vulnérabilités SAST avec l'IA agentique est désormais disponible en version bêta. La résolution des vulnérabilités SAST avec l'IA agentique crée automatiquement une merge request avec un correctif proposé pour les vulnérabilités SAST vérifiées, ce qui réduit le délai de remédiation et limite le besoin d'une expertise approfondie en sécurité.
• La détection des faux positifs pour les secrets est désormais disponible en version bêta. Ce flow applique la même réduction de bruit basée sur l'IA à la détection des secrets, en signalant les secrets factices et de test afin de réduire l'effort de revue.

Ces flows sont disponibles pour les clients GitLab Ultimate qui utilisent GitLab Duo Agent Platform.

Réduire le temps de classement grâce à la détection des faux positifs SAST

Les scanners SAST traditionnels signalent chaque modèle de code suspect qu'ils détectent, indépendamment de l'accessibilité des chemins de code ou de la prise en charge du risque par les frameworks. Sans contexte d'exécution, ils ne peuvent pas distinguer une véritable vulnérabilité d'un code sûr qui semble simplement dangereux.

Les équipes de développement peuvent ainsi passer des heures à examiner des résultats qui s'avèrent être des faux positifs. Au fil du temps, cette situation peut éroder la confiance dans le rapport et ralentir les équipes chargées de corriger les risques réels.

Après chaque scan SAST, GitLab Duo Agent Platform analyse automatiquement les nouveaux résultats de gravité critique et élevée, et y associe :

• Un score de confiance indiquant la probabilité que le résultat soit un faux positif
• Une explication générée par l'IA qui décrit le raisonnement
• Un badge visuel qui permet de distinguer facilement les faux positifs probables des résultats probablement réels dans l'interface utilisateur

Ces résultats apparaissent dans le rapport de vulnérabilités, comme illustré ci-dessous. Vous pouvez filtrer le rapport pour vous concentrer sur les résultats qui ne sont pas des faux positifs, afin que les équipes consacrent leur temps à traiter les vulnérabilités réelles plutôt qu'à classer des résultats sans importance.

L'évaluation de GitLab Duo Agent Platform est une recommandation. Vous gardez le contrôle sur chaque faux positif pour déterminer sa validité, et vous pouvez vérifier le raisonnement de l'agent à tout moment pour renforcer votre confiance dans le modèle.

Transformer les vulnérabilités en correctifs automatisés

Savoir qu'une vulnérabilité est réelle ne représente que la moitié du travail. La remédiation nécessite encore de comprendre le chemin de code, de rédiger un correctif sécurisé et de s'assurer que rien d'autre n'est affecté.

Si la vulnérabilité est identifiée comme probablement réelle par le flow SAST False Positive Detection, le flow Agentic SAST Vulnerability Resolution effectue automatiquement les étapes suivantes :

1. Lecture du code vulnérable et du contexte environnant depuis votre dépôt
2. Génération de correctifs proposés de haute qualité
3. Validation des correctifs par des tests automatisés
4. Ouverture d'une merge request avec un correctif proposé comprenant :
   • Les modifications concrètes du code
   • Un score de confiance
   • Une explication des changements apportés et leur justification

Dans cette démonstration, vous verrez comment GitLab peut automatiquement traiter une vulnérabilité SAST, de la détection jusqu'à la création d'une merge request prête à être examinée. Observez comment l'agent lit le code, génère et valide un correctif, puis ouvre une merge request avec des modifications claires et explicites, afin que les équipes de développement puissent corriger le problème plus rapidement sans être des experts en sécurité.

Comme pour toute suggestion générée par l'IA, il est recommandé d'examiner attentivement la merge request proposée avant de procéder au merge.

Identifier les secrets réels

La détection des secrets n'est utile que si les équipes font confiance aux résultats. Lorsque les rapports regorgent d'identifiants de test, de valeurs de remplacement et de tokens d'exemple, les équipes de développement risquent de perdre du temps à examiner des informations superflues au lieu de corriger les expositions réelles. Cette situation peut ralentir la remédiation des vulnérabilités et réduire la confiance dans le scan.

La détection des faux positifs pour les secrets aide les équipes à se concentrer sur les secrets importants afin de réduire les risques plus rapidement. Lors de l'exécution sur la branche par défaut, le flow effectue automatiquement les étapes suivantes :

1. Analyse de chaque résultat pour repérer les identifiants de test, les valeurs d'exemple et les secrets factices potentiels
2. Attribution d'un score de confiance qui indique si le résultat représente un risque réel ou un probable faux positif
3. Génération d'une explication justifiant pourquoi le secret est considéré comme réel ou comme un faux positif
4. Ajout d'un badge dans le rapport de vulnérabilités pour que les équipes de développement puissent voir le statut en un seul coup d'œil

Les équipes de développement peuvent également déclencher cette analyse manuellement depuis le rapport de vulnérabilités en sélectionnant « Vérifier les faux positifs » sur n'importe quel résultat de détection de secrets, ce qui leur permet d'éliminer les résultats sans risque et de se concentrer plus rapidement sur les véritables secrets.

Adoptez la sécurité basée sur l'IA dès aujourd'hui

GitLab 18.10 introduit des fonctionnalités couvrant l'ensemble du workflow de gestion des vulnérabilités, de la réduction du bruit lié aux faux positifs dans les scans SAST et la détection des secrets à la génération automatique de merge requests avec des correctifs proposés.

Pour découvrir comment la sécurité basée sur l'IA peut réduire le temps de revue et transformer les résultats en correctifs prêts à être fusionnés, commencez un essai gratuit de GitLab Duo Agent Platform dès maintenant.

Un tournant s'amorce avec GitLab 18.10. Dès aujourd'hui, les équipes qui utilisent la version gratuite de GitLab.com peuvent acheter un abonnement mensuel de GitLab Credits et commencer à utiliser GitLab Duo Agent Platform immédiatement, sans mise à niveau de leur abonnement. Il s'agit d'un véritable point d'entrée vers l'IA agentique pour les équipes qui ne sont pas encore prêtes à souscrire un abonnement GitLab, mais qui souhaitent commencer à développer avec l'IA.

Le fonctionnement est simple : vous payez pour ce que l'IA accomplit, et non pour le nombre de personnes qui l'utilisent. Le propriétaire de votre groupe achète un engagement mensuel de GitLab Credits via les paramètres de facturation du groupe. L'ensemble de votre équipe accède alors aux mêmes agents et workflows d'IA que les clients GitLab Premium et GitLab Ultimate pour la planification, la génération de code, la revue de code automatisée et le diagnostic de pipelines, le tout à partir d'un pool de crédits partagé.

Le tableau de bord GitLab Credits offre aux propriétaires de groupe une visibilité sur les agents et workflows qui consomment des crédits, afin de relier directement les dépenses de l'IA au travail produit.

Zero-day avec GitLab Duo Agent Platform

Dès que le propriétaire de votre groupe a acheté des crédits, chaque membre de l'équipe peut commencer à utiliser GitLab Duo Agent Platform.

Voici le fonctionnement d'un workflow type :

Vous commencez avec une demande de fonctionnalité pour votre logiciel. Ouvrez l'agent GitLab Duo Planner dans l'Agentic Chat et décrivez vos besoins. L'agent les décompose en éléments de travail structurés : tickets avec descriptions, labels et relations, tous créés directement dans votre projet. Ce qui prenait auparavant un après-midi entier de gestion manuelle des tickets ne prend plus que quelques minutes.

Sélectionnez l'un de ces tickets et assignez le flow Developer pour démarrer le travail. L'agent lit le contexte du ticket, génère du code conforme aux exigences, exécute les tests et ouvre une merge request pour revue. Vous pouvez également utiliser l'Agentic Chat pour un travail plus itératif, qu'il s'agisse de refactorisation, d'extension ou d'explication de code dans le contexte de votre projet.

Lorsque la merge request est prête, le flow Code Review exécute une revue automatisée en plusieurs étapes : analyse des modifications, prise en compte du contexte du dépôt et publication de commentaires inline structurés, directement liés au diff. Vos réviseurs humains peuvent ainsi se concentrer sur l'architecture et la logique métier, sans avoir à gérer les premières étapes manuelles.

Et si le pipeline échoue, le flow Fix CI/CD Pipeline lit les logs d'erreurs, identifie la cause profonde et propose un correctif. Au lieu de parcourir manuellement les job logs, votre équipe dispose d'un point de départ pour la correction.

GitLab Duo Agent Platform accompagne le développement logiciel de l'itération au déploiement, à partir d'un seul pool de crédits.

La prise en main des agents et workflows est simple. Découvrez comment passer de la planification au déploiement en moins de 3 minutes dans cette vidéo :

Revue de code à un tarif forfaitaire : des coûts prévisibles à grande échelle

Parmi tous les workflows disponibles via GitLab Duo Agent Platform, la revue de code automatisée est celui qui livre des résultats le plus rapidement, et celui pour lequel la prévisibilité des coûts est la plus importante.

Le flow Code Review coûte désormais un tarif forfaitaire de 0,25 crédit GitLab par revue, indépendamment de la taille de la merge request, de la complexité du dépôt ou du nombre d'étapes exécutées en interne. Quatre revues correspondent à un crédit. Que votre équipe fusionne 500 ou 50 000 merge requests par mois, vous pouvez prévoir les coûts directement en fonction du nombre de revues.

Les chiffres parlent d'eux-mêmes. Les revues de code manuelles ne coûtent pas seulement de l'argent : elles prennent du temps et perturbent le développement en raison de changements de contexte constants. Le temps économisé grâce au flow Code Review peut se traduire par des économies substantielles à mesure que le volume des revues augmente. Vous avez désormais la possibilité d'exécuter des centaines de revues simultanément au lieu de les laisser en file d'attente, ce qui signifie que les gains de temps se combinent rapidement aux économies financières.

Les équipes qui utilisent la version gratuite de GitLab savent désormais exactement quelle part de leur pool mensuel de crédits est consacrée à la revue de code afin de pouvoir planifier en conséquence.

Découvrez le fonctionnement du flow Code Review et comment faire évoluer votre organisation.

Pourquoi GitLab Premium multiplie la valeur ajoutée

Les crédits GitLab de la version gratuite offrent à votre équipe un accès direct à l'IA agentique. Si votre équipe s'appuie davantage sur GitLab, GitLab Premium est l'abonnement qui allie avantages économiques et fonctionnalités avancées.

Disponible pour 29 $ par utilisateur et par mois, GitLab Premium inclut 12 GitLab Credits par utilisateur dans le cadre d'une offre promotionnelle. Pour une équipe de 20 personnes, cela représente 240 crédits par mois avant toute dépense supplémentaire, soit suffisamment pour couvrir environ 960 revues de code automatisées, ou une combinaison de revues de code, de planification, de workflows de développement et de corrections de pipelines.

GitLab Duo Agent Platform ne représente qu'une partie de GitLab Premium. Vous bénéficiez également d'un CI/CD avancé pour les pipelines à fort volume, d'approbations de merge requests et de propriétaires du code pour la gouvernance, ainsi que d'une IA qui fonctionne au sein d'une couche de données unifiée avec un contexte partagé entre vos projets.

Si votre équipe utilise des crédits dans le cadre de la version gratuite et constate que l'IA devient centrale dans son workflow, GitLab Premium constitue l'étape suivante naturelle grâce aux crédits promotionnels inclus. Cette formule offre davantage de fonctionnalités et offre une structure de base qui évolue avec vous.

Commencez dès aujourd'hui

GitLab 18.10 est disponible dès maintenant. Que votre équipe ait besoin de l'IA agentique pour accélérer ses tâches ou de la plateforme complète pour accompagner ses méthodes de travail actuelles, vous disposez désormais d'une solution claire pour accélérer votre processus de développement logiciel.

• Équipes qui utilisent la version gratuite de GitLab.com : achetez un engagement mensuel de GitLab Credits via les paramètres de facturation de votre groupe et commencez à utiliser GitLab Duo Agent Platform dès aujourd'hui.
• Équipes prêtes pour la plateforme complète : trouvez l'abonnement GitLab adapté à votre équipe ou démarrez un essai gratuit de GitLab Ultimate.

La configuration des crédits pour votre équipe est rapide et simple. Regardez cette démo pour en savoir plus :

FAQ

Qu'est-ce qu'un engagement mensuel de GitLab Credits ?

Un engagement mensuel est une option d'achat basée sur l'utilisation, dans laquelle le propriétaire de votre groupe sélectionne un nombre défini de crédits qui s'appliquent en tant que pool partagé pour l'ensemble du groupe. Les crédits sont consommés lorsque votre équipe utilise les fonctionnalités de GitLab Duo Agent Platform. Consultez la documentation GitLab Credits pour en savoir plus.

Qui peut acheter des GitLab Credits aujourd'hui ?

Les clients GitLab Premium et GitLab Ultimate profitent déjà de crédits promotionnels inclus dans leur abonnement. À partir de la version 18.10, les espaces de nommage de groupe principal de la version gratuite de GitLab.com peuvent également acheter un engagement mensuel de crédits via la facturation en libre-service du groupe. Consultez la documentation GitLab Credits pour connaître les dernières conditions d'éligibilité.

Quelles fonctionnalités d'IA les crédits débloquent-ils dans la version gratuite ?

Les équipes disposant de crédits accèdent aux mêmes fonctionnalités et modèles d'IA agentique que les clients GitLab Premium et GitLab Ultimate, notamment l'agent Planner, le flow Developer, le flow Code Review, le flow Fix CI/CD Pipeline, l'Agentic Chat, les suggestions de code, les agents et workflows personnalisés, et bien plus encore. Consultez la documentation relative à GitLab Duo Agent Platform pour obtenir la liste complète.

Combien coûte la revue de code automatisée ?

Le flow Code Review applique un tarif forfaitaire de 0,25 crédit GitLab par revue, indépendamment de la taille ou de la complexité de la merge request. Consultez la documentation relative au flow Code Review pour connaître les détails actuels des tarifs.

Puis-je passer de la version gratuite avec crédits à GitLab Premium ?

Dans GitLab 18.10, la mise à niveau d'un espace de nommage de la version gratuite avec un engagement mensuel de crédits vers GitLab Premium est disponible via un processus accompagné par l'équipe commerciale. Contactez l'équipe commerciale GitLab pour connaître vos options.

La revue de code est devenue l'un des principaux goulots d'étranglement dans la livraison logicielle moderne. Les équipes qui s'appuient sur une poignée d'ingénieurs pour examiner manuellement chaque merge request en ressentent les effets. Ajoutez à cela la multiplication d'outils de codage basés sur l'IA au sein des équipes d'ingénierie, chacun générant du code et chacun étant examiné de manière isolée sans garde-fous unifiés, et le problème s'amplifie. Les entreprises ne font pas seulement face à un retard de traitement : elles font face à un manque de cohérence à grande échelle.

C'est pourquoi GitLab a développé le flow Revue de Code, un workflow d'IA agentique au sein de GitLab Duo Agent Platform qui examine automatiquement les merge requests dès leur ouverture. Ce flow analyse le code dans le contexte du dépôt, du pipeline, des résultats de sécurité et des exigences de conformité, et fournit un retour cohérent et exploitable sans attendre qu'un ingénieur s'en charge. Aujourd'hui, nous facilitons encore davantage le déploiement à grande échelle du flow Revue de Code grâce à l'introduction d'une tarification forfaitaire.

Des centaines de revues en parallèle, au même endroit

Le flow Revue de Code est une fonctionnalité d'IA agentique intégrée au sein de GitLab Duo Agent Platform qui examine automatiquement les merge requests à mesure qu'elles arrivent. C'est une première étape dans la réduction des goulots d'étranglement liés à la génération de code et un élément central de la stratégie de GitLab pour accélérer le développement logiciel grâce à l'IA. Lorsqu'une merge request est ouverte, le flow Revue de Code peut automatiquement exécuter une revue en plusieurs étapes : analyse des modifications, exploration du contexte pertinent du dépôt et génération d'une revue structurée avec des commentaires intégrés.

Le résultat est une revue ancrée dans ce qui se passe réellement dans le projet, et pas seulement dans ce qui a changé dans le diff.

Comme le flow Revue de Code s'exécute au sein de GitLab, vous bénéficiez d'un avantage que les outils de revue IA autonomes ne peuvent pas offrir : une cohérence à l'échelle de l'organisation. Les organisations peuvent créer des instructions de revue de merge request personnalisées afin que les revues de code soient cohérentes et respectent les normes du projet. Un projet peut utiliser le flow Revue de Code intégré. Un autre peut recourir à un agent externe comme Claude Code ou Codex. Un troisième peut exécuter un agent personnalisé conçu autour des normes spécifiques de l'équipe. Tout cela fonctionne simultanément, à travers chaque groupe, équipe et projet, chaque revue étant alignée sur ses propres garde-fous et le tout étant visible au même endroit.

C'est une architecture fondamentalement différente d'un assistant d'IA individuel intégré à un IDE. GitLab permet d'effectuer des centaines de revues de code en parallèle à travers toute l'organisation, et non une à la fois.

Découvrez le flow Revue de Code en action dans cette démo :

Un calcul simple, des dépenses prévisibles

À mesure que les équipes de développement livrent davantage de code grâce à l'assistance de l'IA, le besoin de coûts de revue de code prévisibles et évolutifs augmente en conséquence. La tarification forfaitaire du flow Revue de Code permet d'exécuter des revues à grande échelle, sur chaque projet et chaque merge request, sans avoir à rationner son utilisation.

Chaque exécution du flow coûte désormais 0,25 crédit GitLab, soit 0,25 $ par revue au tarif catalogue. Chaque revue coûte le même prix, quelle que soit la taille de la merge request, la complexité du dépôt ou le nombre d'étapes internes exécutées par le flow.

Le calcul est simple : 4 revues = 1 crédit GitLab. Que votre équipe fusionne 500 merge requests par mois ou 50 000, vous pouvez prévoir les dépenses directement en nombre de revues, sans calcul de tokens ni conversion nécessaire.

Vous souhaitez en savoir plus sur les GitLab Credits ? Les GitLab Credits sont l'unité de consommation pour l'utilisation de GitLab Duo Agent Platform. 1 crédit = 1 $. Consultez notre documentation pour plus d'informations.

Faites évoluer vos revues, pas vos coûts

La tarification forfaitaire ne se limite pas à une simplification de la facturation. Elle élargit les possibilités de votre équipe.

Activez la revue automatique sur tous vos projets. Lorsque vous connaissez exactement le coût de chaque revue, celle-ci devient un simple poste de dépense dans votre budget R&D. Configurez-la pour qu'elle se déclenche sur chaque merge request et laissez l'agent gérer la file d'attente.

Comparez sur un pied d'égalité. Le flow Revue de Code affiche un prix par revue clair, ce qui facilite l'évaluation par rapport à d'autres outils de revue d'IA sans conversion d'unités nécessaire.

Constatez les économies cumulées à mesure que votre organisation se développe. Considérez ce que pourrait coûter une revue de code manuelle : si une revue manuelle prend environ 15 minutes du temps d'un ingénieur, selon le taux horaire, elle pourrait être évaluée à environ 25 $ par revue. À 0,25 $ par revue automatisée, la réduction des coûts est significative. Et comme des centaines de revues peuvent s'exécuter simultanément, les gains de temps peuvent être tout aussi importants. Plus l'organisation est grande, plus ces deux avantages deviennent marqués.

Commencez dès aujourd'hui

La tarification forfaitaire pour le flow Revue de Code est disponible dès maintenant sur GitLab Duo Agent Platform.

Commencez un essai gratuit de GitLab Duo Agent Platform dès maintenant ! Si vous êtes déjà client GitLab, contactez votre chargé de compte pour toute question.

Pour faire face à cette problématique, le secteur propose des outils de revue alimentés par l'IA, mais la plupart présentent un inconvénient majeur : une tarification imprévisible basée sur les tokens qui rend difficile leur déploiement à grande échelle. Certains de ces nouveaux outils coûtent entre 15 et 25 $ par revue, selon la taille et la complexité de la modification. À ce prix, les équipes réservent les revues aux changements cruciaux, et les files d'attente ne raccourcissent pas.

Le flow Code Review, une fonctionnalité d'IA agentique au sein de GitLab Duo Agent Platform, coûte 0,25 $ par revue. Ce tarif forfaitaire vaut pour chaque merge request et chaque projet.

Fonctionnement

Lorsqu'une merge request est ouverte, le flow Code Review lance automatiquement une revue en plusieurs étapes : scan des modifications, exploration du contexte pertinent du dépôt, vérification du pipeline, des résultats de sécurité et des exigences de conformité, puis génération de commentaires inline structurés.

Le résultat ? Une revue ancrée dans votre projet, et non plus limitée aux seules modifications du diff. Et comme elle s'exécute au sein de GitLab, vous bénéficiez d'un avantage que les outils autonomes ne peuvent offrir : des centaines de revues exécutées en parallèle dans toute votre organisation, et non une seule à la fois dans l'IDE d'un ingénieur.

Découvrez le flow Code Review en action dans cette démo :

Un calcul simple, des économies réelles

Chaque revue coûte 0,25 crédit GitLab (0,25 $ au tarif catalogue). Quatre revues correspondent à un crédit. Que votre équipe fusionne 500 merge requests par mois ou 50 000, le calcul reste le même.

Fini les estimations de tokens et les mauvaises surprises sur les factures liées aux merge requests complexes : vous profitez d'un coût forfaitaire par revue, facile à prévoir dans un tableur.

Si une revue de code manuelle prend environ 15 minutes du temps d'un ingénieur senior, cela représente environ 25 $ en coût d'ingénierie. À 0,25 $ par revue automatisée, la réduction du coût par revue atteint 99 %. Et comme les revues s'exécutent en parallèle au lieu de s'accumuler dans une file d'attente, vous ne faites pas que réaliser des économies : vos merge requests sont débloquées en quelques minutes au lieu de plusieurs heures.

Pourquoi le tarif forfaitaire change-t-il la donne ?

Avec une tarification variable, les équipes choisissent les merge requests qui doivent bénéficier d'une revue par l'IA. Au tarif forfaitaire de 0,25 $, ce choix n'a plus lieu d'être. Vous pouvez désormais activer ce flow pour toutes les merge requests.

Chaque merge request, chaque projet. Configurez le flow Code Review pour qu'il se déclenche automatiquement sur chaque merge request. Laissez l'agent gérer la file d'attente pendant que vos ingénieurs se concentrent sur l'architecture et le mentorat.

Des normes cohérentes à grande échelle. Définissez des instructions de revue personnalisées par projet. Un projet utilise le flow intégré. Un autre utilise Claude Code ou Codex. Un troisième exécute un agent personnalisé. Tout fonctionne en parallèle, chaque agent aligné sur ses propres garde-fous, avec une visibilité unifiée.

Allègement de la file d'attente des revues. Dans la livraison logicielle, le goulot d'étranglement n'est pas l'écriture du code, mais l'attente liée aux revues. Les revues alimentées par l'IA en parallèle et à un tarif forfaitaire transforment une file d'attente de plusieurs jours en un processus de quelques minutes.

Vous ne connaissez pas GitLab Credits ? GitLab Credits est l'unité de consommation de GitLab Duo Agent Platform. 1 crédit = 1 $. Découvrez le fonctionnement de GitLab Credits.

Lancez-vous dès aujourd'hui

La tarification forfaitaire de 0,25 $ pour la revue de code agentique est disponible dès maintenant si vous utilisez GitLab Duo Agent Platform sur GitLab.com, GitLab Dedicated ou sur des instances auto-gérées exécutant la version 18.8.4 ou ultérieure. Activez le flow Code Review par défaut pour chaque merge request créée par votre équipe.

Commencez un essai gratuit de GitLab Duo Agent Platform pour découvrir ce flow en action, ou, si vous êtes déjà client GitLab, contactez votre chargé de compte pour toute question.

Les accélérateurs du centre d'excellence (CoE) de GitLab et TCS agissent conjointement pour réduire les frictions liées à la migration, codifier les garde-fous et industrialiser l'adoption du DevSecOps à grande échelle. Ensemble, ils ouvrent la voie d'une standardisation de l'orchestration intelligente, avec les garde-fous auditables nécessaires tout au long du développement.

Accompagner les entreprises tournées vers l'avenir

Les entreprises recherchent une plateforme DevSecOps conçue pour durer, sans devoir entreprendre une refonte majeure à intervalles réguliers. Le modèle de données unifié de GitLab regroupe l'ensemble du cycle de vie logiciel en une source unique de contexte, afin que les entreprises puissent standardiser les pipelines, les contrôles et les métriques à grande échelle. L'innovation continue de GitLab en matière de capacités pilotées par l'IA renforce sa pertinence sur le long terme, à mesure que les entreprises adoptent des workflows agentiques pour réduire la durée de création de valeur.

GitLab et TCS synchronisent l'orchestration multi-agents, la planification dynamique, la prise de décisions basée sur des scores de confiance et les cycles d'apprentissage continu afin d'automatiser le développement, les revues de code, les tests, la sécurité et les workflows CI/CD.

GitLab Duo Agent Platform assure une orchestration intelligente du cycle de vie logiciel grâce à des actions autonomes en contexte, un raisonnement en plusieurs étapes, une modernisation du code, des scans de sécurité et une automatisation des flows pour simplifier et accélérer le développement logiciel. Cette approche s'aligne naturellement avec la hiérarchie structurée des agents de TCS pour les opérations informatiques, qui favorise le raisonnement dynamique et la planification, et permet aux agents de domaine d'invoquer les agents spécialisés de GitLab Duo Agent Platform (par exemple, les agents Planner, Security Analyst, Code Review) via des intégrations alimentées par Model Context Protocol (MCP) et des flows avec un contexte de projet enrichi, le tout sous des contrôles DevSecOps avec l'IA native de GitLab.

Développer le DevSecOps grâce à l'ingénierie de plateforme

L'ingénierie de plateforme se détourne de la gestion des pipelines et des chaînes d'outils individuels pour se concentrer sur la construction d'une plateforme de développement interne (IDP) qui standardise la manière dont les logiciels sont développés, sécurisés, testés et déployés à l'échelle de l'organisation.

Les entreprises peuvent se développer en industrialisant l'expérience développeur via l'ingénierie de plateforme et en opérant des IDP avec des Golden Paths en libre-service. La sécurité, la conformité et la gouvernance sont intégrées par défaut via la politique en tant que code afin de standardiser les opérations Jour 2. GitLab devient le plan de contrôle de l'IDP, alors que TCS industrialise la conception et déploie le libre-service comme interface au-dessus de ce plan de contrôle pour offrir une expérience de développement de qualité. En tant que solutions architect, TCS construit des parcours en libre-service, tandis que GitLab Duo Agent Platform y ajoute une IA agentique pour automatiser le développement tout au long du SDLC.

Passer du DevSecOps à l'orchestration intelligente

Une plateforme DevSecOps unifiée offre aux entreprises une base solide, mais à mesure que les agents d'IA deviennent des participants actifs du cycle de développement logiciel, la plateforme ne doit pas se contenter de gérer le code et les pipelines. Elle doit orchestrer conjointement le travail des équipes et des agents d'IA, avec un contexte de cycle de développement complet et des garde-fous intégrés. GitLab Duo Agent Platform concrétise ce passage du DevSecOps à l'orchestration intelligente et améliore la qualité de la livraison logicielle à long terme.

GitLab Duo Agent Platform

GitLab Duo Agent Platform introduit dans le cycle de développement logiciel des agents d'IA qui travaillent aux côtés des équipes en tant que collaborateurs. Plusieurs agents d'IA traitent des tâches en parallèle, de la génération de code aux tests en passant par les corrections CI/CD, afin de réduire les goulots d'étranglement et d'accélérer les releases. Les équipes pilotent et guident ces agents via des règles définies afin de conserver le contrôle et de déléguer les tâches répétitives. Cette orchestration d'agents prend en charge des workflows complexes (comme la correction automatique des pipelines en échec) et permet aux équipes de se concentrer sur les tâches à plus forte valeur ajoutée.

Les agents d'IA opèrent au sein du modèle de données unifié de GitLab : ils créent des merge requests, améliorent le code et assurent la conformité pour accroître la productivité et la vélocité. Étant donné que toutes les actions des agents bénéficient d'un contexte de projet complet, sont auditables et alignées sur les politiques, les entreprises peuvent déployer l'IA à grande échelle pour des milliers d'ingénieurs en toute confiance, en maintenant la sécurité et la conformité réglementaire dans tous les workflows automatisés. Résultat : la charge est réduite pour les Application Engineers, les DevSecOps Engineers, les Scrum Masters et les Product Managers.

Comprendre l'architecture de référence

GitLab et TCS, un partenariat puissant

GitLab fournit une plateforme d'orchestration intelligente pour le DevSecOps dans laquelle les équipes logicielles et les agents d'IA collaborent tout au long du cycle de développement. TCS propose des moteurs d'adoption industrialisés, des architectures de référence éprouvées, des centres de migration à grande échelle, des normes de sécurité de niveau entreprise, des capacités d'IA d'entreprise, des outils et frameworks de gestion de la confiance et des risques liés à l'IA, ainsi qu'une culture produit pour les opérations de plateforme.

Ce partenariat se distingue par la connaissance contextuelle que TCS a acquise au fil des décennies dans le cadre de projets dans de nombreux secteurs, zones géographiques et environnements réglementaires. Cette expérience permet à TCS de contextualiser les capacités de GitLab pour répondre aux contraintes des entreprises comme les systèmes legacy, les exigences de conformité, les modèles opérationnels et les défis liés à la mise à l'échelle plutôt que de déployer des outils de manière isolée. Ensemble, GitLab et TCS garantissent une livraison rapide, fiable et à l'échelle de l'entreprise, sur tous les clouds et avec une conformité intégrée.

Pour en savoir plus sur GitLab et TCS, veuillez envoyer un e-mail à l'adresse suivante : ecosystem@gitlab.com.

Dans ce guide, nous vous présenterons la configuration de l'authentification SAML entre Google Workspace et GitLab.com, en incluant la synchronisation automatique des groupes qui associe les groupes Google Workspace aux rôles GitLab. À la fin de ce processus, vos utilisateurs pourront se connecter à GitLab avec leurs identifiants Google, et leurs autorisations refléteront automatiquement leurs adhésions aux groupes Google.

Remarque : ce guide se concentre sur GitLab.com (version SaaS). Si vous utilisez GitLab Self-Managed, le processus de configuration diffère légèrement. Consultez la documentation officielle GitLab relative au protocole SAML pour les instances auto-gérées pour obtenir des instructions détaillées.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

• Google Workspace avec un accès super-administrateur
• GitLab.com avec un abonnement de niveau GitLab Premium ou GitLab Ultimate
• Rôle de propriétaire dans un groupe principal GitLab
• Des utilisateurs déjà existants dans Google Workspace (ils seront créés automatiquement dans GitLab lors de leur première connexion)

Comprendre l'architecture

Lorsque vous configurez l'authentification unique basée sur le protocole SAML avec la synchronisation de groupe, voici ce qui se produit :

1. Flux d'authentification : les utilisateurs accèdent à l'URL d'authentification SSO de GitLab et sont redirigés vers Google Workspace pour s'authentifier.
2. Assertion SAML : après une authentification réussie, Google envoie une réponse SAML contenant les détails de l'utilisateur et ses adhésions aux groupes.
3. Provisionnement automatique : GitLab crée le compte utilisateur (si nécessaire) et l'assigne aux groupes en fonction de ses adhésions aux groupes Google.
4. Synchronisation des autorisations : chaque fois que les utilisateurs se connectent, GitLab met à jour leurs adhésions aux groupes et leurs rôles pour qu'elles correspondent à leurs groupes Google actuels.

Cette configuration offre plusieurs avantages :

• Contrôle d'accès centralisé : vous pouvez gérer l'accès des utilisateurs via les groupes Google Workspace.
• Provisionnement automatique : les nouveaux utilisateurs obtiennent un accès à GitLab dès leur première connexion.
• Autorisations dynamiques : les rôles des utilisateurs se mettent à jour automatiquement en fonction des modifications de l'adhésion aux groupes.
• Sécurité renforcée : vous pouvez exploiter les fonctionnalités de sécurité d'authentification de Google.
• Réduction de la charge administrative : il n'est pas nécessaire de gérer manuellement les adhésions aux groupes GitLab.

Partie 1 : obtenir vos valeurs de configuration SAML GitLab

Tout d'abord, vous devrez collecter certaines informations depuis GitLab que vous utiliserez lors de la création de l'application SAML dans Google Workspace. Voici les étapes à suivre :

Étape 1 : accéder aux paramètres SAML de votre groupe GitLab

1. Connectez-vous à GitLab.com.
2. Accédez à votre groupe principal (remarque : l'authentification SSO SAML ne peut être configurée qu'au niveau du groupe principal, pas dans les sous-groupes).
3. Dans la barre latérale gauche, sélectionnez Paramètres > Authentification unique SAML.

Étape 2 : copier les URL requises

Sur la page des paramètres relatifs à l'authentification unique SAML, vous verrez trois URL importantes. Copiez-les et enregistrez-les dans un endroit accessible, vous en aurez bientôt besoin :

• URL du service consommateur d'assertion : c'est ici que Google enverra les réponses SAML.
  • Format : https://gitlab.com/groups/your-group/-/saml/callback
• Identifiant : également appelé ID de l'entité, il identifie de manière unique votre groupe GitLab.
  • Format : https://gitlab.com/groups/your-group
• URL de l'authentification unique GitLab : c'est l'URL que vos utilisateurs utiliseront pour se connecter.
  • Format : https://gitlab.com/groups/your-group/-/saml/sso

Vous allez maintenant créer une application SAML personnalisée dans Google Workspace qui se connecte à votre groupe GitLab.

Étape 3 : accéder à la console d'administration Google

1. Ouvrez un nouvel onglet de navigateur et connectez-vous à la console d'administration Google avec un compte super-administrateur.
2. Cliquez sur l'icône Menu (☰) en haut à gauche.
3. Accédez à Applications > Applications Web et mobiles.
4. Cliquez sur Ajouter une application > Ajouter une application SAML personnalisée.

Étape 4 : configurer le nom de l'application

1. Dans le champ Nom de l'application, saisissez GitLab (ou le nom de votre choix).
2. Facultatif : téléchargez un logo GitLab comme icône d'application pour faciliter l'identification de l'application.
3. Cliquez sur Continuer.

Étape 5 : télécharger les détails du fournisseur d'identité Google

Sur la page Détails du fournisseur d'identité Google, vous devrez enregistrer deux éléments :

1. URL d'authentification SSO : copiez cette URL. Elle indique à GitLab où envoyer les demandes d'authentification.
   • Format d'exemple : https://accounts.google.com/o/saml2/idp?idpid=C1234abcd
2. Certificat : cliquez sur le bouton Télécharger pour enregistrer le fichier de certificat.
   • Le fichier sera nommé comme l'exemple suivant : GoogleIDPCertificate-gitlab.pem.
   • Enregistrez ce fichier dans un endroit où vous pourrez facilement le retrouver. Vous en aurez besoin dans la section suivante.
3. Cliquez sur Continuer.

Étape 6 : configurer les détails du fournisseur de services

C'est ici que vous utiliserez les URL GitLab que vous avez copiées à l'étape 2. Saisissez les informations suivantes :

Cliquez sur Continuer une fois que vous avez terminé.

Étape 7 : configurer le mappage des attributs

Le mappage des attributs indique à Google quelles informations utilisateur envoyer à GitLab. Vous configurerez à la fois les attributs des utilisateurs de base et l'adhésion aux groupes.

Attributs de base

Ajoutez ces trois mappages d'attributs en cliquant sur Ajouter un mappage pour chacun :

Configuration de l'adhésion aux groupes

Il s'agit de la configuration critique qui permet la synchronisation automatique des groupes :

1. Faites défiler jusqu'à la section « Adhésion aux groupes (facultatif) ».
2. Sous « Groupes Google », cliquez sur « Rechercher un groupe ».
3. Recherchez et sélectionnez chaque groupe Google Workspace que vous souhaitez synchroniser avec GitLab.
   • Vous pouvez sélectionner jusqu'à 75 groupes
   • Exemples : Ingénierie, DevOps, Équipe plateforme, Équipe sécurité
4. Sous « Attribut de l'application », saisissez exactement : groups.
5. Cliquez sur Terminer.

Important : le nom de l'attribut de l'application DOIT être exactement groups (minuscules). C'est ce que GitLab s'attend à recevoir dans la réponse SAML. Toute autre valeur ou majuscule empêchera la synchronisation des groupes.

Étape 8 : activer l'application pour les utilisateurs

Votre application SAML est créée mais pas encore activée. Pour la rendre disponible aux utilisateurs :

1. Dans la console d'administration Google, repérez votre application GitLab dans la liste des applications Web et mobiles.
2. Cliquez sur l'application pour accéder aux détails.
3. Dans la barre latérale gauche, cliquez sur Accès utilisateur.
4. Sélectionnez l'une des options suivantes :
   • ACTIVÉ pour tous : active l'application pour tous les utilisateurs de votre organisation
   • ACTIVÉ pour certaines unités organisationnelles : sélectionnez des unités organisationnelles spécifiques
5. Cliquez sur Enregistrer.

Remarque : les modifications peuvent nécessiter jusqu'à 24 heures, mais prennent généralement effet en quelques minutes.

Partie 3 : convertir le certificat au format d'empreinte SHA-1

GitLab requiert une empreinte de certificat SHA-1, mais le téléchargement du certificat de Google n'inclut pas directement ce format. Vous devrez le convertir.

Étape 9 : convertir le certificat

Vous avez deux options pour convertir le certificat au format requis.

Option 1 : outil de conversion en ligne

Il s'agit d'une méthode viable si vous êtes à l'aise avec l'utilisation d'un outil tiers :

1. Localisez le fichier de certificat que vous avez téléchargé à l'étape 5 :
   • Vérifiez votre dossier Téléchargements
   • Le fichier aura un nom similaire à GoogleIDPCertificate-gitlab.pem
2. Ouvrez le fichier dans un éditeur de texte :
   • Mac : Clic droit > Ouvrir avec > TextEdit
   • Windows : Clic droit > Ouvrir avec > Bloc-notes
   • Linux : utilisez votre éditeur de texte préféré
3. Copiez TOUT le contenu du fichier, y compris l'en-tête et le pied de page :

-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAXqD...
(plusieurs lignes de texte encodé)
...kE7RnF6yQ==
-----END CERTIFICATE-----

4. Accédez à : un outil de conversion d'empreinte SHA-1 comme celui-ci.
5. Collez le contenu du certificat dans la zone de texte.
6. Sélectionnez « SHA-1 » dans le menu déroulant de l'algorithme (et non SHA-256 !).
7. Cliquez sur « Calculer l'empreinte ».
8. Copiez l'empreinte résultante : elle sera au format : XX:XX:XX:XX:XX:....

Option 2 : conversion en ligne de commande

Si vous préférez utiliser la ligne de commande :

Pour Mac, Linux ou Windows avec WSL :

cd ~/Downloads
openssl x509 -noout -fingerprint -sha1 -inform pem -in "GoogleIDPCertificate-gitlab.pem"

Les données de sortie afficheront :

SHA1 Fingerprint=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX

Copiez tout ce qui se trouve après SHA1 Fingerprint=.

Partie 4 : finaliser la configuration SAML GitLab

Maintenant que vous disposez de l'URL d'authentification SSO Google et de l'empreinte du certificat, vous pouvez finaliser la configuration côté GitLab.

Étape 10 : saisir les détails du fournisseur d'identité Google

Retournez à votre onglet de navigateur GitLab (Paramètres > Authentification unique SAML) et procédez comme suit :

1. URL de l'authentification SSO du fournisseur d'identité :
   • Collez l'URL de l'authentification SSO que vous avez copiée depuis Google à l'étape 5.
2. Empreinte du certificat :
   • Collez l'empreinte SHA-1 que vous avez générée à l'étape 9.
   • Vérifiez que le format est correct : 59 caractères avec des deux-points (XX:XX:XX:...).
3. Activer l'authentification SAML pour ce groupe :
   • Cochez cette case pour activer l'authentification SSO SAML.

Étape 11 : configurer les paramètres de sécurité (recommandé)

Pour renforcer la sécurité, envisagez d'activer ces options supplémentaires :

• Mettre en œuvre l'authentification unique SSO pour l'activité Web de ce groupe
  • Cette option oblige les utilisateurs à s'authentifier via SAML pour accéder à l'interface Web GitLab.
• Mettre en œuvre l'authentification unique SSO pour les activités de Git et du proxy de dépendance pour ce groupe
  • Cette option exige l'authentification SAML pour les opérations Git et l'accès au proxy de dépendances.

Cliquez sur Enregistrer les modifications pour appliquer votre configuration.

Étape 12 : tester la configuration SAML

Avant de procéder à la synchronisation des groupes, vérifiez que l'authentification SAML de base fonctionne :

1. Ouvrez une fenêtre de navigation privée ou incognito.
2. Accédez à votre URL d'authentification SSO GitLab.
   • Format : https://gitlab.com/groups/your-group/-/saml/sso
3. Vous devriez être redirigé vers la page de connexion Google.
4. Connectez-vous avec un compte Google Workspace qui a accès à l'application GitLab.
5. Après une authentification réussie, vous devriez être redirigé vers GitLab.

Si le test réussit, vous pouvez procéder à la configuration de la synchronisation des groupes.

Si le test échoue, vérifiez les points suivants :

• Vérifiez que l'empreinte du certificat est au format SHA-1 (et non SHA-256).
• Confirmez que l'URL de l'authentification SSO est correcte.
• Assurez-vous que l'utilisateur a accès à l'application SAML GitLab dans la console d'administration Google.
• Vérifiez que l'URL ACS et l'ID de l'entité correspondent exactement.

Partie 5 : configurer la synchronisation des groupes SAML

Il est maintenant temps de mapper vos groupes Google Workspace aux rôles GitLab afin que les autorisations soient automatiquement gérées en fonction de l'adhésion aux groupes.

Étape 13 : configurer le rôle d'adhésion par défaut

Comme bonne pratique de sécurité, définissez un rôle par défaut minimal pour les utilisateurs qui se connectent mais n'appartiennent à aucun groupe mappé :

1. Dans votre groupe GitLab, accédez à Paramètres > Général.
2. Développez la section Permissions et fonctionnalités du groupe.
3. Sous Rôle d'adhésion par défaut, sélectionnez Accès minimal ou Invité.
4. Cliquez sur Enregistrer les modifications.

Étape 14 : créer des liens de groupe SAML

Les liens de groupe SAML représentent les mappages entre les groupes Google Workspace et les rôles GitLab. Voici comment les créer :

1. Dans votre groupe GitLab, accédez à Paramètres > Liens de groupe SAML.
2. Cliquez sur « Ajouter un nouveau lien de groupe SAML ».

Pour chaque groupe Google Workspace que vous souhaitez synchroniser :

Nom du groupe SAML :

• Saisissez le nom exact de votre groupe Google Workspace
• Il est sensible à la casse et doit correspondre parfaitement
• Exemple : Ingénierie (et non ingénierie)
• Pour trouver le nom exact : Console d'administration Google > Annuaire > Groupes

Niveau d'accès : sélectionnez le rôle GitLab approprié :

• Accès minimal : peut voir que le groupe existe
• Invité : peut afficher les tickets et laisser des commentaires
• Rapporteur : peut récupérer le code, afficher les tickets et créer de nouveaux tickets
• Développeur : peut effectuer un push du code, créer des merge requests et gérer les tickets
• Chargé de maintenance : peut gérer les paramètres du projet et les membres
• Propriétaire : il possède le contrôle administratif complet sur le groupe

3. Cliquez sur Enregistrer.
4. Répétez ce processus pour chaque groupe Google Workspace que vous souhaitez mapper.

Remarque : les règles de synchronisation des groupes SAML sont appliquées chaque fois qu'un utilisateur se connecte. Si l'adhésion d'un utilisateur à un groupe Google correspond à une règle de synchronisation, son rôle GitLab sera automatiquement défini sur le niveau d'accès configuré, même si vous l'avez modifié manuellement. Par exemple, si vous configurez une règle de synchronisation qui accorde un accès « Chargé de maintenance » puis que vous promouvez manuellement un utilisateur à « Propriétaire », il sera automatiquement rétrogradé à « Chargé de maintenance » » lors de sa prochaine connexion SAML.

Bonnes pratiques : pour maintenir des niveaux d'accès personnalisés pour des utilisateurs spécifiques, effectuez l'une des actions suivantes :

• Utilisez la synchronisation de groupe SAML uniquement sur votre groupe principal et gérez manuellement les autorisations dans les sous-groupes.
• Créez des groupes Google séparés pour les utilisateurs qui nécessitent des autorisations élevées.
• Évitez de configurer des règles de synchronisation qui entreraient en conflit avec les affectations de rôles manuelles.

Exemple de configuration de mappage de groupes

Voici un exemple pratique de la façon dont vous pourriez structurer vos mappages de groupes :

Étape 15 : vérifier les liens de groupe

Après avoir créé tous vos liens de groupe :

1. Examinez la liste complète des liens de groupe SAML dans Paramètres > Liens de groupe SAML.
2. Vérifiez que chaque nom de groupe SAML correspond exactement au groupe Google Workspace correspondant.
3. Vérifiez que chaque niveau d'accès est approprié pour l'objectif prévu.
4. Vérifiez les fautes de frappe ou les espaces supplémentaires.

Partie 6 : tester la configuration complète

Il est maintenant temps de tester l'ensemble de la configuration, y compris la synchronisation des groupes.

Étape 16 : tester avec un utilisateur réel

Choisissez un utilisateur de test qui répond à ces critères :

• Possède un compte Google Workspace
• Est membre d'au moins un groupe Google Workspace que vous avez configuré
• A l'application SAML GitLab activée dans la console d'administration Google
• Idéalement, est quelqu'un d'autre que vous (pour garantir un test réaliste)

Pour effectuer le test :

1. Ouvrez une fenêtre de navigation privée ou incognito
2. Accédez à votre URL d'authentification SSO GitLab :
   • https://gitlab.com/groups/your-group/-/saml/sso
3. Connectez-vous avec les identifiants Google Workspace de l'utilisateur de test
4. L'utilisateur devrait être :
   • Authentifié avec succès
   • Redirigé vers GitLab
   • Ajouté automatiquement au groupe GitLab
   • Assigné au rôle approprié en fonction de son adhésion au groupe Google

Étape 17 : vérifier l'adhésion au groupe et l'attribution de rôle

Dans votre compte administrateur GitLab :

1. Accédez à votre groupe dans GitLab.
2. Sélectionnez Gestion > Membres dans la barre latérale gauche.
3. Trouvez l'utilisateur de test dans la liste des membres.
4. Vérifiez les points suivants :
   • L'utilisateur apparaît dans la liste des membres.
   • L'utilisateur a le rôle maximum correct en fonction de son/ses groupe(s) Google.
   • La colonne Source affiche un indicateur SAML.

Partie 7 : configurer l'accès aux sous-groupes (facultatif)

Pour les grandes organisations, vous souhaiterez peut-être fournir un contrôle d'accès plus granulaire en utilisant les sous-groupes GitLab. Les liens de groupe SAML peuvent être configurés à n'importe quel niveau de votre hiérarchie de groupes pour vous permettre de mapper différents groupes Google Workspace à des équipes ou projets spécifiques.

Comprendre la structure des sous-groupes GitLab

GitLab prend en charge les hiérarchies de groupes imbriqués qui peuvent refléter votre structure organisationnelle :

acme-corp/                          ← Top-level group (SAML configured here)
├── engineering/                    ← Subgroup
│   ├── backend/                   ← Nested subgroup
│   └── frontend/                  ← Nested subgroup
├── marketing/                      ← Subgroup
└── operations/                     ← Subgroup

Créer des sous-groupes

Si vous devez créer des sous-groupes supplémentaires :

1. Accédez à votre groupe parent (par exemple, acme-corp).
2. Cliquez sur le bouton Nouveau sous-groupe.
3. Configurez le sous-groupe :
   • Nom du sous-groupe : nom affiché (par exemple, Ingénierie)
   • URL du sous-groupe : slug d'URL (par exemple, ingenierie)
   • Niveau de visibilité : choisissez Privé, Interne ou Public
4. Cliquez sur Créer un sous-groupe.
5. Répétez le processus pour les autres sous-groupes si nécessaire.

Configurer les liens de groupe SAML pour les sous-groupes

Suivez les étapes ci-dessous pour configurer les liens de groupe SAML pour les sous-groupes.

Ajouter de nouveaux groupes Google à l'application SAML (si nécessaire)

Si vous ajoutez de nouveaux groupes Google Workspace pour l'accès aux sous-groupes :

1. Accédez à Console d'administration Google > Applications > Applications Web et mobiles > GitLab.
2. Cliquez sur Mappage des attributs SAML.
3. Faites défiler jusqu'à « Adhésion aux groupes (facultatif) ».
4. Ajoutez vos nouveaux groupes (par exemple, équipe backend, équipe frontend).
5. Vérifiez que l'« Attribut de l'application » est toujours groups.
6. Cliquez sur Enregistrer.

Mapper les groupes Google aux sous-groupes

1. Accédez au sous-groupe spécifique dans GitLab
   • Exemple : acme-corp/engineering/backend
2. Accédez à Paramètres > Liens de groupe SAML.
3. Cliquez sur « Ajouter un nouveau lien de groupe SAML ».
4. Configurez le mappage :
   • Nom du groupe SAML : équipe backend (nom exact du groupe Google Workspace)
   • Niveau d'accès : Développeur (ou le rôle de votre choix)
5. Cliquez sur Enregistrer.

Répétez ce processus pour tous les sous-groupes et leurs groupes Google correspondants.

Exemple d'accès multi-niveaux

Voici comment les autorisations pourraient fonctionner à différents niveaux :

Groupe principal : acme-corp

Liens de groupe SAML :

• « Administrateurs de l'entreprise » → Propriétaire
• « Tous les collaborateurs » → Accès minimal

Sous-groupe : acme-corp/engineering

Liens de groupe SAML :

• « Responsables ingénierie » → Propriétaire
• « Équipe ingénierie » → Chargé de maintenance

Sous-groupe imbriqué : acme-corp/engineering/backend

Liens de groupe SAML :

• « Responsables backend » → Chargé de maintenance
• « Équipe backend » → Développeur

Héritage et combinaison des autorisations

Comprendre le comportement des autorisations est important :

• Calcul du rôle : à chaque niveau, les utilisateurs reçoivent le rôle le plus élevé de tous leurs groupes Google.
• Héritage : les autorisations plus élevées au niveau des groupes parents sont transmises aux sous-groupes enfants.
• Indépendance : chaque niveau calcule les autorisations en fonction de ses propres liens de groupe et des autorisations héritées.
• Aucune limitation : les autorisations inférieures au niveau des groupes parents ne restreignent PAS les autorisations supérieures au niveau des groupes enfants.

Exemples de scénarios :

Utilisateur A (membre de l'équipe backend uniquement) :

• acme-corp : accès minimal (depuis « Tous les collaborateurs » par défaut)
• acme-corp/engineering : accès minimal (hérité du groupe parent)
• acme-corp/engineering/backend : Développeur (depuis le mappage « Équipe backend »)

Utilisateur B (membre des responsables ingénierie et de l'équipe backend) :

• acme-corp : accès minimal (depuis « Tous les collaborateurs » par défaut)
• acme-corp/engineering : Propriétaire (depuis le mappage « Responsables ingénierie »)
• acme-corp/engineering/backend : Propriétaire (hérité du groupe parent, qui est supérieur à Développeur)

Comment fonctionne la synchronisation ?

Comprendre les mécanismes de synchronisation des groupes SAML vous aide à gérer le système efficacement.

Calendrier de synchronisation

• Synchronisation : les adhésions aux groupes se mettent à jour chaque fois qu'un utilisateur se connecte via SAML.
• Fréquence : les modifications ne sont pas continues, elles ne se produisent qu'à la connexion.
• Direction : la synchronisation est unidirectionnelle de Google Workspace vers GitLab.
• Première connexion : le compte utilisateur est créé automatiquement et les groupes sont affectés.
• Connexions suivantes : les adhésions aux groupes existantes sont mises à jour pour correspondre aux groupes Google actuels.

Priorité et combinaison des rôles

Si un utilisateur appartient à plusieurs groupes Google Workspace :

• GitLab évalue tous les groupes de l'utilisateur à chaque niveau de la hiérarchie.
• L'utilisateur obtient le rôle le plus élevé de l'un de ses groupes.
• Ce calcul se produit indépendamment à chaque niveau (groupe principal, sous-groupes, etc.).

Exemple :

• Utilisateur dans « Développeurs » (rôle Développeur) + « Responsables tech » (rôle Chargé de maintenance) → Chargé de maintenance

Modifications automatiques de rôle

Le système gère automatiquement les modifications d'adhésion :

• Utilisateur ajouté à un groupe Google : rôle mis à niveau lors de la prochaine connexion.
• Utilisateur supprimé d'un groupe Google : rôle recalculé en fonction des groupes restants lors de la prochaine connexion.
• Utilisateur supprimé de tous les groupes mappés : revient au rôle d'adhésion par défaut lors de la prochaine connexion.
• Utilisateur ajouté à des groupes supplémentaires : obtient le rôle le plus élevé de tous les groupes lors de la prochaine connexion.

Calendrier de propagation

Voici le calendrier de propagation à prendre en compte :

• Modifications Google Workspace : peuvent prendre jusqu'à 24 heures pour se propager, bien qu'elles ne prennent généralement que quelques minutes.
• Synchronisation GitLab : se produit immédiatement lorsque l'utilisateur se connecte après que les modifications Google sont actives.
• Tests : demandez aux utilisateurs de se déconnecter et de se reconnecter pour tester les modifications d'autorisations.

Comprendre le cycle de vie des utilisateurs et les cas particuliers

Que se passe-t-il lorsque vous supprimez un utilisateur de GitLab ?

Suppression des autorisations uniquement : si vous supprimez un utilisateur des projets GitLab mais laissez son compte actif et qu'il est toujours dans les groupes Google autorisés :

• Il conserve le même compte (même ID d'utilisateur et nom d'utilisateur).
• Lorsqu'il se connecte via SAML, ses adhésions aux groupes sont automatiquement restaurées.
• Il retrouve les autorisations en fonction de ses adhésions actuelles aux groupes Google.

Blocage du compte :

• Le compte existe mais est verrouillé.
• L'utilisateur ne peut pas se connecter même s'il est dans les groupes Google.
• Peut être débloqué ultérieurement, en préservant tout l'historique.

Suppression du compte :

• Le compte est définitivement supprimé.
• Si l'utilisateur se connecte à nouveau (tout en étant toujours dans les groupes Google), GitLab crée un compte entièrement nouveau.
• Le nouveau compte a un ID d'utilisateur différent sans aucune connexion avec l'ancien.

Processus de désactivation approprié

Pour révoquer définitivement l'accès d'un utilisateur, suivez ces étapes :

1. Supprimez l'utilisateur des groupes Google Workspace pour empêcher l'authentification.
2. Bloquez l'utilisateur dans GitLab pour empêcher la recréation du compte et préserver les pistes d'audit.
3. Supprimez le compte (facultatif) seulement si vous êtes certain que l'utilisateur ne reviendra pas.

Important : supprimer un utilisateur uniquement de GitLab sans le supprimer des groupes Google signifie qu'il peut simplement se reconnecter et obtenir un nouvel accès.

Propagation de l'adhésion aux groupes Google

Selon la documentation de Google, les modifications d'adhésion aux groupes peuvent prendre jusqu'à 24 heures pour se propager, bien qu'elles se produisent généralement en quelques minutes.

Scénarios de recréation de compte

Dépannage des problèmes courants

Même une configuration minutieuse peut entraîner des problèmes. Voici des solutions pour remédier aux problèmes les plus courants.

Les utilisateurs ne sont pas ajoutés aux groupes

Problème : l'utilisateur se connecte avec succès via SAML mais n'apparaît dans aucun groupe GitLab, ou apparaît seulement avec le rôle par défaut.

Causes possibles et solutions :

1. Les noms de groupe ne correspondent pas exactement
   • Vérifiez l'orthographe et les majuscules dans Google Workspace et GitLab.
   • Recherchez les espaces supplémentaires avant ou après les noms de groupe.
   • Vérifiez le nom exact dans Console d'administration Google > Annuaire > Groupes.
2. L'utilisateur n'est pas réellement dans le groupe Google
   • Vérifiez l'adhésion : Console d'administration Google > Annuaire > Groupes > Groupe > Membres.
   • N'oubliez pas que l'adhésion aux groupes imbriqués pourrait être exclue.
3. Les groupes ne sont pas configurés dans l'application SAML
   • Vérifiez que les groupes sont sélectionnés dans le mappage des attributs SAML Google.
   • Confirmez que l'« Attribut de l'application » est défini sur groups (minuscules).
   • Réalisez un test de connexion SAML pour inspecter la réponse SAML.
4. Problème de calendrier ou de cache
   • Attendez 24 heures pour que les modifications Google se propagent complètement.
   • Demandez à l'utilisateur de se déconnecter complètement de GitLab et Google.
   • Effacez le cache du navigateur et réessayez.
   • L'utilisateur doit se connecter via l'URL d'authentification unique SAML, pas la connexion GitLab normale.

L'utilisateur a un rôle incorrect

Problème : l'utilisateur a accès mais possède le mauvais niveau d'autorisation.

Causes possibles et solutions :

1. L'utilisateur appartient à plusieurs groupes
   • Rappel : les utilisateurs obtiennent le rôle le plus élevé de tous leurs groupes.
   • Vérifiez tous les groupes Google auxquels l'utilisateur appartient.
   • Examinez toutes les configurations de liens de groupe SAML à tous les niveaux.
2. Lien de groupe SAML mal configuré
   • Vérifiez le paramètre Niveau d'accès dans Paramètres > Liens de groupe SAML.
   • Recherchez les mappages de groupes en double qui pourraient entrer en conflit.
3. L'utilisateur ne s'est pas connecté depuis les modifications
   • Les rôles ne se mettent à jour que lorsque les utilisateurs se connectent via SAML.
   • Demandez à l'utilisateur de se déconnecter complètement et de se reconnecter via l'URL d'authentification SSO.
4. Autorisations héritées des groupes parents
   • Vérifiez les liens de groupe SAML dans les groupes parents.
   • N'oubliez pas que les rôles plus élevés au niveau des groupes parents sont transmis aux groupes enfant.

L'authentification SAML échoue complètement

Problème : les utilisateurs ne peuvent pas du tout se connecter ou reçoivent des messages d'erreur pendant l'authentification.

Causes possibles et solutions :

1. Empreinte de certificat incorrecte
   • Vérifiez que vous avez utilisé le format SHA-1, et non SHA-256.
   • Vérifiez que l'empreinte a le format correct avec des deux-points.
   • Régénérez un certificat en utilisant l'outil en ligne ou la commande OpenSSL.
2. URL d'authentification unique incorrecte
   • Vérifiez à nouveau l'URL d'authentification unique copiée depuis Google.
   • Assurez-vous qu'il n'y a pas d'espaces ou de caractères supplémentaires.
3. Incompatibilité de l'URL ACS ou de l'ID de l'entité
   • Vérifiez que l'URL ACS dans la console d'administration Google correspond exactement à GitLab.
   • Confirmez que l'ID de l'entité correspond entre les deux systèmes.
4. L'utilisateur n'a pas d'accès à l'application
   • Vérifiez les paramètres d'accès utilisateur dans la console d'administration Google.
   • Vérifiez que l'unité organisationnelle de l'utilisateur a l'application activée.
   • Confirmez que l'application est activée pour les utilisateurs appropriés.
5. Certificat expiré
   • Vérifiez les dates de validité du certificat.
   • Téléchargez un nouveau certificat si nécessaire.

Attribut de groupe manquant dans la réponse SAML

Problème : les utilisateurs peuvent se connecter, mais la synchronisation des groupes ne fonctionne pas.

Causes possibles et solutions :

1. Groupes non sélectionnés dans la configuration Google
   • Retournez à Console d'administration Google > Applications > GitLab > Mappage des attributs.
   • Vérifiez que les groupes sont sélectionnés sous « Adhésion aux groupes ».
   • Confirmez que l'« Attribut de l'application » est exactement groups (minuscules).
2. L'utilisateur n'est dans aucun groupe configuré
   • Seuls les groupes auxquels l'utilisateur appartient sont envoyés dans la réponse SAML.
   • Ajoutez l'utilisateur à au moins un groupe sélectionné pour effectuer un test.
3. La configuration ne s'est pas propagée
   • Attendez jusqu'à 24 heures pour que les modifications prennent effet.
   • Essayez de vous déconnecter de la console d'administration Google et de vous reconnecter.
4. Faute de frappe dans le nom de l'attribut de l'application
   • Le nom de l'attribut doit être exactement groups (minuscules).
   • Une lettre majuscule ou un espace supplémentaire cassera la fonctionnalité.

Bonnes pratiques pour gérer la synchronisation de groupe SAML

Suivez ces recommandations pour maintenir une configuration sécurisée et efficace.

Bonnes pratiques de sécurité

1. Maintenir un accès d'urgence
   • Conservez au moins un compte Propriétaire qui utilise l'authentification par mot de passe (pas SAML).
   • Vous aurez un accès d'urgence si la configuration SAML ne fonctionne plus.
   • Stockez ces identifiants de façon sécurisée.
2. Utiliser le principe du moindre privilège
   • Définissez l'adhésion par défaut sur Accès minimal.
   • Accordez uniquement des autorisations plus élevées via des mappages de groupes explicites.
   • Examinez et auditez régulièrement les adhésions aux groupes.
3. Activer les options d'application
   • Activez les options « Mettre en œuvre l'authentification unique SSO ».
   • Cela empêche les utilisateurs de contourner l'authentification unique.
   • Les exceptions doivent être rares et bien documentées.
4. Effectuer des audits de sécurité réguliers
   • Examinez tous les trimestre les adhésions aux groupes Google Workspace.
   • Vérifiez chaque année les mappages de liens de groupe SAML.
   • Surveillez les journaux d'audit GitLab pour détecter les schémas d'accès inhabituels.

Résumé et prochaines étapes

Félicitations ! Vous avez configuré avec succès l'authentification unique basée sur le protocole SAML et la synchronisation automatique des groupes entre Google Workspace et GitLab. Votre configuration offre désormais :

• Une authentification transparente : les utilisateurs se connectent avec leurs identifiants Google Workspace.
• Un provisionnement automatique : les comptes utilisateur sont créés lors de la première connexion sans intervention manuelle.
• Des autorisations dynamiques : les adhésions aux groupes et les rôles se mettent à jour automatiquement en fonction des groupes Google Workspace.
• Un contrôle d'accès centralisé : gérez tous les accès via vos groupes Google Workspace existants.
• Une sécurité renforcée : exploitez l'infrastructure d'authentification de Google et appliquez des politiques cohérentes.
• Une réduction de la charge administrative : éliminez la gestion manuelle des utilisateurs et des autorisations dans GitLab.

Fonctionnement correct

Lorsque les utilisateurs accèdent à GitLab :

1. Ils accèdent à votre URL d'authentification SSO GitLab.
2. Ils s'authentifient avec leurs identifiants Google Workspace.
3. Ils sont automatiquement ajoutés aux groupes GitLab appropriés.
4. Ils reçoivent des autorisations basées sur leurs adhésions aux groupes Google.
5. Leurs autorisations se mettent à jour chaque fois qu'ils se connectent.

Ressources supplémentaires

• Documentation concernant l'authentification unique basée sur le protocole SAML de GitLab
• Documentation concernant la synchronisation des groupes SAML GitLab
• Configuration de l'application SAML sur Google Workspace
• Outil d'empreinte de certificat SAML

Pour enregistrer une clé d'accès sur votre compte, accédez aux paramètres de votre profil et sélectionnez Compte > Gérer l'authentification.

Les clés d'accès utilisent la technologie WebAuthn et la cryptographie à clé publique, composée d'une clé privée et d'une clé publique. Votre clé privée est stockée de façon sécurisée sur votre appareil et ne le quitte jamais, tandis que votre clé publique est stockée sur GitLab. Même si GitLab était compromis, les attaquants ne pourraient pas utiliser vos identifiants stockés pour accéder à votre compte. Les clés d'accès fonctionnent sur les navigateurs de bureau (Chrome, Firefox, Safari, Edge), les appareils mobiles (iOS 16 et versions ultérieures, Android 9 et versions ultérieures) et les clés de sécurité matérielles FIDO2, ce qui vous permet d'enregistrer plusieurs clés d'accès sur vos appareils pour garantir un accès pratique.

GitLab a signé l'engagement Secure by Design de l'agence fédérale CISA, qui vise à améliorer notre posture de sécurité et à aider nos clients à développer des logiciels sécurisés plus rapidement. L'un des objectifs clés de cet engagement est d'augmenter l'utilisation de l'authentification multifacteur (MFA) sur l'ensemble des produits du fabricant. Les clés d'accès font partie intégrante de cet objectif et offrent une méthode MFA fluide qui résiste au hameçonnage et rend la connexion à GitLab à la fois plus sûre et plus pratique.

Si vous avez des questions, souhaitez partager votre expérience ou aimeriez échanger directement avec notre équipe concernant de potentielles améliorations, consultez ce ticket.

Découvrez dans cet article comment les fonctionnalités intégrées de scan de sécurité de GitLab combinées avec l'agent GitLab Duo Security Analyst peuvent transformer la gestion des vulnérabilités d'un processus manuel chronophage en un workflow intelligent et efficace.

Qu'est-ce que le classement des vulnérabilités ?

Le classement des vulnérabilités est le processus d'analyse, de priorisation et de traitement des problèmes de sécurité détectés dans vos applications. Toutes les vulnérabilités ne se valent pas : certaines représentent des risques critiques et nécessitent une attention immédiate, tandis que d'autres peuvent être des faux positifs ou constituent une menace minime dans votre contexte spécifique.

Le classement traditionnel comprend les éléments suivants :

• L'examen des résultats d'analyse provenant de plusieurs outils de sécurité
• L'évaluation de la gravité en fonction des scores CVSS et l'exploitabilité
• La compréhension du contexte, par exemple si le code vulnérable est réellement accessible
• La priorisation de la remédiation en fonction de l'impact métier et du risque
• Le suivi de la résolution jusqu'au déploiement

Ce processus devient extrêmement fastidieux lorsqu’il s’agit de codes sources volumineux et de scans fréquents. C'est là que GitLab entre en jeu : la plateforme relève ces défis grâce à des scans de sécurité intégrés et une analyse alimentée par l'IA.

Comment ajouter des scanners de sécurité intégrés dans GitLab ?

GitLab fournit des scanners de sécurité qui s'intègrent de manière transparente dans vos pipelines CI/CD. Ces scanners s'exécutent automatiquement pendant l'exécution du pipeline et alimentent le rapport de vulnérabilités de GitLab avec les résultats de la branche par défaut.

Quels sont les scanners de sécurité disponibles ?

GitLab propose les scanners suivants :

• Tests statiques de sécurité des applications (SAST) : analysent le code source à la recherche de vulnérabilités
• Analyse des dépendances : identifie les vulnérabilités dans les dépendances du projet
• Analyse des conteneurs : analyse les images Docker à la recherche de vulnérabilités connues
• Tests dynamiques de sécurité des applications (DAST) : testent les applications en cours d'exécution à la recherche de vulnérabilités
• Détection des secrets : détecte les secrets et identifiants validés accidentellement
• Analyse de l'Infrastructure as Code (IaC) : analyse l'Infrastructure as Code à la recherche de mauvaises configurations
• Tests de sécurité des API : testent les API Web pour détecter les bogues et les problèmes de sécurité potentiels
• Test de l’API web par injection de données aléatoires : transmet des valeurs inattendues aux paramètres de fonctionnement des API pour provoquer des comportements et erreurs inattendus dans le backend

Exemple : ajouter des scanners SAST et l'analyse des dépendances

Pour activer le scan de sécurité, ajoutez les scanners à votre fichier .gitlab-ci.yml.

Dans cet exemple, nous incluons les templates SAST et analyse des dépendances qui exécutent automatiquement ces scanners lors de la phase de test. Chaque scanner peut être remplacé à l'aide de variables (qui diffèrent pour chaque scanner). Par exemple, la variable SAST_EXCLUDED_PATHS indique aux SAST d'ignorer les répertoires/fichiers fournis. Les jobs de sécurité peuvent être remplacés à l'aide de la syntaxe des jobs GitLab.

include:
  - template: Security/SAST.gitlab-ci.yml
  - template: Security/Dependency-Scanning.gitlab-ci.yml

stages:
  - test

variables:
  SAST_EXCLUDED_PATHS: "spec/, test/, tests/, tmp/"

Exemple : ajouter l'analyse des conteneurs

GitLab fournit un registre de conteneurs intégré dans lequel vous pouvez stocker des images de conteneurs pour chaque projet GitLab. Pour analyser ces conteneurs à la recherche de vulnérabilités, activez l'analyse des conteneurs.

Dans cet exemple, un conteneur est compilé, puis un push est effectué dans le job build-container à l'étape build. Le conteneur est ensuite analysé dans le même pipeline à l'étape test :

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

stages:
  - build
  - test

build-container:
  stage: build
  variables:
    IMAGE: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $IMAGE .
    - docker push $IMAGE

container_scanning:
  variables:
    CS_IMAGE: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA

Une fois configurés, ces scanners s'exécutent automatiquement dans votre pipeline et transmettent leurs résultats dans le rapport de vulnérabilités.

Remarque : bien que cela ne soit pas abordé dans cet article, veuillez noter que dans les merge requests, les scanners affichent la diff entre les vulnérabilités d'une branche de fonctionnalité et celles de la branche cible. De plus, des politiques de sécurité granulaires peuvent être créées pour empêcher le merge du code vulnérable (sans approbation) si des vulnérabilités sont détectées, ainsi que pour forcer l'exécution des scanners, indépendamment de la façon dont le fichier .gitlab-ci.yml est défini.

Classement des résultats avec le rapport de vulnérabilités et GitLab Pages

Une fois les scanners exécutés, GitLab regroupe tous les résultats dans des vues centralisées pour faciliter le classement.

Accès au rapport de vulnérabilités

Accédez à Sécurisation > Rapport de vulnérabilités dans votre projet ou groupe. Cette page affiche toutes les vulnérabilités découvertes avec les informations clés suivantes :

• Niveaux de gravité (critique, élevé, moyen, faible, info)
• Statut (détecté, confirmé, rejeté, résolu)
• Type de scanner ayant détecté la vulnérabilité
• Fichiers et lignes de code concernés
• Date de détection et informations sur le pipeline

Filtrage et organisation des vulnérabilités

Le rapport de vulnérabilités fournit de puissantes options de filtrage :

• Filtrer par gravité, statut, scanner, identifiant et accessibilité
• Regrouper par gravité, statut, scanner, Open Web Application Security Project Top 10 (OWASP)
• Rechercher des vulnérabilités et expositions communes (CVE) ou des noms de vulnérabilités spécifiques
• Trier par date de détection ou gravité
• Afficher les tendances dans le temps avec le tableau de bord de sécurité

Classement manuel du workflow

Le classement traditionnel dans GitLab implique :

1. L'examen de chaque vulnérabilité en cliquant sur la page de détails
2. L'évaluation de la description et la compréhension de l'impact potentiel
3. L'examen du code affecté via des liens intégrés
4. La vérification des correctifs existants ou des correctifs dans les dépendances
5. La définition du statut (confirmer, rejeter avec motif ou créer un ticket)
6. L'attribution de la responsabilité pour la correction

Voici un exemple de données de vulnérabilité fournies pour permettre le classement, y compris le flux de code :

Sur la page des données relatives aux vulnérabilités, vous pouvez sélectionner Éditer la vulnérabilité pour modifier son statut et fournir un motif. Vous pouvez ensuite créer un ticket et l'attribuer pour la remédiation.

Bien que ce workflow soit complet, il nécessite une expertise en matière de sécurité et peut prendre beaucoup de temps lorsqu'il s'agit de traiter des centaines de résultats. C'est là que l'agent GitLab Duo Security Analyst, qui fait partie de GitLab Duo Agent Platform, devient indispensable.

Agent GitLab Duo Security Analyst : définition et configuration

L'agent GitLab Duo Security Analyst est un outil alimenté par l'IA qui automatise l'analyse et le classement des vulnérabilités. L'agent comprend le contexte de votre application, évalue intelligemment les risques et fournit des recommandations exploitables.

Comment fonctionne l'agent GitLab Duo Security Analyst ?

L'agent analyse les vulnérabilités en :

• Évaluant l'exploitabilité dans le contexte spécifique de votre code source
• Évaluant l'accessibilité pour déterminer si les chemins de code vulnérables sont réellement utilisés
• Priorisant en fonction du risque plutôt que de simples scores CVSS
• Expliquant les vulnérabilités dans un langage clair et exploitable
• Recommandant des mesures correctives spécifiques à votre application
• Réduisant les faux positifs grâce à une analyse contextuelle

Prérequis

Pour utiliser l'agent Security Analyst, vous avez besoin des éléments suivants :

• Un abonnement GitLab Ultimate avec GitLab Duo Agent Platform activé
• Des scanners de sécurité configurés dans votre projet
• Au moins une vulnérabilité dans votre rapport de vulnérabilités

Activation de l'agent Security Analyst

L'agent Security Analyst est un agent par défaut. Contrairement à l'agent GitLab Duo, les agents par défaut comprennent les workflows, frameworks et bonnes pratiques propres à leurs domaines spécialisés. Les agents par défaut sont accessibles directement depuis votre projet sans configuration supplémentaire.

Vous pouvez trouver l'agent Security Analyst dans le catalogue d'IA :

Pour approfondir et voir les détails de l'agent, tels que son invite système et ses outils :

1. Accédez à gitlab.com/explore/.
2. Sélectionnez Catalogue d'IA dans l'onglet latéral.
3. Sélectionnez Security Analyst Agent dans la liste.

L'agent s’intègre directement à votre workflow existant et ne requiert aucune configuration supplémentaire au-delà des prérequis définis.

Identification des vulnérabilités critiques avec l'agent Security Analyst

Voyons maintenant comment tirer parti de l'agent Security Analyst pour identifier et prioriser rapidement les vulnérabilités les plus importantes.

Analyse

Pour démarrer une analyse, accédez à votre projet GitLab (assurez-vous qu'il répond aux prérequis). Vous pouvez ensuite ouvrir GitLab Duo Chat et sélectionner Security Analyst.

Dans le chat, sélectionnez le modèle à utiliser avec l'agent et assurez-vous d'activer le mode agentique.

Un chat s'ouvrira où vous pourrez interagir avec l'agent GitLab Duo Security Analyst en utilisant l'interface conversationnelle de l'agent. Cet agent peut effectuer les actions suivantes :

• Classement des vulnérabilités : analyser et prioriser les résultats de sécurité sur différents types de scan.
• Évaluation des risques : évaluer la gravité, l'exploitabilité et l'impact métier des vulnérabilités.
• Identification des faux positifs : distinguer les menaces réelles des résultats sans danger.
• Gestion de la conformité : comprendre les exigences réglementaires et les délais de correction.
• Rapports de sécurité : générer des résumés de la posture de sécurité et des progrès de remédiation.
• Planification des corrections : créer des plans d'action pour traiter les vulnérabilités.
• Automatisation du workflow de sécurité : rationaliser les tâches répétitives d'évaluation de la sécurité.

De plus, voici les outils dont dispose l'agent Security Analyst :

Par exemple, il est possible de demander « Quelles sont les vulnérabilités les plus critiques et lesquelles dois-je traiter en priorité ? » pour déterminer facilement ce qui est important.

L'agent répondra comme suit :

Exemples de requêtes pour un classement efficace

Voici des requêtes efficaces à utiliser avec l'agent Security Analyst :

Identifier les problèmes critiques :

« Montre-moi les vulnérabilités qui sont activement exploitables dans notre code de production »

Se concentrer sur les vulnérabilités accessibles :

« Quelles sont les vulnérabilités de gravité élevée qui se trouvent dans les chemins de code qui sont réellement exécutés ? »

Comprendre les dépendances :

« Quelles sont les vulnérabilités de dépendances les plus critiques et des correctifs sont-ils disponibles ? »

Obtenir des conseils de remédiation :

« Explique-moi comment corriger la vulnérabilité d'injection SQL dans l'authentification utilisateur »

Vous pouvez également attribuer directement les vulnérabilités aux équipes de développement.

Les recommandations de l'agent

Lorsque l'agent Security Analyst analyse les vulnérabilités, il fournit les éléments suivants :

Évaluation des risques : l'agent explique pourquoi une vulnérabilité est critique au-delà du simple score CVSS et tient compte de l'architecture et des modèles d'utilisation spécifiques de votre application.

Analyse d'exploitabilité : il détermine si le code vulnérable est réellement accessible et exploitable dans votre environnement, ce qui aide à filtrer les risques théoriques.

Mesures correctives : l'agent fournit des conseils spécifiques et concrets sur la façon de corriger les vulnérabilités, y compris des exemples de code le cas échéant.

Classement par ordre de priorité : au lieu de vous submerger avec des centaines de résultats, l'agent vous aide à identifier les principaux problèmes qui doivent être traités en priorité.

Exemple concret de workflow

Voici à quoi pourrait ressembler une session de classement type :

1. Commencer par une vue d'ensemble : « Analyse la posture de sécurité de ce projet et met en évidence les 5 vulnérabilités les plus critiques. »
2. Entrer dans les détails : pour chaque vulnérabilité critique identifiée, posez la question suivante : « Cette vulnérabilité est-elle réellement exploitable dans notre application ? »
3. Planifier la remédiation : « Quel est le correctif recommandé pour ce problème d'injection SQL, et y a-t-il des conséquences à prendre en compte ? »
4. Suivre les progrès : après avoir traité les problèmes critiques, posez la question suivante : « Quelles vulnérabilités dois-je prioriser ensuite ? »

Avantages du classement assisté par agent

L'utilisation de l'agent Security Analyst transforme la gestion des vulnérabilités :

• Gain de temps : réduisez les heures d'analyse manuelle à quelques minutes d'examen guidé
• Meilleure priorisation : concentrez-vous sur les vulnérabilités qui présentent réellement un risque pour votre application
• Transfert de connaissances : apprenez les bonnes pratiques de sécurité grâce aux explications de l'agent
• Normes cohérentes : appliquez une logique de classement cohérente à tous les projets
• Réduction de la fatigue liée aux alertes : filtrez efficacement le bruit et les faux positifs

Lancez-vous dès aujourd'hui

Le classement des vulnérabilités ne doit pas forcément être un processus manuel et fastidieux. En combinant les scanners de sécurité intégrés de GitLab avec l'agent GitLab Duo Security Analyst, les équipes de développement peuvent rapidement identifier et prioriser les vulnérabilités qui comptent vraiment.

La capacité de l'agent à comprendre le contexte, à évaluer le risque réel et fournir des conseils pratiques transforme l'analyse de sécurité d'une simple case à cocher en matière de conformité en une tâche pratique et efficace de votre workflow de développement. Au lieu de vous plonger dans des centaines de rapports de vulnérabilités, vous pouvez concentrer votre énergie sur la résolution des problèmes qui menacent réellement la sécurité de votre application.

Commencez par activer les scanners de sécurité dans vos pipelines GitLab, puis tirez parti de l'agent Security Analyst pour prendre des décisions intelligentes et éclairées concernant la correction des vulnérabilités.

Prêt à vous lancer ? Consultez la documentation de GitLab Duo Agent Platform et la documentation sur l'analyse de sécurité pour commencer à transformer votre workflow de gestion des vulnérabilités dès aujourd'hui.

C'est pourquoi nous sommes ravis de collaborer avec Oracle Cloud Infrastructure (OCI) et Data Intensity, un fournisseur de services gérés de confiance d'Oracle, en vue de proposer une nouvelle option de service géré, le DevSecOps-as-a-Service. Cette option réunit le meilleur des deux mondes : le contrôle offert par GitLab Self-Managed et la simplicité opérationnelle d'un service entièrement géré.

Pourquoi choisir GitLab Self-Managed ?

Avec GitLab Self-Managed, vous bénéficiez d’une maîtrise totale de votre plateforme DevSecOps. Vous contrôlez l'emplacement de vos données, la configuration de votre instance, et pouvez la personnaliser pour répondre à des exigences spécifiques de conformité, de sécurité ou d’exploitation. Ce niveau de contrôle est essentiel pour les organisations avec des exigences réglementaires strictes, des besoins en matière de résidence des données ou des intégrations spécifiques.

Pour certains clients GitLab Self-Managed, la gestion des serveurs et des mises à niveau, le maintien d'une haute disponibilité et la mise en œuvre de la reprise après sinistre constituent des défis qui nécessitent une expertise spécialisée et des ressources dédiées.

Une transition facilitée vers GitLab Self-Managed

Le DevSecOps-as-a-Service de Data Intensity sur OCI élimine ces contraintes opérationnelles tout en préservant les avantages de GitLab Self-Managed en matière de contrôle. Au lieu de construire et de maintenir vous-même votre infrastructure, vous bénéficiez d'une instance GitLab autonome gérée par l'équipe d'experts de Data Intensity, qui s'exécute sur l'infrastructure cloud haute performance d'OCI.

Voici ce que cette offre inclut :

• Instance GitLab autonome sur l'infrastructure OCI
• Surveillance 24 h/24 et 7 j/7, alarmes et assistance
• Correctifs trimestriels programmés pendant vos fenêtres de maintenance choisies
• Sauvegardes automatisées et protection contre les sinistres

Évoluer avec votre organisation

Le service géré de Data Intensity est conçu pour évoluer avec votre équipe : il offre plusieurs niveaux d'architecture adaptés à votre nombre d'utilisateurs et à vos exigences de récupération.

Consultez le site web de Data Intensity pour en savoir plus sur le DevSecOps-as-a-Service.

Pourquoi choisir OCI pour GitLab ?

Oracle Cloud Infrastructure fournit une base solide pour l'exécution de GitLab Self-Managed et offre un environnement sécurisé et hautement performant à un coût nettement inférieur à celui des autres hyperscalers. Les organisations qui migrent leurs charges de travail vers OCI enregistrent généralement des réductions de coûts d'infrastructure de 40 à 50 %, ce qui facilite le financement et la mise à l'échelle des déploiements.

OCI prend en charge un large éventail de modèles de déploiement, des régions de cloud public aux environnements spécialisés (Government Cloud, EU Sovereign Cloud), ainsi que les infrastructures dédiées déployées derrière votre pare-feu. Ces options s'accompagnent d'une tarification, d'outils et d'une expérience opérationnelle cohérents, qui permettent aux équipes de standardiser les déploiements GitLab dans des environnements réglementés, hybrides et mondiaux.

La combinaison de la plateforme DevSecOps complète de GitLab, de l'infrastructure haute performance d'OCI et de l'expertise en services gérés de Data Intensity fournit une solution clé en main qui permet à vos équipes de se concentrer sur ce qui compte : créer des logiciels de qualité.

Cette solution est-elle adaptée à votre organisation ?

Optez pour le DevSecOps-as-a-Service de Data Intensity si vous :

• Souhaitez utiliser GitLab Self-Managed mais avez besoin de minimiser la charge opérationnelle.
• Devez respecter des exigences spécifiques de conformité, de sécurité ou de résidence des données.
• Avez besoin de SLA garantis et de capacités professionnelles de reprise après sinistre.
• Préférez des coûts prévisibles et une gestion d'experts plutôt que de développer une expertise interne en matière d'infrastructure.
• Utilisez déjà ou prévoyez d'utiliser OCI pour votre infrastructure cloud.
• Privilégiez la flexibilité et le contrôle.
• Souhaitez disposer d’une instance dédiée gérée en externe avec le contrôle d'un environnement auto-géré.

Lancez-vous dès aujourd’hui !

Les organisations qui souhaitent exécuter GitLab Self-Managed sur OCI via le DevSecOps-as-a-Service de Data Intensity peuvent contacter Data Intensity sur leur site web pour discuter des exigences spécifiques et commencer la planification du déploiement.

Moderniser votre DevSecOps est plus simple que vous ne le pensez. Data Intensity propose une migration facultative des dépôts de code et des options de personnalisation pour assurer une transition en douceur vers OCI.

Alors que GitLab continue de développer son écosystème de partenaires, des solutions comme celle-ci démontrent notre engagement à offrir aux organisations le choix dans la façon dont elles déploient et gèrent GitLab.

Le développement ne représente aujourd’hui que 20 % du cycle de vie de la livraison logicielle, les 80 % restants deviennent le goulot d'étranglement : les backlogs de révision du code s'accumulent, les scans de sécurité peinent à suivre le rythme, la documentation prend du retard, et la coordination manuelle génère des surcharges croissantes.

La bonne nouvelle est que les mêmes capacités d'IA qui accélèrent le codage individuel peuvent éliminer ces retards à l'échelle de l'équipe. Il suffit d'appliquer l'IA à l'ensemble du cycle de développement logiciel, et pas uniquement lors de la phase de codage.

Vous trouverez ci-dessous 10 prompts prêts à l'emploi issus de la bibliothèque de prompts de GitLab Duo Agent Platform, qui aident les équipes à surmonter les obstacles courants pour accélérer la livraison logicielle. Chaque prompt correspond à un ralentissement spécifique qui apparaît lorsque la productivité individuelle augmente sans que les processus de l'équipe ne s'améliorent en conséquence.

Comment transformer la révision de code de goulot d'étranglement en accélérateur ?

Les développeurs génèrent des demandes de fusion plus rapidement grâce à l'IA, mais les réviseurs humains peuvent vite se retrouver débordés lorsque les cycles de révision s'étendent de quelques heures à plusieurs jours. L'IA peut prendre en charge les tâches de révision courantes, libérant ainsi les réviseurs pour qu'ils se concentrent sur l'architecture et la logique métier plutôt que sur la détection d'erreurs logiques basiques ou de violations de contrats d'API.

Réviser une demande de fusion pour détecter les erreurs logiques

Complexité : Débutant

Catégorie : Révision de code

Invite de la bibliothèque :

Review this MR for logical errors, edge cases, and potential bugs: [MR URL or paste code]

Pourquoi c'est utile : Les outils de lint automatisés détectent les problèmes de syntaxe, mais les erreurs logiques nécessitent de comprendre l'intention. Cette invite identifie les bugs avant même que les réviseurs humains n'examinent le code, réduisant les cycles de révision de plusieurs allers-retours à souvent une seule validation.

Identifier les changements incompatibles dans une demande de fusion

Complexité : Débutant

Catégorie : Révision de code

Invite de la bibliothèque :

Does this MR introduce any breaking changes?

Changes:
[PASTE CODE DIFF]

Check for:
1. API signature changes
2. Removed or renamed public methods
3. Changed return types
4. Modified database schemas
5. Breaking configuration changes

Pourquoi c'est utile : Les changements incompatibles découverts lors du déploiement peuvent entraîner des retours arrière et des incidents. Cette invite déplace cette détection en amont, au stade de la demande de fusion, là où les correctifs sont plus rapides et moins coûteux.

Comment décaler la sécurité vers la gauche sans ralentir le développement ?

Les analyses de sécurité génèrent des centaines de résultats. Les équipes sécurité trient manuellement chacun d'eux pendant que les développeurs attendent l'autorisation de déployer. La plupart des résultats sont des faux positifs ou des problèmes à faible risque, mais identifier les véritables menaces demande expertise et temps. L'IA peut prioriser les résultats selon leur exploitabilité réelle et corriger automatiquement les vulnérabilités courantes, permettant aux équipes sécurité de se concentrer sur les menaces qui comptent vraiment.

Analyser les résultats d'une analyse de sécurité

Complexité : Intermédiaire

Catégorie : Sécurité

Agent : Duo Security Analyst

Invite de la bibliothèque :

@security_analyst Analyze these security scan results:

[PASTE SCAN OUTPUT]

For each finding:
1. Assess real risk vs false positive
2. Explain the vulnerability
3. Suggest remediation
4. Prioritize by severity

Pourquoi c'est utile : La majorité des résultats d'analyses de sécurité sont des faux positifs ou des problèmes à faible risque. Cette invite aide les équipes sécurité à se concentrer sur les résultats qui comptent vraiment, réduisant le temps de remédiation de plusieurs semaines à quelques jours.

Réviser le code pour détecter des problèmes de sécurité

Complexité : Intermédiaire

Catégorie : Sécurité

Agent : Duo Security Analyst

Invite de la bibliothèque :

@security_analyst Review this code for security issues:

[PASTE CODE]

Check for:
1. Injection vulnerabilities
2. Authentication/authorization flaws
3. Data exposure risks
4. Insecure dependencies
5. Cryptographic issues

Pourquoi c'est utile : Les révisions de sécurité traditionnelles interviennent après l'écriture du code. Cette invite permet aux développeurs de détecter et corriger les problèmes de sécurité avant de créer une demande de fusion, supprimant les allers-retours qui retardent les déploiements.

Comment maintenir la documentation à jour au fil des évolutions du code ?

Le code évolue plus vite que la documentation. L'intégration de nouveaux développeurs prend des semaines parce que les docs sont obsolètes ou inexistantes. Les équipes savent que la documentation est importante, mais elle est toujours reportée quand les délais approchent. Automatiser la génération et la mise à jour de la documentation dans le cadre de votre flux de travail standard garantit que les docs restent à jour sans effort manuel supplémentaire.

Générer des notes de version à partir des demandes de fusion

Complexité : Débutant

Catégorie : Documentation

Invite de la bibliothèque :

Generate release notes for these merged MRs:
[LIST MR URLs or paste titles]

Group by:
1. New features
2. Bug fixes
3. Performance improvements
4. Breaking changes
5. Deprecations

Pourquoi c'est utile : La compilation manuelle des notes de version prend des heures et comporte souvent des erreurs ou des omissions. La génération automatisée garantit que chaque version dispose de notes complètes sans alourdir votre processus de publication.

Mettre à jour la documentation après des modifications du code

Complexité : Débutant

Catégorie : Documentation

Invite de la bibliothèque :

I changed this code:

[PASTE CODE CHANGES]

What documentation needs updating? Check:
1. README files
2. API documentation
3. Architecture diagrams
4. Onboarding guides

Pourquoi c'est utile : La dérive de la documentation survient parce que les équipes oublient quels docs doivent être mis à jour après des modifications du code. Cette invite intègre la maintenance de la documentation dans votre flux de développement, plutôt que d'en faire une tâche séparée perpétuellement reportée.

Comment réduire la complexité de la planification ?

Les grandes fonctionnalités se retrouvent bloquées en phase de planification. Les équipes passent des semaines en réunions pour délimiter le périmètre et identifier les dépendances. La complexité semble insurmontable et il est difficile de savoir par où commencer. L'IA peut décomposer méthodiquement un travail complexe en tâches concrètes et réalisables, avec des dépendances claires et des critères d'acceptation précis — transformant des semaines de planification en une mise en œuvre ciblée.

Décomposer un epic en issues

Complexité : Intermédiaire

Catégorie : Documentation

Agent : Duo Planner

Invite de la bibliothèque :

Break down this epic into implementable issues:

[EPIC DESCRIPTION]

Consider:
1. Technical dependencies
2. Reasonable issue sizes
3. Clear acceptance criteria
4. Logical implementation order

Pourquoi c'est utile : Cette invite transforme une semaine de réunions de planification en 30 minutes de décomposition assistée par l'IA suivie d'une revue d'équipe. Les équipes démarrent l'implémentation plus tôt, avec une direction plus claire.

Comment améliorer la couverture de tests sans alourdir l'effort ?

Les développeurs écrivent du code plus vite, mais si les tests ne suivent pas le rythme, la couverture diminue et les bugs passent au travers. Écrire des tests complets manuellement est chronophage, et les développeurs manquent souvent les cas limites sous pression des délais. Générer des tests automatiquement permet aux développeurs de réviser et d'affiner plutôt que d'écrire depuis zéro, maintenant la qualité sans sacrifier la vélocité.

Générer des tests unitaires

Complexité : Débutant

Catégorie : Tests

Invite de la bibliothèque :

Generate unit tests for this function:

[PASTE FUNCTION]

Include tests for:
1. Happy path
2. Edge cases
3. Error conditions
4. Boundary values
5. Invalid inputs

Pourquoi c'est utile : Écrire des tests manuellement est chronophage, et les développeurs manquent souvent les cas limites. Cette invite génère des suites de tests complètes en quelques secondes, que les développeurs peuvent réviser et ajuster plutôt qu'écrire de zéro.

Identifier les lacunes de couverture de tests

Complexité : Débutant

Catégorie : Tests

Invite de la bibliothèque :

Analyze test coverage for [MODULE/COMPONENT]:

Current coverage: [PERCENTAGE]

Identify:
1. Untested functions/methods
2. Uncovered edge cases
3. Missing error scenario tests
4. Integration points without tests
5. Priority areas to test next

Pourquoi c'est utile : Cette invite révèle les angles morts de votre suite de tests avant qu'ils ne provoquent des incidents en production. Les équipes peuvent améliorer systématiquement la couverture là où cela compte le plus.

Comment réduire le temps moyen de résolution lors du débogage ?

Les incidents en production prennent des heures à diagnostiquer. Les développeurs parcourent des logs et des traces d'appel pendant que les utilisateurs subissent des interruptions de service. Chaque minute de débogage représente une minute de productivité perdue et potentiellement un manque à gagner. L'IA peut accélérer l'analyse des causes profondes en interprétant des messages d'erreur complexes et en proposant des correctifs précis, réduisant le temps de diagnostic de plusieurs heures à quelques minutes.

Déboguer un pipeline en échec

Complexité : Débutant

Catégorie : Débogage

Invite de la bibliothèque :

This pipeline is failing:

Job: [JOB NAME]
Stage: [STAGE]
Error: [PASTE ERROR MESSAGE/LOG]

Help me:
1. Identify the root cause
2. Suggest a fix
3. Explain why it started failing
4. Prevent similar issues

Pourquoi c'est utile : Les échecs de pipeline CI/CD bloquent des équipes entières. Cette invite diagnostique les pannes en quelques secondes au lieu des 15 à 30 minutes que les développeurs consacrent habituellement aux investigations, maintenant ainsi une vélocité de déploiement élevée.

Passer des gains individuels à l'accélération collective

Ces invites illustrent une évolution dans la manière dont les équipes exploitent l'IA pour la livraison logicielle. Plutôt que de se concentrer uniquement sur la productivité individuelle des développeurs, elles s'attaquent aux défis de coordination, de qualité et de partage des connaissances qui contraignent réellement la vélocité des équipes.

La bibliothèque d'invites complète contient plus de 100 invites couvrant toutes les étapes du cycle de vie logiciel : planification, développement, sécurité, tests, déploiement et opérations. Chaque invite est étiquetée par niveau de complexité (Débutant, Intermédiaire, Avancé) et classée par cas d'usage, facilitant la recherche du bon point de départ pour votre équipe.

Commencez par les invites étiquetées « Débutant » qui s'attaquent aux obstacles les plus pressants de votre équipe. À mesure que votre équipe prend confiance, explorez les invites intermédiaires et avancées qui permettent des flux de travail plus sophistiqués. L'objectif n'est pas seulement un développement plus rapide — c'est une livraison logicielle plus rapide, plus sûre et de meilleure qualité, de la planification jusqu'à la mise en production.