Cursor, un agent de codage d'IA, excelle dans la partie ciblée de ce problème. Donnez-lui un test en échec ou un problème bien délimité, et il pourra examiner l'implémentation, expliquer ce qui s'est mal déroulé, proposer un correctif et exécuter les tests sans sortir du workflow de développement. Ce qu'il ne peut toutefois pas déterminer de lui-même, c'est ce que « sûr » signifie dans le cadre d'une migration en plusieurs étapes.

C'est là qu'intervient GitLab, avec GitLab Duo Agent Platform : il orchestre les workflows d'IA dans le reste du cycle de vie logiciel et est conçu pour certifier le travail des agents de codage. En raison de la hiérarchie des tickets avec les epics, le scénario est durable et vérifiable. Le serveur Model Context Protocol (MCP) de GitLab apporte le contexte du cycle de développement logiciel dans Cursor. Le CI/CD, le scan de sécurité, la revue de code, l'analyse d'impact et un test inter-services nous fournissent les preuves nécessaires avant de modifier le comportement en production.

Dans ce tutoriel, nous allons passer en revue trois cas d'utilisation de Cursor et de GitLab :

1. Corriger un test en échec de bout en bout avec Cursor
2. Préparer des contrôles de qualité pour la modernisation de Java 8 vers Java 21
3. Moderniser la gestion des connexions HTTP avec Java 21

La progression est essentielle : commencez à petite échelle, ajoutez le contexte du projet, puis modernisez un périmètre. Cursor avance rapidement à l’intérieur de ce périmètre. Le flow Code Review, le flow Developer, le CI/CD, les approbations des propriétaires du code et l'analyse d'impact maintiennent cette vitesse en toute sécurité. Ce ne sont pas des points de contrôle facultatifs, mais des mécanismes qui garantissent que chaque merge request créée par un agent respecte les mêmes normes que toutes les autres.

Nous utilisons le collecteur de métriques HTTP Java de la plateforme Tanuki IoT pour ces trois cas d'utilisation. Il vérifie les points de terminaison HTTP, enregistre des métriques telles que le statut de réponse et les délais, et envoie les relevés à son backend de métriques Rust. Nous obtenons ainsi un périmètre d'application visible à moderniser et un véritable contrat backend à vérifier. Il y a quelque temps, nous avons développé le backend Rust dans le tutoriel Codex et GitLab, et il s'intègre désormais à l'architecture de production :

flowchart LR
  subgraph sources["Sources de métriques HTTP"]
    direction TB
    health["État des points de terminaison"]
    maintenance["Maintenance des points de terminaison"]
  end

  java["Collecteur de métriques HTTP Java"]
  rust[("Backend de stockage des métriques Rust")]

  java -->|"GET"| health
  java -->|"GET"| maintenance
  java -->|"POST/api/metrics"| rust
  rust -->|"Réponse HTTP"| java

  classDef source fill:#f8fafc,stroke:#64748b,stroke-width:2px,color:#0f172a
  classDef focus fill:#dcfce7,stroke:#16a34a,stroke-width:3px,color:#0f172a
  classDef backend fill:#e0f2fe,stroke:#0284c7,stroke-width:2px,color:#0f172a

  class health,maintenance source
  class java focus
  class rust backend

Prérequis

1. Cursor doit être installé et configuré. Nous utiliserons l'IDE Cursor dans ce tutoriel.
2. Un projet GitLab contenant le code source du collecteur Java, les tickets et les éléments de travail de modernisation. Vous pouvez utiliser le collecteur de métriques HTTP Java de la plateforme Tanuki IoT.
3. Java 8 pour le premier cas d'utilisation et Java 21 pour les travaux de modernisation.
4. Maven, Docker et Docker Compose pour les builds locaux et les tests fonctionnels.
5. Le serveur MCP de GitLab activé sur votre instance GitLab ou votre groupe principal.
6. Le flow GitLab Duo Code Review, le flow Developer et un flow personnalisé pour l'analyse d'impact des changements majeurs activés pour le projet du collecteur Java. Ces flows appliquent des garde-fous au projet pour chaque merge request créée par l'agent.

Préparer le projet GitLab

Si vous souhaitez reproduire ce workflow dans votre propre environnement, commencez par importer et cloner le projet, puis ouvrez-le dans Cursor :

1. Importez le collecteur de métriques HTTP Java de la plateforme Tanuki IoT dans votre environnement GitLab avec tous les tickets ouverts.
2. Clonez le projet dans votre environnement local et accédez-y.
3. Ouvrez le projet dans Cursor.

git clone https://gitlab.com/gitlab-da/demo-environments/tanuki-iot-platform/sensors/java-http-metrics-collector.git
cd java-http-metrics-collector

cursor .

Le projet comprend un fichier AGENTS.md contenant des instructions relatives au dépôt et des commandes Maven. Cursor peut utiliser ces instructions locales pour comprendre l'organisation du projet et la manière dont les modifications doivent être testées.

Corriger un test en échec de bout en bout avec Cursor

Le collecteur permet aux utilisateurs de configurer le code de statut HTTP qu'ils attendent d'un point de terminaison. Toutefois, l'implémentation traite chaque réponse 2xx comme réussie, et les erreurs 503 échouent systématiquement, même lorsqu'elles sont configurées comme prévu.

Le test de bout en bout expose déjà cette incohérence, mais le job CI/CD est autorisé à échouer. Ce qui a transformé un signal utile en bruit de fond accepté.

Reproduire et corriger avec Cursor

Le problème peut être reproduit localement. Ouvrez l'IDE Cursor avec un nouveau chat et commencez par décrire le problème observable directement dans le prompt :

Can you help me fix the end-to-end tests in this project? Please create an analysis first, then fix it, and run the tests again.

Cursor commence par retracer la configuration du point de terminaison dans HttpCollector et le test de bout en bout en échec, puis identifie la cause racine.

Une fois les tests ciblés et la suite de tests Maven complète réussis, créez une branche et une merge request. Le job de bout en bout, auparavant autorisé à échouer, peut devenir obligatoire lorsqu'il est déterministe et qu’il passe avec succès.

Can you create a git branch and merge request?

Réviser et fusionner

La merge request déclenche automatiquement le build et les tests CI/CD, ainsi que le scan de sécurité.

GitLab Duo Code Review passe ensuite en revue la modification ciblée en utilisant les instructions de revue spécifiques au projet Java.

Lorsque la revue identifie un problème concret, nous le traitons avec le flow Developer avant de fusionner. C'est précisément l'objectif : le flow Code Review garantit que chaque merge request créée par un agent répond aux mêmes exigences que n'importe quelle autre merge request, quelle que soit la rapidité avec laquelle Cursor l'a produite. La merge request reste la surface de collaboration et de décision.

Le correctif nous fournit une référence de comportement. Nous avons corrigé un véritable bogue sans le mélanger avec une migration de l'environnement d'exécution, et les tests protègent désormais le contrat de statut attendu pendant les travaux de modernisation qui suivront.

Regardez cette vidéo pour découvrir comment Cursor analyse et corrige les tests de bout en bout attendus :

Préparer les murs qualité pour la modernisation vers Java 21

Le premier correctif a fonctionné avec le seul contexte du dépôt. La prochaine tâche est bien plus ambitieuse : moderniser le collecteur de Java 8 vers Java 21.

Ce projet dispose déjà d'un contexte de planification dans l'epic de modernisation Java : éléments de travail enfants, discussions d'équipe, recherches avec merge requests, historique des pipelines, dépendances et résultats de sécurité. Ces détails ne se trouvent pas dans la copie locale. Plutôt que de tous les copier dans un seul prompt gigantesque, nous pouvons intégrer le contexte de GitLab dans Cursor grâce au MCP.

Configurer le serveur MCP de GitLab dans Cursor

Assurez-vous que le serveur MCP de GitLab est activé sur votre instance ou votre groupe principal. Cursor utilise le transport HTTP pour se connecter directement sans dépendances supplémentaires.

Pour connecter Cursor au serveur MCP de GitLab :

1. Dans Cursor, accédez à Settings > Cursor Settings > Tools & MCP.
2. Sous Installed MCP Servers, sélectionnez New MCP Server.
3. Ajoutez la définition ci-dessous à la clé mcpServers dans le fichier mcp.json ouvert. Pour GitLab.com, remplacez <gitlab.example.com> par gitlab.com. Pour GitLab Self-Managed ou GitLab Dedicated, utilisez l'URL de votre instance GitLab.

{
  "mcpServers": {
    "GitLab": {
      "type": "http",
      "url": "https://<gitlab.example.com>/api/v4/mcp"
    }
  }
}

4. Enregistrez le fichier et attendez que la page d'autorisation OAuth s'ouvre dans votre navigateur. Si elle ne s'ouvre pas, fermez et redémarrez Cursor.
5. Examinez et approuvez la demande d'autorisation dans votre navigateur.
6. Revenez dans Cursor et inspectez les outils affichés.

Vous pouvez maintenant démarrer un nouveau chat et poser une question basée sur les outils MCP disponibles de GitLab.

Lorsque Cursor s'authentifie auprès du MCP de GitLab, il agit avec votre identité GitLab existante. Il ne peut accéder qu'aux projets et ressources auxquels vous avez déjà accès. Le MCP apporte un contexte approuvé dans l'IDE ; il ne contourne pas les autorisations de GitLab.

Préparer l'environnement pour la modernisation vers Java 21

L'epic de modernisation de Java 8 à 21 décompose le plan nécessaire en itérations plus petites, chaque artefact et chaque modification étant testable indépendamment.

La première étape consiste à s'assurer que l'infrastructure CI/CD teste à la fois Java 8 et Java 21 en parallèle. L'augmentation de la couverture de test dès le début de chaque tâche de modernisation est également obligatoire.

Ouvrez l'IDE Cursor et utilisez le prompt suivant pour récupérer le contexte de planification :

Please help me modernize this sensor from Java 8 to 21. We want to start with the base line for CI/CD builds in work item 14, and then also look into test coverage from 21. Start the implementation in a new Git branch called `maint-java-21` so we can continue testing different scenarios.

Après avoir terminé le travail sur le ticket de visibilité du build CI, Cursor peut également utiliser l'outil MCP create_workitem_note pour ajouter un commentaire récapitulatif dans le ticket.

La nouvelle merge request déclenche les pipelines CI/CD, ainsi que le flow Code Review, qui laisse des commentaires sur le guide de style de développement nécessitant une documentation.

Nous pouvons immédiatement traiter le retour dans l'interface GitLab en mentionnant le compte de service du flow Developer.

@duo-developer-<group-name> Can you help address the review feedback?

Ce prompt démarre une nouvelle session en arrière-plan, et nous pouvons nous concentrer sur d'autres tâches pendant ce temps. Nous pouvons également revenir dans l'IDE Cursor et utiliser son chat pour traiter le retour de revue dans la merge request.

Cursor met en œuvre les modifications et ajoute des commentaires dans les fils de discussion de la merge request à l'aide de l'outil MCP create_merge_request_note.

La modification conserve la base de référence Java 8 temporaire et ajoute une validation distincte du build et des tests Java 21. Ce changement rend la compatibilité visible dans le pipeline avant que le code source ne commence à utiliser des API exclusives à Java 21. Une fois ces murs qualité en place, chaque modification ultérieure pilotée par un agent est révisée, testée et traçable. C'est la même norme que nous appliquons à toute autre merge request, et c'est ce qui permet à Cursor d'avancer rapidement en toute sécurité.

Regardez cette vidéo pour découvrir comment Cursor utilise le MCP de GitLab pour préparer les murs qualité et traiter le retour de revue de code :

Moderniser la gestion des connexions HTTP avec Java 21

Le collecteur de métriques HTTP Java utilise actuellement l'API legacy HttpURLConnection de Java 8. Java 21 a modernisé la bibliothèque HTTP avec java.net.http.HttpClient, mais il ne s'agit pas d'un simple renommage mécanique. Les redirections, les en-têtes restreints, la portée des délais d'attente, les corps de réponse, les interruptions et la réutilisation des connexions peuvent tous se comporter différemment. C'est pourquoi l'implémentation est contenue dans un seul élément de travail bien délimité : Remplacer HttpURLConnection par java.net.http.HttpClient.

Ouvrez l'IDE Cursor avec un nouveau chat et demandez à mettre en œuvre les modifications.

Remarque : pour ce cas d'utilisation, nous souhaitons utiliser une configuration Docker Compose locale pour vérifier les modifications. Si vous souhaitez reproduire le comportement, installez Docker et Docker Compose ; sinon, supprimez le deuxième prompt.

We want to continue modernizing the app to Java 21 - use the same maint-java-21 branch, and start implementing issue 16.

Verify the changes locally using the docker compose setup, after making the changes.

Le serveur MCP de GitLab fournit le contexte du ticket, les critères d'acceptation, les dépendances et les discussions associées. Le premier ticket de modernisation du code reste délibérément synchrone et limité. Il remplace HttpURLConnection par un seul HttpClient réutilisable et n'ajoute pas de threads virtuels, ne modifie pas le modèle temporel, et ne corrige pas les dépendances non liées. Ce sont des améliorations précieuses, mais les combiner rendrait les changements de comportement plus difficiles à isoler, à réviser et à annuler.

Mettre en œuvre et vérifier localement

Des tests HTTP locaux ciblés couvrent les méthodes, les en-têtes, les codes de statut attendus et inattendus, les redirections, les délais d'attente, les métadonnées de réponse, les échecs de connexion et les interruptions.

Le test fonctionnel Docker Compose prouve ensuite que les relevés authentifiés arrivent toujours dans le backend rust-metrics-store.

Si les pipelines CI/CD échouent après les modifications, utilisez les outils du serveur MCP de GitLab pour inspecter et corriger directement dans l'IDE Cursor sans changer de contexte.

Dans l'interface GitLab, vous pouvez utiliser le flow Fix CI/CD Pipeline ou demander l'aide de l'agent CI Expert.

Preuves CI/CD et de revue

GitLab CI/CD, GitLab Duo Code Review, l'analyse de sécurité et l'analyse d'impact assistée par l'IA fournissent les preuves finales dans la merge request. La revue humaine reste primordiale, notamment pour les frontières subtiles : toute différence de comportement intentionnelle doit être explicite dans la merge request, et non découverte après le déploiement.

Regardez cette vidéo pour découvrir comment Cursor et GitLab modernisent la bibliothèque HTTP du collecteur vers Java 21 :

Conseils pour Cursor et GitLab

Voici quelques conseils pour utiliser Cursor et GitLab ensemble.

Automatiser l'analyse d'impact pour les changements majeurs de modernisation

Le troisième cas d'utilisation montre le flow Developer effectuant une analyse d'impact des changements majeurs. Vous pouvez transformer ce workflow en un flow personnalisé automatisé qui se déclenche lorsqu'une merge request est prête ou que le pipeline est au vert. Un contexte supplémentaire peut être récupéré depuis GitLab Orbit, qui fournit un graphe de contexte à travers le code, les éléments de travail, les merge requests, les vulnérabilités, et plus encore.

Vous pouvez commencer à inspecter le flow d'exemple dans le catalogue d'IA : MR Impact analysis (Orbit). Merci à ma collègue Fatima Sarah Kalid pour l'inspiration. Les flows personnalisés sont en disponibilité générale depuis GitLab 19.2.

Documenter les directives et les limites pour les agents

AGENTS.md pour Java

Un fichier AGENTS.md aide Cursor et d'autres agents de codage à comprendre l'architecture du projet, les commandes, le style de code, les attentes en matière de tests et les limites. Conservez ces instructions à proximité du code et veillez à ce qu'elles soient suffisamment précises et concrètes pour être vérifiées.

Exemple tiré du fichier AGENTS.md dans le projet de collecteur de métriques HTTP Java :

# Java HTTP Metrics Collector - Agent Instructions

## Overview

The Java HTTP Metrics Collector is a REST API metrics collection sensor for the Tanuki IoT Platform. It monitors HTTP endpoints, collects performance metrics (response time, status codes, content length), and exports them in Prometheus text format. The application runs continuously with configurable collection intervals and supports concurrent endpoint monitoring.

## Code Style and Standards

### Java 8 Compatibility

- Do not modernize Java 8 code to Java 11+ features unless there is a GitLab issue or task specifically requesting modernization
- Target Java 8 for source and compilation: `maven.compiler.source=1.8` and `maven.compiler.target=1.8`
- Use Java 8 compatible patterns (e.g., anonymous inner classes instead of lambdas where appropriate)

### Documentation

- All public classes must have Javadoc describing purpose and usage
- All public methods must have Javadoc with `@param` and `@return` tags
- Include code examples in main class Javadoc

### Class Organization

- **Main entry point**: `HttpMetricsCollector` - orchestrates configuration loading, metric collection, and export
- **Collector**: `HttpCollector` - performs HTTP requests and collects metrics
- **Exporter**: `PrometheusExporter` - exports metrics in Prometheus text format
- **Models**: `CollectorConfig`, `EndpointConfig`, `HttpMetric` - data transfer objects

### Dependency Management

- Always use Maven for dependency management
- Use property-based version management for dependencies (e.g., `${jackson.version}`)
- Keep dependencies up-to-date in `pom.xml`

### Error Handling

- Use try-catch blocks with proper resource management (try-with-resources where applicable)
- Log errors using SLF4J Logger
- Gracefully handle configuration loading failures
- Implement proper shutdown hooks for resource cleanup

### Concurrency

- Use `ExecutorService` for concurrent HTTP requests
- Thread pool size is limited to the minimum of endpoint count and 10
- Properly shutdown executor service with timeout handling
- Use `Future` objects to collect results from concurrent tasks

Instructions de revue de code pour Java

Le flow GitLab Duo Code Review aide à maintenir les guides de style et les limites. Il s'attend à des instructions spécifiques dans le fichier .gitlab/duo/mr-review-instructions.yaml, par exemple pour Java :

# Custom instructions for GitLab Duo Code Review

instructions:
  # General guidelines

  - name: Code Review
    instructions: |
      1. Focus on correctness and performance
      2. Ensure code comments and documentation are clear and concise
      3. Be respectful and constructive in comments

  - name: CI/CD Configuration
    fileFilters:
      - ".gitlab-ci.yml"
    instructions: |
      1. Do not use YAML anchors
      2. Always use rules in jobs, avoid using `only`

  # Java style guide

  - name: Java Style Guide
    fileFilters:
      - "**/*.java"
    instructions: |
      1. Do not modernize Java 8 code to Java 11+ features, unless there is a GitLab issue or task specifically requesting modernization
      2. All public classes must have Javadoc describing purpose and usage
      3. All public methods must have Javadoc with @param and @return tags
      4. Include code examples in main class Javadoc
      5. All public methods must have at least one test case
      6. Use httpbun.com for test endpoints (status codes, delays, JSON responses)

Au cours du processus de modernisation du code, la première directive relative à l'application de Java 8 devra être mise à jour.

Transformer un workflow éprouvé en compétence agentique

Lorsqu'un workflow spécialisé devient répétable, capturez-le dans une compétence agentique. Les compétences sont chargées à la demande et ne remplissent pas la fenêtre de contexte par défaut.

Commencez avec un CI/CD fonctionnel, des tests et des décisions révisées afin que la compétence agentique reflète une pratique éprouvée plutôt qu'un plan non testé. Le ticket 24 dans l'epic de modernisation capture l'approche dans une compétence agentique ciblée de modernisation Java 21 et les versions ultérieures. Cette approche apporte une valeur au-delà de la merge request actuelle : les futures sessions d'agents pourront réutiliser les mêmes limites de sécurité au lieu de les reconstruire à partir de discussions antérieures.

Essayez cet exemple d'implémentation de compétence, inspiré de la compétence de maintenance Maven pour Java 8 existante :

---
name: java21-modernization
description: >-
  Guide incremental Java 8 to Java 21+ modernization for the HTTP metrics
  collector. Use when a GitLab work item asks for Java 21 CI visibility,
  runtime/image upgrades, HttpClient migration, dependency or source API
  modernization, or review of maint-java-21 style merge requests. Do not use
  for routine Java 8 maintenance; prefer java8-maven-maintenance instead.
compatibility: Requires Maven, Docker Compose, and access to the owning GitLab work item.
---

# Java 21 Modernization

## Overview

Modernize in small, reviewable steps. The owning work item is authoritative.
Preserve collector → Rust metrics-store behavior unless the issue says otherwise.

Companion skill: `skills/java8-maven-maintenance/` for the Java 8 default path.

## Before editing

1. Read the owning issue/epic, `AGENTS.md`, `.gitlab-ci.yml`, `pom.xml`,
   `Dockerfile`, and affected tests.
2. Record the current baseline:
   - `maven.compiler.source` / `target`
   - default CI image vs any `*:java-21` jobs
   - container base image
   - observable CLI/Compose behavior
3. Classify the change into **one** lane:
   - CI visibility only
   - runtime / image switch
   - source / API modernization
   - dependency upgrade
   - tests / contract checks

Do not combine lanes in one MR unless the work item explicitly requires it.

## Workflow

Copy and track:

```text
Modernization progress:
- [ ] Baseline recorded
- [ ] Scoped to owning work item
- [ ] Target-JDK CI evidence available before JDK-only APIs
- [ ] Java 8 lane preserved until exit criteria say otherwise
- [ ] Unit / IT / Compose checks run
- [ ] MR documents risks, rollback, human decisions
```

## Guardrails

- Do not remove Java 8 compatibility unless the work item authorizes it.
- Do not introduce Java 21-only APIs before target-JDK CI evidence exists.
- Do not mix runtime upgrades with unrelated refactors.
- Do not claim performance wins without measurements.
- Preserve the Java → Rust API and authentication contract.
- Stop for a human decision when support policy, rollback, data format, or downstream compatibility is unclear.

## Validation

```bash
mvn -Dmaven.repo.local=.m2/repository test
mvn -Dmaven.repo.local=.m2/repository clean package
```

If Compose or container files change:

```bash
docker compose config --quiet
TANUKI_INGESTION_TOKEN=replace-me docker compose up -d --build
# confirm metric_sample logs and authenticated ingest still work
docker compose down -v
```

## Completion report

In the MR description, include:

1. Baseline before the change
2. Lane changed (CI / runtime / source / deps / tests)
3. Evidence run (commands + CI jobs)
4. Remaining risks and rollback
5. Human decisions still open

## Out of scope

- Broad "modernize everything to Java 21" prompts
- HTTP endpoint semantics unrelated to the JDK migration
  (use `skills/http-endpoint-collector-behavior/`)
- Security triage unrelated to the migration slice
  (use `skills/security-triage-java-sensor/`)

Résumé

Les trois cas d'utilisation de ce tutoriel s'appuient les uns sur les autres. Cursor a corrigé un échec de test de bout en bout accepté en utilisant uniquement le contexte du dépôt. Ensuite, le serveur MCP de GitLab a apporté le plan de modernisation, afin que Cursor puisse mettre en place des murs qualité et boucler la boucle sur le retour de revue de GitLab Duo directement depuis l'IDE. Enfin, Cursor a effectué un changement Java 21 bien délimité et a remplacé HttpURLConnection par un HttpClient réutilisable, étayé par des tests ciblés, des exécutions d'ingestion inter-services, un pipeline, des scans de sécurité, une nomenclature logicielle, des preuves de revue et une analyse d'impact.

La modernisation d'un code source Java 8 legacy n'est pas plus sûre simplement parce qu'un agent écrit le code. Elle devient plus sûre parce que chaque modification est délimitée, révisée et testée dans Java 8 et Java 21, et traçable jusqu'à un élément de travail avec les décisions et les preuves qui le sous-tendent. Cursor gère l'implémentation. GitLab gère les preuves. Ensemble, ils font de la migration quelque chose en quoi une équipe peut avoir confiance.

Si vous souhaitez essayer ce workflow, commencez par un test qui expose un échec accepté dans une application legacy. Rendez ce test fiable, saisissez le plan de modernisation global dans GitLab et choisissez un périmètre que vous pouvez modifier et prouver indépendamment. L'agent aura ainsi une tâche ciblée, et l'équipe aura des preuves qu'elle pourra réviser.

Si vous n'utilisez pas encore GitLab Duo Agent Platform, commencez un essai gratuit.

Si vous utilisez déjà l'édition Gratuite de GitLab, vous pouvez vous inscrire à GitLab Duo Agent Platform en suivant quelques étapes simples.

Et si vous êtes déjà abonné à GitLab Premium ou GitLab Ultimate, lancez-vous simplement en activant GitLab Duo Agent Platform et en utilisant les GitLab Credits inclus dans votre abonnement.

En résumé : c'est possible. Les agents d'IA fonctionnent et peuvent révéler les faiblesses de vos méthodes de travail habituelles. Néanmoins, l'équipe, le workflow et l'observabilité ont joué un rôle plus important que les agents eux-mêmes. Voici comment nous avons structuré ce projet à l'aide de GitLab, de GitLab Duo Agent Platform et d'autres outils : découvrez ce qui a fonctionné, comment nous avons structuré notre workflow et où celui-ci a échoué, et comment vous pouvez reproduire notre démarche.

Le contexte

GitLab utilise depuis des années deux systèmes de limitation de débit en production : Gitlab::ApplicationRateLimiter au niveau de l'application avec 121 clés, et un système distinct au niveau Rack. Nous avions pour objectif de les unifier au sein d'une seule implémentation dans labkit-ruby afin d'obtenir un résultat observable, testable et exploité de la même manière partout. Chaque requête adressée au monolithe passe par ce mécanisme, ses modes de défaillance doivent donc rester visibles et réversibles.

L'équipe comptait trois membres de GitLab et plusieurs agents d'IA. Max Woolf, Staff Backend Engineer au sein de l'équipe API Platform, s'est chargé du volet monolithe et a mené la plupart des déploiements. Bob Van Landuyt, qui travaille sur l'évolutivité, s'est occupé de la gemme et a défini l'architecture. Je me suis chargé du périmètre du projet et écrit une partie du code labkit initial. D'autres ingénieurs sont intervenus ponctuellement pour prendre connaissance du contexte et contribuer au code et aux revues.

