[{"data":1,"prerenderedAt":760},["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":438,"footer-fr-fr":448,"blog-post-authors-fr-fr-Dov Hershkovitch":658,"blog-related-posts-fr-fr-ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline":672,"assessment-promotions-fr-fr":711,"next-steps-fr-fr":751},{"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":428},{"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/get-started/","get started",{"freeTrial":420,"mobileIcon":424,"desktopIcon":426},{"text":421,"config":422},"En savoir plus sur GitLab Duo",{"href":74,"dataGaName":423,"dataGaLocation":405},"gitlab duo",{"altText":407,"config":425},{"src":409,"dataGaName":410,"dataGaLocation":405},{"altText":407,"config":427},{"src":413,"dataGaName":410,"dataGaLocation":405},{"freeTrial":429,"mobileIcon":434,"desktopIcon":436},{"text":430,"config":431},"Retour aux tarifs",{"href":183,"dataGaName":432,"dataGaLocation":405,"icon":433},"back to pricing","GoBack",{"altText":407,"config":435},{"src":409,"dataGaName":410,"dataGaLocation":405},{"altText":407,"config":437},{"src":413,"dataGaName":410,"dataGaLocation":405},{"title":439,"button":440,"config":445},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":441,"config":442},"Regarder GitLab Transcend maintenant",{"href":443,"dataGaName":444,"dataGaLocation":40},"/fr-fr/events/transcend/virtual/","transcend event",{"layout":446,"icon":447,"disabled":27},"release","AiStar",{"data":449},{"text":450,"source":451,"edit":457,"contribute":462,"config":467,"items":472,"minimal":649},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":452,"config":453},"Afficher le code source de la page",{"href":454,"dataGaName":455,"dataGaLocation":456},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":458,"config":459},"Modifier cette page",{"href":460,"dataGaName":461,"dataGaLocation":456},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":463,"config":464},"Veuillez contribuer",{"href":465,"dataGaName":466,"dataGaLocation":456},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":468,"facebook":469,"youtube":470,"linkedin":471},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[473,496,550,582,617],{"title":58,"links":474,"subMenu":479},[475],{"text":476,"config":477},"Plateforme DevSecOps",{"href":67,"dataGaName":478,"dataGaLocation":456},"devsecops platform",[480],{"title":181,"links":481},[482,486,491],{"text":483,"config":484},"Voir les forfaits",{"href":183,"dataGaName":485,"dataGaLocation":456},"view plans",{"text":487,"config":488},"Pourquoi choisir GitLab Premium ?",{"href":489,"dataGaName":490,"dataGaLocation":456},"/fr-fr/pricing/premium/","why premium",{"text":492,"config":493},"Pourquoi choisir GitLab Ultimate ?",{"href":494,"dataGaName":495,"dataGaLocation":456},"/fr-fr/pricing/ultimate/","why ultimate",{"title":497,"links":498},"Solutions",[499,504,507,509,514,519,523,526,529,534,536,538,540,545],{"text":500,"config":501},"Transformation digitale",{"href":502,"dataGaName":503,"dataGaLocation":456},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":505,"config":506},"Sécurité et conformité",{"href":122,"dataGaName":129,"dataGaLocation":456},{"text":114,"config":508},{"href":99,"dataGaName":100,"dataGaLocation":456},{"text":510,"config":511},"Développement agile",{"href":512,"dataGaName":513,"dataGaLocation":456},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":515,"config":516},"Transformation cloud",{"href":517,"dataGaName":518,"dataGaLocation":456},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":520,"config":521},"SCM",{"href":111,"dataGaName":522,"dataGaLocation":456},"source code management",{"text":23,"config":524},{"href":104,"dataGaName":525,"dataGaLocation":456},"continuous integration & delivery",{"text":153,"config":527},{"href":155,"dataGaName":528,"dataGaLocation":456},"value stream management",{"text":530,"config":531},"GitOps",{"href":532,"dataGaName":533,"dataGaLocation":456},"/fr-fr/solutions/gitops/","gitops",{"text":166,"config":535},{"href":168,"dataGaName":169,"dataGaLocation":456},{"text":171,"config":537},{"href":173,"dataGaName":174,"dataGaLocation":456},{"text":176,"config":539},{"href":178,"dataGaName":179,"dataGaLocation":456},{"text":541,"config":542},"Formation",{"href":543,"dataGaName":544,"dataGaLocation":456},"/fr-fr/solutions/education/","education",{"text":546,"config":547},"Services financiers",{"href":548,"dataGaName":549,"dataGaLocation":456},"/fr-fr/solutions/finance/","financial services",{"title":186,"links":551},[552,554,557,559,562,564,567,570,572,574,576,578,580],{"text":198,"config":553},{"href":200,"dataGaName":201,"dataGaLocation":456},{"text":555,"config":556},"Guides de démarrage rapide",{"href":205,"dataGaName":206,"dataGaLocation":456},{"text":208,"config":558},{"href":210,"dataGaName":211,"dataGaLocation":456},{"text":213,"config":560},{"href":215,"dataGaName":561,"dataGaLocation":456},"docs",{"text":236,"config":563},{"href":238,"dataGaName":239},{"text":565,"config":566},"Histoires de réussite client",{"href":233,"dataGaLocation":456},{"text":568,"config":569},"Histoires de succès client",{"href":233,"dataGaName":234,"dataGaLocation":456},{"text":241,"config":571},{"href":243,"dataGaName":244,"dataGaLocation":456},{"text":249,"config":573},{"href":251,"dataGaName":252,"dataGaLocation":456},{"text":254,"config":575},{"href":256,"dataGaName":257,"dataGaLocation":456},{"text":259,"config":577},{"href":261,"dataGaName":262,"dataGaLocation":456},{"text":264,"config":579},{"href":266,"dataGaName":267,"dataGaLocation":456},{"text":269,"config":581},{"href":271,"dataGaName":272,"dataGaLocation":456},{"title":287,"links":583},[584,586,589,591,593,595,597,601,606,608,610,612],{"text":294,"config":585},{"href":296,"dataGaName":289,"dataGaLocation":456},{"text":587,"config":588},"Emplois",{"href":301,"dataGaName":302,"dataGaLocation":456},{"text":307,"config":590},{"href":309,"dataGaName":310,"dataGaLocation":456},{"text":312,"config":592},{"href":314,"dataGaName":315,"dataGaLocation":456},{"text":317,"config":594},{"href":319,"dataGaName":320,"dataGaLocation":456},{"text":322,"config":596},{"href":324,"dataGaName":325,"dataGaLocation":456},{"text":598,"config":599},"Sustainability",{"href":600,"dataGaName":598,"dataGaLocation":456},"/sustainability/",{"text":602,"config":603},"Diversité, inclusion et appartenance (DIB)",{"href":604,"dataGaName":605,"dataGaLocation":456},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":327,"config":607},{"href":329,"dataGaName":330,"dataGaLocation":456},{"text":337,"config":609},{"href":339,"dataGaName":340,"dataGaLocation":456},{"text":342,"config":611},{"href":344,"dataGaName":345,"dataGaLocation":456},{"text":613,"config":614},"Déclaration de transparence sur l'esclavage moderne",{"href":615,"dataGaName":616,"dataGaLocation":456},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":347,"links":618},[619,622,627,629,634,639,644],{"text":620,"config":621},"Échanger avec un expert",{"href":49,"dataGaName":50,"dataGaLocation":456},{"text":623,"config":624},"Aide",{"href":625,"dataGaName":626,"dataGaLocation":456},"https://support.gitlab.com/hc/en-us/articles/11626483177756-GitLab-Support","get help",{"text":361,"config":628},{"href":363,"dataGaName":364,"dataGaLocation":456},{"text":630,"config":631},"Statut",{"href":632,"dataGaName":633,"dataGaLocation":456},"https://status.gitlab.com/","status",{"text":635,"config":636},"Conditions d'utilisation",{"href":637,"dataGaName":638},"/terms/","terms of use",{"text":640,"config":641},"Déclaration de confidentialité",{"href":642,"dataGaName":643,"dataGaLocation":456},"/fr-fr/privacy/","privacy statement",{"text":645,"config":646},"Préférences en matière de cookies",{"dataGaName":647,"dataGaLocation":456,"id":648,"isOneTrustButton":27},"cookie preferences","ot-sdk-btn",{"items":650},[651,653,656],{"text":635,"config":652},{"href":637,"dataGaName":638,"dataGaLocation":456},{"text":654,"config":655},"Politique de confidentialité",{"href":642,"dataGaName":643,"dataGaLocation":456},{"text":645,"config":657},{"dataGaName":647,"dataGaLocation":456,"id":648,"isOneTrustButton":27},[659],{"id":660,"title":18,"body":8,"config":661,"content":663,"description":8,"extension":25,"meta":667,"navigation":27,"path":668,"seo":669,"stem":670,"__hash__":671},"blogAuthors/en-us/blog/authors/dov-hershkovitch.yml",{"template":662},"BlogAuthor",{"name":18,"config":664},{"headshot":665,"ctfId":666},"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",[673,687,700],{"content":674,"config":685},{"title":675,"description":676,"authors":677,"heroImage":679,"date":680,"body":681,"category":9,"tags":682},"GitLab Duo CLI : l'IA agentique au service du développement, désormais dans le terminal","Les équipes de développement qui travaillent en dehors de l'IDE et de l'interface utilisateur de GitLab peuvent désormais accéder à GitLab Duo Agent Platform directement depuis le terminal, avec des contrôles de sécurité intégrés et la prise en charge du mode headless.",[678],"John Coghlan","https://res.cloudinary.com/about-gitlab-com/image/upload/v1775561395/bhe1as7ttjvzltxwgo5m.png","2026-04-07","Déboguer un pipeline en échec en fin de sprint ou intégrer l'IA dans un workflow [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") qui s'exécute sans intervention humaine : voilà exactement les situations où les assistants d'IA actuels montrent leurs limites, car ils se concentrent sur le code, qui ne représente qu'une partie du cycle de vie logiciel. Ces assistants sont conçus pour des sessions de codage interactives, et non pour l'automatisation des différentes étapes du développement logiciel. GitLab Duo CLI, désormais disponible en version bêta publique, a été pensé pour répondre à ces deux cas d'usages.\n\nGitLab Duo CLI intègre l'IA agentique propulsée par [GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/) directement dans le terminal, avec une prise en charge complète des workflows automatisés et un mode de chat interactif lorsqu'un contrôle humain est nécessaire. Découvrez les fonctionnalités de GitLab Duo CLI, le fonctionnement de ses deux modes d'utilisation et le modèle de sécurité sur lequel il s'appuie.\n\n## Comment installer GitLab Duo CLI\n\nSi vous avez déjà installé Glab (GitLab CLI), saisissez :\n\n```\nglab duo cli\n```\n\nSuivez ensuite les instructions.\n\nSi Glab n'est pas encore installé, vous pouvez l'installer en accédant à [cette page](https://gitlab.com/gitlab-org/cli/#installation) ou [utiliser GitLab Duo CLI en tant qu'outil autonome](https://docs.gitlab.com/user/gitlab_duo_cli/#without-the-gitlab-cli).\n\n## Pourquoi le terminal, et pourquoi maintenant\n\nLa première génération d'assistants d'IA pour le développement logiciel était intégrée à l'[IDE](https://about.gitlab.com/fr-fr/blog/what-is-an-ide/ \"Qu'est-ce qu'un IDE ?\") et se concentrait exclusivement sur le code. Cette approche était logique lorsque l'objectif se limitait à l'autocomplétion. Mais à mesure que les agents d'IA commencent à *agir* à chaque étape du cycle de vie logiciel (exécution de tests, déclenchement de pipelines, surveillance des scans de sécurité, etc.), l'IDE n'est plus nécessairement la seule interface adaptée.\n\nLes meilleurs outils de développement sont ceux qui fonctionnent aussi bien pour les équipes que pour les machines. Les CLI bénéficient de plusieurs décennies d'itérations de conception dans cette optique. Elles sont composables : vous pouvez rediriger les données de sortie, enchaîner les commandes et les intégrer dans des scripts. Elles facilitent le débogage : en cas de problème, il suffit d'exécuter la même commande pour voir exactement ce que l'agent a vu. Elles sont aussi transparentes : aucun processus en arrière-plan, aucune procédure d'initialisation complexe, aucun protocole à décoder en cas de dysfonctionnement.\n\nLes interfaces de terminal sont mieux adaptées à l'automatisation, aux scripts et à la portabilité entre environnements. Les interfaces des IDE sont plus adaptées au développement interactif et riche en contexte. GitLab Duo CLI est conçu pour le premier cas de figure, tandis que GitLab Duo Agentic Chat dans l'IDE et l'interface couvre le second.\n\n## Ce que GitLab Duo CLI permet de faire\n\nAvec GitLab Duo CLI, les équipes de développement peuvent créer, modifier, refactoriser et moderniser du code, à l'instar d'autres assistants de codage basés sur l'IA et conçus pour le terminal. Mais les possibilités ne s'arrêtent pas là. Tout agent et tout flow défini dans GitLab Duo Agent Platform est accessible via GitLab Duo CLI, qu'il s'agisse d'automatiser la configuration CI/CD et d'optimiser les pipelines ou d'effectuer des tâches de développement en plusieurs étapes de manière autonome sur l'ensemble du cycle de développement logiciel ([SDLC](https://about.gitlab.com/fr-fr/blog/what-is-sdlc/ \"Qu'est-ce que le SDLC ?\")).\n\nGitLab Duo CLI fonctionne selon deux modes :\n\n* **Mode interactif :** une expérience de chat dans le terminal, indépendante d'un éditeur, avec supervision humaine avant toute action. Utilisez-le pour comprendre la structure d'un code source, créer du code, corriger des erreurs ou résoudre des problèmes de pipelines.  \n* **Mode headless :** non interactif, conçu pour les runners, les scripts et les workflows automatisés. Intégrez-le dans vos [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") et laissez-le opérer en toute autonomie.\n\n## L'IA avec des garde-fous\n\nL'[IA agentique](https://about.gitlab.com/fr-fr/topics/agentic-ai/ \"Qu'est-ce que l'IA agentique ?\") capable d'exécuter des actions crée une exposition réelle en matière de sécurité. GitLab Duo CLI traite cette problématique au niveau de la plateforme, et non comme un ajout après coup :\n\n* **Supervision humaine par défaut** en mode interactif : aucune action n'est exécutée sans approbation préalable.  \n* **Détection d'injections de prompts** intégrée nativement à GitLab Duo Agent Platform.  \n* **Identité composite** qui limite les accès de l'agent et rend chaque action pilotée par l'IA auditable.\n\nGitLab Duo CLI prend également en charge les [fichiers d'instructions personnalisées](https://docs.gitlab.com/user/duo_agent_platform/customize/), tels que `chat-rules.md`, `AGENTS.md` et `SKILL.md`, qui définissent les tâches, ressources, contextes, connaissances et actions autorisés pour vos agents. **Il s'agit du principe du moindre privilège appliqué à l'IA : votre agent fait exactement ce que vous avez autorisé, et rien de plus.**\n\nDécouvrez GitLab Duo CLI en action :\n\u003Ciframe src=\"https://player.vimeo.com/video/1179964611?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=\"GitLab Duo CLI Beta Demo V1\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Utilisez GitLab Duo CLI dès aujourd'hui\n\nDécouvrez les avantages de GitLab Duo CLI en [démarrant un essai gratuit de GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr). \n\nSi vous utilisez déjà GitLab dans l'offre gratuite, vous pouvez vous inscrire à GitLab Duo Agent Platform en [suivant quelques étapes simples](https://docs.gitlab.com/subscriptions/gitlab_credits/#for-the-free-tier-on-gitlabcom). \n\nEt si vous utilisez déjà GitLab Premium ou GitLab Ultimate, vous pouvez profiter de GitLab Duo CLI en [activant simplement GitLab Duo Agent Platform](https://docs.gitlab.com/user/duo_agent_platform/turn_on_off/) et en commençant à utiliser les crédits GitLab [inclus](https://docs.gitlab.com/subscriptions/gitlab_credits/#included-credits) dans votre abonnement.",[683,9,684],"AI/ML","features",{"featured":11,"template":12,"slug":686},"gitlab-duo-cli",{"content":688,"config":698},{"title":689,"description":690,"authors":691,"category":9,"tags":693,"body":695,"heroImage":696,"date":697},"Arborescence des fichiers : naviguez plus rapidement dans les dépôts","Découvrez cette nouvelle fonctionnalité qui améliore la visibilité et simplifie la navigation sur GitLab.com, GitLab Self-Managed et GitLab Dedicated.",[692],"Talia Armato-Helle",[684,9,694],"DevSecOps","Imaginez le scénario suivant : vous repérez un fichier dans le navigateur de dépôt. Vous cliquez dessus, parcourez le code, puis vous vérifiez un élément dans une autre partie de l'arborescence. Vous cliquez donc sur le bouton retour. Vous redescendez dans l'arborescence, et accédez peut-être à niveau inférieur. Vous trouvez le fichier suivant, vous cliquez dessus et recommencez.\n\nCette approche fonctionne, mais devient vite fastidieuse. Si vous avez déjà souhaité que le navigateur de dépôt ressemble davantage à votre [IDE](https://about.gitlab.com/fr-fr/blog/what-is-an-ide/ \"Qu'est-ce qu'un IDE ?\") qu'à une série de fils d'Ariane, l'arborescence de fichiers de GitLab 18.9 est faite pour vous.\n\n## Fonctionnement de l'arborescence de fichiers\n\nL'arborescence de fichiers ajoute un panneau repliable et redimensionnable à côté de vos vues de fichiers et de répertoires, de sorte que la structure de votre projet reste visible pendant que vous lisez et naviguez dans le code. Ainsi, vous n'avez plus besoin de cliquer sur retour pour savoir où vous vous trouvez.\n\nCette fonctionnalité affiche les fichiers et répertoires de votre projet dans une arborescence à côté de la liste des fichiers et du contenu des fichiers, ce qui vous permet de voir la structure et le code en même temps.\n\nSi vous avez déjà utilisé une arborescence de fichiers dans un IDE ou une plateforme [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\"), elle devrait vous sembler familière :\n\n**Navigation avec une vue structurée**\n\nDéveloppez et repliez les répertoires et basculez entre les fichiers tout en gardant une vue claire de votre position dans la hiérarchie du dépôt. Lorsque vous accédez directement à un fichier imbriqué, l'arborescence développe les répertoires parents et met en surbrillance le fichier actuel afin que vous ne perdiez pas le contexte. L'arborescence se synchronise également avec votre position actuelle : lorsque vous sélectionnez un fichier dans la zone de contenu principale, l'arborescence se met à jour en conséquence.\n\n**Filtrage par nom de fichier**\n\nAprès avoir ouvert l'arborescence, appuyez sur `F` pour ouvrir la boîte de dialogue de recherche globale. Saisissez une partie d'un nom de fichier pour y accéder directement depuis la liste de résultats, chaque résultat affichant ses répertoires parents afin que vous sachiez où vous vous trouvez.\n\n\n**Navigation axée sur le clavier**\n\nL'arborescence implémente le modèle de vue arborescente ARIA du W3C, ce qui vous permet de naviguer parmi les fichiers et répertoires à l'aide du clavier et des touches fléchées, ainsi que des touches Entrée, Espace, Début, Fin et des touches de caractères. Ce type de navigation est plus accessible pour les utilisateurs de lecteurs d'écran et pour toute personne qui préfère utiliser un clavier.\n\n\n**Réactivité sur tous les écrans**\n\nSur un ordinateur, l'arborescence s'affiche côte à côte avec votre liste de fichiers et votre code. Sur les écrans plus petits, elle se transforme en panneau latéral gauche que vous pouvez ouvrir lorsque vous en avez besoin. Sur mobile, l'arborescence est masquée afin que la vue du code puisse occuper tout l'écran.\n\n\n**Conception pour les dépôts volumineux**\n\nPour les dépôts avec de nombreuses entrées, l'arborescence utilise la pagination afin que vous puissiez charger davantage d'éléments selon vos besoins sans surcharger la page. L'expérience reste fluide à mesure que votre projet se développe.\n\n## Découvrez l'arborescence de fichiers en action\n\nMichael Friedrich, Principal Developer Advocate chez GitLab, présente la nouvelle arborescence de fichiers dans GitLab. Découvrez comment cette fonctionnalité facilite la navigation dans les dépôts volumineux, comme si vous travailliez dans votre IDE. La démonstration utilise le projet GitLab [Tanuki IoT Platform](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/demo-environments/tanuki-iot-platform), que vous pouvez explorer vous-même pour tester l'arborescence de fichiers dans un véritable dépôt. \n\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1171188581?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=\"File Tree in Repo Demo\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\n## Essayez l'arborescence de fichiers dès aujourd'hui\n\nL'arborescence de fichiers est disponible dès maintenant sur GitLab.com et a été publiée dans la [version 18.9](https://about.gitlab.com/releases/2026/02/19/gitlab-18-9-released/) pour GitLab Self-Managed et GitLab Dedicated.\n\nVoici comment y accéder :\n\n1. Ouvrez n'importe quelle vue de fichier ou de répertoire de dépôt dans votre projet (`/\u003Cproject>/-/tree/\u003Cbranch>`).\n2. Dans le coin supérieur gauche, sélectionnez l'icône d'arborescence de fichiers ou appuyez sur `Shift+F` pour activer/désactiver l'arborescence de fichiers.\n3. Appuyez sur `F` pour filtrer les fichiers par nom ou extension, commencez à saisir du texte, puis utilisez les touches fléchées et `Entrée` pour accéder directement au fichier souhaité.\n\n## Perspectives\n\nL'équipe Source Code de GitLab a conçu l'arborescence de fichiers en plaçant l'accessibilité, les performances à grande échelle et la cohérence entre les différents écrans au cœur de ses exigences. Ces principes continueront de guider nos prochains développements, et vos retours nous aideront à façonner les futures itérations.\n\n## Aidez-nous à améliorer l'arborescence de fichiers\n\nPartagez vos retours sur l'arborescence de fichiers dans notre [ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/581271).\n\n\n> Vous souhaitez en savoir plus sur l'arborescence de fichiers ? Consultez la [documentation](https://docs.gitlab.com/user/project/repository/files/file_tree_browser/).\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1773075582/yiosxfhwk8rfkulrtchv.png","2026-03-31",{"featured":27,"template":12,"slug":699},"navigate-repositories-faster-with-the-file-tree-browser",{"content":701,"config":709},{"title":702,"description":703,"authors":704,"heroImage":705,"date":706,"body":707,"category":9,"tags":708},"GitLab 18.10 : l'IA agentique accessible à encore plus d'utilisateurs","Les utilisateurs de la version gratuite de GitLab.com peuvent acheter des crédits GitLab pour utiliser les agents et workflows d'IA, et profitent d'une revue de code automatisée à un tarif forfaitaire.",[692],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773843921/rm35fx4gylrsu9alf2fx.png","2026-03-19","L'IA agentique transforme la façon dont les logiciels sont développés. Mais pour de nombreuses équipes, en particulier dans les petites et moyennes structures, le chemin vers son adoption s'apparente à un choix binaire : souscrire un abonnement complet à une plateforme ou renoncer entièrement à l'IA.\n\nUn tournant s'amorce avec GitLab 18.10. Dès aujourd'hui, les équipes qui utilisent la version gratuite de GitLab.com peuvent acheter un abonnement mensuel de [GitLab Credits](https://docs.gitlab.com/subscriptions/gitlab_credits/) et commencer à utiliser [GitLab Duo Agent Platform](https://docs.gitlab.com/user/duo_agent_platform/) immédiatement, sans mise à niveau de leur abonnement. Il s'agit d'un véritable point d'entrée vers l'IA agentique pour les équipes qui ne sont pas encore prêtes à souscrire un abonnement GitLab, mais qui souhaitent commencer à développer avec l'IA.\n\nLe fonctionnement est simple : vous payez pour ce que l'IA accomplit, et non pour le nombre de personnes qui l'utilisent. Le propriétaire de votre groupe achète un engagement mensuel de GitLab Credits via les paramètres de facturation du groupe. L'ensemble de votre équipe accède alors aux mêmes agents et workflows d'IA que les clients GitLab Premium et GitLab Ultimate pour la planification, la génération de code, la revue de code automatisée et le diagnostic de pipelines, le tout à partir d'un pool de crédits partagé.\n\nLe [tableau de bord GitLab Credits](https://docs.gitlab.com/subscriptions/gitlab_credits/#gitlab-credits-dashboard) offre aux propriétaires de groupe une visibilité sur les agents et workflows qui consomment des crédits, afin de relier directement les dépenses de l'IA au travail produit.\n\n![Tableau de bord GitLab Credits qui affiche un pool mensuel engagé de 50 crédits avec suivi de l'utilisation, consommation de crédits à la demande et allocation de crédits par utilisateur pour GitLab Duo Agent Platform.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1773867549/jdrzquwptvjnbr7eqd56.png)\n\n## Zero-day avec GitLab Duo Agent Platform\n\nDès que le propriétaire de votre groupe a acheté des crédits, chaque membre de l'équipe peut commencer à utiliser GitLab Duo Agent Platform.\n\nVoici le fonctionnement d'un workflow type :\n\nVous commencez avec une demande de fonctionnalité pour votre logiciel. Ouvrez [l'agent GitLab Duo Planner](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/planner/) dans l'Agentic Chat et décrivez vos besoins. L'agent les décompose en éléments de travail structurés : tickets avec descriptions, labels et relations, tous créés directement dans votre projet. Ce qui prenait auparavant un après-midi entier de gestion manuelle des tickets ne prend plus que quelques minutes.\n\nSélectionnez l'un de ces tickets et assignez [le flow Developer](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/developer/) pour démarrer le travail. L'agent lit le contexte du ticket, génère du code conforme aux exigences, exécute les tests et ouvre une merge request pour revue. Vous pouvez également utiliser [l'Agentic Chat](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/) pour un travail plus itératif, qu'il s'agisse de refactorisation, d'extension ou d'explication de code dans le contexte de votre projet.\n\nLorsque la merge request est prête, [le flow Code Review](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/code_review/) exécute une revue automatisée en plusieurs étapes : analyse des modifications, prise en compte du contexte du dépôt et publication de commentaires inline structurés, directement liés au diff. Vos réviseurs humains peuvent ainsi se concentrer sur l'architecture et la logique métier, sans avoir à gérer les premières étapes manuelles.\n\nEt si le pipeline échoue, le [flow Fix CI/CD Pipeline](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/fix_pipeline/) lit les logs d'erreurs, identifie la cause profonde et propose un correctif. Au lieu de parcourir manuellement les job logs, votre équipe dispose d'un point de départ pour la correction.\n\nGitLab Duo Agent Platform accompagne le développement logiciel de l'itération au déploiement, à partir d'un seul pool de crédits.\n\nLa prise en main des agents et workflows est simple. Découvrez comment passer de la planification au déploiement en moins de 3 minutes dans cette vidéo :\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1175244743?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=\"18.10 Main Demo V2\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Revue de code à un tarif forfaitaire : des coûts prévisibles à grande échelle\n\nParmi tous les workflows disponibles via GitLab Duo Agent Platform, la revue de code automatisée est celui qui livre des résultats le plus rapidement, et celui pour lequel la prévisibilité des coûts est la plus importante.\n\nLe flow Code Review coûte désormais un tarif forfaitaire de 0,25 crédit GitLab par revue, indépendamment de la taille de la merge request, de la complexité du dépôt ou du nombre d'étapes exécutées en interne. Quatre revues correspondent à un crédit. Que votre équipe fusionne 500 ou 50 000 merge requests par mois, vous pouvez prévoir les coûts directement en fonction du nombre de revues.\n\nLes chiffres parlent d'eux-mêmes. Les revues de code manuelles ne coûtent pas seulement de l'argent : elles prennent du temps et perturbent le développement en raison de changements de contexte constants. Le temps économisé grâce au flow Code Review peut se traduire par des économies substantielles à mesure que le volume des revues augmente. Vous avez désormais la possibilité d'exécuter des centaines de revues simultanément au lieu de les laisser en file d'attente, ce qui signifie que les gains de temps se combinent rapidement aux économies financières.\n\nLes équipes qui utilisent la version gratuite de GitLab savent désormais exactement quelle part de leur pool mensuel de crédits est consacrée à la revue de code afin de pouvoir planifier en conséquence.\n\n> Découvrez [le fonctionnement du flow Code Review](https://about.gitlab.com/fr-fr/blog/code-review-without-the-bottlenecks-or-the-bill/) et comment faire évoluer votre organisation.\n\n## Pourquoi GitLab Premium multiplie la valeur ajoutée\n\nLes crédits GitLab de la version gratuite offrent à votre équipe un accès direct à l'[IA agentique](https://about.gitlab.com/fr-fr/topics/agentic-ai/ \"Qu'est-ce que l'IA agentique ?\"). Si votre équipe s'appuie davantage sur GitLab, GitLab Premium est l'abonnement qui allie avantages économiques et fonctionnalités avancées.\n\nDisponible pour 29 $ par utilisateur et par mois, [GitLab Premium](https://about.gitlab.com/fr-fr/pricing/) inclut 12 GitLab Credits par utilisateur dans le cadre d'une offre promotionnelle. Pour une équipe de 20 personnes, cela représente 240 crédits par mois avant toute dépense supplémentaire, soit suffisamment pour couvrir environ 960 revues de code automatisées, ou une combinaison de revues de code, de planification, de workflows de développement et de corrections de pipelines.\n\nGitLab Duo Agent Platform ne représente qu'une partie de GitLab Premium. Vous bénéficiez également d'un [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") avancé pour les pipelines à fort volume, d'approbations de merge requests et de propriétaires du code pour la gouvernance, ainsi que d'une IA qui fonctionne au sein d'une couche de données unifiée avec un contexte partagé entre vos projets.\n\nSi votre équipe utilise des crédits dans le cadre de la version gratuite et constate que l'IA devient centrale dans son workflow, GitLab Premium constitue l'étape suivante naturelle grâce aux crédits promotionnels inclus. Cette formule offre davantage de fonctionnalités et offre une structure de base qui évolue avec vous.\n\n## Commencez dès aujourd'hui\n\nGitLab 18.10 est disponible dès maintenant. Que votre équipe ait besoin de l'IA agentique pour accélérer ses tâches ou de la plateforme complète pour accompagner ses méthodes de travail actuelles, vous disposez désormais d'une solution claire pour accélérer votre processus de développement logiciel.\n\n* **Équipes qui utilisent la version gratuite de GitLab.com :** [achetez un engagement mensuel de GitLab Credits](https://docs.gitlab.com/subscriptions/gitlab_credits/#for-the-free-tier-on-gitlabcom) via les paramètres de facturation de votre groupe et commencez à utiliser GitLab Duo Agent Platform dès aujourd'hui.\n\n* **Équipes prêtes pour la plateforme complète :** [trouvez l'abonnement GitLab adapté à votre équipe](https://docs.gitlab.com/subscriptions/choosing_subscription/) ou [démarrez un essai gratuit de GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/).\n\nLa configuration des crédits pour votre équipe est rapide et simple. Regardez cette démo pour en savoir plus :\n\u003Ciframe src=\"https://player.vimeo.com/video/1175238100?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=\"GitLab Credits Purchase Flow\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n---\n\n## FAQ\n\n**Qu'est-ce qu'un engagement mensuel de GitLab Credits ?**\n\nUn engagement mensuel est une option d'achat basée sur l'utilisation, dans laquelle le propriétaire de votre groupe sélectionne un nombre défini de crédits qui s'appliquent en tant que pool partagé pour l'ensemble du groupe. Les crédits sont consommés lorsque votre équipe utilise les fonctionnalités de GitLab Duo Agent Platform. Consultez la [documentation GitLab Credits](https://docs.gitlab.com/subscriptions/gitlab_credits/) pour en savoir plus.\n\n**Qui peut acheter des GitLab Credits aujourd'hui ?**\n\nLes clients GitLab Premium et GitLab Ultimate profitent déjà de crédits promotionnels inclus dans leur abonnement. À partir de la version 18.10, les espaces de nommage de groupe principal de la version gratuite de GitLab.com peuvent également acheter un engagement mensuel de crédits via la facturation en libre-service du groupe. Consultez la [documentation GitLab Credits](https://docs.gitlab.com/subscriptions/gitlab_credits/) pour connaître les dernières conditions d'éligibilité.\n\n**Quelles fonctionnalités d'IA les crédits débloquent-ils dans la version gratuite ?**\n\nLes équipes disposant de crédits accèdent aux mêmes fonctionnalités et modèles d'IA agentique que les clients GitLab Premium et GitLab Ultimate, notamment l'agent Planner, le flow Developer, le flow Code Review, le flow Fix CI/CD Pipeline, l'Agentic Chat, les suggestions de code, les agents et workflows personnalisés, et bien plus encore. Consultez la [documentation relative à GitLab Duo Agent Platform](https://docs.gitlab.com/user/duo_agent_platform/) pour obtenir la liste complète.\n\n**Combien coûte la revue de code automatisée ?**\n\nLe flow Code Review applique un tarif forfaitaire de 0,25 crédit GitLab par revue, indépendamment de la taille ou de la complexité de la merge request. Consultez la [documentation relative au flow Code Review](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/code_review/) pour connaître les détails actuels des tarifs.\n\n**Puis-je passer de la version gratuite avec crédits à GitLab Premium ?**\n\nDans GitLab 18.10, la mise à niveau d'un espace de nommage de la version gratuite avec un engagement mensuel de crédits vers GitLab Premium est disponible via un processus accompagné par l'équipe commerciale. Contactez l'[équipe commerciale GitLab](https://about.gitlab.com/fr-fr/contact-sales/) pour connaître vos options.\n\n\n",[684,9],{"featured":27,"template":12,"slug":710},"gitlab-18-10-agentic-ai-now-open-to-even-more-teams-on-gitlab",{"promotions":712},[713,727,739],{"id":714,"categories":715,"header":717,"text":718,"button":719,"image":724},"ai-modernization",[716],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":720,"config":721},"Get your AI maturity score",{"href":722,"dataGaName":723,"dataGaLocation":239},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":725},{"src":726},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":728,"categories":729,"header":731,"text":718,"button":732,"image":736},"devops-modernization",[9,730],"devsecops","Are you just managing tools or shipping innovation?",{"text":733,"config":734},"Get your DevOps maturity score",{"href":735,"dataGaName":723,"dataGaLocation":239},"/assessments/devops-modernization-assessment/",{"config":737},{"src":738},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":740,"categories":741,"header":743,"text":718,"button":744,"image":748},"security-modernization",[742],"security","Are you trading speed for security?",{"text":745,"config":746},"Get your security maturity score",{"href":747,"dataGaName":723,"dataGaLocation":239},"/assessments/security-modernization-assessment/",{"config":749},{"src":750},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":752,"blurb":753,"button":754,"secondaryButton":758},"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":755},{"href":756,"dataGaName":45,"dataGaLocation":757},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/fr-fr/","feature",{"text":47,"config":759},{"href":49,"dataGaName":50,"dataGaLocation":757},1777309995348]