[{"data":1,"prerenderedAt":765},["ShallowReactive",2],{"/fr-fr/blog/ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline":3,"navigation-fr-fr":34,"banner-fr-fr":439,"footer-fr-fr":449,"blog-post-authors-fr-fr-Dov Hershkovitch":659,"blog-related-posts-fr-fr-ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline":673,"assessment-promotions-fr-fr":716,"next-steps-fr-fr":756},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":25,"isFeatured":11,"meta":26,"navigation":27,"path":28,"publishedDate":20,"seo":29,"stem":30,"tagSlugs":31,"__hash__":33},"blogPosts/fr-fr/blog/ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline.yml","Ci Cd Inputs Secure And Preferred Method To Pass Parameters To A Pipeline",[7],"dov-hershkovitch",null,"product",{"featured":11,"template":12,"slug":13},false,"BlogPost","ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline",{"heroImage":15,"body":16,"authors":17,"updatedDate":19,"date":20,"title":21,"tags":22,"description":24,"category":9},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658912/Blog/Hero%20Images/blog-image-template-1800x945__20_.png","Les intrants CI/CD représentent une avancée majeure dans la gestion des pipelines.\nSpécialement conçus pour passer des paramètres typés, validés et sécurisés, ils instaurent des contrats explicites et une sécurité renforcée entre les composants de vos workflows et résolvent enfin les limites structurelles auxquelles les équipes de développement font face depuis des années avec les variables traditionnelles.\n\nLes variables CI/CD ont été détournées de leur usage initial. Historiquement, elles étaient conçues pour stocker des paramètres de configuration, et non comme un mécanisme sophistiqué de transmission de paramètres dans le cadre de workflows complexes. Ce décalage a entraîné son lot de problèmes : manque de fiabilité, failles de sécurité, complexité croissante en termes de maintenance.\n\nDans cet article, découvrez pourquoi les intrants CI/CD sont désormais l'approche recommandée pour passer des paramètres à vos pipelines, ainsi que leurs nombreux avantages (sécurité des types, prévention des échecs de pipeline, élimination des conflits entre variables, automatisation simplifiée). Des exemples concrets illustreront leur mise en œuvre et les problèmes qu'ils résolvent, dans l'espoir de vous convaincre d'abandonner les solutions de contournement à base de variables au profit d'une approche plus fiable et structurée.\n\n## Les coûts cachés de la transmission de paramètres via des variables\n\nUtiliser des variables pour passer des paramètres aux pipelines peut sembler pratique, mais cette approche peut être source de frustration et poser de nombreux risques.\n\n**Absence de validation des types**\n\nLes variables sont des chaînes de caractères. Sans validation des types, un pipeline peut recevoir accidentellement une chaîne à la place d'une valeur booléenne ou d'un nombre et entraîner des échecs inattendus. Un workflow de déploiement de production critique peut par exemple échouer quelques heures après son démarrage, car une vérification booléenne dans une variable n'a pas été transmise correctement.\n\n**Mutabilité pendant l'exécution**\n\nLes variables peuvent être modifiées à tout moment lors de l'exécution du pipeline, ce qui génère des comportements imprévisibles lorsque plusieurs jobs tentent de modifier les mêmes valeurs. Par exemple, deploy_job_a définit `DEPLOY_ENV=staging`, mais deploy_job_b attribue la valeur `production` à `DEPLOY_ENV`.\n\n**Risques de sécurité**\n\nLes variables utilisées comme de simples paramètres héritent souvent des mêmes autorisations d'accès que les secrets sensibles, ce qui entraîne des problèmes de sécurité. Il n'existe aucun contrat définissant les paramètres attendus par un pipeline, leurs types ou leurs valeurs par défaut. Ainsi, un paramètre apparemment anodin comme `BUILD_TYPE` peut soudainement se retrouver à tort avec un accès à des secrets de production simplement parce que les variables ne font pas intrinsèquement la distinction entre les paramètres et les données sensibles.\n\nPire encore, les erreurs ne sont détectées qu'au moment de l'exécution du pipeline, parfois après plusieurs minutes, voire plusieurs heures. Une simple variable mal configurée peut ainsi provoquer l'échec d'un pipeline, avec à la clé la perte de précieuses ressources [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") et une perte de temps pour l'équipe de développement. Pour limiter ces risques, les équipes recourent alors à des solutions de contournement, telles que des scripts de validation maison, une documentation excessive ou des conventions de nommage complexes, autant de tentatives pour renforcer du mieux possible la fiabilité de la transmission de paramètres basée sur des variables.\n\nNombreux sont les utilisateurs qui ont exprimé le besoin de disposer de fonctionnalités de débogage local pour tester les configurations de leurs pipelines avant le déploiement. Bien que cette solution semble logique, elle se révèle rapidement inefficace dans la pratique. Les workflows CI/CD s'appuient sur des dizaines de systèmes tiers (fournisseurs de services cloud, dépôts d'artefacts, scanners de sécurité, cibles de déploiement), qui ne peuvent tout simplement pas être répliqués localement. Même dans cette éventualité, la complexité rendrait les environnements de test locaux presque impossibles à maintenir. Face à ces limites, une remise en question s'imposait. Au lieu de chercher à mieux tester les pipelines localement, nous avons cherché à comprendre comment nous pouvions éviter les erreurs de configuration liées à la transmission de paramètres via des variables avant même l'exécution du workflow d'automatisation CI/CD.\n\n## Le casse-tête de la priorité des variables\n\nLe système de variables de GitLab comprend plusieurs [niveaux de priorité](https://docs.gitlab.com/ci/variables/#cicd-variable-precedence) qui offrent une grande flexibilité en fonction des cas d'utilisation rencontrés. Bien que ce système soit utile dans de nombreux scénarios, comme permettre aux administrateurs de définir des valeurs par défaut à l'échelle de l'instance ou du groupe tout en autorisant les projets individuels à les remplacer si nécessaire, il peut créer des difficultés lors de la construction de composants de pipeline réutilisables.\n\nLorsque vous développez des composants ou des templates destinés à être partagés dans différents projets et groupes, la hiérarchie de priorité des variables peut rendre leur comportement moins prévisible. Par exemple, un template qui fonctionne parfaitement dans un projet peut produire des résultats différents dans un autre, simplement parce que certaines variables ont été redéfinies au niveau du groupe ou de l'instance et ne sont pas visibles dans la configuration locale du pipeline.\n\nLorsque vous combinez plusieurs templates, il devient alors difficile de savoir quelles variables sont définies ainsi qu'où et comment elles interagissent.\n\nEn outre, les auteurs de composants doivent non seulement documenter les variables que leur template utilise, mais également identifier les risques de conflits avec des variables susceptibles d'être définies à des niveaux de priorité plus élevés.\n\n### Exemples de hiérarchie de priorité des variables\n\n**Fichier de pipeline principal (`.gitlab-ci.yml`) :**\n\n```yaml\nvariables:\n  ENVIRONMENT: production  # Top-level default for all jobs\n  DATABASE_URL: prod-db.example.com\n\ninclude:\n  - local: 'templates/test-template.yml'\n  - local: 'templates/deploy-template.yml'\n\n```\n\n**Template de test (`templates/test-template.yml`) :**\n\n```yaml\nrun-tests:\n  variables:\n    ENVIRONMENT: test  # Job-level variable overrides the default\n  script:\n    - echo \"Running tests in $ENVIRONMENT environment\"\n    - echo \"Database URL is $DATABASE_URL\"  # Still inherits prod-db.example.com!\n    - run-integration-tests --env=$ENVIRONMENT --db=$DATABASE_URL\n    `# Issue: Tests run in \"test\" environment but against production database`\n\n```\n\n**Template de déploiement (`templates/deploy-template.yml`) :**\n\n```yaml\ndeploy-app:\n  script:\n    - echo \"Deploying to $ENVIRONMENT\"  # Uses production (top-level default)\n    - echo \"Database URL is $DATABASE_URL\"  # Uses prod-db.example.com\n    - deploy --target=$ENVIRONMENT --db=$DATABASE_URL\n    # This will deploy to production as intended\n\n```\n\n**Défis dans cet exemple :**\n\n1. Héritage partiel : le job de test hérite bien de `ENVIRONMENT=test`, mais conserve `DATABASE_URL=prod-db.example.com`.\n2. Coordination complexe : les auteurs de templates doivent connaître l'ensemble des variables définies en amont pour éviter les conflits.\n3. Remplacement imprévisible : lorsqu'une variable définie au niveau du job porte le même nom qu'une variable globale, elle la remplace — un comportement qui peut être difficile à anticiper.\n4. Dépendances cachées : les templates dépendent des noms de variables définis dans le pipeline principal.\n\nPour relever ces défis, GitLab a introduit les [intrants CI/CD](https://docs.gitlab.com/ee/ci/inputs/ \"Qu'est-ce qu'un intrant CI/CD ?\"), une solution dédiée à la transmission des paramètres aux pipelines, qui offre des paramètres typés, validés dès la création du pipeline et non au moment de son exécution.\n\n## Principes de base des intrants CI/CD\n\nLes intrants CI/CD permettent de définir des paramètres typés pour des pipelines réutilisables, avec une validation intégrée dès leur création. Conçus spécifiquement pour fournir des valeurs au moment de l'exécution du pipeline, ils instaurent un contrat explicite entre le pipeline et ses utilisateurs : chaque paramètre attendu y est clairement défini, ainsi que son type et ses contraintes.\n\n### Flexibilité et portée de la configuration\n\nL'un des avantages des intrants CI/CD est leur flexibilité en termes de temps de configuration. Évalués et interpolés dès la création du pipeline à l'aide du format d'interpolation `$[[ inputs.input-id ]]`, ils peuvent être utilisés dans toutes les parties de la configuration de votre pipeline, y compris les noms de jobs, les conditions de règles, les images de conteneurs et tout autre élément du fichier de configuration YAML. Ils contournent ainsi les limites liées à l'interpolation des variables dans certains contextes.\n\nVoici un cas d'utilisation courant : vous définissez des noms de jobs comme suit : `test-$[[ inputs.environment ]]-deployment`.\n\nEn intégrant des intrants CI/CD dans les noms de jobs, vous évitez les conflits lorsqu'un composant est inclus plusieurs fois dans un même pipeline. Sinon, le fait d'inclure le même composant deux fois entraînerait des conflits de noms de jobs, la deuxième inclusion écrasant la première. Les intrants CI/CD permettent au contraire de générer des noms de jobs uniques à chaque inclusion.\n\n**Voici le script sans les intrants CI/CD :**\n\n```yaml\ntest-service:\n  variables:\n    SERVICE_NAME: auth-service\n    ENVIRONMENT: staging\n  script:\n    - run-tests-for $SERVICE_NAME in $ENVIRONMENT\n\n```\n\n**Voici le script avec les intrants CI/CD :**\n\n```yaml\nspec:\n  inputs:\n    environment:\n      type: string\n    service_name:\n      type: string\n\ntest-$[[ inputs.service_name ]]-$[[ inputs.environment ]]:\n  script:\n    - run-tests-for $[[ inputs.service_name ]] in $[[ inputs.environment ]]\n\n```\n\nLorsqu'un composant est inclus plusieurs fois avec des intrants différents, il génère des jobs tels que `test-auth-service-staging`, `test-payment-service-production` et `test-notification-service-development`. Chaque job porte ainsi un nom unique et explicite qui indique clairement son objectif, ce qui renforce la visualisation du pipeline : en effet, cela évite que plusieurs jobs avec des noms identiques se remplacent les uns les autres.\n\nRevenons maintenant au premier exemple présenté au début de cet article, cette fois en tirant parti des intrants CI/CD. Premier avantage immédiat : au lieu de gérer plusieurs fichiers de templates, nous pouvons désormais n'en maintenir qu'un seul et le réutiliser avec des valeurs d'intrant personnalisées :\n\n```yaml\nspec:\n  inputs:\n    environment:\n      type: string\n    database_url:\n      type: string\n    action:\n      type: string\n---\n\n$[[ inputs.action ]]-$[[ inputs.environment ]]:\n  script:\n    - echo \"Running $[[ inputs.action ]] in $[[ inputs.environment ]] environment\"\n    - echo \"Database URL is $[[ inputs.database_url ]]\"\n    - run-$[[ inputs.action ]] --env=$[[ inputs.environment ]] --db=$[[ inputs.database_url ]]\n\n```\n\nDans le fichier principal `gitlab-ci.yml`, nous pouvons l'inclure deux fois (ou plus) avec des valeurs différentes, en veillant à éviter les conflits de noms.\n\n```yaml\ninclude:\n  - local: 'templates/environment-template.yml'\n    inputs:\n      environment: test\n      database_url: test-db.example.com\n      action: tests\n  - local: 'templates/environment-template.yml'\n    inputs:\n      environment: production\n      database_url: prod-db.example.com\n      action: deploy\n\n```\n\n**Résultat :** au lieu de maintenir des fichiers YAML distincts pour les jobs de test et de déploiement, vous disposez désormais d'un template réutilisable unique qui gère les deux cas d'utilisation en toute sécurité. Cette approche s'adapte à un nombre illimité d'environnements ou de types de jobs, ce qui réduit les frais de maintenance, élimine la duplication du code et garantit la cohérence de l'ensemble de la configuration de votre pipeline. Vous n'avez qu'un seul template à maintenir au lieu de plusieurs, sans risque de conflit de variables ni de dérive de configuration.\n\n### Validation et sécurité des types\n\nL'un des grands atouts des intrants CI/CD par rapport aux variables réside dans les capacités de validation des types. Ils prennent en charge différents types de valeurs, notamment les chaînes, les nombres, les valeurs booléennes et les tableaux, et la validation a lieu dès la création du pipeline. Si vous définissez un intrant CI/CD en tant que valeur booléenne, mais que vous passez une chaîne, GitLab rejette le pipeline avant l'exécution de tout job, ce qui vous permet d'économiser du temps et des ressources.\n\nVoici un exemple illustrant l'énorme avantage de la validation des types.\n\n**Sans validation des types (variables) :**\n\n```yaml\nvariables:\n  ENABLE_TESTS: \"true\"  # Always a string\n  MAX_RETRIES: \"3\"      # Always a string\n\ndeploy_job:\n  script:\n    - if [ \"$ENABLE_TESTS\" = true ]; then  # This fails!\n        echo \"Running tests\"\n      fi\n    - retry_count=$((MAX_RETRIES + 1))      # String concatenation: \"31\"\n\n```\n\n**Problème :** la vérification booléenne échoue, car « `true` » (chaîne) n'est pas égal à `true` (valeur booléenne).\n\n**Avec validation des types (intrants CI/CD) :**\n\n```yaml\nspec:\n  inputs:\n    enable_tests:\n      type: boolean\n      default: true\n    max_retries:\n      type: number\n      default: 3\n\n\n\n\ndeploy_job:\n  script:\n    - if [ \"$[[ inputs.enable_tests ]]\" = true ]; then  # Works correctly\n        echo \"Running tests\"\n      fi\n    - retry_count=$(($[[ inputs.max_retries ]] + 1))    # Math works: 4\n\n```\n\n**Impact réel d'un échec de validation des types via des variables** : imaginons qu'un développeur ou processus déclenche un pipeline GitLab CI/CD avec `ENABLE_TESTS = yes` au lieu de `true`. Supposons qu'il faille en moyenne 30 minutes avant que le job de déploiement ne commence : lorsque ce job démarre, au bout de 30 minutes d'exécution du pipeline ou plus, le script de déploiement tente d'évaluer la valeur booléenne et échoue.\n\nCela a un impact non seulement sur le délai de mise sur le marché, mais également sur le temps de débogage requis pour trouver la raison de l'échec d'un job de déploiement apparemment basique.\n\nAvec les intrants CI/CD basés sur la validation des types, GitLab CI/CD génère immédiatement une erreur et fournit un message d'erreur explicite concernant l'incompatibilité de type.\n\n### Sécurité et contrôle d'accès\n\nLes intrants CI/CD renforcent la sécurité, car ils contrôlent de façon stricte la transmission de paramètres avec des contrats explicites qui définissent précisément les valeurs attendues et autorisées. Ainsi, les limites sont claires entre les paramètres et la logique du pipeline. De plus, une fois le pipeline démarré, les intrants ne peuvent pas être modifiés pendant l'exécution, ce qui garantit un comportement prévisible tout au long du cycle de vie du pipeline et permet d'éliminer les risques de sécurité liés à la manipulation des variables en cours de route.\n\n### Portée et cycle de vie\n\nLes variables définies à l'aide du mot-clé `variables:` au niveau supérieur de votre fichier `.gitlab-ci.yml` s'appliquent par défaut à tous les jobs de votre pipeline. Lorsque vous incluez des templates, vous devez tenir compte de ces variables globales, car elles peuvent interagir avec le comportement attendu du template en raison de l'ordre de priorité des variables propre à GitLab.\n\nÀ l'inverse, les intrants CI/CD sont définis dans les fichiers de configuration CI (par exemple, les composants ou les templates), puis des valeurs leur sont attribuées lorsqu'un pipeline est déclenché, ce qui vous permet de personnaliser les configurations CI réutilisables. Ils servent uniquement à la création et la configuration du pipeline et sont limités au fichier de configuration CI où ils sont définis. Une fois l'exécution du pipeline lancée, ils ne peuvent plus être modifiés. Étant donné que chaque composant conserve ses propres intrants, il n'y a aucun risque d'interférence avec d'autres composants ou templates de votre pipeline. Cette approche prévient les conflits et les remplacements de variables qui sont fréquents avec le système traditionnel basé sur les variables globales.\n\n## Combiner variables et intrants\n\nDe nombreuses équipes utilisent de manière intensive des workflows basés sur les variables, et une migration complète vers les intrants CI/CD ne se fait pas du jour au lendemain. C'est pourquoi nous avons développé des mécanismes qui permettent d'utiliser à la fois des intrants et des variables pour favoriser la transition entre les deux systèmes et surmonter les principaux défis liés à l'expansion des variables.\n\nPrenons un exemple concret pour illustrer cette complémentarité.\n\n**Expansion des variables dans les conditions de règles**\n\nL'utilisation de variables qui contiennent d'autres références au sein des conditions `rules:if` peut s'avérer problématique. GitLab ne développe les variables que sur un niveau lors de l'évaluation de ces règles, ce qui peut entraîner des comportements inattendus :\n\n```yaml\n# This doesn't work as expected\n\nvariables:\n  TARGET_ENV:\n    value: \"${CI_COMMIT_REF_SLUG}\"\n\ndeploy-job:\n  rules:\n    - if: '$TARGET_ENV == \"production\"'  # Compares \"${CI_COMMIT_REF_SLUG}\" != \"production\"\n      variables:\n        DEPLOY_MODE: \"blue-green\"\n\n```\n\nLa fonction `expand_vars` résout ce problème en forçant une expansion appropriée des variables dans les intrants :\n\n```yaml\nspec:\n  inputs:\n    target_environment:\n      description: \"Target deployment environment\"\n      default: \"${CI_COMMIT_REF_SLUG}\"\n---\n\n\ndeploy-job:\n  rules:\n    - if: '\"$[[ inputs.target_environment | expand_vars ]]\" == \"production\"'\n      variables:\n        DEPLOY_MODE: \"blue-green\"\n        APPROVAL_REQUIRED: \"true\"\n    - when: always\n      variables:\n        DEPLOY_MODE: \"rolling\"\n        APPROVAL_REQUIRED: \"false\"\n  script:\n    - echo \"Target: $[[ inputs.target_environment | expand_vars ]]\"\n    - echo \"Deploy mode: ${DEPLOY_MODE}\"\n\n```\n\n### L'importance d'une telle opérabilité\n\nSans `expand_vars`, les conditions de règles sont évaluées à partir de la référence littérale d'une variable (comme `\"${CI_COMMIT_REF_SLUG}\"`) plutôt que sa variable développée (comme `\"production\"`). Il en résulte des règles qui ne se déclenchent pas comme prévu et brisent la logique conditionnelle du pipeline.\n\n**Remarques importantes concernant expand_vars :**\n\n* Seules les variables qui peuvent être utilisées avec le terme *include* sont prises en charge.\n* Les variables doivent être rendues accessibles (non marquées comme protégées/masquées).\n* L'expansion des variables imbriquées n'est pas prise en charge.\n* Les conditions de règles avec `expand_vars` doivent être correctement citées : `'\"$[[ inputs.name | expand_vars ]]\" == \"value\"'`.\n\nCe mécanisme résout la limitation d'expansion de variables à un seul niveau et fonctionne pour toute logique conditionnelle qui nécessite de comparer des valeurs de variables entièrement résolues.\n\n### Chaînage de fonctions pour un traitement avancé\n\nEn plus de `expand_vars`, vous pouvez chaîner d'autres fonctions telles que `truncate` pour raccourcir les valeurs aux restrictions de nommage (par exemple, celles imposées par les noms de ressources [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes\")). Vous pouvez ainsi créer des pipelines plus sophistiqués, capables de traiter les paramètres tout en maintenant la sécurité et la prévisibilité qu'offrent les intrants CI/CD.\n\n```yaml\nspec:\n  inputs:\n    service_identifier:\n      default: 'service-$CI_PROJECT_NAME-$CI_COMMIT_REF_SLUG'\n---\n\ncreate-resource:\n  script:\n    - resource_name=$[[ inputs.service_identifier | expand_vars | truncate(0,50) ]]\n\n```\n\nCette capacité d'intégration vous permet d'adopter progressivement les intrants CI/CD tout en tirant parti de votre infrastructure de variables existante, ce qui facilite la migration vers le nouveau système.\n\n### Des composants uniquement aux pipelines CI complets\n\nJusqu'à la version GitLab 17.11, les intrants n'étaient réservés qu'aux composants et templates inclus via la syntaxe `include:`, ce qui limitait leur utilisation aux configurations CI/CD réutilisables, mais ne répondait pas au besoin plus large de personnalisation dynamique des pipelines.\n\n### Prise en charge des intrants à l'échelle du pipeline\n\nÀ partir de GitLab 17.11, les intrants peuvent désormais être utilisés pour modifier en toute sécurité le comportement du pipeline dans tous les contextes d'exécution associés afin de remplacer le recours traditionnel aux variables de pipeline. Cette prise en charge étendue inclut notamment les pipelines suivants :\n\n* Pipelines planifiés : définissez des intrants avec des valeurs par défaut pour les exécutions automatisées et autorisez le remplacement manuel si nécessaire.\n* Pipelines en aval : transmettez des intrants structurés aux pipelines enfants et multi-projets, avec une validation et une sécurité des types garanties.\n* Pipelines manuels : proposez une interface claire et validée pour la saisie des intrants.\n\nCes premières améliorations, auxquelles s'ajouteront prochainement d'autres fonctionnalités, permettent aux équipes de moderniser leurs pipelines tout en assurant une rétrocompatibilité progressive. Une fois les intrants CI/CD pleinement adoptés, vous pouvez désactiver les variables de pipeline pour garantir un environnement CI/CD plus sécurisé et prévisible.\n\n## Résumé\n\nLa migration des variables vers les intrants CI/CD représente plus qu'une simple mise à niveau technique : cette évolution garantit des [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") plus faciles à maintenir, plus prévisibles et plus sécurisés. Même si les variables continuent de servir des objectifs importants dans de nombreux scénarios de configuration, les intrants CI/CD fournissent les capacités de transmission de paramètres tant attendues par les équipes de développement.\n\nConscients que les variables sont profondément intégrées dans les workflows actuels, nous avons conçu des passerelles entre les deux systèmes. La fonction `expand_vars` et d'autres capacités d'intrant permettent de tirer parti de ce mécanisme, mais aussi de votre infrastructure de variables existante.\n\nEn commençant par de nouveaux composants et templates, puis en migrant progressivement les workflows critiques, vous constaterez rapidement les avantages de contrats explicites, d'une détection précoce des erreurs et d'une automatisation plus fiable qui s'étend à l'ensemble de votre entreprise. De plus, l'adoption des intrants CI/CD constitue un socle idéal pour tirer pleinement parti du [catalogue CI/CD de GitLab](https://gitlab.com/explore/catalog). Grâce à leurs interfaces typées, les composants réutilisables deviennent des fondamentaux puissants pour structurer vos workflows [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que l'approche DevOps ?\"). Nous reviendrons sur ce sujet en détail dans un prochain article.\n\nAdopter les intrants CI/CD aujourd'hui, c'est investir dans des pipelines plus robustes, plus lisibles, plus compréhensibles pour demain. Même si vous utilisez déjà un système basé sur des variables, les intrants peuvent être intégrés progressivement afin d'assurer une transition en douceur.\n\n## Prochaines étapes\n\nNous prévoyons d'étendre les capacités actuelles des intrants en vue de résoudre deux enjeux clés : améliorer le déclenchement des pipelines avec des options en cascade qui [s'ajustent dynamiquement au choix de l'utilisateur](https://gitlab.com/gitlab-org/gitlab/-/issues/520094) et introduire des intrants au niveau des jobs afin de pouvoir [relancer des jobs spécifiques avec des paramètres différents](https://gitlab.com/groups/gitlab-org/-/epics/17833). Nous vous encourageons à suivre ces discussions, à partager vos retours et à contribuer à façonner le développement de ces fonctionnalités via notre [ticket dédié aux retours d'expérience](https://gitlab.com/gitlab-org/gitlab/-/issues/407556).\n",[18],"Dov Hershkovitch","2025-08-07","2025-07-07","Intrants CI/CD : transmission de paramètres aux pipelines",[23],"CI/CD","Les intrants CI/CD de GitLab remplacent les variables par des paramètres typés et validés pour transmettre des instructions fiables et sécurisées aux pipelines.","yml",{},true,"/fr-fr/blog/ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline",{"noIndex":11,"title":21,"description":24},"fr-fr/blog/ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline",[32],"cicd","Fe5vqWqR5CFpNUyI0aINDHQDVznjTYywQ3o77djOwmw",{"data":35},{"logo":36,"freeTrial":41,"sales":46,"login":51,"items":56,"search":365,"minimal":400,"duo":419,"pricingDeployment":429},{"config":37},{"href":38,"dataGaName":39,"dataGaLocation":40},"/fr-fr/","gitlab logo","header",{"text":42,"config":43},"Commencer un essai gratuit",{"href":44,"dataGaName":45,"dataGaLocation":40},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr&glm_content=default-saas-trial/","free trial",{"text":47,"config":48},"Contacter l'équipe commerciale",{"href":49,"dataGaName":50,"dataGaLocation":40},"/fr-fr/sales/","sales",{"text":52,"config":53},"Connexion",{"href":54,"dataGaName":55,"dataGaLocation":40},"https://gitlab.com/users/sign_in/","sign in",[57,84,180,185,286,346],{"text":58,"config":59,"cards":61},"Plateforme",{"dataNavLevelOne":60},"platform",[62,68,76],{"title":58,"description":63,"link":64},"La plateforme d'orchestration intelligente pour le DevSecOps",{"text":65,"config":66},"Découvrir notre plateforme",{"href":67,"dataGaName":60,"dataGaLocation":40},"/fr-fr/platform/",{"title":69,"description":70,"link":71},"GitLab Duo Agent Platform","L'IA agentique pour l'ensemble du cycle de développement logiciel",{"text":72,"config":73},"Découvrir GitLab Duo",{"href":74,"dataGaName":75,"dataGaLocation":40},"/fr-fr/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":77,"description":78,"link":79},"Choisir GitLab","Découvrez les principales raisons pour lesquelles les entreprises choisissent GitLab",{"text":80,"config":81},"En savoir plus",{"href":82,"dataGaName":83,"dataGaLocation":40},"/fr-fr/why-gitlab/","why gitlab",{"text":85,"left":27,"config":86,"link":88,"lists":92,"footer":162},"Produit",{"dataNavLevelOne":87},"solutions",{"text":89,"config":90},"Voir toutes les solutions",{"href":91,"dataGaName":87,"dataGaLocation":40},"/fr-fr/solutions/",[93,117,140],{"title":94,"description":95,"link":96,"items":101},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":97},{"icon":98,"href":99,"dataGaName":100,"dataGaLocation":40},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[102,105,108,113],{"text":23,"config":103},{"href":104,"dataGaLocation":40,"dataGaName":23},"/fr-fr/solutions/continuous-integration/",{"text":69,"config":106},{"href":74,"dataGaLocation":40,"dataGaName":107},"gitlab duo agent platform - product menu",{"text":109,"config":110},"Gestion du code source",{"href":111,"dataGaLocation":40,"dataGaName":112},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":114,"config":115},"Livraison de logiciels automatisée",{"href":99,"dataGaLocation":40,"dataGaName":116},"Automated software delivery",{"title":118,"description":119,"link":120,"items":125},"Sécurité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":121},{"href":122,"dataGaName":123,"dataGaLocation":40,"icon":124},"/fr-fr/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[126,130,135],{"text":127,"config":128},"Tests de sécurité des applications",{"href":122,"dataGaName":129,"dataGaLocation":40},"Application security testing",{"text":131,"config":132},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":133,"dataGaLocation":40,"dataGaName":134},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":136,"config":137},"Conformité logicielle",{"href":138,"dataGaName":139,"dataGaLocation":40},"/fr-fr/solutions/software-compliance/","Software Compliance",{"title":141,"link":142,"items":147},"Mesures",{"config":143},{"icon":144,"href":145,"dataGaName":146,"dataGaLocation":40},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[148,152,157],{"text":149,"config":150},"Visibilité et mesures",{"href":145,"dataGaLocation":40,"dataGaName":151},"Visibility and Measurement",{"text":153,"config":154},"Gestion de la chaîne de valeur",{"href":155,"dataGaLocation":40,"dataGaName":156},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":158,"config":159},"Données d'analyse et informations clés",{"href":160,"dataGaLocation":40,"dataGaName":161},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":163,"items":164},"GitLab pour",[165,170,175],{"text":166,"config":167},"Entreprises",{"href":168,"dataGaLocation":40,"dataGaName":169},"/fr-fr/enterprise/","enterprise",{"text":171,"config":172},"PME",{"href":173,"dataGaLocation":40,"dataGaName":174},"/fr-fr/small-business/","small business",{"text":176,"config":177},"Secteur public",{"href":178,"dataGaLocation":40,"dataGaName":179},"/fr-fr/solutions/public-sector/","public sector",{"text":181,"config":182},"Tarifs",{"href":183,"dataGaName":184,"dataGaLocation":40,"dataNavLevelOne":184},"/fr-fr/pricing/","pricing",{"text":186,"config":187,"link":189,"lists":193,"feature":273},"Ressources",{"dataNavLevelOne":188},"resources",{"text":190,"config":191},"Afficher toutes les ressources",{"href":192,"dataGaName":188,"dataGaLocation":40},"/fr-fr/resources/",[194,227,245],{"title":195,"items":196},"Premiers pas",[197,202,207,212,217,222],{"text":198,"config":199},"Installation",{"href":200,"dataGaName":201,"dataGaLocation":40},"/fr-fr/install/","install",{"text":203,"config":204},"Guides de démarrage",{"href":205,"dataGaName":206,"dataGaLocation":40},"/fr-fr/get-started/","quick setup checklists",{"text":208,"config":209},"Apprentissage",{"href":210,"dataGaLocation":40,"dataGaName":211},"https://university.gitlab.com/","learn",{"text":213,"config":214},"Documentation sur le produit",{"href":215,"dataGaName":216,"dataGaLocation":40},"https://docs.gitlab.com/","product documentation",{"text":218,"config":219},"Vidéos sur les bonnes pratiques",{"href":220,"dataGaName":221,"dataGaLocation":40},"/fr-fr/getting-started-videos/","best practice videos",{"text":223,"config":224},"Intégrations",{"href":225,"dataGaName":226,"dataGaLocation":40},"/fr-fr/integrations/","integrations",{"title":228,"items":229},"Découvrir",[230,235,240],{"text":231,"config":232},"Témoignages clients",{"href":233,"dataGaName":234,"dataGaLocation":40},"/fr-fr/customers/","customer success stories",{"text":236,"config":237},"Blog",{"href":238,"dataGaName":239,"dataGaLocation":40},"/fr-fr/blog/","blog",{"text":241,"config":242},"Travail à distance",{"href":243,"dataGaName":244,"dataGaLocation":40},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":246,"items":247},"Connecter",[248,253,258,263,268],{"text":249,"config":250},"Services GitLab",{"href":251,"dataGaName":252,"dataGaLocation":40},"/fr-fr/services/","services",{"text":254,"config":255},"Communauté",{"href":256,"dataGaName":257,"dataGaLocation":40},"/community/","community",{"text":259,"config":260},"Forum",{"href":261,"dataGaName":262,"dataGaLocation":40},"https://forum.gitlab.com/","forum",{"text":264,"config":265},"Événements",{"href":266,"dataGaName":267,"dataGaLocation":40},"/events/","events",{"text":269,"config":270},"Partenaires",{"href":271,"dataGaName":272,"dataGaLocation":40},"/fr-fr/partners/","partners",{"backgroundColor":274,"textColor":275,"text":276,"image":277,"link":281},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":278,"config":279},"carte promo The Source",{"src":280},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":282,"config":283},"Lire les articles les plus récents",{"href":284,"dataGaName":285,"dataGaLocation":40},"/fr-fr/the-source/","the source",{"text":287,"config":288,"lists":290},"Société",{"dataNavLevelOne":289},"company",[291],{"items":292},[293,298,304,306,311,316,321,326,331,336,341],{"text":294,"config":295},"À propos",{"href":296,"dataGaName":297,"dataGaLocation":40},"/fr-fr/company/","about",{"text":299,"config":300,"footerGa":303},"Carrières",{"href":301,"dataGaName":302,"dataGaLocation":40},"/jobs/","jobs",{"dataGaName":302},{"text":264,"config":305},{"href":266,"dataGaName":267,"dataGaLocation":40},{"text":307,"config":308},"Leadership",{"href":309,"dataGaName":310,"dataGaLocation":40},"/company/team/e-group/","leadership",{"text":312,"config":313},"Équipe",{"href":314,"dataGaName":315,"dataGaLocation":40},"/company/team/","team",{"text":317,"config":318},"Manuel",{"href":319,"dataGaName":320,"dataGaLocation":40},"https://handbook.gitlab.com/","handbook",{"text":322,"config":323},"Relations avec les investisseurs",{"href":324,"dataGaName":325,"dataGaLocation":40},"https://ir.gitlab.com/","investor relations",{"text":327,"config":328},"Centre de confiance",{"href":329,"dataGaName":330,"dataGaLocation":40},"/fr-fr/security/","trust center",{"text":332,"config":333},"Centre pour la transparence de l'IA",{"href":334,"dataGaName":335,"dataGaLocation":40},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":337,"config":338},"Newsletter",{"href":339,"dataGaName":340,"dataGaLocation":40},"/company/contact/#contact-forms","newsletter",{"text":342,"config":343},"Presse",{"href":344,"dataGaName":345,"dataGaLocation":40},"/press/","press",{"text":347,"config":348,"lists":349},"Nous contacter",{"dataNavLevelOne":289},[350],{"items":351},[352,355,360],{"text":47,"config":353},{"href":49,"dataGaName":354,"dataGaLocation":40},"talk to sales",{"text":356,"config":357},"Portail d’assistance",{"href":358,"dataGaName":359,"dataGaLocation":40},"https://support.gitlab.com","support portal",{"text":361,"config":362},"Portail clients GitLab",{"href":363,"dataGaName":364,"dataGaLocation":40},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":366,"login":367,"suggestions":374},"Fermer",{"text":368,"link":369},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":370,"config":371},"gitlab.com",{"href":54,"dataGaName":372,"dataGaLocation":373},"search login","search",{"text":375,"default":376},"Suggestions",[377,379,384,386,391,396],{"text":69,"config":378},{"href":74,"dataGaName":69,"dataGaLocation":373},{"text":380,"config":381},"Suggestions de code (IA)",{"href":382,"dataGaName":383,"dataGaLocation":373},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":23,"config":385},{"href":104,"dataGaName":23,"dataGaLocation":373},{"text":387,"config":388},"GitLab sur AWS",{"href":389,"dataGaName":390,"dataGaLocation":373},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":392,"config":393},"GitLab sur Google Cloud ",{"href":394,"dataGaName":395,"dataGaLocation":373},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":397,"config":398},"Pourquoi utiliser GitLab ?",{"href":82,"dataGaName":399,"dataGaLocation":373},"Why GitLab?",{"freeTrial":401,"mobileIcon":406,"desktopIcon":411,"secondaryButton":414},{"text":402,"config":403},"Commencer votre essai gratuit",{"href":404,"dataGaName":45,"dataGaLocation":405},"https://gitlab.com/-/trials/new/","nav",{"altText":407,"config":408},"Icône GitLab",{"src":409,"dataGaName":410,"dataGaLocation":405},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":407,"config":412},{"src":413,"dataGaName":410,"dataGaLocation":405},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":415,"config":416},"Commencer",{"href":417,"dataGaName":418,"dataGaLocation":405},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr/compare/gitlab-vs-github/","get started",{"freeTrial":420,"mobileIcon":425,"desktopIcon":427},{"text":421,"config":422},"En savoir plus sur GitLab Duo",{"href":423,"dataGaName":424,"dataGaLocation":405},"/fr-fr/gitlab-duo/","gitlab duo",{"altText":407,"config":426},{"src":409,"dataGaName":410,"dataGaLocation":405},{"altText":407,"config":428},{"src":413,"dataGaName":410,"dataGaLocation":405},{"freeTrial":430,"mobileIcon":435,"desktopIcon":437},{"text":431,"config":432},"Retour aux tarifs",{"href":183,"dataGaName":433,"dataGaLocation":405,"icon":434},"back to pricing","GoBack",{"altText":407,"config":436},{"src":409,"dataGaName":410,"dataGaLocation":405},{"altText":407,"config":438},{"src":413,"dataGaName":410,"dataGaLocation":405},{"title":440,"button":441,"config":446},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":442,"config":443},"Regarder GitLab Transcend maintenant",{"href":444,"dataGaName":445,"dataGaLocation":40},"/fr-fr/events/transcend/virtual/","transcend event",{"layout":447,"icon":448},"release","AiStar",{"data":450},{"text":451,"source":452,"edit":458,"contribute":463,"config":468,"items":473,"minimal":650},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":453,"config":454},"Afficher le code source de la page",{"href":455,"dataGaName":456,"dataGaLocation":457},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":459,"config":460},"Modifier cette page",{"href":461,"dataGaName":462,"dataGaLocation":457},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":464,"config":465},"Veuillez contribuer",{"href":466,"dataGaName":467,"dataGaLocation":457},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":469,"facebook":470,"youtube":471,"linkedin":472},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[474,497,551,583,618],{"title":58,"links":475,"subMenu":480},[476],{"text":477,"config":478},"Plateforme DevSecOps",{"href":67,"dataGaName":479,"dataGaLocation":457},"devsecops platform",[481],{"title":181,"links":482},[483,487,492],{"text":484,"config":485},"Voir les forfaits",{"href":183,"dataGaName":486,"dataGaLocation":457},"view plans",{"text":488,"config":489},"Pourquoi choisir GitLab Premium ?",{"href":490,"dataGaName":491,"dataGaLocation":457},"/fr-fr/pricing/premium/","why premium",{"text":493,"config":494},"Pourquoi choisir GitLab Ultimate ?",{"href":495,"dataGaName":496,"dataGaLocation":457},"/fr-fr/pricing/ultimate/","why ultimate",{"title":498,"links":499},"Solutions",[500,505,508,510,515,520,524,527,530,535,537,539,541,546],{"text":501,"config":502},"Transformation digitale",{"href":503,"dataGaName":504,"dataGaLocation":457},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":506,"config":507},"Sécurité et conformité",{"href":122,"dataGaName":129,"dataGaLocation":457},{"text":114,"config":509},{"href":99,"dataGaName":100,"dataGaLocation":457},{"text":511,"config":512},"Développement agile",{"href":513,"dataGaName":514,"dataGaLocation":457},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":516,"config":517},"Transformation cloud",{"href":518,"dataGaName":519,"dataGaLocation":457},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":521,"config":522},"SCM",{"href":111,"dataGaName":523,"dataGaLocation":457},"source code management",{"text":23,"config":525},{"href":104,"dataGaName":526,"dataGaLocation":457},"continuous integration & delivery",{"text":153,"config":528},{"href":155,"dataGaName":529,"dataGaLocation":457},"value stream management",{"text":531,"config":532},"GitOps",{"href":533,"dataGaName":534,"dataGaLocation":457},"/fr-fr/solutions/gitops/","gitops",{"text":166,"config":536},{"href":168,"dataGaName":169,"dataGaLocation":457},{"text":171,"config":538},{"href":173,"dataGaName":174,"dataGaLocation":457},{"text":176,"config":540},{"href":178,"dataGaName":179,"dataGaLocation":457},{"text":542,"config":543},"Formation",{"href":544,"dataGaName":545,"dataGaLocation":457},"/fr-fr/solutions/education/","education",{"text":547,"config":548},"Services financiers",{"href":549,"dataGaName":550,"dataGaLocation":457},"/fr-fr/solutions/finance/","financial services",{"title":186,"links":552},[553,555,558,560,563,565,568,571,573,575,577,579,581],{"text":198,"config":554},{"href":200,"dataGaName":201,"dataGaLocation":457},{"text":556,"config":557},"Guides de démarrage rapide",{"href":205,"dataGaName":206,"dataGaLocation":457},{"text":208,"config":559},{"href":210,"dataGaName":211,"dataGaLocation":457},{"text":213,"config":561},{"href":215,"dataGaName":562,"dataGaLocation":457},"docs",{"text":236,"config":564},{"href":238,"dataGaName":239},{"text":566,"config":567},"Histoires de réussite client",{"href":233,"dataGaLocation":457},{"text":569,"config":570},"Histoires de succès client",{"href":233,"dataGaName":234,"dataGaLocation":457},{"text":241,"config":572},{"href":243,"dataGaName":244,"dataGaLocation":457},{"text":249,"config":574},{"href":251,"dataGaName":252,"dataGaLocation":457},{"text":254,"config":576},{"href":256,"dataGaName":257,"dataGaLocation":457},{"text":259,"config":578},{"href":261,"dataGaName":262,"dataGaLocation":457},{"text":264,"config":580},{"href":266,"dataGaName":267,"dataGaLocation":457},{"text":269,"config":582},{"href":271,"dataGaName":272,"dataGaLocation":457},{"title":287,"links":584},[585,587,590,592,594,596,598,602,607,609,611,613],{"text":294,"config":586},{"href":296,"dataGaName":289,"dataGaLocation":457},{"text":588,"config":589},"Emplois",{"href":301,"dataGaName":302,"dataGaLocation":457},{"text":307,"config":591},{"href":309,"dataGaName":310,"dataGaLocation":457},{"text":312,"config":593},{"href":314,"dataGaName":315,"dataGaLocation":457},{"text":317,"config":595},{"href":319,"dataGaName":320,"dataGaLocation":457},{"text":322,"config":597},{"href":324,"dataGaName":325,"dataGaLocation":457},{"text":599,"config":600},"Sustainability",{"href":601,"dataGaName":599,"dataGaLocation":457},"/sustainability/",{"text":603,"config":604},"Diversité, inclusion et appartenance (DIB)",{"href":605,"dataGaName":606,"dataGaLocation":457},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":327,"config":608},{"href":329,"dataGaName":330,"dataGaLocation":457},{"text":337,"config":610},{"href":339,"dataGaName":340,"dataGaLocation":457},{"text":342,"config":612},{"href":344,"dataGaName":345,"dataGaLocation":457},{"text":614,"config":615},"Déclaration de transparence sur l'esclavage moderne",{"href":616,"dataGaName":617,"dataGaLocation":457},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":347,"links":619},[620,623,628,630,635,640,645],{"text":621,"config":622},"Échanger avec un expert",{"href":49,"dataGaName":50,"dataGaLocation":457},{"text":624,"config":625},"Aide",{"href":626,"dataGaName":627,"dataGaLocation":457},"/support/","get help",{"text":361,"config":629},{"href":363,"dataGaName":364,"dataGaLocation":457},{"text":631,"config":632},"Statut",{"href":633,"dataGaName":634,"dataGaLocation":457},"https://status.gitlab.com/","status",{"text":636,"config":637},"Conditions d'utilisation",{"href":638,"dataGaName":639},"/terms/","terms of use",{"text":641,"config":642},"Déclaration de confidentialité",{"href":643,"dataGaName":644,"dataGaLocation":457},"/fr-fr/privacy/","privacy statement",{"text":646,"config":647},"Préférences en matière de cookies",{"dataGaName":648,"dataGaLocation":457,"id":649,"isOneTrustButton":27},"cookie preferences","ot-sdk-btn",{"items":651},[652,654,657],{"text":636,"config":653},{"href":638,"dataGaName":639,"dataGaLocation":457},{"text":655,"config":656},"Politique de confidentialité",{"href":643,"dataGaName":644,"dataGaLocation":457},{"text":646,"config":658},{"dataGaName":648,"dataGaLocation":457,"id":649,"isOneTrustButton":27},[660],{"id":661,"title":18,"body":8,"config":662,"content":664,"description":8,"extension":25,"meta":668,"navigation":27,"path":669,"seo":670,"stem":671,"__hash__":672},"blogAuthors/en-us/blog/authors/dov-hershkovitch.yml",{"template":663},"BlogAuthor",{"name":18,"config":665},{"headshot":666,"ctfId":667},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665628/Blog/Author%20Headshots/dhershkovitch-headshot.png","dhershkovitch",{},"/en-us/blog/authors/dov-hershkovitch",{},"en-us/blog/authors/dov-hershkovitch","Iz4JuWpp9w9MyL2i-FC6CmJS1rnfmg76IL873W1AcMU",[674,687,702],{"content":675,"config":685},{"title":676,"description":677,"authors":678,"heroImage":680,"body":681,"date":682,"category":9,"tags":683},"Réduction des goulots d'étranglement CI/CD avec GitLab","Découvrez comment les indicateurs de performance des jobs CI/CD et le registre virtuel de conteneurs, actuellement disponible en version bêta, aident les équipes plateforme à identifier rapidement les jobs lents et à simplifier les extractions de conteneurs multi-registres.",[679],"Talia Armato-Helle","https://res.cloudinary.com/about-gitlab-com/image/upload/v1771438388/t6sts5qw4z8561gtlxiq.png","Les ingénieurs plateforme et [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que le DevOps ?\") passent trop de temps à rassembler les informations dispersées entre différents outils fragmentés et à gérer une infrastructure qui devrait simplement fonctionner. \n\nDeux nouvelles fonctionnalités GitLab, disponibles actuellement en version bêta, abordent ce problème sous différents angles mais partagent le même objectif : donner aux praticiens un contrôle direct sur l'infrastructure [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") dont ils dépendent, sans ajouter un nouvel outil tiers. L'une affiche les données de performance au niveau des jobs directement à l'endroit où vous surveillez les pipelines. L'autre simplifie la façon dont vous extrayez les images de conteneurs à partir de plusieurs registres avec une mise en cache intégrée.\n\nCes deux fonctionnalités sont désormais ouvertes aux retours. Vos commentaires nous aideront à façonner les prochaines versions.\n\n## Indicateurs de performance des jobs CI/CD\n\n* **Niveaux disponibles :** GitLab Premium, GitLab Ultimate\n* **Statut :** Version bêta à disponibilité limitée sur GitLab.com ; disponible sur GitLab Self-Managed et GitLab Dedicated lorsque ClickHouse est configuré\n\nÀ l'heure actuelle, il n'existe aucun moyen simple de savoir quand la durée d'un job commence à augmenter ou quels jobs ralentissent l'exécution de votre pipeline. La plupart des équipes construisent des tableaux de bord personnalisés ou examinent manuellement les logs pour répondre à des questions basiques telles que :\n\n* Quels jobs sont les plus lents ?\n* Où les taux d'échec augmentent-ils ?\n* Quelle étape constitue le véritable goulot d'étranglement ?\n\nLes indicateurs de performance des jobs CI/CD changent cela en ajoutant un nouveau panneau axé sur les jobs à la page d'analyse CI/CD au niveau du projet.\n\nPour chaque job, vous pouvez voir :\n\n* La durée typique (P50, médiane) et la durée dans le pire des cas (P95) du job, pour que vous puissiez rapidement comparer les exécutions normales et les exécutions les plus lentes\n* Le taux d'échec, pour que vous puissiez identifier les jobs fragiles ou instables\n* Le nom et l’étape du job, couvrant par défaut les 30 derniers jours\n\nLe tableau est triable, consultable par nom de job et paginé, ce qui permet aux équipes de plateforme d'obtenir une vue unique pour répondre aux questions qui nécessitaient auparavant des outils distincts ou des rapports personnalisés.\n\n**Essayez cette fonctionnalité**\n\n* Accédez à votre projet et sélectionnez **Analyse \\> Données d'analyse CI/CD**.\n* Recherchez le panneau des indicateurs de performance des jobs CI/CD et triez-les par durée ou par taux d'échec pour trouver vos jobs les plus lents ou les moins fiables.\n\n**Documentation**\n\n* [Analyses CI/CD – Indicateurs de performance des jobs CI/CD](https://docs.gitlab.com/user/analytics/ci_cd_analytics/#cicd-job-performance-metrics)\n\n**À venir**\n\nNous travaillons actuellement sur le regroupement par étape pour que vous puissiez consulter les indicateurs agrégés dans vos étapes de build, de test et de déploiement, et comprendre rapidement où concentrer vos efforts d'optimisation.\n\n**Partagez vos retours :**\n\n* [Epic des indicateurs de performance des jobs CI/CD](https://gitlab.com/groups/gitlab-org/-/work_items/18548)\n\n## Registre virtuel de conteneurs\n\n**Niveau :** GitLab Premium, GitLab Ultimate\n**Statut :** Version bêta, compatible API dans la version 18.9\n\nLa plupart des organisations qui intègrent des images de conteneurs dans les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") s'appuient sur plusieurs registres : Docker Hub, Harbor, Quay et les registres internes, pour n'en citer que quelques-uns. Gérer l'authentification, la disponibilité et la mise en cache sur l'ensemble de ces registres représente une charge opérationnelle qui ralentit les pipelines et introduit une certaine fragilité.\n\nLe registre virtuel de conteneurs vous permet de créer un point de terminaison GitLab unique qui extrait des données de plusieurs sources de conteneurs en amont avec une mise en cache intégrée.\n\nAu lieu de configurer les identifiants et la disponibilité pour chaque registre dans votre configuration de pipeline, vous pouvez :\n\n* Diriger vos pipelines vers un point de terminaison de registre virtuel GitLab\n* Configurer plusieurs registres en amont (Docker Hub, Harbor, Quay et autres utilisant l'authentification par jeton à longue durée de vie)\n* Laisser GitLab résoudre automatiquement les extractions d'images, avec une mise en cache pull-through pour réduire les coûts de bande passante et améliorer la fiabilité\n\nPour les équipes qui évaluent GitLab comme remplacement de registre de conteneurs, cela comble une lacune critique en matière de capacités. Pour les équipes qui gèrent déjà des worflows de conteneurs multi-registres, cela centralise la gestion des images dans GitLab et réduit les extractions répétées.\n\n**Ce que la version bêta prend en charge aujourd'hui**\n\n* Registres en amont qui utilisent l'authentification par jeton à longue durée de vie : Docker Hub, Harbor, Quay et autres registres compatibles\n* Mise en cache pull-through pour que les images couramment utilisées soient fournies par GitLab après le premier pull\n* Configuration API-first, avec gestion de l'interface utilisateur en cours++\n\nLes registres de fournisseurs cloud qui nécessitent une authentification IAM (tels que Amazon Elastic Container Registry, Google Artifact Registry et Azure Container Registry) sont à l'étude pour de futures itérations.\n\n**Essayez cette fonctionnalité**\n\n* Le registre virtuel de conteneurs est compatible API dans la version 18.9.\n* SaaS (GitLab.com) : demandez l'accès via votre CSM ou en commentant le ticket ci-dessous pour que le feature flag soit activé pour votre groupe.\n* GitLab Self-managed : activez le feature flag et configurez le registre virtuel à l'aide de l'API.\n\n**Documentation**\n\n* [API du registre virtuel de conteneurs](https://docs.gitlab.com/api/container_virtual_registries/)\n* [Extraire des images de conteneurs à partir du registre virtuel](https://docs.gitlab.com/user/packages/virtual_registry/container/#pull-container-images-from-the-virtual-registry)\n\n\n Regardez cette démonstration du registre virtuel de conteneurs disponible en version bêta :\n   \n\n  \u003Ciframe src=\"https://player.vimeo.com/video/1167512082?title=0&byline=0&portrait=0&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=\"20260223_Container Virtual Registry Beta_V1\">\u003C/iframe>\u003C\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n  \u003Cbr>\u003C/br>\n\n\n\n**Partagez vos retours :**\n\n* [Ticket lié aux retours sur le registre virtuel de conteneurs](https://gitlab.com/gitlab-org/gitlab/-/issues/589630)\n\n## Aidez-nous à construire GitLab\n\nTous les membres de la communauté GitLab sont des contributeurs. Nous avons développé ces versions bêta en fonction des demandes de la communauté.\n\n* **Les indicateurs de performance des jobs CI/CD** ont été proposés par des équipes qui n'avaient aucun moyen facile de voir quand les temps de build commençaient à évoluer dans la mauvaise direction, ou quels jobs nuisaient à la fiabilité du pipeline.\n* **Le registre virtuel de conteneurs** a été proposé par des entreprises clientes qui géraient plusieurs registres et cherchaient à réduire la prolifération d'outils et les coûts de bande passante tout en évaluant GitLab comme registre central.\n\nVos retours façonnent ce que nous créons. Essayez ces versions bêta et partagez votre expérience dans les tickets mentionnés dans cet article.\n\nCet article le premier d'une série de versions bêta Core DevOps que nous prévoyons de mettre en avant. D'autres suivront tout au long de l'année, et nous espérons que vous nous aiderez à les rendre aussi utiles que possible.\n","2026-03-02",[23,9,684],"features",{"featured":27,"template":12,"slug":686},"new-gitlab-metrics-and-registry-features-help-reduce-ci-cd-bottlenecks",{"content":688,"config":700},{"title":689,"description":690,"authors":691,"date":694,"body":695,"heroImage":696,"category":9,"tags":697},"GitLab garantit une disponibilité de 99,9 % avec des crédits de service pour les clients Ultimate","Les clients GitLab Ultimate bénéficient désormais de crédits de service lorsque la disponibilité de la plateforme passe sous le seuil de 99,9 %, garantissant la fiabilité des workflows DevSecOps critiques.",[692,693],"Aathira Nair","Lyle Kozloff","2026-02-18","GitLab garantit désormais son engagement en matière de disponibilité de 99,9 % avec des crédits de service destinés aux clients GitLab Ultimate sur GitLab.com et [GitLab Dedicated](https://about.gitlab.com/dedicated/). Lorsque la disponibilité mensuelle est inférieure à ce seuil, les clients éligibles reçoivent des crédits à appliquer sur leurs prochaines factures. Cet engagement assure à vos workflows DevSecOps la fiabilité dont ils ont besoin.\n\n## Votre confiance, notre priorité\n\nLa livraison logicielle moderne évolue à un rythme soutenu : les équipes effectuent des push de code, ouvrent des merge requests et suivent les tickets en continu tout au long de la journée. Les opérations [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") (push, pull, clone) se produisent des milliers de fois par heure au sein d’équipes distribuées. Lorsque l'une de ces actions essentielles devient indisponible, l'ensemble de votre workflow de livraison de logiciels est impacté.\n\nL'accord de niveau de service (SLA) garantissant une disponibilité de 99,9 % vous assure que votre rythme de développement accéléré ne se heurte pas à des obstacles liés à l’infrastructure. Les crédits de service témoignent de notre responsabilité. Ils lient notre réussite à la fiabilité de la plateforme et alignent nos intérêts sur les vôtres. Nous nous tenons responsables de vos résultats commerciaux, et pas seulement des objectifs de disponibilité.\n\nL'engagement SLA de GitLab couvre les services de base de la plateforme essentiels à vos workflows DevSecOps.\n\nAu lancement, les expériences couvertes sont les suivantes :\n\n* Tickets et merge requests\n* Opérations Git (push, pull, clone via HTTPS et SSH)\n* Opérations du registre de conteneurs\n* Opérations du registre de paquets\n* Requêtes API (limitées aux éléments ci-dessus)\n\nLa liste actualisée des expériences couvertes et exclues est disponible dans le [manuel de GitLab](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/service-level-agreement/#covered-experiences).\n\nLa disponibilité du service est mesurée à l'aide d'une surveillance automatisée couvrant plusieurs zones géographiques, offrant une représentation précise de la disponibilité réelle du service telle qu’elle est expérimentée par les clients. Lorsque la disponibilité passe sous le seuil de 99,9 %, les clients sont éligibles à des crédits proportionnels à la durée et à la sévérité de l’indisponibilité.\n\n## Comprendre les minutes d'indisponibilité\n\nLorsque le service de GitLab enregistre une disponibilité dégradée affectant 5 % ou plus des requêtes clients valides pour les expériences couvertes au cours d'une minute donnée, entraînant des erreurs serveur, cette période est appelée une [minute d'indisponibilité](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/service-level-agreement/#downtime-minute-definition). Les erreurs serveur sont définies comme des codes de statut HTTP 5xx ou des délais d'expiration de connexion dépassant 30 secondes, tels que déterminés par les systèmes de surveillance internes et externes de GitLab.\n\nLe SLA mesure les défaillances côté serveur, mais certains problèmes peuvent ne pas générer d'erreurs 5xx, comme les bogues applicatifs qui rendent des fonctionnalités inutilisables, les interruptions du traitement des jobs Sidekiq ou les problèmes d'infrastructure qui dégradent les performances sans provoquer des échecs de requêtes.\n\nVoici comment réclamer des crédits de service lorsque les conditions requises sont remplies :\n\n1. Soumettez une demande d'assistance sur support.gitlab.com dans les trente (30) jours suivant la fin du mois affecté.\n\n2. L'équipe de GitLab examine la demande, valide l'indisponibilité et traite le crédit le cas échéant.\n\n3. Les crédits de service seront appliqués sur votre prochaine facture émise.\n\n[Consultez notre manuel](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/service-level-agreement/#calculating-monthly-uptime-percentage) pour en savoir plus sur le calcul de la disponibilité mensuelle, les crédits de service offerts le cas échéant et les procédures de réclamation de crédits.\n\nBien que notre système de surveillance soit conçu pour détecter la grande majorité des interruptions de service, si votre expérience ne correspond pas à la disponibilité rapportée, nous vous encourageons à soumettre une demande de crédit de service. GitLab examinera la demande dans sa globalité, y compris les problèmes susceptibles de ne pas être reflétés dans la surveillance automatisée.\n\n## Une fiabilité sur laquelle vous pouvez compter\n\nLe SLA à 99,9 % assorti de crédits de service traduit notre engagement à être une base fiable pour vos workflows de livraison logicielle. Vos équipes comptent sur GitLab pour continuer à livrer des logiciels, et nous sommes là pour vous soutenir.\n\nDes questions sur le SLA ? Contactez votre chargé de compte GitLab ou soumettez une demande via le [support de GitLab](http://support.GitLab.com).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1758812952/yxhgljkwljld0lyizmaz.png",[698,9,699],"performance","DevSecOps",{"featured":27,"template":12,"slug":701},"gitlab-backs-99-9-availability-with-service-credits-for-ultimate-customers",{"content":703,"config":714},{"title":704,"description":705,"authors":706,"heroImage":708,"date":709,"body":710,"category":9,"tags":711},"GitLab Credits : la tarification à l'usage pour GitLab Duo Agent Platform","Découvrez comment GitLab Credits permet de réduire les coûts et offre une flexibilité relative à l'utilisation de l'IA agentique dans le cycle de développement logiciel en entreprise.",[707],"Manav Khurana","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1768314648/gvy4pfqjaeahkoagsjmr.png","2026-01-15","Nous avons créé GitLab Credits car la tarification par siège n’avait pas de sens pour l'IA agentique.\n\nLa tarification par siège crée une fracture entre les équipes d'ingénierie qui ont accès à l'IA et celles qui n'y ont pas accès, ce qui est en totale contradiction avec la manière dont l'IA agentique moderne devrait être utilisée tout au long du cycle de développement logiciel. \n\nAujourd'hui, vous devez acheter un siège pour chaque personne avant qu'elle ne puisse commencer à utiliser l'IA. Bien que cette tarification fonctionne pour les quelques utilisateurs intensifs, elle peut s'avérer trop coûteuse et injuste pour la majorité de l'équipe dont l'utilisation est ponctuelle. C'est pourquoi dans de nombreuses organisations, seule une partie de l'équipe dispose d'un « siège IA ».\n\nPar ailleurs, [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/blog/gitlab-duo-agent-platform-is-generally-available/) diffère de GitLab Duo Pro, de GitLab Duo Enterprise et des autres outils de développement d'IA sur le marché. Les agents et les flows agentiques peuvent être utilisés par votre équipe lorsque celle-ci a besoin d'une assistance IA et déclenchés par des événements [SDLC](https://about.gitlab.com/fr-fr/blog/what-is-sdlc/) qui s'exécutent en arrière-plan. Avec GitLab Duo Agent Platform, l'IA agentique n'est plus uniquement liée aux sièges utilisateurs.\n\nGitLab Credits, notre nouvelle monnaie virtuelle pour la tarification à l'usage, permet de pallier ces différences d'utilisation, à commencer par GitLab Duo Agent Platform. Chaque membre de votre organisation avec un compte GitLab (Premium ou Ultimate) peut désormais utiliser les fonctionnalités d'IA agentique sans que vous ayez à payer pour un siège IA, que celles-ci soient utilisées directement ou configurées comme agents en arrière-plan. \n\n## Fonctionnement de GitLab Credits\n\nLes crédits sont mutualisés dans l'ensemble de votre organisation. GitLab Duo Agent Platform, y compris l'usage synchrone et asynchrone des agents et des flows agentiques, requiert des GitLab Credits.\n\nLes fonctionnalités suivantes consomment des GitLab Credits :\n\n* Les [agents de base](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/) tels que l'agent GitLab Duo Security Analyst,  l'agent GitLab Duo Planner et l'agent GitLab Duo Data Analyst  \n\n* Les [flows de base](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/) tels que le flow « revue de code », le flow flow « développeur » et le flow « correction de pipelines CI/CD »  \n\n* Les [agents externes](https://docs.gitlab.com/user/duo_agent_platform/agents/external/) tels qu'Anthropic Claude Code et OpenAI Codex  \n\n* Les agents et les flows personnalisés que vous créez et publiez dans votre [Catalogue d'IA](https://docs.gitlab.com/user/duo_agent_platform/ai_catalog/)  \n\n* [Agentic Chat](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/) dans l'interface de GitLab et dans l'[IDE](https://about.gitlab.com/fr-fr/blog/what-is-an-ide/).\n\n**Remarque :** les agents externes sont disponibles gratuitement dans la version 18.8 et ne consomment pas de GitLab Credits. Nous présenterons la tarification le mois prochain, lors de la sortie de la version GitLab 18.9. Les flow personnalisés sont actuellement en version bêta et ne consomment pas de GitLab Credits. \n\nLe nombre de crédits utilisés est basé sur le nombre de requêtes agentiques effectuées par les grands modèles de langage ([LLM](https://about.gitlab.com/fr-fr/blog/what-is-a-large-language-model-llm/)) (plus de détails [ici](https://docs.gitlab.com/subscriptions/gitlab_credits/#models)). À mesure que le nombre de LLM disponibles augmentera, nous les certifierons pour une utilisation avec GitLab Duo Agent Platform et les ajouterons à cette liste afin d'offrir aux utilisateurs une vision transparente de leur consommation.\n\nLe nombre total de crédits est calculé à la fin du mois en fonction de l'utilisation réelle. Ce modèle compense également automatiquement l'usage des utilisateurs intensifs par rapport à celui des utilisateurs occasionnels, afin de réduire ainsi efficacement le coût total de l'IA par personne (par rapport au paiement par siège pour chaque personne). \n\nPar souci de simplicité, chaque crédit a un prix catalogue **à la demande** de 1 $. Vous pouvez utiliser GitLab Duo Agent Platform sans aucun engagement, et l'utilisation est facturée mensuellement (à la fin de chaque mois). Pour les clients Enterprise qui souscrivent à des **engagements annuels**, nous proposons des remises sur volume pour les crédits mensuels. \n\nDans le cadre d'une promotion à durée limitée[*](#notes), tous les clients GitLab avec un abonnement GitLab Premium et GitLab Ultimate actif recevront automatiquement **12 $ et 24 $ de crédits inclus par utilisateur**, respectivement. Ces crédits seront renouvelés chaque mois jusqu'à la fin de la période promotionnelle et permettront à votre équipe d'accéder à toutes les fonctionnalités de GitLab Duo Agent Platform sans frais supplémentaires. Lorsque vous acceptez nos conditions de facturation, toute utilisation supérieure à ces crédits inclus sera facturée via des crédits mensuels engagés ou des crédits à la demande.\n\n## Gouvernance des coûts avec GitLab Credits\n\n**Dimensionnement de GitLab Credits :** votre équipe commerciale dispose d'un calculateur de dimensionnement dans le cadre de la disponibilité générale de GitLab Duo Agent Platform, pour estimer le nombre de crédits dont vous aurez besoin chaque mois. Ce calculateur a été conçu avec des modèles d'utilisation que nous avons observés pendant la période bêta. De plus, en tant que client existant ou nouveau client, vous pouvez demander un essai gratuit pour confirmer votre utilisation réelle estimée. \n\n**Visibilité de l'utilisation :** avec la version 18.8, vous disposez d'informations détaillées sur l'utilisation via deux tableaux de bord complémentaires : un disponible dans le portail clients de GitLab pour les responsables de facturation à des fins de supervision financière, et l'autre intégré au produit pour les administrateurs à des fins de surveillance opérationnelle. Les deux fournissent une attribution de l'utilisation, des répartitions de coûts et des tendances historiques afin que vous sachiez toujours exactement comment vos crédits sont consommés. Si vous suivez une pratique de refacturation interne, vous pourrez utiliser les cumuls au niveau des projets et des groupes pour les allocations de coûts.  \n\n**Contrôles d'utilisation :** vous pouvez activer ou désactiver l'accès à GitLab Duo Agent Platform pour des équipes ou des projets spécifiques afin de garantir que seule l'utilisation approuvée peut être comptabilisée dans vos crédits. Nous prévoyons également d'ajouter des contrôles au niveau utilisateur peu après la disponibilité générale pour vous aider à gérer l'usage des fonctionnalités de GitLab Duo Agent Platform et des crédits.\n\n**Notifications automatiques d'utilisation :** nous vous tiendrons informé de manière proactive de votre utilisation des crédits via des alertes par e-mail lorsque vous atteindrez 50 %, 80 % et 100 % de vos crédits mensuels engagés, afin que vous ayez le temps d'ajuster votre utilisation, d'acheter des engagements supplémentaires ou de planifier la facturation à la demande.\n\n## Mise à niveau de la tarification par siège GitLab Duo Pro/GitLab Enterprise vers GitLab Credits pour GitLab Duo Agent Platform\n\nSi vous avez acheté et utilisez GitLab Duo Pro et GitLab Duo Enterprise, vous pouvez continuer à utiliser ces fonctionnalités comme options prises en charge. Vous pouvez passer à tout moment à GitLab Duo Agent Platform, afin d'utiliser la version « classique » de GitLab Duo, et accéder à de nouvelles fonctionnalités telles que l'Agentic Chat, des agents de base supplémentaires, des agents et des flows personnalisés, des agents externes et plus encore. \n\nAu moment de la mise à niveau, nous transférerons votre investissement dans les sièges de GitLab Duo Pro et GitLab Duo Enterprise vers GitLab Credits pour GitLab Duo Agent Platform. Le montant restant des engagements de sièges sera échangé contre des GitLab Credits mensuels avec des remises basées sur le volume. Les crédits mensuels pourront ensuite être partagés entre tous les membres de votre organisation que vous autorisez, et non plus seulement les utilisateurs qui disposaient de sièges GitLab Duo assignés auparavant. \n\n## Comparaison concurrentielle : GitLab Credits vs tarification par siège \n\n| Avantage | GitLab Credits | Tarification par siège |\n| ----- | ----- | ----- |\n| **L'IA pour tous** | Chaque membre d'équipe approuvé dispose d'un accès IA dès le premier jour | Crée des « nantis » et des « non-nantis » de l'IA, impose un rationnement des sièges |\n| **Aucun investissement initial**  | Commencez modestement avec les crédits inclus, augmentez l'engagement au fur et à mesure que le ROI devient clair | Vous devez acheter des sièges à l'avance avant de prouver leur valeur |\n| **Payez ce que vous utilisez** | Seul le travail d'IA réellement effectué au-delà du niveau inclus est facturé | Vous payez par siège quelle que soit l'utilisation réelle |\n| **Dépenses optimisées** | Le pool de crédits partagé vous permet d'équilibrer les utilisateurs intensifs avec les utilisateurs occasionnels | Vous devez payer pour les utilisateurs occasionnels et les dépassements pour les requêtes premium des utilisateurs intensifs |\n| **Visibilité détaillée** | Tableaux de bord d'utilisation avec attribution détaillée et tendances historiques | Aperçu limité des utilisateurs qui génèrent de la valeur |\n| **Contrôles de coûts granulaires** | Déterminez les utilisateurs, des alertes proactives et des contrôles budgétaires à venir pour limiter l'usage | Limitez qui obtient un siège pour contrôler les coûts |\n| **Flexibilité de dimensionnement**  | Calculateur pour estimer les crédits mensuels, avec plus de remises unitaires en volume | Comptez qui obtient un siège multiplié par le prix par siège |\n| **Contrats et facturation simplifiés** | Un seul SKU et une facture couvre toutes les fonctionnalités agentiques dans le cycle de vie DevSecOps | Plusieurs licences IA requises pour différents outils tiers |\n\n## Configuration\n\n1. **Pour les clients GitLab Premium et GitLab Ultimate existants** : avec la disponibilité générale, GitLab Duo Agent Platform sera disponible pour les clients disposant de licences GitLab Premium et GitLab Ultimate actives[**](#notes). Les clients GitLab.com SaaS y auront accès automatiquement. Les clients GitLab Self-Managed y auront accès lorsqu'ils passeront à la version GitLab 18.8 (avec la disponibilité générale prévue de GitLab Duo Agent Platform). Les clients [GitLab Dedicated](https://about.gitlab.com/fr-fr/dedicated/) seront mis à niveau vers GitLab 18.8 pendant leur fenêtre de maintenance programmée en février et pourront alors utiliser GitLab Duo Agent Platform.\n      \n2. **Activez GitLab Duo** : assurez-vous que GitLab Duo Agent Platform est activé dans les paramètres de votre espace de nommage.  \n\n3. **Commencez à explorer** : utilisez vos GitLab Credits mensuels inclus pour essayer les fonctionnalités de GitLab Duo Agent Platform.   \n\n4. **Au-delà des crédits inclus :** vous pourrez accepter GitLab Credits pour une utilisation étendue au-delà des crédits inclus au prix catalogue à la demande. Pour des remises sur volume avec engagement, veuillez [nous contacter](https://about.gitlab.com/fr-fr/sales/) pour obtenir un devis pour votre niveau d'utilisation spécifique. \n\nConsultez notre [documentation](https://docs.gitlab.com/user/duo_agent_platform/) pour en savoir plus sur la prise en main de GitLab Duo Agent Platform.\n\n## Remarques\n\n\\* Ces crédits promotionnels inclus sont disponibles pour une durée limitée lors de la disponibilité générale, et peuvent être modifiés à la discrétion de GitLab.\n\n** Exclut GitLab Duo avec Amazon Q et GitLab Dedicated pour les clients \ngouvernementaux.\n\n> Pour en savoir plus sur GitLab Duo Agent Platform et toutes les façons dont l'IA agentique peut transformer le travail de votre équipe, [consultez notre page GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/). Si vous êtes un client GitLab existant, contactez votre gestionnaire de compte GitLab ou votre partenaire pour planifier une démonstration de nos fonctionnalités de plateforme.\n\n## FAQ sur GitLab Credits\n\n**1\\. Qu'est-ce que GitLab Credits et pourquoi GitLab les a-t-il introduits ?**\n\nGitLab Credits est une nouvelle monnaie virtuelle pour les fonctionnalités GitLab basées sur l'utilisation, à commencer par GitLab Duo Agent Platform. GitLab a introduit ce modèle car la tarification par siège forçait les organisations à rationner l'accès à l'IA au sein des équipes d'ingénierie, et l'utilisation de GitLab Duo Agent Platform n'est pas uniquement liée aux sièges. Les crédits sont mutualisés dans l'ensemble de votre organisation, vous permettant de donner à chaque membre de l'équipe un accès aux fonctionnalités d'IA, ou de configurer des workflows agentiques en arrière-plan, sans nécessiter l'achat de sièges individuels à l'avance.\n\n**2\\. Comment fonctionne la consommation de crédits ?**\n\nLes crédits sont déduits en fonction du nombre de requêtes agentiques effectuées, avec des taux différents selon le LLM utilisé. Par exemple, vous obtenez deux requêtes de modèle par crédit pour Claude-sonnet-4.5 (le modèle par défaut pour la plupart des fonctionnalités), et 20 requêtes par crédit pour des modèles comme gpt-5-mini ou claude-3-haiku. \n\n**3\\. Qu'est-ce qui est inclus pour les clients GitLab Premium et GitLab Ultimate existants ?**\n\nDans le cadre d'une promotion à durée limitée, les clients disposant d'abonnements GitLab Premium et GitLab Ultimate actifs reçoivent automatiquement des crédits inclus gratuitement parallèlement à la version de disponibilité générale de GitLab Duo Agent Platform dans GitLab 18.8 : \n\n* 12 $ de crédits par utilisateur par mois pour GitLab Premium  \n\n* 24 $ de crédits par utilisateur par mois pour GitLab Ultimate\n\nLes crédits inclus sont au niveau utilisateur, se renouvellent mensuellement et permettent l'accès à toutes les fonctionnalités de GitLab Duo Agent Platform sans frais supplémentaires. Toute utilisation supplémentaire sera facturée séparément. Ces crédits promotionnels inclus sont disponibles pour une durée limitée après la disponibilité générale, et peuvent être modifiés  à la discrétion de GitLab.\n\n**4\\. Comment puis-je contrôler et surveiller l'utilisation des crédits ?**\n\nGitLab fournit plusieurs outils de gouvernance : tableaux de bord d'utilisation détaillés dans le portail clients et au sein du produit, possibilité d'activer et de désactiver l'accès pour des équipes ou des projets spécifiques, contrôles au niveau utilisateur à venir, et alertes e-mail automatisées à 50 %, 80 % et 100 % des crédits mensuels engagés. Nous prévoyons également de proposer un calculateur de dimensionnement pour estimer vos besoins mensuels en crédits.\n\n**5\\. Comment puis-je commencer à utiliser GitLab Duo Agent Platform ?**\n\nUne fois en disponibilité générale, pour les clients GitLab Premium et GitLab Ultimate existants, l'accès est automatique sur GitLab.com SaaS. Les clients Self-Managed obtiennent l'accès lors de la mise à niveau vers GitLab 18.8 avec la disponibilité générale prévue de GitLab Duo Agent Platform. Activez simplement GitLab Duo Agent Platform dans les paramètres de votre espace de nommage et commencez à explorer GitLab Duo Agent Platform en utilisant vos crédits mensuels inclus. Pour une utilisation au-delà des crédits inclus, vous pouvez accepter la facturation à la demande ou contacter GitLab pour des remises sur volume avec engagements annuels.\n\n*Cet article de blog contient des « déclarations prospectives » au sens de la section 27A du Securities Act de 1933, tel que modifié, et de la section 21E du Securities Exchange Act de 1934. Bien que nous croyions que les attentes reflétées dans ces déclarations sont raisonnables, elles sont soumises à des risques, incertitudes, hypothèses et autres facteurs connus et inconnus qui peuvent entraîner des résultats ou des issues réels sensiblement différents. Des informations supplémentaires sur ces risques et autres facteurs sont incluses sous la rubrique « Facteurs de risque » dans nos dépôts auprès de la SEC. Nous ne nous engageons à mettre à jour ou à réviser ces déclarations après la date de cet article de blog, sauf si la loi l'exige.*",[712,9,713],"AI/ML","news",{"featured":11,"template":12,"slug":715},"introducing-gitlab-credits",{"promotions":717},[718,732,744],{"id":719,"categories":720,"header":722,"text":723,"button":724,"image":729},"ai-modernization",[721],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":725,"config":726},"Get your AI maturity score",{"href":727,"dataGaName":728,"dataGaLocation":239},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":730},{"src":731},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":733,"categories":734,"header":736,"text":723,"button":737,"image":741},"devops-modernization",[9,735],"devsecops","Are you just managing tools or shipping innovation?",{"text":738,"config":739},"Get your DevOps maturity score",{"href":740,"dataGaName":728,"dataGaLocation":239},"/assessments/devops-modernization-assessment/",{"config":742},{"src":743},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":745,"categories":746,"header":748,"text":723,"button":749,"image":753},"security-modernization",[747],"security","Are you trading speed for security?",{"text":750,"config":751},"Get your security maturity score",{"href":752,"dataGaName":728,"dataGaLocation":239},"/assessments/security-modernization-assessment/",{"config":754},{"src":755},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":757,"blurb":758,"button":759,"secondaryButton":763},"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":42,"config":760},{"href":761,"dataGaName":45,"dataGaLocation":762},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/fr-fr/","feature",{"text":47,"config":764},{"href":49,"dataGaName":50,"dataGaLocation":762},1772652100376]