Les agents ont analysé le contexte, rédigé les spécifications, mis en œuvre des modifications bien délimitées, écrit les tests et procédé à une première revue des merge requests. GitLab Duo Code Review a permis de maintenir un haut niveau de qualité du code sur les merge requests. Les équipes, quant à elles, étaient toujours responsables de la portée, de l'architecture, du déploiement et de la revue finale.

Nous avons suivi un cycle rigoureux : lecture de l'epic, rédaction de la spécification, révision contradictoire de la spécification, mise en œuvre uniquement après résolution des blocages, vérification à l'aide de preuves explicites, révision contradictoire de la merge request, transfert vers une revue humaine, puis merge. La revue contradictoire était limitée à deux cycles de résolution avant qu'un humain ne doive intervenir. Sur l'ensemble du projet, nous avons livré 14 spécifications numérotées et un peu plus de 30 merge requests dans labkit-ruby. Dans la pratique, la boucle était plus ou moins stricte selon la personne. Bob effectuait souvent plusieurs cycles de spécification et de revue en privé avant de livrer un artefact partagé.

Cette boucle peut sembler complexe, mais sur du code legacy, nous pouvons nous y fier, et un agent peut l'exécuter correctement.

Ce qui a fonctionné

La cohorte 1 constituait le test à fort enjeu : cinq clés à fort trafic, dont pipelines_create, notes_create et user_sign_in. Nous l'avons déployée à 1 %, puis 10 %, puis 50 % le 4 mai 2026, et à 100 % le 5 mai 2026. Le commentaire de Bob ce jour-là résume à lui seul tout le modèle opérationnel :

« Tous les déploiements sont terminés. Pour l'instant, toutes les limites de débit issues d'applimiter et de l'implémentation labkit concordent. Mais je soupçonne que c'est parce qu'il n'y a pas beaucoup de trafic à cet endroit. Je vais essayer de générer un trafic qui dépasse la limite. »

Voilà à quoi ressemble un bon déploiement, et c'est le genre de jugement qu'aucun agent ne devrait porter à votre place. Le fait que le nouveau système fonctionne comme l'ancien n'est pas en soi un succès : cela peut simplement signifier que rien ne s'est déclenché.

La cohorte 2 a regroupé les 95 sites d'appel suivants, 83 dans le monolithe et 12 dans GitLab Enterprise Edition (EE), sous une seule paire de feature flags. Sans cette consolidation, le déploiement aurait nécessité environ 95 activations de feature flags individuelles et près de 190 modifications YAML. Les agents excellent dans ce type de déploiement mécanique à grande échelle dans un code source. Les équipes humaines, en revanche, beaucoup moins.

Là où la boucle a échoué

Le premier incident a concerné le mode « shadow ». La cohorte 2 fonctionnait en mode « shadow » depuis plusieurs jours, conformément à l'ancienne implémentation. Le passage du mode observation au mode application aurait dû se dérouler sans encombre. Un petit incident s'est pourtant produit.

Le nouvel adaptateur a perdu un identifiant sans déclencher d'alerte sur un chemin de code non authentifié. Trois valeurs de type String étaient compressées dans deux emplacements primitifs, et la mauvaise valeur a écrasé l'identifiant. Une infime proportion d'utilisateurs a rencontré une erreur générique pendant une courte période.

La comparaison en mode « shadow » avait en réalité signalé une divergence sur cette clé. Nous n'avions tout simplement pas encore défini notre système de labels pour distinguer une collision structurelle d'une divergence normale, si bien que le signal est resté dans le tableau de bord pendant que nous montions en charge jusqu'à 100 %.

Nous avons immédiatement désactivé le feature flag d'application. Bob a résumé le problème structurel en une phrase :

« Je pense que nous devrions améliorer ce scénario une fois que nous aurons nettoyé ce désordre, et n'appeler ApplicationLimiter qu'avec des caractéristiques nommées, sans aucune portée sous forme de tableau. »

Le correctif immédiat a été livré deux jours plus tard. Le nettoyage structurel est au programme de la prochaine itération.

L'incident a pourtant traversé chaque étape du cycle : spécification, revue contradictoire, mise en œuvre, GitLab Duo Code Review, déploiement progressif. La boucle l'a à la fois détecté et laissé passer. La leçon à tirer de cette situation n'est pas que les agents sont dangereux, mais que nous disposons d'une observabilité, qui n'est malheureusement pas capable de distinguer les modes de défaillance qui comptent vraiment.

Le 15 mai, Max a réalisé un audit sur la branche principale, m'a contacté sur Slack, et a ouvert la cohorte 6 :

« J'ai ajouté une cohorte 6 à la migration avec des éléments épars qui étaient passés entre les mailles du filet. »

Nous avions prévu cinq cohortes. Il nous en a fallu six. Le diagnostic est tombé quelques jours plus tard : Claude avait oublié une poignée de limites de débit propres à GitLab EE : notification_emails, quelques entrées de registre GitLab EE, trois clés webhook, trois clés partner_* de moins d'une seconde, et quelques lignes d'adaptateur orphelines. 17 clés sur 121 avaient échappé aux cohortes précédentes. Chaque clé avait une raison de ne pas s'intégrer proprement dans les cohortes. Aucune ne devait pourtant être invisible.

Nous n'avions demandé ni aux agents, ni à nous-mêmes, de tenir un décompte continu par rapport à l'inventaire complet des clés.

Autre point à mentionner : Redis. Le service redis-cluster-ratelimiting fonctionne comme un cluster à 4 shards. L'estimation initiale de Bob était honnête : « Il y a de la marge, mais pas assez pour doubler entièrement l'utilisation. »

Début mai, la contrainte déjà rencontrée par le passé est réapparue, comme le mentionne Bob :

« Le goulot d'étranglement que nous avions déjà rencontré, qui n'était pas nouveau pour ce projet, en est bel et bien un. Cela signifie que nous devons faire évoluer l'infrastructure pour le contourner. »

Nous avons augmenté le paramètre maxclients par paliers et nous sommes arrêtés à 75 000 connexions au lieu de viser 100 000, une fois qu'il est devenu évident que davantage de connexions ferait basculer le CPU des nœuds primaires en saturation. Un seul nœud primaire par shard, un seul cœur pour l'exécution des commandes. Aucun levier vertical à actionner.

Ce que les agents ont réellement changé

Les agents ont déplacé le goulot d'étranglement. Avec des agents qui rédigent les spécifications et implémentent le code au sein d'une boucle serrée, la génération de code a cessé d'être le maillon faible. La capacité de revue, l’évaluation du déploiement et l'attention des opérateurs sont devenus les points de friction. C'est un bien meilleur problème à avoir, mais il continue aujourd'hui de mobiliser des ressources humaines.

L'expérience n'a pas non plus toujours été agréable. En cours de projet, Max a écrit :

« Résultat mitigé, je me suis retrouvé à tourner en rond avec un agent. Je me suis dit que j'aurais fait ça plus vite moi-même, ce qui était agaçant. »

Quelques semaines plus tôt, il avait qualifié le projet de « l'une des courbes d'apprentissage les plus exigeantes chez GitLab ». Travailler avec des agents est une compétence à part entière, et le prix à payer pour l'acquérir se traduit par des jours pendant lesquels on aurait pu progresser davantage en travaillant seul.

L'autre évolution a porté sur l'honnêteté quant à la définition de « terminé ». La remarque de Bob à la fin de la cohorte 1 (« le feature flag par limite de débit est excessif, nous ne devrions pas procéder ainsi pour les prochaines migrations ») illustre bien ce type de jugement qu'aucun agent ne peut porter à votre place. Ils génèreront volontiers 95 feature flags si vous le leur demandez. Le jugement humain consiste justement à décider de ne pas le faire.

Où nous en sommes aujourd'hui

Mi-juin, les six cohortes étaient toutes à 100 %. Les 121 clés d'ApplicationRateLimiter passent désormais par le nouveau framework, un audit a confirmé que le chemin d’accès legacy est pratiquement réduit à néant, et nous avons ajouté un garde-fou pour qu'aucune future limite de débit ne puisse le contourner silencieusement.

La migration au niveau applicatif est donc terminée. RackAttack est la prochaine étape. Il s'agit de la couche à plus fort volume, avec environ 4 milliards de requêtes par jour. Son intergiciel (middleware) d'observation puis d'application est en cours de développement ; la première merge request est approuvée et en attente de merge.

Si vous souhaitez reproduire cette démarche, vous pouvez utiliser GitLab Duo Agent Platform pour vous aider à rédiger vos spécifications, GitLab Duo Developer pour mettre en œuvre vos tickets et GitLab Duo Code Review pour vous aider à fusionner vos merge requests. Mais ce n’est que la partie facile. Demandez-vous plutôt si vous avez un Bob dans votre entreprise : quelqu'un qui cherchera délibérément à faire échouer le nouveau système à 1 % avant de le laisser tourner à 50 %. Demandez-vous également si vous avez un Max : quelqu'un qui effectuera un audit alors que tout le monde pense que la migration est terminée. Le workflow est essentiel, mais les personnes qui composent vos équipes le sont encore plus. Si vous souhaitez tester cette approche sur votre propre code legacy, lancez-vous dès aujourd'hui.

Observez le flow s'activer, acheminer et attribuer des tâches en temps réel, et imaginez comment une automatisation continue et sans intervention humaine pourrait bénéficier à vos propres projets.

Le problème : l'attribution manuelle ne passe pas à l'échelle

Attribuer des éléments de travail manuellement parmi plusieurs projets est plus complexe qu'il n'y paraît. Il ne s'agit pas d'une décision unique, mais de dizaines de décisions à prendre chaque jour. Pour chaque nouveau ticket créé, quelqu'un doit interrompre ses tâches, vérifier la capacité de l'équipe, équilibrer les charges de travail en cours avec les nouvelles tâches entrantes, puis décider à qui confier cet élément. En tenant compte des réunions, des pauses ou des congés, l'ensemble du processus peut s'allonger encore davantage. Si cette approche fonctionne à petite échelle, elle pose rapidement problème à mesure que le volume augmente et entraîne des retards dans le classement des priorités, une répartition inégale du travail et des responsables d'équipe qui consacrent leur temps à l'attribution des tâches plutôt qu'à des activités à plus forte valeur ajoutée.

Jusqu'à récemment, cette friction était inhérente au fonctionnement des flows. Chaque flow de GitLab Duo nécessitait une action humaine dans l'interface utilisateur (par exemple, une mention, une attribution ou un événement d'attribution de relecteur) pour être activé. Il n'était pas possible de piloter les flows par programmation ni de les déclencher dès qu'un événement se produisait sans qu'une personne actionne manuellement le déclencheur. Ainsi, même un flow d'attribution bien conçu devait toujours attendre qu'une personne le lance.

Comment le déclencheur « Work item created » résout ce problème

Le déclencheur « Work item created » comble cette lacune. Il se déclenche automatiquement dès qu'un nouvel élément de travail est créé dans un projet, sans aucun transfert manuel. Au lieu qu'une personne remarque le ticket, évalue la charge de travail de l'équipe et l'attribue, un flow s'active de lui-même et effectue ces étapes à sa place. Grâce aux déclencheurs, les flows s'exécutent en continu et en arrière-plan dès que les conditions définies par votre organisation sont remplies, pendant que vos équipes de développement restent concentrées sur les tâches qui requièrent véritablement leur jugement.

Valeur et avantages

Le déclencheur « Work item created » présente les avantages suivants :

Classement instantané et sans intervention
L'attribution s'effectue dès la création d'un élément de travail : vous n'avez plus besoin d'attendre qu'une personne s'en charge.

Passage à l'échelle quel que soit le volume
Qu'il s'agisse d'un seul ticket ou de centaines, le déclencheur les traite tous en quelques secondes sans alourdir la charge de travail de quiconque.

Attribution plus intelligente et équilibrée
Le flow peut évaluer la charge de travail actuelle et la disponibilité de chaque membre de l'équipe avant d'attribuer un élément. Il s'agit là du même raisonnement qu'une personne appliquerait, mais de manière systématique.

Fin des tâches répétitives pour votre équipe
Fini le tri manuel des éléments de travail ouverts pour déterminer qui peut s'en charger : un agent prend la décision en fonction des mêmes informations que vous utiliseriez.

L'attribution automatique en action : tutoriel pas à pas

Pour vous donner un exemple concret, parcourons un scénario réel à l'aide d'un projet appelé Intra-account-transfers.

1. La configuration du déclencheur

Nous avons créé un flow nommé « Work item assigner » et l'avons configuré pour s'exécuter chaque fois qu'un élément de travail est créé dans ce projet.

2. La structure du flow

Le flow « Work item assigner » utilise deux agents, chacun doté d'un prompt détaillé décrivant le processus à suivre et les outils à utiliser. Le premier agent utilise GitLab Orbit pour déterminer la charge de travail actuelle de chaque personne au sein de l'organisation. GitLab Orbit est le graphe de contexte du cycle de vie pour l'ingénierie logicielle, qui accélère les capacités et renforce la précision des agents d'IA de GitLab Duo Agent Platform.

Le second agent identifie la personne ayant le moins d'éléments de travail ouverts et lui attribue le nouvel élément.

La logique d'attribution étant intégrée au flow, le déclencheur suffit à lui seul à mettre l'ensemble du processus en marche.

3. Le déclencheur en action

3.1. Nous créons un nouvel élément de travail.

3.2. Dès que le ticket est créé, le déclencheur s'active et le flow « Work item assigner » démarre automatiquement. Depuis le journal d'activité du flow, vous pouvez suivre sa progression étape par étape : le premier agent récupère les informations du projet et utilise les outils de GitLab Orbit pour comptabiliser les éléments de travail ouverts de chaque utilisateur au sein du groupe principal.

Le second agent identifie ensuite le membre de l'équipe ayant le moins de tâches ouvertes (dans cette démo, il s'agit de William), et procède à l'attribution.

4. Vérification de l'attribution à la personne avec le moins de tâches

Un rapide retour sur le ticket le confirme : le nouvel élément de travail a bien été attribué automatiquement à William.

5. Un avantage de bout en bout

Ce scénario illustre clairement le changement de paradigme : au lieu qu'une personne classe les éléments de travail ouverts pour déterminer les personnes qui peuvent s'en charger et attribue ensuite le ticket manuellement, le flow personnalisé de GitLab Duo Agent Platform, lancé par le déclencheur « Work item created », accomplit l'ensemble de ces opérations en quelques secondes. Il libère l'équipe d'une décision de routine qu'un agent peut prendre avec exactement les mêmes informations qu'un être humain utiliserait, permettant ainsi aux équipes de concentrer leur attention là où elle est vraiment utile.

6. Pour aller plus loin

Voici quelques améliorations potentielles à apporter à ce flow personnalisé :

• Ajouter une connectivité Model Context Protocol (MCP) à votre système RH (ou de gestion des congés) afin que l'agent puisse prendre en compte les dates de congés lors de l'attribution d'un élément de travail.
• Ajouter une connectivité MCP aux calendriers des membres de vos équipes afin que l'agent puisse tenir compte de leur disponibilité lors de l'attribution d'un élément de travail.

Premiers pas

L'attribution des nouveaux éléments de travail à grande échelle a toujours représenté une charge silencieuse : il s'agit de dizaines de petites décisions par jour, chacune nécessitant de vérifier les charges de travail et les disponibilités avant d'attribuer un ticket. Ce processus ne suit pas le rythme à mesure que le volume augmente. Le déclencheur « Work item created » dans GitLab Duo Agent Platform supprime ce goulot d'étranglement en activant un flow dès la création d'un élément de travail, sans transfert manuel. Comme le montre le tutoriel pas à pas ci-dessus, un flow à deux agents alimenté par GitLab Orbit peut consulter la charge de travail réelle de l'équipe et attribuer chaque nouvel élément à la personne la mieux placée pour le prendre en charge, le tout en quelques secondes. Le résultat : un classement plus rapide, des charges de travail mieux équilibrées et une équipe libre de se concentrer sur les tâches qui nécessitent véritablement un jugement humain.

Commencez un essai gratuit de GitLab Duo Agent Platform dès aujourd'hui.

La merge request ne contient pas de lien vers le ticket qu'elle était censée corriger. Le pipeline CI/CD échoue car l'agent ignorait l'existence d'une règle de linter ajoutée récemment. Un scan de sécurité signale une dépendance que l'agent a intégrée sans vérifier la liste des dépendances approuvées du projet.

Il s’agit là de défaillances liées au contexte, qui déterminent si le codage agentique accélère la livraison ou ralentit le travail des équipes. Mais lorsque les équipes de développement utilisent des agents de codage avec GitLab, ceux-ci s'appuient sur les tickets, les pipelines et les politiques de sécurité déjà présents dans la plateforme afin de détecter les problèmes et y remédier dans le workflow de développement.

Cet article présente les changements qui interviennent lorsque vous fournissez à un agent de codage un contexte de cycle de vie de plus en plus riche, allant d'une visibilité limitée à un dépôt à une visibilité complète sur la plateforme, en s'appuyant sur deux tutoriels GitLab. Vous découvrirez comment le contexte de la plateforme améliore la qualité du code, les évaluations de sécurité et les cycles de revue, et ce que les équipes plateforme peuvent faire dès aujourd'hui pour combler cet écart.

Mise en pratique du contexte

Les tutoriels GitLab montrent ce qui se passe lorsque vous fournissez à un agent de codage externe un contexte de plateforme complet de manière progressive. Le premier tutoriel présente trois workflows avec Claude Code : la correction d'un crash de capteur C++, l’enrichissement d'une session avec le serveur Model Context Protocol (MCP) de GitLab et l’utilisation de Claude Code comme agent externe dans une merge request pour traiter les retours de revue. Le second tutoriel suit la même progression avec Codex et GitLab, en corrigeant cette fois-ci un bogue de filtrage WebSocket en Rust dans ces trois scénarios.

Scénario 1 : l'agent ne voit que le dépôt
Vous dirigez l'agent vers le code source et décrivez le problème dans un prompt. L'agent lit les fichiers, propose un correctif et lance le build. Le correctif fonctionne, mais il repose uniquement sur ce que l'agent déduit des fichiers locaux et de votre prompt. Il ne comprend pas le contexte de votre organisation : les critères d'acceptation du ticket, les exigences non fonctionnelles, ni les normes de revue définies dans la configuration CI de votre projet. Le code se compile, mais ne correspond pas forcément aux besoins de votre équipe.

Scénario 2 : l'agent voit le dépôt et le ticket GitLab
Connectez le serveur MCP de GitLab pour que l'agent puisse récupérer le ticket avant d'écrire la moindre ligne de code. Il lit alors les exigences fonctionnelles, les notes d'implémentation, les labels et les jalons. Dans le tutoriel Codex et GitLab, cela signifie que l'agent ajoute Closes #32 à la description de la merge request, car il comprend la relation entre la modification du code et le ticket. Dans le tutoriel Claude Code, l'agent utilise get_issue pour récupérer le rapport de bogue, puis create_merge_request pour créer la merge request avec les bonnes références. Cette fois, le correctif correspond à ce que l'équipe avait planifié.

Scénario 3 : l'agent intervient dans la merge request
Une fois la merge request créée, le flow Code Review de GitLab s'exécute automatiquement et partage ses retours. Dans les deux tutoriels, l'agent de codage est invoqué en tant qu'agent externe au sein de la merge request pour traiter ces retours. Il ajoute les tests manquants, met à jour les commentaires de documentation et corrige les lacunes de validation détectées lors de la revue. L'agent effectue un commit directement sur la branche de la merge request, les pipelines CI/CD s'exécutent automatiquement sur le nouveau commit, et un relecteur humain peut inspecter le résultat sans changer d'outil.

Dans ce scénario, les deux tutoriels démontrent une réduction du nombre de cycles de revue et un délai réduit avant le merge.

Importance du codage agentique et de la visibilité sur la plateforme

Si vous dirigez une équipe plateforme, vous décidez de la manière dont le développement assisté par l'IA fonctionne au sein de votre organisation. Vous définissez quels agents sont autorisés, quels outils ils peuvent utiliser, comment leurs données de sortie sont vérifiées et à quel moment du processus les décisions humaines interviennent.

L'agent a besoin de contexte pour produire des modifications auxquelles votre organisation peut se fier, et ce contexte réside dans votre plateforme DevSecOps. Votre outil de suivi des tickets répertorie les exigences. La configuration CI/CD définit le niveau de qualité attendu. Les instructions de revue de code codifient le style et les normes de l'équipe. Les scanners de sécurité appliquent les politiques en matière de vulnérabilités. Enfin, c'est dans la merge request que tout converge : l'étape où s'effectue le contrôle humain.

Un agent intégrant le contexte de la plateforme suit le même workflow que celui utilisé par les équipes de développement, avec les mêmes garde-fous. La différence réside dans les cycles de revue, les taux de réussite des pipelines et le délai avant le merge.

Un agent basé sur un IDE ou un terminal, aussi performant soit-il, ne voit que les fichiers qu'on lui fournit. La plateforme, elle, accède à l'ensemble du cycle de vie du ticket, du pipeline et de la politique de sécurité jusqu'à la cible de déploiement et aux règles d'approbation. Cet écart de visibilité explique pourquoi la plateforme de votre organisation, et non l'agent, détermine ce qui est livré en toute sécurité.

Production de code accélérée par les agents : l'impact sur la sécurité

Dans tous les tutoriels, les pipelines CI/CD et la revue de code s'exécutent automatiquement sur chaque merge request créée par l'agent de codage. Les scans de sécurité font partie des pipelines, même si les tutoriels se concentrent sur la qualité du code plutôt que sur les résultats de sécurité. Pour les équipes plateforme, le contexte devient encore plus crucial lorsque la sécurité entre en jeu.

Les agents de codage produisent davantage de code, plus rapidement. Plus de code signifie plus de vulnérabilités introduites, plus de problèmes signalés par les scanners et plus de merge requests de correction générées.

• Avant l'arrivée des agents de codage dans le workflow, le goulot d'étranglement dans la gestion des vulnérabilités se situait du côté de la sécurité applicative : scan, hiérarchisation des résultats, transmission des plus importants aux équipes de développement, puis attente d'un correctif.
• Désormais, grâce aux agents qui accélèrent la production de code et la remédiation, le goulot d'étranglement se déplace. Le workflow passe de la question « quelle vulnérabilité corriger en premier » à « quelle merge request de correctif générée par l'IA doit être revue et approuvée par un humain en premier ».

Cette décision nécessite des informations contextuelles dont l'agent de codage ne dispose pas : le code du projet dans son ensemble, le flux de données complet, la cible de déploiement et les politiques de sécurité applicables au sein de votre organisation.

• Avec un contexte, la priorisation s'affine : un agent qui s’appuie sur le code environnant, le flux de données et les politiques applicables peut classer les résultats en fonction de l'exposition réelle dans votre environnement, plutôt que selon des scores de gravité génériques et mettre en évidence les éléments réellement importants avant que les relecteurs n'y consacrent du temps.

Tout comme l'agent de codage du second scénario produisait un meilleur code lorsqu'il pouvait lire le ticket GitLab, la couche de sécurité produit de meilleures évaluations lorsqu'elle peut lire le contexte complet de l'application plutôt qu'un seul fichier.

La couche de sécurité de GitLab analyse les résultats en tenant compte du contexte complet du projet, filtre les faux positifs détectés et signale les vulnérabilités confirmées. Lorsqu'une vulnérabilité est confirmée, la résolution agentique des vulnérabilités SAST lit le code vulnérable et son contexte environnant à partir du dépôt, puis crée automatiquement une merge request avec un correctif proposé. Le pipeline s'exécute pour valider le correctif. Un relecteur humain le vérifie et prend la décision finale de fusionner la merge request. L'agent se charge de la remédiation ; et le modèle de gouvernance reste intact.

Les contrôles qualité CI/CD, les instructions de revue de code et les scans de sécurité opèrent tous dans la merge request, là où les agents de codage effectuent également leur travail. Plus ces contrôles sont efficaces au moment de la création du code, moins les vulnérabilités atteignent la production.

Instructions personnalisées avec AGENTS.md

Les deux tutoriels s'appuient sur les fichiers AGENTS.md présents dans le dépôt. Il s'agit d'instructions personnalisées destinées aux agents, qui portent sur la structure du projet, les commandes à exécuter et les exigences en matière de qualité du code, y compris ce qu'il ne faut pas modifier.

Dans le tutoriel Codex et GitLab, le fichier AGENTS.md définissait tout, de l'édition Rust au modèle de concurrence asynchrone en passant par la politique d'épinglage des images CI. L’agent n’avait pas besoin que le contexte soit répété dans le prompt. Il lisait le fichier et suivait les règles.

Cet investissement ponctuel porte ses fruits à chaque interaction avec l’agent, que celui-ci s'exécute en local dans le terminal d'un développeur, qu'il soit connecté via MCP ou qu'il fonctionne en tant qu'agent externe dans une merge request. Standardiser le fichier AGENTS.md d’un projet à l’autre améliore la qualité des résultats fournis par les agents, car chaque session d'agent, qu’elle soit locale ou distante, lit les mêmes règles.

Limites de la fenêtre de contexte

Les grands modèles de langage disposent de fenêtres de contexte déterminées, et des recherches ont montré que les performances des modèles se dégradent lorsque l'utilisation du contexte dépasse 30 à 40 %. Plus une session contient d'outils, de fichiers et d'instructions, moins le raisonnement de l’agent est fiable.

