[{"data":1,"prerenderedAt":808},["ShallowReactive",2],{"/fr-fr/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0":3,"navigation-fr-fr":40,"banner-fr-fr":445,"footer-fr-fr":455,"blog-post-authors-fr-fr-Martin Brümmer|Fabian Zimmer|Sam Wiskow":665,"blog-related-posts-fr-fr-a-guide-to-the-breaking-changes-in-gitlab-18-0":704,"blog-promotions-fr-fr":746,"next-steps-fr-fr":799},{"id":4,"title":5,"authorSlugs":6,"body":10,"categorySlug":11,"config":12,"content":16,"description":10,"extension":28,"isFeatured":14,"meta":29,"navigation":30,"path":31,"publishedDate":24,"seo":32,"stem":36,"tagSlugs":37,"__hash__":39},"blogPosts/fr-fr/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0.yml","A Guide To The Breaking Changes In Gitlab 18 0",[7,8,9],"martin-brmmer","fabian-zimmer","sam-wiskow",null,"product",{"slug":13,"featured":14,"template":15},"a-guide-to-the-breaking-changes-in-gitlab-18-0",false,"BlogPost",{"title":17,"description":18,"authors":19,"heroImage":23,"date":24,"body":25,"category":11,"tags":26},"Guide des changements cassants et suppressions de GitLab 18.0","Anticipez dès maintenant les suppressions prévues dans notre prochaine version majeure. Évaluez les conséquences pour votre projet, puis consultez les mesures d'atténuation décrites dans la documentation afin de garantir une transition fluide vers GitLab 18.0.",[20,21,22],"Martin Brümmer","Fabian Zimmer","Sam Wiskow","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659437/Blog/Hero%20Images/AdobeStock_398929148.jpg","2025-04-18","GitLab 18.0, notre prochaine version majeure, inclut de nouvelles fonctionnalités qui repoussent les limites de l'innovation DevSecOps, tandis que certaines options obsolètes sont supprimées. Découvrez dans cet article un récapitulatif complet des évolutions majeures à venir, ainsi que des pistes concrètes pour en limiter l’impact sur vos projets.\n\n## Fenêtres de déploiement GitLab 18.0\n\n### GitLab.com \nLes changements cassants sur GitLab.com sont concentrés sur ces trois périodes clés :\n- Du 21 au 23 avril 2025  - Du 28 au 30 avril 2025  - Du 5 au 7 mai 2025\n\nDe nombreux autres évolutions continuent d'être déployés au fil des mois. Pour en savoir plus sur les modifications les plus sensibles apportées prévues à ces dates, consultez notre [documentation dédie aux changements cassants](https://docs.gitlab.com/update/breaking_windows/).\n\n***Remarque :** exceptionnellement, certaines mises à jour importantes peuvent intervenir légèrement en dehors de ces périodes.*\n\n### GitLab Self-Managed\n\nGitLab 18.0 est disponible depuis le 15 mai. Consultez le calendrier complet des sorties de nouvelles versions sur [cette page](/releases/whats-new/).\n\n### GitLab Dedicated\n\nLa mise à niveau vers GitLab 18.0 aura lieu pendant votre fenêtre de maintenance, entre le 24 et le 29 juin 2025. Pour en savoir plus et connaître votre fenêtre de maintenance, consultez [cette page](https://docs.gitlab.com/administration/dedicated/maintenance/#release-rollout-schedule).\n\nNous mettons également à votre disposition des outils et ressources adaptés pour vous aider à mesurer l'impact de ces changements sur votre environnement et préparer votre passage à la version 18.0. N'hésitez pas à consulter [toutes les informations sur ces outils, ressources et les mesures d'atténuation](#tools-and-resources-to-manage-your-impact).\n\nEn outre, la [page des obsolescences](https://docs.gitlab.com/ee/update/deprecations?removal_milestone=18.0) répertorie l'ensemble des suppressions prévues dans la version 18.0. Découvrez ci-dessous les nouveautés de cette année et comment vous y préparer selon la configuration de votre déploiement.\n\n## Changements cassants\n\n### Impact élevé\n\n**1. Token pour job CI/CD : suppression du paramètre « Limiter l'accès depuis votre projet »**\n\nGitLab.com | GiitLab Self-Managed | GitLab Dedicated\n\nDans GitLab 14.4, nous avions mis en place le paramètre **Limiter l'accès à CI_JOB_TOKEN** pour améliorer la sécurité en **[restreignant l'accès *depuis* les tokens de job CI/CD de votre projet (CI_JOB_TOKEN)](https://docs.gitlab.com/ci/jobs/ci_job_token/#limit-your-projects-job-token-access)** Dans la version 16.3 de GitLab, ce paramètre a été renommé **Limiter l'accès *à partir* de ce projet** pour plus de clarté.\nDans la version 15.9 de GitLab, nous avions introduit une solution alternative : le paramètre **[Groupes et projets autorisés](https://docs.gitlab.com/ci/jobs/ci_job_token/#add-a-group-or-project-to-the-job-token-allowlist)**. Celui-ci contrôle l'accès au token pour job CI/CD de votre projet à l'aide d'une liste d'autorisations et constitue une amélioration significative par rapport à l'original. La première itération a été rendue obsolète dans GitLab 16.0 et sa suppression est prévue dans GitLab 18.0.\n\nLe paramètre **Limiter l'accès *à partir* de ce projet** est désactivé par défaut pour tous les nouveaux projets. Depuis GitLab 16.0, une fois ce paramètre désactivé dans un projet, il n’est plus possible de le réactiver, mais vous pouvez utiliser le paramètre **Groupes et projets autorisés** pour contrôler l'accès au token pour job de vos projets.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#cicd-job-token---limit-access-from-your-project-setting-removal)\n- [Vérification GitLab Detective disponible](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md)\n\n**2. Token pour job CI/CD : application de la liste d'autorisation « Groupes et projets autorisés »**\n\nGitLab.com | GitLab Self-Managed | GitLab Dedicated\n\nIntroduit dans GitLab 15.9, le **[paramètre « Groupes et projets autorisés »](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-group-or-project-to-the-job-token-allowlist)** (renommé **Limiter l'accès à ce projet** dans la version 16.3 de GitLab), vous permet de gérer l'accès au token pour job CI/CD de votre projet. Lorsque le paramètre est défini sur **Uniquement ce projet et tous les groupes et projets de la liste d'autorisation**, seuls les groupes ou projets explicitement ajoutés à cette liste peuvent accéder à votre projet par le biais d'un token de job.\n\n* **Avant GitLab 15.9**, le token de job était accessible depuis n'importe quel projet, car la liste d'autorisation était désactivée par défaut et définie sur [**« Tous les groupes et projets »**](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#allow-any-project-to-access-your-project), sans restriction d'accès.\n* **Depuis GitLab 17.6**, les administrateurs des instances GitLab Self-Managed ou GitLab Dedicated peuvent désormais [**imposer des règles de sécurité plus strictes pour tous les projets**](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#job-token-permissions) et empêcher les chargés de maintenance des projets de sélectionner **Tous les groupes et projets**. Cette modification garantit un niveau de sécurité plus élevé entre les projets.   * Dans GitLab 18.0, ce paramètre sera activé par défaut. Sur GitLab.com, nous remplirons automatiquement les listes d'autorisations de vos projets en fonction des logs d'authentification de votre projet.   * Pour anticiper ce changement sur **GitLab.com**, les chargés de maintenance du projet qui utilisent le token de job pour l'authentification inter-projets doivent remplir les listes d'autorisations **Groupes et projets autorisés**, puis définir le paramètre sur **Uniquement** **ce projet et tous les groupes et projets de la liste d'autorisation**. Nous vous encourageons à utiliser les [outils de migration](https://docs.gitlab.com/ci/jobs/ci_job_token/#auto-populate-a-projects-allowlist) disponibles pour ***automatiser*** la création de la liste d'autorisation en fonction des [logs d'authentification](https://docs.gitlab.com/ci/jobs/ci_job_token/#job-token-authentication-log) du projet avant le passage à la version GitLab 18.0.   * Les **utilisateurs de GitLab Self-Managed** doivent remplir les listes d'autorisations avant d'effectuer la mise à niveau vers la version 18.0.   * Les **utilisateurs de GitLab Dedicated** doivent élaborer, en collaboration avec l'équipe chargée de leur compte GitLab, une approche adaptée à leur instance.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#cicd-job-token---authorized-groups-and-projects-allowlist-enforcement)\n- [Documentation](https://docs.gitlab.com/ci/jobs/ci_job_token/#add-a-gr)\n- [Vérification GitLab Detective disponible](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md)\n\n**3. Renforcement de la portée des tokens pour le proxy de dépendances**\n\nGitLab.com | GitLab Self-Managed | GitLab Dedicated\n\nActuellement, le proxy de dépendances pour les conteneurs accepte les commandes **`docker login`** et **`docker pull`** en utilisant des tokens **d'accès personnels, de projet** ou **de groupe**, sans vérifier leurs portées.\nÀ partir de GitLab 18.0, il exigera la présence des portées **`read_registry`** et **`write_registry`** pour valider toute authentification. Après cette modification, les tentatives d'authentification avec des tokens ne disposant pas de ces portées seront **rejetées**.\n\nAvant de procéder à la mise à niveau, vous devez générer de nouveaux tokens avec les [**portées requises**](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#authenticate-with-the-dependency-proxy-for-container-images), puis mettre à jour les variables et scripts de vos workflows avec ces nouveaux jetons.\n\nVous avez également la possibilité d'utiliser [**Dependency Token Checker**](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/dependancy-token-checker/), un script développé par la communauté, qui vous permet de visualiser les tokens et de procéder à leur rotation automatique.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#dependency-proxy-token-scope-enforcement)\n\n### Impact modéré\n\n**1. Nouvelles limites de conservation des données relatives aux vulnérabilités sur GitLab.com**\n\nGitLab.com - **Réservé aux clients Ultimate**\n\nÀ partir de GitLab 18.1, nous mettrons en place progressivement, sur une période de six mois, une **nouvelle limite de conservation des données** pour les clients de l'édition **GitLab Ultimate** sur GitLab.com, afin d'améliorer les performances et la fiabilité du système. Celle-ci aura une incidence sur la durée de conservation des données relatives aux vulnérabilité.\n\nLes vulnérabilités datant de plus de 12 mois qui n'ont pas été mises à jour seront automatiquement déplacées vers des archives de stockage à froid qui :\n\n* restent accessibles et téléchargeables via l'interface utilisateur (UI) de GitLab  * sont conservées pendant 3 ans  * sont définitivement supprimées après 3 ans\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#new-data-retention-limits-for-vulnerabilities-on-gitlabcom)\n- [Documentation](https://handbook.gitlab.com/handbook/security/records-retention-deletion/)\n\n**2. Rejet des stratégies de pull d'image de conteneur qui ne figurent pas dans `allowed_pull_policies`**\n\nGitLab.com | GitLab Self-Managed | GitLab Dedicated \nToutes les stratégies de pull configurées doivent être présentes dans la [**configuration allowed_pull_policies**](https://docs.gitlab.com/runner/executors/docker/#allow-docker-pull-policies) spécifiée dans le fichier **`config.toml`** du runner. Si ce n'est pas le cas, le job devrait échouer avec une erreur de type**`incompatible pull policy`**.\n\nActuellement, les jobs ne sont pas rejetés tant qu'au moins une stratégie de pull figure dans **`allowed-pull-policies`**, même si d'autres sont exclues.\n\nDans GitLab 18.0, un job ne sera en échec que si aucune stratégie de pull définie ne figure dans **`allowed-pull-policies`**. Toutefois, maintenant, seules les stratégies autorisées dans **`allowed-pull-policies`** seront effectivement appliquées. Avec GitLab 18.0, cette distinction risque de provoquer l'échec de jobs qui s'exécutent actuellement avec succès.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#reject-container-image-pull-policies-not-in-allowed_pull_policies)\n- [Documentation](https://docs.gitlab.com/runner/executors/docker/#allow-docker-pull-policies)\n\n**3. Fin de la prise en charge de PostgreSQL 14 et 15**\n\nGitLab Self-Managed\nGitLab suit une [**cadence de mise à niveau annuelle pour PostgreSQL**](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/database-framework/postgresql-upgrade-cadence/).\n\nLa prise en charge de PostgreSQL 14 et 15 sera supprimée dans GitLab 18.0 et PostgreSQL 16 deviendra la version minimale requise.\n\nPostgreSQL 14 et 15 seront pris en charge pendant l'ensemble du cycle de sortie de nouvelles versions de GitLab 17. PostgreSQL 16 sera également pris en charge pour les instances qui souhaitent effectuer une mise à niveau avant la sortie de GitLab 18.0.\n\nPour anticiper ce changement, les instances qui n'utilisent pas [**PostgreSQL Cluster**](https://docs.gitlab.com/administration/postgresql/replication_and_failover/) (comme celles installées avec un paquet Omnibus sur une seule instance PostgreSQL), bénéficieront d'une mise à niveau automatique vers PostgreSQL 16 à partir de GitLab 17.11. Si vous utilisez [**PostgreSQL Cluster**](https://docs.gitlab.com/administration/postgresql/replication_and_failover/) ou si vous [**désactivez cette mise à niveau automatique**](https://docs.gitlab.com/omnibus/settings/database/#opt-out-of-automatic-postgresql-upgrades), vous devrez [**effectuer une mise à niveau manuelle vers PostgreSQL 16**](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server) pour passer à GitLab 18.0. Assurez-vous de disposer de suffisamment d'espace disque pour effectuer la mise à niveau.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#postgresql-14-and-15-no-longer-supported)\n- [Documentation](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server)\n- [Instructions pour la migration](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions/)\n\n**4. Obsolescence des templates CI/CD Terraform**\n\nGitLab Self-Managed\n\nLes templates CI/CD Terraform sont déclarés obsolètes et sont supprimés dans GitLab 18.0. Les templates concernés sont les suivants  :\n\n* `Terraform.gitlab-ci.yml`  * `Terraform.latest.gitlab-ci.yml`  * `Terraform/Base.gitlab-ci.yml`  * `Terraform/Base.latest.gitlab-ci.yml`\n\nGitLab ne pourra pas mettre à jour le binaire **`terraform`** dans les images de job vers une version sous licence Business Source License (BSL).\n\nPour continuer à utiliser Terraform, clonez les templates et l'[**image Terraform**](https://gitlab.com/gitlab-org/terraform-images), et maintenez-les à jour si nécessaire. GitLab fournit des [**instructions détaillées**](https://gitlab.com/gitlab-org/terraform-images) pour migrer vers une image personnalisée.\n\n**À la place, nous vous recommandons d'utiliser le nouveau composant CI/CD OpenTofu sur GitLab.com ou le nouveau template CI/CD OpenTofu sur GitLab Self-Managed.** Les composants CI/CD ne sont pas encore disponibles sur GitLab Self-Managed. Toutefois, le [**ticket n° 415638**](https://gitlab.com/gitlab-org/gitlab/-/issues/415638) propose d'ajouter cette fonctionnalité. Si les composants CI/CD deviennent disponibles sur GitLab Self-Managed, le template CI/CD OpenTofu sera supprimé.\n\nEn savoir plus sur le nouveau [composant CI/CD OpenTofu](https://gitlab.com/components/opentofu).\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#deprecate-terraform-cicd-templates)\n\n**5. Mise à jour majeure du sous-chart Prometheus**\n\nGitLab Self-Managed\n\nAvec GitLab 18.0 et le chart GitLab 9.0, le sous-chart Prometheus sera mis à jour de la version 15.3 à la version 27.3.\n\nAvec cette mise à jour, Prometheus 3 sera livré par défaut.\n\nVous devrez effectuer certaines étapes manuelles pour effectuer la mise à niveau. Si Alertmanager, Node Exporter ou Pushgateway sont activés, vous devrez également mettre à jour vos valeurs Helm.\n\nVeuillez vous référer au [**guide sur la migration**](https://docs.gitlab.com/charts/releases/9_0/#prometheus-upgrade) pour plus d'informations.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#major-update-of-the-prometheus-subchart)\n\n### Impact faible\n\n**1. Arrêt de la compilation des paquets SUSE Linux Enterprise Server 15 SP2**\n\nGitLab Self-Managed\n\nLe version avec service et support à long terme (LTSS) pour SUSE Linux Enterprise Server (SLES) 15 SP2 a pris fin en décembre 2024.\n\nPar conséquent, nous ne prendrons plus en charge la distribution de SLES SP2 pour les installations de paquets Linux. Veuillez effectuer une mise à niveau vers SLES 15 SP6 pour bénéficier d'une prise en charge continue.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#support-for-suse-linux-enterprise-server-15-sp2)\n\n**2. Suppression du limiteur de débit Gitaly**\n\nGitLab Self-Managed\n\nAuparavant, Gitaly prenait en charge la [**limitation de débit basée sur RPC**](https://gitlab.com/gitlab-org/gitaly/-/blob/4b7ea24f6172a03e7989879200b47b6fd0e2d059/doc/backpressure.md#L55-55). Nous rendons aujourd'hui cette fonctionnalité obsolète, car elle ne donne pas les résultats escomptés. Veuillez consulter le ticket relatif à l'obsolescence pour plus de détails.\n\nSi vous avez procédé à la configuration du limiteur de débit (bientôt obsolète), aucune erreur ne sera renvoyée et celle-ci sera simplement ignorée.\n\nÀ la place, vous devez utiliser le [**limiteur de simultanéité**](https://docs.gitlab.com/administration/gitaly/concurrency_limiting/).\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#gitaly-rate-limiting)\n\n**3. Obsolescence de la prise en charge de l'image du contrôleur NGINX 1.3.1**\n\nGitLab Self-Managed\n\nNous passons à la version 1.11.2 du contrôleur NGINX par défaut, laquelle impose de nouvelles règles de contrôle d'accès basé sur les rôles (RBAC). Les utilisateurs qui utilisent **nginx-ingress.rbac.create: false** pour gérer leurs propres règles RBAC\n\ndevront les mettre à jour avant de migrer vers la version 1.11.2 ou une version ultérieure. Un mécanisme alternatif permet désormais de déployer la version 1.3.1 uniquement si la valeur Helm est définie comme indiqué ci-dessus. Par ailleurs, nous avons ajouté la valeur **nginx-ingress.controller.image.disableFallback**, qui est définie par défaut sur « false ». Si vous gérez vos propres règles RBAC, vous pouvez définir cette valeur sur « true » une fois les nouvelles règles en place, afin de permettre le déploiement de la version 1.11.2.\n\nLa version 17.5 marquera la fin de la prise en charge de l'image 1.3.1 et du mécanisme alternatif, afin de généraliser l'utilisation de la version 1.11.2, plus sécurisée.\n\n[Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#fallback-support-for-gitlab-nginx-chart-controller-image-v131)\n\n**4. Mise à jour de la version majeure des analyseurs de tests de sécurité des applications**\n\nGitLab.com | GitLab Self-Managed | GitLab Dedicated\n\nAvec GitLab 18.0, les analyseurs utilisés pour les tests de sécurité des applications passeront à de nouvelles versions majeures.\n\nSi vous n'utilisez pas les templates inclus par défaut ou si vous avez épinglé vos versions d'analyseur, pensez à mettre à jour votre job CI/CD en retirant la version épinglée ou en passant à la dernière version majeure.\n\nJusqu'à GitLab 18.0, les analyseurs seront toujours mis à jour sur les versions 17.0 à 17.11. Ensuite, seuls les analyseurs de la nouvelle version majeure bénéficieront des correctifs et des nouvelles fonctionnalités.\n\nConformément à notre politique de maintenance, nous ne rétroportons pas les bogues ni les nouvelles fonctionnalités vers les versions obsolètes. Seuls les correctifs de sécurité peuvent être appliqués aux trois dernières versions mineures.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#application-security-testing-analyzers-major-version-update)\n\n**5. API Discovery utilisera les pipelines de branche par défaut**\n\nGitLab.com | GitLab Self-Managed | GitLab Dedicated\n\nDans GitLab 18.0, nous mettrons à jour le comportement par défaut du template CI/CD pour API Discovery (**API-Discovery.gitlab-ci.yml**).\n\nJusqu'à GitLab 18.0, il configurait par défaut les jobs pour qu'ils s'exécutent dans des [**pipelines de merge requests (MR)**](https://docs.gitlab.com/ci/pipelines/merge_request_pipelines/) dès l'ouverture d'une MR.\n\nDès GitLab 18.0, ce template adoptera le même comportement que les [**éditions stables de templates**](https://docs.gitlab.com/user/application_security/detect/roll_out_security_scanning/#template-editions) des autres scanners d'arbre de syntaxe abstraite (AST) :\n\n* Par défaut, le template exécutera des jobs de scan dans les pipelines de branche.  * Vous pourrez définir la variable CI/CD **AST_ENABLE_MR_PIPELINES: true** pour utiliser les pipelines MR lors de l'ouverture d'une MR. Le suivi de la mise en œuvre de cette variable est disponible via le [**ticket n° 410880**](https://gitlab.com/gitlab-org/gitlab/-/issues/410880).\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#api-discovery-will-use-branch-pipelines-by-default)\n\n**6. Réduction par défaut de la valeur du DAST DAST_DEVTOOLS_API_TIMEOUT**\n\nGitLab.com | GitLab Self-Managed | GitLab Dedicated\n\nLa variable d'environnement **DAST_DEVTOOLS_API_TIMEOUT** détermine la durée pendant laquelle un test dynamique de sécurité des applications (DAST) attend une réponse du navigateur. Avant GitLab 18.0, la variable avait une valeur statique de 45 secondes. Dès GitLab 18.0, la variable d'environnement **DAST_DEVTOOLS_API_TIMEOUT** aura une valeur dynamique, calculée en fonction d'autres configurations de délai d'attente dépassé.\n\nDans la plupart des cas, la valeur de 45 secondes était supérieure à la valeur du délai d'attente dépassé de nombreuses fonctions du scanner. Le passage à un calcul dynamique permet d'adapter la variable __DAST_DEVTOOLS_API_TIMEOUT__ à un plus grand nombre de situations.\n\n- [Avis d'obsolescence](https://docs.gitlab.com/update/deprecations/#dast-dast_devtools_api_timeout-will-have-a-lower-default-value)\n## Outils et ressources pour gérer l'impact sur votre environnement\n\nNous avons développé des outils spécifiques pour aider nos clients à comprendre l'impact de ces changements planifiés sur leur(s) instance(s) GitLab. Après avoir évalué l'impact sur votre projet, consultez les mesures d'atténuation décrites dans la documentation pour assurer une transition fluide vers GitLab 18.0.\n\n* [Obsolescence de la recherche avancée](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/deprecation-migration-tools/advanced-search-deprecations) : cet outil s'appuie sur l'API de recherche avancée de GitLab pour repérer les chaînes liées aux obsolescences dans vos groupes et projets, et signale aussi les fichiers nécessitant une vérification manuelle. *__Remarque :__ peut comporter des faux positifs.*   * [Assistant de détection de prise en charge de la compilation pour l'analyse des dépendances](https://gitlab.com/security-products/tooling/build-support-detection-helper) : cet outil détecte les projets concernés par trois obsolescences liées à l'analyse des dépendances ([1](https://docs.gitlab.com/update/deprecations/#dependency-scanning-for-javascript-vendored-libraries), [2](https://docs.gitlab.com/update/deprecations/#dependency-scanning-upgrades-to-the-gitlab-sbom-vulnerability-scanner), [3](https://docs.gitlab.com/update/deprecations/#resolve-a-vulnerability-for-dependency-scanning-on-yarn-projects) ; toutes reportées à la version 19.0) et s'appuie sur l'API pour analyser les fichiers et les nom de jobs CI.\n* [GitLab Detective](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md) (GitLab Auto-géré uniquement) : cet outil expérimental analyse automatiquement votre installation GitLab pour détecter les problèmes connus, en s'appuyant sur des vérifications poussées des fichiers de configuration et valeurs issues de la base de données. **Remarque :** l’outil doit s'exécuter directement sur vos nœuds GitLab.\n\nPour vous accompagner dans cette transition, nous avons lancé sur GitLab University des micro-cours pratiques (de 15 minutes maximum) dédiés à la préparation et à la mise en œuvre des actions d'atténuation nécessaires. [Commencez votre parcours d'apprentissage ici](https://university.gitlab.com/catalog?query=18.0).\nSi vous disposez d'un forfait payant et que vous avez des questions ou besoin d'aide concernant ces changements, veuillez [créer un ticket d'assistance](https://support.gitlab.com/hc/en-us/articles/11626501035292-Support-Portal-User-Guide) sur le portail d'assistance GitLab.\nSi vous utilisez la [version gratuite de Gitlab.com](https://support.gitlab.com/hc/en-us/articles/11625911285404-Statement-of-Support#free-users), vous pouvez obtenir de l'aide via les ressources communautaires : [documentation GitLab](https://docs.gitlab.com/), [forum de la communauté GitLab](https://forum.gitlab.com/) et [Stack Overflow](http://stackoverflow.com/questions/tagged/gitlab).\n",[11,27],"DevSecOps platform","yml",{},true,"/fr-fr/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",{"title":17,"description":18,"ogTitle":17,"ogDescription":18,"noIndex":14,"ogImage":23,"ogUrl":33,"ogSiteName":34,"ogType":35,"canonicalUrls":33},"https://about.gitlab.com/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0","https://about.gitlab.com","article","fr-fr/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",[11,38],"devsecops-platform","eesrFFlR9T8KquPV1Cx_LstNXnCRg1gvMK3gkiKz7Ys",{"data":41},{"logo":42,"freeTrial":47,"sales":52,"login":57,"items":62,"search":372,"minimal":407,"duo":426,"pricingDeployment":435},{"config":43},{"href":44,"dataGaName":45,"dataGaLocation":46},"/fr-fr/","gitlab logo","header",{"text":48,"config":49},"Commencer un essai gratuit",{"href":50,"dataGaName":51,"dataGaLocation":46},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr&glm_content=default-saas-trial/","free trial",{"text":53,"config":54},"Contacter l'équipe commerciale",{"href":55,"dataGaName":56,"dataGaLocation":46},"/fr-fr/sales/","sales",{"text":58,"config":59},"Connexion",{"href":60,"dataGaName":61,"dataGaLocation":46},"https://gitlab.com/users/sign_in/","sign in",[63,90,187,192,293,353],{"text":64,"config":65,"cards":67},"Plateforme",{"dataNavLevelOne":66},"platform",[68,74,82],{"title":64,"description":69,"link":70},"La plateforme d'orchestration intelligente pour le DevSecOps",{"text":71,"config":72},"Découvrir notre plateforme",{"href":73,"dataGaName":66,"dataGaLocation":46},"/fr-fr/platform/",{"title":75,"description":76,"link":77},"GitLab Duo Agent Platform","L'IA agentique pour l'ensemble du cycle de développement logiciel",{"text":78,"config":79},"Découvrir GitLab Duo",{"href":80,"dataGaName":81,"dataGaLocation":46},"/fr-fr/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":83,"description":84,"link":85},"Choisir GitLab","Découvrez les principales raisons pour lesquelles les entreprises choisissent GitLab",{"text":86,"config":87},"En savoir plus",{"href":88,"dataGaName":89,"dataGaLocation":46},"/fr-fr/why-gitlab/","why gitlab",{"text":91,"left":30,"config":92,"link":94,"lists":98,"footer":169},"Produit",{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"Voir toutes les solutions",{"href":97,"dataGaName":93,"dataGaLocation":46},"/fr-fr/solutions/",[99,124,147],{"title":100,"description":101,"link":102,"items":107},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":46},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[108,112,115,120],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":46,"dataGaName":109},"/fr-fr/solutions/continuous-integration/",{"text":75,"config":113},{"href":80,"dataGaLocation":46,"dataGaName":114},"gitlab duo agent platform - product menu",{"text":116,"config":117},"Gestion du code source",{"href":118,"dataGaLocation":46,"dataGaName":119},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":121,"config":122},"Livraison de logiciels automatisée",{"href":105,"dataGaLocation":46,"dataGaName":123},"Automated software delivery",{"title":125,"description":126,"link":127,"items":132},"Sécurité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":46,"icon":131},"/fr-fr/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[133,137,142],{"text":134,"config":135},"Tests de sécurité des applications",{"href":129,"dataGaName":136,"dataGaLocation":46},"Application security testing",{"text":138,"config":139},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":140,"dataGaLocation":46,"dataGaName":141},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":143,"config":144},"Conformité logicielle",{"href":145,"dataGaName":146,"dataGaLocation":46},"/fr-fr/solutions/software-compliance/","Software Compliance",{"title":148,"link":149,"items":154},"Mesures",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":46},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"Visibilité et mesures",{"href":152,"dataGaLocation":46,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"Gestion de la chaîne de valeur",{"href":162,"dataGaLocation":46,"dataGaName":163},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"Données d'analyse et informations clés",{"href":167,"dataGaLocation":46,"dataGaName":168},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLab pour",[172,177,182],{"text":173,"config":174},"Entreprises",{"href":175,"dataGaLocation":46,"dataGaName":176},"/fr-fr/enterprise/","enterprise",{"text":178,"config":179},"PME",{"href":180,"dataGaLocation":46,"dataGaName":181},"/fr-fr/small-business/","small business",{"text":183,"config":184},"Secteur public",{"href":185,"dataGaLocation":46,"dataGaName":186},"/fr-fr/solutions/public-sector/","public sector",{"text":188,"config":189},"Tarifs",{"href":190,"dataGaName":191,"dataGaLocation":46,"dataNavLevelOne":191},"/fr-fr/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":280},"Ressources",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"Afficher toutes les ressources",{"href":199,"dataGaName":195,"dataGaLocation":46},"/fr-fr/resources/",[201,234,252],{"title":202,"items":203},"Premiers pas",[204,209,214,219,224,229],{"text":205,"config":206},"Installation",{"href":207,"dataGaName":208,"dataGaLocation":46},"/fr-fr/install/","install",{"text":210,"config":211},"Guides de démarrage",{"href":212,"dataGaName":213,"dataGaLocation":46},"/fr-fr/get-started/","quick setup checklists",{"text":215,"config":216},"Apprentissage",{"href":217,"dataGaLocation":46,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"Documentation sur le produit",{"href":222,"dataGaName":223,"dataGaLocation":46},"https://docs.gitlab.com/","product documentation",{"text":225,"config":226},"Vidéos sur les bonnes pratiques",{"href":227,"dataGaName":228,"dataGaLocation":46},"/fr-fr/getting-started-videos/","best practice videos",{"text":230,"config":231},"Intégrations",{"href":232,"dataGaName":233,"dataGaLocation":46},"/fr-fr/integrations/","integrations",{"title":235,"items":236},"Découvrir",[237,242,247],{"text":238,"config":239},"Témoignages clients",{"href":240,"dataGaName":241,"dataGaLocation":46},"/fr-fr/customers/","customer success stories",{"text":243,"config":244},"Blog",{"href":245,"dataGaName":246,"dataGaLocation":46},"/fr-fr/blog/","blog",{"text":248,"config":249},"Travail à distance",{"href":250,"dataGaName":251,"dataGaLocation":46},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":253,"items":254},"Connecter",[255,260,265,270,275],{"text":256,"config":257},"Services GitLab",{"href":258,"dataGaName":259,"dataGaLocation":46},"/fr-fr/services/","services",{"text":261,"config":262},"Communauté",{"href":263,"dataGaName":264,"dataGaLocation":46},"/community/","community",{"text":266,"config":267},"Forum",{"href":268,"dataGaName":269,"dataGaLocation":46},"https://forum.gitlab.com/","forum",{"text":271,"config":272},"Événements",{"href":273,"dataGaName":274,"dataGaLocation":46},"/events/","events",{"text":276,"config":277},"Partenaires",{"href":278,"dataGaName":279,"dataGaLocation":46},"/fr-fr/partners/","partners",{"backgroundColor":281,"textColor":282,"text":283,"image":284,"link":288},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":285,"config":286},"carte promo The Source",{"src":287},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":289,"config":290},"Lire les articles les plus récents",{"href":291,"dataGaName":292,"dataGaLocation":46},"/fr-fr/the-source/","the source",{"text":294,"config":295,"lists":297},"Société",{"dataNavLevelOne":296},"company",[298],{"items":299},[300,305,311,313,318,323,328,333,338,343,348],{"text":301,"config":302},"À propos",{"href":303,"dataGaName":304,"dataGaLocation":46},"/fr-fr/company/","about",{"text":306,"config":307,"footerGa":310},"Carrières",{"href":308,"dataGaName":309,"dataGaLocation":46},"/jobs/","jobs",{"dataGaName":309},{"text":271,"config":312},{"href":273,"dataGaName":274,"dataGaLocation":46},{"text":314,"config":315},"Leadership",{"href":316,"dataGaName":317,"dataGaLocation":46},"/company/team/e-group/","leadership",{"text":319,"config":320},"Équipe",{"href":321,"dataGaName":322,"dataGaLocation":46},"/company/team/","team",{"text":324,"config":325},"Manuel",{"href":326,"dataGaName":327,"dataGaLocation":46},"https://handbook.gitlab.com/","handbook",{"text":329,"config":330},"Relations avec les investisseurs",{"href":331,"dataGaName":332,"dataGaLocation":46},"https://ir.gitlab.com/","investor relations",{"text":334,"config":335},"Centre de confiance",{"href":336,"dataGaName":337,"dataGaLocation":46},"/fr-fr/security/","trust center",{"text":339,"config":340},"Centre pour la transparence de l'IA",{"href":341,"dataGaName":342,"dataGaLocation":46},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":344,"config":345},"Newsletter",{"href":346,"dataGaName":347,"dataGaLocation":46},"/company/contact/#contact-forms","newsletter",{"text":349,"config":350},"Presse",{"href":351,"dataGaName":352,"dataGaLocation":46},"/press/","press",{"text":354,"config":355,"lists":356},"Nous contacter",{"dataNavLevelOne":296},[357],{"items":358},[359,362,367],{"text":53,"config":360},{"href":55,"dataGaName":361,"dataGaLocation":46},"talk to sales",{"text":363,"config":364},"Portail d’assistance",{"href":365,"dataGaName":366,"dataGaLocation":46},"https://support.gitlab.com","support portal",{"text":368,"config":369},"Portail clients GitLab",{"href":370,"dataGaName":371,"dataGaLocation":46},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":373,"login":374,"suggestions":381},"Fermer",{"text":375,"link":376},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":377,"config":378},"gitlab.com",{"href":60,"dataGaName":379,"dataGaLocation":380},"search login","search",{"text":382,"default":383},"Suggestions",[384,386,391,393,398,403],{"text":75,"config":385},{"href":80,"dataGaName":75,"dataGaLocation":380},{"text":387,"config":388},"Suggestions de code (IA)",{"href":389,"dataGaName":390,"dataGaLocation":380},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":392},{"href":111,"dataGaName":109,"dataGaLocation":380},{"text":394,"config":395},"GitLab sur AWS",{"href":396,"dataGaName":397,"dataGaLocation":380},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":399,"config":400},"GitLab sur Google Cloud ",{"href":401,"dataGaName":402,"dataGaLocation":380},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":404,"config":405},"Pourquoi utiliser GitLab ?",{"href":88,"dataGaName":406,"dataGaLocation":380},"Why GitLab?",{"freeTrial":408,"mobileIcon":413,"desktopIcon":418,"secondaryButton":421},{"text":409,"config":410},"Commencer votre essai gratuit",{"href":411,"dataGaName":51,"dataGaLocation":412},"https://gitlab.com/-/trials/new/","nav",{"altText":414,"config":415},"Icône GitLab",{"src":416,"dataGaName":417,"dataGaLocation":412},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":414,"config":419},{"src":420,"dataGaName":417,"dataGaLocation":412},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":422,"config":423},"Commencer",{"href":424,"dataGaName":425,"dataGaLocation":412},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr/get-started/","get started",{"freeTrial":427,"mobileIcon":431,"desktopIcon":433},{"text":428,"config":429},"En savoir plus sur GitLab Duo",{"href":80,"dataGaName":430,"dataGaLocation":412},"gitlab duo",{"altText":414,"config":432},{"src":416,"dataGaName":417,"dataGaLocation":412},{"altText":414,"config":434},{"src":420,"dataGaName":417,"dataGaLocation":412},{"freeTrial":436,"mobileIcon":441,"desktopIcon":443},{"text":437,"config":438},"Retour aux tarifs",{"href":190,"dataGaName":439,"dataGaLocation":412,"icon":440},"back to pricing","GoBack",{"altText":414,"config":442},{"src":416,"dataGaName":417,"dataGaLocation":412},{"altText":414,"config":444},{"src":420,"dataGaName":417,"dataGaLocation":412},{"title":446,"button":447,"config":452},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":448,"config":449},"Regarder GitLab Transcend maintenant",{"href":450,"dataGaName":451,"dataGaLocation":46},"/fr-fr/events/transcend/virtual/","transcend event",{"layout":453,"icon":454,"disabled":30},"release","AiStar",{"data":456},{"text":457,"source":458,"edit":464,"contribute":469,"config":474,"items":479,"minimal":656},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":459,"config":460},"Afficher le code source de la page",{"href":461,"dataGaName":462,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":465,"config":466},"Modifier cette page",{"href":467,"dataGaName":468,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":470,"config":471},"Veuillez contribuer",{"href":472,"dataGaName":473,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":475,"facebook":476,"youtube":477,"linkedin":478},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[480,503,557,589,624],{"title":64,"links":481,"subMenu":486},[482],{"text":483,"config":484},"Plateforme DevSecOps",{"href":73,"dataGaName":485,"dataGaLocation":463},"devsecops platform",[487],{"title":188,"links":488},[489,493,498],{"text":490,"config":491},"Voir les forfaits",{"href":190,"dataGaName":492,"dataGaLocation":463},"view plans",{"text":494,"config":495},"Pourquoi choisir GitLab Premium ?",{"href":496,"dataGaName":497,"dataGaLocation":463},"/fr-fr/pricing/premium/","why premium",{"text":499,"config":500},"Pourquoi choisir GitLab Ultimate ?",{"href":501,"dataGaName":502,"dataGaLocation":463},"/fr-fr/pricing/ultimate/","why ultimate",{"title":504,"links":505},"Solutions",[506,511,514,516,521,526,530,533,536,541,543,545,547,552],{"text":507,"config":508},"Transformation digitale",{"href":509,"dataGaName":510,"dataGaLocation":463},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":512,"config":513},"Sécurité et conformité",{"href":129,"dataGaName":136,"dataGaLocation":463},{"text":121,"config":515},{"href":105,"dataGaName":106,"dataGaLocation":463},{"text":517,"config":518},"Développement agile",{"href":519,"dataGaName":520,"dataGaLocation":463},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":522,"config":523},"Transformation cloud",{"href":524,"dataGaName":525,"dataGaLocation":463},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":527,"config":528},"SCM",{"href":118,"dataGaName":529,"dataGaLocation":463},"source code management",{"text":109,"config":531},{"href":111,"dataGaName":532,"dataGaLocation":463},"continuous integration & delivery",{"text":160,"config":534},{"href":162,"dataGaName":535,"dataGaLocation":463},"value stream management",{"text":537,"config":538},"GitOps",{"href":539,"dataGaName":540,"dataGaLocation":463},"/fr-fr/solutions/gitops/","gitops",{"text":173,"config":542},{"href":175,"dataGaName":176,"dataGaLocation":463},{"text":178,"config":544},{"href":180,"dataGaName":181,"dataGaLocation":463},{"text":183,"config":546},{"href":185,"dataGaName":186,"dataGaLocation":463},{"text":548,"config":549},"Formation",{"href":550,"dataGaName":551,"dataGaLocation":463},"/fr-fr/solutions/education/","education",{"text":553,"config":554},"Services financiers",{"href":555,"dataGaName":556,"dataGaLocation":463},"/fr-fr/solutions/finance/","financial services",{"title":193,"links":558},[559,561,564,566,569,571,574,577,579,581,583,585,587],{"text":205,"config":560},{"href":207,"dataGaName":208,"dataGaLocation":463},{"text":562,"config":563},"Guides de démarrage rapide",{"href":212,"dataGaName":213,"dataGaLocation":463},{"text":215,"config":565},{"href":217,"dataGaName":218,"dataGaLocation":463},{"text":220,"config":567},{"href":222,"dataGaName":568,"dataGaLocation":463},"docs",{"text":243,"config":570},{"href":245,"dataGaName":246},{"text":572,"config":573},"Histoires de réussite client",{"href":240,"dataGaLocation":463},{"text":575,"config":576},"Histoires de succès client",{"href":240,"dataGaName":241,"dataGaLocation":463},{"text":248,"config":578},{"href":250,"dataGaName":251,"dataGaLocation":463},{"text":256,"config":580},{"href":258,"dataGaName":259,"dataGaLocation":463},{"text":261,"config":582},{"href":263,"dataGaName":264,"dataGaLocation":463},{"text":266,"config":584},{"href":268,"dataGaName":269,"dataGaLocation":463},{"text":271,"config":586},{"href":273,"dataGaName":274,"dataGaLocation":463},{"text":276,"config":588},{"href":278,"dataGaName":279,"dataGaLocation":463},{"title":294,"links":590},[591,593,596,598,600,602,604,608,613,615,617,619],{"text":301,"config":592},{"href":303,"dataGaName":296,"dataGaLocation":463},{"text":594,"config":595},"Emplois",{"href":308,"dataGaName":309,"dataGaLocation":463},{"text":314,"config":597},{"href":316,"dataGaName":317,"dataGaLocation":463},{"text":319,"config":599},{"href":321,"dataGaName":322,"dataGaLocation":463},{"text":324,"config":601},{"href":326,"dataGaName":327,"dataGaLocation":463},{"text":329,"config":603},{"href":331,"dataGaName":332,"dataGaLocation":463},{"text":605,"config":606},"Sustainability",{"href":607,"dataGaName":605,"dataGaLocation":463},"/sustainability/",{"text":609,"config":610},"Diversité, inclusion et appartenance (DIB)",{"href":611,"dataGaName":612,"dataGaLocation":463},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":334,"config":614},{"href":336,"dataGaName":337,"dataGaLocation":463},{"text":344,"config":616},{"href":346,"dataGaName":347,"dataGaLocation":463},{"text":349,"config":618},{"href":351,"dataGaName":352,"dataGaLocation":463},{"text":620,"config":621},"Déclaration de transparence sur l'esclavage moderne",{"href":622,"dataGaName":623,"dataGaLocation":463},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":354,"links":625},[626,629,634,636,641,646,651],{"text":627,"config":628},"Échanger avec un expert",{"href":55,"dataGaName":56,"dataGaLocation":463},{"text":630,"config":631},"Aide",{"href":632,"dataGaName":633,"dataGaLocation":463},"https://support.gitlab.com/hc/en-us/articles/11626483177756-GitLab-Support","get help",{"text":368,"config":635},{"href":370,"dataGaName":371,"dataGaLocation":463},{"text":637,"config":638},"Statut",{"href":639,"dataGaName":640,"dataGaLocation":463},"https://status.gitlab.com/","status",{"text":642,"config":643},"Conditions d'utilisation",{"href":644,"dataGaName":645},"/terms/","terms of use",{"text":647,"config":648},"Déclaration de confidentialité",{"href":649,"dataGaName":650,"dataGaLocation":463},"/fr-fr/privacy/","privacy statement",{"text":652,"config":653},"Préférences en matière de cookies",{"dataGaName":654,"dataGaLocation":463,"id":655,"isOneTrustButton":30},"cookie preferences","ot-sdk-btn",{"items":657},[658,660,663],{"text":642,"config":659},{"href":644,"dataGaName":645,"dataGaLocation":463},{"text":661,"config":662},"Politique de confidentialité",{"href":649,"dataGaName":650,"dataGaLocation":463},{"text":652,"config":664},{"dataGaName":654,"dataGaLocation":463,"id":655,"isOneTrustButton":30},[666,680,692],{"id":667,"title":668,"body":10,"config":669,"content":671,"description":10,"extension":28,"meta":675,"navigation":30,"path":676,"seo":677,"stem":678,"__hash__":679},"blogAuthors/en-us/blog/authors/martin-brmmer.yml","Martin Brmmer",{"template":670},"BlogAuthor",{"name":20,"config":672},{"headshot":673,"ctfId":674},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659427/Blog/Author%20Headshots/martin_brummer.webp","1QkLKK0UnkvZDDBzzEhkaA",{},"/en-us/blog/authors/martin-brmmer",{},"en-us/blog/authors/martin-brmmer","5XXFf9xKfqhpm33ots964Z5lLGWP6fmjjylRLOrvUe4",{"id":681,"title":21,"body":10,"config":682,"content":683,"description":10,"extension":28,"meta":687,"navigation":30,"path":688,"seo":689,"stem":690,"__hash__":691},"blogAuthors/en-us/blog/authors/fabian-zimmer.yml",{"template":670},{"name":21,"config":684},{"headshot":685,"ctfId":686},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750713473/q6awwqbxtg0a4x9gtmhs.png","3TK88UogcX5lx83kWMVuvI",{},"/en-us/blog/authors/fabian-zimmer",{},"en-us/blog/authors/fabian-zimmer","qPVb4mKZuBff6-yly4-T5Bar6IdyXcx_tJHGlSL8QIA",{"id":693,"title":22,"body":10,"config":694,"content":695,"description":10,"extension":28,"meta":699,"navigation":30,"path":700,"seo":701,"stem":702,"__hash__":703},"blogAuthors/en-us/blog/authors/sam-wiskow.yml",{"template":670},{"name":22,"config":696},{"headshot":697,"ctfId":698},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659433/Blog/Author%20Headshots/swiskow-headshot.jpg","swiskow",{},"/en-us/blog/authors/sam-wiskow",{},"en-us/blog/authors/sam-wiskow","TR52XmFI8G3xfSF6pTXW6r_bf0Bd5tf82MmM7VjjKfM",[705,720,733],{"content":706,"config":718},{"title":707,"description":708,"body":709,"category":11,"tags":710,"date":713,"authors":714,"heroImage":717},"GitLab + Amazon : l'orchestration de plateforme portée par une IA fiable","Associez GitLab Duo Agent Platform à Amazon Bedrock pour un développement logiciel agentique et une orchestration sécurisée.","Si votre équipe utilise GitLab et dispose d'une solide pratique AWS, la combinaison de GitLab Duo Agent Platform et d'Amazon Bedrock a été conçue pour vous. Le principe est simple : GitLab joue le rôle de couche d'orchestration pour accélérer l'ensemble de votre cycle de vie logiciel grâce à l'[IA agentique](https://about.gitlab.com/fr-fr/topics/agentic-ai/ \"Qu'est-ce que l'IA agentique ?\"), tandis qu'Amazon Bedrock fournit une couche de modèles de fondation sécurisée et conforme, avec l'inférence IA en arrière-plan.\n\nGitLab Duo Agent Platform vous permet de gérer la planification, les merge de pipelines, les scans de sécurité, la remédiation des vulnérabilités et bien plus encore dans le cadre de vos workflows GitLab, tandis que la passerelle d'IA de GitLab achemine les appels de modèles vers Amazon Bedrock (ou vers des points de terminaison gérés par GitLab et adossés à Bedrock, selon votre configuration). Vous pouvez ainsi vous appuyer sur les politiques de gestion des identités et des accès (IAM), les périmètres de cloud privé virtuel (VPC), les contrôles régionaux et les engagements de dépenses cloud que vous avez déjà définis dans AWS.\n\nSi vous utilisez déjà Amazon Bedrock et souhaitez que l'IA intervienne directement dans vos activités GitLab, et non dans un autre outil de chat autonome, cette combinaison est faite pour vous.\n\n\nDans cet article, nous abordons le problème concret auquel de nombreuses équipes sont confrontées aujourd'hui : l'IA est fragmentée, les flux de données sont flous et l'investissement dans Amazon Bedrock est sous-exploité lorsque l'IA se trouve en dehors du cycle de développement logiciel. \n\nNous détaillerons ensuite vos options de déploiement pour GitLab Duo Agent Platform :\n\n* Intégration avec des modèles auto-hébergés sur Amazon Bedrock pour les déploiements GitLab Self-Managed et la passerelle d'IA auto-hébergée\n* Intégration avec des modèles opérés par GitLab sur Amazon Bedrock (avec des clés appartenant à GitLab) pour les déploiements GitLab Self-Managed et la passerelle d'IA hébergée par GitLab\n* Intégration avec des modèles opérés par GitLab sur Amazon Bedrock (avec des clés appartenant à GitLab) pour les instances GitLab.com et la passerelle d'IA hébergée par GitLab\n\nEnfin, nous conclurons par un résumé expliquant comment cette approche permet d'éviter le shadow AI et la prolifération d'outils spécialisés, sans créer de pile technologique parallèle dédiée à l'IA.\n\n## IA omniprésente, contrôle inexistant\n\nEn ce moment même, des équipes de développement au sein de votre entreprise utilisent peut-être un outil d'IA que votre équipe de sécurité n'a pas approuvé. Des données de prompt quittent peut-être votre environnement par un chemin que personne n'a entièrement cartographié. Et l'investissement de votre organisation dans Amazon Bedrock est peut-être sous-exploité, tandis que d'autres équipes financent séparément des outils d'IA, détournant ainsi les charges de travail et les dépenses cloud des plateformes auxquelles vous vous êtes déjà engagés.\n\nPlutôt qu'un problème humain, il s'agit peut-être d'un problème d'architecture. Et il fait ressortir les trois mêmes contraintes dans presque toutes les entreprises :\n\n**Fragmentation opérationnelle.** Chaque équipe, voire chaque développeur, choisit ses propres outils de développement, y compris les outils d'IA et la sélection des modèles. Cette fragmentation rend la gouvernance de bout en bout au sein du cycle de vie du développement logiciel quasiment impossible.\n\n**Sécurité et souveraineté.** Où circulent réellement les données de prompt et de code ? Qui est propriétaire des logs ?\n\n**Optimisation des dépenses cloud.** Les engagements envers des fournisseurs cloud majeurs comme AWS se diluent à mesure que les charges de travail et l'utilisation de l'IA migrent vers des outils ponctuels en dehors des accords existants des clients.\n\nGitLab Duo Agent Platform et Amazon Bedrock contribuent ensemble à résoudre ces problèmes. La répartition des responsabilités est claire : GitLab Duo Agent Platform prend en charge l'orchestration des workflows avec l'IA agentique pour le développement logiciel, Amazon Bedrock gère la couche d'inférence et héberge les modèles de fondation approuvés, et votre organisation conserve un contrôle total sur les périmètres de données et de politiques déjà définis dans AWS. Trois missions, trois responsables, aucune fragmentation.\n\n## GitLab Duo Agent Platform : le plan de contrôle agentique\n\nGitLab Duo Agent Platform est la couche d'IA agentique de GitLab : un framework d'agents et de flow spécialisés qui opèrent simultanément et en parallèle, dépassant les transferts traditionnels par étapes et contribuant à automatiser les tâches sur l'ensemble du cycle de vie logiciel. Plutôt qu'un assistant unique répondant à des prompts, GitLab Duo Agent Platform permet aux équipes d'orchestrer de nombreux agents d'IA de manière asynchrone, en s'appuyant sur des données unifiées et le contexte du projet, tickets, merge requests, pipelines et résultats de sécurité inclus. Les workflows linéaires se transforment en une collaboration coordonnée et continue entre les équipes de développement et leurs agents d'IA, à grande échelle.\n\nUne fois ce plan de contrôle mis en place, la question qui se pose naturellement est de savoir quelle infrastructure d'IA devrait alimenter ces agents. Pour les clients qui exécutent GitLab Self-Managed sur AWS et ont besoin que le trafic d'inférence, les données de prompt et les logs restent également dans leur environnement AWS avec leurs données de cycle de vie logiciel, Amazon Bedrock en tant que couche d'inférence IA est la solution idéale.\n\n## Amazon Bedrock : une base fiable pour l'IA\n\nAmazon Bedrock est une couche de modèles de fondation entièrement gérée et sans serveur, qui s'exécute intégralement dans votre environnement AWS. Les données clients restent dans leur compte AWS : les entrées et sorties sont chiffrées en transit et au repos, ne sont jamais partagées avec les fournisseurs de modèles et ne sont jamais utilisées pour entraîner des modèles de base. Amazon Bedrock est certifié pour la conformité RGPD, HIPAA et FedRAMP High, couvrant de nombreuses exigences des secteurs réglementés sans configuration supplémentaire. Les équipes peuvent également importer des modèles affinés depuis d'autres sources via Custom Model Import et les déployer aux côtés des modèles Amazon Bedrock natifs via la même infrastructure, sans gérer de pipelines de déploiement séparés. Bedrock Guardrails ajoute des protections configurables sur tous les modèles pour le filtrage de contenu, la détection des hallucinations et la protection des données sensibles.\n\nEnsemble, GitLab Duo Agent Platform et Amazon Bedrock consolident l'orchestration [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") et la gouvernance des modèles d'IA, contribuant à éliminer la fragmentation qui survient lorsque les équipes déploient des outils d'IA de manière indépendante.\n\n## Choisir votre modèle de déploiement\n\nL'intégration offre les mêmes fonctionnalités principales de GitLab Duo Agent Platform, quel que soit le mode de déploiement. Ce qui varie, c'est qui gère GitLab, qui opère la passerelle d'IA et dans quel compte Amazon Bedrock l'inférence s'exécute. Le bon modèle dépend de l'environnement dans lequel votre organisation opère déjà.\n\nÀ un niveau général, l'intégration comporte trois composants principaux :\n\n* **GitLab Duo Agent Platform :** workflows agentiques intégrés tout au long du cycle de vie du développement logiciel\n* **Passerelle d'IA (gérée par GitLab ou auto-hébergée) :** la couche d'abstraction entre GitLab Duo Agent Platform et le backend de modèles de fondation\n* **Amazon Bedrock :** le substrat de modèles d'IA et d'inférence\n\n![Déploiement de GitLab et AWS Bedrock](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776362365/udmvmv2efpmwtkxgydch.png)\n\nLe choix d'un modèle de déploiement est guidé par l'endroit où une organisation souhaite placer les leviers de contrôle. Les modèles présentés ci-dessous sont conçus pour s'adapter à la situation actuelle des équipes, qu'elles privilégient une approche SaaS, optent pour une gestion autonome à des fins de conformité ou misent entièrement sur AWS en tirant parti de leurs investissements existants dans Amazon Bedrock.\n\n| Modèle de déploiement | Instance GitLab.com avec passerelle d'IA hébergée par GitLab et modèles Amazon Bedrock opérés par GitLab | GitLab Self-Managed avec passerelle d'IA hébergée par GitLab et modèles Bedrock opérés par GitLab | GitLab Self-Managed avec passerelle d'IA auto-hébergée et modèles Bedrock opérés par le client |\n| :---- | :---- | :---- | :---- |\n| **Idéal si vous :** | Utilisez principalement GitLab.com et ne souhaitez pas auto-héberger la passerelle d'IA et les modèles Bedrock | Avez besoin de GitLab Self-Managed pour des raisons de conformité et opérationnelles, mais ne souhaitez pas gérer la couche d'IA | Êtes centré sur AWS avec une utilisation Bedrock existante et des besoins stricts en matière de données et de contrôle |\n| **Principaux avantages** | La solution la plus rapide et clé en main pour accéder aux workflows de GitLab Duo Agent Platform : GitLab gère GitLab.com, la passerelle d'IA, intégrée aux modèles d'IA Bedrock. | Conservez GitLab déployé dans votre propre environnement tout en consommant les modèles Bedrock via une passerelle d'IA gérée par GitLab, alliant contrôle du déploiement et simplification des opérations d'IA. | Exécutez GitLab et la passerelle d'IA dans votre compte AWS, réutilisez vos configurations IAM/VPC/régions existantes, conservez les logs et les données dans votre environnement, et imputez l'utilisation de Bedrock à vos engagements de dépenses AWS existants. |\n\n## Comment les clients utilisent GitLab Duo Agent Platform avec Amazon Bedrock\n\nLes équipes plateforme peuvent utiliser GitLab Duo Agent Platform avec Amazon Bedrock pour standardiser les modèles chargés des suggestions de code, de l'analyse de sécurité et de la remédiation des pipelines. Cela permet d'appliquer des garde-fous et une journalisation de manière centralisée, plutôt que de laisser chaque équipe adopter des outils séparés de façon indépendante.\n\nLes workflows de sécurité bénéficient d'avantages particuliers. Les agents de GitLab Duo Agent Platform peuvent proposer et valider des correctifs pour les résultats de sécurité au sein de GitLab, contribuant à réduire le travail de triage manuel que les développeurs devraient autrement effectuer en dehors de la plateforme.\n\nPour les entreprises déjà engagées envers AWS, le routage des charges de travail d'IA via Bedrock depuis GitLab vous permet de maintenir l'utilisation de l'IA par les développeurs en cohérence avec les accords cloud existants, plutôt que de générer des dépenses séparées et non planifiées.\n\n## En résumé\n\nLes contraintes qui freinent l'adoption de l'IA en entreprise ne sont souvent pas d'ordre technique, elles sont organisationnelles : fragmentation des outils, flux de données non gouvernés et dépenses cloud qui ne se consolident jamais. Ce sont ces problèmes qui peuvent bloquer les programmes d'IA même après la réussite des projets pilotes.\n\nGitLab Duo Agent Platform et Amazon Bedrock permettent de s'attaquer directement à chacun de ces problèmes. Les équipes plateforme bénéficient d'une gouvernance cohérente, d'une auditabilité et de chemins standardisés pour l'utilisation de l'IA tout au long du cycle de vie du développement logiciel. Les équipes de développement disposent de workflows agentiques rationalisés qui s'intègrent naturellement à GitLab. Et les organisations centrées sur AWS peuvent étendre leur investissement Bedrock existant plutôt que de construire une infrastructure d'IA parallèle.\n\nLe résultat est un programme d'IA qui évolue sans se fragmenter. Gouvernance et vélocité sur la même pile, au service des mêmes équipes, sous des politiques que l'organisation maîtrise déjà.\n\n\n> Pour déterminer quel modèle de déploiement convient à votre organisation et comment aligner GitLab Duo Agent Platform et Amazon Bedrock avec votre stratégie AWS existante, [contactez l'équipe commerciale de GitLab](https://about.gitlab.com/sales/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr) et nous vous aiderons à concevoir et mettre en œuvre la meilleure architecture pour votre environnement. Vous pouvez également [visiter notre page partenaire AWS](https://about.gitlab.com/fr-fr/partners/technology-partners/aws/) pour en savoir plus.",[279,711,712],"AWS","AI/ML","2026-04-22",[715,716],"Joe Mann","Mark Kriaf","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776362275/ozbwn9tk0dditpnfddlz.png",{"featured":30,"template":15,"slug":719},"gitlab-amazon-platform-orchestration-on-a-trusted-ai-foundation",{"content":721,"config":731},{"title":722,"description":723,"authors":724,"heroImage":726,"date":727,"body":728,"category":11,"tags":729},"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.",[725],"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/).",[11,712,730],"news",{"featured":14,"template":15,"slug":732},"gitlab-18-11-budget-guardrails-for-gitlab-credits",{"content":734,"config":744},{"title":735,"description":736,"authors":737,"heroImage":739,"date":727,"body":740,"category":11,"tags":741},"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.",[738],"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).",[742,712,11,743],"security","features",{"featured":14,"template":15,"slug":745},"automate-remediation-with-ready-to-merge-ai-code-fixes",{"promotions":747},[748,762,774,785],{"id":749,"categories":750,"header":752,"text":753,"button":754,"image":759},"ai-modernization",[751],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":755,"config":756},"Get your AI maturity score",{"href":757,"dataGaName":758,"dataGaLocation":246},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":760},{"src":761},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":763,"categories":764,"header":766,"text":753,"button":767,"image":771},"devops-modernization",[11,765],"devsecops","Are you just managing tools or shipping innovation?",{"text":768,"config":769},"Get your DevOps maturity score",{"href":770,"dataGaName":758,"dataGaLocation":246},"/assessments/devops-modernization-assessment/",{"config":772},{"src":773},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":775,"categories":776,"header":777,"text":753,"button":778,"image":782},"security-modernization",[742],"Are you trading speed for security?",{"text":779,"config":780},"Get your security maturity score",{"href":781,"dataGaName":758,"dataGaLocation":246},"/assessments/security-modernization-assessment/",{"config":783},{"src":784},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":786,"paths":787,"header":790,"text":791,"button":792,"image":797},"github-azure-migration",[788,789],"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":793,"config":794},"See how GitLab compares to GitHub",{"href":795,"dataGaName":796,"dataGaLocation":246},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":798},{"src":773},{"header":800,"blurb":801,"button":802,"secondaryButton":806},"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":48,"config":803},{"href":804,"dataGaName":51,"dataGaLocation":805},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/fr-fr/","feature",{"text":53,"config":807},{"href":55,"dataGaName":56,"dataGaLocation":805},1777302664012]