[{"data":1,"prerenderedAt":815},["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":449,"footer-fr-fr":459,"blog-post-authors-fr-fr-Dov Hershkovitch":696,"blog-related-posts-fr-fr-ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline":710,"blog-promotions-fr-fr":753,"next-steps-fr-fr":806},{"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/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","iMv-z5yNZpNyMPkc1tBqe9dVHkYRvwyTWA1hFeUPCfQ",{"data":35},{"logo":36,"freeTrial":41,"sales":46,"login":51,"items":56,"search":365,"minimal":400,"duo":419,"switchNav":428,"pricingDeployment":439},{"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},"Explorer 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},"Pourquoi 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",[165,170,175],{"text":166,"config":167},"Pour les entreprises",{"href":168,"dataGaLocation":40,"dataGaName":169},"/fr-fr/enterprise/","enterprise",{"text":171,"config":172},"Pour les PME",{"href":173,"dataGaLocation":40,"dataGaName":174},"/fr-fr/small-business/","small business",{"text":176,"config":177},"Pour le 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",{"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},"Trust Center",{"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},"Assistance GitLab",{"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},{"button":429,"mobileIcon":434,"desktopIcon":436},{"text":430,"config":431},"/switch",{"href":432,"dataGaName":433,"dataGaLocation":405},"#contact","switch",{"altText":407,"config":435},{"src":409,"dataGaName":410,"dataGaLocation":405},{"altText":407,"config":437},{"src":438,"dataGaName":410,"dataGaLocation":405},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":440,"mobileIcon":445,"desktopIcon":447},{"text":441,"config":442},"Retour aux tarifs",{"href":183,"dataGaName":443,"dataGaLocation":405,"icon":444},"back to pricing","GoBack",{"altText":407,"config":446},{"src":409,"dataGaName":410,"dataGaLocation":405},{"altText":407,"config":448},{"src":413,"dataGaName":410,"dataGaLocation":405},{"title":450,"button":451,"config":456},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":452,"config":453},"Regarder GitLab Transcend maintenant",{"href":454,"dataGaName":455,"dataGaLocation":40},"/fr-fr/events/transcend/virtual/","transcend event",{"layout":457,"icon":458,"disabled":27},"release","AiStar",{"data":460},{"text":461,"source":462,"edit":468,"contribute":473,"config":478,"items":483,"minimal":687},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence.",{"text":463,"config":464},"Afficher le code source de la page",{"href":465,"dataGaName":466,"dataGaLocation":467},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":469,"config":470},"Modifier cette page",{"href":471,"dataGaName":472,"dataGaLocation":467},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":474,"config":475},"Veuillez contribuer",{"href":476,"dataGaName":477,"dataGaLocation":467},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":479,"facebook":480,"youtube":481,"linkedin":482},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[484,529,581,625,652],{"title":181,"links":485,"subMenu":500},[486,490,495],{"text":487,"config":488},"Voir les forfaits",{"href":183,"dataGaName":489,"dataGaLocation":467},"view plans",{"text":491,"config":492},"GitLab Premium",{"href":493,"dataGaName":494,"dataGaLocation":467},"/fr-fr/pricing/premium/","why premium",{"text":496,"config":497},"GitLab Ultimate",{"href":498,"dataGaName":499,"dataGaLocation":467},"/fr-fr/pricing/ultimate/","why ultimate",[501],{"title":347,"links":502},[503,505,507,509,514,519,524],{"text":47,"config":504},{"href":49,"dataGaName":50,"dataGaLocation":467},{"text":356,"config":506},{"href":358,"dataGaName":359,"dataGaLocation":467},{"text":361,"config":508},{"href":363,"dataGaName":364,"dataGaLocation":467},{"text":510,"config":511},"Statut",{"href":512,"dataGaName":513,"dataGaLocation":467},"https://status.gitlab.com/","status",{"text":515,"config":516},"Conditions d'utilisation",{"href":517,"dataGaName":518,"dataGaLocation":467},"/terms/","terms of use",{"text":520,"config":521},"Politique de confidentialité",{"href":522,"dataGaName":523,"dataGaLocation":467},"/fr-fr/privacy/","privacy statement",{"text":525,"config":526},"Gérer vos cookies",{"dataGaName":527,"dataGaLocation":467,"id":528,"isOneTrustButton":27},"cookie preferences","ot-sdk-btn",{"title":85,"links":530,"subMenu":539},[531,535],{"text":532,"config":533},"Plateforme DevSecOps",{"href":67,"dataGaName":534,"dataGaLocation":467},"devsecops platform",{"text":536,"config":537},"Développement assisté par l'IA",{"href":74,"dataGaName":538,"dataGaLocation":467},"ai-assisted development",[540],{"title":541,"links":542},"Thèmes",[543,546,551,556,561,566,571,576],{"text":23,"config":544},{"href":545,"dataGaName":32,"dataGaLocation":467},"/fr-fr/topics/ci-cd/",{"text":547,"config":548},"GitOps",{"href":549,"dataGaName":550,"dataGaLocation":467},"/fr-fr/topics/gitops/","gitops",{"text":552,"config":553},"DevOps",{"href":554,"dataGaName":555,"dataGaLocation":467},"/fr-fr/topics/devops/","devops",{"text":557,"config":558},"Contrôle de version",{"href":559,"dataGaName":560,"dataGaLocation":467},"/fr-fr/topics/version-control/","version control",{"text":562,"config":563},"DevSecOps",{"href":564,"dataGaName":565,"dataGaLocation":467},"/fr-fr/topics/devsecops/","devsecops",{"text":567,"config":568},"Cloud-native",{"href":569,"dataGaName":570,"dataGaLocation":467},"/fr-fr/topics/cloud-native/","cloud native",{"text":572,"config":573},"IA pour la programmation",{"href":574,"dataGaName":575,"dataGaLocation":467},"/fr-fr/topics/devops/ai-for-coding/","ai for coding",{"text":577,"config":578},"IA agentique",{"href":579,"dataGaName":580,"dataGaLocation":467},"/fr-fr/topics/agentic-ai/","agentic ai",{"title":582,"links":583},"Solutions",[584,587,589,594,597,600,603,606,609,612,615,620],{"text":127,"config":585},{"href":122,"dataGaName":586,"dataGaLocation":467},"Application Security Testing",{"text":114,"config":588},{"href":99,"dataGaName":100,"dataGaLocation":467},{"text":590,"config":591},"Développement Agile",{"href":592,"dataGaName":593,"dataGaLocation":467},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":109,"config":595},{"href":111,"dataGaName":596,"dataGaLocation":467},"source code management",{"text":23,"config":598},{"href":104,"dataGaName":599,"dataGaLocation":467},"continuous integration & delivery",{"text":153,"config":601},{"href":155,"dataGaName":602,"dataGaLocation":467},"value stream management",{"text":547,"config":604},{"href":605,"dataGaName":550,"dataGaLocation":467},"/fr-fr/solutions/gitops/",{"text":607,"config":608},"Entreprises",{"href":168,"dataGaName":169,"dataGaLocation":467},{"text":610,"config":611},"PME",{"href":173,"dataGaName":174,"dataGaLocation":467},{"text":613,"config":614},"Secteur public",{"href":178,"dataGaName":179,"dataGaLocation":467},{"text":616,"config":617},"Éducation",{"href":618,"dataGaName":619,"dataGaLocation":467},"/fr-fr/solutions/education/","education",{"text":621,"config":622},"Services financiers",{"href":623,"dataGaName":624,"dataGaLocation":467},"/fr-fr/solutions/finance/","financial services",{"title":186,"links":626},[627,629,631,633,636,638,640,642,644,646,648,650],{"text":198,"config":628},{"href":200,"dataGaName":201,"dataGaLocation":467},{"text":203,"config":630},{"href":205,"dataGaName":206,"dataGaLocation":467},{"text":208,"config":632},{"href":210,"dataGaName":211,"dataGaLocation":467},{"text":213,"config":634},{"href":215,"dataGaName":635,"dataGaLocation":467},"docs",{"text":236,"config":637},{"href":238,"dataGaName":239,"dataGaLocation":467},{"text":231,"config":639},{"href":233,"dataGaName":234,"dataGaLocation":467},{"text":241,"config":641},{"href":243,"dataGaName":244,"dataGaLocation":467},{"text":249,"config":643},{"href":251,"dataGaName":252,"dataGaLocation":467},{"text":254,"config":645},{"href":256,"dataGaName":257,"dataGaLocation":467},{"text":259,"config":647},{"href":261,"dataGaName":262,"dataGaLocation":467},{"text":264,"config":649},{"href":266,"dataGaName":267,"dataGaLocation":467},{"text":269,"config":651},{"href":271,"dataGaName":272,"dataGaLocation":467},{"title":287,"links":653},[654,656,658,660,662,664,666,671,676,678,680,682],{"text":294,"config":655},{"href":296,"dataGaName":289,"dataGaLocation":467},{"text":299,"config":657},{"href":301,"dataGaName":302,"dataGaLocation":467},{"text":307,"config":659},{"href":309,"dataGaName":310,"dataGaLocation":467},{"text":312,"config":661},{"href":314,"dataGaName":315,"dataGaLocation":467},{"text":317,"config":663},{"href":319,"dataGaName":320,"dataGaLocation":467},{"text":322,"config":665},{"href":324,"dataGaName":325,"dataGaLocation":467},{"text":667,"config":668},"Développement durable",{"href":669,"dataGaName":670,"dataGaLocation":467},"/sustainability/","Sustainability",{"text":672,"config":673},"Diversité, inclusion et appartenance (DIB)",{"href":674,"dataGaName":675,"dataGaLocation":467},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":327,"config":677},{"href":329,"dataGaName":330,"dataGaLocation":467},{"text":337,"config":679},{"href":339,"dataGaName":340,"dataGaLocation":467},{"text":342,"config":681},{"href":344,"dataGaName":345,"dataGaLocation":467},{"text":683,"config":684},"Déclaration de transparence sur l'esclavage moderne",{"href":685,"dataGaName":686,"dataGaLocation":467},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":688},[689,691,694],{"text":515,"config":690},{"href":517,"dataGaName":518,"dataGaLocation":467},{"text":692,"config":693},"Gestion des cookies",{"dataGaName":527,"dataGaLocation":467,"id":528,"isOneTrustButton":27},{"text":520,"config":695},{"href":522,"dataGaName":523,"dataGaLocation":467},[697],{"id":698,"title":18,"body":8,"config":699,"content":701,"description":8,"extension":25,"meta":705,"navigation":27,"path":706,"seo":707,"stem":708,"__hash__":709},"blogAuthors/en-us/blog/authors/dov-hershkovitch.yml",{"template":700},"BlogAuthor",{"name":18,"config":702},{"headshot":703,"ctfId":704},"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",[711,725,740],{"content":712,"config":723},{"title":713,"description":714,"authors":715,"heroImage":717,"date":718,"category":9,"tags":719,"body":722},"Feature flags en Python sur GitLab : guide de démarrage","Découvrez comment intégrer les feature flags GitLab dans une application Flask en Python avec le SDK Unleash pour contrôler le déploiement progressif de fonctionnalités sans avoir à redéployer.",[716],"Omid Khan","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1774465167/n5hlvrsrheadeccyr1oz.png","2026-04-27",[720,721,9],"features","tutorial","Imaginez le scénario suivant : vous avez passé des semaines à développer une nouvelle fonctionnalité. Elle passe tous les tests, la revue de code est terminée, et elle est prête à être livrée. Vous la déployez donc en production et, en moins d'une heure, votre boîte de réception déborde de rapports de bogues. La fonctionnalité fonctionne parfaitement pour la plupart des utilisateurs, mais un comportement du trafic de production que vous n’aviez pas anticipé provoque des échecs pour une partie d'entre eux. Vous voilà en train de vous démener pour effectuer un retour à la version précédente, rédiger des rapports d'incident et gérer les retombées en termes de relations publiques.\n\n\nLes feature flags empêchent précisément ce genre de scénarios. Ils vous permettent de dissocier le déploiement de la release : vous effectuez un push de votre code en production dès qu'il est prêt, puis contrôlez qui voit réellement la nouvelle fonctionnalité en activant un bouton bascule sur GitLab. Commencez par votre équipe QA à l'aide d'une stratégie « identifiants des utilisateurs », passez ensuite à un « déploiement progressif à 10 % », puis basculez sur « tous les utilisateurs » lorsque vous êtes sûr de vous. Si quelque chose ne se déroule pas comme prévu à un moment donné, il vous suffit de désactiver la fonctionnalité en quelques secondes. Aucun redéploiement, aucun correctif d'urgence, aucun impact sur votre réputation.\n\n\nCe tutoriel vous guide à travers une application Flask fonctionnelle qui lit les feature flags GitLab via le SDK Unleash en Python. Une version complète et exécutable du code est disponible sur [gitlab.com/omid-blogs/gitlab-feature-flags-demo](https://gitlab.com/omid-blogs/gitlab-feature-flags-demo). Clonez-la dans votre propre groupe ou workspace pour disposer d'un contrôle en temps réel avec des feature flags en quelques minutes.\n\n\nÀ la fin de ce tutoriel, vous comprendrez le fonctionnement de l'intégration et disposerez d'un template pour vos propres projets.\n\n\n## Ce dont vous aurez besoin\n\n\n* Un projet GitLab (version gratuite, GitLab Premium ou GitLab Ultimate) avec les feature flags activés. C'est ici que vous créerez et gérerez vos feature flags. Pour les activer, accédez à votre projet et naviguez vers **Paramètres > Général > Visibilité, fonctionnalités du projet, autorisations**, puis vérifiez que l'option **Feature flags** est activée.\n\n* Le [dépôt de démonstration](https://gitlab.com/omid-blogs/gitlab-feature-flags-demo) dupliqué dans votre propre espace de nommage GitLab, puis cloné localement.\n\n\n## Fonctionnement des feature flags GitLab en coulisses\n\n\nGitLab expose une API compatible avec [Unleash](https://github.com/Unleash/unleash) pour chaque projet. Cela signifie que n'importe quel SDK de client Unleash (Go, Ruby, Python, JavaScript, et bien d'autres) peut se connecter directement à GitLab sans serveur Unleash séparé.\n\n\nAu démarrage, le SDK récupère toutes les définitions des feature flags, puis les actualise selon un intervalle configurable (15 secondes dans la démo). Chaque appel à `is_enabled()` s'évalue localement à partir de la configuration en cache, sans appel réseau par vérification de feature flag. L'évaluation des feature flags est donc quasi instantanée et résiliente face aux problèmes réseau transitoires.\n\n\nVoici les étapes à suivre pour intégrer les feature flags GitLab dans une application Flask en Python à l'aide du SDK Unleash.\n\n\n## 1. Configurer votre projet GitLab et cloner la démo\n\n\nVous aurez besoin des éléments suivants :\n\n\n* Votre propre projet GitLab pour héberger les feature flags\n\n\n* Le dépôt de démonstration cloné localement pour exécuter l'application\n\n\n### Dupliquer ou cloner le dépôt de démonstration\n\n\nAccédez à [gitlab.com/omid-blogs/gitlab-feature-flags-demo](https://gitlab.com/omid-blogs/gitlab-feature-flags-demo) et dupliquez-le dans votre propre espace de nommage GitLab. Vous obtiendrez ainsi une copie personnelle du projet où vous pourrez gérer vos propres feature flags. Clonez-le ensuite localement et ouvrez-le dans votre IDE préféré :\n\n\n\n```shell\ngit clone https://gitlab.com/\u003Cyour-namespace>/gitlab-feature-flags-demo.git\ncd gitlab-feature-flags-demo\n```\n\n\n### Contenu du dépôt\n\n```\n.\n├── app.py                # Flask app + Unleash SDK integration\n├── requirements.txt      # Python dependencies\n├── .env.example          # Template for required environment variables\n├── .gitignore\n├── templates/\n│   └── index.html        # Web UI template\n└── static/\n    └── styles.css        # Styling\n```\n\n## 2. Créer vos feature flags dans GitLab\n\n\nOuvrez votre propre projet GitLab et naviguez vers **Déploiement > Feature flags**, puis cliquez sur **Nouveau feature flag**. Créez les quatre feature flags suivants, en définissant le statut de chacun sur **Actif** avec une stratégie **Tous les utilisateurs**.\n\n\n* **dark_mode :** bascule la page vers un schéma de couleurs sombre.\n\n* **holiday_banner :** affiche une bannière festive en haut de la page.\n\n* **new_layout :** passe la grille de cartes à une disposition en une seule colonne.\n\n* **fun_fonts :** remplace la police du corps de texte par un style manuscrit ludique.\n\n\n\n\u003Cfigure>\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1774466322/pifymwd6senqz3nzcyxa.png\" alt=\"Les quatre feature flags dans l'interface GitLab\">\u003Cfigcaption>\u003Cem>Les quatre feature flags dans l'interface GitLab\u003C/em>\u003C/figcaption>\u003C/figure>\n\n\n**Conseil :** un feature flag doit être actif et disposer d'au moins une stratégie pour être considéré comme activé. Sans stratégie, le SDK considère le feature flag comme désactivé même s'il est marqué comme « Actif ».\n\n\n### Comprendre les stratégies\n\n\n« Tous les utilisateurs » est un simple bouton bascule, mais GitLab prend en charge plusieurs autres stratégies prêtes à l'emploi :\n\n\n* **Pourcentage de déploiement** *(recommandé)* : déploiement progressif vers un pourcentage d'utilisateurs, basé sur l'identifiant de l'utilisateur, l'identifiant de session ou de manière aléatoire. C'est l'option la plus flexible et celle à privilégier en premier.\n\n* **Pourcentage d'utilisateurs :** activation pour un pourcentage d'utilisateurs authentifiés. Moins flexible que le pourcentage de déploiement, car elle ne fonctionne qu'avec les utilisateurs connectés.\n\n* **ID des utilisateurs :** activation pour des identifiants d'utilisateurs spécifiques uniquement, idéale pour les tests internes avec un groupe nommé.\n\n* **Listes d'utilisateurs :** activation pour une liste prédéfinie d'utilisateurs.\n\n* **Tous les utilisateurs :** activation pour tout le monde.\n\n\nLes stratégies font la force des feature flags. Commencez par votre équipe QA avec une stratégie basée sur les ID des utilisateurs, passez à un déploiement progressif à 10 %, puis basculez sur tous les utilisateurs lorsque vous êtes sûr de vous. Tout est paramétrable depuis l'interface utilisateur GitLab, sans aucune modification de code.\n\n\n## 3. Obtenir vos identifiants Unleash\n\n\nSur la page Feature flags, cliquez sur **Configurer** dans le coin supérieur droit. Vous verrez deux valeurs :\n\n\n* **URL de l'API :** `https://gitlab.com/api/v4/feature_flags/unleash/\u003Cyour-project-id>`\n\n* **Identifiant d'instance :** un jeton unique limité à votre projet\n\n\nCopiez les deux valeurs. Vous les transmettrez à l'application en tant que variables d'environnement. Notez que l'identifiant d'instance est en lecture seule. Il ne peut que récupérer l'état des feature flags, pas le modifier, mais traitez tout de même l'identifiant d'instance comme un secret afin d'éviter toute divulgation d'informations.\n\n\n\u003Cfigure>\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1774466322/bxkn0xkpe4xude0es4zx.png\" alt=\"Le panneau Configurer affichant l'URL de l'API et votre identifiant d'instance\">\u003Cfigcaption>\u003Cem>Le panneau Configurer affichant l'URL de l'API et votre identifiant d'instance\u003C/em>\u003C/figcaption>\u003C/figure>\n\n\n## 4. Configurer le projet localement\n\n\nLe README contient le guide de configuration complet, mais en résumé :\n\n\n```shell\npip install -r requirements.txt\n```\n\n\nDéfinissez ensuite vos identifiants. Deux options s'offrent à vous :\n\n\n**Option A : utiliser le fichier .env (recommandé)**\n\n\nLe dépôt inclut un fichier `.env.example`. Copiez-le et renseignez vos valeurs :\n\n\n```shell\ncp .env.example .env\n```\n\n\nOuvrez `.env` dans votre éditeur et remplacez les valeurs par défaut par vos identifiants de l'étape 3 :\n\n\n```\nUNLEASH_URL=https://gitlab.com/api/v4/feature_flags/unleash/\u003Cyour-project-id>\nUNLEASH_INSTANCE_ID=\u003Cyour-instance-id>\nUNLEASH_APP_NAME=production\n```\n\n\nEnsuite, exportez-les :\n\n\n```shell\nexport $(grep -v '^#' .env | xargs)\n```\n\n\n**Option B : exporter directement dans votre terminal**\n\n\n```shell\nexport UNLEASH_URL=\"https://gitlab.com/api/v4/feature_flags/unleash/\u003Cyour-project-id>\"\nexport UNLEASH_INSTANCE_ID=\"\u003Cyour-instance-id>\"\nexport UNLEASH_APP_NAME=\"production\"\n```\n\n\nN'effectuez jamais un commit de votre fichier `.env` dans le contrôle de version. Le `.gitignore` du dépôt l'exclut déjà, mais il est utile de savoir pourquoi : votre identifiant d'instance est un secret et ne doit pas figurer dans l'historique Git.\n\n\nTrois variables d'environnement pilotent l'ensemble de l'intégration :\n\n\n| Variable | Requise | Description | Valeur par défaut |\n| ----- | ----- | ----- | ----- |\n| `UNLEASH_URL` | Oui | URL de l'API Unleash GitLab pour votre projet | — |\n| `UNLEASH_INSTANCE_ID` | Oui | Identifiant d'instance du panneau Configurer | — |\n| `UNLEASH_APP_NAME` | Non | Nom de l'environnement, correspond aux stratégies de feature flags | `production` |\n\n\n\n\n`UnleashClient` est la dépendance clé. Il s'agit du SDK Python officiel d'Unleash qui gère l'interrogation périodique, la mise en cache et l'évaluation locale des feature flags afin que vous n'ayez pas à développer tout cela vous-même.\n\n\n## 5. Comprendre l'application\n\n\nAvant de l'exécuter, parcourez `app.py`. Voici les modèles clés à comprendre pour les reproduire dans vos propres projets.\n\n\n**Initialisation du SDK**\n\n\n```py\nunleash_client = UnleashClient(\n    url=UNLEASH_URL,\n    app_name=UNLEASH_APP_NAME,\n    instance_id=UNLEASH_INSTANCE_ID,\n    refresh_interval=15,\n    metrics_interval=60,\n)\n\nunleash_client.initialize_client()\n```\n\nAucun jeton d'accès personnel, aucun identifiant codé en dur dans le code source. L'application s'arrête immédiatement avec un message d'erreur clair si l'une des deux variables requises est manquante.\n\n\n**Vérification d'un feature flag**\n\n\n```py\ndef is_flag_enabled(flag_name):\n    return unleash_client.is_enabled(flag_name)\n```\n\nÉtant donné que le SDK met en cache les définitions des feature flags en mémoire, `is_enabled()` renvoie un résultat instantanément, sans aller-retour réseau.\n\n\n**Contrôler le comportement réel derrière les feature flags**\n\n\nLa route index construit un dictionnaire de fonctionnalités, évalue chaque feature flag et transmet les résultats au template :\n\n\n```py\nfeatures = {}\nfor flag_name, config in feature_configs.items():\n    features[flag_name] = {\n        **config,\n        'enabled': is_flag_enabled(flag_name)\n    }\n\nreturn render_template('index.html', features=features)\n```\n\nLe template utilise ces valeurs pour appliquer conditionnellement des classes CSS et afficher des éléments de l'interface. `dark_mode` bascule une classe sur le corps, `holiday_banner` affiche ou masque entièrement un élément de bannière. Ouvrez `templates/index.html` pour voir comment le tout est connecté.\n\n\nVeuillez noter que `index.html` se rafraîchit également automatiquement toutes les 30 secondes via un petit extrait JavaScript, ce qui vous permet d'observer les changements de feature flags sans recharger manuellement la page.\n\n\n**Transmettre le contexte utilisateur pour les stratégies ciblées**\n\n\nLorsque vous souhaitez aller au-delà de la stratégie Tous les utilisateurs et utiliser des déploiements par pourcentage ou le ciblage par utilisateur, transmettez un objet de contexte à `is_enabled()` :\n\n\n```py\nunleash_client.is_enabled(\n    'new_layout',\n    context={'userId': current_user.id}\n)\n```\n\nLe SDK gère automatiquement le hachage cohérent pour les déploiements par pourcentage, sans calcul de votre côté.\n\n\n## 6. Exécuter l'application\n\n\n```shell\npython3 app.py\n```\n\n\nAccédez à `http://localhost:8080`. Vous devriez voir les quatre cartes de fonctionnalités affichant leur état actuel (activé/désactivé).\n\n\n\u003Cfigure>\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1774466322/bjc0rp7h43wetefny8cw.png\" alt=\"Application de démonstration avec les quatre feature flags désactivés\">\u003Cfigcaption>\u003Cem>Application de démonstration avec les quatre feature flags désactivés\u003C/em>\u003C/figcaption>\u003C/figure>\n\n\n## 7. Activer les feature flags en temps réel\n\n\nRetournez dans **Déploiement > Feature flags** dans GitLab et activez l'un des feature flags. Essayez `dark_mode` ou `holiday_banner` pour tester l'effet le plus visible. Attendez environ 15 secondes, puis rechargez la page. La carte se met à jour pour refléter le nouvel état, et si vous avez activé `dark_mode`, l'ensemble de la page passe en thème sombre. Désactivez la fonctionnalité, attendez, rechargez, et tout revient instantanément à la normale.\n\n\nC'est le principal atout des feature flags : vous contrôlez le comportement de l'application depuis GitLab sans toucher au code ni effectuer de redéploiement.\n\n\n\u003Cfigure>\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1774466321/kfbvvazflpta4pt8vtoj.png\" alt=\"Application de démonstration avec deux feature flags désactivés\">\u003Cfigcaption>\u003Cem>Application de démonstration avec deux feature flags désactivés\u003C/em>\u003C/figcaption>\u003C/figure>\n\n\n\n\u003Cfigure>\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1774466321/rslzfdcpronixcfokfbk.png\" alt=\"Application de démonstration avec deux feature flags désactivés\">\u003Cfigcaption>\u003Cem>Application de démonstration avec deux feature flags désactivés\u003C/em>\u003C/figcaption>\u003C/figure>\n\n\n\n## Pourquoi utiliser le SDK Unleash plutôt que l'API REST GitLab ?\n\n\nPour une application qui évalue des feature flags à chaque requête, le SDK est le choix évident. Il est plus rapide, plus simple, et l'identifiant d'instance qu'il utilise ne dispose d'aucune autorisation au-delà de la lecture de l'état des feature flags. La surface d'exposition est bien plus réduite qu'avec un jeton d'accès personnel.\n\n\n|  | API REST | SDK Unleash |\n| ----- | ----- | ----- |\n| **Authentification** | Nécessite un jeton d'accès personnel avec des autorisations étendues dans le projet | Utilise uniquement l'identifiant d'instance, en lecture seule, limité à l'état des feature flags, aucun jeton d'accès personnel nécessaire |\n| **Évaluation des feature flags** | Appel réseau par vérification | Évaluation locale à partir de la configuration en cache |\n| **Latence par vérification** | Aller-retour réseau | Quasi nulle (en mémoire) |\n| **Prise en charge des stratégies** | Analyse syntaxique manuelle requise | Prise en charge intégrée des déploiements par pourcentage et du ciblage par identifiant d'utilisateur |\n| **Limites de débit** | Limites de débit de l'API GitLab.com | Une seule connexion d'interrogation par instance d'application |\n\n\n## Dépannage\n\n\n| Problème | Solution |\n| ----- | ----- |\n| L'application se ferme avec `ERROR: UNLEASH_URL and UNLEASH_INSTANCE_ID...` | Définissez les deux variables env. Consultez `.env.example`. |\n| Tous les feature flags apparaissent comme désactivés | Vérifiez que les feature flags existent dans GitLab et disposent d'une stratégie active. Attendez ensuite 15 secondes que le SDK se rafraîchisse. |\n| Les modifications dans GitLab n'apparaissent pas | Le SDK interroge le serveur toutes les 15 secondes. Rechargez la page après un court délai. |\n| Une adresse IP locale ne fonctionne pas | Le pare-feu de votre système d'exploitation bloque peut-être le port 8080. Utilisez `localhost:8080` à la place. |\n\n\n## Note sur les limites de débit en production\n\n\nL'intervalle d'interrogation de 15 secondes convient parfaitement au développement et aux petits déploiements. Lorsque tous les clients interrogent depuis la même IP, GitLab.com peut prendre en charge environ 125 clients à un intervalle de 15 secondes avant d'atteindre les limites de débit. Si vous développez une application de production à plus grande échelle, envisagez de placer un proxy Unleash en amont de vos clients. Ce dernier regroupe les requêtes vers GitLab pour l'ensemble de vos instances et réduit considérablement le trafic en amont.\n\n\n## Considérations de sécurité\n\n\n1. **`debug=False` est déjà défini dans la démo :** conservez ce paramètre. Le mode de débogage de Flask expose un débogueur interactif qui permet l'exécution de code à distance.\n\n2. **Maintenez vos dépendances à jour :** le fichier `requirements.txt` fixe des versions spécifiques. Activez l'[analyse des dépendances](https://docs.gitlab.com/user/application_security/dependency_scanning/) de GitLab dans votre pipeline CI/CD pour surveiller les vulnérabilités.\n\n3. **Utilisez des variables d'environnement pour les identifiants :** ne codez jamais l'identifiant d'instance ni aucun jeton en dur dans le code source. Le fichier `.env.example` de la démo illustre cette bonne pratique.\n\n4. **L'identifiant d'instance est en lecture seule :** il ne peut que récupérer l'état des feature flags, pas le modifier. Traitez-le néanmoins comme un secret.\n\n\n## Synthèse\n\n\nCe tutoriel a couvert le cycle complet d'intégration des feature flags GitLab dans une application Python : création des feature flags avec les bonnes stratégies, récupération des identifiants Unleash, initialisation du SDK, évaluation locale des feature flags dans Flask et activation du comportement en temps réel sans redéploiement.\n\n\nL'ensemble de l'intégration nécessite une seule dépendance (`UnleashClient`), trois variables d'environnement et un unique appel de méthode (`is_enabled()`). Aucun serveur Unleash séparé, aucun jeton d'accès personnel, aucune infrastructure complexe.\n\n\nLes feature flags comptent parmi les outils les plus pratiques pour réduire les risques de déploiement. La possibilité de désactiver instantanément une fonctionnalité en échec, ou de la déployer progressivement d'un groupe d'utilisateurs ciblé à un pourcentage puis à l'ensemble des utilisateurs, sans toucher à un pipeline de déploiement, offre une valeur considérable avec une configuration minimale. Le [dépôt de démonstration](https://gitlab.com/omid-blogs/gitlab-feature-flags-demo) fournit une base fonctionnelle à dupliquer et adapter pour n'importe quel projet.\n\n\n## Ressources\n\n\n* [Projet de démonstration sur GitLab](https://gitlab.com/omid-blogs/gitlab-feature-flags-demo)\n\n* [Documentation sur les feature flags GitLab](https://docs.gitlab.com/operations/feature_flags/)\n\n* [SDK Unleash en Python sur GitHub](https://github.com/Unleash/unleash-python-sdk)\n\n* [SDK Unleash (tous les langages)](https://github.com/Unleash/unleash#unleash-sdks)",{"featured":11,"template":12,"slug":724},"getting-started-with-gitlab-feature-flags-in-python",{"content":726,"config":738},{"title":727,"description":728,"body":729,"category":9,"tags":730,"date":733,"authors":734,"heroImage":737},"GitLab + Amazon : l'orchestration de plateforme portée par une IA fiable","Associez GitLab Duo Agent Platform à Amazon Bedrock pour un développement logiciel agentique et une orchestration sécurisée.","Si votre équipe utilise GitLab et dispose d'une solide pratique AWS, la combinaison de GitLab Duo Agent Platform et d'Amazon Bedrock a été conçue pour vous. Le principe est simple : GitLab joue le rôle de couche d'orchestration pour accélérer l'ensemble de votre cycle de vie logiciel grâce à l'[IA agentique](https://about.gitlab.com/fr-fr/topics/agentic-ai/ \"Qu'est-ce que l'IA agentique ?\"), tandis qu'Amazon Bedrock fournit une couche de modèles de fondation sécurisée et conforme, avec l'inférence IA en arrière-plan.\n\nGitLab Duo Agent Platform vous permet de gérer la planification, les merge de pipelines, les scans de sécurité, la remédiation des vulnérabilités et bien plus encore dans le cadre de vos workflows GitLab, tandis que la passerelle d'IA de GitLab achemine les appels de modèles vers Amazon Bedrock (ou vers des points de terminaison gérés par GitLab et adossés à Bedrock, selon votre configuration). Vous pouvez ainsi vous appuyer sur les politiques de gestion des identités et des accès (IAM), les périmètres de cloud privé virtuel (VPC), les contrôles régionaux et les engagements de dépenses cloud que vous avez déjà définis dans AWS.\n\nSi vous utilisez déjà Amazon Bedrock et souhaitez que l'IA intervienne directement dans vos activités GitLab, et non dans un autre outil de chat autonome, cette combinaison est faite pour vous.\n\n\nDans cet article, nous abordons le problème concret auquel de nombreuses équipes sont confrontées aujourd'hui : l'IA est fragmentée, les flux de données sont flous et l'investissement dans Amazon Bedrock est sous-exploité lorsque l'IA se trouve en dehors du cycle de développement logiciel. \n\nNous détaillerons ensuite vos options de déploiement pour GitLab Duo Agent Platform :\n\n* Intégration avec des modèles auto-hébergés sur Amazon Bedrock pour les déploiements GitLab Self-Managed et la passerelle d'IA auto-hébergée\n* Intégration avec des modèles opérés par GitLab sur Amazon Bedrock (avec des clés appartenant à GitLab) pour les déploiements GitLab Self-Managed et la passerelle d'IA hébergée par GitLab\n* Intégration avec des modèles opérés par GitLab sur Amazon Bedrock (avec des clés appartenant à GitLab) pour les instances GitLab.com et la passerelle d'IA hébergée par GitLab\n\nEnfin, nous conclurons par un résumé expliquant comment cette approche permet d'éviter le Shadow AI et la multiplication d'outils spécialisés, sans créer de pile technologique parallèle dédiée à l'IA.\n\n## IA omniprésente, contrôle inexistant\n\nEn ce moment même, des équipes de développement au sein de votre entreprise utilisent peut-être un outil d'IA que votre équipe de sécurité n'a pas approuvé. Des données de prompt quittent peut-être votre environnement par un chemin que personne n'a entièrement cartographié. Et l'investissement de votre organisation dans Amazon Bedrock est peut-être sous-exploité, tandis que d'autres équipes financent séparément des outils d'IA, détournant ainsi les charges de travail et les dépenses cloud des plateformes auxquelles vous vous êtes déjà engagés.\n\nPlutôt qu'un problème humain, il s'agit peut-être d'un problème d'architecture. Et il fait ressortir les trois mêmes contraintes dans presque toutes les entreprises :\n\n**Fragmentation opérationnelle.** Chaque équipe, voire chaque développeur, choisit ses propres outils de développement, y compris les outils d'IA et les modèles. Cette fragmentation rend la gouvernance de bout en bout au sein du cycle de vie du développement logiciel quasiment impossible.\n\n**Sécurité et souveraineté.** Où circulent réellement les données de prompt et de code ? Qui est propriétaire des logs ?\n\n**Optimisation des dépenses cloud.** Les engagements envers des fournisseurs cloud majeurs comme AWS se diluent à mesure que les charges de travail et l'utilisation de l'IA migrent vers des outils ponctuels en dehors des accords existants des clients.\n\nGitLab Duo Agent Platform et Amazon Bedrock contribuent ensemble à résoudre ces problèmes. La répartition des responsabilités est claire : GitLab Duo Agent Platform prend en charge l'orchestration des workflows avec l'IA agentique pour le développement logiciel, Amazon Bedrock gère la couche d'inférence et héberge les modèles de fondation approuvés, et votre organisation conserve un contrôle total sur les périmètres de données et de politiques déjà définis dans AWS. Trois missions, trois responsables, aucune fragmentation.\n\n## GitLab Duo Agent Platform : le plan de contrôle agentique\n\nGitLab Duo Agent Platform est la couche d'IA agentique de GitLab : un framework d'agents et de flows spécialisés qui opèrent simultanément et en parallèle, dépassant les transferts traditionnels par étapes et contribuant à automatiser les tâches sur l'ensemble du cycle de vie logiciel. Plutôt qu'un assistant unique répondant à des prompts, GitLab Duo Agent Platform permet aux équipes d'orchestrer de nombreux agents d'IA de manière asynchrone, en s'appuyant sur des données unifiées et le contexte du projet, tickets, merge requests, pipelines et résultats de sécurité inclus. Les workflows linéaires se transforment en une collaboration coordonnée et continue entre les équipes de développement et leurs agents d'IA, à grande échelle.\n\nUne fois ce plan de contrôle mis en place, la question qui se pose naturellement est de savoir quelle infrastructure d'IA devrait alimenter ces agents. Pour les clients qui exécutent GitLab Self-Managed sur AWS et ont besoin que le trafic d'inférence, les données de prompt et les logs restent également dans leur environnement AWS avec leurs données de cycle de vie logiciel, Amazon Bedrock en tant que couche d'inférence IA est la solution idéale.\n\n## Amazon Bedrock : une base fiable pour l'IA\n\nAmazon Bedrock est une couche de modèles de fondation entièrement gérée et sans serveur, qui s'exécute intégralement dans votre environnement AWS. Les données clients restent dans leur compte AWS : les entrées et sorties sont chiffrées en transit et au repos, ne sont jamais partagées avec les fournisseurs de modèles et ne sont jamais utilisées pour entraîner des modèles de base. Amazon Bedrock est certifié pour la conformité RGPD, HIPAA et FedRAMP High, couvrant de nombreuses exigences des secteurs réglementés sans configuration supplémentaire. Les équipes peuvent également importer des modèles affinés depuis d'autres sources via Custom Model Import et les déployer aux côtés des modèles Amazon Bedrock natifs via la même infrastructure, sans gérer de pipelines de déploiement séparés. Bedrock Guardrails ajoute des protections configurables sur tous les modèles pour le filtrage de contenu, la détection des hallucinations et la protection des données sensibles.\n\nEnsemble, GitLab Duo Agent Platform et Amazon Bedrock consolident l'orchestration [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") et la gouvernance des modèles d'IA, contribuant à éliminer la fragmentation qui survient lorsque les équipes déploient des outils d'IA de manière indépendante.\n\n## Choisir votre modèle de déploiement\n\nL'intégration offre les mêmes fonctionnalités principales de GitLab Duo Agent Platform, quel que soit le mode de déploiement. Ce qui varie, c'est qui gère GitLab, qui opère la passerelle d'IA et dans quel compte Amazon Bedrock l'inférence s'exécute. Le bon modèle dépend de l'environnement dans lequel votre organisation opère déjà.\n\nÀ un niveau général, l'intégration comporte trois composants principaux :\n\n* **GitLab Duo Agent Platform :** workflows agentiques intégrés tout au long du cycle de vie du développement logiciel\n* **Passerelle d'IA (gérée par GitLab ou auto-hébergée) :** la couche d'abstraction entre GitLab Duo Agent Platform et le backend de modèles de fondation\n* **Amazon Bedrock :** le substrat de modèles d'IA et d'inférence\n\n![Déploiement de GitLab et AWS Bedrock](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776362365/udmvmv2efpmwtkxgydch.png)\n\nLe choix d'un modèle de déploiement est guidé par l'endroit où une organisation souhaite placer les leviers de contrôle. Les modèles présentés ci-dessous sont conçus pour s'adapter à la situation actuelle des équipes, qu'elles privilégient une approche SaaS, optent pour une gestion autonome à des fins de conformité ou misent entièrement sur AWS en tirant parti de leurs investissements existants dans Amazon Bedrock.\n\n| Modèle de déploiement | Instance GitLab.com avec passerelle d'IA hébergée par GitLab et modèles Amazon Bedrock opérés par GitLab | GitLab Self-Managed avec passerelle d'IA hébergée par GitLab et modèles Bedrock opérés par GitLab | GitLab Self-Managed avec passerelle d'IA auto-hébergée et modèles Bedrock opérés par le client |\n| :---- | :---- | :---- | :---- |\n| **Idéal si vous :** | Utilisez principalement GitLab.com et ne souhaitez pas auto-héberger la passerelle d'IA et les modèles Bedrock | Avez besoin de GitLab Self-Managed pour des raisons de conformité et opérationnelles, mais ne souhaitez pas gérer la couche d'IA | Êtes centré sur AWS avec une utilisation Bedrock existante et des besoins stricts en matière de données et de contrôle |\n| **Principaux avantages** | La solution la plus rapide et clé en main pour accéder aux workflows de GitLab Duo Agent Platform : GitLab gère GitLab.com, la passerelle d'IA, intégrée aux modèles d'IA Bedrock. | Conservez GitLab déployé dans votre propre environnement tout en consommant les modèles Bedrock via une passerelle d'IA gérée par GitLab, alliant contrôle du déploiement et simplification des opérations d'IA. | Exécutez GitLab et la passerelle d'IA dans votre compte AWS, réutilisez vos configurations IAM/VPC/régions existantes, conservez les logs et les données dans votre environnement, et imputez l'utilisation de Bedrock à vos engagements de dépenses AWS existants. |\n\n## Comment les clients utilisent GitLab Duo Agent Platform avec Amazon Bedrock\n\nLes équipes plateforme peuvent utiliser GitLab Duo Agent Platform avec Amazon Bedrock pour standardiser les modèles chargés des suggestions de code, de l'analyse de sécurité et de la remédiation des pipelines. Cela permet d'appliquer des garde-fous et une journalisation de manière centralisée, plutôt que de laisser chaque équipe adopter des outils séparés de façon indépendante.\n\nLes workflows de sécurité bénéficient d'avantages particuliers. Les agents de GitLab Duo Agent Platform peuvent proposer et valider des correctifs pour les résultats de sécurité au sein de GitLab, contribuant à réduire le travail de triage manuel que les développeurs devraient autrement effectuer en dehors de la plateforme.\n\nPour les entreprises déjà engagées envers AWS, le routage des charges de travail d'IA via Bedrock depuis GitLab vous permet de maintenir l'utilisation de l'IA par les développeurs en cohérence avec les accords cloud existants, plutôt que de générer des dépenses séparées et non planifiées.\n\n## En résumé\n\nLes contraintes qui freinent l'adoption de l'IA en entreprise ne sont souvent pas d'ordre technique, elles sont organisationnelles : fragmentation des outils, flux de données non gouvernés et dépenses cloud qui ne se consolident jamais. Ce sont ces problèmes qui peuvent bloquer les programmes d'IA même après la réussite des projets pilotes.\n\nGitLab Duo Agent Platform et Amazon Bedrock permettent de s'attaquer directement à chacun de ces problèmes. Les équipes plateforme bénéficient d'une gouvernance cohérente, d'une auditabilité et de chemins standardisés pour l'utilisation de l'IA tout au long du cycle de vie du développement logiciel. Les équipes de développement disposent de workflows agentiques rationalisés qui s'intègrent naturellement à GitLab. Et les organisations centrées sur AWS peuvent étendre leur investissement Bedrock existant plutôt que de construire une infrastructure d'IA parallèle.\n\nLe résultat est un programme d'IA qui évolue sans se fragmenter. Gouvernance et vélocité sur la même pile, au service des mêmes équipes, sous des politiques que l'organisation maîtrise déjà.\n\n\n> Pour déterminer quel modèle de déploiement convient à votre organisation et comment aligner GitLab Duo Agent Platform et Amazon Bedrock avec votre stratégie AWS existante, [contactez l'équipe commerciale de GitLab](https://about.gitlab.com/sales/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr), qui vous aidera à concevoir et à mettre en œuvre la meilleure architecture pour votre environnement. Vous pouvez également [consulter notre page partenaire AWS](https://about.gitlab.com/fr-fr/partners/technology-partners/aws/) pour en savoir plus.",[272,731,732],"AWS","AI/ML","2026-04-22",[735,736],"Joe Mann","Mark Kriaf","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776362275/ozbwn9tk0dditpnfddlz.png",{"featured":27,"template":12,"slug":739},"gitlab-amazon-platform-orchestration-on-a-trusted-ai-foundation",{"content":741,"config":751},{"title":742,"description":743,"authors":744,"heroImage":746,"date":747,"body":748,"category":9,"tags":749},"GitLab 18.11 : garde-fous budgétaires pour les GitLab Credits","Découvrez comment les plafonds de dépenses et les limites de crédits par utilisateur offrent aux organisations les garde-fous budgétaires nécessaires pour déployer GitLab Duo Agent Platform à grande échelle.",[745],"Bryan Rothwell","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1776259080/cakqnwo5ecp255lo8lzo.png","2026-04-17","Les équipes qui utilisent GitLab Duo Agent Platform avec des crédits GitLab à la demande livrent plus rapidement, détectent les bogues plus tôt et automatisent des tâches qui mobilisaient auparavant des sprints entiers. Mais à mesure que l'adoption progresse, les équipes finances, achats et plateforme exigent des preuves que les dépenses liées à l'IA sont encadrées, prévisibles et maîtrisables.\n\nL'un des principaux freins à une adoption plus large de l'IA n'est pas le scepticisme vis-à-vis de la technologie : c'est l'incertitude quant à la maîtrise des dépenses. Sans plafond budgétaire, un mois particulièrement chargé pourrait engendrer des dépenses imprévues. Sans limites par utilisateur, une poignée d'utilisateurs intensifs pourrait épuiser les crédits de l'équipe avant la fin du mois. Et sans aucun de ces mécanismes, les responsables techniques qui souhaitent étendre l'utilisation de l'IA agentique pour le développement logiciel doivent multiplier les démarches pour obtenir les validations budgétaires.\n\nDepuis sa [disponibilité générale](https://about.gitlab.com/fr-fr/blog/gitlab-duo-agent-platform-is-generally-available/), GitLab Duo Agent Platform offre des fonctionnalités de gouvernance et de visibilité sur l'utilisation. Avec GitLab 18.11, nous introduisons des contrôles d'utilisation pour [GitLab Credits](https://about.gitlab.com/fr-fr/blog/introducing-gitlab-credits/) : des plafonds de dépenses et des garde-fous budgétaires qui donnent à votre organisation encore plus de contrôle et de transparence sur la consommation des crédits.\n\n## Gestion de GitLab Credits\n\nGitLab 18.11 ajoute trois niveaux de contrôle sur la consommation des GitLab Credits : un plafond de dépenses au niveau de l'abonnement, des limites de crédits par utilisateur et une visibilité sur l'état et l'application des plafonds.\n\n### Plafond de dépenses au niveau de l'abonnement\n\nLes responsables de facturation peuvent désormais définir un plafond mensuel strict pour la consommation de crédits GitLab à la demande sur l'ensemble de leur abonnement.\n\nVoici comment cela fonctionne :\n\n* **Définissez un plafond** dans le `portail clients`, dans les paramètres de votre abonnement relatifs à GitLab Credits.\n\n* **Appliquez automatiquement les limites de dépenses.** Lorsque la consommation à la demande atteint le plafond, l'accès à GitLab Duo Agent Platform est suspendu pour tous les utilisateurs de l'abonnement jusqu'au début de la période mensuelle suivante.\n\n* **Ajustez en cours de route.** Augmentez ou désactivez le plafond en cours de mois pour rétablir l'accès.\n\nLe plafond se réinitialise à chaque période mensuelle et la limite configurée est reconduite automatiquement, sauf si vous la modifiez. Étant donné que les données d'utilisation sont synchronisées périodiquement plutôt qu'en temps réel, un léger dépassement peut survenir après que le plafond est atteint, avant que l'application ne prenne effet. Consultez la [documentation relative à GitLab Credits](https://docs.gitlab.com/subscriptions/gitlab_credits/) pour plus de détails.\n\n### Plafonds de dépenses par utilisateur\n\nIl est naturel que tous les utilisateurs ne consomment pas les crédits au même rythme. Mais lorsqu'un ou deux utilisateurs intensifs consomment une part disproportionnée du pool, le reste de l'équipe peut perdre son accès à l'IA avant la fin du mois.\n\nLes plafonds de crédits par utilisateur empêchent qu'un seul utilisateur consomme plus que la part qui lui est allouée :\n\n* **Plafond forfaitaire par utilisateur.** Définissez une limite de crédits forfaitaire qui s'applique de manière égale à chaque utilisateur de l'abonnement via l'API GraphQL de GitLab. Contrairement au plafond au niveau de l'abonnement, le plafond par utilisateur s'applique à la consommation totale d'un utilisateur, toutes sources de crédits confondues.\n\n* **Limites personnalisées par utilisateur.** Pour les organisations qui ont besoin de limites différenciées, vous pouvez définir des plafonds de crédits individuels pour des utilisateurs spécifiques via l'API GraphQL. Par exemple, vous pourriez accorder une allocation plus élevée à vos staff engineers tout en appliquant une limite standard au reste de l'équipe.\n\n* **Application individuelle.** Lorsqu'un utilisateur atteint son plafond, il conserve un accès complet à GitLab. Seule sa consommation de crédits GitLab Duo Agent Platform est suspendue jusqu'au prochain cycle de facturation. Tous les autres membres de l'équipe continuent à travailler sans interruption jusqu'à atteindre leur propre limite ou le plafond au niveau de l'abonnement, selon la première éventualité.\n\n### Visibilité et notifications\n\nLorsqu'un plafond au niveau de l'abonnement est atteint, GitLab envoie une notification par e-mail aux responsables de facturation afin qu'ils puissent agir : augmenter le plafond, attendre la période suivante ou redistribuer les crédits.\n\nDans GitLab, les propriétaires de groupe (GitLab.com) et les administrateurs d'instance (GitLab Self-Managed) peuvent consulter les utilisateurs bloqués en raison de l'atteinte de leur plafond par utilisateur et rétablir l'accès en ajustant le plafond via l'API GraphQL.\n\n## Comment les garde-fous budgétaires aident les organisations à déployer l'IA à grande échelle\n\nLes garde-fous sont essentiels à mesure que les organisations accélèrent leur adoption de l'IA. Voici pourquoi :\n\n### Des budgets d'IA prévisibles\n\nLes contrôles d'utilisation de GitLab Duo Agent Platform transforment l'IA en un poste budgétaire encadré et prévisible grâce aux crédits GitLab à la demande. Il devient ainsi plus facile de déployer des agents sur l'ensemble du cycle de développement logiciel, d'obtenir la validation des équipes financières, de justifier les renouvellements et de planifier les dépenses trimestrielles.\n\n### Gouvernance et refacturation interne\n\nLes grandes organisations doivent souvent aligner la consommation d'IA sur leurs budgets internes, centres de coûts ou politiques de départements. Les plafonds par utilisateur offrent aux équipes plateforme un mécanisme simple pour répartir les crédits équitablement et suivre la consommation au niveau individuel. Les options d'importation par API facilitent la gestion des plafonds à l'échelle de l'entreprise. En combinant les plafonds par utilisateur aux données d'utilisation par utilisateur du tableau de bord GitLab Credits, les organisations peuvent analyser les tendances de consommation pour alimenter leurs propres processus de refacturation interne ou d'allocation budgétaire.\n\n### La confiance pour passer à l'échelle\n\nDe nombreux clients commencent à utiliser GitLab Duo Agent Platform avec un petit groupe pilote. Les contrôles d'utilisation éliminent les risques associés à l'extension de ce pilote à l'ensemble de l'organisation. Vous pouvez déployer GitLab Duo Agent Platform auprès de centaines, voire de milliers de développeurs, en sachant qu'un plafond strict protège votre budget. Si la consommation augmente plus vite que prévu, vous atteindrez le plafond, sans facture inattendue.\n\n## Dépasser le dilemme de la tarification par siège et du manque de visibilité\n\nDe nombreux outils de programmation assistée par l'IA adoptent une approche par siège pour la gestion des coûts. Vous achetez un nombre fixe de sièges à un prix forfaitaire par utilisateur, et c'est votre budget. L'approche est simple, mais rigide. Vous payez le même montant, qu'un développeur utilise l'outil dix fois par jour ou n'y touche jamais. Et à mesure que les éditeurs introduisent des modèles premium et des dépassements basés sur l'utilisation en plus de la tarification par siège, la prévisibilité des coûts promise par ce modèle commence à s'éroder.\n\nGitLab adopte une approche différente : une tarification à l'usage avec des plafonds stricts et un tableau de bord de gouvernance unifié. Vous profitez d'une véritable flexibilité : vous ne payez que ce que vos équipes consomment réellement et pouvez prévoir un budget grâce aux limites de dépenses appliquées automatiquement.\n\n## Exemples concrets de contrôles d'utilisation\n\n**Prenons l'exemple d'une entreprise cliente SaaS de taille moyenne qui souhaite respecter son budget mensuel.** Une entreprise d'ingénierie de 200 personnes définit un plafond au niveau de l'abonnement correspondant à sa consommation à la demande prévue. Le VP Engineering peut affirmer avec certitude aux équipes financières que les dépenses liées à GitLab Duo Agent Platform ne dépasseront jamais le montant approuvé, même lors de l'intégration de nouvelles équipes. Si l'organisation approche du plafond en cours de mois, le responsable de facturation reçoit une notification et peut décider d'augmenter la limite ou d'attendre la période suivante.\n\n**Chez GitLab, nous travaillons également avec de grandes entreprises qui souhaitent garantir une utilisation équitable entre les équipes.** Une société de services financiers internationale comptant 2 000 développeurs utilise les plafonds par utilisateur pour assurer un accès équitable. Les ingénieurs seniors travaillant sur des projets de refactorisation complexes bénéficient d'une allocation individuelle plus élevée via l'API, tandis que la majorité des développeurs profite d'un plafond forfaitaire standard. Aucun utilisateur ne peut épuiser le pool à lui seul, et l'équipe plateforme utilise les données d'utilisation par utilisateur du tableau de bord GitLab Credits pour analyser les tendances de consommation et concevoir la planification budgétaire trimestrielle.\n\n## Premiers pas\n\nLes contrôles d'utilisation sont disponibles pour les clients GitLab.com et GitLab Self-Managed dès la version GitLab 18.11. Les contrôles sont configurés à différents emplacements selon la portée et votre rôle.\n\n**Plafond au niveau de l'abonnement**\n\nLes responsables de facturation définissent le plafond à la demande au niveau de l'abonnement dans le portail client :\n\n1. Connectez-vous au `Portail clients`.\n\n2. Sur la carte de votre abonnement, accédez aux paramètres de **GitLab Credits**.\n\n3. Activez le plafond mensuel de crédits à la demande et saisissez la limite souhaitée.\n\n**Plafond forfaitaire par utilisateur**\n\nLe plafond forfaitaire par utilisateur peut être défini via l'API GraphQL de GitLab par les propriétaires d'espace de nommage (GitLab.com) ou les administrateurs d'instance (GitLab Self-Managed). Consultez la [documentation relative à GitLab Credits](https://docs.gitlab.com/subscriptions/gitlab_credits/) pour les dernières informations sur les interfaces de configuration disponibles.\n\n**Limites personnalisées par utilisateur**\n\nPour des limites différenciées, les propriétaires d'espace de nommage (GitLab.com) et les administrateurs d'instance (Self-Managed) peuvent définir des plafonds individuels par programmation. Cette option est particulièrement utile pour les workflows d'automatisation et d'Infrastructure as Code.\n\n**Suivi de l'utilisation et de l'état des plafonds**\n\n* **Portail client :** consultez l'utilisation détaillée et l'état des plafonds.\n\n* **GitLab.com :** les propriétaires de groupe peuvent consulter les utilisateurs bloqués sous **Paramètres > GitLab Credits**.\n\n* **GitLab Self-Managed :** les administrateurs d'instance peuvent consulter l'état des plafonds et les utilisateurs bloqués sous **Admin > GitLab Credits**.\n\n## GitLab Duo Agent Platform est prêt à passer à l'échelle\n\nLes contrôles d'utilisation sont disponibles dès maintenant dans GitLab 18.11. Si vous attendiez les bons garde-fous avant de déployer GitLab Duo Agent Platform à l'échelle de votre organisation, c'est le moment. Définissez vos plafonds, déployez GitLab Duo Agent Platform auprès de davantage d'équipes et accélérez vos livraisons !\n\n> [En savoir plus sur GitLab Credits et les contrôles d'utilisation](https://docs.gitlab.com/subscriptions/gitlab_credits/).",[9,732,750],"news",{"featured":11,"template":12,"slug":752},"gitlab-18-11-budget-guardrails-for-gitlab-credits",{"promotions":754},[755,769,780,792],{"id":756,"categories":757,"header":759,"text":760,"button":761,"image":766},"ai-modernization",[758],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":762,"config":763},"Get your AI maturity score",{"href":764,"dataGaName":765,"dataGaLocation":239},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":767},{"src":768},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":770,"categories":771,"header":772,"text":760,"button":773,"image":777},"devops-modernization",[9,565],"Are you just managing tools or shipping innovation?",{"text":774,"config":775},"Get your DevOps maturity score",{"href":776,"dataGaName":765,"dataGaLocation":239},"/assessments/devops-modernization-assessment/",{"config":778},{"src":779},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":781,"categories":782,"header":784,"text":760,"button":785,"image":789},"security-modernization",[783],"security","Are you trading speed for security?",{"text":786,"config":787},"Get your security maturity score",{"href":788,"dataGaName":765,"dataGaLocation":239},"/assessments/security-modernization-assessment/",{"config":790},{"src":791},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":793,"paths":794,"header":797,"text":798,"button":799,"image":804},"github-azure-migration",[795,796],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":800,"config":801},"See how GitLab compares to GitHub",{"href":802,"dataGaName":803,"dataGaLocation":239},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":805},{"src":779},{"header":807,"blurb":808,"button":809,"secondaryButton":813},"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":810},{"href":811,"dataGaName":45,"dataGaLocation":812},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/fr-fr/","feature",{"text":47,"config":814},{"href":49,"dataGaName":50,"dataGaLocation":812},1777379613202]