Votre organisation souhaite fournir à l'agent un contexte complet sur le cycle de vie : ticket, instructions de revue, historique des pipelines et politique de sécurité. Mais vous souhaitez également que ce contexte soit structuré, pertinent et transmis efficacement.

Au lieu que chaque session d'agent doive reconstituer le contexte en lisant des fichiers et en effectuant des appels API inutiles (ce qui dilue la fenêtre de contexte et consomme des jetons), une plateforme capable de comprendre les relations entre le code, les tickets, les pipelines et les déploiements peut fournir le bon contexte au bon moment. GitLab capture bon nombre de ces relations tout au long du cycle de vie afin de transmettre le contexte plus efficacement. Lorsque la plateforme sait à quel ticket une merge request se rapporte, quels services sont impactés par une modification du code et quels pipelines valident le résultat, elle peut transmettre ces informations sous forme de contexte structuré plutôt que de les reconstituer à partir de fragments.

L'efficacité des workflows de développement assistés par l'IA de votre organisation dépend de la capacité de votre plateforme à fournir un contexte structuré, et non de la taille de la fenêtre de contexte de votre modèle.

Un cycle de revue raccourci grâce aux agents

Lorsqu'un agent de codage traite les retours de revue d'une merge request, il agit sur la revue. L'agent lit les commentaires, apporte les modifications demandées, effectue un commit et laisse le CI/CD valider le résultat. Le relecteur humain valide toujours le résultat, en l’approuvant ou en demandant des modifications supplémentaires et prend la décision finale de fusionner la merge request.

Les règles d'approbation, les propriétaires du code, les politiques de sécurité et les pistes d'audit restent en place. L'agent accélère le cycle de revue sans contourner les contrôles qui l'encadrent.

Les agents externes de GitLab Duo Agent Platform peuvent être davantage intégrés avec des déclencheurs basés sur des événements et des flows personnalisés afin d'offrir aux équipes de plateforme un contrôle sur le moment et la manière dont les agents interviennent dans le workflow.

Vos premiers pas avec le codage agentique

Si vous évaluez la manière dont les agents de codage s'intègrent dans le workflow de développement de votre organisation :

Choisissez un bogue visible dans un projet réel. Définissez le comportement attendu dans un ticket GitLab avec des exigences claires. Suivez la même progression que celle présentée dans les tutoriels : corrigez-le localement avec l'agent travaillant depuis le dépôt, connectez le MCP de GitLab pour que l'agent travaille depuis le ticket, puis utilisez l'agent comme relecteur externe pour prendre en compte les retours dans la merge request.

Investissez dans AGENTS.md. Documentez le fonctionnement du dépôt, les commandes à surveiller et les attentes en matière de qualité du code. Ces instructions garantissent des résultats de meilleure qualité fournis par les agents, qui s’améliorent au fil du temps à mesure que davantage d’agents et d'équipes de développement interagissent avec le projet.

Surveillez la consommation liée au contexte. Si les sessions des agents sont lentes, coûteuses ou produisent des résultats superficiels, le problème est probablement dû au contexte fourni au modèle, et non au modèle lui-même. Un contexte structuré et pertinent transmis via des intégrations de plateforme, donne de meilleurs résultats que le simple dépôt de fichiers bruts.

Vérifiez la couverture de sécurité. À mesure que les agents de codage génèrent davantage de merge requests entre les projets, assurez-vous que chaque projet fait l'objet d'un scan. Appliquez des profils de configuration de sécurité au niveau du groupe afin que les scanners soient activés automatiquement, puis utilisez l'inventaire de sécurité pour confirmer la couverture et identifier les zones de concentration des vulnérabilités.

Lancez-vous dès aujourd’hui dans le codage agentique

Les organisations qui tireront le meilleur parti du codage agentique seront celles qui disposent de plateformes DevSecOps offrant aux agents le contexte et les contrôles nécessaires pour livrer en toute sécurité.

Si vous n'utilisez pas encore GitLab Duo Agent Platform, vous pouvez commencer un essai gratuit.

Si vous utilisez déjà GitLab dans l'édition gratuite, vous pouvez vous inscrire à GitLab Duo Agent Platform en suivant ces étapes.

Et si vous êtes déjà abonné à GitLab Premium ou GitLab Ultimate, lancez-vous en activant GitLab Duo Agent Platform et en utilisant les crédits promotionnels GitLab inclus dans votre abonnement.

Cette lettre défend l'idée que les poids ouverts stimulent l'innovation, offrent aux clients un meilleur contrôle et constituent une voie importante vers la sécurité de l'IA. Au-delà d'une position politique que nous partageons, ce principe est au cœur de notre vision de l'ingénierie agentique : les équipes donnent le meilleur d'elles-mêmes lorsqu'elles peuvent choisir le modèle le plus adapté à leurs besoins.

En tant que plateforme d'orchestration intelligente pour le DevSecOps, GitLab allie rapidité et contrôle au service du développement logiciel agentique, et place le choix du client au cœur de sa démarche en orchestrant le cycle de vie logiciel et en prenant en charge plusieurs modèles tout au long du workflow des équipes.

Permettre aux clients de choisir leurs modèles d'IA

De nombreuses organisations manifestent un intérêt croissant pour un accès encadré aux meilleurs modèles de base et aux modèles à poids ouverts. GitLab prend en charge les deux.

Les modèles de base offrent souvent des capacités polyvalentes, tandis que les modèles à poids ouverts permettent aux clients de mieux maîtriser les coûts, le déploiement et la résidence des données. Notre objectif est d'aider les clients à les combiner selon leurs besoins.

L'une des décisions les plus critiques pour les dirigeants d'entreprise est de protéger leurs logiciels et leur propriété intellectuelle stratégique contre les menaces liées à la sécurité, à la confidentialité et à la concurrence. Les organisations ne devraient pas être contraintes de dépendre d'un seul fournisseur de cloud ou de modèles d'IA.

GitLab est la seule plateforme à la fois neutre vis-à-vis du cloud et des modèles d'IA. Cette liberté de choix ne peut être préservée que si le marché des modèles reste ouvert. Les modèles à poids ouverts offrent aux équipes de développement la possibilité de choisir où exécuter leurs modèles d'IA, dans des environnements air-gapped si nécessaire, tout en conservant le contrôle de leur code.

Notre position

À l'instar des décideurs politiques, nous souhaitons un écosystème d'IA sûr et sécurisé, et considérons l'ouverture comme un élément essentiel pour y parvenir. Nous soutenons les politiques qui préservent la capacité à développer, distribuer et utiliser des modèles à poids ouverts, sous réserve de mesures de protection ciblées et fondées sur les risques, ainsi que d'outils adaptés pour lutter contre les usages malveillants avérés. Ces types d'interventions peuvent jouer un rôle significatif dans le développement d'un écosystème robuste, où plusieurs fournisseurs de modèles (ouverts et propriétaires) peuvent se concurrencer sur le fond, au bénéfice de l'innovation, de la sécurité et du choix des clients.

Liens connexes

• Centre pour la transparence de l'IA de GitLab
• L'indépendance des entreprises : un sujet plus important que jamais en DevSecOps

Le dernier modèle d'IA d'Anthropic, Claude Opus 5, désormais disponible sur GitLab Duo Agent Platform, est conçu pour les tâches les plus exigeantes pour un agent. Avec Opus 5, vos équipes d'ingénierie peuvent confier aux agents des tâches plus complexes et critiques. Lors de l’évaluation interne menée par GitLab, Opus 5 a résolu 93,3 % des tâches de référence, soit une amélioration de 20,3 points par rapport au taux de résolution de 73,0 % d'Opus 4.8.

« Les équipes qui tirent le meilleur parti des agents d'IA peuvent leur confier leurs tâches les plus complexes et les plus critiques, avec la certitude que le raisonnement tiendra la route du début à la fin. »

— Stuart Moncada, VP, AI Product Management, GitLab

Un raisonnement qui résiste à la complexité

Certaines équipes hésitent à confier leurs tâches les plus complexes à un agent, car les erreurs sont coûteuses à corriger. Sur des tâches de longue durée et de grande complexité, le raisonnement d'un agent doit rester cohérent du début à la fin. Grâce au raisonnement approfondi d'Opus 5, un plus grand nombre de vos tâches complexes, comme les fonctionnalités impliquant plusieurs fichiers et les refactorisations de grande envergure, sont résolues correctement dès la première tentative, ce qui réduit le temps consacré au diagnostic et aux nouvelles tentatives après des exécutions infructueuses. Les équipes qui utilisent GitLab Duo Agent Platform avec Opus 5 peuvent s'attendre à moins de correctifs partiels, avec davantage de tâches prêtes à être fusionnées.

Cette fiabilité s'étend également à l'exhaustivité. Lors des tests internes de GitLab, Opus 5 a mené à bien 100 % des tâches qu'il a tentées, égalant le taux de complétion d'Opus 4.8. La différence réside dans la qualité des résultats : un plus grand nombre de solutions proposées par Opus 5 sont vérifiées comme correctes, ce qui porte le taux de résolution à 93,3 %, contre 73,0 % pour Opus 4.8.

L'une des tâches de l'évaluation de GitLab consistait à implémenter la prise en charge d'une connexion SSO simulable dans un flux d'authentification CLI, une modification couvrant cinq fichiers, incluant de nouveaux types exportés et des champs de configuration. Plusieurs autres modèles testés n'ont produit aucune tentative de correction. Opus 5, quant à lui, a développé l'implémentation complète, l'a validée et a ouvert une merge request.

Vous pouvez vous attendre à la même précision lors de la revue de code. Opus 5 signale les véritables bogues et génère peu de faux positifs, ce qui permet à vos équipes de rester concentrées sur les vulnérabilités réelles et de passer moins de temps à filtrer le bruit.

Si votre charge de travail fait tourner plusieurs agents simultanément, vous perdez moins de temps à démêler les conflits entre eux. Opus 5 assure la coordination des sous-agents, en veillant à ce qu'ils n'interfèrent pas dans le travail des autres. Les modèles « writer-verifier » détectent les problèmes entre les agents avant qu'ils ne vous parviennent, avec un agent vérifiant les données de sortie d'un autre avant qu'elle ne soit acceptée. Les équipes qui mènent des sessions plus longues et plus autonomes avec davantage d'agents en parallèle obtiennent les meilleurs résultats.

Pour les charges de travail sensibles aux coûts qui exécutent plusieurs agents en parallèle, les plafonds d'utilisation des GitLab Credits vous permettent de fixer une limite stricte sur les dépenses, afin que le travail en parallèle ne dépasse jamais votre budget.

La vitesse va de pair avec la profondeur

Sur les tests de performance les plus exigeants de GitLab, Opus 5 associe fiabilité et rapidité. Au 95e percentile, c'est-à-dire dans la partie la plus lente de ses exécutions, Opus 5 a terminé 2,2 % plus vite qu'Opus 4.8 (768 secondes contre 784,98 secondes) et 21,9 % plus vite que Sonnet 4.6 (768 secondes contre 982,57 secondes). Fiabilité et rapidité vont de pair. Pour vos équipes, cela se traduit par des délais d'exécution plus prévisibles, même pour vos exécutions les plus longues.

Choisir le bon modèle selon la tâche

Le choix du modèle dépend de la tâche à accomplir, et non d'une politique unique à l'échelle de l'organisation. Les modèles de la classe Sonnet prennent en charge l’essentiel du travail de développement quotidien : ils sont rapides, abordables et fiables pour les tâches que la plupart des équipes exécutent en continu. Optez pour Opus 5 lorsque le travail exige un raisonnement plus approfondi : les débogages les plus complexes, les refactorisations les plus importantes, les décisions que vous ne souhaitez pas revoir.

Vous définissez ce choix directement dans votre instance GitLab via la sélection de modèle. Quel que soit le modèle choisi, il s'exécute dans la même infrastructure : la couche de contexte, les contrôles de politique et la piste d'audit qui couvrent chaque modèle sur GitLab Duo Agent Platform.

Mettez Opus 5 à contribution

Claude Opus 5 est disponible dès maintenant sur GitLab Duo Agent Platform et, à l'instar des autres modèles, fonctionne avec les GitLab Credits. Vous découvrez GitLab Duo Agent Platform ? Démarrez un essai gratuit dès aujourd'hui. Vous êtes déjà abonné à GitLab Premium ou GitLab Ultimate ? Activez GitLab Duo Agent Platform et utilisez les GitLab Credits inclus dans votre abonnement.

Dans le développement moderne, cette planification ne vit plus en silo : elle s’inscrit dans un cycle DevSecOps continu où les idées deviennent du code testé, sécurisé et déployé en production. L’objectif n’est pas seulement de « mieux planifier », mais de raccourcir le temps entre l’idée et la valeur réellement livrée aux utilisateurs.

Les équipes livrent ainsi des fonctionnalités exploitables plus vite, s'adaptent aux retours des utilisateurs et réduisent le risque de construire un produit déconnecté des besoins réels.

Ce guide présente les fondamentaux de la planification Agile et ses principales méthodologies, puis détaille les étapes pour mettre en place des pratiques efficaces, en montrant comment les connecter au cycle de développement logiciel.

→ Commencez un essai gratuit de GitLab Ultimate.

Qu'est-ce que la planification Agile ?

La planification Agile désigne une approche de gestion de projet qui privilégie l'adaptation continue plutôt que le respect strict d'un plan initial. Contrairement au modèle en cascade (Waterfall), où chaque phase doit être terminée avant de passer à la suivante, la planification Agile découpe le travail en itérations courtes. Chaque cycle vise à produire un incrément de produit livrable et porteur de valeur.

Dans le développement logiciel, les exigences évoluent constamment. Les besoins des utilisateurs se précisent au fil du temps, les contraintes techniques apparaissent en cours de route et le marché peut évoluer entre le début et la fin d'un projet. Plutôt que de considérer ces changements comme des perturbations, la planification Agile les intègre comme une composante inhérente au processus.

L'origine de cette philosophie remonte à février 2001, lorsque 17 experts du développement logiciel se sont réunis à Snowbird, dans l'Utah, pour trouver un terrain d'entente entre leurs différentes pratiques. De cette rencontre est né le Manifeste Agile, un document fondateur qui pose les bases d'une nouvelle façon de concevoir les projets.

Depuis, l'agilité s'est étendue bien au-delà du développement logiciel pour toucher les équipes IT, produit, marketing, ainsi que les organisations adoptant les pratiques DevOps et DevSecOps.

Les quatre valeurs du Manifeste Agile

Le Manifeste Agile repose sur quatre valeurs fondamentales qui guident toute démarche de planification Agile.

La première place les individus et leurs interactions au-dessus des processus et des outils. Concrètement, cela signifie qu'une équipe qui communique bien livrera toujours mieux qu'une équipe dotée des meilleurs outils mais qui travaille en silos.

La deuxième valeur privilégie le logiciel fonctionnel à une documentation exhaustive. L'objectif n'est pas d'éliminer la documentation, mais de concentrer l'énergie sur ce qui apporte de la valeur aux utilisateurs.

La troisième valeur met la collaboration avec le client au centre du processus, plutôt que la négociation contractuelle. Le client n'est pas un interlocuteur qu'on voit au début et à la fin du projet, mais un partenaire impliqué tout au long du développement.

Enfin, la quatrième valeur encourage l'adaptation au changement plutôt que le suivi strict d'un plan. Un plan reste utile, mais il doit pouvoir évoluer quand les circonstances l'exigent.

Ces quatre valeurs ont formalisé des pratiques déjà émergentes, comme Scrum, co-créé par Jeff Sutherland et Ken Schwaber (tous deux signataires du Manifeste) et présenté publiquement dès 1995. Elles s'accompagnent de 12 principes opérationnels et constituent le socle sur lequel repose le fonctionnement concret de la planification Agile.

Comment fonctionne la planification Agile ?

Dans une approche Agile, la planification ne se fait pas une seule fois au début du projet. Elle s'effectue à plusieurs niveaux, du plus stratégique au plus opérationnel, et se révise régulièrement. Cette structure en couches permet de garder une vision d'ensemble tout en restant flexible sur les détails d'exécution.

Le travail est organisé autour d’une liste de tâches liées au développement produit (appelée backlog, que ce soit dans une approche Scrum ou Kanban). Chaque élément de cette liste décrit une fonctionnalité ou un besoin du point de vue de l'utilisateur. Le responsable produit (ou Product Owner) est chargé de maintenir cette liste, de la prioriser et de s'assurer que chaque élément est suffisamment clair pour être développé.

Selon la méthode retenue, le rythme de travail prend des formes différentes. Dans une approche Scrum, l'équipe sélectionne à intervalles réguliers les éléments prioritaires de la liste de tâches pour les traiter lors d'un sprint à durée fixe (généralement d'une à quatre semaines). Elle se concentre alors sur ces éléments et limite au maximum l'ajout de nouvelles tâches en cours de cycle. À la fin du sprint, elle présente ce qu'elle a réalisé aux parties prenantes (lors de la Sprint Review), puis identifie les améliorations à apporter à son fonctionnement pour le sprint suivant (lors de la Sprint Retrospective).

Dans une approche en flux continu comme Kanban, il n'y a pas de cycle à durée fixe. Les tâches sont prises en charge dès qu'une capacité se libère, dans la limite du nombre de tâches en cours autorisées (WIP limit ou limite de travail en cours), et le backlog est réapprovisionné au besoin plutôt qu'à cadence régulière.

Dans les deux cas, le principe reste le même : limiter les perturbations en cours de traitement pour garder un rythme prévisible tout en s'adaptant aux changements.

Les niveaux de planification

La planification Agile s'organise en plusieurs horizons temporels qui s'emboîtent les uns dans les autres.

Au niveau le plus élevé, la vision produit définit la direction, généralement sur 6 à 18 mois selon les organisations. Elle répond à la question fondamentale : « Quel problème résolvons-nous, pour qui et pourquoi maintenant ? » Dans GitLab, cette vision peut se matérialiser à travers des epics de haut niveau et des objectifs produits partagés.

La roadmap traduit cette vision en jalons concrets, typiquement sur 3 à 12 mois. Elle identifie les grandes fonctionnalités à livrer, sans entrer dans le détail de leur implémentation. Les équipes Scrum, par exemple, utilisent souvent des epics pour regrouper les éléments de la roadmap. Un epic représente une initiative significative qui nécessitera plusieurs itérations pour être complétée.

La planification des versions (ou release planning) affine la roadmap en déterminant quelles fonctionnalités feront partie de chaque version livrée aux utilisateurs. C'est à ce niveau que les dépendances entre équipes sont identifiées, que les risques majeurs sont anticipés et que l’on s’assure que les releases restent cohérentes avec la vision produit.

Le niveau suivant est celui de l’itération. Avec la méthode Scrum, la planification d'itération (ou sprint planning) a lieu selon une cadence fixe d'une à quatre semaines : à chaque cycle, l'équipe décide quels éléments de la liste de tâches (backlog) elle s'engage à livrer. Dans GitLab, ce niveau s’exprime à travers les itérations et les jalons, auxquels les tickets sont rattachés.

Avec la méthode Kanban, ce niveau prend la forme d'un réapprovisionnement continu du backlog (replenishment), déclenché à la demande plutôt qu'à intervalles fixes. L’enjeu reste le même : rendre explicite ce qui est en cours, ce qui vient ensuite et ce qui peut attendre.

Enfin, la réunion quotidienne de synchronisation (également appelée Daily Scrum ou Daily Standup), bien qu'issue de l’approche Scrum, est aujourd'hui largement adoptée par les équipes Agile, quelle que soit la méthode suivie. Elle permet chaque jour d'aligner l'équipe, de visualiser le travail en cours et d'identifier rapidement les obstacles.

Cette structure en couches évite de tout planifier dans le détail dès le départ tout en gardant le cap sur les objectifs, et elle se prête particulièrement bien aux outils qui relient vision, epics, tickets et code dans un même espace.

Scrum, Kanban et autres méthodes Agiles

L'agilité n'est pas une méthode unique, mais un ensemble de principes qui se déclinent en plusieurs frameworks. Chacun propose une façon différente d'organiser le travail, avec ses forces et ses contextes d'application privilégiés.

Scrum est un framework itératif structuré autour de sprints de durée fixe, avec des rôles définis et des événements récurrents. Il convient particulièrement aux projets complexes où les exigences évoluent.

Kanban repose sur le flux continu, sans sprints. Le travail progresse sur un tableau visuel avec des limites sur le travail en cours. Cette approche s'adapte aux équipes de support, de maintenance ou aux contextes où les priorités changent fréquemment.

Extreme Programming (XP) est une méthode Agile à part entière qui met l'accent sur les pratiques techniques comme le pair programming, les tests automatisés et l'intégration continue. Certaines équipes choisissent de combiner XP avec Scrum pour renforcer la qualité du code tout en conservant la structure itérative de Scrum.

Les frameworks d'agilité à l'échelle comme le Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS) ou la boîte à outils Disciplined Agile (DA) permettent de déployer l'agilité dans les grandes organisations, en coordonnant plusieurs équipes autour d'objectifs communs.

Le choix d'un framework dépend du contexte : taille de l'équipe, nature du produit, maturité Agile, contraintes organisationnelles. Certaines équipes commencent avec une approche Scrum pour sa structure claire, puis évoluent vers des approches hybrides au fil de leur montée en compétence.

Scrum en détail

Scrum est le framework Agile le plus répandu. Son succès tient à sa structure claire qui donne des repères aux équipes tout en préservant leur autonomie. Le travail s'organise en sprints d’une à quatre semaines, chacun produisant un incrément potentiellement livrable du produit. Consultez ce tutoriel pour en savoir plus sur l’utilisation des fonctionnalités de planification et de suivi Agile dans GitLab, afin de faciliter les événements et les workflows Scrum.

Trois rôles structurent l'équipe Scrum. Le Product Owner (ou responsable produit) porte la vision du produit et priorise la liste de tâches. Le Scrum Master veille au respect du cadre Scrum et aide l'équipe à s'améliorer. Les développeurs s'autogèrent pour transformer les éléments de la liste de tâches en fonctionnalités.

Cinq événements rythment le sprint :

• Le Sprint lui-même constitue l'événement conteneur dans lequel tous les autres événements se déroulent.
• Le Sprint Planning définit le travail à accomplir.
• Le Daily Scrum (ou Daily Standup) synchronise l'équipe chaque jour.
• La Sprint Review présente ce qui a été réalisé aux parties prenantes.
• La Sprint Retrospective identifie les améliorations à apporter au processus.

Cette cadence régulière crée un rythme prévisible qui facilite la coordination.

Scrum fonctionne particulièrement bien pour les projets où les exigences sont susceptibles d'évoluer, où les retours utilisateurs sont disponibles régulièrement et où l'équipe peut se consacrer au projet sans interruptions constantes.

Kanban pour le flux continu

Kanban propose une approche différente, fondée sur la visualisation du travail et l'optimisation du flux, sans sprints ni rôles formalisés. Les tâches à réaliser sont collectées dans un backlog, depuis lequel l'équipe les fait progresser d'une colonne à l'autre sur un tableau Kanban, au rythme permis par les limites de travail en cours.

Le principe central de Kanban est la limite du travail en cours, ou WIP limit. En restreignant le nombre de tâches que l'équipe peut traiter simultanément, celle-ci évite la dispersion et fait émerger les goulots d'étranglement. Si une colonne atteint sa limite, l'équipe doit terminer les tâches en cours avant d'en commencer de nouvelles.

Cette approche convient particulièrement aux équipes où les demandes arrivent en continu et où il est difficile de planifier à l'avance. Elle permet aussi une transition en douceur vers l'agilité pour les organisations qui ne souhaitent pas bouleverser leur fonctionnement du jour au lendemain.

Passer à l'échelle avec SAFe, LeSS et Disciplined Agile

Quand plusieurs équipes travaillent sur un même produit ou portefeuille, la coordination devient un défi. Les frameworks d'agilité à l'échelle proposent des mécanismes pour aligner les efforts sans perdre les bénéfices de l'autonomie des équipes.

Scaled Agile Framework (SAFe) est le framework le plus structuré. Il organise les équipes en Agile Release Trains qui livrent ensemble à intervalles réguliers. Il définit des rôles additionnels et des événements de synchronisation inter-équipes. Cette structure convient aux grandes organisations qui ont besoin de gouvernance et de prévisibilité.

Large-Scale Scrum (LeSS) prend le parti inverse. Il conserve le framework Scrum aussi simple que possible, même avec plusieurs équipes. Toutes les équipes partagent la même liste de tâches et travaillent sur un produit commun, avec un seul Product Owner.

Disciplined Agile (DA) propose une approche modulaire où chaque organisation compose son propre framework en fonction de son contexte.

Quel que soit le framework choisi, le passage à l'échelle fonctionne mieux quand les équipes disposent d'une plateforme unifiée pour visualiser le travail à effectuer, gérer les dépendances et suivre l'avancement des tâches. Les outils fragmentés multiplient les frictions et les risques de désalignement.

Pour en savoir plus sur la planification et le suivi de vos projets au sein de GitLab, consultez notre documentation.

Avantages et limites de la planification Agile

L'agilité n'est pas une solution miracle, mais elle apporte des bénéfices mesurables quand elle est bien mise en œuvre. Elle présente aussi des défis qu'il vaut mieux anticiper.

Ce que l'agilité apporte aux équipes

Les organisations qui adoptent la planification Agile constatent généralement une livraison plus rapide de valeur. Le travail étant découpé en incréments, les utilisateurs bénéficient de nouvelles fonctionnalités plus tôt, sans attendre la fin du projet.

L'agilité améliore aussi la capacité d'adaptation. Les équipes peuvent réorienter leurs efforts à chaque itération en fonction des retours du terrain ou des évolutions du marché. Cette flexibilité réduit le risque de livrer un produit qui ne correspond plus aux attentes des utilisateurs.

La visibilité constitue un autre avantage significatif. Les parties prenantes voient l'avancement réel à chaque fin d'itération, sous forme de fonctionnalités démontrables, et non de simples indicateurs chiffrés.

