[{"data":1,"prerenderedAt":793},["ShallowReactive",2],{"/fr-fr/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab":3,"navigation-fr-fr":43,"banner-fr-fr":447,"footer-fr-fr":457,"blog-post-authors-fr-fr-Benjamin Skierlak|James Wormwell":667,"blog-related-posts-fr-fr-from-code-to-production-a-guide-to-continuous-deployment-with-gitlab":693,"blog-promotions-fr-fr":731,"next-steps-fr-fr":784},{"id":4,"title":5,"authorSlugs":6,"body":9,"categorySlug":10,"config":11,"content":15,"description":9,"extension":30,"isFeatured":13,"meta":31,"navigation":32,"path":33,"publishedDate":22,"seo":34,"stem":38,"tagSlugs":39,"__hash__":42},"blogPosts/fr-fr/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","From Code To Production A Guide To Continuous Deployment With Gitlab",[7,8],"benjamin-skierlak","james-wormwell",null,"product",{"slug":12,"featured":13,"template":14},"from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",false,"BlogPost",{"title":16,"description":17,"authors":18,"heroImage":21,"date":22,"body":23,"category":10,"tags":24,"updatedDate":29},"Du code à la production : guide du déploiement continu avec GitLab","Découvrez comment créer un pipeline de déploiement continu robuste dans GitLab.",[19,20],"Benjamin Skierlak","James Wormwell","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659478/Blog/Hero%20Images/REFERENCE_-_Use_this_page_as_a_reference_for_thumbnail_sizes.png","2025-01-28","Le déploiement continu est une pratique qui change la donne et qui permet aux équipes d'offrir de la valeur plus rapidement, avec une confiance accrue. Cependant, adopter des workflows de déploiement avancés, tels que [GitOps](https://about.gitlab.com/fr-fr/topics/gitops/ \"Qu'est-ce que GitOps ? \"), l'orchestration de conteneurs avec [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Kubernetes, la solution d’orchestration des conteneurs\") ou les environnements dynamiques, peut être intimidant pour les équipes non expérimentées.\n\nChez GitLab, nous nous engageons à ce que la livraison de logiciels soit sans accroc et évolutive. En permettant aux équipes de se concentrer sur les fondamentaux, nous leur donnons les moyens d'établir une base solide qui soutient la croissance et de mettre en place des stratégies plus complexes au fil du temps.\nDans ce guide, découvrez les étapes clés pour mettre en œuvre le déploiement continu avec GitLab et poser les bases d'une réussite à long terme.\n\n## Commencez par planifier votre workflow\n\nAvant de passer à la mise en œuvre technique, prenez le temps de planifier votre workflow de déploiement. Une planification minutieuse et une approche méthodique sont les clés du succès.\n\n### Stratégie de gestion des artefacts\n\nDans le contexte du déploiement continu, les artefacts désignent les fichiers empaquetés suite au processus de compilation, destinés à être stockés, déployés et dont vous devez gérer les versions.\nEn voici quelques exemples :\n\n- images de conteneurs pour vos applications\n- paquets\n- exécutables ou fichiers binaires compilés\n- bibliothèques\n- fichiers de configuration\n- packages de documentation\n- autres artefacts\n\nChaque type d'artefact joue un rôle spécifique dans votre processus de déploiement. Par exemple, une application web typique peut générer les artefacts suivants :\n\n- une image de conteneur pour le service backend\n- une archive ZIP des ressources frontend compilées\n- des fichiers SQL pour les modifications de base de données\n- des fichiers de configuration propres à l'environnement\n\nLa gestion efficace de ces artefacts est cruciale pour la réussite des déploiements. Voici comment aborder la gestion des artefacts.\n\n#### Artefacts et stratégies de contrôle des versions\n\nUne bonne pratique permettant de démarrer avec une structure bien organisée consiste à établir une stratégie de gestion des versions claire pour vos artefacts.\nLors de la création de nouvelles versions :\n\n- Utilisez la gestion sémantique de version (major.minor.patch) pour les tags de version\n  - Exemple : `myapp:1.2.3` pour une version stable\n  - Modifications de la version majeure (2.0.0) pour les changements cassants\n  - Modifications de la version mineure (1.3.0) pour les nouvelles fonctionnalités\n  - Modifications de la version des correctifs (1.2.4) pour les corrections de bugs\n- Conservez un tag 'latest' pour la version stable la plus récente\n  - Exemple : `myapp:latest` pour les déploiements automatisés\n- Incluez un SHA de validation pour un suivi précis des versions\n  - Exemple : `myapp:1.2.3-abc123f` pour le débogage\n- Utilisez des tags basés sur les branches pour les environnements de développement\n  - Exemple : `myapp:feature-user-auth` pour les tests de fonctionnalités\n\n#### Rétention des artefacts de compilation\n\nMettez en œuvre des règles de durée de rétention définies :\n\n- Définissez des délais d'expiration explicites pour les artefacts temporaires\n- Définissez les artefacts nécessitant une durée de rétention permanente\n- Configurez des stratégies de nettoyage pour gérer le stockage\n\n#### Accès au registre et authentification\n\nSécurisez vos artefacts avec des contrôles d'accès appropriés :\n\n- Implémentez des jetons d'accès personnels (Personal Access Tokens) pour l'accès des développeurs\n- Configurez des variables CI/CD pour l'authentification du pipeline\n- Mettez en place des portées d'accès appropriées\n\n### Stratégie d’environnement de déploiement\nRéfléchissez dès le départ à la configuration de vos environnements, car ils façonnent l'ensemble de votre pipeline de déploiement :\n\n- Configurations de l'environnement de développement, de préproduction et de production\n- Variables et secrets propres à l'environnement\n- Contrôles d'accès et règles de protection\n- Approche de suivi et de surveillance du déploiement\n\n### Cibles de déploiement\n\nIl est important de réfléchir à la cible de déploiement et à l'approche choisie, tout en prenant en compte les avantages et les inconvénients de ces décisions :\n\n- Besoins en infrastructure (machines virtuelles, conteneurs, services cloud)\n- Configurations de la sécurité et de l'accès au réseau\n- Mécanismes d'authentification (clés SSH, jetons d'accès)\n- Éléments à prendre en compte pour l'allocation des ressources et la mise à l'échelle\n\nLorsque vous avez défini votre stratégie et pris les décisions fondamentales, vous pouvez transformer cette planification en un pipeline fonctionnel. Nous allons créer un exemple concret qui démontre ces concepts, en commençant par une application simple à laquelle nous ajouterons progressivement des fonctionnalités de déploiement.\n\n## Mettez en œuvre votre pipeline CD\n\n### Exemple pas à pas\n\nExaminons comment mettre en œuvre un pipeline de déploiement continu de base pour une application web. Nous utiliserons une application HTML simple à titre d'exemple, mais ces principes s'appliquent à tout type d'application. Nous allons également déployer notre application sous la forme d'une image Docker sur une simple machine virtuelle. Cela nous permettra de nous appuyer sur une image organisée avec un minimum de dépendances et de nous assurer qu'aucun prérequis propre à l'environnement n'est introduit involontairement. En travaillant sur une machine virtuelle, nous ne ferons pas appel aux intégrations natives de GitLab, ce qui nous permettra de travailler sur une configuration plus simple, quoique moins évolutive.\n\n#### Prérequis\n\nDans cet exemple, nous allons conteneuriser une application qui s'exécutera sur une machine virtuelle hébergée sur la plateforme d'un fournisseur de services cloud. Nous testerons également cette application localement sur notre machine. Cette liste de prérequis n'est nécessaire que pour notre scénario.\n\n##### Configuration de la machine virtuelle\n\n- Provisionnez une machine virtuelle sur la plateforme de votre fournisseur de services cloud préféré (par exemple, GCP, AWS, Azure).\n- Configurez les règles du réseau pour autoriser l'accès sur les ports 22, 80 et 443.\n- Enregistrez l'adresse IP publique de la machine pour le déploiement.\n\n##### Configuration de l'authentification SSH :\n\n- Générez une paire de clés publique/privée pour la machine.\n- Dans GitLab, accédez à **Paramètres > CI/CD > Variables**.\n- Créez une variable nommée `GITLAB_KEY`.\n- Définissez le type sur « Fichier » (requis pour l'authentification SSH).\n- Collez la clé privée dans le champ Valeur.\n- Définissez une variable USER (utilisateur qui se connecte et exécute les scripts sur votre machine virtuelle).\n\n##### Configuration des variables de déploiement\n\n- Créez des variables pour vos cibles de déploiement :\n  - `STAGING_TARGET` : l'adresse IP/le domaine de votre serveur de préproduction\n  - `PRODUCTION_TARGET` : l'adresse IP/le domaine de votre serveur de production\n\n##### Configuration du développement local\n\n- Installez [Docker](https://about.gitlab.com/fr-fr/blog/what-is-docker-comprehensive-guide/ 'Docker') sur votre machine locale pour tester les déploiements.\n\n##### Accès au registre de conteneurs GitLab\n\n- Localisez votre chemin d'accès au registre :\n  - Accédez à **Déploiement > Registre de conteneurs**.\n- Copiez le chemin d'accès au registre (par exemple, registry.gitlab.com/group/project).\n- Configurez l'authentification :\n  - Accédez au menu **Paramètres > Jetons d'accès**.\n  - Créez un jeton avec un accès au registre.\n  - Expiration du jeton : maximum 1 an.\n  - Enregistrez le jeton de façon sécurisée.\n- Configurez l'accès au registre local :\n\n```shell\ndocker login registry.gitlab.com\n# The username if you are using a PAT is gitlab-ci-token\n# Password: your-access-token\n```\n\n#### 1. Création de votre application\n\nCommencez avec une application web de base. Dans notre exemple, nous utilisons une page HTML simple :\n\n```xml\n\u003C!|||UNTRANSLATED_CONTENT_START|||-- index.html -->\n\u003Chtml>\n  \u003Chead>\n    \u003Cstyle>\n      body {\n        background-color: #171321; /* GitLab dark */\n      }\n    \u003C/style>\n  \u003C/head>\n  \u003Cbody>\n    \u003C!|||UNTRANSLATED_CONTENT_END|||-- Your content here -->\n  \u003C/body>\n\u003C/html>\n```\n\n#### 2. Conteneurisation de votre application\n\nCréez un Dockerfile pour empaqueter votre application :\n\n```text\nFROM nginx:1.26.2\nCOPY index.html /usr/share/nginx/html/index.html\n```\n\nCe Dockerfile :\n\n- Utilise nginx comme image de base pour diffuser du contenu web\n- Copie votre fichier HTML au bon endroit dans la structure du répertoire nginx\n\n#### 3. Configuration de votre pipeline CI/CD\n\nCréez un fichier `.gitlab-ci.yml` pour définir les étapes de votre [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") :\n\n```text\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n\nstages:\n  - publish\n  - deploy\n```\n\nDécomposons ce code :\n\n`TAG_LATEST` est composé de trois parties :\n\n- `$CI_REGISTRY_IMAGE` est le chemin d'accès au registre des conteneurs de votre projet dans GitLab.\n\nPar exemple : `registry.gitlab.com/your-group/your-project`\n\n- `$CI_COMMIT_REF_NAME` est le nom de votre branche ou tag.\n\nPar exemple, si vous travaillez sur la branche principale : `/main`, et si vous travaillez sur une branche de fonctionnalité : `/feature-login`\n\n- `:latest` est un suffixe fixe.\n\nAinsi, si vous êtes sur la branche principale, `TAG_LATEST` devient `registry.gitlab.com/your-group/your-project/main:latest`.\n\n`TAG_COMMIT` est presque identique, mais au lieu de `:latest`, il utilise : `$CI_COMMIT_SHA`, qui est l'identifiant de commit, par exemple `:abc123def456`.\n\nAinsi, pour ce même commit sur la branche principale, `TAG_COMMIT` devient :` registry.gitlab.com/your-group/your-project/main:abc123def456`.\n\nLa présence de ces deux variables s'explique par le fait que `TAG_LATEST` vous permet facilement de toujours obtenir la version la plus récente. `TAG_COMMIT` vous fournit une version spécifique à laquelle vous pouvez revenir si nécessaire.\n\n#### 4. Publication dans le registre de conteneurs\n\nAjoutez le job de publication à votre pipeline :\n\n```text\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n```\n\nCe job :\n\n- Utilise Docker-in-Docker pour compiler des images\n- Crée deux versions avec tag de votre image\n- S'authentifie auprès du registre GitLab\n- Effectue un push des deux versions vers le registre\nMaintenant que vos images sont stockées de façon sécurisée dans le registre, vous pouvez vous concentrer sur leur déploiement dans vos environnements cibles. Commençons par des tests locaux pour valider notre configuration avant de passer aux déploiements dans l'environnement de production.\n\n#### 5. Déploiement dans votre environnement\n\nAvant le déploiement en production, vous pouvez effectuer un test localement. Nous venons de publier notre image dans le dépôt GitLab, pour lequel nous allons effectuer un pull localement. Si vous ne connaissez pas le chemin d'accès exact, accédez à **Déploiement > Registre de conteneurs**. Vous devriez voir une icône permettant de copier le chemin d'accès de votre image à la fin de la ligne pour l'image de conteneur que vous souhaitez tester.\n\n```shell\ndocker login registry.gitlab.com docker run -p 80:80 registry.gitlab.com/your-project-path/main:latest\n```\n\nCe faisant, vous devriez être en mesure d'accéder à votre application localement sur votre adresse localhost via votre navigateur web.\n\nVous pouvez maintenant ajouter un job de déploiement à votre pipeline :\n\n```text\ndeploy:\n  stage: deploy\n  image: alpine:latest\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$TARGET_SERVER       docker pull $TAG_COMMIT &&\n      docker rm -f myapp || true &&\n      docker run -d -p 80:80 --name myapp $TAG_COMMIT\n```\n\nCe job :\n\n- Configure l'accès SSH à votre cible de déploiement\n- Effectue un pull de l'image la plus récente\n- Supprime tout conteneur existant\n- Déploie la nouvelle version\n\n#### 6. Suivi des déploiements\n\nActivez le suivi des déploiements en ajoutant la configuration de l'environnement :\n\n```text\ndeploy:\n  environment:\n    name: production\n    url: https://your-application-url.com ```\n\nCela crée un objet environnement dans la section **Exploitation > Environnements** de GitLab et fournit :\n\n- L'historique de déploiement\n- Le statut de déploiement actuel\n- Un accès rapide à votre application\n\nBien qu'un pipeline d'environnement unique soit un bon point de départ, la plupart des équipes doivent gérer plusieurs environnements, dont des environnements de test et de préproduction. Étoffons notre pipeline pour gérer ce scénario plus réaliste.\n\n#### 7. Configuration de plusieurs environnements\n\nPour obtenir un pipeline plus robuste, configurez les déploiements de préproduction et de production :\n\n```text\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\nstaging:\n  stage: staging\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  environment:\n    name: staging\n    url: https://staging.your-app.com\n  # deployment script here\n\nproduction:\n  stage: production\n  rules:\n    - if: $CI_COMMIT_TAG\n  environment:\n    name: production\n    url: https://your-app.com\n  # deployment script here\n```\n\nCette configuration :\n\n- Effectue un déploiement vers l'environnement de préproduction à partir de votre branche principale\n- Utilise les tags GitLab pour déclencher les déploiements de production\n- Fournit un suivi distinct pour chaque environnement\n\nQue ce soit à cette étape ou à l'étape suivante, nous tirons parti des tags, qui sont une fonctionnalité très utile de GitLab. En créant manuellement un tag dans la section **Code > Tags**, `$CI_COMMIT_TAG` est créé, ce qui nous permet de déclencher des jobs en conséquence.\n\n#### 8. Création de notes de version automatisées\n\nNous utiliserons les fonctionnalités de gestion des versions de GitLab depuis notre pipeline CI/CD. Commencez par mettre à jour les étapes de votre pipeline CI/CD dans `.gitlab-ci.yml` :\n\n```yaml\nstages:\n\n- publish\n- staging\n- release # New stage for releases\n- version\n- production\n```\n\nEnsuite, ajoutez le job de release :\n\n```text\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG                  # Only run when a tag is created\n  script:\n    - echo \"Creating release for $CI_COMMIT_TAG\"\n  release:                                # Release configuration\n    name: 'Release $CI_COMMIT_TAG'\n    description: 'Release created from $CI_COMMIT_TAG'\n    tag_name: '$CI_COMMIT_TAG'           # The tag to create\n    ref: '$CI_COMMIT_TAG'                # The tag to base release on\n```\n\nVous pouvez l'améliorer en ajoutant des liens vers vos images de conteneurs :\n\n```text\nrelease:\n  name: 'Release $CI_COMMIT_TAG'\n  description: 'Release created from $CI_COMMIT_TAG'\n  tag_name: '$CI_COMMIT_TAG'\n  ref: '$CI_COMMIT_TAG'\n  assets:\n    links:\n      - name: 'Container Image'\n        url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n        link_type: 'image'\n```\n\nPour générer des notes de version automatisées pertinentes :\n\n- Utilisez des commits conventionnels (feat:, fix:, et autres commandes.).\n- Incluez les numéros de ticket (#123).\n- Séparez le sujet du corps par un saut de ligne.\n\nSi vous souhaitez des notes de version personnalisées avec des informations de déploiement :\n\n```text\nrelease_job:\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## Deployment Info\n      - Deployed on: $DEPLOY_TIME\n      - Environment: Production\n      - Version: $CI_COMMIT_TAG\n\n      ## Changes\n      $CHANGES\n\n      ## Artifacts\n      - Container Image: \\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    description: './release_notes.md'\n```\n\nUne fois configurées, les versions sont créées automatiquement lorsque vous ajoutez un tag [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \"). Vous pouvez les afficher dans GitLab sous **Déploiement > Releases**.\n\n#### 9. Assemblage\n\nVoici à quoi ressemble notre fichier YAML final :\n\n```text\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n  STAGING_TARGET: $STAGING_TARGET    # Set in CI/CD Variables\n  PRODUCTION_TARGET: $PRODUCTION_TARGET  # Set in CI/CD Variables\n\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\n# Build and publish to registry\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n\n# Deploy to staging\nstaging:\n  stage: staging\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$STAGING_TARGET \"\n        docker pull $TAG_COMMIT &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $TAG_COMMIT\"\n  environment:\n    name: staging\n    url: http://$STAGING_TARGET\n\n# Create release\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## Deployment Info\n      - Deployed on: $DEPLOY_TIME\n      - Environment: Production\n      - Version: $CI_COMMIT_TAG\n\n      ## Changes\n      $CHANGES\n\n      ## Artifacts\n      - Container Image: \\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: './release_notes.md'\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_TAG'\n    assets:\n      links:\n        - name: 'Container Image'\n          url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n          link_type: 'image'\n\n# Version the image with release tag\nversion_job:\n  stage: version\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - docker pull $TAG_COMMIT\n    - docker tag $TAG_COMMIT $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n\n# Deploy to production\nproduction:\n  stage: production\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$PRODUCTION_TARGET \"\n        docker pull $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\"\n  environment:\n    name: production\n    url: http://$PRODUCTION_TARGET\n```\n\nCe pipeline complet :\n\n- Publie des images dans le registre (branche principale)\n- Déploie vers l'environnement de préproduction (branche principale)\n- Crée des versions (lorsqu'un tag est ajouté)\n- Crée des versions d'images avec des tags de version - Déploie dans l'environnement de production (lorsqu'un tag est créé)\n\nPrincipaux avantages :\n\n- Environnement de développement et de test local propre et reproductible\n- Chemin d'accès clair vers les environnements de production avec une structure qui renforce la confiance dans ce qui est déployé\n- Modèle pour se remettre de défaillances inattendues, entre autres\n- Possibilité de développement sur cette base et d'adoption de stratégies de déploiement plus complexes\n\n### Bonnes pratiques\n\nTout au long de la mise en œuvre, respectez les principes suivants :\n\n- Documentez tout, de l'utilisation des variables aux procédures de déploiement.\n- Utilisez les fonctionnalités intégrées de GitLab (environnements, releases, registre).\n- Mettez en œuvre des contrôles d'accès et des mesures de sécurité adaptés.\n- Pensez aux éventuelles défaillances en mettant en place des procédures de restauration robustes.\n- Évitez les redondances dans vos configurations de pipeline en suivant le principe DRY (Don't Repeat Yourself).\n\n## Mise à l'échelle de votre stratégie de déploiement\n\nPour terminer, voici quelques aspects à prendre en compte à mesure que votre stratégie de déploiement continu évolue.\n\n### Mesures de sécurité avancées\n\nAméliorez la sécurité grâce aux fonctionnalités suivantes :\n\n- Environnements protégés avec accès restreint\n- Approbations requises pour les déploiements en production\n- Scanning de sécurité intégré\n- Évaluations automatisées des vulnérabilités\n- Règles de protection des branches pour les modifications liées au déploiement\n\n### Stratégies de livraison progressive\n\nMettez en œuvre des stratégies de déploiement avancées :\n\n- Feature flags pour les déploiements contrôlés\n- Déploiements canari pour l'atténuation des risques\n- Stratégies de déploiement bleu-vert\n- Capacités de test A/B\n- Gestion dynamique de l'environnement\n\n### Surveillance et optimisation\n\nMettez en place des pratiques de surveillance robustes :\n\n- Suivi des mesures de déploiement\n- Mise en place d'un suivi des performances\n- Configuration d'alertes de déploiement\n- Établissement d'objectifs de niveau de service (SLO) en matière de déploiement\n- Optimisation régulière du pipeline\n\n## Pourquoi utiliser GitLab ?\n\nLa plateforme GitLab est idéale pour les workflows de déploiement modernes grâce à ses fonctionnalités de déploiement continu. Elle permet de simplifier les étapes menant du code à la production, en offrant un registre de conteneurs intégré, une gestion de l'environnement et le suivi des déploiements au sein d'une seule interface. Les variables propres à l'environnement, les portes d'approbation de déploiement et les fonctionnalités de restauration de GitLab fournissent la sécurité et le contrôle nécessaires aux déploiements en production, tandis que les fonctionnalités telles que les versions temporaires d'applications et les feature flags offrent des approches de livraison progressive. Ces fonctionnalités de déploiement continu font partie intégrante de la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") complète de GitLab et s'intègrent parfaitement à l'ensemble du cycle de vie de vos logiciels.\n\n## Lancez-vous dès aujourd'hui\n\nOpter pour un déploiement continu est une évolution, pas une révolution. Commencez par les fondamentaux, établissez une base solide et intégrez progressivement des fonctionnalités avancées lorsque les besoins de votre équipe augmentent. GitLab fournit les outils et la flexibilité nécessaires pour vous accompagner à chaque étape de ce parcours, de votre premier déploiement automatisé aux pipelines de livraison complexes et multi-environnements.\n\n> [Essayez GitLab Ultimate gratuitement](https://about.gitlab.com/fr-fr/free-trial/devsecops/) et commencez votre déploiement continu dès aujourd'hui.",[25,26,27,10,28],"CD","CI/CD","features","tutorial","2025-03-24","yml",{},true,"/fr-fr/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"title":16,"description":17,"ogTitle":16,"ogDescription":17,"noIndex":13,"ogImage":21,"ogUrl":35,"ogSiteName":36,"ogType":37,"canonicalUrls":35},"https://about.gitlab.com/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab","https://about.gitlab.com","article","fr-fr/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",[40,41,27,10,28],"cd","cicd","XDDevWTi8MJZZyJU43-t1w2rvYMr6oRFN61ZftmV1vs",{"data":44},{"logo":45,"freeTrial":50,"sales":55,"login":60,"items":65,"search":374,"minimal":409,"duo":428,"pricingDeployment":437},{"config":46},{"href":47,"dataGaName":48,"dataGaLocation":49},"/fr-fr/","gitlab logo","header",{"text":51,"config":52},"Commencer un essai gratuit",{"href":53,"dataGaName":54,"dataGaLocation":49},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr&glm_content=default-saas-trial/","free trial",{"text":56,"config":57},"Contacter l'équipe commerciale",{"href":58,"dataGaName":59,"dataGaLocation":49},"/fr-fr/sales/","sales",{"text":61,"config":62},"Connexion",{"href":63,"dataGaName":64,"dataGaLocation":49},"https://gitlab.com/users/sign_in/","sign in",[66,93,189,194,295,355],{"text":67,"config":68,"cards":70},"Plateforme",{"dataNavLevelOne":69},"platform",[71,77,85],{"title":67,"description":72,"link":73},"La plateforme d'orchestration intelligente pour le DevSecOps",{"text":74,"config":75},"Découvrir notre plateforme",{"href":76,"dataGaName":69,"dataGaLocation":49},"/fr-fr/platform/",{"title":78,"description":79,"link":80},"GitLab Duo Agent Platform","L'IA agentique pour l'ensemble du cycle de développement logiciel",{"text":81,"config":82},"Découvrir GitLab Duo",{"href":83,"dataGaName":84,"dataGaLocation":49},"/fr-fr/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":86,"description":87,"link":88},"Choisir GitLab","Découvrez les principales raisons pour lesquelles les entreprises choisissent GitLab",{"text":89,"config":90},"En savoir plus",{"href":91,"dataGaName":92,"dataGaLocation":49},"/fr-fr/why-gitlab/","why gitlab",{"text":94,"left":32,"config":95,"link":97,"lists":101,"footer":171},"Produit",{"dataNavLevelOne":96},"solutions",{"text":98,"config":99},"Voir toutes les solutions",{"href":100,"dataGaName":96,"dataGaLocation":49},"/fr-fr/solutions/",[102,126,149],{"title":103,"description":104,"link":105,"items":110},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":106},{"icon":107,"href":108,"dataGaName":109,"dataGaLocation":49},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[111,114,117,122],{"text":26,"config":112},{"href":113,"dataGaLocation":49,"dataGaName":26},"/fr-fr/solutions/continuous-integration/",{"text":78,"config":115},{"href":83,"dataGaLocation":49,"dataGaName":116},"gitlab duo agent platform - product menu",{"text":118,"config":119},"Gestion du code source",{"href":120,"dataGaLocation":49,"dataGaName":121},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":123,"config":124},"Livraison de logiciels automatisée",{"href":108,"dataGaLocation":49,"dataGaName":125},"Automated software delivery",{"title":127,"description":128,"link":129,"items":134},"Sécurité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":130},{"href":131,"dataGaName":132,"dataGaLocation":49,"icon":133},"/fr-fr/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[135,139,144],{"text":136,"config":137},"Tests de sécurité des applications",{"href":131,"dataGaName":138,"dataGaLocation":49},"Application security testing",{"text":140,"config":141},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":142,"dataGaLocation":49,"dataGaName":143},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Conformité logicielle",{"href":147,"dataGaName":148,"dataGaLocation":49},"/fr-fr/solutions/software-compliance/","Software Compliance",{"title":150,"link":151,"items":156},"Mesures",{"config":152},{"icon":153,"href":154,"dataGaName":155,"dataGaLocation":49},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[157,161,166],{"text":158,"config":159},"Visibilité et mesures",{"href":154,"dataGaLocation":49,"dataGaName":160},"Visibility and Measurement",{"text":162,"config":163},"Gestion de la chaîne de valeur",{"href":164,"dataGaLocation":49,"dataGaName":165},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":167,"config":168},"Données d'analyse et informations clés",{"href":169,"dataGaLocation":49,"dataGaName":170},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":172,"items":173},"GitLab pour",[174,179,184],{"text":175,"config":176},"Entreprises",{"href":177,"dataGaLocation":49,"dataGaName":178},"/fr-fr/enterprise/","enterprise",{"text":180,"config":181},"PME",{"href":182,"dataGaLocation":49,"dataGaName":183},"/fr-fr/small-business/","small business",{"text":185,"config":186},"Secteur public",{"href":187,"dataGaLocation":49,"dataGaName":188},"/fr-fr/solutions/public-sector/","public sector",{"text":190,"config":191},"Tarifs",{"href":192,"dataGaName":193,"dataGaLocation":49,"dataNavLevelOne":193},"/fr-fr/pricing/","pricing",{"text":195,"config":196,"link":198,"lists":202,"feature":282},"Ressources",{"dataNavLevelOne":197},"resources",{"text":199,"config":200},"Afficher toutes les ressources",{"href":201,"dataGaName":197,"dataGaLocation":49},"/fr-fr/resources/",[203,236,254],{"title":204,"items":205},"Premiers pas",[206,211,216,221,226,231],{"text":207,"config":208},"Installation",{"href":209,"dataGaName":210,"dataGaLocation":49},"/fr-fr/install/","install",{"text":212,"config":213},"Guides de démarrage",{"href":214,"dataGaName":215,"dataGaLocation":49},"/fr-fr/get-started/","quick setup checklists",{"text":217,"config":218},"Apprentissage",{"href":219,"dataGaLocation":49,"dataGaName":220},"https://university.gitlab.com/","learn",{"text":222,"config":223},"Documentation sur le produit",{"href":224,"dataGaName":225,"dataGaLocation":49},"https://docs.gitlab.com/","product documentation",{"text":227,"config":228},"Vidéos sur les bonnes pratiques",{"href":229,"dataGaName":230,"dataGaLocation":49},"/fr-fr/getting-started-videos/","best practice videos",{"text":232,"config":233},"Intégrations",{"href":234,"dataGaName":235,"dataGaLocation":49},"/fr-fr/integrations/","integrations",{"title":237,"items":238},"Découvrir",[239,244,249],{"text":240,"config":241},"Témoignages clients",{"href":242,"dataGaName":243,"dataGaLocation":49},"/fr-fr/customers/","customer success stories",{"text":245,"config":246},"Blog",{"href":247,"dataGaName":248,"dataGaLocation":49},"/fr-fr/blog/","blog",{"text":250,"config":251},"Travail à distance",{"href":252,"dataGaName":253,"dataGaLocation":49},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":255,"items":256},"Connecter",[257,262,267,272,277],{"text":258,"config":259},"Services GitLab",{"href":260,"dataGaName":261,"dataGaLocation":49},"/fr-fr/services/","services",{"text":263,"config":264},"Communauté",{"href":265,"dataGaName":266,"dataGaLocation":49},"/community/","community",{"text":268,"config":269},"Forum",{"href":270,"dataGaName":271,"dataGaLocation":49},"https://forum.gitlab.com/","forum",{"text":273,"config":274},"Événements",{"href":275,"dataGaName":276,"dataGaLocation":49},"/events/","events",{"text":278,"config":279},"Partenaires",{"href":280,"dataGaName":281,"dataGaLocation":49},"/fr-fr/partners/","partners",{"backgroundColor":283,"textColor":284,"text":285,"image":286,"link":290},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":287,"config":288},"carte promo The Source",{"src":289},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":291,"config":292},"Lire les articles les plus récents",{"href":293,"dataGaName":294,"dataGaLocation":49},"/fr-fr/the-source/","the source",{"text":296,"config":297,"lists":299},"Société",{"dataNavLevelOne":298},"company",[300],{"items":301},[302,307,313,315,320,325,330,335,340,345,350],{"text":303,"config":304},"À propos",{"href":305,"dataGaName":306,"dataGaLocation":49},"/fr-fr/company/","about",{"text":308,"config":309,"footerGa":312},"Carrières",{"href":310,"dataGaName":311,"dataGaLocation":49},"/jobs/","jobs",{"dataGaName":311},{"text":273,"config":314},{"href":275,"dataGaName":276,"dataGaLocation":49},{"text":316,"config":317},"Leadership",{"href":318,"dataGaName":319,"dataGaLocation":49},"/company/team/e-group/","leadership",{"text":321,"config":322},"Équipe",{"href":323,"dataGaName":324,"dataGaLocation":49},"/company/team/","team",{"text":326,"config":327},"Manuel",{"href":328,"dataGaName":329,"dataGaLocation":49},"https://handbook.gitlab.com/","handbook",{"text":331,"config":332},"Relations avec les investisseurs",{"href":333,"dataGaName":334,"dataGaLocation":49},"https://ir.gitlab.com/","investor relations",{"text":336,"config":337},"Centre de confiance",{"href":338,"dataGaName":339,"dataGaLocation":49},"/fr-fr/security/","trust center",{"text":341,"config":342},"Centre pour la transparence de l'IA",{"href":343,"dataGaName":344,"dataGaLocation":49},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":346,"config":347},"Newsletter",{"href":348,"dataGaName":349,"dataGaLocation":49},"/company/contact/#contact-forms","newsletter",{"text":351,"config":352},"Presse",{"href":353,"dataGaName":354,"dataGaLocation":49},"/press/","press",{"text":356,"config":357,"lists":358},"Nous contacter",{"dataNavLevelOne":298},[359],{"items":360},[361,364,369],{"text":56,"config":362},{"href":58,"dataGaName":363,"dataGaLocation":49},"talk to sales",{"text":365,"config":366},"Portail d’assistance",{"href":367,"dataGaName":368,"dataGaLocation":49},"https://support.gitlab.com","support portal",{"text":370,"config":371},"Portail clients GitLab",{"href":372,"dataGaName":373,"dataGaLocation":49},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":375,"login":376,"suggestions":383},"Fermer",{"text":377,"link":378},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":379,"config":380},"gitlab.com",{"href":63,"dataGaName":381,"dataGaLocation":382},"search login","search",{"text":384,"default":385},"Suggestions",[386,388,393,395,400,405],{"text":78,"config":387},{"href":83,"dataGaName":78,"dataGaLocation":382},{"text":389,"config":390},"Suggestions de code (IA)",{"href":391,"dataGaName":392,"dataGaLocation":382},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":26,"config":394},{"href":113,"dataGaName":26,"dataGaLocation":382},{"text":396,"config":397},"GitLab sur AWS",{"href":398,"dataGaName":399,"dataGaLocation":382},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":401,"config":402},"GitLab sur Google Cloud ",{"href":403,"dataGaName":404,"dataGaLocation":382},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":406,"config":407},"Pourquoi utiliser GitLab ?",{"href":91,"dataGaName":408,"dataGaLocation":382},"Why GitLab?",{"freeTrial":410,"mobileIcon":415,"desktopIcon":420,"secondaryButton":423},{"text":411,"config":412},"Commencer votre essai gratuit",{"href":413,"dataGaName":54,"dataGaLocation":414},"https://gitlab.com/-/trials/new/","nav",{"altText":416,"config":417},"Icône GitLab",{"src":418,"dataGaName":419,"dataGaLocation":414},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":416,"config":421},{"src":422,"dataGaName":419,"dataGaLocation":414},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":424,"config":425},"Commencer",{"href":426,"dataGaName":427,"dataGaLocation":414},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr/get-started/","get started",{"freeTrial":429,"mobileIcon":433,"desktopIcon":435},{"text":430,"config":431},"En savoir plus sur GitLab Duo",{"href":83,"dataGaName":432,"dataGaLocation":414},"gitlab duo",{"altText":416,"config":434},{"src":418,"dataGaName":419,"dataGaLocation":414},{"altText":416,"config":436},{"src":422,"dataGaName":419,"dataGaLocation":414},{"freeTrial":438,"mobileIcon":443,"desktopIcon":445},{"text":439,"config":440},"Retour aux tarifs",{"href":192,"dataGaName":441,"dataGaLocation":414,"icon":442},"back to pricing","GoBack",{"altText":416,"config":444},{"src":418,"dataGaName":419,"dataGaLocation":414},{"altText":416,"config":446},{"src":422,"dataGaName":419,"dataGaLocation":414},{"title":448,"button":449,"config":454},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":450,"config":451},"Regarder GitLab Transcend maintenant",{"href":452,"dataGaName":453,"dataGaLocation":49},"/fr-fr/events/transcend/virtual/","transcend event",{"layout":455,"icon":456,"disabled":32},"release","AiStar",{"data":458},{"text":459,"source":460,"edit":466,"contribute":471,"config":476,"items":481,"minimal":658},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":461,"config":462},"Afficher le code source de la page",{"href":463,"dataGaName":464,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":467,"config":468},"Modifier cette page",{"href":469,"dataGaName":470,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":472,"config":473},"Veuillez contribuer",{"href":474,"dataGaName":475,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":477,"facebook":478,"youtube":479,"linkedin":480},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[482,505,559,591,626],{"title":67,"links":483,"subMenu":488},[484],{"text":485,"config":486},"Plateforme DevSecOps",{"href":76,"dataGaName":487,"dataGaLocation":465},"devsecops platform",[489],{"title":190,"links":490},[491,495,500],{"text":492,"config":493},"Voir les forfaits",{"href":192,"dataGaName":494,"dataGaLocation":465},"view plans",{"text":496,"config":497},"Pourquoi choisir GitLab Premium ?",{"href":498,"dataGaName":499,"dataGaLocation":465},"/fr-fr/pricing/premium/","why premium",{"text":501,"config":502},"Pourquoi choisir GitLab Ultimate ?",{"href":503,"dataGaName":504,"dataGaLocation":465},"/fr-fr/pricing/ultimate/","why ultimate",{"title":506,"links":507},"Solutions",[508,513,516,518,523,528,532,535,538,543,545,547,549,554],{"text":509,"config":510},"Transformation digitale",{"href":511,"dataGaName":512,"dataGaLocation":465},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":514,"config":515},"Sécurité et conformité",{"href":131,"dataGaName":138,"dataGaLocation":465},{"text":123,"config":517},{"href":108,"dataGaName":109,"dataGaLocation":465},{"text":519,"config":520},"Développement agile",{"href":521,"dataGaName":522,"dataGaLocation":465},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":524,"config":525},"Transformation cloud",{"href":526,"dataGaName":527,"dataGaLocation":465},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":529,"config":530},"SCM",{"href":120,"dataGaName":531,"dataGaLocation":465},"source code management",{"text":26,"config":533},{"href":113,"dataGaName":534,"dataGaLocation":465},"continuous integration & delivery",{"text":162,"config":536},{"href":164,"dataGaName":537,"dataGaLocation":465},"value stream management",{"text":539,"config":540},"GitOps",{"href":541,"dataGaName":542,"dataGaLocation":465},"/fr-fr/solutions/gitops/","gitops",{"text":175,"config":544},{"href":177,"dataGaName":178,"dataGaLocation":465},{"text":180,"config":546},{"href":182,"dataGaName":183,"dataGaLocation":465},{"text":185,"config":548},{"href":187,"dataGaName":188,"dataGaLocation":465},{"text":550,"config":551},"Formation",{"href":552,"dataGaName":553,"dataGaLocation":465},"/fr-fr/solutions/education/","education",{"text":555,"config":556},"Services financiers",{"href":557,"dataGaName":558,"dataGaLocation":465},"/fr-fr/solutions/finance/","financial services",{"title":195,"links":560},[561,563,566,568,571,573,576,579,581,583,585,587,589],{"text":207,"config":562},{"href":209,"dataGaName":210,"dataGaLocation":465},{"text":564,"config":565},"Guides de démarrage rapide",{"href":214,"dataGaName":215,"dataGaLocation":465},{"text":217,"config":567},{"href":219,"dataGaName":220,"dataGaLocation":465},{"text":222,"config":569},{"href":224,"dataGaName":570,"dataGaLocation":465},"docs",{"text":245,"config":572},{"href":247,"dataGaName":248},{"text":574,"config":575},"Histoires de réussite client",{"href":242,"dataGaLocation":465},{"text":577,"config":578},"Histoires de succès client",{"href":242,"dataGaName":243,"dataGaLocation":465},{"text":250,"config":580},{"href":252,"dataGaName":253,"dataGaLocation":465},{"text":258,"config":582},{"href":260,"dataGaName":261,"dataGaLocation":465},{"text":263,"config":584},{"href":265,"dataGaName":266,"dataGaLocation":465},{"text":268,"config":586},{"href":270,"dataGaName":271,"dataGaLocation":465},{"text":273,"config":588},{"href":275,"dataGaName":276,"dataGaLocation":465},{"text":278,"config":590},{"href":280,"dataGaName":281,"dataGaLocation":465},{"title":296,"links":592},[593,595,598,600,602,604,606,610,615,617,619,621],{"text":303,"config":594},{"href":305,"dataGaName":298,"dataGaLocation":465},{"text":596,"config":597},"Emplois",{"href":310,"dataGaName":311,"dataGaLocation":465},{"text":316,"config":599},{"href":318,"dataGaName":319,"dataGaLocation":465},{"text":321,"config":601},{"href":323,"dataGaName":324,"dataGaLocation":465},{"text":326,"config":603},{"href":328,"dataGaName":329,"dataGaLocation":465},{"text":331,"config":605},{"href":333,"dataGaName":334,"dataGaLocation":465},{"text":607,"config":608},"Sustainability",{"href":609,"dataGaName":607,"dataGaLocation":465},"/sustainability/",{"text":611,"config":612},"Diversité, inclusion et appartenance (DIB)",{"href":613,"dataGaName":614,"dataGaLocation":465},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":336,"config":616},{"href":338,"dataGaName":339,"dataGaLocation":465},{"text":346,"config":618},{"href":348,"dataGaName":349,"dataGaLocation":465},{"text":351,"config":620},{"href":353,"dataGaName":354,"dataGaLocation":465},{"text":622,"config":623},"Déclaration de transparence sur l'esclavage moderne",{"href":624,"dataGaName":625,"dataGaLocation":465},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":356,"links":627},[628,631,636,638,643,648,653],{"text":629,"config":630},"Échanger avec un expert",{"href":58,"dataGaName":59,"dataGaLocation":465},{"text":632,"config":633},"Aide",{"href":634,"dataGaName":635,"dataGaLocation":465},"https://support.gitlab.com/hc/en-us/articles/11626483177756-GitLab-Support","get help",{"text":370,"config":637},{"href":372,"dataGaName":373,"dataGaLocation":465},{"text":639,"config":640},"Statut",{"href":641,"dataGaName":642,"dataGaLocation":465},"https://status.gitlab.com/","status",{"text":644,"config":645},"Conditions d'utilisation",{"href":646,"dataGaName":647},"/terms/","terms of use",{"text":649,"config":650},"Déclaration de confidentialité",{"href":651,"dataGaName":652,"dataGaLocation":465},"/fr-fr/privacy/","privacy statement",{"text":654,"config":655},"Préférences en matière de cookies",{"dataGaName":656,"dataGaLocation":465,"id":657,"isOneTrustButton":32},"cookie preferences","ot-sdk-btn",{"items":659},[660,662,665],{"text":644,"config":661},{"href":646,"dataGaName":647,"dataGaLocation":465},{"text":663,"config":664},"Politique de confidentialité",{"href":651,"dataGaName":652,"dataGaLocation":465},{"text":654,"config":666},{"dataGaName":656,"dataGaLocation":465,"id":657,"isOneTrustButton":32},[668,681],{"id":669,"title":19,"body":9,"config":670,"content":672,"description":9,"extension":30,"meta":676,"navigation":32,"path":677,"seo":678,"stem":679,"__hash__":680},"blogAuthors/en-us/blog/authors/benjamin-skierlak.yml",{"template":671},"BlogAuthor",{"name":19,"config":673},{"headshot":674,"ctfId":675},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659471/Blog/Author%20Headshots/Benjamin_Skierlak_headshot.png","Kzp6pkUjPORYYMoeLFPRf",{},"/en-us/blog/authors/benjamin-skierlak",{},"en-us/blog/authors/benjamin-skierlak","RbLU9KGFtah9Juo58JyxfHHYNIU4fyzzOUb5p7-fubo",{"id":682,"title":20,"body":9,"config":683,"content":684,"description":9,"extension":30,"meta":688,"navigation":32,"path":689,"seo":690,"stem":691,"__hash__":692},"blogAuthors/en-us/blog/authors/james-wormwell.yml",{"template":671},{"name":20,"config":685},{"headshot":686,"ctfId":687},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659474/Blog/Author%20Headshots/james_wormwell_headshot.png","CPPijHb0Op5C5aVcvsOEf",{},"/en-us/blog/authors/james-wormwell",{},"en-us/blog/authors/james-wormwell","n6G4XENUWxgqOdCgfG0ECu0Uqj7qOS9zr3Rl8ouF49M",[694,708,720],{"content":695,"config":706},{"title":696,"description":697,"authors":698,"heroImage":700,"date":701,"body":702,"category":10,"tags":703},"GitLab 18.11 : garde-fous budgétaires pour les GitLab Credits","Découvrez comment les plafonds de dépenses et les limites de crédits par utilisateur offrent aux organisations les garde-fous budgétaires nécessaires pour déployer GitLab Duo Agent Platform à grande échelle.",[699],"Bryan Rothwell","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1776259080/cakqnwo5ecp255lo8lzo.png","2026-04-17","Les équipes qui utilisent GitLab Duo Agent Platform avec des crédits GitLab à la demande livrent plus rapidement, détectent les bogues plus tôt et automatisent des tâches qui mobilisaient auparavant des sprints entiers. Mais à mesure que l'adoption progresse, les équipes finances, achats et plateforme exigent des preuves que les dépenses liées à l'IA sont encadrées, prévisibles et maîtrisables.\n\nL'un des principaux freins à une adoption plus large de l'IA n'est pas le scepticisme vis-à-vis de la technologie : c'est l'incertitude quant à la maîtrise des dépenses. Sans plafond budgétaire, un mois particulièrement chargé pourrait engendrer des dépenses imprévues. Sans limites par utilisateur, une poignée d'utilisateurs intensifs pourrait épuiser les crédits de l'équipe avant la fin du mois. Et sans aucun de ces mécanismes, les responsables techniques qui souhaitent étendre l'utilisation de l'IA agentique pour le développement logiciel doivent multiplier les démarches pour obtenir les validations budgétaires.\n\nDepuis sa [disponibilité générale](https://about.gitlab.com/fr-fr/blog/gitlab-duo-agent-platform-is-generally-available/), GitLab Duo Agent Platform offre des fonctionnalités de gouvernance et de visibilité sur l'utilisation. Avec GitLab 18.11, nous introduisons des contrôles d'utilisation pour [GitLab Credits](https://about.gitlab.com/fr-fr/blog/introducing-gitlab-credits/) : des plafonds de dépenses et des garde-fous budgétaires qui donnent à votre organisation encore plus de contrôle et de transparence sur la consommation des crédits.\n\n## Gestion de GitLab Credits\n\nGitLab 18.11 ajoute trois niveaux de contrôle sur la consommation des GitLab Credits : un plafond de dépenses au niveau de l'abonnement, des limites de crédits par utilisateur et une visibilité sur l'état et l'application des plafonds.\n\n### Plafond de dépenses au niveau de l'abonnement\n\nLes responsables de facturation peuvent désormais définir un plafond mensuel strict pour la consommation de crédits GitLab à la demande sur l'ensemble de leur abonnement.\n\nVoici comment cela fonctionne :\n\n* **Définissez un plafond** dans le `portail clients`, dans les paramètres de votre abonnement relatifs à GitLab Credits.\n\n* **Appliquez automatiquement les limites de dépenses.** Lorsque la consommation à la demande atteint le plafond, l'accès à GitLab Duo Agent Platform est suspendu pour tous les utilisateurs de l'abonnement jusqu'au début de la période mensuelle suivante.\n\n* **Ajustez en cours de route.** Augmentez ou désactivez le plafond en cours de mois pour rétablir l'accès.\n\nLe plafond se réinitialise à chaque période mensuelle et la limite configurée est reconduite automatiquement, sauf si vous la modifiez. Étant donné que les données d'utilisation sont synchronisées périodiquement plutôt qu'en temps réel, un léger dépassement peut survenir après que le plafond est atteint, avant que l'application ne prenne effet. Consultez la [documentation relative à GitLab Credits](https://docs.gitlab.com/subscriptions/gitlab_credits/) pour plus de détails.\n\n### Plafonds de dépenses par utilisateur\n\nIl est naturel que tous les utilisateurs ne consomment pas les crédits au même rythme. Mais lorsqu'un ou deux utilisateurs intensifs consomment une part disproportionnée du pool, le reste de l'équipe peut perdre son accès à l'IA avant la fin du mois.\n\nLes plafonds de crédits par utilisateur empêchent qu'un seul utilisateur consomme plus que la part qui lui est allouée :\n\n* **Plafond forfaitaire par utilisateur.** Définissez une limite de crédits forfaitaire qui s'applique de manière égale à chaque utilisateur de l'abonnement via l'API GraphQL de GitLab. Contrairement au plafond au niveau de l'abonnement, le plafond par utilisateur s'applique à la consommation totale d'un utilisateur, toutes sources de crédits confondues.\n\n* **Limites personnalisées par utilisateur.** Pour les organisations qui ont besoin de limites différenciées, vous pouvez définir des plafonds de crédits individuels pour des utilisateurs spécifiques via l'API GraphQL. Par exemple, vous pourriez accorder une allocation plus élevée à vos staff engineers tout en appliquant une limite standard au reste de l'équipe.\n\n* **Application individuelle.** Lorsqu'un utilisateur atteint son plafond, il conserve un accès complet à GitLab. Seule sa consommation de crédits GitLab Duo Agent Platform est suspendue jusqu'au prochain cycle de facturation. Tous les autres membres de l'équipe continuent à travailler sans interruption jusqu'à atteindre leur propre limite ou le plafond au niveau de l'abonnement, selon la première éventualité.\n\n### Visibilité et notifications\n\nLorsqu'un plafond au niveau de l'abonnement est atteint, GitLab envoie une notification par e-mail aux responsables de facturation afin qu'ils puissent agir : augmenter le plafond, attendre la période suivante ou redistribuer les crédits.\n\nDans GitLab, les propriétaires de groupe (GitLab.com) et les administrateurs d'instance (GitLab Self-Managed) peuvent consulter les utilisateurs bloqués en raison de l'atteinte de leur plafond par utilisateur et rétablir l'accès en ajustant le plafond via l'API GraphQL.\n\n## Comment les garde-fous budgétaires aident les organisations à déployer l'IA à grande échelle\n\nLes garde-fous sont essentiels à mesure que les organisations accélèrent leur adoption de l'IA. Voici pourquoi :\n\n### Des budgets d'IA prévisibles\n\nLes contrôles d'utilisation de GitLab Duo Agent Platform transforment l'IA en un poste budgétaire encadré et prévisible grâce aux crédits GitLab à la demande. Il devient ainsi plus facile de déployer des agents sur l'ensemble du cycle de développement logiciel, d'obtenir la validation des équipes financières, de justifier les renouvellements et de planifier les dépenses trimestrielles.\n\n### Gouvernance et refacturation interne\n\nLes grandes organisations doivent souvent aligner la consommation d'IA sur leurs budgets internes, centres de coûts ou politiques de départements. Les plafonds par utilisateur offrent aux équipes plateforme un mécanisme simple pour répartir les crédits équitablement et suivre la consommation au niveau individuel. Les options d'importation par API facilitent la gestion des plafonds à l'échelle de l'entreprise. En combinant les plafonds par utilisateur aux données d'utilisation par utilisateur du tableau de bord GitLab Credits, les organisations peuvent analyser les tendances de consommation pour alimenter leurs propres processus de refacturation interne ou d'allocation budgétaire.\n\n### La confiance pour passer à l'échelle\n\nDe nombreux clients commencent à utiliser GitLab Duo Agent Platform avec un petit groupe pilote. Les contrôles d'utilisation éliminent les risques associés à l'extension de ce pilote à l'ensemble de l'organisation. Vous pouvez déployer GitLab Duo Agent Platform auprès de centaines, voire de milliers de développeurs, en sachant qu'un plafond strict protège votre budget. Si la consommation augmente plus vite que prévu, vous atteindrez le plafond, sans facture inattendue.\n\n## Dépasser le dilemme de la tarification par siège et du manque de visibilité\n\nDe nombreux outils de programmation assistée par l'IA adoptent une approche par siège pour la gestion des coûts. Vous achetez un nombre fixe de sièges à un prix forfaitaire par utilisateur, et c'est votre budget. L'approche est simple, mais rigide. Vous payez le même montant, qu'un développeur utilise l'outil dix fois par jour ou n'y touche jamais. Et à mesure que les éditeurs introduisent des modèles premium et des dépassements basés sur l'utilisation en plus de la tarification par siège, la prévisibilité des coûts promise par ce modèle commence à s'éroder.\n\nGitLab adopte une approche différente : une tarification à l'usage avec des plafonds stricts et un tableau de bord de gouvernance unifié. Vous profitez d'une véritable flexibilité : vous ne payez que ce que vos équipes consomment réellement et pouvez prévoir un budget grâce aux limites de dépenses appliquées automatiquement.\n\n## Exemples concrets de contrôles d'utilisation\n\n**Prenons l'exemple d'une entreprise cliente SaaS de taille moyenne qui souhaite respecter son budget mensuel.** Une entreprise d'ingénierie de 200 personnes définit un plafond au niveau de l'abonnement correspondant à sa consommation à la demande prévue. Le VP Engineering peut affirmer avec certitude aux équipes financières que les dépenses liées à GitLab Duo Agent Platform ne dépasseront jamais le montant approuvé, même lors de l'intégration de nouvelles équipes. Si l'organisation approche du plafond en cours de mois, le responsable de facturation reçoit une notification et peut décider d'augmenter la limite ou d'attendre la période suivante.\n\n**Chez GitLab, nous travaillons également avec de grandes entreprises qui souhaitent garantir une utilisation équitable entre les équipes.** Une société de services financiers internationale comptant 2 000 développeurs utilise les plafonds par utilisateur pour assurer un accès équitable. Les ingénieurs seniors travaillant sur des projets de refactorisation complexes bénéficient d'une allocation individuelle plus élevée via l'API, tandis que la majorité des développeurs profite d'un plafond forfaitaire standard. Aucun utilisateur ne peut épuiser le pool à lui seul, et l'équipe plateforme utilise les données d'utilisation par utilisateur du tableau de bord GitLab Credits pour analyser les tendances de consommation et concevoir la planification budgétaire trimestrielle.\n\n## Premiers pas\n\nLes contrôles d'utilisation sont disponibles pour les clients GitLab.com et GitLab Self-Managed dès la version GitLab 18.11. Les contrôles sont configurés à différents emplacements selon la portée et votre rôle.\n\n**Plafond au niveau de l'abonnement**\n\nLes responsables de facturation définissent le plafond à la demande au niveau de l'abonnement dans le portail client :\n\n1. Connectez-vous au `Portail clients`.\n\n2. Sur la carte de votre abonnement, accédez aux paramètres de **GitLab Credits**.\n\n3. Activez le plafond mensuel de crédits à la demande et saisissez la limite souhaitée.\n\n**Plafond forfaitaire par utilisateur**\n\nLe plafond forfaitaire par utilisateur peut être défini via l'API GraphQL de GitLab par les propriétaires d'espace de nommage (GitLab.com) ou les administrateurs d'instance (GitLab Self-Managed). Consultez la [documentation relative à GitLab Credits](https://docs.gitlab.com/subscriptions/gitlab_credits/) pour les dernières informations sur les interfaces de configuration disponibles.\n\n**Limites personnalisées par utilisateur**\n\nPour des limites différenciées, les propriétaires d'espace de nommage (GitLab.com) et les administrateurs d'instance (Self-Managed) peuvent définir des plafonds individuels par programmation. Cette option est particulièrement utile pour les workflows d'automatisation et d'Infrastructure as Code.\n\n**Suivi de l'utilisation et de l'état des plafonds**\n\n* **Portail client :** consultez l'utilisation détaillée et l'état des plafonds.\n\n* **GitLab.com :** les propriétaires de groupe peuvent consulter les utilisateurs bloqués sous **Paramètres > GitLab Credits**.\n\n* **GitLab Self-Managed :** les administrateurs d'instance peuvent consulter l'état des plafonds et les utilisateurs bloqués sous **Admin > GitLab Credits**.\n\n## GitLab Duo Agent Platform est prêt à passer à l'échelle\n\nLes contrôles d'utilisation sont disponibles dès maintenant dans GitLab 18.11. Si vous attendiez les bons garde-fous avant de déployer GitLab Duo Agent Platform à l'échelle de votre organisation, c'est le moment. Définissez vos plafonds, déployez GitLab Duo Agent Platform auprès de davantage d'équipes et accélérez vos livraisons !\n\n> [En savoir plus sur GitLab Credits et les contrôles d'utilisation](https://docs.gitlab.com/subscriptions/gitlab_credits/).",[10,704,705],"AI/ML","news",{"featured":13,"template":14,"slug":707},"gitlab-18-11-budget-guardrails-for-gitlab-credits",{"content":709,"config":718},{"title":710,"description":711,"authors":712,"heroImage":714,"date":701,"body":715,"category":10,"tags":716},"GitLab 18.11 : automatisez la correction des vulnérabilités avec l'IA","Avec GitLab 18.11, Agentic SAST Vulnerability Resolution est désormais en disponibilité générale.",[713],"Alisa Ho","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776259080/cakqnwo5ecp255lo8lzo.png","L’IA génère du code plus vite que n’importe quelle équipe de sécurité ne peut en assurer la revue. Ce qui constituait autrefois un backlog gérable de vulnérabilités détectées par les tests statiques de sécurité des applications (SAST) est désormais une liste écrasante et difficile à analyser. Demander aux équipes de développement de rechercher et de corriger manuellement chaque vulnérabilité n’est pas un processus, c’est un goulot d’étranglement. La solution ne réside pas dans un effort humain accru, mais dans un pipeline autonome. [Agentic SAST Vulnerability Resolution](https://docs.gitlab.com/user/application_security/vulnerabilities/agentic_vulnerability_resolution/) intégré à GitLab Duo Agent Platform a été conçue précisément pour répondre à ce problème.\n\nDésormais en disponibilité générale, Agentic SAST Vulnerability Resolution génère automatiquement des correctifs de code prêts à être fusionnés pour remédier aux vulnérabilités SAST. Grâce à cette fonctionnalité :\n\n* Les équipes de développement restent concentrées sur leur travail\n\n* Les vulnérabilités sont résolues avant d’atteindre l'environnement de production\n\n* Les équipes AppSec consacrent moins de temps au classement et à la coordination avec les équipes\n\nAgentic SAST Vulnerability Resolution représente l’avenir de la sécurité des applications. La version GitLab 18.11 offre également des scans SAST plus rapides, une priorisation plus intelligente et une gouvernance renforcée sur l’ensemble de la plateforme.\n\n## Une correction automatique sans interrompre votre workflow\n\nLorsque l’IA génère du code à grande échelle, l'équation change. Un backlog de sécurité qui progressait autrefois de façon linéaire s’accroît désormais de manière exponentielle à chaque commit assisté par un modèle. Il n’existe aucune solution à ce problème qui consiste à demander aux équipes de développement de changer de contexte plus souvent et de continuer à corriger manuellement des vulnérabilités. Selon le [rapport DevSecOps 2025 de GitLab](https://about.gitlab.com/fr-fr/blog/devsecops-report-france/), les équipes de développement consacrent déjà 11 heures par mois à corriger des vulnérabilités après la mise en production, c’est-à-dire à résoudre des problèmes déjà exploitables en production au lieu de livrer de nouvelles fonctionnalités.\n\nAgentic SAST Vulnerability Resolution transforme l’économie de ce cycle. Lorsqu’un scan SAST est terminé, les résultats déclenchent automatiquement le flow de [SAST false positive detection](https://docs.gitlab.com/user/application_security/vulnerabilities/false_positive_detection/). Les risques confirmés sont directement intégrés au flow Agentic SAST Vulnerability Resolution, où GitLab Duo Agent Platform :\n\n\n* Analyse la vulnérabilité dans son contexte\n\n* Génère un correctif qui traite la cause profonde\n\n* Valide le correctif à l'aide de tests automatisés\n\nL’équipe de développement reçoit une merge request prête à être fusionnée, accompagnée d’un score de confiance, afin de prendre une décision éclairée sur la manière de corriger la vulnérabilité. Le sprint reste dans les temps, les équipes de développement restent concentrés sur leur travail et les vulnérabilités sont résolues avant d’atteindre l'environnement de production.\n\nAccélérer la production logicielle implique également de ne pas attendre les résultats de votre scanner. GitLab 18.11 introduit le [scan incrémental pour Advanced SAST](https://docs.gitlab.com/user/application_security/sast/gitlab_advanced_sast/#incremental-scanning), permettant aux équipes de développement d’obtenir les résultats relatifs aux vulnérabilités sans attendre la fin d’un scan complet, et aux pipelines de continuer d'avancer.\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1183195999?badge=0&autopause=0&player_id=0&app_id=58479%2Fembed\" allow=\"autoplay; fullscreen; picture-in-picture\" allowfullscreen=\"\" frameborder=\"0\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\">\u003C/iframe>\n\n\n## Une remédiation en fonction du risque métier\n\nLa correction autonome ne fonctionne que si le signal qui la déclenche est fiable. Lorsque les scores de sévérité ne reflètent pas l’exploitabilité réelle, les équipes de développement cessent de faire confiance au signal et commencent à l’ignorer.\n\nGitLab 18.11 répond à ce problème sur quatre niveaux. Premièrement, les [scores de vulnérabilité](https://docs.gitlab.com/user/application_security/vulnerabilities/severities/#critical-severity) s’appuient désormais sur le Common Vulnerability Scoring System (CVSS) 4.0, la norme la plus récente du secteur, avec des métriques plus granulaires qui reflètent davantage l’exploitabilité réelle. Le score affiché dans GitLab correspond ainsi à la norme du secteur la plus à jour pour mesurer le risque réel.\n\nLes équipes AppSec peuvent ensuite définir des [règles basées sur des politiques](https://docs.gitlab.com/user/application_security/policies/vulnerability_management_policy/#severity-override-policies) qui ajustent automatiquement les scores de sévérité des vulnérabilités en fonction de signaux tels que les Common Vulnerabilities and Exposures (CVE), les Common Weakness Enumeration (CWE) et le le chemin d'accès au fichier/répertoire. Une fois la politique définie, les modifications de sévérité s’appliquent immédiatement, permettant aux équipes de développement de travailler à partir d’un backlog qui reflète le risque métier réel, et non les résultats bruts du scanner.\n\nL'application des règles en fonction des risques ne se limite pas au backlog. Les équipes AppSec peuvent désormais configurer des [politiques d’approbation pour bloquer](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/#vulnerability_attributes-object) ou émettre des alertes en fonction du statut Known Exploited Vulnerabilities (KEV) ou des seuils de score Exploit Prediction Scoring System (EPSS). Lorsqu’un merge est bloqué, les équipes de développement savent que c’est parce que la vulnérabilité s'appuie sur des données d’exploitabilité réelles, et non sur un score qui ne tenait pas compte de leur environnement.\n\nEnfin, le [nouveau graphique du tableau de bord de sécurité Top CWEs](https://docs.gitlab.com/user/application_security/security_dashboard/#top-10-cwes) offre aux équipes une visibilité sur les classes de vulnérabilités qui apparaissent le plus fréquemment dans leurs projets. Plutôt que de traiter les résultats individuellement, les équipes peuvent identifier des tendances, établir des priorités au niveau de la cause profonde et traiter les risques systémiques avant qu’ils ne s’aggravent.\n\n## Des contrôles de sécurité renforcés avec moins de charge opérationnelle\n\nL'efficacité d'un pipeline de correction autonome dépend entièrement de la couverture offerte par le scanner de sécurité sur lequel il s'appuie. Si la configuration du scanner est incohérente, les résultats transmis au pipeline sont incomplets, tout comme les correctifs.\n\nGitLab 18.11 introduit le [Security Manager](https://docs.gitlab.com/user/permissions/#default-roles), un nouveau rôle par défaut conçu spécifiquement pour les professionnels de la sécurité. Grâce au rôle Security Manager, les équipes de sécurité peuvent appliquer des scanners de sécurité, définir et configurer des politiques de sécurité, gérer les workflows de classement et de correction des vulnérabilités, et maintenir les frameworks de conformité et les flux d’audit, sans avoir besoin d’autorisations de modification du code ou de déploiement. Les équipes de sécurité disposent ainsi des accès nécessaires à leur travail, et rien de plus, ce qui permet de limiter les autorisations au travail à accomplir et de laisser les autorisations relatives au code et au déploiement aux équipes de développement.\n\nPour les équipes AppSec, obtenir une couverture cohérente du scanner SAST sur plusieurs projets et groupes est désormais beaucoup plus simple. Les [profils de configuration SAST](https://docs.gitlab.com/user/application_security/configuration/security_configuration_profiles/) offrent aux équipes de sécurité un espace unique pour définir la configuration des scans une seule fois et l’appliquer à tous les projets d’un groupe en une seule action. Les équipes n'ont plus besoin de rédiger et de maintenir des fichiers de politique YAML, de dépendre des équipes de développement pour configurer les scanners, ni de vérifier manuellement chaque projet pour identifier les lacunes de couverture.\n\n## Commencer dès aujourd’hui avec la remédiation agentique des vulnérabilités\n\nGitLab 18.11 offre un workflow complet de [gestion des vulnérabilités](https://about.gitlab.com/fr-fr/blog/what-is-vulnerability-management/ \"Gestion des vulnérabilités\") sur une seule plateforme : une IA qui corrige automatiquement les vulnérabilités, une priorisation plus intelligente qui réduit le bruit lié aux vulnérabilités, et des contrôles de gouvernance qui donnent aux équipes de sécurité les accès et la couverture appropriés à grande échelle.\n\n> Pour découvrir comment GitLab Duo Agent Platform intègre la correction automatisée directement dans le workflow de vos équipes de développement, [commencez un essai gratuit de GitLab Ultimate dès aujourd’hui](https://about.gitlab.com/free-trial/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr).",[717,704,10,27],"security",{"featured":13,"template":14,"slug":719},"automate-remediation-with-ready-to-merge-ai-code-fixes",{"content":721,"config":729},{"title":722,"description":723,"authors":724,"heroImage":714,"date":726,"body":727,"category":10,"tags":728},"GitLab 18.11 : les agents CI Expert et Data Analyst comblent les lacunes du développement","Configurez votre CI et interrogez vos données de cycle de vie du développement logiciel grâce à deux nouveaux agents fondamentaux de GitLab Duo Agent Platform, disponibles dans GitLab 18.11.",[725],"Corinne Dent","2026-04-16","Le code généré par l'IA progresse plus vite que les systèmes qui l'entourent ne peuvent suivre. Plus de code signifie plus de merge requests en attente, plus de pipelines à configurer, plus de questions sur la livraison auxquelles personne n'a le temps de répondre — et la plupart des outils sur lesquels les équipes s'appuient n'ont pas été conçus pour ce rythme.\n\nDans GitLab 18.11, deux nouveaux agents fondamentaux pour Duo Agent Platform s'attaquent à des lacunes spécifiques du cycle de développement que l'IA a largement laissées de côté :\n* L'agent CI Expert (désormais en version bêta) comble le fossé entre l'écriture\n  du code et son intégration dans un pipeline opérationnel.\n\n* L'agent Data Analyst (désormais en disponibilité générale) comble le fossé entre\n  la livraison du code et la capacité à répondre à des questions fondamentales sur\n  le déroulement réel de cette livraison.\n\n\n\nCes problématiques ne pouvaient pas être résolues par un assistant généraliste. Un outil fonctionnant en dehors de GitLab peut générer un fichier YAML ou répondre à une question, mais il n'a aucune connaissance des performances historiques de vos pipelines, des zones de concentration des échecs, ni de vos temps de cycle de merge request réels. Ce contexte réside dans GitLab. Ces agents aussi.\n## Configurer rapidement la CI avec l'agent CI Expert\n\nL'IA a facilité l'écriture du code comme jamais auparavant. Intégrer ce code dans un pipeline opérationnel reste pourtant quelque chose que la plupart des équipes font des jours, voire des semaines plus tard — si tant est qu'elles le fassent. Le problème de la page blanche n'est plus dans l'éditeur. La page blanche, c'est désormais `.gitlab-ci.yml`.\n\nLes développeurs qui n'ont jamais configuré de CI ne savent pas à quoi ressemble la détection de langage en YAML, quelles commandes de test utiliser, ni comment valider le résultat avant de pousser leurs modifications. Les équipes copient généralement une configuration d'un projet précédent qui ne correspond pas forcément, assemblent des exemples tirés de la documentation, ou attendent la seule personne qui l'a déjà fait. Si cette personne n'est pas disponible, la CI devient quelque chose qu'on « fera plus tard ». Plus tard ne vient jamais.\n\nQuand la CI n'est jamais mise en place, les conséquences se font sentir partout. Les modifications sont livrées sans filet de sécurité fiable, les régressions apparaissent en production plutôt qu'en pipeline, et le travail s'accumule en lots plus importants et plus risqués, car personne ne veut être celui qui « casse le build ». Avec le temps, les équipes s'habituent à travailler dans l'incertitude, en s'appuyant souvent sur des connaissances institutionnelles non documentées et des tests ad hoc, plutôt que sur une boucle de retour rapide et prévisible intégrée à chaque modification.\n\nL'agent CI Expert, désormais disponible en version bêta, supprime ces frictions. Il inspecte votre dépôt, identifie votre langage et votre framework, et propose un pipeline de build et de test opérationnel, adapté à ce qui s'y trouve réellement — en expliquant chaque décision en langage clair. L'objectif : un pipeline fonctionnel en quelques minutes, sans écrire une seule ligne de YAML à la main.\n\nCe que fait l'agent CI Expert :\n\n* La génération de pipeline tenant compte du dépôt détecte le langage, le\n  framework et la configuration des tests.\n\n* Il génère des configurations de build et de test valides et exécutables.\n* Un flux guidé pour le premier pipeline, avec une explication en langage clair\n  de chaque étape dans Agentic Chat.\n\n* Une sémantique GitLab CI native, sans traduction de configuration requise.\n\nParce qu'il s'exécute dans GitLab et observe le comportement réel des pipelines au fil du temps, chaque amélioration peut s'appuyer sur la façon dont les équipes travaillent réellement, et non sur de simples exemples statiques.\n\u003Ciframe src=\"https://player.vimeo.com/video/1183458036?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"CI/CD Expert Agent\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cbr>\u003C/br>\n\nL'agent CI Expert est disponible sur GitLab.com, Self-Managed et Dedicated, dans les éditions Free, Premium et Ultimate avec GitLab Duo Agent Platform activé.\n\n## Interroger les données GitLab en langage naturel avec l'agent Data Analyst\n\nL'IA a accéléré la cadence de livraison des équipes. Répondre à des questions fondamentales sur l'avancement de ce travail est devenu plus difficile, pas plus simple.\n\nCombien de temps les merge requests restent-elles en revue ? Quels pipelines ralentissent les équipes ? Les objectifs de déploiement sont-ils réellement atteints ? Ces questions trouvaient autrefois une réponse en consultant un tableau de bord. Aujourd'hui, avec davantage de code, davantage d'équipes et une complexité accrue, les données existent — elles sont dans GitLab — mais y accéder implique encore d'attendre une équipe analytique, de soumettre une demande de tableau de bord, ou d'apprendre le GLQL.\n\nL'agent Data Analyst comble ce fossé. Posez une question en langage naturel et obtenez une visualisation instantanée dans Agentic Chat. Aucun langage de requête, aucune demande de tableau de bord, aucune attente que quelqu'un d'autre assemble les réponses.\n\nPar exemple, l'agent peut répondre aux questions portant sur les sujets suivants, selon les rôles :\n\n* Responsables ingénierie : temps de cycle des merge requests, débit par projet,\n  points de blocage dans les revues.\n\n* Développeurs : tendances de contribution, tests instables bloquant leurs merge\n  requests, évolution de la vitesse des pipelines.\n\n* Ingénieurs DevOps et plateforme : taux de succès/échec des pipelines,\n  utilisation des runners, fréquence de déploiement.\n\n* Direction ingénierie : fréquence de déploiement multi-portefeuille, métriques\n  de santé des projets, comparaisons des délais de livraison.\n\n\nDésormais en disponibilité générale dans la version 18.11, l'agent couvre les merge requests, les tickets, les projets, les pipelines et les jobs — une couverture complète du cycle de vie du développement logiciel, étendue par rapport au périmètre de la version bêta. Parce que l'agent Data Analyst interroge ce qui se trouve déjà dans GitLab, le contexte est toujours à jour, sans pipeline à maintenir ni outil tiers à synchroniser. Les requêtes générées en GitLab Query Language peuvent être copiées et utilisées partout où le Markdown GitLab est pris en charge, avec une exportation directe vers les éléments de travail et les tableaux de bord prévue dans la roadmap.\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1183094817?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Data Analyst agent demo\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cbr>\u003C/br>\n\nL'agent Data Analyst est disponible sur GitLab.com, Self-Managed et Dedicated, dans les éditions Free, Premium et Ultimate avec GitLab Duo Agent Platform activé.\n\n## Une plateforme unique, un contexte connecté\n\nLes deux agents s'exécutent dans GitLab, avec accès au code, aux pipelines, aux tickets et aux merge requests déjà présents. C'est ce qui distingue une IA native à la plateforme d'un assistant déconnecté : le contexte est toujours à jour et ne fait que gagner en pertinence avec le temps. L'agent CI Expert et l'agent Data Analyst représentent deux avancées concrètes vers une plateforme où l'IA ne se contente pas de vous aider à écrire du code plus vite, mais vous aide à comprendre, livrer et maintenir ce qui est construit.\n\n> [Commencer un essai gratuit de GitLab Duo Agent Platform](https://about.gitlab.com/gitlab-duo/)\n  pour découvrir ces agents IA fondamentaux.",[704,27,10],{"featured":32,"template":14,"slug":730},"ci-expert-and-data-analyst-ai-agents-target-development-gaps",{"promotions":732},[733,747,759,770],{"id":734,"categories":735,"header":737,"text":738,"button":739,"image":744},"ai-modernization",[736],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":740,"config":741},"Get your AI maturity score",{"href":742,"dataGaName":743,"dataGaLocation":248},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":745},{"src":746},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":748,"categories":749,"header":751,"text":738,"button":752,"image":756},"devops-modernization",[10,750],"devsecops","Are you just managing tools or shipping innovation?",{"text":753,"config":754},"Get your DevOps maturity score",{"href":755,"dataGaName":743,"dataGaLocation":248},"/assessments/devops-modernization-assessment/",{"config":757},{"src":758},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":760,"categories":761,"header":762,"text":738,"button":763,"image":767},"security-modernization",[717],"Are you trading speed for security?",{"text":764,"config":765},"Get your security maturity score",{"href":766,"dataGaName":743,"dataGaLocation":248},"/assessments/security-modernization-assessment/",{"config":768},{"src":769},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":771,"paths":772,"header":775,"text":776,"button":777,"image":782},"github-azure-migration",[773,774],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":778,"config":779},"See how GitLab compares to GitHub",{"href":780,"dataGaName":781,"dataGaLocation":248},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":783},{"src":758},{"header":785,"blurb":786,"button":787,"secondaryButton":791},"Commencez à développer plus rapidement dès aujourd'hui","Découvrez ce que votre équipe peut accomplir avec la plateforme d'orchestration intelligente pour le DevSecOps.\n",{"text":51,"config":788},{"href":789,"dataGaName":54,"dataGaLocation":790},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/fr-fr/","feature",{"text":56,"config":792},{"href":58,"dataGaName":59,"dataGaLocation":790},1776449952477]