Enfin, les cycles courts et les événements réguliers créent des occasions d'échange qui renforcent la collaboration entre les équipes métiers, les utilisateurs et les équipes de développement.

Les défis à anticiper

La planification Agile n'est pas sans difficultés. Le premier obstacle est souvent la résistance au changement. L'agilité remet en question les habitudes établies, les structures de pouvoir et les modes de reporting traditionnels. Sans accompagnement, les équipes peuvent rejeter le nouveau cadre ou ne pas l’appliquer correctement.

L'estimation du budget total soulève également des questions. Quand on ne sait pas exactement ce qu'on va livrer à la fin, comment s'engager sur un montant fixe ? La réponse passe généralement par un budget par capacité, c'est-à-dire le financement d'une équipe pendant une durée donnée, plutôt que par un budget projet figé.

Sans discipline, l'agilité peut aussi conduire à accumuler de la dette technique. La pression pour livrer à chaque itération peut pousser à négliger la qualité du code, les tests ou la documentation. Les équipes expérimentées intègrent explicitement le traitement de la dette technique dans leur planification.

Enfin, l'agilité demande une implication forte des parties prenantes. Si les retours arrivent avec des semaines de retard ou si les priorités ne sont pas claires, l'équipe perd en efficacité et en alignement. La solution passe par des points de feedback courts et fréquents, et un responsable produit disponible et décisionnaire.

Mettre en place la planification Agile au sein de votre organisation

Adopter une approche Agile ne se fait pas en un jour. Une transition réussie commence généralement par un projet pilote ou une équipe volontaire, plutôt que par une transformation globale de l'organisation. Cette approche permet d'apprendre, d'ajuster et de démontrer des résultats avant d'étendre les pratiques.

La formation de l'équipe est un prérequis souvent sous-estimé. Chaque membre doit comprendre les principes sous-jacents, pas seulement les événements à suivre. Sans cette compréhension, ces événements deviennent des formalités vides de sens.

La clarification des rôles évite beaucoup de conflits. Qui priorise la liste de tâches ? Qui peut ajouter des tâches en cours d’itération ? Qui décide si une fonctionnalité est terminée ? Ces questions doivent trouver des réponses claires dès le départ.

Enfin, les outils de visualisation et de suivi permettent à l'équipe de travailler efficacement. Un tableau Kanban, même physique, vaut mieux qu'un tableur partagé que personne ne met à jour.

Définir les rôles et les responsabilités

La clarté des rôles évite bien des malentendus une fois le projet lancé.

Dans le cadre d’une approche Scrum, le Product Owner est le garant de la valeur. Il comprend les besoins des utilisateurs, définit la vision du produit, priorise le backlog et prend les décisions sur ce qui doit être fait.

Le Scrum Master n'est pas un chef de projet. Son rôle est de faciliter : aider l'équipe à respecter le cadre Scrum, lever les obstacles, protéger l'équipe des interruptions et favoriser l'amélioration continue. Un bon Scrum Master rend l'équipe autonome et non dépendante de lui.

Les développeurs forment une équipe pluridisciplinaire et autogérée. Elle regroupe toutes les compétences nécessaires pour transformer un élément de la liste de tâches en fonctionnalité livrée, qu'il s'agisse de développement, de test, de design ou d'ops.

Selon le Scrum Guide 2020, l'équipe Scrum compte généralement 10 personnes ou moins, Product Owner et Scrum Master inclus.

Structurer et prioriser les tâches

Une liste de tâches bien tenue est la colonne vertébrale de la planification Agile. Chaque élément doit être formulé de façon à ce que l'équipe puisse l'estimer et le développer.

Dans les équipes Scrum, le format le plus courant est celui de la user story, qui suit la structure suivante : « En tant que [type d'utilisateur], je veux [action], afin de [bénéfice] ». Ce guide de planification et de suivi détaille les bonnes pratiques pour utiliser GitLab afin de faciliter les événements et les workflows Scrum.

Les user stories sont regroupées en epics pour les initiatives importantes et découpées en tâches pour le travail quotidien. Cette hiérarchie permet de naviguer entre la vision d'ensemble et le détail opérationnel.

Pour prioriser, plusieurs techniques existent. La méthode MoSCoW classe les éléments en Must have, Should have, Could have et Won't have. L'approche par valeur métier pondère chaque élément en fonction de son impact attendu. Quelle que soit la méthode, l'essentiel est que le haut de la liste de tâches soit clair, détaillé et prêt à être développé.

Les outils pour une planification Agile efficace

Un outil de planification Agile ne fait pas l'agilité, mais il peut la faciliter ou la freiner. Les équipes ont besoin de tableaux visuels pour représenter le workflow et suivre l'avancement des tâches : colonnes par étape (à faire, en cours, en revue, terminé), limites de travail en cours, regroupement par équipe ou par epic.

Elles ont besoin d'une gestion des tâches qui permette de prioriser, d'estimer et de découper les éléments : user stories, bogues, tâches techniques, dette technique. Le suivi des itérations, à l'aide de graphiques d'avancement (burndown ou burnup charts) et de rapports réguliers, aide à piloter le processus d'itération et à ajuster la charge en fonction de la vélocité de l’équipe.

Dès que plusieurs équipes travaillent ensemble, la gestion des dépendances devient critique : savoir quelles tâches en bloquent d’autres, quelles fonctionnalités doivent être livrées ensemble, et où se situent les goulots d’étranglement. Enfin, les roadmaps permettent de communiquer la vision et les jalons clés aux parties prenantes, dans un langage compréhensible au-delà de l’IT.

Un critère souvent négligé est l'intégration avec l'environnement de développement. De nombreuses organisations utilisent un outil de planification déconnecté de leur code, ce qui oblige les équipes de développement à mettre à jour deux systèmes en parallèle. Les informations divergent, et personne n'a de vision fiable de l'état réel du projet.

GitLab adresse précisément ce point en regroupant, dans une seule plateforme, les tableaux Scrum ou Kanban, les epics, les roadmaps, les jalons, les itérations, les graphiques d’avancement et les analyses de flux de valeur (Value Stream Analytics). La planification, le suivi et l’exécution vivent au même endroit que le code, les revues de merge requests, les pipelines CI/CD et les contrôles de sécurité, ce qui réduit les frictions et améliore la fiabilité des données utilisées pour décider.

Connecter la planification au cycle de développement logiciel

La planification Agile prend tout son sens quand elle est connectée au code. Quand un élément de la liste de tâches est lié aux commits qui l'implémentent, aux pipelines qui le testent et aux déploiements qui le mettent en production, la traçabilité devient automatique. Le responsable produit voit exactement où en est chaque fonctionnalité, sans avoir à demander de reporting supplémentaire.

Cette intégration permet aussi d'alimenter des métriques fiables. Les graphiques d'avancement se mettent à jour en temps réel en fonction des tâches réellement terminées. La vélocité de l'équipe se calcule à partir des tickets clôturés, pas de projections théoriques. Les analyses du flux de valeur révèlent où le temps est perdu dans le cycle de développement : spécification, revue de code, tests, déploiement, etc.

GitLab illustre cette approche avec ses capacités de livraison Agile. Les tableaux des tickets permettent de visualiser le travail en Scrum ou Kanban. Les epics gèrent les initiatives de grande envergure, les jalons marquent les étapes clés, et les itérations structurent le rythme de travail des équipes.

Le cas d'Iron Mountain montre les gains possibles : l'entreprise a économisé 20 heures par projet sur le temps d’onboarding en utilisant une plateforme unifiée pour son framework SAFe, tout en améliorant la collaboration entre les équipes informatiques et les principales parties prenantes.

« GitLab nous a fourni les bases et la plateforme nécessaires à la mise en place de notre Scaled Agile Framework. Nous sommes désormais en mesure de collaborer au sein de nos équipes informatiques et avec nos principales parties prenantes. » — Hayelom Tadesse, Vice President of Enterprise Technology, Iron Mountain

Dans ce modèle, la planification n’est plus une couche séparée que l’on alimente manuellement. Elle devient une vue cohérente et en temps réel de tout le cycle de développement logiciel (SDLC), de l’idée jusqu’au déploiement.

L’agent Planner de GitLab

L'IA vient également enrichir cette planification Agile. Avec GitLab Duo Agent Platform et l'agent Planner, les équipes peuvent générer et structurer plus rapidement leurs tickets, préparer leurs listes de tâches et leurs itérations, et mieux visualiser les dépendances.

À partir d’une simple description de fonctionnalité, l’agent peut proposer une arborescence d’epics et de tickets, des estimations et une répartition dans les sprints, que l’équipe ajuste ensuite. Résultat : moins de temps passé sur les tâches administratives et de coordination, et plus de temps consacré à la conception et à la livraison de valeur. Pour en savoir plus, parcourez la catégorie du blog de GitLab dédiée à la Planification Agile.

→ Vous souhaitez en savoir plus sur la planification Agile au sein de GitLab ? Commencez un essai gratuit de GitLab Ultimate.

Conclusion

La planification Agile n'est pas une recette magique, mais un cadre qui aide les équipes à livrer de la valeur de façon plus prévisible. Ses fondamentaux restent simples : découper le travail en cycles courts, prioriser ce qui compte vraiment, s'adapter aux retours et s'améliorer continuellement.

Le choix du framework, qu'il s'agisse de Scrum, de Kanban ou d'une approche hybride, importe moins que la qualité de son implémentation. Une équipe qui comprend les principes sous-jacents et qui dispose des bons outils progressera, quel que soit le cadre choisi, à condition de rester ouverte à une amélioration continue.

Si vous souhaitez passer à l'échelle, GitLab propose une plateforme où la planification, le développement et le déploiement cohabitent, permettant aux équipes de se concentrer sur ce qui compte : livrer des logiciels qui répondent aux besoins des utilisateurs.

FAQ sur la planification Agile

Quelle est la différence entre Scrum et Agile ?

Agile est une philosophie de gestion de projet basée sur l'adaptation et la collaboration, formalisée par le Manifeste Agile de 2001. Scrum est l'un des frameworks qui implémentent cette philosophie, avec des rôles définis (Product Owner, Scrum Master), des sprints de durée fixe et des événements spécifiques.

Comment organiser un sprint planning efficace ?

Un sprint planning réussi commence par un backlog préparé. Les user stories prioritaires doivent être claires et estimables avant la réunion. Limitez la durée à environ quatre heures pour un sprint de deux semaines et assurez-vous que le Product Owner est présent pour répondre aux questions. Terminez avec un objectif de sprint (Sprint Goal) partagé et un engagement réaliste basé sur la vélocité passée de l'équipe.

Combien de temps dure un sprint Agile ?

La durée standard d'un sprint est de deux semaines, mais elle peut varier d’une à quatre semaines selon les contextes. Les sprints courts permettent des retours plus fréquents et une meilleure réactivité. Les sprints plus longs conviennent aux équipes qui travaillent sur des fonctionnalités complexes nécessitant plus de temps de développement.

La méthode Agile convient-elle à tous les projets ?

L'agilité fonctionne mieux pour les projets où les exigences sont susceptibles d'évoluer, où le feedback utilisateur est accessible et où l'équipe peut travailler de façon autonome. Elle est moins adaptée aux projets à périmètre fixe et à budget contraint, ou aux environnements très réglementés où chaque changement nécessite des validations lourdes. Dans ces cas, une approche hybride peut être pertinente.

Comment mesurer l'efficacité de sa planification Agile ?

Plusieurs indicateurs permettent de suivre la santé d'une équipe Agile. La vélocité mesure le nombre de story points livrés par sprint (l'unité d'estimation utilisée en Scrum). Le délai d'exécution indique le temps entre la création d'une tâche et sa mise en production. Le taux d'achèvement des sprints et la satisfaction de l'équipe sont également révélateurs. Les métriques DORA (fréquence de déploiement, délai de livraison, taux d'échec des changements, temps de restauration) complètent ces indicateurs pour les équipes de développement.

Comment mettre en place la planification Agile avec GitLab ?

GitLab propose un ensemble complet de fonctionnalités pour la planification Agile : epics et roadmaps pour la vision, tableaux de tickets pour Scrum ou Kanban, itérations pour structurer les sprints, jalons pour suivre les releases, et analytics pour mesurer la vélocité et les goulots d’étranglement. En connectant ces éléments au code, aux pipelines CI/CD et aux contrôles de sécurité, les équipes obtiennent une vue de bout en bout du cycle de développement, sans changer constamment d’outil.

GitLab Orbit est un graphe vivant et interrogeable de votre code, de vos merge requests, pipelines, déploiements et responsabilités, avec toutes les relations entre ces éléments maintenues à jour en permanence. Les agents écrivent bien du code, mais peinent à comprendre le système qui l'entoure. Répondre aux questions « de quoi dépend cet élément », « quels tests le couvrent », « qui est responsable en cas de retombées » nécessitait autrefois qu'un agent parcoure des fichiers ou qu'un ingénieur explore quatre outils différents. GitLab Orbit transforme ces étapes en une seule requête. Les agents accèdent à GitLab Orbit via le Model Context Protocol (MCP), les ingénieurs l'interrogent directement, et la réponse est fournie en quelques secondes plutôt qu'en quelques heures. La page d'accueil de GitLab Orbit présente les fonctionnalités complètes de cet outil. Nous souhaitions voir ce que les participants construiraient une fois qu'ils en auraient la maîtrise.

Le hackathon a réuni 1 576 développeurs inscrits, qui ont livré 265 projets éligibles dans la catégorie Showcase Track, construits sur GitLab Orbit : des agents, des flows et des compétences. Par ailleurs, 26 contributrices et contributeurs ont fusionné 61 améliorations directement dans la base de code de GitLab Orbit (nouveaux langages pris en charge, correction de bogues et perfectionnement de la documentation). La communauté n'a pas seulement construit sur GitLab Orbit, elle a amélioré GitLab Orbit.

Les problèmes ciblés par les participants

Avant même de procéder à l'évaluation, un élément a retenu notre attention : si nous avions trié les projets soumis selon leur fonction, la répartition aurait été très déséquilibrée.

70 équipes ont créé une version du même outil : Dis-moi ce que cette modification pourrait faire échouer avant que je la fusionne. Plus de 30 ont développé des outils d'intégration et de compréhension : « Aide-moi à comprendre ce code source ». Venaient ensuite l'analyse des causes profondes d'incidents, la dérive architecturale, le diagnostic de pipelines instables et le suivi d'une vulnérabilité ou exposition commune (CVE) dans plusieurs dépôts.

Rien de tout cela n'est le fruit du hasard. Les ingénieurs posent constamment ces questions et n'ont pas de réponses satisfaisantes, car celles-ci étaient jusqu'à présent dispersées entre Git, CI, les outils de déploiement et quelques tableaux de bord auxquels personne ne pouvait vraiment se fier. Rassemblez tout cela dans un graphe unique, et les équipes s'y précipitent naturellement.

Cette approche repose sur une orchestration avec un contexte, et non une orchestration seule, et une vitesse avec un contrôle intégré. Et quand des dizaines d'équipes indépendantes posent la même question sans qu'on le leur demande, c'est un signal clair pour toutes les plateformes : le contexte se situe là où le travail se passe réellement. La barre était haute dans les catégories les plus disputées. Des projets se sont distingués en devançant 68 autres équipes, ou en explorant des territoires inédits.

Implémentation technologique

Lauréat : Sankofa. Trois agents, chacun déclenché par un moment différent de votre journée, tous connectés à GitLab Orbit. Ouvrez une merge request et Radar vous donne le rayon d'impact : les appelants en aval, les pipelines affectés, l'équipe responsable des retombées. Un ticket vous est attribué, et Guide vous prépare un document explicatif avant de commencer. Une vulnérabilité est détectée, et Shield en trace chaque chemin d'accès. Le contexte est fourni là où vous êtes déjà, puis Shield vous laisse travailler.

« Quand une vulnérabilité de sécurité est signalée, les équipes passent des jours à tracer manuellement son étendue, faute d'un outil qui relie automatiquement tous les éléments. »

Lester K, Sankofa

Shield le fait en un seul passage sur le graphe.

Finaliste : Stayed Shipped. Il pose une question à laquelle vos tableaux de bord ne peuvent pas répondre : parmi les changements que vos agents d'IA ont fusionnés le mois dernier, combien sont encore en production ? Il vérifie si un changement fusionné est encore en production ou s'il a été discrètement corrigé par un ingénieur senior dans un commit, échappant ainsi à tous les indicateurs standard.

Design et convivialité

Lauréat : Carver. Carver évalue le coût d'une migration de code legacy avant que vous ne vous y engagiez. Décrivez ce que vous souhaitez migrer, et Carver analyse le graphe de dépendances de GitLab Orbit afin de vous fournir un devis : le nombre d'unités, la durée estimée, l'ordre des opérations, et où sont dissimulés les risques. Ce projet se distingue par le résultat produit. Carver vous présente une ligne par unité, dimensionnée et signalée par niveau de risque, et n'en détaille le contenu que sur demande. La migration d'AngularJS vers Angular représente environ neuf semaines d'effort humain pour un coût de génération de dix dollars, avec le service non testé et structurellement critique mis en évidence en rouge pour que vous sachiez où concentrer votre attention en premier lieu.

« Carver interroge GitLab Orbit et, s'il ne trouve pas le service, il demande où se trouve le vrai code. »

Anes Mulalic, Carver

C'est la raison pour laquelle l'agent refuse d'inventer un chiffre qu'il ne peut pas justifier.

Finaliste : Marshal. Ce projet s'attaque au même problème, mais propose une approche opposée : une autonomie totale. Fixez un objectif à l'échelle de l'organisation, et Marshal identifie chaque dépôt concerné via GitLab Orbit, séquence le travail et soumet des merge requests vague par vague, en veillant à ce qu'aucune cible ne soit omise.

Impact potentiel

Lauréat : CrossCut. CrossCut n'exécute que les tests qu'un changement pourrait effectivement faire échouer. Ouvrez une merge request : il extrait les symboles modifiés, parcourt le graphe d'appels de GitLab Orbit pour identifier le véritable impact transitif, et construit un pipeline qui n'exécute que ces tests-là. Aucun modèle dans la boucle, aucune approximation, uniquement un parcours de graphe. Sur une suite de tests volumineuse ou sur plusieurs dépôts, la charge CI est réduite d'au moins 90 %, ce qui en vaut la peine presque immédiatement.

« Pour savoir quels tests une modification peut atteindre, il faut disposer du graphe d'appels de l'ensemble du code source. C'est exactement ce que construit GitLab Orbit : au lieu de deviner, nous interrogeons le graphe. »

Pritesh Kumar, CrossCut

Finaliste : OrbitWeaver. Il effectue une refactorisation autonome en s'appuyant sur le rayon d'impact exact de GitLab Orbit plutôt que sur la similarité vectorielle. Il cartographie tous les fichiers concernés et les modifie en fonction de l'ordre de leurs dépendances. C'est l'argument le plus convaincant en faveur d'un véritable graphe plutôt qu'une recherche approximative quand une erreur signifie un pipeline en échec.

Qualité de l'idée

Lauréat : Transcend. La plupart des équipes ont interrogé GitLab Orbit directement, ce qui constitue la bonne approche pour la majorité des questions. Transcend a construit un second moteur de raisonnement par-dessus, en utilisant la pile du Web sémantique (OWL, SPARQL et RDF) pour explorer les questions auxquelles l'API native ne peut pas répondre en un seul appel, comme la fermeture transitive ou les jointures qui sortent de votre code source pour s'appuyer sur les connaissances structurées du monde entier. Sa démonstration interroge les méthodes d'embedding de graphes de connaissances qu'implémente un code source, et obtient en retour les noms de classes ainsi que les publications qui les ont inspirées, leurs auteurs et les années, joints en temps réel au code. GitLab Orbit est considéré comme une base sur laquelle construire plutôt que comme une simple API à appeler : l'idée était véritablement novatrice, et c'est précisément ce que récompense cette catégorie.

Finaliste : Universal Agent OS. Il construit la couche de gouvernance autour des agents plutôt que l'agent lui-même : questionnement préalable, planification avant le code, conservation des preuves et validation obligatoire. À mesure que les agents produisent une part croissante du code, garantir leur responsabilité deviendra le véritable enjeu. C'est le même problème que le contexte de GitLab Orbit met en lumière partout dans les projets de cet article : les agents sont rapides, mais quelqu'un doit toujours assumer la responsabilité de leurs actions.

Contribute Track

La catégorie Contribute Track s'est déroulée en parallèle de la catégorie Showcase Track, et n'a rien à lui envier. Vingt-six contributeurs ont fusionné 61 merge requests directement dans le code source de GitLab Orbit : prise en charge des concepts C++20, déclarations de paquets Go, coroutines Kotlin et lambdas Ruby ; corrections d'ontologie, correction d'un bogue SIGPIPE dans la CI, premier tutoriel de requête GitLab Orbit et améliorations de la documentation pour que personne ne confonde max_depth et max_hops. Dix-neuf contributeurs ont reçu un prix en espèces. Tous les participants ont obtenu des crédits swag.

Les prix en espèces ont été attribués aux 40 premières contributions fusionnées, ce classement reflète donc autant la rapidité que la qualité. Il s'agit des contributeurs qui ont réussi à faire relire et fusionner un changement fonctionnel en premier. Félicitations aux lauréates et lauréats de cette édition :

achalbajpai, aishahsofea, AlphaTheGoat27, anushkrishnav, bartekp854, bhandari.varun04, ChaitanyaManik17, fa220, fongse, gatlavishweshwarreddy26, gkepas, JonstonChan, koves, MattGaiser, MatthewOscar, nexpectArpit, priyansh3133, Vinayreddy765, zidanesalim.

Consultez l'ensemble des contributions fusionnées.

Ce que nous pouvons retenir de ce hackathon

Nous comprenons beaucoup d'un outil en observant ce que les personnes construisent avec lui, avant même que nous leur disions à quoi il sert.

Personne n'a créé de chatbot. Les meilleurs projets ont tous creusé sous la surface. Ils se sont attaqués à une question qui nécessitait autrefois un après-midi de recherche à travers quatre outils. Et ils y ont répondu en une seule requête.

• Qu'est-ce qui échoue si je fusionne ce changement ?
• Quels tests comptent vraiment ?
• Quel est le coût réel de cette migration ?
• Le changement du mois dernier est-il encore actif ?

Nous n'avons pas livré ces réponses comme fonctionnalités. La communauté les a trouvées dès lors qu'elle pouvait utiliser le graphe, ce qui nous en dit plus sur GitLab Orbit qu'aucun benchmark ne pourrait le faire.

L'ensemble des projets est disponible dans une galerie si vous souhaitez en savoir plus. Nombre de bons projets n'ont pas pu être mentionnés dans cet article.

Ce que vous pouvez construire sur GitLab Orbit

Chacun des lauréats ci-dessus apporte une réponse à la même question : que peut faire un agent lorsqu'il raisonne à partir d'un contexte propriétaire sur l'ensemble de votre système, au lieu de deviner à partir de fragments ? GitLab Orbit cartographie en continu votre code, vos éléments de travail, merge requests, pipelines, déploiements et responsabilités dans un graphe unique, afin que les agents et les ingénieurs s'appuient sur une source de vérité commune. Vous n'avez pas besoin d'un hackathon pour vous lancer. Voici les approches que la communauté a validées, chacune ancrée dans un cas d'utilisation pour lequel GitLab Orbit a été conçu.

• Livraison consciente des modifications : identifiez ce qu'une modification fait échouer avant d'effectuer un push. Interrogez GitLab Orbit pour obtenir chaque appelant downstream d'une fonction, les pipelines qu'elle alimente et l'équipe qui en est responsable, en une seule requête. Le Radar de Sankofa effectue cette opération sur une merge request ; CrossCut exploite le même graphe d'appels pour n'exécuter que les tests qu'une modification peut atteindre, réduisant une exécution CI de 90 %. Détectez les dépendances cachées en amont plutôt qu'à la fin du pipeline CI.
• Des migrations plus sûres avec un contexte système complet. Identifiez quels services dépendent de celui que vous souhaitez déplacer, dans quel ordre, et où se situe le risque. Carver traduit ces données en devis chiffré ; Marshal le pilote dépôt par dépôt. Tous deux délimitent le rayon d'impact à partir du véritable graphe de dépendances, ce qui permet aux équipes plateforme de s'engager sur une date de migration sans découvrir des dépendances cachées trois semaines après le lancement du projet.
• Analyse rapide du rayon d'impact pour identifier les vulnérabilités. À partir d'une fonction vulnérable, suivez le graphe jusqu'à tous les points de terminaison accessibles, les pipelines qui les construisent et les équipes qui en sont responsables. Le Shield de Sankofa accomplit en un seul passage ce qui nécessitait autrefois un exercice de corrélation projet par projet sur plusieurs jours.

Le fil conducteur de ces projets : la réponse n'a jamais été dans le code seul. Elle réside dans la façon dont le code se connecte aux pipelines, déploiements, vulnérabilités et responsabilités. GitLab Orbit maintient ces connexions à jour pour que vous puissiez tout interroger en une seule requête. Les agents sur GitLab Duo Agent Platform l'interrogent nativement, les agents externes se connectent via MCP, et les ingénieurs interrogent le même graphe directement via le Data Explorer. Un graphe, une source de vérité, pour chaque agent et chaque membre de l'équipe.

Essayez GitLab Orbit

Un grand merci à toutes les personnes ayant participé. Pour construire votre propre solution, essayez GitLab Orbit sur GitLab Duo Agent Platform : le même contexte qu'ont utilisé ces équipes est déjà actif dans votre cycle de développement logiciel. Ce hackathon n'est pas le dernier : inscrivez-vous sur contributors.gitlab.com pour connaître les prochains en avant-première.

Vous avez déjà accès à GitLab Duo Agent Platform et à GitLab Orbit et souhaitez explorer jusqu'où vous pouvez aller ? Demandez à participer au programme Co-Create.

Vous ne pouvez pas réduire ce que vous ne mesurez pas.

Les intégrations tierces Eco CI et Carmen ajoutent des données sur l'impact carbone aux pipelines que vous exécutez déjà dans GitLab. Ces deux outils open source peuvent être intégrés dès aujourd'hui à n'importe quel pipeline. Découvrez pourquoi leur intégration en vaut la peine et comment vous lancer dans le Green DevOps.

L'importance du Green DevOps

L'empreinte de calcul d'un pipeline moderne ne cesse de croître. Les tests assistés par l'IA, la revue de code et l'automatisation des pipelines génèrent tous des jobs qui n'existaient pas il y a quelques années, et impliquent tous un coût énergétique qui n'apparaît jamais dans les métriques de vos pipelines ni dans votre schéma d'architecture. Le Green DevOps vise à changer cette situation : il consiste à mesurer les émissions par exécution de pipeline, par service et par pod, puis à utiliser ces données pour prendre de meilleures décisions d'ingénierie.

Où l'empreinte carbone apparaît-elle dans votre pile ?

Les deux couches les plus exploitables pour les équipes d'ingénierie sont les suivantes :

Le pipeline

Eco CI mesure la consommation d'énergie et les émissions de carbone de vos jobs CI/CD. Il s'exécute sous forme de scripts Bash légers, sans serveurs ni bases de données distincts. Vous obtenez des données d'émissions par job, identifiez les jobs les plus gourmands en ressources, suivez les tendances dans le temps et affichez un badge carbone dans votre README.

Pour la plupart des équipes, il s'agit d'un bon point de départ. Votre pipeline est déjà instrumenté ; Eco CI y ajoute simplement des données sur l'empreinte carbone.

L'infrastructure et les applications

Carmen (Carbon Measurement Engine) va plus loin. Basé sur le Green Software Foundation Impact Framework, il mesure les émissions des machines virtuelles, des pods et des charges de travail applicatives individuelles qui s'exécutent dans Kubernetes. Vous obtenez un rapport CSV par composant, ventilé entre carbone opérationnel (consommation d'énergie) et carbone incorporé (fabrication et mise au rebut du matériel), que vous pouvez injecter dans Grafana, dans vos tableaux de bord FinOps ou dans vos propres outils. Les champs de sortie incluent EnergykWh et TotalCarbonGramsCO2eq par composant : les données s'intègrent donc aux tableaux de bord existants sans avoir besoin d'être transformées.

Carmen se révèle particulièrement puissant pour répondre aux questions suivantes :

• Quel service de notre pile émet le plus de CO2 ?
• Comment se positionne notre passerelle API face à notre couche de traitement des données ?

Testez ces intégrations dans votre pipeline

Les deux outils s'intègrent directement dans .gitlab-ci.yml. Voici à quoi ressemble un job Carmen :

carbon-report:
  image: python:3.12
  before_script:
    # Install Carmen and the IF toolchain
    - apt-get update && apt-get install -y nodejs npm git lsb-release
    - git clone https://github.com/Green-Software-Foundation/if-carmen.git
    - npm install -g "@grnsft/if@1.0.0" "@grnsft/if-plugins@0.3.2" "@grnsft/if-unofficial-plugins@0.3.1"
    - pip install --upgrade pip && pip install -e $CI_PROJECT_DIR/if-carmen
  script:
    - cd $CI_PROJECT_DIR/if-carmen/example-data && carbon-daemon
  artifacts:
    paths:
      - if-carmen/example-data/output/
    expire_in: 1 week

Exécutez-le et téléchargez l'artefact pour obtenir votre premier rapport carbone.

En pratique

Imaginez une équipe qui exécute des centaines de jobs de pipeline chaque jour. Elle ajoute Eco CI en un après-midi, avec quelques lignes dans .gitlab-ci.yml et un badge dans le README. Son premier rapport hebdomadaire fait apparaître un constat inattendu : sa suite de tests d'intégration représente une part disproportionnée des émissions totales du pipeline, plus que tout autre type de job.

Le coupable n'est pas les tests eux-mêmes, mais leur configuration : chaque exécution réinstalle l'intégralité de ses dépendances à partir de zéro. Mettre en cache la couche des dépendances peut réduire à la fois la durée d'exécution des jobs de test et leur empreinte carbone. Aucune nouvelle infrastructure est nécessaire, ni aucune décision d'architecture. Il suffit d'ajouter une simple ligne de configuration du cache.

Six semaines plus tard, l'équipe exécute Carmen sur son cluster de préproduction et découvre un problème d'un autre ordre : un service de traitement de données hérité d'une fonctionnalité obsolète tourne toujours, à vide, et consomme du carbone incorporé et opérationnel pour des tâches qui n'ont plus lieu d'être. L'équipe n'a alors qu'à ouvrir un ticket pour terminer le service.

Aucun de ces correctifs n'a exigé d'initiative dédiée au développement durable, il suffisait juste de les rendre visibles. La plupart des pertes carbone ne sont pas intentionnelles : elles sont invisibles, et c'est précisément ce qu'Eco CI et Carmen visent à corriger.

Peu d'efforts, un vrai retour sur investissement

Cette stratégie Green DevOps demande peu d'efforts, car elle s'intègre à des pipelines que vous exécutez déjà. Elle offre également un vrai retour sur investissement : les données s'accumulent, que ce soit sous forme de socle de conformité ou de facture CI réduite.

Les petits chiffres permettent d’établir une base de référence
Au niveau d'une entreprise, les émissions des pipelines représentent probablement un chiffre négligeable. Mais la mesure ne concerne pas uniquement une part dans le total. Il s'agit de construire les données, les outils et la culture dont vous aurez besoin à mesure que les exigences en matière de rapports sur les émissions évoluent. Les équipes qui mesurent dès aujourd'hui leur empreinte carbone disposeront déjà de bases de référence et d'habitudes internes le jour venu, au lieu de partir de zéro sous la pression.

Le processus s'intègre aux pipelines dont vous disposez déjà
Eco CI se résume à quelques lignes et un script Bash. Il ne déclenche pas d'infrastructure supplémentaire et n'ajoute pas de latence significative. Carmen s'exécute comme un job distinct et non bloquant. Aucun des deux n'est situé sur votre chemin critique. Si votre pipeline peut exécuter une vérification de linting, il peut exécuter une mesure de l'empreinte carbone.

Le retour sur investissement se reflète aussi dans vos indicateurs FinOps
Un code économe en carbone est souvent aussi un code plus rapide et moins coûteux. Les pipelines surdimensionnés consomment du temps de développement et du budget cloud avant de consommer du carbone. Le cache qui réduit les émissions peut également contribuer à réduire votre facture CI. Le dimensionnement optimal des runners représente un atout tant pour le FinOps que pour le développement durable, et vous n'avez pas besoin de le présenter comme une initiative environnementale pour en tirer profit.

Une perspective plus large

La conscience de son empreinte carbone devient une exigence professionnelle pour l'ingénierie, et non plus un simple atout. Des réglementations comme la directive concernant la publication d'informations en matière de durabilité par les entreprises obligent les grandes entreprises à publier les émissions générées tout au long de leur chaîne de valeur, y compris celles liées à l'usage du cloud. Les entreprises interrogent de plus en plus leurs fournisseurs sur leurs pratiques en matière de développement durable lors des processus d'achat.

Vous n'avez pas besoin d'attendre une obligation réglementaire pour vous lancer : ajoutez Eco CI à un pipeline, puis introduisez Carmen pour obtenir une vision au niveau de l'infrastructure.

Pour aller plus loin

• Vue d'ensemble du développement durable CI/CD
• Intégration d'Eco CI
• Intégration de Carmen

GitLab 19.2 comble cette lacune avec la disponibilité générale des flows personnalisés : des workflows alimentés par l'IA que vous définissez une seule fois, déclenchés par des événements GitLab natifs et exécutés dans un pipeline CI/CD. Un schéma de pipeline auto-correctif tel que analyser un test échoué → générer un correctif → effectuer un commit → notifier l'équipe devient ainsi un workflow que la plateforme peut exécuter de bout en bout.

Par ailleurs, les flows par défaut ne se déclenchent plus uniquement depuis un bouton, une mention ou une attribution. Désormais, lorsque votre requête dans GitLab Duo Agentic Chat correspond à une tâche spécifique (implémenter une modification, réviser une merge request, corriger un pipeline défaillant), GitLab Duo recommande le flow approprié, vous approuvez le transfert et suivez son avancement directement depuis la conversation.

La livraison logicielle agentique va au-delà du simple échange de messages. Les équipes encodent les séquences en lesquelles elles ont déjà confiance, les déclenchent depuis des événements ou le chat, et conservent la main sur les approbations plutôt que sur chaque étape intermédiaire.

Pourquoi la livraison logicielle multi-étapes reste manuelle

Les démonstrations agentiques privilégient les étapes isolées. Le travail de livraison réel est une chaîne : rassembler le contexte, modifier le code, ouvrir une merge request, attendre la CI, puis répondre aux retours de revue. Sans flows, chaque maillon de cette chaîne implique qu'une personne clique, copie-colle ou mémorise des étapes spécifiques.

Construire ces chaînes semblait provisoire tant que les flows personnalisés au sein de GitLab Duo Agent Platform étaient encore en phase de maturation. Les équipes différaient l'encodage des séquences en lesquelles elles avaient déjà confiance, tels que les pipelines auto-correctifs, « implémenter ce ticket » et les suivis pilotés par des événements, car la disponibilité en production et la couverture des événements n'étaient pas encore au rendez-vous.

Ce que les flows agentiques changent pour les équipes d'ingénierie

• Automatisez les séquences en lesquelles vous avez déjà confiance. Les flows personnalisés exécutent des tâches en plusieurs étapes sur plusieurs projets, déclenchés par des événements GitLab avec lesquels vous travaillez déjà : mentions, attributions, pipelines, cycle de vie des merge requests, modifications d'éléments de travail, et bien plus encore. Ils s'exécutent sous une identité composite, de sorte que les accès restent délimités et les actions traçables.
• Lancez des tâches spécialisées depuis le chat. Demandez à Agentic Chat d'utiliser le flow Developer pour implémenter une tâche, le flow Code Review pour réviser une merge request, ou le flow Fix CI/CD Pipeline pour diagnostiquer et corriger un pipeline en échec. Approuvez le transfert, puis continuez à travailler pendant que la progression s'affiche en ligne.
• Gardez le contrôle sur la revue automatique. Dans GitLab 19.2, les règles d'exclusion vous permettent d'ignorer la revue automatique pour les merge requests créées par des bots ou correspondant à des schémas de branches pour lesquelles vous ne souhaitez pas consommer de crédits. Les instructions de revue personnalisées définissent les critères de la revue, de sorte que vous choisissez non seulement quelles merge requests sont révisées, mais aussi comment.

Découvrez les flows agentiques GitLab Duo en action :

Comment fonctionnent les flows ?

Flows personnalisés. Créez-en un depuis un projet ou le catalogue d'IA, choisissez la visibilité, activez-le là où vous en avez besoin et associez un déclencheur afin que les événements GitLab appropriés le lancent. Vous pouvez ajouter des points de contrôle nécessitant une intervention humaine aux étapes sensibles. Dans la version 19.2, les flows personnalisés intègrent également un déclencheur « changement de statut d'un élément de travail » et une activation groupée pour les flows publics sur jusqu'à 100 projets. À l'avenir, un flow Creation Agent est prévu dans la roadmap, afin que les équipes puissent décrire un flow en langage naturel et obtenir une définition exécutable, sans avoir à rédiger manuellement le schéma complet au préalable.

Flows par défaut dans Agentic Chat. Lorsque votre requête correspond à une tâche spécialisée, elle peut être transmise à un flow par défaut. Vous donnez votre accord avant toute exécution, et restez dans la conversation pendant que le flow s'exécute. C'est là toute la différence avec un chat qui se contente uniquement de répondre : les étapes multiples sont prises en charge sans que vous ayez à quitter GitLab.

Automatisation mise à jour pour le flow Code Review. Les règles d'exclusion empêchent les merge requests pilotées par des bots ou hors périmètre de consommer des cycles de revue de code non souhaités. De plus, les instructions de revue personnalisées définissent ce que la qualité signifie pour votre équipe, de sorte que l'extension de l'automatisation ne revient pas à réviser tout de la même façon.

Commencez à encoder les séquences que vous exécutez déjà

Les flows personnalisés sont désormais en disponibilité générale, et les flows par défaut peuvent désormais être lancés depuis Agentic Chat, qui achemine votre requête vers le flow spécialisé approprié au fil de votre description, traduisant les séquences de livraison logicielle agentique en lesquelles votre équipe a déjà confiance en une automatisation prévisible.

Vous souhaitez en savoir plus ? Consultez notre documentation sur les flows personnalisés et les flows par défaut. Un point à anticiper : les flows pilotés par des événements consomment des crédits en fonction des tâches effectuées. Testez-les sur quelques projets avant de les déployer à grande échelle.

À l'instar des autres fonctionnalités de GitLab Duo Agent Platform, vous pouvez accéder aux flows agentiques grâce à un essai gratuit de GitLab Duo Agent Platform. Sur l'édition Gratuite, vous pouvez vous inscrire en quelques étapes simples.

Vous utilisez déjà GitLab Premium ou GitLab Ultimate ? Commencez par activer GitLab Duo Agent Platform et utilisez les GitLab Credits inclus dans votre abonnement.

Le flow Security Review, désormais disponible en version bêta publique, examine les modifications de code comme le ferait un ingénieur en sécurité. Il analyse l'intention au lieu de comparer des signatures, afin de détecter les failles logiques avant qu'elles n'atteignent l'environnement de production. Il s'agit d'une avancée majeure pour identifier les failles dangereuses que les scanners manquent habituellement.

Les limites des scanners basés sur des modèles

Les vulnérabilités applicatives les plus préjudiciables semblent souvent correctes ligne par ligne, mais enfreignent un contexte que le code ne contient pas, comme votre modèle d'autorisation, vos règles de sensibilité des données et vos workflows prévus. Voici trois des catégories de vulnérabilités les plus courantes :

Accès et autorisation : la possibilité pour un utilisateur de lire ou de modifier une ressource est définie par votre modèle d'autorisation, et non par une construction du langage. La Broken Object Level Authorization (faille d'autorisation donnant accès aux données d'un autre utilisateur en modifiant un identifiant) figure en tête du classement OWASP API Security Top 10 depuis 2019.

Exposition des données : sérialiser un objet et le renvoyer est un code courant, d'apparence correcte. La question de savoir s'il divulgue des informations dépend des champs sensibles et de leurs destinataires, des éléments propres à votre domaine, et non à votre syntaxe.

Flux de contrôle et workflow : les failles de logique métier et les conditions de concurrence surviennent lorsque des opérations valides s'exécutent dans le mauvais ordre, se répètent de façon inattendue ou sont manipulées. Exemples : processus de paiement contournable, état réactivé en raison d'une condition de concurrence ou paramètre modifié pour changer un prix.

Jusqu'à présent, la détection de ces failles nécessitait une revue de sécurité manuelle (coûteuse à mettre à l'échelle pour chaque merge request) ou des tests de pénétration et des programmes de bug bounty, qui interviennent trop tard. Il en résulte un écart croissant entre le rythme de développement et la rapidité avec laquelle l'expertise en sécurité peut être mise à profit.

Intégrer une évaluation de sécurité à chaque merge request

Le flow Security Review, disponible par défaut sur GitLab Duo Agent Platform, comble cet écart en analysant la finalité de votre code. Il détecte précisément les catégories de failles décrites ci-dessus : Broken Object Level Authorization et Broken Function Level Authorization (faille d'autorisation donnant à un utilisateur un accès à des fonctionnalités qui devraient lui être interdites), absence d'autorisation sur les opérations modifiant l'état, divulgation d'informations, attributions en masse, erreurs de logique métier et conditions de concurrence dans les workflows avec état.

Il complète les scanners traditionnels et l'analyse humaine sans les remplacer, et examine le code au moment même où une modification est apportée, lorsque la correction est la moins coûteuse. L'équipe de sécurité applicative de GitLab a utilisé le flow Security Review sur l'ensemble de ses merge requests internes tout au long de son développement.

Découvrez le flow Security Review en action :

Fonctionnement

Lorsque votre merge request est prête, demandez une revue à Duo Security Review, comme vous le feriez auprès d'une personne. Le flow Security Review analyse le diff en contexte : les fichiers d'origine, les lignes modifiées, la discussion de la merge request et le code associé. Son raisonnement est optimisé pour la précision, et une passe de validation indépendante examine chaque résultat afin de filtrer les faux positifs probables.

Les résultats apparaissent sous forme de fils de discussion sur les lignes concernées, accompagnés d'un résumé dans une note interne. Sur les projets publics, ils sont limités à la note interne afin que les détails de sécurité ne soient pas exposés.

Chaque résultat est accompagné du contexte dont les relecteurs ont besoin :

• Type de vulnérabilité, avec une référence CWE
• Sévérité : critique, élevée, modérée ou faible
• Niveau : Niveau 1 (Exploitable), Niveau 2 (Faille logique) ou Niveau 3 (Problème de conception)
• Une explication en langage clair du problème
• Une correction suggérée, lorsqu'elle est disponible

La sévérité détermine l'état du relecteur : un résultat critique ou élevé définit l'état sur Demander des modifications, tandis que les résultats modérés ou faibles donnent lieu à un Commentaire. Le flow n'approuve jamais, même lorsqu'il ne trouve rien, la décision finale revient toujours à un humain.

À partir de là, mentionnez le compte de service GitLab Duo Security Review de votre organisation dans un fil de discussion pour poser une question, discuter d'une correction ou contester un résultat. Résolvez chaque résultat en appliquant la correction sous forme de suggestion de merge request standard, en le rejetant comme faux positif ou en acceptant le risque. Après avoir effectué un commit de vos corrections, demandez une nouvelle revue pour vérifier ce qui a changé.

Lancez votre premier flow Security Review

Le flow Security Review est en version bêta publique pour les clients GitLab Ultimate. Il est disponible sur GitLab.com, GitLab Self-Managed et GitLab Dedicated.

Découvrez comment démarrer en consultant notre documentation dédiée au flow Security Review.

Vous pouvez accéder au flow Security Review grâce à un essai gratuit de GitLab Duo Agent Platform. Vous êtes déjà abonné à GitLab Ultimate ? Activez GitLab Duo Agent Platform et utilisez les GitLab Credits inclus dans votre abonnement.

Le coût varie en fonction de la complexité du diff et du modèle sélectionné ; testez-le sur quelques merge requests avant de le déployer à grande échelle. La tarification pourra être mise à jour lors de la disponibilité générale.

Partagez vos retours dans notre ticket dédié à cette fonctionnalité, afin que vos contributions orientent nos développements.

Une IA agentique dans le terminal qui ne comprend que le code ne peut pas vous aider dans ces situations. Un assistant autonome ne connaît pas vos agents sur l'ensemble du cycle de vie logiciel, vos autorisations sur les nombreux projets de votre organisation, ni le contexte spécifique d'un projet que vous avez déjà configuré dans GitLab.

C'est ce qui change avec GitLab 19.2. GitLab Duo CLI est désormais en disponibilité générale et intègre GitLab Duo Agentic Chat directement dans votre terminal. Contrairement aux outils externes, il connaît déjà votre projet, vos pipelines et votre configuration d'agents. Vous pouvez l'utiliser de manière interactive lorsque vous explorez et développez, ou en mode headless lorsque vous souhaitez l'exécuter dans un job ou un script.

Ainsi, les équipes de développement restent dans le shell où l'échec s'est produit, et leur travail se poursuit entre le terminal, l'interface utilisateur et l'éditeur. Les équipes plateforme gèrent le déploiement comme tout le reste sur GitLab, et l'assistance agentique couvre enfin davantage du cycle de livraison que la simple rédaction d'une fonction.

Pourquoi l'IA agentique dans le terminal s'est limitée au code

Les outils agentiques ont d'abord évolué là où les démonstrations sont les plus convaincantes : la modification de fichiers. Le cycle de vie après le commit est plus complexe et plus opérationnel. Lorsque l'échec concerne un pipeline, une dépendance ou une configuration CI, le contexte se trouve dans GitLab, et non dans l'ensemble d'apprentissage d'un agent de codage ou dans son contexte local.

Les équipes qui ont tenté de combler cet écart avec des assistants CLI génériques ont rencontré d'autres obstacles : aucun contrôle d'administration partagé, aucun diagnostic MCP/configuration aligné sur la plateforme et aucun modèle d'identité unique avec le reste du cycle de vie logiciel agentique. Le travail agentique dans le terminal est resté cantonné au codage, au lieu d'apporter son aide sur l'ensemble du processus de livraison.

Avantages de GitLab Duo CLI en disponibilité générale pour les équipes

• Restez dans le terminal pour les tâches qui s'y trouvent déjà. Explorez l'architecture du code, construisez et refactorisez, analysez les échecs de pipeline, optimisez votre CI/CD et accomplissez des tâches multi-étapes sans avoir à ouvrir le navigateur à chaque fois que vous avez besoin d'une réponse.
• Reprenez là où vous vous êtes arrêté, quelle que soit la surface. Les sessions sont synchronisées entre GitLab Duo CLI, l'interface utilisateur de GitLab et les extensions d'éditeur. Commencez une conversation dans le navigateur et continuez-la simplement dans votre shell.
• Planifiez d'abord, puis construisez. Le mode interactif fonctionne comme Agentic Chat : le mode Planification explore l'environnement sans rien modifier, tandis que le mode Build applique les modifications. Vous avez besoin d'une exécution sans surveillance ? Le mode headless s'intègre aux jobs CI et aux scripts.
• Activez GitLab Duo CLI quand vous êtes prêt. GitLab Duo CLI fonctionne sur GitLab.com, GitLab Self-Managed et GitLab Dedicated. Sur GitLab Self-Managed et GitLab Dedicated, les administrateurs peuvent activer ou désactiver l'accès à l'instance. Où que vous l'utilisiez, les équipes de développement peuvent exécuter /doctor pour vérifier leur configuration et /mcp pour consulter leur configuration MCP.

Découvrez GitLab Duo CLI en action :

Fonctionnement de GitLab Duo CLI

La méthode la plus simple consiste à utiliser GitLab CLI : exécutez glab duo cli, et glab se charge de l'authentification à votre place. Vous pouvez également installer et exécuter duo en tant qu'outil autonome à l'aide d'un jeton d'accès personnel. Ces deux configurations prennent en charge les mêmes modes et fonctionnalités.

• Mode interactif : discutez dans le terminal et approuvez les outils avant toute exécution. Explorez le code source, planifiez un correctif, puis passez en mode Build lorsque vous êtes prêt à effectuer des modifications.
• Mode headless : exécution non interactive pour les runners, les scripts et l'automatisation. Utilisez glab duo cli run --goal ou duo run --goal.

Par exemple, lorsqu'un pipeline échoue, posez votre question depuis le même shell :

$ glab duo cli
> The pipelines in MR 23 are failing. Please help me fix them.

GitLab Duo CLI examine la situation, identifie ce qui s'est mal passé et propose des modifications que vous pouvez examiner avant de les appliquer. Il suit vos instructions personnalisées (chat-rules.md, AGENTS.md, SKILL.md) à mesure que vous évoluez, et vous pouvez enrichir ses sessions interactives avec des commandes slash personnalisées.

Commencez à utiliser GitLab Duo CLI dès aujourd'hui

Consultez la documentation sur GitLab Duo CLI pour l'installation et l'authentification. Si vous utilisez déjà GitLab CLI, commencez par glab duo cli.

Vous souhaitez en savoir plus sur GitLab ? Démarrez un essai gratuit de GitLab Duo Agent Platform. Vous utilisez déjà GitLab Premium ou GitLab Ultimate ? Activez GitLab Duo Agent Platform et utilisez les GitLab Credits inclus dans votre abonnement.

La fonctionnalité Dependency Scanning Auto-Remediation, désormais en version bêta, comble cet écart en matière de sécurité. Lorsque l'analyse des dépendances détecte un paquet vulnérable, GitLab ouvre une merge request pour le mettre à jour, utilise l'IA pour corriger les changements cassants et itère jusqu'à ce que votre pipeline soit opérationnel, chaque modification étant régie par vos portes logicielles et votre piste d'audit existantes.

Résultat : les backlogs de sécurité diminuent sans mobiliser les équipes de développement, les vulnérabilités de sévérité élevée sont corrigées dans les délais de conformité, et les mises à niveau cassantes arrivent sous forme de merge requests prêtes à être approuvées.

Pourquoi le backlog de dépendances ne cesse de croître

Les composants vulnérables et obsolètes constituent un risque de longue date de l'OWASP TOP 10 et une part importante des backlogs de corrections. Le traitement des failles détectées est un travail lent et manuel qui empiète sur la livraison de fonctionnalités, si bien que des vulnérabilités de sévérité élevée restent non résolues au-delà des délais de 30 jours imposés par les normes PCI-DSS et FedRAMP. Par ailleurs, même dans des bibliothèques établies, l'ingénierie d'exploits assistée par l'IA accélère la divulgation et les attaques.

Près d'une mise à jour de dépendance sur huit introduit un changement cassant, et nombre de celles qualifiées de rétrocompatibles font tout de même échouer le build. Les équipes ont tendance à reporter les changements complexes, et plus ces vulnérabilités persistent, plus elles deviennent sérieuses.

Du backlog à la correction, sans mobiliser les équipes de développement

La fonctionnalité Dependency Scanning Auto-Remediation transforme les dépendances vulnérables en corrections examinées et prêtes à être fusionnées, afin que votre équipe puisse traiter les failles détectées plus rapidement et consacrer moins de temps à la résolution des changements cassants. Les équipes profitent ainsi d'améliorations en termes de rapidité, d'effort et de contrôle :

• Réduisez le backlog des dépendances. Les dépendances vulnérables sont mises à niveau dès leur détection. Ainsi, les failles de sécurité ne s'accumulent pas et les problèmes de sévérité élevée respectent les délais de conformité.
• Récupérez le temps perdu à réécrire les changements cassants. Lorsqu'une mise à jour fait échouer le build, GitLab Duo Agent Platform effectue un commit d'une correction pour que les équipes de développement examinent une modification fonctionnelle au lieu de la créer à partir de zéro.
• Maintenez chaque modification sous contrôle. La correction automatique prépare la modification, mais rien n'est fusionné tant qu'un relecteur ne l'a pas approuvée, et chaque merge request fournit une piste d'audit avec les changements et les approbateurs.

Corriger rapidement les vulnérabilités, même lorsqu'elles nécessitent des modifications de code

La fonctionnalité Dependency Scanning Auto-Remediation met à niveau les dépendances et corrige les changements cassants en deux étapes :

La mise à niveau automatisée de la version des dépendances s'exécute automatiquement lorsque le scan détecte une dépendance vulnérable : une merge request est alors ouverte pour la mettre à niveau vers la version corrigée la plus proche. Lorsqu'aucune correction éligible n'existe, la faille détectée reste dans votre rapport de vulnérabilités jusqu'à ce qu'un chemin de mise à niveau sûr soit disponible. Chaque merge request est attribuée à un compte de service dédié pour que chaque modification soit traçable jusqu'à une identité distincte.

La résolution agentique des changements cassants prend en charge les cas difficiles lorsqu'une mise à niveau de version introduit des changements cassants. Si le pipeline d'une merge request de correction échoue parce que la nouvelle version fait échouer votre projet, GitLab Duo Agent Platform analyse automatiquement les erreurs du pipeline, le changelog de la dépendance et la façon dont votre code utilise cette dépendance. Ensuite, dans la même merge request, il effectue des commits pour corriger votre code afin que votre projet soit aligné sur la version mise à jour. S'il ne parvient pas à faire passer le pipeline, il s'arrête et publie ses conclusions dans la merge request pour que vous puissiez prendre le relais. Les écosystèmes pris en charge incluent Bundler, Maven, Gradle, ainsi que les principaux gestionnaires de paquets Python et JavaScript/TypeScript, avec Rust et Go prévus dans les mois à venir.

La fonctionnalité Dependency Scanning Auto-Remediation ne fusionne jamais de manière autonome. Pour accélérer la revue, chaque merge request précise la vulnérabilité qu'elle traite, la version vers laquelle elle migre, et le code que GitLab Duo Agent Platform a suggéré pour maintenir le build opérationnel : les approbateurs n'ont ainsi pas à reconstituer la modification par eux-mêmes.

Fonctionnement de la fonctionnalité Dependency Scanning Auto-Remediation

La fonctionnalité Dependency Scanning Auto-Remediation s'exécute automatiquement lorsque l'analyse des dépendances basée sur les nomenclatures logicielles (SBOM) détecte une dépendance vulnérable disposant d'une correction disponible. Il est également possible de l'utiliser pour une faille individuelle depuis le rapport de vulnérabilités. GitLab ouvre alors une merge request de correction qui suit votre processus habituel de revue et de merge ; lorsque la résolution agentique des changements cassants est activée et que la mise à niveau de version fait échouer le pipeline, GitLab Duo Agent Platform tente de corriger les modifications de code résultantes dans cette même merge request.

Des garde-fous intégrés empêchent cette fonctionnalité de devenir source de faux positifs. Des périodes de stabilisation évitent que les projets très actifs ne déclenchent une correction à chaque pipeline, et GitLab ne recrée pas une merge request fermée à moins qu'une correction plus récente ne soit disponible.

Configurez la fonctionnalité selon votre tolérance au risque. Vous pouvez cibler des vulnérabilités de n'importe quelle sévérité, du niveau faible au niveau critique, limiter l'amplitude des mises à niveau autorisées (correctif, mineur ou majeur), et stocker les paramètres dans des profils de configuration au niveau du projet ou du groupe (via l'API pendant la version bêta).

La fonctionnalité s'exécute via le pipeline de votre organisation et hérite ainsi de vos contrôles d'accès et de vos portes d'approbation existants. Vous disposez également d'un enregistrement complet et auditable des changements, des approbateurs et des motifs.

Découvrez la fonctionnalité Dependency Scanning Auto-Remediation en action :

Commencez à réduire votre backlog de dépendances dès aujourd'hui

La fonctionnalité Dependency Scanning Auto-Remediation est en version bêta publique. Elle est disponible sur GitLab.com et déployée progressivement sur GitLab Self-Managed et GitLab Dedicated.

Prêt à l'essayer ? Consultez la documentation relative à la fonctionnalité Dependency Scanning Auto-Remediation.

La mise à niveau automatisée de la version des dépendances est incluse dans GitLab Ultimate sans coût supplémentaire.

Vous pouvez accéder à la résolution agentique des changements cassants avec un essai gratuit de GitLab Duo Agent Platform. Vous êtes déjà abonné à GitLab Ultimate ? Activez GitLab Duo Agent Platform et utilisez les GitLab Credits inclus dans votre abonnement.

Vous avez des retours à partager ? Communiquez-nous vos commentaires dans cet epic.

Le développement agentique permet aux équipes de développement de gagner en rapidité. Le véritable défi pour les entreprises est de transformer cette rapidité en retour sur investissement concret. Des commits plus rapides ne constituent qu'une partie de l'équation lorsqu'il s'agit de livrer des logiciels prêts pour la mise en production. Un ingénieur système senior dans le secteur des assurances et des services financiers l'a exprimé clairement : la revue de code qui prenait auparavant des heures ne prend désormais qu'une fraction de ce temps, avec 80 à 90 % de la génération de code prise en charge par la plateforme.

Pour aider les dirigeants à comprendre les retours sur investissement réalisables avec GitLab, Forrester a interrogé quatre décideurs dans les secteurs des services financiers, du développement logiciel, du divertissement et des assurances, qui utilisent GitLab Duo Agent Platform en production. Leurs expériences ont ensuite été regroupées au sein d'une seule et même organisation composite : une entreprise mondiale générant 3 milliards de dollars de chiffre d'affaires annuel et comptant 3 000 employés, dont le nombre d'utilisateurs de GitLab Duo Agent Platform est passé de 150 à 250 en trois ans.

Évaluer les coûts au regard du ROI

L'étude fait preuve de transparence quant à l'investissement requis : sur trois ans, les coûts ajustés au risque s'élèvent à 1,3 million de dollars en crédits de consommation et à 589 000 dollars en frais de mise en œuvre et de gestion courante, y compris la main-d'œuvre interne pour le programme pilote, la formation et l'assistance. Face à 9,4 millions de dollars de bénéfices, ces chiffres constituent la base du ROI de 400 % et de la valeur actuelle nette de 7,5 millions de dollars.

Avant : tâches manuelles, interruptions et goulots d'étranglement dans la revue de code

Avant d'adopter GitLab Duo Agent Platform, les personnes interrogées décrivaient des goulots d'étranglement bien connus : les équipes étaient dépendantes de processus manuels, de l'expertise des ingénieurs seniors et d'un partage de connaissances informel pour développer, réviser et sécuriser les logiciels. Les nouvelles recrues ne pouvaient pas débloquer leur travail sans solliciter un ingénieur senior. Les correctifs de sécurité s'accumulaient jusqu'à ce que l'une des rares personnes disposant du contexte adéquat ait le temps de les examiner. La revue de code, plutôt que l'écriture du code elle-même, constituait souvent un frein à la mise en production. Ce sont ces dépendances que l'organisation composite de Forrester a identifiées, résolues et évaluées.

Après : intégration accélérée, migration, correction des vulnérabilités et gain de temps

Forrester a quantifié quatre domaines où l'organisation composite a réalisé des bénéfices, qui ont totalisé 9,4 millions de dollars de bénéfices ajustés au risque pour 1,9 million de dollars de coûts :

L'intégration des nouveaux développeurs a connu une accélération de 80 %. Au lieu de mobiliser un collaborateur, les nouveaux membres de l'équipe ont utilisé le chat agentique intégré à leurs IDE et à leurs dépôts pour obtenir le contexte nécessaire et se familiariser par eux-mêmes avec des codes sources et des conventions qui leur étaient inconnues, soit une économie de 582 000 dollars.

Une migration prévue sur huit mois s'est achevée en deux mois, soit une réduction de 75 % du calendrier. L'organisation composite a utilisé GitLab Duo Agent Platform pour diagnostiquer les échecs de pipeline et résoudre les problèmes en temps réel lors d'une migration à grande échelle d'un environnement GitLab sur site vers GitLab SaaS, ce qui a permis d'économiser 157 000 dollars en coûts de main-d'œuvre.

Les ingénieurs en sécurité et en assurance qualité ont récupéré 40 % de leur temps. Les ingénieurs en assurance qualité et en sécurité ont réduit leur temps de correction grâce aux explications contextuelles et aux correctifs suggérés par GitLab Duo Agent Platform. Ainsi, leur dépendance vis-à-vis des ingénieurs seniors a diminué, ce qui a permis une économie de main-d'œuvre de 1,3 million de dollars sur trois ans.

Chaque développeur a pu récupérer 20 % de son temps hebdomadaire pour développer des fonctionnalités. Le chat agentique et les agents d'IA ont pris en charge la revue de code, les tests et le débogage qui empiétaient auparavant sur le temps de développement. Ce gain cumulé a atteint 7,4 millions de dollars pour l'ensemble des équipes de développement à mesure que l'adoption s'est généralisée au cours de ces trois années.

Forrester a également identifié des bénéfices qu'il n'a pas quantifiés dans cette étude, notamment les économies réalisées grâce à la consolidation des outils de développement alimentés par l'IA redondants, l'amélioration de la satisfaction des équipes de développement et un meilleur partage des connaissances entre les équipes.

« Les releases de fonctionnalités qui prenaient auparavant quelques semaines sont désormais réalisées en quelques jours. Nous observons donc une forte augmentation de la productivité des équipes. » — Responsable de l'automatisation dans une société de services financiers

Des retours cumulés pour livrer des logiciels sécurisés plus rapidement

Les personnes interrogées n'ont pas seulement codé plus vite : elles ont livré des fonctionnalités en quelques jours au lieu de plusieurs semaines, corrigé des vulnérabilités en quelques minutes, intégré de nouvelles recrues en un temps record et réduit une migration de huit à deux mois. Cette étude met en évidence que si le développement agentique accélère la production individuelle, le retour sur investissement ne se démultiplie que lorsque cette rapidité s'appuie sur une infrastructure conçue pour l'ensemble du cycle de vie logiciel.

Si vous élaborez actuellement une analyse de rentabilité en faveur d'une infrastructure agentique dédiée à l'ingénierie logicielle au sein de votre organisation, cette étude vous offre un framework qui s'appuie sur les actions concrètes menées par quatre entreprises, afin que vous puissiez transformer vos prévisions en réalité.

Consultez l'étude Total Economic Impact™ de Forrester consacrée à GitLab Duo Agent Platform pour découvrir la méthodologie complète, le modèle financier et les résultats des entretiens.

Cette étude a été commanditée par GitLab et réalisée par Forrester Consulting. Elle n'est pas destinée à être utilisée comme analyse concurrentielle. Forrester ne formule aucune hypothèse quant au ROI potentiel que d'autres organisations pourraient obtenir ; les résultats sont représentatifs des expériences des organisations interrogées et de l'organisation composite qu'elles ont permis de constituer. GitLab a fourni les noms des clients pour les entretiens, mais n'y a pas participé, et Forrester conserve le contrôle éditorial sur les conclusions de l'étude.

Qu'est-ce que l'accès restreint ?

L'accès restreint est une fonctionnalité de gestion des sièges disponible sur GitLab.com et GitLab Self-Managed. Lorsqu'elle est activée et que tous les sièges sous licence sont déjà utilisés, GitLab empêche l'ajout de nouveaux utilisateurs facturables.

Les organisations peuvent ainsi éviter une augmentation imprévue du nombre de sièges avant le renouvellement et maintenir une utilisation des sièges en adéquation avec le nombre de sièges achetés. L'accès restreint est conçu pour prévenir les futurs dépassements, et non pour corriger ceux qui existent déjà.

Les utilisateurs qui n'ont pas besoin d'accéder aux projets ou aux groupes, comme ceux qui s'authentifient via GitLab en tant que fournisseur OpenID Connect (OIDC), peuvent se voir attribuer le rôle Accès minimal (non facturable). Ces utilisateurs peuvent toujours s'authentifier sans utiliser de siège payant.

Aucun impact rétroactif sur les membres facturables existants

L'accès restreint s'applique uniquement aux utilisateurs futurs. Si vous l'activez sur un groupe ou une instance qui dépasse déjà la limite de sièges, GitLab ne rétrograde pas, ne supprime pas et ne bloque pas les membres facturables existants. Les abonnements actuels restent inchangés. En cas de dépassement, les administrateurs doivent tout de même restreindre l'utilisation dans les limites de l'abonnement souscrit, en supprimant des membres facturables ou en achetant des sièges supplémentaires.

Une fois l'utilisation des sièges régularisée, l'accès restreint contribue à empêcher toute nouvelle augmentation supplémentaire des coûts facturables au-delà de cette limite.

Meilleure intégration de l'accès restreint à votre fournisseur d'identité

Un volet majeur des récentes améliorations a porté sur le comportement de l'accès restreint face au provisionnement basé sur l'identité.

Lorsque l'accès restreint est activé et qu'aucun siège n'est disponible, les utilisateurs provisionnés via SAML, SCIM ou LDAP ne sont plus ajoutés directement à des rôles facturables. À la place, GitLab leur attribue le rôle Accès minimal (non facturable). La synchronisation peut ainsi se poursuivre sans provoquer immédiatement un dépassement facturable.

Ce comportement est particulièrement utile pour les organisations qui s'appuient sur le provisionnement automatisé et souhaitent renforcer le contrôle des coûts sans renoncer à une gestion centralisée des identités.

Si vous utilisez GitLab comme fournisseur OIDC et que certains utilisateurs n'ont besoin que d'une authentification, sans accès aux projets ou aux groupes, leur attribuer le rôle Accès minimal au niveau du groupe principal reste une pratique pertinente. Ces utilisateurs ne consomment pas de siège facturable, et les utilisateurs disposant uniquement du rôle Accès minimal peuvent toujours être réactivés, même quand aucun siège n'est disponible.

Plus de dépassements invisibles par les utilisateurs inactifs

GitLab peut désactiver automatiquement les utilisateurs restés inactifs pendant une durée configurable pour libérer des sièges. Auparavant, lorsque ces utilisateurs se reconnectaient via OIDC ou l'authentification unique (SSO), ils pouvaient être réactivés de manière invisible en tant qu'utilisateurs facturables. Ils contournaient ainsi les restrictions d’accès et provoquaient des dépassements de licence.

Désormais, quand l'accès restreint est activé et qu'aucun siège n'est disponible, les utilisateurs inactifs qui se reconnectent sont placés en attente d'approbation. Leurs adhésions aux groupes et aux projets sont conservées, et un administrateur peut les approuver dès qu'un siège se libère.

Des avertissements, bannières et notifications plus clairs

L'accès restreint est également plus simple à gérer au quotidien. Des améliorations récentes ont introduit davantage d'indications directement dans le produit, afin que les administrateurs puissent suivre ce qui se passera avant et après avoir atteint leur limite de sièges. Selon le cas, cela inclut :

• Des avertissements contextuels lors de la configuration de la synchronisation LDAP, des liens de groupe SAML ou du provisionnement SCIM pendant que l'accès restreint est actif
• Des états distincts au sein du produit lorsque la limite de sièges approche et lorsqu'elle est atteinte
• Des notifications par e-mail aux propriétaires de groupe ou aux administrateurs d'instance lorsque des utilisateurs se voient attribuer le rôle Accès minimal faute de sièges payants disponibles
• Une visibilité d'audit pour les événements de repli du rôle Accès minimal

L'objectif ne se limite pas à bloquer les nouveaux utilisateurs facturables : il s'agit aussi de faciliter la compréhension de ce comportement et sa gestion.

Le cache des paramètres de GitLab Self-Managed

Sur GitLab Self-Managed, les paramètres de l'application sont mis en cache pendant 60 secondes par défaut pour des raisons de performance.

Par conséquent, si vous basculez entre l'accès restreint et le plafond d'utilisateurs, certains changements d'interface ou comportements de contrôle des sièges peuvent ne pas apparaître immédiatement. Le cache se rafraîchit automatiquement, et les modifications seront visibles à ce moment-là. Si nécessaire, les administrateurs peuvent ajuster la durée de mise en cache.

Consultez notre documentation sur le cache des paramètres de l'application.

La différence entre l'accès restreint et le plafond d'utilisateurs

L'accès restreint et le plafond d'utilisateurs sont liés, mais ils répondent à des problèmes différents.

Le plafond d'utilisateurs place les nouveaux utilisateurs dans un processus d'approbation destiné aux administrateurs ou aux propriétaires de groupe, que des sièges soient encore disponibles ou non. L'accès restreint, lui, est directement lié au nombre de sièges sous licence et bloque les nouveaux ajouts facturables uniquement lorsqu'il ne reste plus de sièges.

Autrement dit, le plafond d'utilisateurs est un contrôle d'approbation. L'accès restreint est un contrôle de limite de sièges.

Les deux fonctionnalités ne peuvent pas être activées en même temps. Lorsque vous activez l'accès restreint, le plafond d'utilisateurs est automatiquement désactivé. Sur GitLab.com, passer du plafond d'utilisateurs à l'accès restreint peut également affecter les membres en attente, il est donc recommandé de consulter notre documentation relative à ce comportement avant d'effectuer tout changement.

Premiers pas

L'accès restreint est disponible sur GitLab.com et GitLab Self-Managed.

• Sur GitLab.com, les propriétaires de groupe peuvent l'activer via Paramètres > Général > Permissions et fonctionnalités du groupe > Contrôle des sièges > Accès restreint.
• Sur GitLab Self-Managed, les administrateurs peuvent l'activer via Admin > Paramètres > Général > Restrictions pour les nouveaux comptes utilisateurs > Contrôle des sièges > Accès restreint.
• Sur GitLab.com, l'accès restreint n'est pas disponible lorsque le groupe principal est partagé avec un groupe externe.

Votre équipe souhaite mieux maîtriser la croissance du nombre de sièges, éviter les mauvaises surprises liées à la facturation et disposer d'un modèle opérationnel plus clair pour le provisionnement et la réactivation ? Adoptez l'accès restreint dès maintenant.

Ressources

• Documentation sur l'accès restreint
• Documentation sur la gestion des sièges
• Documentation sur le cache des paramètres de l'application

Mais écrire du code n'est que la première étape. Il faut encore le ticket, la merge request, le pipeline CI/CD, la revue de code et la décision humaine finale de déployer la modification. Écrire du code et livrer des logiciels sont deux étapes distinctes, et cet écart devient d'autant plus évident à mesure que les agents de codage gagnent en rapidité.

C'est là que GitLab entre en jeu. Dans ce tutoriel, nous allons explorer trois cas d'utilisation avec Codex et GitLab Duo Agent Platform :

1. Corriger un bogue Rust WebSocket en local pour se lancer avec Codex
2. Enrichir le contexte avec le MCP de GitLab pour corriger le bogue Rust en adéquation avec les exigences du ticket
3. Utiliser Codex dans GitLab Duo Agent Platform en tant qu'agent externe pour traiter les retours de revue dans la merge request

Nous utilisons le projet Tanuki IoT Platform pour les trois cas d'utilisation. Le backend Rust de métriques fournit deux bogues pratiques sur lesquels travailler : un bogue de filtre de métriques WebSocket et un bogue de validation de l'API REST.

Prérequis

1. Codex dans le terminal, configuré et opérationnel.
2. Un projet GitLab avec des rapports de bogues et des propositions de fonctionnalités sous forme de tickets, par exemple le projet Tanuki IoT Platform.
3. Pour certains cas d'utilisation : le serveur MCP de GitLab et GitLab Duo Agent Platform avec des agents externes.
4. Pour coder : Cargo et le compilateur Rust, par exemple rustup.

Préparer le projet GitLab

Si vous souhaitez reproduire le workflow dans votre propre environnement, commencez par importer et cloner le projet, puis ouvrez Codex à la racine du dépôt :

1. Importez le projet Tanuki IoT Platform dans votre environnement GitLab, en incluant tous les tickets ouverts.
2. Clonez le projet dans votre environnement local et accédez-y.
3. Ouvrez un terminal et lancez Codex avec la commande codex.

git clone https://gitlab.example.com/examplegroup/tanuki-iot-platform.git
cd tanuki-iot-platform

codex

Posez une question dans le prompt pour en savoir plus sur la finalité du projet.

What is this project about?

La partie qui nous intéresse dans ce tutoriel est le stockage de métriques Rust situé dans le répertoire backend/. Les capteurs envoient des relevés via une API REST, et les tableaux de bord consomment les données en temps réel via des flux WebSocket. Le problème et le correctif sont ainsi faciles à identifier.

Premiers pas avec Codex et GitLab pour corriger un bogue du backend Rust

Dans ce scénario, un bogue se trouve dans le flux WebSocket en temps réel. Le backend prend déjà en charge le filtrage des métriques côté API REST, mais le flux WebSocket ne semble pas filtrer correctement par métrique. En guise de test, si nous nous abonnons à un capteur et une métrique spécifiques, nous recevons quand même d'autres métriques. Voici un test rapide dans le terminal pour confirmer le problème.

Démarrez le backend dans un premier terminal, en écoute sur le port 9090 :

PORT=9090 cargo run --manifest-path backend/rust-metrics-store/Cargo.toml

Ouvrez un client WebSocket dans un second terminal. Sur macOS, websocat est disponible via Homebrew : brew install websocat.

websocat 'ws://localhost:9090/ws?sensor=arduino-iot-collector&metric=temperature_celsius'

Envoyez maintenant deux métriques différentes pour le capteur arduino-iot-collector.

curl -s -X POST http://localhost:9090/api/metrics \
  -H 'Content-Type: application/json' \
  -d '{"sensor":"arduino-iot-collector","metric":"temperature_celsius","value":23.5}'

curl -s -X POST http://localhost:9090/api/metrics \
  -H 'Content-Type: application/json' \
  -d '{"sensor":"arduino-iot-collector","metric":"humidity_percent","value":61.2}'

Vous vous attendez à ne voir que temperature_celsius, mais le flux affiche aussi humidity_percent, ce qui confirme le bogue.

C'est à ce moment-là que nous confions le problème à Codex dans un nouveau prompt :

I need help with a backend change to add metric filtering to /ws so live streams can be narrowed to one metric.

Grâce à notre fichier AGENTS.md au sein de notre projet GitLab, Codex sait comment le backend Rust est structuré, quelles commandes exécuter et à quoi ressemblent les exigences de qualité du code.

Codex inspecte le code source Rust et identifie l'élément manquant. Le point de terminaison /ws comprend déjà un paramètre de requête capteur, mais il lui faut aussi un paramètre métrique optionnel. Codex met à jour la logique du gestionnaire, ajoute des tests et synchronise la documentation avec les modifications du code.

Après les modifications du code, Codex exécute le formatage, les tests et le build. Codex effectue ensuite une vérification finale avant de toucher à Git. À partir de là, nous pouvons lui demander de créer une branche, d'effectuer un commit et de pousser la modification.

Une fois la merge request créée, GitLab prend le relais pour les étapes suivantes du cycle de vie logiciel. Les pipelines CI/CD démarrent, le scan de sécurité s'exécute et la revue de code de GitLab Duo vérifie les modifications selon les exigences de style de code Rust.

Après le déploiement, nous relançons le test local et confirmons que le flux WebSocket n'émet désormais que la métrique demandée lorsque le capteur et la métrique sont tous deux fournis, puis nous publions les résultats dans la merge request.

Ce premier cas d'utilisation sert de référence : Codex reste proche du code et GitLab prend le relais dès que le correctif entre dans le cycle de vie de la merge request.

Voici un enregistrement détaillé de Codex, GitLab CI/CD et GitLab Duo Agent Platform en action :

Corriger le filtre de métriques WebSocket avec le MCP de GitLab et le contexte du cycle de développement

Dans notre premier cas d'utilisation, Codex pouvait voir le dépôt du projet. Mais il n'avait pas de visibilité sur le ticket GitLab, les exigences convenues, les notes d'implémentation, ni sur l'état de la merge request et du pipeline autour du travail en cours. Ce contexte réside dans GitLab, pas dans les fichiers locaux.

C'est là que le serveur MCP de GitLab entre en jeu.

Dans ce cas d'utilisation, le ticket existe déjà et il est détaillé à dessein. Il décrit le problème, inclut des exigences fonctionnelles et non fonctionnelles, et mentionne explicitement les tests ainsi que les mises à jour de README.md et AGENTS.md. Cela signifie que Codex n'a pas besoin que nous collions toutes ces informations dans le prompt. Il peut récupérer directement le ticket et travailler à partir de la même source de vérité qu'un développeur.

Configurer le serveur MCP de GitLab

Ajoutez ensuite le serveur MCP de GitLab à Codex. Assurez-vous qu'il est activé sur l'instance ou le groupe principal.

Ouvrez un nouveau terminal et ajoutez le serveur MCP de GitLab à Codex en utilisant le type de transport http.

Modifiez gitlab.example.com pour correspondre à votre instance GitLab :

codex mcp add --url "https://<gitlab.example.com>/api/v4/mcp" GitLab

Le client MCP de Codex peut nécessiter un feature flag pour le rmcp_client en Rust. Ouvrez ~/.codex/config.toml et ajoutez la section [features]. Vous pouvez également vérifier que le serveur MCP de GitLab a été ajouté dans la section mcp_servers..

vim ~/.codex/config.toml

[features]
"rmcp_client" = true

[mcp_servers.GitLab]
url = "https://<gitlab.example.com>/api/v4/mcp"

Lancez codex dans un nouveau terminal et saisissez /mcp pour vous authentifier auprès du serveur MCP de GitLab si cela ne s'est pas fait automatiquement lors de l'ajout.

codex

/mcp

Pour vérifier la connexion, demandez à Codex :

Which GitLab MCP tools are available to you?

Show the GitLab MCP Server version.

Demander à Codex d'implémenter le ticket de filtre WebSocket

Ouvrez Codex et posez la question suivante dans le prompt pour traiter le ticket :

Can you help me implement issue 32?

C'est ici que le workflow change. Dans ce scénario, Codex utilise l'outil MCP get_issue et récupère les détails du ticket dans la session avant de modifier le code. Il voit désormais les exigences, les labels, les remarques et la portée globale du travail avant de toucher à l'implémentation.

Le correctif en lui-même est similaire : ajout du paramètre metric optionnel, mise à jour de la logique de correspondance, ajout de tests et mise à jour de la documentation. La différence réside dans la source de vérité. Dans le premier cas d'utilisation, cette source de vérité était le dépôt plus le prompt. Dans ce cas d'utilisation, ce sont le ticket et le dépôt ensemble.

Après la validation locale, Codex crée une branche, effectue un commit du travail et crée la merge request via des appels d'outils MCP au lieu de s'appuyer sur les options de push Git ou un basculement vers le navigateur.

Parce qu'il connaît le contexte du ticket, Codex ajoute également closes 32 dans la description de la merge request afin que le ticket se ferme automatiquement lors du merge.

Ce workflow est plus significatif qu'il n'y paraît : l'agent ne se contente plus d'écrire du code, il participe également à la livraison logicielle avec le ticket, la merge request et le contexte du pipeline dans la boucle. C'est la valeur ajoutée du MCP de GitLab au workflow de développement de bout en bout.

À ce stade, une fois que la revue de code de GitLab Duo et les tests donnent le feu vert, nous sommes prêts pour la revue finale et le merge.

Regardez l'enregistrement pour découvrir comment Codex corrige le problème avec l'aide du serveur MCP de GitLab :

Vérifier les retours de revue et les exigences avec Codex en tant qu'agent externe

Le troisième cas d'utilisation est encore plus intéressant. Au lieu de nous demander si Codex peut ouvrir une merge request, nous pouvons poser une question plus pratique : peut-il aider après la création de la merge request, et traiter les retours de revue directement dans la merge request ?

Pour explorer ce cas d'utilisation, nous passons à un bogue de validation de l'API REST différent. Le problème que nous simulons avec ce bogue est le suivant : POST /api/metrics accepte des entrées invalides et retourne tout de même 201 Created, alors qu'il devrait retourner 400 Bad Request pour les charges utiles contenant des valeurs invalides telles que des métriques vides.

Testons ce scénario en ouvrant deux terminaux. Dans le Terminal 1, nous lançons le serveur du stockage de métriques sur le port 9090 :

PORT=9090 cargo run --manifest-path backend/rust-metrics-store/Cargo.toml

Dans le Terminal 2, utilisons curl pour envoyer une requête API REST spécifiquement conçue avec une valeur de métrique vide afin de provoquer une erreur.

curl -w "\nHTTP %{http_code}\n" -X POST http://localhost:9090/api/metrics \
  -H "Content-Type: application/json" \
  -d '{"sensor": "sensor-a", "metric": "  ", "value": 23.5, "labels": {}}'

Codex a déjà ouvert une première merge request en mode brouillon avec le correctif principal en place. Un rapide nouveau test local montre que le comportement principal s'est amélioré et que les entrées invalides retournent désormais 400.

C'est un progrès, mais ce n'est pas terminé. La revue de code de GitLab Duo signale deux éléments manquants selon les exigences de style de code Rust :

1. Les éléments publics ont besoin de commentaires de documentation.
2. Les modifications d'API nécessitent des tests de gestionnaire pour les chemins de succès et d'échec, et un test de validation est encore manquant.

À ce stade, nous passons du terminal local à l'interface GitLab où nous pouvons activer l'agent Codex depuis le catalogue d'IA de GitLab dans le menu IA > Agents. Notez l'identifiant du compte de service commençant par @ai-codex-agent, et mentionnez l'agent directement dans la discussion de la merge request afin qu'il puisse traiter les retours de revue.

La merge request devient désormais la surface de travail de l'agent Codex, avec le diff du code, les commentaires de revue, les pipelines CI/CD, les résultats des scanners de sécurité et les règles d'approbation. Codex peut travailler sur le suivi exactement là où la collaboration se déroule déjà.

Ajoutons un nouveau commentaire demandant de l'aide, avec des instructions pour ajouter les correctifs directement dans la merge request :

Please help address the review feedback, and push a fix.

Codex traite les retours, ajoute et effectue un commit du test de validation manquant, relance les vérifications dans son propre contexte d'exécution dans la session d'agent et publie un commentaire récapitulatif dans la merge request.

Nous pouvons inspecter la fonction de test ingest_rejects_blank_metric qui vient d'être ajoutée dans le job log.

C'est là l'utilité du modèle d'agent externe en pratique. Les agents externes ne sont pas utiles parce qu'ils remplacent les revues, ils le sont parce qu'ils aident à combler l'écart entre les retours de revue et l'itération suivante, tout en conservant la merge request, les approbations et la décision humaine finale exactement là où elles doivent être. Et ils peuvent être davantage intégrés à GitLab Duo Agent Platform via les déclencheurs d'événements et les flows personnalisables.

Regardez l'enregistrement pour découvrir comment Codex peut aider lors des revues en tant qu'agent externe dans GitLab Duo Agent Platform.

Conseils pour utiliser Codex avec GitLab

Voici quelques conseils pour utiliser Codex et GitLab ensemble.

Instructions personnalisées avec AGENTS.md

Vous pouvez demander aux agents de compiler et tester le code avant chaque commit, de limiter les modifications au strict nécessaire ou de mieux comprendre l'architecture du projet, en utilisant une entrée dans le fichier AGENTS.md. Le projet Tanuki IoT Platform utilise un fichier au niveau racine, ainsi que des fichiers et des instructions spécifiques pour les sous-répertoires des capteurs et du backend.

tree -P AGENTS.md --prune
.
├── AGENTS.md
├── backend
│   └── rust-metrics-store
│       └── AGENTS.md
└── sensors
    ├── arduino-iot-collector
    │   └── AGENTS.md
    ├── c-file-monitor
    │   └── AGENTS.md
    ├── cobol-mainframe-bridge
    │   └── AGENTS.md
    └── java-http-metrics-collector
        └── AGENTS.md

Pour le backend Rust, un fichier AGENTS.md au niveau du répertoire est maintenu dans backend/rust-metrics-store/AGENTS.md. Il définit le style et les normes de code pour Rust, la documentation, l'organisation des fichiers, la gestion des erreurs, la programmation asynchrone, la conteneurisation et le CI/CD, ainsi que la manière de compiler et d'exécuter le code avec la chaîne d'outils disponible (Cargo). Ouvrez le fichier lié dans le projet GitLab pour découvrir tous les détails.

# rust-metrics-store - Agent Instructions

## Overview

The `rust-metrics-store` is a lightweight, standalone time-series metrics backend for the Tanuki IoT Platform. It accepts metrics from all sensors via a simple REST API and streams live data to frontend clients over WebSocket. No external dependencies — a single binary with in-memory ring buffers.

## Code Style and Standards

### Rust Standards

- Use Rust 2021 edition idioms
- Run `cargo fmt` before committing
- Run `cargo clippy -- -D warnings` and resolve all warnings
- Prefer `Arc<T>` + `RwLock<T>` for shared state; avoid `Mutex` unless write-heavy
- Use `?` for error propagation in fallible functions; only `unwrap()` on truly unrecoverable states (e.g., lock poisoning)
- Derive `Debug`, `Clone`, `Serialize`, `Deserialize` only where needed
- Keep `pub` visibility minimal — expose only what callers need

### Documentation

- Public types and functions must have a doc comment
- Include `# Errors` section in doc comments for fallible functions
- Document env vars and their defaults in `README.md`, not in code

### File Organization

- **`src/main.rs`** — router wiring and `tokio::main`; no business logic
- **`src/store.rs`** — `MetricsStore` and data types; no HTTP concerns
- **`src/handlers.rs`** — Axum extractors and response types; thin layer over the store

### Error Handling

- HTTP handlers should return meaningful status codes (201 for ingest, 404 for unknown sensor)
- Log warnings for recoverable issues (e.g., lagging WebSocket clients) with `tracing::warn!`
- Never silently swallow errors

### Async and Concurrency

- Use `tokio::sync::broadcast` for the live-stream fan-out; `RwLock` for the ring-buffer map
- WebSocket handlers must break cleanly on send errors — do not loop after a closed socket
- Handle `RecvError::Lagged` by logging and continuing, not by disconnecting

### Containerization

- Use a multi-stage Dockerfile: `rust:1.95-slim` builder, `debian:bookworm-slim` runtime
- Always run the container as a non-root user — create `appuser` with `addgroup`/`adduser` and set `USER appuser` before `CMD`
- Include a `.dockerignore` that excludes `target/` and `.git/` to keep build context small
- Use specific image tags — never `latest` in Dockerfile or CI base templates

### CI/CD

- Pin all CI images to specific tags (e.g., `rust:1.95`) — never use `rust:latest` or `debian:latest`
- The `.rust_base` template in `.gitlab-ci.yml` must match the Dockerfile builder image version

## Local Toolchain Setup

// More instructions in the file

Ces instructions personnalisées sont également prises en compte par les agents et les flows sur GitLab Duo Agent Platform.

Si vous souhaitez obtenir de meilleurs résultats des agents de codage, commencez par là. Documentez le fonctionnement du dépôt, les commandes importantes, ce qu'il ne faut pas toucher, et à quoi ressemble une bonne modification. Cet investissement unique est rentable aussi bien pour les outils de codage locaux que pour le MCP de GitLab et les agents externes.

Résumé

Les trois cas d'utilisation de ce tutoriel s'appuient les uns sur les autres, mais ils illustrent aussi un point plus large.

Codex excelle pour nous aider à passer rapidement d'un énoncé de problème au code. GitLab ajoute le contexte de livraison logicielle qui nous aide à transformer ce code en une modification que nous pouvons comprendre, vérifier, revoir et déployer en toute confiance.

Dans le premier cas d'utilisation, nous sommes restés proches du code et avons laissé Codex travailler à partir du dépôt et des instructions d'agent locales. Dans le deuxième cas d'utilisation, le MCP de GitLab a fourni le ticket, les exigences et le workflow de la merge request directement dans la session du terminal. Dans le troisième cas d'utilisation, Codex s'est déplacé dans la merge request elle-même et a aidé à combler l'écart entre les retours de revue et l'itération suivante.

Cette progression souligne l'attrait de la combinaison. Nous ne choisissons pas entre un outil de codage et une plateforme DevSecOps. Nous étendons la rapidité du codage agentique à l'ensemble du cycle de vie logiciel à grande échelle dans de nombreux projets avec de multiples jalons de release, et dans de nombreuses équipes.

Si vous utilisez déjà Codex, GitLab vous offre un moyen concret d'associer cette rapidité de codage avec le contexte et la collaboration nécessaires une fois le correctif créé. Et si vous utilisez déjà GitLab Duo Agent Platform, les agents externes vous offrent une nouvelle façon d'intégrer des outils de codage tiers dans GitLab sans perdre la merge request, sa piste d'audit ou la prise de décision humaine qui reste essentielle.

Si vous souhaitez essayer par vous-même, commencez modestement. Choisissez un bogue visible, définissez le comportement attendu dans un ticket, puis suivez la même progression que celle utilisée ici : codage local, implémentation avec contexte du ticket et collaboration dans la merge request. C'est là que la combinaison devient bien plus qu'un simple correctif rapide.

Si vous n'utilisez pas encore GitLab Duo Agent Platform, vous pouvez le découvrir dans un essai gratuit.

Si vous utilisez déjà GitLab dans l'offre gratuite, vous pouvez souscrire à GitLab Duo Agent Platform en suivant quelques étapes simples.

Et si vous êtes déjà abonné à GitLab Premium ou GitLab Ultimate, il vous suffit d'activer GitLab Duo Agent Platform et de commencer à utiliser les GitLab Credits inclus dans votre abonnement.

Les politiques de gestion des vulnérabilités de GitLab peuvent désormais remplacer automatiquement ces niveaux de gravité CVSS par défaut, selon des conditions que vous définissez : votre rapport de vulnérabilités reflète ainsi votre modèle de risque réel plutôt qu'un modèle générique.

Fonctionnement des politiques de remplacement de la gravité

Une politique de remplacement de la gravité est un type de politique de gestion des vulnérabilités qui ajuste automatiquement les niveaux de gravité des vulnérabilités de chaque pipeline de la branche par défaut. Vous définissez des règles avec des critères de correspondance (identifiant CVE, identifiant CWE, chemin de fichier ou répertoire) et une action de remplacement. Lorsqu'une vulnérabilité correspond, le Security Policy Bot de GitLab met immédiatement à jour sa gravité.

Trois opérations de remplacement sont disponibles :

• Définir la gravité : force la gravité à un niveau précis (information, faible, modéré, élevé ou critique).
• Augmenter la gravité : fait monter la gravité d'un niveau.
• Diminuer la gravité : fait descendre la gravité d'un niveau.

Les remplacements manuels effectués par des utilisateurs autorisés ont toujours la priorité sur les remplacements définis par politique. Chaque modification automatisée est consignée dans l'historique de la vulnérabilité et dans les événements d'audit, ce qui vous garantit une traçabilité complète de ce qui a été modifié et pourquoi.

Cas d'utilisation avec configurations prêtes à l'emploi

Chaque exemple ci-dessous inclut une configuration de politique que vous pouvez copier, personnaliser et appliquer immédiatement.

1. Rétrograder les CVE à faible risque dans les services internes

Les scanners de sécurité ne savent pas quels projets sont des outils internes, des utilitaires de test ou des services en production. Ils évaluent chaque CVE de la même façon, quel que soit le contexte de déploiement. Pour les équipes qui gèrent des tableaux de bord d'administration internes, des outils de développement ou des traitements par lots sans exposition au trafic externe, une vulnérabilité de dépendance classée comme critique ne justifie souvent pas la même réponse que si elle se trouvait dans une API exposée aux clients.

Cette politique diminue la gravité de CVE spécifiques détectées dans les répertoires de services internes :

vulnerability_management_policy:
  - name: "Downgrade CVEs in internal services"
    description: "Internal-only services have lower exposure risk"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            identifier_type: cve
            values:
              - "CVE-2023-44487"
              - "CVE-2024-29041"
          - type: directory
            value: "internal/**/*"
    actions:
      - type: severity_override
        severity_override_operation: decrease

Remplacez les valeurs CVE par les identifiants que votre équipe a évalués comme présentant un risque moindre pour les déploiements internes. L'opération decrease fait baisser la gravité d'un niveau (critique devient élevée, élevée devient modérée), ce qui préserve la priorité relative sans surréagir à des scores inadaptés au contexte.

2. Augmenter la gravité des vulnérabilités d'injection dans le code en production

Certaines catégories de vulnérabilités nécessitent une réponse plus forte lorsqu'elles sont détectées dans le code source en production. Le cross-site scripting, ou XSS (CWE-79), et l'injection SQL (CWE-89) figurent régulièrement parmi les types de vulnérabilités les plus exploités, selon l'Open Web Application Security Project (OWASP) et la base de données des vulnérabilités exploitées connues (Known Exploited Vulnerabilities ou KEV) de l'Agence de cybersécurité et de sécurité des infrastructures (CISA). Si votre scanner signale ces vulnérabilités comme modérées ou élevées dans votre répertoire src/, votre processus de classement doit les traiter comme critiques.

Cette politique définit la gravité à critique pour les résultats XSS et SQLi dans le code en production :

vulnerability_management_policy:
  - name: "Upgrade XSS and SQLi in production code"
    description: "Injection vulnerabilities in src/ are always Critical"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            identifier_type: cwe
            values:
              - "CWE-79"
              - "CWE-89"
          - type: directory
            value: "src/**/*"
    actions:
      - type: severity_override
        severity_override_operation: set
        severity_override_value: critical

Associez cette politique à une politique d'approbation des merge requests qui exige l'approbation de l'équipe de sécurité pour les résultats critiques. La politique de remplacement de la gravité garantit que les bons résultats sont signalés et priorisés dans le rapport de vulnérabilités, tandis que la politique d'approbation s'assure que les nouvelles vulnérabilités détectées ne peuvent pas atteindre la production sans révision.

3. Normaliser la gravité entre les différents scanners

Il arrive que des scanners différents attribuent des niveaux de gravité différents à la même CVE. Votre scanner d'analyse statique de sécurité des applications (SAST) peut évaluer un résultat comme élevé, tandis que l'analyse des dépendances le qualifiera de modéré. Ces incohérences créent de la confusion lors du classement et compliquent la définition de seuils d'approbation cohérents entre les types d'analyse.

Utilisez une politique de remplacement de la gravité pour imposer un niveau de référence cohérent. Si votre équipe de sécurité a évalué une famille de CVE spécifique et déterminé qu'elle doit toujours être élevée quel que soit le scanner, définissez ce paramètre explicitement :

vulnerability_management_policy:
  - name: "Normalize log4j severity to High"
    description: "Consistent severity for log4j CVEs across all scanners"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            identifier_type: cve
            values:
              - "CVE-2021-44228"
              - "CVE-2021-45046"
              - "CVE-2021-45105"
    actions:
      - type: severity_override
        severity_override_operation: set
        severity_override_value: high

Cette approche est particulièrement utile pour les organisations qui utilisent plusieurs types d'analyse (SAST, analyse des dépendances, analyse des conteneurs) et pour lesquelles la même vulnérabilité sous-jacente apparaît avec des évaluations différentes selon la méthode de détection.

4. Aligner la gravité sur les renseignements d'exploitation

Les scores CVSS sont statiques. Ils n'évoluent pas lorsqu'une vulnérabilité commence à être activement exploitée, et ils ne tiennent pas compte de la probabilité d'exploitation réelle. Le score EPSS (Exploit Prediction Scoring System) de FIRST et le catalogue KEV de la CISA fournissent les informations manquantes.

Lorsque vos renseignements sur les menaces indiquent qu'une CVE de gravité modérée est désormais activement exploitée (KEV) ou présente une forte probabilité d'exploitation (score EPSS supérieur à 0,5), utilisez un remplacement de la gravité pour l'augmenter :

vulnerability_management_policy:
  - name: "Upgrade actively exploited CVEs"
    description: "CVEs in CISA KEV catalog should be treated as Critical"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            identifier_type: cve
            values:
              - "CVE-2024-3094"
              - "CVE-2023-4966"
              - "CVE-2023-22515"
    actions:
      - type: severity_override
        severity_override_operation: set
        severity_override_value: critical

Maintenez une liste évolutive des entrées KEV pertinentes pour votre pile et mettez la politique à jour au fur et à mesure que de nouvelles CVE sont ajoutées au catalogue. Vous créez ainsi une boucle de rétroaction entre les renseignements sur les menaces et la gravité visible par les développeurs, sans que les analystes aient à ajuster manuellement chaque résultat.

5. Appliquer des modèles de risque au niveau du groupe dans l'organisation

Les politiques des projets individuels ne sont pas évolutives lorsque votre organisation compte des centaines ou des milliers de projets. Les politiques de remplacement de la gravité peuvent être appliquées au niveau du groupe, ce qui affecte tous les projets du groupe. Combinez-les à policy_scope pour cibler des politiques sur les projets correspondant à un label de framework de conformité spécifique.

Par exemple, une organisation disposant d'un framework de conformité « PCI-DSS » peut imposer un traitement de gravité plus strict pour les vulnérabilités d'injection dans tous les projets à périmètre PCI, tout en appliquant une politique plus légère aux groupes d'outils internes :

vulnerability_management_policy:
  - name: "PCI projects: upgrade injection severity"
    description: "All injection vulnerabilities are Critical in PCI scope"
    enabled: true
    policy_scope:
      compliance_frameworks:
        - id: 12345
    rules:
      - type: detected
        criteria:
          - type: identifier
            identifier_type: cwe
            values:
              - "CWE-79"
              - "CWE-89"
              - "CWE-78"
              - "CWE-94"
    actions:
      - type: severity_override
        severity_override_operation: set
        severity_override_value: critical

Avec ce modèle, l'équipe de sécurité définit le modèle de risque une seule fois pour qu'il s'applique de manière cohérente partout. Aucune configuration par projet. Aucune dépendance vis-à-vis du bon vouloir de chaque équipe pour configurer les choses correctement.

Premiers pas

Suivez ces étapes pour créer des politiques de gestion des vulnérabilités :

1. Identifiez le décalage. Ouvrez votre rapport de vulnérabilités et filtrez par « Nécessite un classement ». Recherchez des schémas : résultats critiques dans du code de test, résultats modérés faisant l'objet d'une exploitation active, évaluations incohérentes entre les types d'analyse.
2. Choisissez un cas d'utilisation. Commencez par le scénario ci-dessus qui couvre le plus grand nombre de résultats incohérents.
3. Définissez votre base de référence. Notez la distribution des gravités avant de créer une politique (nombre de résultats critiques, élevés, modérés dans le périmètre cible).
4. Créez et appliquez une politique. Accédez à Sécurisation > Politiques > Nouvelle politique > Politique de gestion des vulnérabilités. Collez la configuration du cas d'utilisation ci-dessus, puis fusionnez la merge request.
5. Validez les résultats. Après le prochain pipeline de la branche par défaut, vérifiez les gravités mises à jour dans le rapport de vulnérabilités. Filtrez le journal d'activité pour identifier les résultats ajustés et confirmer leur exactitude.

Référence rapide

FAQ

Quelle est la différence entre le rejet automatique et le remplacement de la gravité ? Le rejet automatique supprime les résultats de votre file de classement active. Le remplacement de la gravité les conserve, mais ajuste leur niveau de priorité : ils continuent d'être suivis et examinés avec l'urgence appropriée.

Peut-on combiner des remplacements de gravité avec d'autres types de politiques ? Oui. Les remplacements de gravité s'appliquent aux résultats sur la branche default, ce qui affecte les vulnérabilités apparaissant dans les rapports de vulnérabilités GitLab. Vous pouvez ensuite utiliser des politiques d'approbation des merge requests pour contrôler les nouvelles vulnérabilités détectées.

Les remplacements de gravité s'appliquent-ils rétroactivement aux vulnérabilités existantes ? Oui. Lorsqu'une politique de remplacement de gravité est appliquée, elle traite les vulnérabilités correspondantes dont le statut est « Nécessite un classement » ou « Confirmé » lors du prochain pipeline de la branche par défaut, jusqu'à 1 000 par exécution.

Que se passe-t-il si deux politiques définissent des gravités contradictoires ? Les remplacements manuels ont toujours la priorité. En cas de conflit entre politiques, la politique la plus récente a la priorité. Examinez régulièrement vos politiques pour éviter les critères qui se chevauchent.

Les équipes de développement peuvent-elles contourner les politiques de remplacement de gravité ? Non. Les politiques sont gérées dans un projet de politique de sécurité à accès restreint. Les équipes de développement ne peuvent ni les modifier ni les désactiver. Les utilisateurs autorisés peuvent appliquer des remplacements manuels sur des vulnérabilités individuelles, qui auront la priorité.

Envie de faire en sorte que votre rapport de vulnérabilités reflète les risques réels ? Consultez la documentation sur les politiques de remplacement de la gravité ou démarrez un essai gratuit de GitLab Ultimate pour essayer cette fonctionnalité dès aujourd'hui.

« Claude Sonnet 5 a géré l'ensemble des tâches de programmation sur lesquelles nous l'avons testé, tout en résolvant davantage de problèmes. C'est une avancée significative en matière de qualité comme d'efficacité. Il est disponible dès aujourd'hui sur GitLab Duo Agent Platform, pour toutes les éditions et tous les modèles de déploiement. »

– Manav Khurana, Chief Product and Marketing Officer, GitLab

Menez chaque exécution d'agent à son terme

Un agent qui s'interrompt à mi-parcours représente souvent l'échec le plus coûteux. Lorsqu'une exécution s'arrête au milieu d'une tâche en plusieurs étapes, le coût ne se limite pas au travail perdu : il faut aussi diagnostiquer le problème, reformuler la requête et vérifier le résultat partiel obtenu. C'est la fiabilité qui transforme un agent que l'on supervise en un agent auquel on délègue des tâches.

C'est précisément le niveau d'exigence qu'atteint Claude Sonnet 5 : il s'agit du premier modèle de notre suite d'évaluation à mener à bien chaque tâche de notre benchmark. Associée à une hausse de 8,8 % du nombre de problèmes résolus, cette fiabilité signifie que les tâches accomplies ont plus de chances d'être exploitables.

Pour les équipes qui utilisent GitLab Duo Agentic Chat, cette amélioration transforme la boucle quotidienne (requêtes, attente, évaluation). Une refactorisation multi-fichiers produit un résultat prêt pour une revue plutôt qu'une impasse. La génération de tests fournit une couverture utilisable. Les investigations de sécurité remontent plus loin dans l'historique du dépôt. Les agents par défaut de GitLab Duo traitent davantage de missions sans intervention, ce qui vous permet de consacrer votre temps à la revue des résultats plutôt qu'au redémarrage des exécutions.

Dépensez moins pour de meilleurs résultats

Efficacité et fiabilité se renforcent mutuellement. Un agent qui accomplit davantage de tâches et qui consomme moins de ressources pour y parvenir réduit le coût réel de chaque tâche terminée.

Les différents modèles disponibles sur GitLab Duo Agent Platform consomment des GitLab Credits à des rythmes différents, et le bon choix du modèle dépend de la tâche. Pour maintenir des workflows d'agents économiquement viables à grande échelle, il faut exécuter un large éventail de tâches de développement au quotidien sur un modèle dont le profil de coût correspond au type de tâches.

Pour la liste complète des modèles et de leur consommation en crédits, consultez la documentation sur les GitLab Credits.

Choisissez le bon modèle pour votre workflow

L'objectif n'est pas d'utiliser un seul modèle. Il s'agit de disposer, pour l'essentiel du travail quotidien des agents, d'une option par défaut fiable et économique, tout en gardant des modèles plus puissants à portée de clic lorsque la tâche le justifie.

Claude Sonnet 5 rejoint un ensemble en constante évolution de modèles d'IA disponibles sur GitLab Duo Agent Platform. Les modèles de la famille Sonnet allient qualité, rapidité et coût pour le développement quotidien. Claude Opus 4.8 reste disponible pour les tâches agentiques complexes et de longue haleine qui exigent une profondeur de raisonnement maximale. Vous pouvez choisir les modèles en fonction de la tâche via la sélection de modèle dans votre instance GitLab.

Lancez-vous dès aujourd'hui

Claude Sonnet 5 est disponible dès maintenant sur GitLab Duo Agent Platform, via la passerelle d'IA de GitLab. Comme les autres modèles, il fonctionne avec les GitLab Credits.

Démarrez un essai gratuit de GitLab Duo Agent Platform dès aujourd'hui, ou inscrivez-vous depuis l'édition gratuite de GitLab en suivant quelques étapes simples. Les clients GitLab Premium ou GitLab Ultimate existants peuvent utiliser les GitLab Credits inclus dans leur abonnement.

Cette enquête révèle qu'à mesure que les outils de codage alimentés par l'IA s'imposent comme une infrastructure standard, la question n'est plus de savoir à quelle vitesse les équipes peuvent générer du code, mais bien si elles sont réellement en mesure de contrôler ce qu'elles livrent en production.

Des chiffres clés au paradoxe de l'IA, en passant par les quatre piliers de la responsabilité en matière d'IA, voici ce que révèle notre enquête.

Pour accéder à notre rapport complet sur la Responsabilité en matière d'IA, cliquez ici. Vous souhaitez en savoir plus sur GitLab Duo Agent Platform ? Commencez par un essai gratuit.

La responsabilité en matière d'IA : définition

La responsabilité en matière d'IA est la capacité organisationnelle et technique à répondre à trois questions sur les workflows agentiques dans le cycle de vie logiciel :

• D'où vient le code ?
• Qu'est-il censé faire ?
• Qui en est responsable une fois en production ?

Bien que les outils de codage alimentés par l'IA aient été largement adoptés et que les gains de productivité soient réels, bon nombre d'organisations sont encore dans l'incapacité de répondre à ces questions. Les entreprises qui se démarquent aujourd'hui sont celles qui ont fait du contexte, de la traçabilité et de la gouvernance les fondations de leur approche.

L'IA tient ses promesses : le cycle de développement logiciel réinventé

L'adoption de l'IA n'est plus une expérimentation. 91 % des organisations utilisent activement au moins deux outils de codage alimentés par l'IA, et plus de la moitié en cumulent trois ou plus.

Cet investissement porte ses fruits, puisque 60 % des professionnels DevSecOps estiment que le retour sur investissement (ROI) des outils de codage alimentés par l'IA a dépassé leurs attentes. Les bénéfices se mesurent très concrètement sur le terrain, comme en témoignent les chiffres suivants : 78 % des professionnels font état d'une production de code plus rapide, et 73 % observent même une amélioration globale de la qualité du code livré.

Cependant, cette montée en puissance révèle un déséquilibre. 79 % des répondants s'accordent à dire que la productivité individuelle s'est améliorée grâce à l'IA, mais que le processus global de livraison logicielle n'a pas progressé au même rythme.

C'est ce qu'on appelle le paradoxe de l'IA.

L'IA a accéléré les étapes du développement logiciel les plus directement liées à l'écriture du code, tandis que la conformité, les scans de sécurité, le déploiement et la gestion des incidents n'ont pas bénéficié de cette même dynamique.

85 % des professionnels constatent eux-mêmes ce glissement, et 84 % estiment que le principal défi n'est plus d'écrire le code généré par l'IA, mais de le maîtriser une fois créé. Le constat s'étend même à la maintenabilité à long terme du code, puisque 82 % redoutent que ce code génère une nouvelle forme de dette technique à laquelle les organisations ne sont pas préparées.

Contexte et traçabilité, les nouveaux facteurs de différenciation

87 % des professionnels DevSecOps sont convaincus que leur équipe pourrait déterminer, en moins de 24 heures, si du code généré par l'IA a contribué à un incident en production. Pourtant, 34 % des organisations ayant subi un incident au cours de l'année écoulée n'ont pas été en mesure de le faire.

Ce décalage ne s'explique pas par un manque de savoir-faire, mais par les outils en place. Pour 43 % des équipes, l'un des principaux obstacles à la traçabilité complète du code est la capacité à distinguer la génération de code par IA du code écrit par un développeur. D'autres composent avec une chaîne d'outils fragmentés (40 %), ou des systèmes qui ne permettent pas de suivre l'origine ou l'intention du code (39 %). Dans les trois cas, le problème est structurel, et non individuel.

L'intégration demeure le chaînon manquant, puisque seuls 28 % des répondants déclarent disposer d'outils couvrant l'ensemble du cycle de développement avec des données et des workflows partagés.

Les entreprises capables de déterminer avec certitude l'implication du code généré par l'IA ont toutes un dénominateur commun : une revue de code active par les équipes sécurité ou DevOps (48 %), une journalisation, une surveillance ou des pistes d'audit qui retracent chaque modification du code (42 %), ou encore une expérience dans l'investigation d'incidents impliquant du code généré par l'IA (40 %).

La gouvernance, un impératif

La gouvernance reste le grand chantier inachevé de la responsabilité en matière d'IA. 92 % des professionnels DevSecOps font état de problèmes de gouvernance liée au code généré par l'IA, et 80 % reconnaissent que leur organisation a adopté des outils d'IA plus rapidement qu'elle n'a élaboré des politiques pour les encadrer.

Les organisations avancent, mais à des rythmes très différents : si les trois quarts des entreprises interrogées disposent d'un framework de gouvernance, seules 41 % ont formalisé une politique complète.

Cet écart a des conséquences directes. Là où la gouvernance est formalisée, 64 % des organisations font relire par des humains la majeure partie de leur code généré par l'IA (70 à 100 %), contre 50 % pour celles qui n'ont pas de gouvernance formelle. À l'inverse, sans règles claires, ce code alourdit la dette technique plus rapidement que les pratiques traditionnelles, comme le reconnaissent 86 % des répondants.

Le risque est désormais traité comme immédiat. 83 % des organisations voient l'accumulation de code généré par l'IA comme un risque à gérer dès maintenant, 44 % allant jusqu'à le qualifier de risque technologique majeur. Les investissements, eux, sont déjà engagés. 91 % envisagent d'investir dans des outils de gouvernance de code alimentés par l'IA au cours des 12 prochains mois, et 98 % ont déjà alloué un budget à cet effet ou envisagent de le faire.

La gouvernance du code généré par l'IA s'impose comme une composante à part entière du DevSecOps, au même titre que la sécurité.

Les quatre piliers de la responsabilité en matière d'IA

Quatre leviers fondamentaux distinguent les entreprises qui montrent la voie de celles qui cherchent encore à rattraper leur retard :

• Des outils intégrés qui préservent le contexte tout au long du cycle de développement logiciel.
• Une traçabilité qui relie chaque ligne de code, qu'elle soit écrite par un humain ou générée par l'IA, à son intention d'origine.
• Une gouvernance capable d'évoluer au rythme de l'adoption, associée à une revue humaine active.
• Une maintenabilité à long terme du code généré par l'IA, soutenue par la documentation et le contexte, même quand le volume augmente.

Ces leviers sont devenus des enjeux stratégiques. 85 % des professionnels estiment que la prochaine phase de l'IA dans le développement logiciel portera moins sur la génération de code que sur sa gouvernance.

Une proportion similaire va plus loin : les organisations incapables de suivre ou de gouverner ce code seront confrontées à des risques opérationnels et de sécurité croissants, à mesure que le développement logiciel agentique se généralise. Enfin, 86 % constatent qu'il crée déjà de nouveaux défis en matière de responsabilité pour les équipes de développement, de sécurité et d'opérations.

Contexte et traçabilité tout au long du SDLC avec GitLab

GitLab réunit l'intégralité du cycle de développement logiciel au sein d'un même système, pour que les organisations puissent répondre aux trois questions au cœur de la responsabilité en matière d'IA pour toute ligne de code : d'où vient-elle, quel est son objectif et qui en est responsable en production ?

La plateforme connecte nativement les tickets, le code, les merge requests, les pipelines, les risques de sécurité détectés et les déploiements au sein d'une plateforme unique, dotée d'un modèle de données commun. En parallèle, GitLab Duo Agent Platform met à disposition des équipes de développement des agents d'IA qui collaborent tout au long du cycle de développement logiciel (SDLC) : planification, build, sécurisation, déploiement, exploitation du code, etc.

Pour améliorer la performance de ces agents, GitLab vient de lancer GitLab Orbit (actuellement disponible en version bêta publique). GitLab Orbit alimente ces agents en indexant en continu l'ensemble du cycle de développement dans un graphe de contexte toujours à jour. Les agents raisonnent à partir de données structurées et complètes, ce qui augmente leur précision et leur efficacité. Plus besoin de jongler entre des outils et des informations fragmentés, le contexte est préservé à chaque étape du cycle.

« Les outils de codage alimentés par l'IA ont tenu leur promesse en matière de vitesse. Mais les événements survenus ces derniers mois (attaques de la chaîne d'approvisionnement logicielle, problèmes de fiabilité et renforcement des exigences réglementaires en matière de traçabilité et de provenance de l'IA) montrent clairement que la vitesse sans contrôle représente un risque, et non un avantage. Les équipes qui souhaitent prendre une longueur d'avance se posent déjà la vraie question : pouvons-nous réellement contrôler tout le code que nous générons ? Les organisations qui livreront des logiciels fiables plus rapidement sont celles qui posent dès maintenant les bases de la responsabilité, avec le contexte, la traçabilité et la gouvernance intégrés à la plateforme, et non ajoutés après coup », explique Manav Khurana, Chief Product and Marketing Officer chez GitLab.

Pour aller plus loin, téléchargez le Rapport sur la responsabilité en matière d'IA, ou découvrez dès maintenant GitLab Duo Agent Platform avec un essai gratuit.

git-history(1) : nouvelle commande fixup

Dans les nouveautés marquantes de Git 2.54.0, nous avons présenté l'introduction de git-history(1). Dans la release 2.55.0, une nouvelle sous-commande a été ajoutée à cet outil : fixup.

Imaginez que vous avez apporté des modifications et que vous souhaitez les intégrer à un commit existant. L'approche la plus courante consiste à créer un commit fixup, puis à le regrouper automatiquement (« autosquash ») avec git-rebase(1) :

git commit --fixup=<commit-id>
git rebase -i --autosquash <commit-id>^

Effectuer cette opération en deux étapes est fastidieux, d'autant plus que cela nécessite un rebasage interactif. À la place, utilisez la commande fixup de git-history(1) :

git history fixup <commit-id>

Celle-ci intègre les modifications indexées au commit indiqué. Avantage supplémentaire : étant donné que vous utilisez git-history(1), toutes les autres branches locales qui contiennent le commit corrigé sont également mises à jour. Ainsi, lorsque vous travaillez avec des branches empilées, corriger un commit de la pile rebase automatiquement toutes les branches associées.

Cette fonctionnalité a été implémentée par Patrick Steinhardt.

Daemon fsmonitor pour Linux

Lorsque vous travaillez avec de grands monorepos, git-status(1) est parfois lent à déterminer ce qui a changé dans l'arborescence de travail locale, car Git doit en parcourir l'intégralité pour repérer les fichiers modifiés. Pour accélérer ce processus, le paramètre core.fsmonitor a été ajouté en janvier 2018 dans Git 2.16. À l'époque, vous deviez fournir votre propre outil (comme Watchman). Une fois configuré, cet outil s'exécute en arrière-plan et surveille les modifications du système de fichiers. Il informe Git qu'un fichier est concerné ; Git vérifie alors si le fichier a été modifié et met à jour le statut mis en cache. Ensuite, chaque fois que l'utilisateur appelle git-status(1), la commande peut simplement renvoyer le statut mis en cache.

En avril 2022, le paramètre core.fsmonitor a été modifié pour accepter une valeur booléenne. Lorsque ce paramètre est défini sur true, un daemon intégré à Git est utilisé et plus aucun outil tiers n'est nécessaire. Mais ce moniteur de système de fichiers n'était implémenté que pour Windows et macOS ; la prise en charge de GNU/Linux n'existait pas encore.

C'est désormais chose faite avec Git 2.55, qui prend en charge Linux. Pour y parvenir, nous avons décidé d'utiliser inotify(7) plutôt que fanotify(7), car fanotify(7) nécessite des privilèges élevés. Il y a toutefois un petit bémol : fsmonitor doit surveiller chaque répertoire du dépôt. Dans un grand dépôt, vous pourriez atteindre la limite de surveillance inotify (fs.inotify.max_user_watches), que vous devrez peut-être augmenter.

Ces modifications ont été soumises par Paul Tarjan à partir des travaux d'Eric DeCosta et de Marziyeh Esipreh.

git push vers un groupe de dépôts distants

Il y a déjà un certain temps, git-fetch(1) a appris à gérer la récupération depuis un groupe de dépôts distants.

La commande suivante configure un groupe de dépôts distants :

git config set remotes.forks "origin upstream"

Une fois cette configuration en place, vous pouvez utiliser git-fetch(1) sur ce groupe nommé « forks » ; les modifications de tous les dépôts distants de ce groupe sont alors récupérées. Cette commande peut s'avérer utile lorsque vous souhaitez obtenir les mises à jour d'un ensemble de dépôts distants en une seule fois.

git-push(1), en revanche, ne pouvait pas utiliser les groupes de dépôts distants.

Git 2.55 comble cette lacune : git-push(1) accepte désormais aussi un groupe de dépôts distants. Voici un exemple de push de la branche main vers le groupe mentionné ci-dessus :

git push forks main

Comme avec git-fetch(1), cette commande envoie les références spécifiées vers chaque dépôt distant du groupe. Chaque dépôt distant fait l'objet d'un push indépendant et respecte sa propre correspondance remote.<name>.push ainsi que ses paramètres de miroir.

Cette fonctionnalité a été soumise par Usman Akinyemi, sur la base d'une suggestion de Junio C Hamano.

Limiter la largeur de git log --graph

L'option --graph de git-log(1) dessine une représentation ASCII de l'historique des commits. Dans un dépôt comptant de nombreux contributeurs actifs, ce graphe peut devenir très large. Par exemple, sur le dépôt git.git, ce graphe atteint neuf caractères de large après seulement 30 commits :

* 26d8d94e94 A few more topics before -rc2
*   02bb39c5cb Merge branch 'js/objects-larger-than-4gb-on-windows-more'
|\
| * c6a4629e32 odb: use size_t for object_info.sizep and the size APIs
| * 7a3a78cc76 packfile,delta: drop the `cast_size_t_to_ulong()` wrappers
| * 188bac14f7 pack-objects: use size_t for in-core object sizes
| * 2d83cc3f84 packfile: widen unpack_entry()'s size out-parameter to size_t
| * 1d43315b31 pack-objects(check_pack_inflate()): use size_t instead of unsigned long
| * 33afe87338 patch-delta: use size_t for sizes
| * 8ea69373a4 compat/msvc: use _chsize_s for ftruncate
* |   8cf57cbec4 Merge branch 'kw/gitattributes-typofix'
|\ \
| * | 0bf506efd4 gitattributes: fix eol attribute for Perl scripts
* | |   8d96f09e92 Merge branch 'js/objects-larger-than-4gb-on-windows'
|\ \ \
| * | | ab3810eb6f zlib: properly clamp to uLong
* | | | 95e20213fa Hopefully final batch before -rc2
* | | |   8632b5c49d Merge branch 'en/commit-graph-timestamp-fix'
|\ \ \ \
| * | | | fbcc5408fc commit-graph: use timestamp_t for max parent generation accumulator
* | | | |   619931f561 Merge branch 'dl/posix-unused-warning-clang'
|\ \ \ \ \
| * | | | | cf48887610 compat/posix.h: simplify GIT_GNUC_PREREQ() comparison
| * | | | | ffd45926dc compat/posix.h: clean up GIT_GNUC_PREREQ() and UNUSED
| * | | | | 689dc92e50 compat/posix.h: enable UNUSED warning messages for Clang
* | | | | |   621962aa7a Merge branch 'td/ls-files-pathspec-prefilter'
|\ \ \ \ \ \
| * | | | | | 3f5203eeb4 ls-files: filter pathspec before lstat
| | |_|_|_|/
| |/| | | |
* | | | | |   0c706d5092 Merge branch 'ta/doc-config-adoc-fixes'
|\ \ \ \ \ \
| * | | | | | 4fa2c6e045 doc: git-config: escape erroneous highlight markup
| * | | | | | 042221cccb doc: config/sideband: fix description list delimiter
| * | | | | | 3eb61fda62 doc: config: terminate runaway lists
* | | | | | |   49cb068fb2 Merge branch 'jc/t1400-fifo-cleanup'
|\ \ \ \ \ \ \
| * | | | | | | e8f12e0e95 t1400: have fifo test clean after itself
* | | | | | | |   b4970f8448 Merge branch 'td/describe-tag-iteration'
|\ \ \ \ \ \ \ \
| * | | | | | | | 55088ac8a4 describe: limit default ref iteration to tags

Chaque voie de l’historique se prolonge vers le bas jusqu'au commit à partir duquel la branche a été créée. Les messages de commit sont ainsi relégués vers la droite, ce qui complique la lecture. Le problème devient particulièrement ingérable lorsque la largeur de l'écran du terminal est atteinte.

Git 2.55 ajoute une nouvelle option (--graph-lane-limit=<n>) pour limiter le nombre de voies dessinées. Toutes les voies au-delà de la limite sont remplacées par une marque de troncature ~ afin d'indiquer clairement que le graphe a été tronqué :

git log --graph --graph-lane-limit=5

En utilisant cette option pour les 30 mêmes commits que ci-dessus, nous obtenons le résultat suivant :

* 26d8d94e94 A few more topics before -rc2
*   02bb39c5cb Merge branch 'js/objects-larger-than-4gb-on-windows-more'
|\
| * c6a4629e32 odb: use size_t for object_info.sizep and the size APIs
| * 7a3a78cc76 packfile,delta: drop the `cast_size_t_to_ulong()` wrappers
| * 188bac14f7 pack-objects: use size_t for in-core object sizes
| * 2d83cc3f84 packfile: widen unpack_entry()'s size out-parameter to size_t
| * 1d43315b31 pack-objects(check_pack_inflate()): use size_t instead of unsigned long
| * 33afe87338 patch-delta: use size_t for sizes
| * 8ea69373a4 compat/msvc: use _chsize_s for ftruncate
* |   8cf57cbec4 Merge branch 'kw/gitattributes-typofix'
|\ \
| * | 0bf506efd4 gitattributes: fix eol attribute for Perl scripts
* | |   8d96f09e92 Merge branch 'js/objects-larger-than-4gb-on-windows'
|\ \ \
| * | | ab3810eb6f zlib: properly clamp to uLong
* | | | 95e20213fa Hopefully final batch before -rc2
* | | |   8632b5c49d Merge branch 'en/commit-graph-timestamp-fix'
|\ \ \ \
| * | | | fbcc5408fc commit-graph: use timestamp_t for max parent generation accumulator
* | | | |   619931f561 Merge branch 'dl/posix-unused-warning-clang'
|\ \ \ \ \
| * | | | ~ cf48887610 compat/posix.h: simplify GIT_GNUC_PREREQ() comparison
| * | | | ~ ffd45926dc compat/posix.h: clean up GIT_GNUC_PREREQ() and UNUSED
| * | | | ~ 689dc92e50 compat/posix.h: enable UNUSED warning messages for Clang
* | | | | ~ 621962aa7a Merge branch 'td/ls-files-pathspec-prefilter'
|\ \ \ \ \~
| * | | | ~ 3f5203eeb4 ls-files: filter pathspec before lstat
| | |_|_|_~
| |/| | | ~
* | | | | ~ 0c706d5092 Merge branch 'ta/doc-config-adoc-fixes'
|\ \ \ \ \~
| * | | | ~ 4fa2c6e045 doc: git-config: escape erroneous highlight markup
| * | | | ~ 042221cccb doc: config/sideband: fix description list delimiter
| * | | | ~ 3eb61fda62 doc: config: terminate runaway lists
* | | | | ~ 49cb068fb2 Merge branch 'jc/t1400-fifo-cleanup'
|\ \ \ \ \~
| * | | | ~ e8f12e0e95 t1400: have fifo test clean after itself
* | | | | ~ b4970f8448 Merge branch 'td/describe-tag-iteration'
|\ \ \ \ \~
| * | | | ~ 55088ac8a4 describe: limit default ref iteration to tags

Cette option n'a de sens qu'avec --graph. La valeur par défaut est 0, ce qui signifie qu'il n'y a aucune limite ; les valeurs nulles ou négatives sont traitées de la même manière, tout comme le fait --max-parents.

Cette fonctionnalité a été soumise par Pablo Sabater.

Évolution de Rust dans le code source de Git

En mars 2025, avec la sortie de Git 2.49, le premier code Rust a été ajouté au code source de Git. Des liaisons Rust ont été ajoutées pour permettre au code Rust d'appeler libgit. Mais aucune partie de ce code Rust n'était utilisée par les binaires de Git.

En novembre 2025, dans Git 2.52, le premier code de production Rust a été introduit dans Git. Une implémentation Rust du sous-système varint a alors été ajoutée. Ce code est compilé de manière facultative si le compilateur Rust est disponible ; dans le cas contraire, c'est l'implémentation C qui est utilisée. Il s'agissait d'un ballon d'essai destiné aux distributeurs, afin qu'ils commencent à préparer leurs outils en vue d'une release de Git qui finirait par exiger Rust.

Plus tôt cette année, dans la release 2.54, davantage de code Rust a été ajouté au code source avec l'introduction du type ObjectID. Celui-ci a été ajouté dans le cadre des efforts visant à mettre en œuvre une interopérabilité entre SHA-1 et SHA-256.

Jusqu'à cette release, les deux systèmes de build Make et Meson revenaient gracieusement à l'implémentation C si le compilateur Rust était introuvable. Avec cette release v2.55, le compilateur Rust est requis, sauf si vous le désactivez explicitement dans le système de build.

Veuillez noter que cela n'affecte pas les utilisateurs de Git. Cela concerne uniquement ceux qui effectuent un build de Git à partir de son code source. Si vous effectuez un build de Git et que vous ne souhaitez pas utiliser Rust, désactivez-le avec l'une de ces commandes :

# Meson
meson configure -Drust=disabled

# Makefile
make NO_RUST=YesPlease

L'intégration de Rust dans Git est un effort continu (et inachevé) porté par la communauté, réparti sur plusieurs releases. Il est impossible de l'attribuer à une seule personne, mais brian m. carlson, Patrick Steinhardt, Ezekiel Newren et Calvin Wan figurent parmi les contributeurs les plus marquants.

git-grep(1) et git-cherry(1) plus rapides dans les clones partiels

git-clone(1) dispose d'une fonctionnalité de clone partiel. Celle-ci permet à l'utilisateur d'appliquer un filtre aux éléments envoyés depuis le serveur. En pratique, c'est l'option --filter. Exemple :

git clone --filter=blob:none <remote>

Le dépôt est cloné, mais tous les blobs (c'est-à-dire le contenu des fichiers de l'arborescence) sont exclus. Le clonage peut en être considérablement accéléré, mais avec un inconvénient : Git doit télécharger les blobs ultérieurement lorsque d'autres commandes lisant le contenu des fichiers sont utilisées. Et certaines commandes peuvent nécessiter de nombreux blobs manquants.

git-grep(1) est l'une de ces commandes, car elle recherche dans le contenu des fichiers. Pour ce faire, elle doit évidemment disposer de ces fichiers. Imaginez que vous souhaitez rechercher le mot « TODO » 100 commits en arrière dans l'historique :

git grep TODO HEAD~100

Cette commande résout le commit HEAD~100 ainsi que les arborescences qui lui sont associées. Mais ces arborescences peuvent pointer vers des blobs qui ne sont pas encore téléchargés. Auparavant, chaque blob était téléchargé séparément. Git 2.55 propose une amélioration : les téléchargements de blobs sont regroupés en un seul aller-retour de négociation avec le serveur.

Ce regroupement est désormais implémenté à la fois pour git-grep(1) et git-cherry(1).

Cette modification a été soumise par Elijah Newren.

Pour en savoir plus

Cet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et la communauté Git pour cette dernière release. Vous pouvez en apprendre davantage dans l'annonce de release officielle du projet Git. Consultez également nos articles de blog précédents sur les releases de Git pour découvrir d'autres contributions des membres de l'équipe GitLab.