[{"data":1,"prerenderedAt":817},["ShallowReactive",2],{"/fr-fr/blog/jenkins-to-gitlab-migration-made-easy":3,"navigation-fr-fr":40,"banner-fr-fr":455,"footer-fr-fr":465,"blog-post-authors-fr-fr-Fernando Diaz":700,"blog-related-posts-fr-fr-jenkins-to-gitlab-migration-made-easy":714,"blog-promotions-fr-fr":755,"next-steps-fr-fr":808},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":20,"description":17,"extension":25,"externalUrl":26,"featured":14,"heroImage":19,"isFeatured":14,"meta":27,"navigation":14,"path":28,"publishedDate":20,"rawbody":29,"seo":30,"slug":13,"stem":35,"tagSlugs":36,"tags":38,"template":15,"updatedDate":24,"__hash__":39},"blogPosts/fr-fr/blog/jenkins-to-gitlab-migration-made-easy.yml","Migrer de Jenkins vers GitLab : le guide complet",[7],"fernando-diaz",[9],"Fernando Diaz","GitLab est la plateforme DevSecOps alimentée par l'IA la plus complète. En effet, GitLab fournit toutes les fonctionnalités dont vous avez besoin pour planifier, développer et livrer des logiciels sécurisés plus rapidement, le tout au sein d'une seule et même plateforme.\nLes plateformes comme GitLab éliminent les difficultés et les défis liés à l'intégration de multiples outils (approche DevOps DIY) pour gérer au mieux le cycle de vie du développement logiciel (SDLC). À l'inverse, Jenkins n'étant pas une plateforme, des outils supplémentaires sont nécessaires pour compléter le SDLC. Cette approche DevOps DIY introduit une complexité supplémentaire liée à la chaîne d'outils, et génère un certain nombre d'inconvénients comme :\n- La nécessité d'une assistance personnalisée pour l'intégration et l'orchestration des outils\n- La difficulté à tenir à jour/mettre à niveau/sécuriser des outils disparates\n- L'impossibilité de mesurer correctement la transformation organisationnelle\n- Une mauvaise expérience des équipes de développement - Des coûts supplémentaires en lien avec la gestion, les délais et le budget\n- Une perte de productivité\n- Un changement de contexte et une inefficacité en terme de collaboration\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175993/Blog/ikr97sr9jclddeqdg7ew.png\" alt=\"Import project selection\">\n   \u003Cfigcaption>DevOps DIY versus plateforme DevSecOps\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nPour ces raisons, de nombreuses équipes de développement utilisant Jenkins envisagent de migrer vers une plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que l'approche DevSecOps ?\") complète. Si vous recherchez une plateforme puissante, fiable et sécurisée, GitLab est votre meilleure option ! GitLab propose une version gratuite ainsi que différents niveaux d'abonnement en fonction des besoins de votre entreprise. Pour en savoir plus sur nos offres et fonctionnalités, consultez notre [page tarifaire](https://about.gitlab.com/fr-fr/pricing/).\n\nDécouvrez dans cet article de blog :\n- Comment planifier une migration\n- Comment migrer des dépôts depuis d'autres outils de gestion du code source (SCM) vers GitLab\n- Comment migrer des pipelines CI/CD de Jenkins vers GitLab\n\n## Comment planifier une migration de Jenkins vers GitLab ?\nAvant d'initier la migration de vos dépôts hébergés sur un autre outil vers GitLab CI/CD, vous devez élaborer un plan de migration. Cette étape technique est importante et vous permet de définir clairement vos attentes. Les outils CI/CD diffèrent par leur approche, leur structure et leurs spécificités techniques. Par conséquent, les migrations ne sont pas de simples transferts directs des données.\nUn plan de migration offre les avantages suivants :\n- Il définit et communique une vision claire de vos objectifs de migration, ce qui aide les personnes impliquées à comprendre le but de cette opération. - Il vous permet de vous assurer d’obtenir l'aval des équipes de direction concernées pour faciliter cette démarche.\n- Il permet d'expliquer aux utilisateurs les changements à venir.\n- Il permet de trouver des moyens de séquencer ou de retarder certaines étapes de la migration pour éviter l'échec de la migration ou une migration partielle.\n- Il documente les avantages des améliorations apportées par GitLab CI/CD et met à jour votre mise en œuvre à chaque étape de la migration.\n\nUn plan de migration vous aide à mettre en place un processus fluide permettant de migrer progressivement vers GitLab, avec un minimum de perturbations. Il peut s'agir d’exécuter simultanément Jenkins et GitLab, tandis que certains projets sont transférés de Jenkins vers GitLab.\n\n### Définissez un processus de gestion du changement\n\nIl se peut que les développeurs, opérateurs informatiques, administrateurs cloud, équipes en charge de la sécurité, ainsi que les ingénieurs qualité n'aient pas d'expérience avec GitLab et ne sachent pas pourquoi vous ou votre équipe de direction avez choisi de réaliser cette migration. C'est pourquoi votre plan de migration doit inclure un processus efficace de gestion du changement.\nLes personnes impactées par cette migration doivent savoir :\n- __Pourquoi__ ce changement est nécessaire\n- __À quoi__ ressemblera le futur système\n- __Comment__ l'entreprise prévoit d'atteindre cet objectif\n- __Vers qui__ se tourner pour obtenir plus d'informations ou de l'aide\nÀ cette fin, vous devez réaliser les étapes suivantes afin de gérer efficacement le changement au sein des différentes équipes fonctionnelles : - __Analysez l'état actuel__ : documentez les processus existants. Collectez des indicateurs qui serviront de base de référence. Identifiez ce qui fonctionne ou non avec l'[approche CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") en interrogeant certains membres de votre équipe. Documentez les défis que vous devez relever, et ce d'un point de vue quantitatif et qualitatif. Comme vous allez devoir expliquer les raisons de ce changement et votre vision, plus vous définirez clairement les problématiques que vous espérez résoudre, plus il vous sera facile d'obtenir l'adhésion de tous. - __Établissez une vision__ : maintenant que vous avez décrit les points de friction actuels quantitativement avec des indicateurs de référence et qualitativement (en vous basant sur les retours des membres de votre équipe), communiquez une vision de l'état futur. Expliquez pourquoi c'est important (en vous référant aux indicateurs de réussite de votre entreprise) et partagez l’état actuel de la situation et les résultats attendus. Renforcez ce message par le biais de différents canaux de communication : groupes de discussion, réunions rassemblant l'ensemble des acteurs de l'entreprise, ou encore notifications par e-mail.\n- __Formez les collaborateurs__ : investissez dans une [formation sur GitLab CI/CD](https://university.gitlab.com/pages/ci-cd-training/) dispensée par un expert GitLab. Mesurez l'acquisition et la mémorisation des connaissances à l'aide des [certifications GitLab](https://levelup.gitlab.com/pages/certifications). - __Communiquez la roadmap et les ressources__ : partagez avec les membres de votre équipe le calendrier prévu de la migration et les ressources mises à leur disposition pour faciliter la transition. Mentionnez également les ressources communautaires (groupes de discussion, forums), afin que votre équipe puisse poser des questions et obtenir de l'aide. Créez un système qui récompense les équipes qui effectuent rapidement cette transition, et encouragez-les à partager leur expérience avec d'autres équipes similaires au sein de l'entreprise.\n\nSi vous mettez en place ces éléments dès le début de cette transition, cela sera de bon augure pour la réussite de votre migration.\n### Définissez des objectifs de migration\n\nAvant d'effectuer votre migration, vous devez avoir une bonne compréhension de vos objectifs et de la façon de les atteindre. Voici par exemple certaines des questions auxquelles vous devez pouvoir répondre :\n\n- Quel est votre calendrier de migration ?\n- Quelle est la configuration actuelle de votre serveur Jenkins ?\n- Combien de projets sont concernés par la migration ?\n- Quel est le degré de complexité de votre pipeline ?\n- Nécessite-t-il des dépendances externes, plusieurs déclencheurs pour s'exécuter, exécute-t-il plusieurs processus en parallèle pour compiler le code, etc. ?\n- Comment/où déployez-vous votre code ?\n- Quel est le processus de revue/sortie des nouvelles versions et de déploiement du code ?\n- Est-il intégré dans Jenkins ou dans un workflow distinct déclenché par Jenkins ?\n- Quels artefacts de compilation ou binaires sont nécessaires au succès du pipeline ?\n- Quels plug-ins sont utilisés par les jobs dans Jenkins aujourd'hui ?\n- Quel logiciel est installé sur les agents Jenkins ?\n- Quelle solution de gestion du code source (SCM) utilisez-vous actuellement ?\n- Utilisez-vous des bibliothèques partagées dans vos jobs Jenkins ?\n- Quelle méthode d'authentification est utilisée pour Jenkins (Basic Authentication, LDAP/AD, SSO) ?\n- Y a-t-il d'autres projets auxquels vous devez accéder depuis votre pipeline ?\n- Des identifiants de connexion dans Jenkins sont-ils utilisés pour accéder à des services externes ?\n\nEn répondant à ces questions, vous saurez comment procéder à la migration, combien de temps durera cette opération et par où commencer. Une fois que vous avez élaboré un plan et que vous êtes conscient des attentes et des écueils possibles, vous pouvez commencer votre processus de migration.\n\n## Prérequis à la migration\n\nUne fois que vous avez créé votre plan de migration et répondu à toutes les attentes associées, vous pouvez commencer à configurer GitLab.\nVoici certains des prérequis suggérés pour la migration :\n- Familiarisez-vous avec GitLab et découvrez les [fonctionnalités clés de GitLab CI/CD](https://docs.gitlab.com/ci/).\n- Suivez des tutoriels pour créer votre premier [pipeline GitLab](https://docs.gitlab.com/ci/quick_start/) et des [pipelines plus complexes](https://docs.gitlab.com/ci/quick_start/tutorial/) qui créent, testent et déploient un site statique.\n- Passez en revue la [liste des mots-clés de configuration .gitlab-ci.yml](https://docs.gitlab.com/ci/yaml/).\n- Configurez GitLab.\n- Testez votre instance GitLab.\n\nUne fois que vous avez compris le fonctionnement de GitLab et qu'une instance a été configurée, vous pouvez suivre votre plan de migration et commencer à déplacer des projets de Jenkins vers GitLab. Vérifiez que votre instance GitLab a été correctement configurée à l'aide des bonnes pratiques et des [architectures de référence](https://docs.gitlab.com/administration/reference_architecture/ s/) de GitLab.\n\n### Migrez vos dépôts vers GitLab\nL'un des principaux inconvénients de Jenkins est qu'il ne fournit pas de solution SCM. Si vous utilisez Jenkins, votre code doit être stocké dans une solution SCM distincte à laquelle Jenkins doit avoir accès. Comme GitLab dispose d'un SCM intégré, la migration depuis Jenkins vous permet également de migrer depuis la solution SCM que vous utilisiez, ce qui entraîne une réduction supplémentaire des coûts.\n\nGitLab fournit des outils pour vous permettre de déplacer facilement votre dépôt et ses métadonnées dans GitLab. Les outils d'importation suivants sont inclus et vous aideront à migrer vos projets vers GitLab :\n\n- [GitHub](https://docs.gitlab.com/user/project/import/github/)\n- [Autre instance GitLab](https://docs.gitlab.com/user/project/settings/import_export/)\n- [Bitbucket Cloud](https://docs.gitlab.com/user/project/import/bitbucket/)\n- [Bitbucket Server](https://docs.gitlab.com/user/project/import/bitbucket_server.htm/ l)\n- [FogBugz](https://docs.gitlab.com/user/project/import/fogbugz/)\n- [Gitea](https://docs.gitlab.com/user/project/import/gitea/)\n- [Jira (Tickets uniquement)](https://docs.gitlab.com/user/project/import/jira/)\n- [Dépôt par fichier manifeste](https://docs.gitlab.com/user/project/import/manifest/)\n- [Dépôt par URL](https://docs.gitlab.com/user/project/import/repo_by_url/)\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176002/Blog/ie2xrexhbcoq6m8rnhit.png\" alt=\"GitHub to GitLab Repo Exporter\">\n   \u003Cfigcaption>Outil d'exportation de dépôt de GitHub vers GitLab\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nChaque outil d'importation importe différentes données d'un projet. Lisez notre [documentation sur l'importation et la migration de projets](https://docs.gitlab.com/user/project/import/) pour en savoir plus sur les outils d'importation fournis et comprendre quelles données sont migrées vers GitLab. De plus, vous pouvez [automatiser l'importation de groupes et de projets](https://docs.gitlab.com/user/project/import/#automate-group-and-project-import) et créer une solution personnalisée pour mieux répondre aux besoins de votre entreprise :\n\n- [Services professionnels](https://about.gitlab.com/services/)\n- [Services de migration](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/docs/using-congregate.md#quick-start)\n- [Foire aux questions sur la migration](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/famq.md)\n\n#### Comment migrer un dépôt ?\nLa migration d'un dépôt vers GitLab est facile grâce à nos outils d'importation intégrés. Dans cet exemple, nous allons vous expliquer comment copier un dépôt de GitHub vers GitLab ainsi que [ses ressources](https://docs.gitlab.com/user/project/import/github/#imported-data) (tickets, pull requests, jalons et plus encore).\nAfin de migrer un dépôt depuis GitHub vers GitLab, vous pouvez suivre les étapes ci-dessous :\n\n1. Dans la barre latérale de gauche, en haut, sélectionnez **Créer un nouveau (+)**.\n2. Sélectionnez **Nouveau projet/dépôt**.\n3. Sélectionnez **Importer un projet**.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176017/Blog/boowmmaqhbredxa3g92s.png\" alt=\"Import project selection\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n4. Cliquez sur le bouton **GitHub**.\n    - Si vous utilisez GitLab Self-Managed, vous devez [activer l'outil d'importation GitHub](https://docs.gitlab.com/administration/settings/import_and_expor/ t_settings.html#configure-allowed-import-sources).\n    - Notez que d'autres outils d'importation peuvent être lancés de la même manière.\n5. Vous pouvez ensuite utiliser l'une des deux options ci-dessous :\n    - Autoriser OAuth de GitHub en sélectionnant **Autoriser avec GitHub**.\n    - Utiliser un jeton d'accès personnel GitHub :\n       - Accédez à la page [https://github.com/settings/tokens/new](https://github.com/settings/tokens/new).\n       - Dans le champ **Note**, saisissez une description du token.\n       - Sélectionnez la portée du dépôt.\n       - En option, pour importer des collaborateurs, sélectionnez la portée **read:org**.\n       - Cliquez sur le bouton **Générer un token**.\n       - Sur la page d'importation de GitLab, dans le champ **Jeton d'accès personnel**, collez le jeton d'accès personnel GitHub.\n6. Cliquez sur le bouton **Authentification**.\n7. Sélectionnez les éléments que vous souhaitez migrer.\n8. Sélectionnez les projets que vous souhaitez migrer et leur destination.\n9. Cliquez sur le bouton **Importer**.\n\nLe projet importé devrait maintenant être disponible dans votre espace de travail. Pour en savoir plus sur la migration de GitHub vers GitLab, regardez cette vidéo :\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=TQ5HI9aMwtzJMiMi\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nUne fois que vous avez terminé la migration de votre dépôt, vous pouvez configurer votre pipeline Jenkins pour exploiter le fichier Jenkinsfile dans GitLab. Pour ce faire, définissez l'URL du dépôt sur le projet que vous venez tout juste d'importer via le menu de configuration du pipeline Jenkins :\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176020/Blog/mu475liw66abcxbu2g6g.png\" alt=\"Jenkins Pipeline SCM settings\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nCette opération est utile pendant la phase de migration initiale du dépôt et vous permet d'utiliser Jenkins et GitLab en parallèle. Vous évitez ainsi toute interruption de service pendant que vous travaillez sur votre migration.\n\nDe plus, vous pouvez utiliser le [plug-in Jenkins GitLab](https://plugins.jenkins.io/gitlab-plugin/) pour faciliter la migration. Ce plug-in permet à GitLab de déclencher et d'obtenir le statut des compilations Jenkins.\n\n### Migrez vos pipelines CI/CD\nUne fois que vous avez migré vos dépôts vers GitLab, vous pouvez procéder à la migration de vos pipelines Jenkins. Bien qu'assez simple, ce processus nécessite une bonne compréhension des concepts et de la syntaxe Jenkins et GitLab.\n\nJenkins fournit deux types de syntaxe pour la définition des pipelines : une syntaxe déclarative et une syntaxe scriptée. Dans ce guide, nous décrirons la migration à partir des pipelines déclaratifs, car ils sont les plus couramment utilisés.\n\n#### Migrez votre pipeline étape par étape\n\nDans ce tutoriel, nous analyserons un fichier Jenkinsfile (Groovy) ainsi qu'un fichier de configuration GitLab CI/CD (YAML) qui compile, teste et déploie un microservice écrit en Golang. Nous activerons ensuite le pipeline dans GitLab et observerons le résultat.\nLe pipeline :\n- Utilisera l'image de conteneur Golang avec le tag **alpine**\n- Exécutera un job pour compiler le code Golang en un fichier binaire exécutable\n   - Stockera le fichier exécutable compilé en tant qu'artefact\n- Exécutera un job pour lancer les tests unitaires\n- Exécutera un job pour effectuer le déploiement sur l'environnement de préproduction\n   - Ne s'exécutera que si la validation cible la branche de **préproduction**\n   - S'exécutera uniquement après la réussite de l'étape de **test**\n   - Utilisera l'artefact exécutable compilé du job précédent\n\nVous trouverez ci-dessous les définitions de pipeline Jenkins et GitLab accompagnées de commentaires descriptifs. Vous pouvez observer le pipeline en action dans le [projet de migration Meow](https://gitlab.com/gitlab-da/projects/blogs/meow-migration).\n\nVoici un fichier Jenkinsfile écrit en Groovy :\n\n```text\n// The top-level of the declarative\n// pipeline.\npipeline {\n\n  // Defines the default agent to use\n  // when it is not explicitly defined\n  // in a job.\n    agent any\n\n  // Defines the stages that will run\n  // in numerical order. Each stage\n  // only runs one job.\n    stages {\n\n    // Defines the name of the stage\n        stage('build') {\n      // Defines the container image to\n      // use for this job, overwriting\n      // the default 'agent any'.\n      // The Jenkins Docker plugin\n      // must be configured for this\n      // to run.\n            agent { docker 'golang:alpine' }\n\n      // Defines the sequence of steps\n      // to execute when the stage is\n      // run.\n            steps {\n                sh 'go build -o bin/meow-micro'\n                sh 'chmod +x bin/meow-micro'\n            }\n\n      // The steps to run after the\n      // stage completes.\n            post {\n              always {\n\n        // Stores the stage artifacts\n        // generated for use in another\n        // job.\n                archiveArtifacts artifacts: 'bin/meow-micro'\n                onlyIfSuccessful: true\n              }\n            }\n        }\n\n    stage('test') {\n            agent { docker 'golang:alpine' }\n            steps {\n                sh 'go test .'\n            }\n        }\n\n        stage('deploy') {\n      // Defines conditions which must\n      // be met in order for the job to\n      // execute. In this case the\n      // deploy job will only run on the       // staging branch.\n            when {\n              branch 'staging'\n            }\n            steps {\n                echo 'Deploying meow-micro to staging'\n        // Uses the artifact stored in\n        // the build stage.\n                sh './bin/meow-micro'\n            }\n        }\n    }\n}\n```\n\nVoyons maintenant comment créer la même fonctionnalité dans GitLab :\n\n```text\n# Defines the default image to use\n# when it is not explicitly defined in\n# a job.\ndefault:\n  image: alpine:latest\n\n# Defines the order to run the stages.\n# Each stage can have multiple jobs.\nstages:\n  - build\n  - test\n  - deploy\n\n# Defines the name of the job\ncreate-binary:\n # Defines the stage the job will run in\n  stage: build\n # Defines the container image to use\n # for this job, overwriting default.\n  image: golang:alpine\n # Defines the sequence of steps to\n # execute when the job is run.\n  script:\n    - go build -o bin/meow-micro\n    - chmod +x bin/meow-micro\n # Stores the job artifacts generated\n # for use in another job.\n  artifacts:\n    paths:\n      - bin/meow-micro\n    expire_in: 1 week\n\nunit-tests:\n  stage: test\n  image: golang:alpine\n  script:\n    - go test .\n # Defines commands to run after the\n # job.\n after_script:\n  - echo \"Tests Complete\"\n\nstaging-deploy:\n  stage: deploy\n # Defines commands to run before the\n # actual job.\n  before_script:\n    - apk update\n  script:\n    - echo \"Deploying meow-micro to staging environment\"\n    - ./bin/meow-micro\n # Defines conditions which must be met\n # in order for this job to execute. In\n # this case the staging-deploy job will  # only run on the staging branch.\n  rules:\n    - if: $CI_COMMIT_BRANCH == 'staging'\n # Allows the artifact stored in the\n # build job to be used in this job.\n  artifacts:\n    paths:\n      - bin/meow-micro\n```\n\nComme vous l'avez peut-être remarqué, il existe de nombreuses similitudes entre Jenkins et GitLab en termes de syntaxe, ce qui simplifie la migration du pipeline. Bien que l'exemple ci-dessus fournisse une vue d'ensemble basique, assurez-vous de consulter la liste complète des [comparaisons de fonctionnalités et de concepts](https://docs.gitlab.com/ci/migration/jenkins/#comparison-of-features-and-concepts) entre les deux outils.\n\nMaintenant que nous comprenons comment transposer Jenkins à GitLab, nous pouvons commencer à créer un pipeline avec les mêmes fonctionnalités dans GitLab. Pour effectuer la migration de votre [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), suivez les étapes suivantes :\n\n##### 1. Ouvrez le dépôt que vous avez migré vers GitLab dans la section ci-dessus.\n- Dans la barre latérale de gauche, en haut, sélectionnez **Rechercher ou accéder à...**\n- Localisez votre projet.\n\n##### 2. Ouvrez l'[éditeur de pipeline](https://docs.gitlab.com/ci/pipeline_editor/).\n- Dans la barre latérale de gauche, sélectionnez **Compilation > Éditeur de pipeline**.\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176026/Blog/ecp4jh7epho2oxuegaor.png\" alt=\"Pipeline editor menu\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n- Cliquez sur le bouton **Configurer le pipeline**.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176029/Blog/nypfh01zhwgvzqc0xz3v.png\" alt=\"Configure pipeline selection\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n##### 3. Complétez le fichier [.gitlab-ci.yml](https://docs.gitlab.com/ci/yaml/).\n- Ajoutez le code du pipeline GitLab CI. \u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176031/Blog/nxi6uxxispyyoiiyvxyg.png\" alt=\"Pipeline editor input\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n- Vérifiez que la syntaxe est correcte.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176037/Blog/x3d4utfsnymye0lvphtf.png\" alt=\"Pipeline syntax validation\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n- Visualisez le pipeline.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176043/Blog/hipzofpyywjxf62edzfv.png\" alt=\"Pipeline visualization\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n##### 4. Validez le fichier dans la branche principale.\n- Ajoutez un message de validation.\n- Assurez-vous que la branche est définie sur la branche principale.\n- Cliquez sur le bouton __Valider les modifications__.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176048/Blog/nn8bl7rdysabccoycfrk.png\" alt=\"Commit changes dialog\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nUne fois le fichier fusionné, le pipeline défini s'exécute. Vous pouvez revenir à votre projet et [observer le pipeline](https://docs.gitlab.com/ci/pipelines/#view-pipelines) en action en le sélectionnant sur la page **Compilation > Pipelines** de votre projet. Comme il a été exécuté sur la branche **principale**, vous ne verrez que les jobs **create-binary** et **unit-tests**. Le job **staging-deploy** s'exécute uniquement sur la branche de préproduction.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176051/Blog/wfb4k8nkzpg28kpf2pzz.png\" alt=\"Pipeline running on main branch\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nSi nous créons une branche de préproduction, le pipeline suivant s'exécute.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176053/Blog/e2jxedpolaniotgixpby.png\" alt=\"Pipeline running on staging branch\">\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nEn cliquant sur un job, nous pouvons voir la sortie associée :  \n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176056/Blog/fywzwbzkwcvc9zzakilh.png\" alt=\"create-binary job output\">\n   \u003Cfigcaption>Sortie du job create-binary\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176061/Blog/ekmpd8ecanwwiena9xi9.png\" alt=\"unit-tests job output input\">\n   \u003Cfigcaption>Entrée/sortie du job unit-tests\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176065/Blog/h7nqxszy50xdmnvhalfq.png\" alt=\"staging-deploy job output\">\n   \u003Cfigcaption>Sortie du job staging-deploy\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nL'artefact est stocké dans le job __create-binary__ et utilisé dans le job __staging-deploy__. Et voilà, la migration d'un pipeline de Jenkins vers GitLab est aussi simple que cela !\n\n### Autres conseils à suivre lors de la migration\nVoici quelques conseils pratiques pour simplifier le processus de déploiement :\n\n- N'essayez pas de répliquer les tâches dans des jobs GitLab une à une. Prenez le temps de comprendre le fonctionnement du pipeline actuel et quel problème il résout.\n\n- Certains jobs Jenkins peuvent être trop complexes pour être migrés immédiatement vers GitLab. Il peut donc s'avérer pratique d'utiliser le [plug-in Jenkins GitLab](https://plugins.jenkins.io/gitlab-plugin/) pour lancer les pipelines Jenkins et afficher leurs résultats directement depuis GitLab. Cela vous permet de migrer lentement certaines actions vers GitLab jusqu'à ce que l'ensemble du pipeline puisse être déplacé.\n\n- Mettez en œuvre des [scanners de sécurité et une vérification de la qualité du code](https://docs.gitlab.com/user/application_security/) à l'aide de templates intégrés fournis par GitLab. Cela vous permettra d'intégrer la sécurité en amont et ainsi de réduire le risque potentiel de failles. Simplifiez votre configuration CI/CD et essayez d'utiliser les avantages de chaque fonctionnalité sans tarder. Modularisez le code et implémentez-le en petites itérations.\n\n- Mettez en place le suivi et la gouvernance dès le départ.\n\n- Sachez que GitLab Runner (Go) peut se comporter différemment de l'agent Jenkins (Java). L'utilisation du processeur et la consommation de mémoire peuvent différer. Pensez à effectuer des comparaisons au fil du temps.\n\n- Envisagez d'investir dans des mécanismes de mise à l'échelle automatique et arrêtez les ressources inutiles le week-end ou en dehors des heures de travail.\n\n- Modernisez le développement d'applications en conteneurisant vos jobs. Les jobs Jenkins ne sont pas actuellement exécutés sur un conteneur, mais sur un agent Jenkins s'exécutant en tant que machine virtuelle.\n\nBien que cette liste ne soit pas exhaustive, elle constitue un bon point de départ. Si vous avez besoin d'une aide supplémentaire, GitLab fournit des [services professionnels](https://about.gitlab.com/fr-fr/get-help/) pour vous aider dans votre parcours de migration.\n\n### Conclusion\n\nMerci de votre intérêt pour cet article ! Nous espérons que ce guide vous a aidé à comprendre les avantages d'une migration de Jenkins vers GitLab, et comment procéder.\nVous hésitez encore ? [Essayez GitLab gratuitement](https://about.gitlab.com/fr-fr/free-trial/) et découvrez les avantages de notre plateforme DevSecOps.\n\nRessources complémentaires :\n- [Migration depuis Jenkins](https://docs.gitlab.com/ci/migration/jenkins/)\n- [Planification d'une migration](https://docs.gitlab.com/ci/migration/plan_a_migration/)\n- [Outils d'importation de projets GitLab](https://docs.gitlab.com/user/project/import/)\n- [Migrer de GitHub Advanced Security vers GitLab Ultimate : notre guide complet](https://about.gitlab.com/fr-fr/blog/migration-guide-github-advanced-security-to-gitlab-ultimate/)\n- [Vidéo : Migration facile de GitHub vers GitLab](https://youtu.be/0Id5oMl1Kqs?feature=shared)\n- [De Jenkins vers GitLab : le guide ultime pour moderniser votre environnement CI/CD](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n","devsecops",{"slug":13,"featured":14,"template":15},"jenkins-to-gitlab-migration-made-easy",true,"BlogPost",{"title":5,"description":17,"authors":18,"heroImage":19,"date":20,"body":10,"category":11,"tags":21,"updatedDate":24},"Découvrez pourquoi et comment migrer facilement de Jenkins vers GitLab en suivant ce guide étape par étape.",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg","2024-02-01",[22,23],"CI/CD","DevSecOps","2025-03-18","yml",null,{},"/fr-fr/blog/jenkins-to-gitlab-migration-made-easy","seo:\n  title: 'Migrer de Jenkins vers GitLab : le guide complet'\n  description: >-\n    Découvrez pourquoi et comment migrer facilement de Jenkins vers GitLab en\n    suivant ce guide étape par étape.\n  ogTitle: 'Migrer de Jenkins vers GitLab : le guide complet'\n  ogDescription: >-\n    Découvrez pourquoi et comment migrer facilement de Jenkins vers GitLab en\n    suivant ce guide étape par étape.\n  noIndex: false\n  ogImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg\n  ogUrl: https://about.gitlab.com/blog/jenkins-to-gitlab-migration-made-easy\n  ogSiteName: https://about.gitlab.com\n  ogType: article\n  canonicalUrls: https://about.gitlab.com/blog/jenkins-to-gitlab-migration-made-easy\ncontent:\n  title: 'Migrer de Jenkins vers GitLab : le guide complet'\n  description: >-\n    Découvrez pourquoi et comment migrer facilement de Jenkins vers GitLab en\n    suivant ce guide étape par étape.\n  authors:\n    - Fernando Diaz\n  heroImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg\n  date: '2024-02-01'\n  body: \"GitLab est la plateforme DevSecOps alimentée par l'IA la plus complète.\n    En effet, GitLab fournit toutes les fonctionnalités dont vous avez besoin\n    pour planifier, développer et livrer des logiciels sécurisés plus\n    rapidement, le tout au sein d'une seule et même plateforme.\\\n\n\n    Les plateformes comme GitLab éliminent les difficultés et les défis liés à\n    l'intégration de multiples outils (approche DevOps DIY) pour gérer au mieux\n    le cycle de vie du développement logiciel (SDLC). À l'inverse, Jenkins\n    n'étant pas une plateforme, des outils supplémentaires sont nécessaires pour\n    compléter le SDLC. Cette approche DevOps DIY introduit une complexité\n    supplémentaire liée à la chaîne d'outils, et génère un certain nombre\n    d'inconvénients comme :\\\n\n\n    - La nécessité d'une assistance personnalisée pour l'intégration et\n    l'orchestration des outils\n\n    - La difficulté à tenir à jour/mettre à niveau/sécuriser des outils\n    disparates\n\n    - L'impossibilité de mesurer correctement la transformation\n    organisationnelle\n\n    - Une mauvaise expérience des équipes de développement\\\n\n    - Des coûts supplémentaires en lien avec la gestion, les délais et le budget\n\n    - Une perte de productivité\n\n    - Un changement de contexte et une inefficacité en terme de collaboration\n\n\n    \u003Ccenter>\n\n    \u003Cfigure>\n\n    \\   \u003Cimg\n    src=\\\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175993/\\\n    Blog/ikr97sr9jclddeqdg7ew.png\\\" alt=\\\"Import project selection\\\">\n\n    \\   \u003Cfigcaption>DevOps DIY versus plateforme DevSecOps\u003C/figcaption>\n\n    \u003C/figure>\n\n    \u003C/center>\n\n    \u003Cp>\u003C/p>\n\n\n    Pour ces raisons, de nombreuses équipes de développement utilisant Jenkins\n    envisagent de migrer vers une plateforme\n    [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \\\"Qu'est-ce que\n    l'approche DevSecOps ?\\\") complète. Si vous recherchez une plateforme\n    puissante, fiable et sécurisée, GitLab est votre meilleure option ! GitLab\n    propose une version gratuite ainsi que différents niveaux d'abonnement en\n    fonction des besoins de votre entreprise. Pour en savoir plus sur nos offres\n    et fonctionnalités, consultez notre [page\n    tarifaire](https://about.gitlab.com/fr-fr/pricing/).\n\n\n    Découvrez dans cet article de blog :\n\n    - Comment planifier une migration\n\n    - Comment migrer des dépôts depuis d'autres outils de gestion du code source\n    (SCM) vers GitLab\n\n    - Comment migrer des pipelines CI/CD de Jenkins vers GitLab\n\n\n    ## Comment planifier une migration de Jenkins vers GitLab ?\\\n\n\n    Avant d'initier la migration de vos dépôts hébergés sur un autre outil vers\n    GitLab CI/CD, vous devez élaborer un plan de migration. Cette étape\n    technique est importante et vous permet de définir clairement vos attentes.\n    Les outils CI/CD diffèrent par leur approche, leur structure et leurs\n    spécificités techniques. Par conséquent, les migrations ne sont pas de\n    simples transferts directs des données.\\\n\n\n    Un plan de migration offre les avantages suivants :\n\n    - Il définit et communique une vision claire de vos objectifs de migration,\n    ce qui aide les personnes impliquées à comprendre le but de cette\n    opération.\\\n\n    - Il vous permet de vous assurer d’obtenir l'aval des équipes de direction\n    concernées pour faciliter cette démarche.\n\n    - Il permet d'expliquer aux utilisateurs les changements à venir.\n\n    - Il permet de trouver des moyens de séquencer ou de retarder certaines\n    étapes de la migration pour éviter l'échec de la migration ou une migration\n    partielle.\n\n    - Il documente les avantages des améliorations apportées par GitLab CI/CD et\n    met à jour votre mise en œuvre à chaque étape de la migration.\n\n\n    Un plan de migration vous aide à mettre en place un processus fluide\n    permettant de migrer progressivement vers GitLab, avec un minimum de\n    perturbations. Il peut s'agir d’exécuter simultanément Jenkins et GitLab,\n    tandis que certains projets sont transférés de Jenkins vers GitLab.\n\n\n    ### Définissez un processus de gestion du changement\n\n\n    Il se peut que les développeurs, opérateurs informatiques, administrateurs\n    cloud, équipes en charge de la sécurité, ainsi que les ingénieurs qualité\n    n'aient pas d'expérience avec GitLab et ne sachent pas pourquoi vous ou\n    votre équipe de direction avez choisi de réaliser cette migration. C'est\n    pourquoi votre plan de migration doit inclure un processus efficace de\n    gestion du changement.\\\n\n\n    Les personnes impactées par cette migration doivent savoir :\n\n    - __Pourquoi__ ce changement est nécessaire\n\n    - __À quoi__ ressemblera le futur système\n\n    - __Comment__ l'entreprise prévoit d'atteindre cet objectif\n\n    - __Vers qui__ se tourner pour obtenir plus d'informations ou de l'aide\\\n\n\n    À cette fin, vous devez réaliser les étapes suivantes afin de gérer\n    efficacement le changement au sein des différentes équipes\n    fonctionnelles :\\\n\n    - __Analysez l'état actuel__ : documentez les processus existants. Collectez\n    des indicateurs qui serviront de base de référence. Identifiez ce qui\n    fonctionne ou non avec l'[approche\n    CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \\\"Qu'est-ce que le CI/CD\n    ?\\\") en interrogeant certains membres de votre équipe. Documentez les défis\n    que vous devez relever, et ce d'un point de vue quantitatif et qualitatif.\n    Comme vous allez devoir expliquer les raisons de ce changement et votre\n    vision, plus vous définirez clairement les problématiques que vous espérez\n    résoudre, plus il vous sera facile d'obtenir l'adhésion de tous.\\\n\n    - __Établissez une vision__ : maintenant que vous avez décrit les points de\n    friction actuels quantitativement avec des indicateurs de référence et\n    qualitativement (en vous basant sur les retours des membres de votre\n    équipe), communiquez une vision de l'état futur. Expliquez pourquoi c'est\n    important (en vous référant aux indicateurs de réussite de votre entreprise)\n    et partagez l’état actuel de la situation et les résultats attendus.\n    Renforcez ce message par le biais de différents canaux de communication :\n    groupes de discussion, réunions rassemblant l'ensemble des acteurs de\n    l'entreprise, ou encore notifications par e-mail.\n\n    - __Formez les collaborateurs__ : investissez dans une [formation sur GitLab\n    CI/CD](https://university.gitlab.com/pages/ci-cd-training/) dispensée par un\n    expert GitLab. Mesurez l'acquisition et la mémorisation des connaissances à\n    l'aide des [certifications\n    GitLab](https://levelup.gitlab.com/pages/certifications).\\\n\n    - __Communiquez la roadmap et les ressources__ : partagez avec les membres\n    de votre équipe le calendrier prévu de la migration et les ressources mises\n    à leur disposition pour faciliter la transition. Mentionnez également les\n    ressources communautaires (groupes de discussion, forums), afin que votre\n    équipe puisse poser des questions et obtenir de l'aide. Créez un système qui\n    récompense les équipes qui effectuent rapidement cette transition, et\n    encouragez-les à partager leur expérience avec d'autres équipes similaires\n    au sein de l'entreprise.\n\n\n    Si vous mettez en place ces éléments dès le début de cette transition, cela\n    sera de bon augure pour la réussite de votre migration.\\\n\n\n    ### Définissez des objectifs de migration\n\n\n    Avant d'effectuer votre migration, vous devez avoir une bonne compréhension\n    de vos objectifs et de la façon de les atteindre. Voici par exemple\n    certaines des questions auxquelles vous devez pouvoir répondre :\n\n\n    - Quel est votre calendrier de migration ?\n\n    - Quelle est la configuration actuelle de votre serveur Jenkins ?\n\n    - Combien de projets sont concernés par la migration ?\n\n    - Quel est le degré de complexité de votre pipeline ?\n\n    - Nécessite-t-il des dépendances externes, plusieurs déclencheurs pour\n    s'exécuter, exécute-t-il plusieurs processus en parallèle pour compiler le\n    code, etc. ?\n\n    - Comment/où déployez-vous votre code ?\n\n    - Quel est le processus de revue/sortie des nouvelles versions et de\n    déploiement du code ?\n\n    - Est-il intégré dans Jenkins ou dans un workflow distinct déclenché par\n    Jenkins ?\n\n    - Quels artefacts de compilation ou binaires sont nécessaires au succès du\n    pipeline ?\n\n    - Quels plug-ins sont utilisés par les jobs dans Jenkins aujourd'hui ?\n\n    - Quel logiciel est installé sur les agents Jenkins ?\n\n    - Quelle solution de gestion du code source (SCM) utilisez-vous\n    actuellement ?\n\n    - Utilisez-vous des bibliothèques partagées dans vos jobs Jenkins ?\n\n    - Quelle méthode d'authentification est utilisée pour Jenkins (Basic\n    Authentication, LDAP/AD, SSO) ?\n\n    - Y a-t-il d'autres projets auxquels vous devez accéder depuis votre\n    pipeline ?\n\n    - Des identifiants de connexion dans Jenkins sont-ils utilisés pour accéder\n    à des services externes ?\n\n\n    En répondant à ces questions, vous saurez comment procéder à la migration,\n    combien de temps durera cette opération et par où commencer. Une fois que\n    vous avez élaboré un plan et que vous êtes conscient des attentes et des\n    écueils possibles, vous pouvez commencer votre processus de migration.\n\n\n    ## Prérequis à la migration\n\n\n    Une fois que vous avez créé votre plan de migration et répondu à toutes les\n    attentes associées, vous pouvez commencer à configurer GitLab.\\\n\n\n    Voici certains des prérequis suggérés pour la migration :\n\n    - Familiarisez-vous avec GitLab et découvrez les [fonctionnalités clés de\n    GitLab CI/CD](https://docs.gitlab.com/ci/).\n\n    - Suivez des tutoriels pour créer votre premier [pipeline\n    GitLab](https://docs.gitlab.com/ci/quick_start/) et des\n    [pipelines plus\n    complexes](https://docs.gitlab.com/ci/quick_start/tutorial/) qui\n    créent, testent et déploient un site statique.\n\n    - Passez en revue la [liste des mots-clés de configuration\n    .gitlab-ci.yml](https://docs.gitlab.com/ci/yaml/).\n\n    - Configurez GitLab.\n\n    - Testez votre instance GitLab.\n\n\n    Une fois que vous avez compris le fonctionnement de GitLab et qu'une\n    instance a été configurée, vous pouvez suivre votre plan de migration et\n    commencer à déplacer des projets de Jenkins vers GitLab. Vérifiez que votre\n    instance GitLab a été correctement configurée à l'aide des bonnes pratiques\n    et des [architectures de\n    référence](https://docs.gitlab.com/administration/reference_architecture/\n    s/) de GitLab.\n\n\n    ### Migrez vos dépôts vers GitLab\n\n    L'un des principaux inconvénients de Jenkins est qu'il ne fournit pas de\n    solution SCM. Si vous utilisez Jenkins, votre code doit être stocké dans une\n    solution SCM distincte à laquelle Jenkins doit avoir accès. Comme GitLab\n    dispose d'un SCM intégré, la migration depuis Jenkins vous permet également\n    de migrer depuis la solution SCM que vous utilisiez, ce qui entraîne une\n    réduction supplémentaire des coûts.\n\n\n    GitLab fournit des outils pour vous permettre de déplacer facilement votre\n    dépôt et ses métadonnées dans GitLab. Les outils d'importation suivants sont\n    inclus et vous aideront à migrer vos projets vers GitLab :\n\n\n    - [GitHub](https://docs.gitlab.com/user/project/import/github/)\n\n    - [Autre instance\n    GitLab](https://docs.gitlab.com/user/project/settings/import_export/)\n\n    - [Bitbucket\n    Cloud](https://docs.gitlab.com/user/project/import/bitbucket/)\n\n    - [Bitbucket\n    Server](https://docs.gitlab.com/user/project/import/bitbucket_server.htm/\n    l)\n\n    - [FogBugz](https://docs.gitlab.com/user/project/import/fogbugz/)\n\n    - [Gitea](https://docs.gitlab.com/user/project/import/gitea/)\n\n    - [Jira (Tickets\n    uniquement)](https://docs.gitlab.com/user/project/import/jira/)\n\n    - [Dépôt par fichier\n    manifeste](https://docs.gitlab.com/user/project/import/manifest/)\n\n    - [Dépôt par\n    URL](https://docs.gitlab.com/user/project/import/repo_by_url/)\n\n\n    \u003Ccenter>\n\n    \u003Cfigure>\n\n    \\   \u003Cimg\n    src=\\\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176002/\\\n    Blog/ie2xrexhbcoq6m8rnhit.png\\\" alt=\\\"GitHub to GitLab Repo Exporter\\\">\n\n    \\   \u003Cfigcaption>Outil d'exportation de dépôt de GitHub vers\n    GitLab\u003C/figcaption>\n\n    \u003C/figure>\n\n    \u003C/center>\n\n    \u003Cp>\u003C/p>\n\n\n    Chaque outil d'importation importe différentes données d'un projet. Lisez\n    notre [documentation sur l'importation et la migration de\n    projets](https://docs.gitlab.com/user/project/import/) pour en savoir\n    plus sur les outils d'importation fournis et comprendre quelles données sont\n    migrées vers GitLab. De plus, vous pouvez [automatiser l'importation de\n    groupes et de\n    projets](https://docs.gitlab.com/user/project/import/#automate-group-and\\\n    -project-import) et créer une solution personnalisée pour mieux répondre aux\n    besoins de votre entreprise :\n\n\n    - [Services professionnels](https://about.gitlab.com/services/)\n\n    - [Services de\n    migration](https://gitlab.com/gitlab-org/professional-services-automation/t\\\n    ools/migration/congregate/-/blob/master/docs/using-congregate.md#quick-star\\\n    t)\n\n    - [Foire aux questions sur la\n    migration](https://gitlab.com/gitlab-org/professional-services-automation/t\\\n    ools/migration/congregate/-/blob/master/customer/famq.md)\n\n\n    #### Comment migrer un dépôt ?\\\n\n\n    La migration d'un dépôt vers GitLab est facile grâce à nos outils\n    d'importation intégrés. Dans cet exemple, nous allons vous expliquer comment\n    copier un dépôt de GitHub vers GitLab ainsi que [ses\n    ressources](https://docs.gitlab.com/user/project/import/github/#impo\\\n    rted-data) (tickets, pull requests, jalons et plus encore).\\\n\n\n    Afin de migrer un dépôt depuis GitHub vers GitLab, vous pouvez suivre les\n    étapes ci-dessous :\n\n\n    1. Dans la barre latérale de gauche, en haut, sélectionnez **Créer un\n    nouveau (+)**.\n\n    2. Sélectionnez **Nouveau projet/dépôt**.\n\n    3. Sélectionnez **Importer un projet**.\n\n\n    \u003Ccenter>\n\n    \u003Cfigure>\n\n    \\   \u003Cimg\n    src=\\\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176017/\\\n    Blog/boowmmaqhbredxa3g92s.png\\\" alt=\\\"Import project selection\\\">\n\n    \u003C/figure>\n\n    \u003C/center>\n\n    \u003Cp>\u003C/p>\n\n\n    4. Cliquez sur le bouton **GitHub**.\n\n    \\    - Si vous utilisez GitLab Self-Managed, vous devez [activer l'outil\n    d'importation\n    GitHub](https://docs.gitlab.com/administration/settings/import_and_expor/\n    t_settings.html#configure-allowed-import-sources).\n\n    \\    - Notez que d'autres outils d'importation peuvent être lancés de la\n    même manière.\n\n    5. Vous pouvez ensuite utiliser l'une des deux options ci-dessous :\n\n    \\    - Autoriser OAuth de GitHub en sélectionnant **Autoriser avec GitHub**.\n\n    \\    - Utiliser un jeton d'accès personnel GitHub :\n\n    \\       - Accédez à la page\n    [https://github.com/settings/tokens/new](https://github.com/settings/tokens\\\n    /new).\n\n    \\       - Dans le champ **Note**, saisissez une description du token.\n\n    \\       - Sélectionnez la portée du dépôt.\n\n    \\       - En option, pour importer des collaborateurs, sélectionnez la\n    portée **read:org**.\n\n    \\       - Cliquez sur le bouton **Générer un token**.\n\n    \\       - Sur la page d'importation de GitLab, dans le champ **Jeton d'accès\n    personnel**, collez le jeton d'accès personnel GitHub.\n\n    6. Cliquez sur le bouton **Authentification**.\n\n    7. Sélectionnez les éléments que vous souhaitez migrer.\n\n    8. Sélectionnez les projets que vous souhaitez migrer et leur destination.\n\n    9. Cliquez sur le bouton **Importer**.\n\n\n    Le projet importé devrait maintenant être disponible dans votre espace de\n    travail. Pour en savoir plus sur la migration de GitHub vers GitLab,\n    regardez cette vidéo :\n\n\n    \u003Cfigure class=\\\"video_container\\\">\n\n    \\  \u003Ciframe\n    src=\\\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=TQ5HI9aMwtzJMiMi\\\"\n    frameborder=\\\"0\\\" allowfullscreen=\\\"true\\\"> \u003C/iframe>\n\n    \u003C/figure>\n\n    \u003C!-- blank line -->\n\n\n    Une fois que vous avez terminé la migration de votre dépôt, vous pouvez\n    configurer votre pipeline Jenkins pour exploiter le fichier Jenkinsfile dans\n    GitLab. Pour ce faire, définissez l'URL du dépôt sur le projet que vous\n    venez tout juste d'importer via le menu de configuration du pipeline\n    Jenkins :\n\n\n    \u003Ccenter>\n\n    \u003Cfigure>\n\n    \\   \u003Cimg\n    src=\\\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176020/\\\n    Blog/mu475liw66abcxbu2g6g.png\\\" alt=\\\"Jenkins Pipeline SCM settings\\\">\n\n    \u003C/figure>\n\n    \u003C/center>\n\n    \u003Cp>\u003C/p>\n\n\n    Cette opération est utile pendant la phase de migration initiale du dépôt et\n    vous permet d'utiliser Jenkins et GitLab en parallèle. Vous évitez ainsi\n    toute interruption de service pendant que vous travaillez sur votre\n    migration.\n\n\n    De plus, vous pouvez utiliser le [plug-in Jenkins\n    GitLab](https://plugins.jenkins.io/gitlab-plugin/) pour faciliter la\n    migration. Ce plug-in permet à GitLab de déclencher et d'obtenir le statut\n    des compilations Jenkins.\n\n\n    ### Migrez vos pipelines CI/CD\n\n    Une fois que vous avez migré vos dépôts vers GitLab, vous pouvez procéder à\n    la migration de vos pipelines Jenkins. Bien qu'assez simple, ce processus\n    nécessite une bonne compréhension des concepts et de la syntaxe Jenkins et\n    GitLab.\n\n\n    Jenkins fournit deux types de syntaxe pour la définition des pipelines : une\n    syntaxe déclarative et une syntaxe scriptée. Dans ce guide, nous décrirons\n    la migration à partir des pipelines déclaratifs, car ils sont les plus\n    couramment utilisés.\n\n\n    #### Migrez votre pipeline étape par étape\n\n\n    Dans ce tutoriel, nous analyserons un fichier Jenkinsfile (Groovy) ainsi\n    qu'un fichier de configuration GitLab CI/CD (YAML) qui compile, teste et\n    déploie un microservice écrit en Golang. Nous activerons ensuite le pipeline\n    dans GitLab et observerons le résultat.\\\n\n\n    Le pipeline :\n\n    - Utilisera l'image de conteneur Golang avec le tag **alpine**\n\n    - Exécutera un job pour compiler le code Golang en un fichier binaire\n    exécutable\n\n    \\   - Stockera le fichier exécutable compilé en tant qu'artefact\n\n    - Exécutera un job pour lancer les tests unitaires\n\n    - Exécutera un job pour effectuer le déploiement sur l'environnement de\n    préproduction\n\n    \\   - Ne s'exécutera que si la validation cible la branche de\n    **préproduction**\n\n    \\   - S'exécutera uniquement après la réussite de l'étape de **test**\n\n    \\   - Utilisera l'artefact exécutable compilé du job précédent\n\n\n    Vous trouverez ci-dessous les définitions de pipeline Jenkins et GitLab\n    accompagnées de commentaires descriptifs. Vous pouvez observer le pipeline\n    en action dans le [projet de migration\n    Meow](https://gitlab.com/gitlab-da/projects/blogs/meow-migration).\n\n\n    Voici un fichier Jenkinsfile écrit en Groovy :\n\n\n    ```text\n\n    // The top-level of the declarative\n\n    // pipeline.\n\n    pipeline {\n\n\n    \\  // Defines the default agent to use\n\n    \\  // when it is not explicitly defined\n\n    \\  // in a job.\n\n    \\    agent any\n\n\n    \\  // Defines the stages that will run\n\n    \\  // in numerical order. Each stage\n\n    \\  // only runs one job.\n\n    \\    stages {\n\n\n    \\    // Defines the name of the stage\n\n    \\        stage('build') {\n\n    \\      // Defines the container image to\n\n    \\      // use for this job, overwriting\n\n    \\      // the default 'agent any'.\n\n    \\      // The Jenkins Docker plugin\n\n    \\      // must be configured for this\n\n    \\      // to run.\n\n    \\            agent { docker 'golang:alpine' }\n\n\n    \\      // Defines the sequence of steps\n\n    \\      // to execute when the stage is\n\n    \\      // run.\n\n    \\            steps {\n\n    \\                sh 'go build -o bin/meow-micro'\n\n    \\                sh 'chmod +x bin/meow-micro'\n\n    \\            }\n\n\n    \\      // The steps to run after the\n\n    \\      // stage completes.\n\n    \\            post {\n\n    \\              always {\n\n\n    \\        // Stores the stage artifacts\n\n    \\        // generated for use in another\n\n    \\        // job.\n\n    \\                archiveArtifacts artifacts: 'bin/meow-micro'\n\n    \\                onlyIfSuccessful: true\n\n    \\              }\n\n    \\            }\n\n    \\        }\n\n\n    \\    stage('test') {\n\n    \\            agent { docker 'golang:alpine' }\n\n    \\            steps {\n\n    \\                sh 'go test .'\n\n    \\            }\n\n    \\        }\n\n\n    \\        stage('deploy') {\n\n    \\      // Defines conditions which must\n\n    \\      // be met in order for the job to\n\n    \\      // execute. In this case the\n\n    \\      // deploy job will only run on the\\\n\n    \\      // staging branch.\n\n    \\            when {\n\n    \\              branch 'staging'\n\n    \\            }\n\n    \\            steps {\n\n    \\                echo 'Deploying meow-micro to staging'\n\n    \\        // Uses the artifact stored in\n\n    \\        // the build stage.\n\n    \\                sh './bin/meow-micro'\n\n    \\            }\n\n    \\        }\n\n    \\    }\n\n    }\n\n    ```\n\n\n    Voyons maintenant comment créer la même fonctionnalité dans GitLab :\n\n\n    ```text\n\n    # Defines the default image to use\n\n    # when it is not explicitly defined in\n\n    # a job.\n\n    default:\n\n    \\  image: alpine:latest\n\n\n    # Defines the order to run the stages.\n\n    # Each stage can have multiple jobs.\n\n    stages:\n\n    \\  - build\n\n    \\  - test\n\n    \\  - deploy\n\n\n    # Defines the name of the job\n\n    create-binary:\n\n    \\ # Defines the stage the job will run in\n\n    \\  stage: build\n\n    \\ # Defines the container image to use\n\n    \\ # for this job, overwriting default.\n\n    \\  image: golang:alpine\n\n    \\ # Defines the sequence of steps to\n\n    \\ # execute when the job is run.\n\n    \\  script:\n\n    \\    - go build -o bin/meow-micro\n\n    \\    - chmod +x bin/meow-micro\n\n    \\ # Stores the job artifacts generated\n\n    \\ # for use in another job.\n\n    \\  artifacts:\n\n    \\    paths:\n\n    \\      - bin/meow-micro\n\n    \\    expire_in: 1 week\n\n\n    unit-tests:\n\n    \\  stage: test\n\n    \\  image: golang:alpine\n\n    \\  script:\n\n    \\    - go test .\n\n    \\ # Defines commands to run after the\n\n    \\ # job.\n\n    \\ after_script:\n\n    \\  - echo \\\"Tests Complete\\\"\n\n\n    staging-deploy:\n\n    \\  stage: deploy\n\n    \\ # Defines commands to run before the\n\n    \\ # actual job.\n\n    \\  before_script:\n\n    \\    - apk update\n\n    \\  script:\n\n    \\    - echo \\\"Deploying meow-micro to staging environment\\\"\n\n    \\    - ./bin/meow-micro\n\n    \\ # Defines conditions which must be met\n\n    \\ # in order for this job to execute. In\n\n    \\ # this case the staging-deploy job will\\\n\n    \\ # only run on the staging branch.\n\n    \\  rules:\n\n    \\    - if: $CI_COMMIT_BRANCH == 'staging'\n\n    \\ # Allows the artifact stored in the\n\n    \\ # build job to be used in this job.\n\n    \\  artifacts:\n\n    \\    paths:\n\n    \\      - bin/meow-micro\n\n    ```\n\n\n    Comme vous l'avez peut-être remarqué, il existe de nombreuses similitudes\n    entre Jenkins et GitLab en termes de syntaxe, ce qui simplifie la migration\n    du pipeline. Bien que l'exemple ci-dessus fournisse une vue d'ensemble\n    basique, assurez-vous de consulter la liste complète des [comparaisons de\n    fonctionnalités et de\n    concepts](https://docs.gitlab.com/ci/migration/jenkins/#comparison-o\\\n    f-features-and-concepts) entre les deux outils.\n\n\n    Maintenant que nous comprenons comment transposer Jenkins à GitLab, nous\n    pouvons commencer à créer un pipeline avec les mêmes fonctionnalités dans\n    GitLab. Pour effectuer la migration de votre [pipeline\n    CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/\n    \\\"Qu'est-ce qu'un pipeline CI/CD ?\\\"), suivez les étapes suivantes :\n\n\n    ##### 1. Ouvrez le dépôt que vous avez migré vers GitLab dans la section\n    ci-dessus.\n\n    - Dans la barre latérale de gauche, en haut, sélectionnez **Rechercher ou\n    accéder à...**\n\n    - Localisez votre projet.\n\n\n    ##### 2. Ouvrez l'[éditeur de\n    pipeline](https://docs.gitlab.com/ci/pipeline_editor/).\n\n    - Dans la barre latérale de gauche, sélectionnez **Compilation > Éditeur de\n    pipeline**.\n\n    \u003Ccenter>\n\n    \u003Cfigure>\n\n    \\   \u003Cimg\n    src=\\\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176026/\\\n    Blog/ecp4jh7epho2oxuegaor.png\\\" alt=\\\"Pipeline editor menu\\\">\n\n    \u003C/figure>\n\n    \u003C/center>\n\n    \u003Cp>\u003C/p>\n\n\n    - Cliquez sur le bouton **Configurer le pipeline**.\n\n\n    \u003Ccenter>\n\n    \u003Cfigure>\n\n    \\   \u003Cimg\n    src=\\\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176029/\\\n    Blog/nypfh01zhwgvzqc0xz3v.png\\\" alt=\\\"Configure pipeline selection\\\">\n\n    \u003C/figure>\n\n    \u003C/center>\n\n    \u003Cp>\u003C/p>\n\n\n    ##### 3. Complétez le fichier\n    [.gitlab-ci.yml](https://docs.gitlab.com/ci/yaml/).\n\n    - Ajoutez le code du pipeline GitLab CI.\\\n\n    \u003Ccenter>\n\n    \u003Cfigure>\n\n    \\   \u003Cimg\n    src=\\\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176031/\\\n    Blog/nxi6uxxispyyoiiyvxyg.png\\\" alt=\\\"Pipeline editor input\\\">\n\n    \u003C/figure>\n\n    \u003C/center>\n\n    \u003Cp>\u003C/p>\n\n\n    - Vérifiez que la syntaxe est correcte.\n\n\n    \u003Ccenter>\n\n    \u003Cfigure>\n\n    \\   \u003Cimg\n    src=\\\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176037/\\\n    Blog/x3d4utfsnymye0lvphtf.png\\\" alt=\\\"Pipeline syntax validation\\\">\n\n    \u003C/figure>\n\n    \u003C/center>\n\n    \u003Cp>\u003C/p>\n\n\n    - Visualisez le pipeline.\n\n\n    \u003Ccenter>\n\n    \u003Cfigure>\n\n    \\   \u003Cimg\n    src=\\\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176043/\\\n    Blog/hipzofpyywjxf62edzfv.png\\\" alt=\\\"Pipeline visualization\\\">\n\n    \u003C/figure>\n\n    \u003C/center>\n\n    \u003Cp>\u003C/p>\n\n\n    ##### 4. Validez le fichier dans la branche principale.\n\n    - Ajoutez un message de validation.\n\n    - Assurez-vous que la branche est définie sur la branche principale.\n\n    - Cliquez sur le bouton __Valider les modifications__.\n\n\n    \u003Ccenter>\n\n    \u003Cfigure>\n\n    \\   \u003Cimg\n    src=\\\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176048/\\\n    Blog/nn8bl7rdysabccoycfrk.png\\\" alt=\\\"Commit changes dialog\\\">\n\n    \u003C/figure>\n\n    \u003C/center>\n\n    \u003Cp>\u003C/p>\n\n\n    Une fois le fichier fusionné, le pipeline défini s'exécute. Vous pouvez\n    revenir à votre projet et [observer le\n    pipeline](https://docs.gitlab.com/ci/pipelines/#view-pipelines) en action\n    en le sélectionnant sur la page **Compilation > Pipelines** de votre projet.\n    Comme il a été exécuté sur la branche **principale**, vous ne verrez que les\n    jobs **create-binary** et **unit-tests**. Le job **staging-deploy**\n    s'exécute uniquement sur la branche de préproduction.\n\n\n    \u003Ccenter>\n\n    \u003Cfigure>\n\n    \\   \u003Cimg\n    src=\\\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176051/\\\n    Blog/wfb4k8nkzpg28kpf2pzz.png\\\" alt=\\\"Pipeline running on main branch\\\">\n\n    \u003C/figure>\n\n    \u003C/center>\n\n    \u003Cp>\u003C/p>\n\n\n    Si nous créons une branche de préproduction, le pipeline suivant s'exécute.\n\n\n    \u003Ccenter>\n\n    \u003Cfigure>\n\n    \\   \u003Cimg\n    src=\\\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176053/\\\n    Blog/e2jxedpolaniotgixpby.png\\\" alt=\\\"Pipeline running on staging branch\\\">\n\n    \u003C/figure>\n\n    \u003C/center>\n\n    \u003Cp>\u003C/p>\n\n\n    En cliquant sur un job, nous pouvons voir la sortie associée :  \\\n\n\n    \u003Ccenter>\n\n    \u003Cfigure>\n\n    \\   \u003Cimg\n    src=\\\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176056/\\\n    Blog/fywzwbzkwcvc9zzakilh.png\\\" alt=\\\"create-binary job output\\\">\n\n    \\   \u003Cfigcaption>Sortie du job create-binary\u003C/figcaption>\n\n    \u003C/figure>\n\n    \u003C/center>\n\n    \u003Cp>\u003C/p>\n\n\n    \u003Ccenter>\n\n    \u003Cfigure>\n\n    \\   \u003Cimg\n    src=\\\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176061/\\\n    Blog/ekmpd8ecanwwiena9xi9.png\\\" alt=\\\"unit-tests job output input\\\">\n\n    \\   \u003Cfigcaption>Entrée/sortie du job unit-tests\u003C/figcaption>\n\n    \u003C/figure>\n\n    \u003C/center>\n\n    \u003Cp>\u003C/p>\n\n\n    \u003Ccenter>\n\n    \u003Cfigure>\n\n    \\   \u003Cimg\n    src=\\\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176065/\\\n    Blog/h7nqxszy50xdmnvhalfq.png\\\" alt=\\\"staging-deploy job output\\\">\n\n    \\   \u003Cfigcaption>Sortie du job staging-deploy\u003C/figcaption>\n\n    \u003C/figure>\n\n    \u003C/center>\n\n    \u003Cp>\u003C/p>\n\n\n    L'artefact est stocké dans le job __create-binary__ et utilisé dans le job\n    __staging-deploy__. Et voilà, la migration d'un pipeline de Jenkins vers\n    GitLab est aussi simple que cela !\n\n\n    ### Autres conseils à suivre lors de la migration\n\n    Voici quelques conseils pratiques pour simplifier le processus de\n    déploiement :\n\n\n    - N'essayez pas de répliquer les tâches dans des jobs GitLab une à une.\n    Prenez le temps de comprendre le fonctionnement du pipeline actuel et quel\n    problème il résout.\n\n\n    - Certains jobs Jenkins peuvent être trop complexes pour être migrés\n    immédiatement vers GitLab. Il peut donc s'avérer pratique d'utiliser le\n    [plug-in Jenkins GitLab](https://plugins.jenkins.io/gitlab-plugin/) pour\n    lancer les pipelines Jenkins et afficher leurs résultats directement depuis\n    GitLab. Cela vous permet de migrer lentement certaines actions vers GitLab\n    jusqu'à ce que l'ensemble du pipeline puisse être déplacé.\n\n\n    - Mettez en œuvre des [scanners de sécurité et une vérification de la\n    qualité du code](https://docs.gitlab.com/user/application_security/) à\n    l'aide de templates intégrés fournis par GitLab. Cela vous permettra\n    d'intégrer la sécurité en amont et ainsi de réduire le risque potentiel de\n    failles. Simplifiez votre configuration CI/CD et essayez d'utiliser les\n    avantages de chaque fonctionnalité sans tarder. Modularisez le code et\n    implémentez-le en petites itérations.\n\n\n    - Mettez en place le suivi et la gouvernance dès le départ.\n\n\n    - Sachez que GitLab Runner (Go) peut se comporter différemment de l'agent\n    Jenkins (Java). L'utilisation du processeur et la consommation de mémoire\n    peuvent différer. Pensez à effectuer des comparaisons au fil du temps.\n\n\n    - Envisagez d'investir dans des mécanismes de mise à l'échelle automatique\n    et arrêtez les ressources inutiles le week-end ou en dehors des heures de\n    travail.\n\n\n    - Modernisez le développement d'applications en conteneurisant vos jobs. Les\n    jobs Jenkins ne sont pas actuellement exécutés sur un conteneur, mais sur un\n    agent Jenkins s'exécutant en tant que machine virtuelle.\n\n\n    Bien que cette liste ne soit pas exhaustive, elle constitue un bon point de\n    départ. Si vous avez besoin d'une aide supplémentaire, GitLab fournit des\n    [services professionnels](https://about.gitlab.com/fr-fr/get-help/) pour\n    vous aider dans votre parcours de migration.\n\n\n    ### Conclusion\n\n\n    Merci de votre intérêt pour cet article ! Nous espérons que ce guide vous a\n    aidé à comprendre les avantages d'une migration de Jenkins vers GitLab, et\n    comment procéder.\\\n\n\n    Vous hésitez encore ? [Essayez GitLab\n    gratuitement](https://about.gitlab.com/fr-fr/free-trial/) et découvrez les\n    avantages de notre plateforme DevSecOps.\n\n\n    Ressources complémentaires :\\\n\n\n    - [Migration depuis\n    Jenkins](https://docs.gitlab.com/ci/migration/jenkins/)\n\n    - [Planification d'une\n    migration](https://docs.gitlab.com/ci/migration/plan_a_migration/)\n\n    - [Outils d'importation de projets\n    GitLab](https://docs.gitlab.com/user/project/import/)\n\n    - [Migrer de GitHub Advanced Security vers GitLab Ultimate : notre guide\n    complet](https://about.gitlab.com/fr-fr/blog/migration-guide-github-advance\\\n    d-security-to-gitlab-ultimate/)\n\n    - [Vidéo : Migration facile de GitHub vers\n    GitLab](https://youtu.be/0Id5oMl1Kqs?feature=shared)\n\n    - [De Jenkins vers GitLab : le guide ultime pour moderniser votre\n    environnement\n    CI/CD](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-moder\\\n    nizing-cicd-environment/)\\n\"\n  category: devsecops\n  tags:\n    - CI/CD\n    - DevSecOps\n  updatedDate: '2025-03-18'\nconfig:\n  slug: jenkins-to-gitlab-migration-made-easy\n  featured: true\n  template: BlogPost\n",{"title":5,"description":17,"ogTitle":5,"ogDescription":17,"noIndex":31,"ogImage":19,"ogUrl":32,"ogSiteName":33,"ogType":34,"canonicalUrls":32},false,"https://about.gitlab.com/blog/jenkins-to-gitlab-migration-made-easy","https://about.gitlab.com","article","fr-fr/blog/jenkins-to-gitlab-migration-made-easy",[37,11],"cicd",[22,23],"48VHl1dcPCCvjiQDNF5kI17Z7sDVUKgyQUA2T0Ji9WQ",{"data":41},{"logo":42,"freeTrial":47,"sales":52,"login":57,"items":62,"search":371,"minimal":406,"duo":425,"switchNav":434,"pricingDeployment":445},{"config":43},{"href":44,"dataGaName":45,"dataGaLocation":46},"/fr-fr/","gitlab logo","header",{"text":48,"config":49},"Commencer un essai gratuit",{"href":50,"dataGaName":51,"dataGaLocation":46},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr&glm_content=default-saas-trial/","free trial",{"text":53,"config":54},"Contacter l'équipe commerciale",{"href":55,"dataGaName":56,"dataGaLocation":46},"/fr-fr/sales/","sales",{"text":58,"config":59},"Connexion",{"href":60,"dataGaName":61,"dataGaLocation":46},"https://gitlab.com/users/sign_in/","sign in",[63,90,186,191,292,352],{"text":64,"config":65,"cards":67},"Plateforme",{"dataNavLevelOne":66},"platform",[68,74,82],{"title":64,"description":69,"link":70},"La plateforme d'orchestration intelligente pour le DevSecOps",{"text":71,"config":72},"Explorer notre plateforme",{"href":73,"dataGaName":66,"dataGaLocation":46},"/fr-fr/platform/",{"title":75,"description":76,"link":77},"GitLab Duo Agent Platform","L'IA agentique pour l'ensemble du cycle de développement logiciel",{"text":78,"config":79},"Découvrir GitLab Duo",{"href":80,"dataGaName":81,"dataGaLocation":46},"/fr-fr/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":83,"description":84,"link":85},"Pourquoi GitLab ?","Découvrez les principales raisons pour lesquelles les entreprises choisissent GitLab",{"text":86,"config":87},"En savoir plus",{"href":88,"dataGaName":89,"dataGaLocation":46},"/fr-fr/why-gitlab/","why gitlab",{"text":91,"left":14,"config":92,"link":94,"lists":98,"footer":168},"Produit",{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"Voir toutes les solutions",{"href":97,"dataGaName":93,"dataGaLocation":46},"/fr-fr/solutions/",[99,123,146],{"title":100,"description":101,"link":102,"items":107},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":46},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[108,111,114,119],{"text":22,"config":109},{"href":110,"dataGaLocation":46,"dataGaName":22},"/fr-fr/solutions/continuous-integration/",{"text":75,"config":112},{"href":80,"dataGaLocation":46,"dataGaName":113},"gitlab duo agent platform - product menu",{"text":115,"config":116},"Gestion du code source",{"href":117,"dataGaLocation":46,"dataGaName":118},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":120,"config":121},"Livraison de logiciels automatisée",{"href":105,"dataGaLocation":46,"dataGaName":122},"Automated software delivery",{"title":124,"description":125,"link":126,"items":131},"Sécurité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":127},{"href":128,"dataGaName":129,"dataGaLocation":46,"icon":130},"/fr-fr/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[132,136,141],{"text":133,"config":134},"Tests de sécurité des applications",{"href":128,"dataGaName":135,"dataGaLocation":46},"Application security testing",{"text":137,"config":138},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":139,"dataGaLocation":46,"dataGaName":140},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":142,"config":143},"Conformité logicielle",{"href":144,"dataGaName":145,"dataGaLocation":46},"/fr-fr/solutions/software-compliance/","software compliance",{"title":147,"link":148,"items":153},"Mesures",{"config":149},{"icon":150,"href":151,"dataGaName":152,"dataGaLocation":46},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[154,158,163],{"text":155,"config":156},"Visibilité et mesures",{"href":151,"dataGaLocation":46,"dataGaName":157},"Visibility and Measurement",{"text":159,"config":160},"Gestion de la chaîne de valeur",{"href":161,"dataGaLocation":46,"dataGaName":162},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":164,"config":165},"Données d'analyse et informations clés",{"href":166,"dataGaLocation":46,"dataGaName":167},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":169,"items":170},"GitLab",[171,176,181],{"text":172,"config":173},"Pour les entreprises",{"href":174,"dataGaLocation":46,"dataGaName":175},"/fr-fr/enterprise/","enterprise",{"text":177,"config":178},"Pour les PME",{"href":179,"dataGaLocation":46,"dataGaName":180},"/fr-fr/small-business/","small business",{"text":182,"config":183},"Pour le secteur public",{"href":184,"dataGaLocation":46,"dataGaName":185},"/fr-fr/solutions/public-sector/","public sector",{"text":187,"config":188},"Tarifs",{"href":189,"dataGaName":190,"dataGaLocation":46,"dataNavLevelOne":190},"/fr-fr/pricing/","pricing",{"text":192,"config":193,"link":195,"lists":199,"feature":279},"Ressources",{"dataNavLevelOne":194},"resources",{"text":196,"config":197},"Afficher toutes les ressources",{"href":198,"dataGaName":194,"dataGaLocation":46},"/fr-fr/resources/",[200,233,251],{"title":201,"items":202},"Premiers pas",[203,208,213,218,223,228],{"text":204,"config":205},"Installation",{"href":206,"dataGaName":207,"dataGaLocation":46},"/fr-fr/install/","install",{"text":209,"config":210},"Guides de démarrage",{"href":211,"dataGaName":212,"dataGaLocation":46},"/fr-fr/get-started/","quick setup checklists",{"text":214,"config":215},"Apprentissage",{"href":216,"dataGaLocation":46,"dataGaName":217},"https://university.gitlab.com/","learn",{"text":219,"config":220},"Documentation",{"href":221,"dataGaName":222,"dataGaLocation":46},"https://docs.gitlab.com/","product documentation",{"text":224,"config":225},"Vidéos sur les bonnes pratiques",{"href":226,"dataGaName":227,"dataGaLocation":46},"/fr-fr/getting-started-videos/","best practice videos",{"text":229,"config":230},"Intégrations",{"href":231,"dataGaName":232,"dataGaLocation":46},"/fr-fr/integrations/","integrations",{"title":234,"items":235},"Découvrir",[236,241,246],{"text":237,"config":238},"Témoignages clients",{"href":239,"dataGaName":240,"dataGaLocation":46},"/fr-fr/customers/","customer success stories",{"text":242,"config":243},"Blog",{"href":244,"dataGaName":245,"dataGaLocation":46},"/fr-fr/blog/","blog",{"text":247,"config":248},"Travail à distance",{"href":249,"dataGaName":250,"dataGaLocation":46},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":252,"items":253},"Connecter",[254,259,264,269,274],{"text":255,"config":256},"Services GitLab",{"href":257,"dataGaName":258,"dataGaLocation":46},"/fr-fr/services/","services",{"text":260,"config":261},"Communauté",{"href":262,"dataGaName":263,"dataGaLocation":46},"/community/","community",{"text":265,"config":266},"Forum",{"href":267,"dataGaName":268,"dataGaLocation":46},"https://forum.gitlab.com/","forum",{"text":270,"config":271},"Événements",{"href":272,"dataGaName":273,"dataGaLocation":46},"/events/","events",{"text":275,"config":276},"Partenaires",{"href":277,"dataGaName":278,"dataGaLocation":46},"/fr-fr/partners/","partners",{"background":280,"textColor":281,"text":282,"image":283,"link":287},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":284,"config":285},"carte promo The Source",{"src":286},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":288,"config":289},"Lire les articles les plus récents",{"href":290,"dataGaName":291,"dataGaLocation":46},"/fr-fr/the-source/","the source",{"text":293,"config":294,"lists":296},"Société",{"dataNavLevelOne":295},"company",[297],{"items":298},[299,304,310,312,317,322,327,332,337,342,347],{"text":300,"config":301},"À propos",{"href":302,"dataGaName":303,"dataGaLocation":46},"/fr-fr/company/","about",{"text":305,"config":306,"footerGa":309},"Carrières",{"href":307,"dataGaName":308,"dataGaLocation":46},"/jobs/","jobs",{"dataGaName":308},{"text":270,"config":311},{"href":272,"dataGaName":273,"dataGaLocation":46},{"text":313,"config":314},"Leadership",{"href":315,"dataGaName":316,"dataGaLocation":46},"/company/team/e-group/","leadership",{"text":318,"config":319},"Équipe",{"href":320,"dataGaName":321,"dataGaLocation":46},"/company/team/","team",{"text":323,"config":324},"Manuel",{"href":325,"dataGaName":326,"dataGaLocation":46},"https://handbook.gitlab.com/","handbook",{"text":328,"config":329},"Relations avec les investisseurs",{"href":330,"dataGaName":331,"dataGaLocation":46},"https://ir.gitlab.com/","investor relations",{"text":333,"config":334},"Trust Center",{"href":335,"dataGaName":336,"dataGaLocation":46},"/fr-fr/security/","trust center",{"text":338,"config":339},"Centre pour la transparence de l'IA",{"href":340,"dataGaName":341,"dataGaLocation":46},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":343,"config":344},"Newsletter",{"href":345,"dataGaName":346,"dataGaLocation":46},"/company/contact/#contact-forms","newsletter",{"text":348,"config":349},"Presse",{"href":350,"dataGaName":351,"dataGaLocation":46},"/press/","press",{"text":353,"config":354,"lists":355},"Nous contacter",{"dataNavLevelOne":295},[356],{"items":357},[358,361,366],{"text":53,"config":359},{"href":55,"dataGaName":360,"dataGaLocation":46},"talk to sales",{"text":362,"config":363},"Assistance GitLab",{"href":364,"dataGaName":365,"dataGaLocation":46},"https://support.gitlab.com","support portal",{"text":367,"config":368},"Portail clients GitLab",{"href":369,"dataGaName":370,"dataGaLocation":46},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":372,"login":373,"suggestions":380},"Fermer",{"text":374,"link":375},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":376,"config":377},"GitLab.com",{"href":60,"dataGaName":378,"dataGaLocation":379},"search login","search",{"text":381,"default":382},"Suggestions",[383,385,390,392,397,402],{"text":75,"config":384},{"href":80,"dataGaName":75,"dataGaLocation":379},{"text":386,"config":387},"Suggestions de code (IA)",{"href":388,"dataGaName":389,"dataGaLocation":379},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":22,"config":391},{"href":110,"dataGaName":22,"dataGaLocation":379},{"text":393,"config":394},"GitLab sur AWS",{"href":395,"dataGaName":396,"dataGaLocation":379},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":398,"config":399},"GitLab sur Google Cloud",{"href":400,"dataGaName":401,"dataGaLocation":379},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":403,"config":404},"Pourquoi utiliser GitLab ?",{"href":88,"dataGaName":405,"dataGaLocation":379},"Why GitLab?",{"freeTrial":407,"mobileIcon":412,"desktopIcon":417,"secondaryButton":420},{"text":408,"config":409},"Commencer votre essai gratuit",{"href":410,"dataGaName":51,"dataGaLocation":411},"https://gitlab.com/-/trials/new/","nav",{"altText":413,"config":414},"Icône GitLab",{"src":415,"dataGaName":416,"dataGaLocation":411},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":413,"config":418},{"src":419,"dataGaName":416,"dataGaLocation":411},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":421,"config":422},"Commencer",{"href":423,"dataGaName":424,"dataGaLocation":411},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr/get-started/","get started",{"freeTrial":426,"mobileIcon":430,"desktopIcon":432},{"text":427,"config":428},"En savoir plus sur GitLab Duo",{"href":80,"dataGaName":429,"dataGaLocation":411},"gitlab duo",{"altText":413,"config":431},{"src":415,"dataGaName":416,"dataGaLocation":411},{"altText":413,"config":433},{"src":419,"dataGaName":416,"dataGaLocation":411},{"button":435,"mobileIcon":440,"desktopIcon":442},{"text":436,"config":437},"/switch",{"href":438,"dataGaName":439,"dataGaLocation":411},"#contact","switch",{"altText":413,"config":441},{"src":415,"dataGaName":416,"dataGaLocation":411},{"altText":413,"config":443},{"src":444,"dataGaName":416,"dataGaLocation":411},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":446,"mobileIcon":451,"desktopIcon":453},{"text":447,"config":448},"Retour aux tarifs",{"href":189,"dataGaName":449,"dataGaLocation":411,"icon":450},"back to pricing","GoBack",{"altText":413,"config":452},{"src":415,"dataGaName":416,"dataGaLocation":411},{"altText":413,"config":454},{"src":419,"dataGaName":416,"dataGaLocation":411},{"title":456,"button":457,"config":462},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":458,"config":459},"Regarder GitLab Transcend maintenant",{"href":460,"dataGaName":461,"dataGaLocation":46},"/fr-fr/events/transcend/virtual/","transcend event",{"layout":463,"icon":464,"disabled":14},"release","AiStar",{"data":466},{"text":467,"source":468,"edit":474,"contribute":479,"config":484,"items":489,"minimal":691},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence.",{"text":469,"config":470},"Afficher le code source de la page",{"href":471,"dataGaName":472,"dataGaLocation":473},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":475,"config":476},"Modifier cette page",{"href":477,"dataGaName":478,"dataGaLocation":473},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":480,"config":481},"Veuillez contribuer",{"href":482,"dataGaName":483,"dataGaLocation":473},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":485,"facebook":486,"youtube":487,"linkedin":488},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[490,535,585,629,656],{"title":187,"links":491,"subMenu":506},[492,496,501],{"text":493,"config":494},"Voir les forfaits",{"href":189,"dataGaName":495,"dataGaLocation":473},"view plans",{"text":497,"config":498},"GitLab Premium",{"href":499,"dataGaName":500,"dataGaLocation":473},"/fr-fr/pricing/premium/","why premium",{"text":502,"config":503},"GitLab Ultimate",{"href":504,"dataGaName":505,"dataGaLocation":473},"/fr-fr/pricing/ultimate/","why ultimate",[507],{"title":353,"links":508},[509,511,513,515,520,525,530],{"text":53,"config":510},{"href":55,"dataGaName":56,"dataGaLocation":473},{"text":362,"config":512},{"href":364,"dataGaName":365,"dataGaLocation":473},{"text":367,"config":514},{"href":369,"dataGaName":370,"dataGaLocation":473},{"text":516,"config":517},"Statut",{"href":518,"dataGaName":519,"dataGaLocation":473},"https://status.gitlab.com/","status",{"text":521,"config":522},"Conditions d'utilisation",{"href":523,"dataGaName":524,"dataGaLocation":473},"/terms/","terms of use",{"text":526,"config":527},"Politique de confidentialité",{"href":528,"dataGaName":529,"dataGaLocation":473},"/fr-fr/privacy/","privacy statement",{"text":531,"config":532},"Gérer vos cookies",{"dataGaName":533,"dataGaLocation":473,"id":534,"isOneTrustButton":14},"cookie preferences","ot-sdk-btn",{"title":91,"links":536,"subMenu":545},[537,541],{"text":538,"config":539},"Plateforme DevSecOps",{"href":73,"dataGaName":540,"dataGaLocation":473},"devsecops platform",{"text":542,"config":543},"Développement assisté par l'IA",{"href":80,"dataGaName":544,"dataGaLocation":473},"ai-assisted development",[546],{"title":547,"links":548},"Thèmes",[549,552,557,562,567,570,575,580],{"text":22,"config":550},{"href":551,"dataGaName":37,"dataGaLocation":473},"/fr-fr/topics/ci-cd/",{"text":553,"config":554},"GitOps",{"href":555,"dataGaName":556,"dataGaLocation":473},"/fr-fr/topics/gitops/","gitops",{"text":558,"config":559},"DevOps",{"href":560,"dataGaName":561,"dataGaLocation":473},"/fr-fr/topics/devops/","devops",{"text":563,"config":564},"Contrôle de version",{"href":565,"dataGaName":566,"dataGaLocation":473},"/fr-fr/topics/version-control/","version control",{"text":23,"config":568},{"href":569,"dataGaName":11,"dataGaLocation":473},"/fr-fr/topics/devsecops/",{"text":571,"config":572},"Cloud-native",{"href":573,"dataGaName":574,"dataGaLocation":473},"/fr-fr/topics/cloud-native/","cloud native",{"text":576,"config":577},"IA pour la programmation",{"href":578,"dataGaName":579,"dataGaLocation":473},"/fr-fr/topics/devops/ai-for-coding/","ai for coding",{"text":581,"config":582},"IA agentique",{"href":583,"dataGaName":584,"dataGaLocation":473},"/fr-fr/topics/agentic-ai/","agentic ai",{"title":586,"links":587},"Solutions",[588,591,593,598,601,604,607,610,613,616,619,624],{"text":133,"config":589},{"href":128,"dataGaName":590,"dataGaLocation":473},"Application Security Testing",{"text":120,"config":592},{"href":105,"dataGaName":106,"dataGaLocation":473},{"text":594,"config":595},"Développement Agile",{"href":596,"dataGaName":597,"dataGaLocation":473},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":115,"config":599},{"href":117,"dataGaName":600,"dataGaLocation":473},"source code management",{"text":22,"config":602},{"href":110,"dataGaName":603,"dataGaLocation":473},"continuous integration & delivery",{"text":159,"config":605},{"href":161,"dataGaName":606,"dataGaLocation":473},"value stream management",{"text":553,"config":608},{"href":609,"dataGaName":556,"dataGaLocation":473},"/fr-fr/solutions/gitops/",{"text":611,"config":612},"Entreprises",{"href":174,"dataGaName":175,"dataGaLocation":473},{"text":614,"config":615},"PME",{"href":179,"dataGaName":180,"dataGaLocation":473},{"text":617,"config":618},"Secteur public",{"href":184,"dataGaName":185,"dataGaLocation":473},{"text":620,"config":621},"Éducation",{"href":622,"dataGaName":623,"dataGaLocation":473},"/fr-fr/solutions/education/","education",{"text":625,"config":626},"Services financiers",{"href":627,"dataGaName":628,"dataGaLocation":473},"/fr-fr/solutions/finance/","financial services",{"title":192,"links":630},[631,633,635,637,640,642,644,646,648,650,652,654],{"text":204,"config":632},{"href":206,"dataGaName":207,"dataGaLocation":473},{"text":209,"config":634},{"href":211,"dataGaName":212,"dataGaLocation":473},{"text":214,"config":636},{"href":216,"dataGaName":217,"dataGaLocation":473},{"text":219,"config":638},{"href":221,"dataGaName":639,"dataGaLocation":473},"docs",{"text":242,"config":641},{"href":244,"dataGaName":245,"dataGaLocation":473},{"text":237,"config":643},{"href":239,"dataGaName":240,"dataGaLocation":473},{"text":247,"config":645},{"href":249,"dataGaName":250,"dataGaLocation":473},{"text":255,"config":647},{"href":257,"dataGaName":258,"dataGaLocation":473},{"text":260,"config":649},{"href":262,"dataGaName":263,"dataGaLocation":473},{"text":265,"config":651},{"href":267,"dataGaName":268,"dataGaLocation":473},{"text":270,"config":653},{"href":272,"dataGaName":273,"dataGaLocation":473},{"text":275,"config":655},{"href":277,"dataGaName":278,"dataGaLocation":473},{"title":293,"links":657},[658,660,662,664,666,668,670,675,680,682,684,686],{"text":300,"config":659},{"href":302,"dataGaName":295,"dataGaLocation":473},{"text":305,"config":661},{"href":307,"dataGaName":308,"dataGaLocation":473},{"text":313,"config":663},{"href":315,"dataGaName":316,"dataGaLocation":473},{"text":318,"config":665},{"href":320,"dataGaName":321,"dataGaLocation":473},{"text":323,"config":667},{"href":325,"dataGaName":326,"dataGaLocation":473},{"text":328,"config":669},{"href":330,"dataGaName":331,"dataGaLocation":473},{"text":671,"config":672},"Développement durable",{"href":673,"dataGaName":674,"dataGaLocation":473},"/sustainability/","Sustainability",{"text":676,"config":677},"Diversité, inclusion et appartenance (DIB)",{"href":678,"dataGaName":679,"dataGaLocation":473},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":333,"config":681},{"href":335,"dataGaName":336,"dataGaLocation":473},{"text":343,"config":683},{"href":345,"dataGaName":346,"dataGaLocation":473},{"text":348,"config":685},{"href":350,"dataGaName":351,"dataGaLocation":473},{"text":687,"config":688},"Déclaration de transparence sur l'esclavage moderne",{"href":689,"dataGaName":690,"dataGaLocation":473},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":692},[693,695,698],{"text":521,"config":694},{"href":523,"dataGaName":524,"dataGaLocation":473},{"text":696,"config":697},"Gestion des cookies",{"dataGaName":533,"dataGaLocation":473,"id":534,"isOneTrustButton":14},{"text":526,"config":699},{"href":528,"dataGaName":529,"dataGaLocation":473},[701],{"id":702,"title":9,"body":26,"config":703,"content":705,"description":26,"extension":25,"meta":709,"navigation":14,"path":710,"seo":711,"stem":712,"__hash__":713},"blogAuthors/en-us/blog/authors/fernando-diaz.yml",{"template":704},"BlogAuthor",{"name":9,"config":706},{"headshot":707,"ctfId":708},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659556/Blog/Author%20Headshots/fern_diaz.png","fjdiaz",{},"/en-us/blog/authors/fernando-diaz",{},"en-us/blog/authors/fernando-diaz","lxRJIOydP4_yzYZvsPcuQevP9AYAKREF7i8QmmdnOWc",[715,728,740],{"content":716,"config":726},{"title":717,"description":718,"authors":719,"date":722,"body":723,"category":11,"tags":724,"heroImage":725},"Automatisez les étapes de votre cycle de développement avec GitLab CI/CD","GitLab CI/CD automatise vos builds, tests et déploiements depuis une plateforme DevSecOps unifiée. Découvrez son fonctionnement, ses composants clés et ses fonctionnalités avancées pour des cycles de livraison plus rapides et fiables.",[720,721],"Charlotte Delbosc","Maud Leuenberger","2026-04-22","Les équipes les plus performantes déploient leur code plusieurs fois par jour, avec un délai de mise en production inférieur à une heure, contre plusieurs jours voire plusieurs semaines pour les équipes moins avancées. Cette performance repose sur quelques principes fondamentaux : détecter les erreurs le plus tôt dans le processus de développement, tester en continu et éviter d’accumuler des modifications difficiles à stabiliser.\n\nC'est là qu'intervient **[GitLab CI/CD](https://docs.gitlab.com/ci/)** : en automatisant les builds, les tests et les déploiements dans un même environnement, les équipes peuvent livrer plus vite, avec moins de risques et une meilleure visibilité sur chaque étape du cycle de développement logiciel.\n\nDans cet article, nous explorerons comment GitLab CI/CD fonctionne et comment le mettre en place pour des cycles de livraison plus rapides, plus fiables et mieux structurés.\n\n> **[→ Commencez un essai gratuit de GitLab Ultimate.](https://about.gitlab.com/fr-fr/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr)**\n\n## Qu’est-ce que GitLab CI/CD ?\n\nLe **[CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\")** regroupe deux pratiques complémentaires : \n\n- **CI pour « continuous integration » (intégration continue)** : intégrer régulièrement des modifications de code pour détecter les erreurs le plus tôt possible dans le cycle de développement logiciel.\n- **CD pour « continuous delivery/deployment » (livraison continue/déploiement continu)** : préparer automatiquement chaque modification pour qu'elle soit prête à être déployée en production à tout moment. Le déploiement continu va plus loin en déclenchant automatiquement la mise en production, sans intervention humaine.\n\nEnsemble, ces pratiques évitent l’accumulation de changements difficiles à stabiliser et réduisent le délai entre un commit et son déploiement.\n\n**GitLab intègre nativement le CI/CD dans sa plateforme où résident déjà le code, les merge requests, la sécurité et les déploiements.** Les pipelines s’exécutent sans nécessiter de plugins ni d’outils externes, ce qui simplifie la configuration et offre une vue centralisée sur l’ensemble du workflow de développement. Sur GitLab.com, des **runners partagés Linux, Windows et macOS** sont également **disponibles sans configuration initiale**, ce qui facilite le démarrage.\n\nConcrètement, **chaque modification déclenche un pipeline qui construit le logiciel, exécute les tests, analyse la sécurité et prépare une version déployable.** Les équipes obtiennent des retours immédiats, ce qui leur permet d'identifier les erreurs tôt et de travailler de manière itérative. \n\nGrâce à cette centralisation, la collaboration est facilitée et l'état du logiciel reste visible et compréhensible à chaque étape de son cycle de développement.\n\n## Pourquoi GitLab CI/CD est devenu une référence dans le développement logiciel ?\n\nDans de nombreuses organisations, l'adoption du CI/CD se heurte à un obstacle récurrent : la fragmentation des outils. Une chaîne de développement qui repose sur des solutions trop nombreuses et disparates devient rapidement lente, difficile à maintenir et propice aux erreurs de configuration.\n\nFace à cette fragmentation, GitLab apporte une réponse concrète : une plateforme qui **réunit le code, les pipelines, la sécurité et le déploiement dans un seul et même environnement.** Les équipes n'ont plus à gérer de multiples outils, ce qui réduit la complexité et fluidifie l'ensemble du workflow de développement logiciel.\n\nAinsi, **les logs, artefacts, résultats de tests et statuts de déploiement cohabitent dans le même espace que le code**, ce qui offre un gain de visibilité significatif aux équipes. Les pipelines se déclenchent directement depuis les merge requests pour obtenir des retours plus rapidement et limiter les régressions tardives.\n\nCette cohérence, alliée à la possibilité d’intégrer dès le départ l’analyse de sécurité ou la gestion des dépendances, explique pourquoi **GitLab CI/CD est aujourd’hui largement adopté par les organisations qui cherchent à fluidifier leurs cycles de livraison logicielle.**\n\n> **Radio France déploie 5 fois plus rapidement avec GitLab CI/CD**\n>\n> Radio France, la société nationale de radiodiffusion française, compte sept stations dans tout le pays. Radio France conçoit, développe et exploite des sites web, des applications mobiles, des API, des podcasts, des assistants vocaux et des plateformes de streaming audio.\n>\n> Avant d'adopter GitLab CI/CD, les équipes utilisaient GitLab pour le code source et Jenkins pour tous les builds en production, ce qui les obligeait à basculer constamment entre les deux outils.\n>\n> Après avoir migré l'ensemble de leurs pipelines vers GitLab CI/CD, les résultats ont été immédiats :\n>\n> - **5x plus rapide de déployer**\n>\n> - **82 % de réduction de la durée de cycle**\n>\n> - **70 % d'économies annuelles sur les coûts CI/CD**\n>\n> *« Nous étions à 10 déploiements par jour avant la migration. Maintenant, avec GitLab, nous effectuons 50 déploiements par jour en production. Nous n'avons plus à basculer entre GitLab et Jenkins. »* — Julien Vey, Operational Excellence Manager, Radio France\n>\n> [Lire le cas client complet >](https://about.gitlab.com/fr-fr/customers/radiofrance/)\n\n## Comment fonctionne un pipeline GitLab CI/CD ?\n\nDans GitLab, **un pipeline est une suite d’étapes exécutées automatiquement à chaque modification du code.** Il se déclenche lors d’un commit, d’une merge request ou d’un événement planifié. Son rôle est de valider la modification et de produire les artefacts nécessaires. Si tout est conforme, il prépare ou déclenche directement le déploiement. \n\n### Les étapes et les jobs\n\nUn pipeline GitLab est composé d'**étapes** (build, test, déploiement…), chacune regroupant un ou plusieurs **jobs**. Les jobs indiquent les actions à exécuter, comme compiler le code ou lancer une suite de tests. **GitLab exécute les jobs d'une même étape en parallèle (en fonction de la disponibilité des runners), gère les dépendances et passe automatiquement à l'étape suivante lorsque tous les jobs de la précédente sont terminés.** Les logs associés à chaque job permettent de suivre l'exécution en détail.\n\nPar défaut, GitLab attend que tous les jobs d'une étape soient terminés avant de passer à la suivante. Pour les pipelines où cette séquence stricte n'est pas nécessaire, le mot-clé `needs:` permet de définir des dépendances directes entre jobs, indépendamment de leur étape. Un job peut ainsi démarrer dès qu'un job précis est terminé, sans avoir à attendre la fin de toute l'étape. Cette approche, appelée **DAG (Directed Acyclic Graph)**, peut réduire considérablement la durée totale d'un pipeline en parallélisant davantage l'exécution. Dans l’interface, ces pipelines apparaissent sous forme de graphe de dépendances, ce qui facilite la compréhension de l’ordre réel d’exécution.\n\n### Les artefacts et le cache : transfert et réutilisation\n\nLes artefacts et le cache sont deux mécanismes de persistance de fichiers entre jobs, souvent confondus.\n\nLes **artefacts** sont les **fichiers générés par un job**, comme un binaire, un rapport de test ou un paquet. Ils peuvent être transmis aux jobs suivants ou conservés pendant une durée définie. Cette gestion intégrée évite les transferts manuels et facilite la **reproductibilité des pipelines.**\n\nLe **cache**, quant à lui, **permet de réutiliser des fichiers entre plusieurs exécutions d'un même pipeline**, typiquement les dépendances (node_modules, packages Maven, gems Ruby…). \n\nLà où les artefacts transfèrent des fichiers d'un job au suivant au sein d'un même pipeline, le cache évite de re-télécharger les mêmes ressources à chaque nouvelle exécution. C'est souvent l'une des premières optimisations à mettre en place pour réduire significativement la durée des pipelines.\n\nEn pratique : les artefacts sont obligatoires pour le job suivant, alors que le cache est optionnel et uniquement là pour aller plus vite.\n\n### Les runners : là où s’exécutent réellement les jobs\n\nLes runners sont les **machines qui exécutent réellement les jobs.** GitLab propose des runners hébergés sur GitLab.com (Linux, Windows, macOS) ou permet d’en installer sur ses propres serveurs ou environnements cloud, notamment en s’appuyant sur la [conteneurisation](https://about.gitlab.com/fr-fr/blog/what-is-containerization/ \"Qu'est-ce que la conteneurisation ?\").\n\nLorsqu'on installe son propre runner, il faut également choisir un executor, c'est-à-dire le mécanisme par lequel le runner exécute les jobs. \n\nLes [executors](https://docs.gitlab.com/runner/executors/) les plus courants sont :\n\n- **Docker** : il exécute chaque job dans un conteneur isolé. Il est rapide, flexible et recommandé pour la majorité des projets.\n\n- **Shell** : il exécute directement les jobs sur la machine hôte. Il est simple, mais sans isolation.\n\n- **[Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\")** : il exécute les jobs dans des pods Kubernetes, avec une scalabilité native.\n\nLe choix de l'executor conditionne directement l'isolation, la reproductibilité et les performances des jobs. Il est indépendant du runner lui-même et se configure au moment de l'installation.\n\nLes tags associés aux runners permettent de cibler un environnement spécifique et d’adapter l’exécution aux besoins du pipeline.\n\nPour en savoir plus sur les runners de GitLab, consultez notre article de blog « [GitLab Runner : installation, configuration et bonnes pratiques pour vos pipelines CI/CD](https://about.gitlab.com/fr-fr/blog/what-is-gitlab-runner/ \"Qu'est-ce qu'un GitLab Runner ?\") ».\n\n### Configuration d’un pipeline GitLab CI/CD\n\nTout pipeline GitLab prend forme dans un fichier **.gitlab-ci.yml** placé à la racine du projet. Ce fichier définit les étapes, les jobs, les scripts à exécuter, les variables, les dépendances ou encore les artefacts à conserver. GitLab lit ce fichier à chaque modification de code et déclenche un pipeline conforme à sa configuration.\n\nIl est utile de distinguer deux types de pipelines selon leur contexte de déclenchement : \n- Le **pipeline de branche** s'exécute lors d'un push direct sur une branche. \n- Le **pipeline de merge request** se déclenche dès qu'une merge request est ouverte ou mise à jour. Il peut s’exécuter soit sur le contenu de la branche source, soit sur le résultat simulé du merge avec la branche cible (grâce aux [pipelines de résultats de merge](https://docs.gitlab.com/ci/pipelines/merged_results_pipelines/)), avant même que celle-ci ne soit effectuée.\n\nCette distinction est importante en pratique : elle permet de réserver certains jobs coûteux ou sensibles (comme les scans de sécurité approfondis ou les déploiements) à un contexte précis, et d'obtenir un retour sur la qualité du code fusionné le plus tôt possible. C'est l'un des leviers concrets pour détecter les régressions avant qu'elles n'atteignent la branche principale.\n\nVoici un exemple de fichier `.gitlab-ci.yml` illustrant la structure d'un pipeline GitLab :\n\n```yaml\nstages:          # Définit l'ordre d'exécution des étapes du pipeline\n  - build\n  - test\n  - deploy\n\nvariables:       # Variables accessibles par tous les jobs du pipeline\n  APP_ENV: \"production\"\n\nbuild-job:\n  stage: build\n  image: node:20                    # Image Docker utilisée pour exécuter ce job\n  cache:\n    key: $CI_COMMIT_REF_SLUG        # Cache propre à chaque branche\n    paths:\n      - node_modules/               # Dossier de dépendances mis en cache\n  script:\n    - echo \"Compilation du code...\"\n  artifacts:\n    paths:\n      - dist/                       # Fichiers générés transmis aux jobs suivants\n    expire_in: 1 hour               # Durée de conservation de l'artefact\n\ntest-job:\n  stage: test\n  image: node:20\n  needs: [\"build-job\"]             # Démarre dès que build-job est terminé (DAG)\n  script:\n    - echo \"Exécution des tests...\"\n\ndeploy-job:\n  stage: deploy\n  script:\n    - echo \"Déploiement en production...\"\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"  # S'exécute uniquement sur la branche principale\n```\n\nCe pipeline illustre plusieurs mécanismes clés de GitLab CI/CD : \n\n- La variable `APP_ENV` est accessible par l'ensemble des jobs. \n\n- Le `build-job` utilise une image Docker Node.js 20, met en cache les dépendances pour accélérer les exécutions suivantes, et produit un artefact, le dossier `dist/`, transmis automatiquement aux jobs suivants. \n\n- Le `test-job` démarre dès que le build est terminé grâce au mot-clé `needs:`, sans attendre la fin de l'étape entière. \n\n- Le `deploy-job` ne s'exécute que sur la branche principale, via une règle `rules:`.\n\nPour les équipes qui débutent avec le CI/CD, GitLab propose également la fonctionnalité d’**[Auto DevOps](https://docs.gitlab.com/topics/autodevops/)** qui détecte automatiquement le langage de votre projet et configure un pipeline prêt à l'emploi, sans fichier `.gitlab-ci.yml`. Auto DevOps couvre les étapes de build, de test, d'analyse de sécurité et de déploiement, et peut être personnalisé progressivement selon vos besoins.\n\n**Bon à savoir** : Comme montré dans l’exemple, GitLab peut exécuter un job à partir d’une image [Docker](https://about.gitlab.com/fr-fr/blog/what-is-docker-comprehensive-guide/ \"Qu'est-ce que Docker ?\") spécifique, définie via le mot-clé `image:` dans le fichier `.gitlab-ci.yml`. Une image par défaut peut être configurée pour l’ensemble du pipeline, tandis que chaque job peut utiliser sa propre image si nécessaire. Cette flexibilité permet d’adapter l’environnement d’exécution à chaque étape, sans maintenance manuelle de serveurs. Les images peuvent provenir du Docker Hub ou du registre de conteneurs de GitLab ([GitLab Container Registry](https://docs.gitlab.com/user/packages/container_registry/)), ce qui permet de choisir rapidement l’environnement adapté.\n\n## Les fonctionnalités avancées de GitLab CI/CD\n\n### Les variables pour personnaliser et sécuriser un pipeline\n\nLes **[variables CI/CD](https://docs.gitlab.com/ci/variables/)** permettent de **transmettre des valeurs aux jobs sans les inscrire directement dans le code.** Elles peuvent contenir des paramètres techniques, des clés d’API ou des informations sensibles.\n\n**GitLab distingue plusieurs types de variables** : personnalisées, prédéfinies, protégées, masquées ou de type fichier. Cette granularité **facilite la configuration et limite l’exposition d’informations critiques dans les logs.**\n\n### Les règles CI/CD pour rendre les pipelines dynamiques\n\nLes règles (`rules:`) permettent d'adapter la logique du pipeline en fonction du contexte d'exécution. Elles s'appuient sur des conditions comme `if:`, `changes:` ou `exists:` pour contrôler quand un job doit s'exécuter.\n\nElles permettent par exemple d'activer certaines étapes selon la branche ou de déclencher des comportements différents selon le type de pipeline exécuté. C'est un moyen d'alléger la configuration et de conserver un pipeline adaptable.\n\n### Les composants et le catalogue CI/CD pour construire des pipelines réutilisables\n\nLes **composants CI/CD ([CI/CD components](https://docs.gitlab.com/ci/components/))** sont des **blocs de configuration réutilisables**. Ils peuvent représenter un ensemble de jobs, une intégration, une logique de test ou un processus de déploiement.\n\nCes composants peuvent être publiés dans le **catalogue CI/CD ([CI/CD catalog](https://docs.gitlab.com/ci/components/#cicd-catalog))**, une spécificité de GitLab qui permet de les partager à l’échelle d’une équipe ou de l’organisation. Cela réduit la duplication des tâches et rend la maintenance des pipelines beaucoup plus souple.\n\n**Bon à savoir** : Le catalogue CI/CD inclut des composants publiés par GitLab et la communauté pour des environnements courants comme Java/Maven, ce qui évite de recréer des configurations complexes pour chaque projet.\n\n### Les groupes de ressources pour contrôler les déploiements concurrents\n\nLes **groupes de ressources** permettent de **limiter l’exécution simultanée de certains jobs.** Ils sont particulièrement utiles pour les déploiements, afin d’**éviter que deux pipelines ne modifient un même environnement au même moment.** GitLab met en file d’attente les jobs qui partagent un même groupe et n’en exécute qu'un seul à la fois.\n\n### Les environnements pour gérer et suivre les déploiements\n\nLes environnements de GitLab permettent de définir et de suivre les cibles de déploiement, comme la préproduction ou la production. Chaque déploiement est associé à un environnement, ce qui offre une traçabilité complète : qui a déployé quoi, quand et depuis quel pipeline.\n\nLes environnements peuvent être protégés pour restreindre les déploiements à certaines branches ou à certains utilisateurs, ce qui réduit les risques d'erreurs en production. GitLab affiche également l'état de chaque environnement en temps réel, directement depuis l'interface.\n\n### Les Review Apps pour tester chaque merge request dans un environnement dédié\n\nLes **environnements éphémères (ou [Review Apps](https://docs.gitlab.com/ci/review_apps/))** poussent la logique des environnements un cran plus loin : GitLab peut déployer automatiquement un environnement éphémère pour chaque merge request, accessible via un lien directement depuis l'interface. Chaque modification devient ainsi testable dans des conditions réelles, sans attendre une intégration dans la branche principale.\n\nL'environnement est détruit automatiquement à la fermeture de la merge request, ce qui évite toute accumulation de ressources inutiles. Pour les équipes qui impliquent des profils non techniques dans le processus de validation (product managers, designers, équipes QA) c'est un levier concret pour raccourcir les cycles de revue et détecter les régressions plus tôt.\n\n### Pipelines parent-enfant et multi-projets\n\nGitLab peut **déclencher un pipeline depuis un autre pipeline (modèle parent-enfant) ou orchestrer plusieurs projets dans un workflow commun (pipelines multi-projets).**\n\nCes mécanismes sont utilisés pour les architectures modulaires, les [monorepos](https://about.gitlab.com/fr-fr/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way/), les écosystèmes multicomposants ou les déploiements distribués. Ils permettent de découper les pipelines tout en conservant une coordination centralisée.\n\n## Comment GitLab CI/CD s’intègre dans votre démarche DevSecOps ?\n\nGitLab CI/CD ne se limite pas à automatiser les livraisons : il relie aussi naturellement le développement, la sécurité et les opérations ([DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\")) au sein d'un même workflow.\n\n### Build, test, sécurité et déploiement dans un même environnement\n\n**GitLab CI/CD s’exécute directement là où se trouvent déjà le code, les merge requests, la sécurité et les déploiements.** Cela réduit les frictions entre équipes : les développeurs disposent d’un pipeline qui teste, analyse et prépare les déploiements, tandis que les équipes sécurité et opérations visualisent les effets de chaque modification dans un même espace.\n\n### Sécurité intégrée dans les pipelines de GitLab\n\nLes scans SAST, DAST, l’analyse des dépendances ou l’analyse des conteneurs peuvent être ajoutés comme jobs standard du pipeline, selon votre abonnement GitLab.\n\n**Comme ces fonctionnalités sont intégrées nativement, elles ne nécessitent ni outils externes ni configuration lourde.** Les résultats s’affichent dans les merge requests, ce qui permet d’aborder la sécurité en amont, sans ralentir les cycles de développement.\n\nAu-delà des scans intégrés, un job peut aussi invoquer un outil tiers comme SonarQube pour compléter l’analyse de qualité du code et détecter la dette technique.\n\n### Retour continu entre les équipes\n\nChaque pipeline fournit des logs, des rapports de tests, des alertes de sécurité et des informations sur les déploiements, consultables dans une seule interface.\n\nLes **retours sont donc immédiats** : une erreur de test, un échec de build ou une alerte de vulnérabilité apparaît directement dans la merge request. Cela **facilite les arbitrages et favorise des décisions rapides et éclairées à chaque étape du cycle de développement**.\n\n## L'IA au cœur du cycle DevSecOps avec GitLab Duo Agent Platform\n\nGitLab intègre des capacités d'IA à chaque étape du cycle de développement logiciel via **[GitLab Duo Agent Platform](https://about.gitlab.com/fr-fr/gitlab-duo-agent-platform/ \"GitLab Duo Agent Platform\")**, une plateforme d’agents spécialisés qui collaborent autour du code, des pipelines et des outils existants. L’objectif n’est pas de remplacer les équipes, mais de leur fournir des agents qui automatisent les tâches répétitives, orchestrent les workflows et accélèrent les décisions tout au long du pipeline.\n\n### Agents pour l’écriture, la revue et l’industrialisation du code \n\nAvec **GitLab Duo Agent Platform**, les capacités d’IA ne se limitent plus à de simples complétions : elle se matérialise sous forme d’**agents GitLab Duo disponibles par défaut (Foundational agents)** (proposés par GitLab, prêts à l’emploi) et d’**agents GitLab Duo personnalisés** (configurés par vos équipes) que vous pouvez adapter à vos propres projets.\n\n- **L’agent GitLab Duo orienté code (Foundational agent).** Cet agent s’appuie sur les capacités natives de GitLab Duo (complétion, génération et refactorisation de code) dans l’[IDE](https://about.gitlab.com/fr-fr/blog/what-is-an-ide/ \"Qu'est-ce qu'un IDE ?\") et le Web IDE. Il aide les équipes à écrire, adapter ou moderniser le code tout en respectant les standards et conventions de vos projets.\n\n- **L’agent GitLab Duo CI/CD personnalisé.** Avec GitLab Duo Agent Platform, il est possible de définir un agent spécialisé CI/CD : il peut générer ou corriger un fichier `.gitlab-ci.yml`, expliquer un pipeline existant, proposer des optimisations (cache, parallélisation, stratégie de runners) et diagnostiquer les erreurs de jobs. Cet agent est personnalisé par les équipes, en fonction de leurs patterns et de leurs contraintes.\n\n- **L’agent GitLab Duo Doc & Connaissance personnalisé.** En s’appuyant sur GitLab Duo Chat connecté au contexte de GitLab, un agent “Connaissance projet” permet d’interroger en langage naturel le code, les merge requests, les tickets et la configuration CI/CD pour comprendre rapidement l’état d’un projet ou la cause probable d’un échec de build. Cet agent exploite les mêmes fondations que GitLab Duo Chat, mais est spécialisé sur votre périmètre (projets, groupes) et vos règles internes.\n\nPour en savoir plus sur les agents d’IA par défaut, personnalisables et externes disponibles sur GitLab Duo Agent Platform, [consultez notre documentation](https://docs.gitlab.com/user/duo_agent_platform/agents/).  \n\n### Analyse proactive des merge requests par des agents \n\nPlutôt qu’un simple résumé automatique, GitLab Duo Agent Platform permet de confier la merge request à un **agent dédié GitLab** (par exemple l’*[agent CI Expert](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/ci_expert_agent/)*) ou à un **flow par défaut (Foundational flow) spécialisé dans la revue de code** (par exemple le flow *[Code Review](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/code_review/)*) qui :\n\n- Synthétise les changements (fonctionnels, sécurité, performance) et met en avant les impacts majeurs.\n- Signale les risques potentiels (endroits sensibles du code, dettes techniques aggravées, modifications de contrats d’API).\n- Propose des points d’attention ciblés pour les relecteurs, voire des suggestions de corrections ou de tests manquants.\n\nCes capacités aident à réduire le temps de revue, à standardiser la qualité des merge requests et à impliquer des profils moins techniques dans l’évaluation des changements.\n\n### IA et sécurité : agents pour expliquer, corriger et gouverner les vulnérabilités \n\nAvec GitLab Duo Agent Platform, la sécurité est prise en charge par un ou plusieurs **agents orientés AppSec** (par exemple l’*[agent Security Analyst](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/)*) qui :\n\n- Consomment les résultats des scans de sécurité (SAST, DAST, analyse des dépendances, analyse des conteneurs, etc.).\n- Expliquent chaque vulnérabilité dans le langage de l’équipe (contexte, scénario d’attaque probable, impact métier).\n- Proposent des patchs concrets ou des refactorings, que les équipes de développement peuvent appliquer et ajuster.\n- Aident à prioriser les vulnérabilités en croisant criticité, surface d’exposition, historique du projet et politiques internes.\n\nCes agents permettent de passer d’une gestion réactive des vulnérabilités à une **gouvernance continue de la posture de sécurité**, directement intégrée dans les pipelines et les merge requests.\n\n### GitLab Duo Agent Platform : vers des pipelines autonomes \n\n**GitLab Duo Agent Platform** représente l'étape suivante : non plus seulement déclencher des jobs prévus à l’avance, mais **confier des tâches complètes à des agents d’IA** capables de raisonner sur l’état du projet et du pipeline. \n\nUn agent peut par exemple analyser un échec de build, proposer un correctif, ouvrir ou mettre à jour une merge request, relancer les jobs nécessaires, ou encore alerter les bonnes personnes avec un résumé exploitable. Cette approche commence à transformer la notion même de pipeline CI/CD : nous passons d’une **automatisation statique** (des scripts fixés dans `.gitlab-ci.yml`) à une **orchestration adaptative**, où des agents spécialisés et des flows agentiques collaborent autour du pipeline pour diagnostiquer, corriger et optimiser en continu.\n\n## Pourquoi choisir GitLab CI/CD ?\n\n### Une plateforme qui simplifie le CI/CD\n\nLa plupart des outils CI reposent sur une logique d'assemblage : un outil pour le code, un autre pour les tests, un autre pour la sécurité, puis un outil de déploiement. Cette fragmentation complique la maintenance et disperse les informations entre plusieurs interfaces.\n\nGitLab adopte une **approche unifiée** : le code, les pipelines, la sécurité, la revue et les déploiements reposent sur une seule plateforme, pour des workflows plus simples et plus cohérents.\n\n### Des fonctionnalités propres à GitLab\n\nGitLab CI/CD dispose de capacités propres à la plateforme et difficiles à reproduire avec une chaîne d'outils fragmentée :\n\n- le catalogue CI/CD (CI/CD Catalog) et les composants (CI/CD components) pour standardiser les pipelines,\n- les runners hébergés par GitLab sur GitLab.com (Linux, Windows, macOS),\n- l’intégration native de la sécurité dans les pipelines,\n- l'éditeur de pipeline ([Pipeline Editor](https://docs.gitlab.com/ci/pipeline_editor/)), un éditeur intégré avec validation en temps réel et visualisation du graphe du pipeline,\n- la gestion complète des merge requests et des protections de branches intégrée au cycle CI/CD,\n- l’IA intégrée à chaque étape du cycle de développement logiciel avec GitLab Duo Agent Platform. \n\nCes éléments permettent de **construire des pipelines complets sans dépendre d’extensions ou de services externes**.\n\n### Une expérience DevSecOps unifiée\n\nComme **l’ensemble du workflow de développement repose sur un environnement unique**, chaque modification bénéficie automatiquement des tests, des analyses de sécurité, des logs de déploiement et des retours dans les merge requests.\n\n**Les équipes travaillent donc sur un cycle continu**, avec moins de ruptures contextuelles et une vue consolidée de la qualité du logiciel à chaque étape.\n\n## Par où commencer avec GitLab CI/CD ?\n\nGitLab CI/CD est conçu pour s'adapter à tous les niveaux de maturité. \n\nLes équipes qui débutent peuvent s'appuyer sur la fonctionnalité Auto DevOps pour obtenir un premier pipeline fonctionnel sans configuration, puis affiner progressivement leur fichier `.gitlab-ci.yml` au fur et à mesure que leurs besoins évoluent.\n\nPour les équipes déjà avancées, les composants du catalogue CI/CD, les pipelines DAG, les Review Apps et l'intégration native de la sécurité permettent de construire des workflows robustes, reproductibles et adaptés à des architectures complexes.\n\nGitLab Duo Agent Platform vient compléter cet ensemble en apportant une couche d'intelligence à chaque étape : assistance à la configuration, analyse des vulnérabilités, résumé des merge requests et, progressivement, des agents capables d'agir de manière autonome dans les pipelines.\n\nDans les deux cas, l'objectif reste le même : réduire le délai entre un commit et sa mise en production, tout en maintenant un niveau de qualité et de fiabilité élevé à chaque étape.\n\n> **[→ Prêt à franchir le pas ? Commencez un essai gratuit de GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr) et explorez l'ensemble des fonctionnalités CI/CD dans votre propre environnement.**\n\n> ### GitLab CI/CD en résumé\n> GitLab CI/CD réunit dans une même plateforme l’ensemble du cycle DevSecOps : le code, les pipelines, les tests, la sécurité, les artefacts et les déploiements. Cette intégration évite la multiplication d’outils et permet de suivre chaque modification de code jusqu’à sa mise en production dans un environnement cohérent.\n>\n> Un pipeline GitLab s’appuie sur plusieurs éléments clés :\n> - un fichier `.gitlab-ci.yml` qui définit les étapes et les jobs,\n> - des runners qui exécutent les tâches,\n> - des artefacts pour transmettre ou conserver les fichiers produits,\n> - le cache pour accélérer les exécutions en évitant de re-télécharger les dépendances à chaque pipeline,\n> - des variables pour adapter le comportement du pipeline en toute sécurité,\n> - le catalogue CI/CD et les composants pour standardiser les configurations à l’échelle d’un projet ou d’une organisation.\n>\n> Cette structure offre un espace unique pour analyser les résultats des tests, vérifier les analyses de sécurité et suivre les déploiements.\n>\n> GitLab Duo Agent Platform vient enrichir cette structure en y apportant une couche d'intelligence : des agents capables d'assister la configuration, d'analyser les vulnérabilités et d'orchestrer des actions correctives de manière autonome.",[22,23,558],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1775561395/bhe1as7ttjvzltxwgo5m.png",{"featured":31,"template":15,"slug":727},"what-is-gitlab-ci-cd",{"content":729,"config":738},{"title":730,"description":731,"authors":732,"date":734,"body":735,"category":11,"tags":736,"heroImage":737},"Conteneurs et machines virtuelles : quelle différence ?","Les conteneurs et les machines virtuelles sont deux approches de virtualisation aux architectures différentes. Découvrez-en davantage sur leur fonctionnement et leurs principales différences.  ",[733],"GitLab France Team","2026-03-03","Les conteneurs et les machines virtuelles sont deux technologies de virtualisation des ressources, essentielles pour le développement logiciel moderne. La machine virtuelle propose une copie numérique complète d'une machine physique, tandis que le conteneur partage le noyau du système d'exploitation hôte et n'embarque que les dépendances applicatives nécessaires à l'exécution de l'application.\n\nDans cet article, découvrez les différences architecturales entre ces deux approches et leurs champs d'application respectifs.\n\n> Essayez [GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr) gratuitement dès aujourd'hui !\n\n## Qu’est-ce qu’une machine virtuelle ?\n\n### Définition et fonctionnement\n\nLa machine virtuelle, ou virtual machine (VM) est un environnement informatique entièrement virtualisé qui reproduit virtuellement ses propres composants (CPU, GPU, mémoire RAM, disque dur et carte réseau) et exécute son propre système d’exploitation (OS).\n\nPlusieurs machines virtuelles peuvent coexister sur une même machine physique, chacune isolée des autres.\n\nLa création d'une machine virtuelle est rendue possible grâce à l'installation d'un hyperviseur sur un OS hôte. Cet outil de virtualisation effectue la partition des ressources matérielles et affecte des quotas système dédiés (processeur, mémoire, stockage, réseau) à chaque machine virtuelle.\n\nIl existe deux types d'hyperviseurs : les hyperviseurs de Type 1 (installés directement sur le matériel physique) et de Type 2 (installés sur un système d'exploitation hôte).\n\n### Avantages et limites de la machine virtuelle\n\nLa technologie de machine virtuelle offre une isolation forte sur machine physique. Résultat, le déploiement des machines virtuelles s'effectue dans un environnement étanche et sécurisé. Même si une machine virtuelle est piratée, elle ne pourra pas contaminer les autres machines. \n\nLe principe de fonctionnement via hyperviseur assure également une compatibilité optimale avec de multiples environnements. Une machine virtuelle peut ainsi être déployée sur différents systèmes d’exploitation hôtes comme Windows, Linux, macOS ou un serveur physique.\n\nToutefois, la machine virtuelle classique présente un inconvénient majeur : sa consommation de ressources. Elle est plus lourde qu’un conteneur, car chaque machine virtuelle embarque un système d’exploitation complet. Ce système a également tendance à offrir des démarrages plus longs que la [conteneurisation](https://about.gitlab.com/fr-fr/blog/what-is-containerization/ \"Qu'est-ce que la conteneurisation ?\"), plus légère et rapide.\n\n## Qu’est-ce qu’un conteneur ?\n\n### Définition et fonctionnement\n\nLe conteneur est une approche alternative de virtualisation, un paquet qui contient toutes les dépendances nécessaires à l'exécution d'une application logicielle (bibliothèques, codes tiers, fichiers, etc.). Il reproduit la couche applicative d'un système d'exploitation, mais sans ses composants externes. Il est donc beaucoup plus léger qu'une machine virtuelle. \n\nUn conteneur peut être exécuté isolément sur n'importe quel système d'exploitation en parallèle d'autres conteneurs, tous partageant le kernel (noyau) de l'OS hôte. Si [Docker](https://about.gitlab.com/fr-fr/blog/what-is-docker-comprehensive-guide/ \"Qu'est-ce que Docker ?\") est l’outil de référence des équipes de développement pour la gestion des conteneurs, la plateforme [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\") intervient quant à elle à un niveau supérieur en orchestrant ces conteneurs à grande échelle, en s'appuyant sur des moteurs d'exécution tels que containerd ou CRI-O.\n\n### Avantages et limites des conteneurs\n\nL'avantage premier du conteneur est sa légèreté et sa rapidité de déploiement. Vous déployez l’image du conteneur sur n’importe quel environnement compatible et l'application est déjà fonctionnelle, avec des démarrages quasi instantanés.\n\nAu contraire de la machine virtuelle, la virtualisation par conteneur est fortement dépendante de l'environnement hôte, car elle ne reproduit pas un nouvel OS complet. De plus, la compartimentation est moins optimale qu'avec la machine virtuelle, en raison du partage du kernel. Cela signifie qu'une vulnérabilité du kernel pourrait potentiellement affecter tous les conteneurs exécutés sur cet hôte.\n\n## Conteneurs vs machines virtuelles : les principales différences\n\n| **Critères**         | **Conteneur**                                                                                                                                                                                                                                                                                                                                                                                                  | **Machine virtuelle**                                                                                       |\n| -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |\n| **Architecture**     | Virtualisation au niveau du système d’exploitation                                                                                                                                                                                                                                                                                                                                                             | Virtualisation au niveau matériel via un hyperviseur                                                        |\n| **Performances**     | Démarrage rapide en quelques secondes et utilisation des ressources plus faible                                                                                                                                                                                                                                                                                                                                | Démarrage plus lent que les conteneurs et consommation élevée en mémoire et CPU                             |\n| **Sécurité**         | Isolation au niveau du kernel via espaces de nommage et cgroups                                                                                                                                                                                                                                                                                                                                                | Isolation au niveau matériel (plus forte)                                                                   |\n| **Usages**           | Pour les [microservices](https://about.gitlab.com/fr-fr/topics/microservices/ \"Qu'est-ce qu'un microservice ?\"), applications [cloud-native](https://about.gitlab.com/fr-fr/topics/cloud-native/ \"Qu'est-ce que l'approche cloud-native ?\"), orchestration, [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), déploiements rapides et continus | Pour les applications héritées qui nécessitent une isolation complète et différents systèmes d’exploitation |\n| **Coûts et gestion** | Moins coûteux en ressources et en maintenance                                                                                                                                                                                                                                                                                                                                                                  | Plus coûteux à exploiter (licences, ressources matérielles)                                                 |\n\n### Architecture\n\nLes conteneurs et les machines virtuelles ne présentent pas la même architecture. Les machines virtuelles embarquent leur propre OS complet, alors que les conteneurs ne font que partager le noyau du système d'exploitation hôte. Ils n'exécutent que les applications qu'ils contiennent, nécessitent moins de ressources matérielles, mais offrent une isolation moins stricte que les machines virtuelles. \n\n### Performance et consommation\n\nSur ce point, les conteneurs ont clairement l'avantage. Ils démarrent quasi instantanément quand les machines virtuelles peuvent mettre plusieurs minutes pour s'exécuter. Cette différence s'explique par les ressources plus importantes consommées par les machines virtuelles. De leur côté, les conteneurs, étant beaucoup plus légers, sont également beaucoup moins gourmands en ressources.\n\n### Sécurité\n\nLa machine virtuelle offre une isolation plus stricte. Chaque machine virtuelle invitée est indépendante du système et des autres machines. Cela assure aux utilisateurs une protection complète. Les conteneurs partagent le noyau de l'OS hôte, leur étanchéité est donc moindre. Cependant, ils utilisent des mécanismes de sécurité du kernel (espaces de nommage, cgroups, sandboxing) pour atteindre un niveau d'isolation robuste, à condition que l'OS hôte soit correctement configuré et maintenu à jour.\n\n### Scalabilité et DevOps\n\nLes conteneurs sont spécialement conçus pour les environnements DevOps et les architectures cloud-native.\n\nIls offrent une excellente scalabilité, ce qui représente un atout majeur pour les pipelines CI/CD et le développement agile.\n\nConcrètement, vous disposez d'une solution qui se met automatiquement à l'échelle selon vos besoins, grâce à des orchestrateurs comme Kubernetes. Cette flexibilité est devenue indispensable, notamment dans les secteurs à forte variabilité de charge.\n\nLes machines virtuelles sont davantage adaptées à des applications monolithiques où l'ensemble du code et des fonctionnalités sont implémentés dans un programme unique. Avec ce modèle, vous devez modifier le code source, créer et déployer une version mise à jour de l’application complète sur la machine virtuelle. Elles peuvent aussi évoluer, mais nécessitent davantage de ressources matérielles et de temps de déploiement.\n\nPour tirer pleinement parti des conteneurs en production, deux outils se distinguent : Kubernetes pour l'orchestration, et GitLab pour l'automatisation des pipelines CI/CD. Voici comment ils s'articulent.\n\n## Kubernetes et GitLab\n\nKubernetes est un système d’orchestration [open source](https://about.gitlab.com/fr-fr/blog/what-is-open-source/ \"Qu'est-ce que l'open source ?\") initié par Google et aujourd’hui gouverné par la Cloud Native Computing Foundation. Il permet la création et la gestion d'applications conteneurisées avec une infrastructure flexible et évolutive. Kubernetes représente une solution très efficace pour développer des applications de type microservices plus rapidement, sans être limité à une infrastructure fixe.\nKubernetes est une solution cloud-native. Vous pouvez ainsi le déployer dans n'importe quel environnement de ce type (cloud public, privé ou hybride). Une caractéristique utile, notamment pour les entreprises qui utilisent plusieurs fournisseurs de services cloud. Vous gagnez en flexibilité et réduisez votre dépendance à un fournisseur cloud unique.\n\nL'autre grande force de Kubernetes est sa capacité d'évolutivité. Les applications développées évoluent automatiquement selon vos besoins. Vos infrastructures disposent d'une disponibilité optimale, même en cas de hausse du trafic ou de pic de charge.\n\nKubernetes intègre enfin tous les outils nécessaires pour assurer une surveillance efficace : tableaux de bord intuitifs, outils de supervision (Prometheus, Grafana), alertes, etc.\n\n### GitLab CI/CD et Kubernetes\n\nLa plateforme DevSecOps de GitLab facilite grandement la mise en place de projets conteneurisés et le développement cloud-native.\n\n[GitLab et Kubernetes](https://about.gitlab.com/fr-fr/solutions/kubernetes/ \"GitLab et Kubernetes\") fonctionnent de trois manières distinctes : \n\n* [Connectez votre cluster Kubernetes à GitLab](https://docs.gitlab.com/user/clusters/agent/) pour déployer, gérer et surveiller vos solutions cloud natives.\n  Utilisez Kubernetes pour gérer vos [GitLab Runners](https://about.gitlab.com/fr-fr/blog/what-is-gitlab-runner/ \"Qu'est-ce qu'un GitLab Runner ?\") et adaptez la charge de travail selon vos besoins.\n  Exécutez GitLab sur un cluster Kubernetes.\n\nChacune de ces approches peut être utilisée ensemble ou séparément. Par exemple, une instance Omnibus GitLab s'exécutant sur une machine virtuelle peut déployer des logiciels stockés en son sein vers Kubernetes.\n\nAvec GitLab et Kubernetes, vous adaptez ainsi vos workflows aux contraintes de votre infrastructure, tout en conservant une intégration et une automatisation complètes.\n\n## Quand choisir un conteneur ou une machine virtuelle ?\n\nDans la plupart des cas, les conteneurs constituent le choix le plus adapté aux environnements modernes, grâce à leur légèreté, leur rapidité de déploiement et leur scalabilité native. Certains contextes spécifiques justifient cependant de privilégier la machine virtuelle. C'est ce que nous allons découvrir maintenant.\n\n### Quand privilégier la machine virtuelle ?\n\nLa conteneurisation offre une sécurité suffisante pour la plupart des entreprises. Toutefois, si vous avez besoin d'environnements entièrement cloisonnés, la machine virtuelle se révèle être une option intéressante.\n\nPrenons un exemple. Votre entreprise de cybersécurité héberge plusieurs environnements de test pour analyser des malwares. Dans cette situation, la partition doit être optimale pour éviter une potentielle contamination entre les systèmes. Il est donc préférable d'utiliser une machine virtuelle.\n\nLa machine virtuelle s'impose également pour les tests en environnements multi OS. Si vous souhaitez tester des logiciels sur plusieurs systèmes d'exploitation (Windows, Linux et macOS), vous pouvez le faire à partir d'une seule machine physique. Vous faites ainsi des économies de matériel.\n\nPlus globalement, les machines virtuelles sont surtout utilisées pour les applications monolithiques ou anciennes. Si votre entreprise est gérée via un ERP développé il y a plusieurs années sur un OS hôte obsolète, la transition conteneur risque d'être complexe (migration progressive du code, refonte architecturale, etc.).\n\nIl est donc préférable de la faire tourner sur une machine virtuelle, mieux adaptée à ce type de structure logicielle.\n\n### Quand adopter les conteneurs ?\n\nAujourd'hui, les développements applicatifs s'appuient sur un modèle de microservices. Cette structure permet de tester, gérer, mettre à jour et déployer chaque module d'un logiciel, indépendamment des autres.\n\nPour arriver à ce résultat, il faut pouvoir disposer d'une distribution optimale des ressources entre les différents services. C'est exactement ce que permet la conteneurisation, grâce à sa structure légère et modulaire.\n\nCet aspect facilite grandement le travail des équipes [Devops](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que le DevOps ?\") qui profitent de déploiements [CI/CD](https://about.gitlab.com/fr-fr/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation/ \"Qu'est-ce que l'approche CI/CD ?\") plus rapides et fréquents. Une méthode qui limite les erreurs liées aux importantes mises à jour grâce à une itération continue.\nLà où les conteneurs sont particulièrement efficaces, c'est lorsque l'on aborde la question de la scalabilité et de la mise à niveau. \n\nAvec la conteneurisation, l'ajout, le retrait et l'ajustement des microservices s'effectuent automatiquement, sans intervention manuelle ni interruption du service. Vous optimisez ainsi les ressources consommées, quelles que soient la charge, la demande ou la taille de votre infrastructure.\n\n## Coexistence machine virtuelle et conteneurs : la solution hybride à adopter\n\nIl est tout à fait possible de faire coexister au sein d'une même structure ces deux architectures. Par exemple, une banque peut utiliser des machines virtuelles pour ses systèmes de paiement critiques et des conteneurs pour ses applications mobiles et services cloud-native.\n\nLa machine virtuelle s'impose pour les applications complexes ou critiques qui ne peuvent pas être divisées en modules ou qui nécessitent une isolation totale.\nPour toutes les applications structurées en microservices (ou susceptibles de l'être), la conteneurisation est le modèle le mieux adapté.\n\nCependant, ce n'est pas toujours la meilleure solution. Si vous devez maintenir ou exécuter des logiciels anciens, analysez bien le rapport coût/bénéfice d'une transition en conteneurs. S'il est trop élevé ou techniquement risqué, la machine virtuelle reste plus pertinente.\n\n## Bonnes pratiques pour passer de la machine virtuelle au conteneur\n\nVous souhaitez passer de la virtualisation par machine virtuelle à la conteneurisation ? Voici comment procéder pour effectuer une transition optimale et sans rupture :\n\n* **Audit de votre structure :** identifiez les systèmes d’exploitation utilisés, les dépendances logicielles, les services en cours d’exécution pour repérer les composants critiques. L'objectif ? Vérifier la compatibilité de ces éléments avec la structure modulaire en conteneurs.\n* **Refactorisation et découplage :** la refactorisation consiste à adapter le code et les processus à une structure de logiciel en microservices. Ensuite, le découplage va isoler les services et bases de données pour les rendre indépendants les uns des autres.\n* **Empaquetage :** une étape charnière pour créer l’image du conteneur via un Dockerfile, un fichier de configuration texte qui décrit l'environnement de l'application : dépendances, variables d'environnement, commandes d'exécution, etc.\n* **Test et sécurité :** l’image conteneurisée doit être soumise à une série de tests rigoureux avant le déploiement en production. Des tests automatisés unitaires, d’intégration, de charge et de sécurité pour assurer une stabilité totale.\n* **Déploiement :** c'est ici qu'entre en jeu [GitLab CI/CD](https://docs.gitlab.com/ci/). Avec GitLab CI/CD, vous déployez automatiquement vos conteneurs via l'intégration native Kubernetes. Avec les outils de monitoring intégrés à GitLab et d'autres solutions (Prometheus, Grafana), vous suivez en temps réel l’état de vos déploiements. \n\nQue vous optiez pour les conteneurs, les machines virtuelles ou une architecture hybride, l'essentiel est d'aligner votre choix technologique sur les besoins réels de votre infrastructure. \n\n> Essayez [GitLab Ultimate](https://about.gitlab.com/fr-fr/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr) gratuitement dès aujourd'hui !",[558,23],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1763646158/crdpd8lt5fndfzbcl9ln.jpg",{"featured":31,"template":15,"slug":739},"containers-vs-virtual-machines",{"content":741,"config":753},{"title":742,"description":743,"authors":744,"heroImage":746,"date":747,"body":748,"category":11,"tags":749},"[Rapport] Comment l'IA redéfinit le DevSecOps en 2026 ?","Découvrez dans notre dernier rapport DevSecOps dédié à « L'ère du développement logiciel intelligent » comment concilier gains de productivité avec qualité, fiabilité et sécurité.",[745],"Manav Khurana","https://res.cloudinary.com/about-gitlab-com/image/upload/v1768217269/rnpqe3mbm3b8unj8ksrk.png","2026-01-12","L'IA promet une accélération majeure en matière d'innovation, mais la plupart des équipes logicielles font face à des défis cruciaux. Selon **notre dernier [rapport DevSecOps](https://learn.gitlab.com/fr-developer-survey/report-fr-fr-fr-devsecops-report-practitioner?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_comm_gated-content_ai_fr_dsp25_fr) dédié à « L'ère du développement logiciel intelligent »**, le code généré par l'IA représente désormais 41 % de l'ensemble du travail de développement. \n\nPourtant, 63 % des professionnels DevSecOps français déclarent que l'IA complexifie la gestion de la conformité, et 78 % estiment que l'IA agentique créera des défis de sécurité sans précédent.\n\nC'est le paradoxe de l'IA : elle accélère le codage, mais la livraison logicielle ralentit car les équipes peinent à tester, sécuriser et déployer tout ce code.\n\n> **Pour accéder à notre rapport DevSecOps complet dédié à « L'ère du développement logiciel intelligent », cliquez [ici](https://learn.gitlab.com/fr-developer-survey/report-fr-fr-fr-devsecops-report-practitioner?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_comm_gated-content_ai_fr_dsp25_fr).**\n\n## Les gains de productivité se heurtent à des goulots d'étranglement dans les workflows\n\nLe problème n'est pas l'IA en elle-même, mais la façon dont les logiciels sont développés aujourd'hui. Le [cycle de vie DevSecOps](https://about.gitlab.com/fr-fr/blog/what-is-sdlc/ \"SDLC\") traditionnel comporte des centaines de petites tâches que les équipes de développement doivent gérer manuellement : mise à jour des tickets, exécution des tests, demandes de revue, attente des approbations, résolution des conflits de merge, traitement des problèmes de sécurité. Ces tâches mobilisent en moyenne six heures par semaine pour chaque membre de l'équipe, selon notre étude, sans compter les 14 heures mensuelles dédiées à la conformité.\n\nLes équipes de développement génèrent du code plus vite que jamais. D'ailleurs, **100 % des professionnels interrogés affirment que l'IA leur a permis de gagner en productivité**. Parmi les domaines où les outils d'IA ont permis les gains d'efficacité les plus importants, nous retrouvons l'automatisation des tâches répétitives (44 %), les tests/assurance qualité (38 %) et la génération de code (37 %). \n\n![Domaines où les outils d'IA ont permis les gains d'efficacité les plus importants](https://res.cloudinary.com/about-gitlab-com/image/upload/v1768227474/rhxyjdxgk4zl5fzfhrbb.png)\n\nMais ce code continue de passer par des chaînes d'outils fragmentées, des transferts manuels et des processus déconnectés. \n\nEn France, **52 % des équipes DevSecOps utilisent plus de cinq outils pour le développement logiciel, et 47 % utilisent plus de cinq outils d'IA.** Plus préoccupant encore, 48 % des professionnels utilisent des outils d'IA non officiellement approuvés par leur entreprise.\n\nCette fragmentation crée des obstacles à la collaboration : 96 % des professionnels [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") font face à des éléments qui limitent la collaboration dans le cycle de vie du développement logiciel, notamment le manque de communication interfonctionnelle (34 %), les effets de silo organisationnels (31 %) et la multiplication des outils utilisés (29 %).\n\nLa solution n'est pas d'ajouter davantage d'outils. Il s'agit plutôt d'une orchestration intelligente qui rassemble les équipes logicielles et leurs agents d'IA à travers les projets et les cycles de release, avec une sécurité, une gouvernance et une conformité de niveau entreprise intégrées nativement.\n\n## Vers un partenariat humain-IA renforcé\n\nLes professionnels DevSecOps ne veulent pas que l'IA prenne le contrôle. Ils veulent des partenariats fiables. **75 % affirment que l'utilisation de l'IA agentique augmenterait leur satisfaction au travail, et 39 % envisagent un avenir idéal avec une répartition équitable entre les contributions humaines et l'IA**. Ils sont prêts à confier 33 % de leurs tâches quotidiennes à l'IA sans révision humaine, notamment pour la documentation (48 %), la création de tests (48 %) et les revues de code (44 %).\n\nCe que nous avons entendu de manière unanime de la part des professionnels DevSecOps, c'est que l'IA ne les remplacera pas, mais qu'elle transformera fondamentalement leurs rôles. **80 % pensent que l'IA modifiera significativement leur travail dans les cinq prochaines années**. Et fait notable, 68 % estiment que cela créera même davantage d'emplois d'ingénieurs. À mesure que le codage devient plus facile avec l'IA, les ingénieurs capables de concevoir des systèmes, d'assurer la qualité et d'apporter un contexte métier seront très demandés. 83 % des répondants affirment d'ailleurs que les ingénieurs qui adoptent l'IA assurent la pérennité de leur carrière.\n\nPoint important : **85 % s'accordent à dire qu'il existe des qualités humaines essentielles que l'IA ne remplacera jamais totalement**, notamment l'innovation (42 %), la vision stratégique (42 %), la créativité (41 %) et la collaboration (38 %).\n\n![Les contributions humaines les plus précieuses dans le SDLC](https://res.cloudinary.com/about-gitlab-com/image/upload/v1768227441/dqqo93d0gwtukb7wdvn5.png)\n\nAlors comment les organisations peuvent-elles combler le fossé entre la promesse de l'IA et la réalité des workflows fragmentés ?\n\n> **Vous souhaitez en savoir plus ? [Téléchargez notre rapport complet dédié à « L'ère du développement logiciel intelligent »](https://learn.gitlab.com/fr-developer-survey/report-fr-fr-fr-devsecops-report-practitioner?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_comm_gated-content_ai_fr_dsp25_fr).** \n\n## Participez à GitLab Transcend\n\nParticipez le 10 février prochain à notre événement GitLab Transcend, où nous dévoilerons comment l'orchestration intelligente transforme le développement logiciel alimenté par l'IA. Vous découvrirez en avant-première la roadmap produit de GitLab et apprendrez comment les équipes résolvent des défis concrets en modernisant leurs workflows de développement avec l'IA.\n\nLes organisations qui réussissent dans cette nouvelle ère trouvent un équilibre entre l'adoption de l'IA et la sécurité, la conformité et la consolidation des plateformes. L'IA offre de véritables gains de productivité lorsqu'elle est implémentée de manière réfléchie. 81 % des professionnels estiment que l'adoption systématique de l'IA générera plus de retours à long terme que son utilisation pour des solutions tactiques rapides. Non pas en remplaçant les développeurs humains, mais en libérant les professionnels DevSecOps pour qu'ils se concentrent sur la réflexion stratégique et l'innovation créative.\n\n> **Inscrivez-vous dès aujourd'hui à [GitLab Transcend](https://about.gitlab.com/fr-fr/events/transcend/virtual/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_comm_webcast_ai_fr_transcend_virtual) et découvrez comment l'orchestration intelligente peut aider vos équipes logicielles.**",[750,751,752],"AI/ML","DevOps platform","security",{"featured":14,"template":15,"slug":754},"devsecops-report-france",{"promotions":756},[757,771,783,794],{"id":758,"categories":759,"header":761,"text":762,"button":763,"image":768},"ai-modernization",[760],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":764,"config":765},"Get your AI maturity score",{"href":766,"dataGaName":767,"dataGaLocation":245},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":769},{"src":770},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":772,"categories":773,"header":775,"text":762,"button":776,"image":780},"devops-modernization",[774,11],"product","Are you just managing tools or shipping innovation?",{"text":777,"config":778},"Get your DevOps maturity score",{"href":779,"dataGaName":767,"dataGaLocation":245},"/assessments/devops-modernization-assessment/",{"config":781},{"src":782},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":784,"categories":785,"header":786,"text":762,"button":787,"image":791},"security-modernization",[752],"Are you trading speed for security?",{"text":788,"config":789},"Get your security maturity score",{"href":790,"dataGaName":767,"dataGaLocation":245},"/assessments/security-modernization-assessment/",{"config":792},{"src":793},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":795,"paths":796,"header":799,"text":800,"button":801,"image":806},"github-azure-migration",[797,798],"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":802,"config":803},"See how GitLab compares to GitHub",{"href":804,"dataGaName":805,"dataGaLocation":245},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":807},{"src":782},{"header":809,"blurb":810,"button":811,"secondaryButton":815},"Commencez à développer plus rapidement dès aujourd'hui","Découvrez ce que votre équipe peut accomplir avec la plateforme d'orchestration intelligente pour le DevSecOps.\n",{"text":48,"config":812},{"href":813,"dataGaName":51,"dataGaLocation":814},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/fr-fr/","feature",{"text":53,"config":816},{"href":55,"dataGaName":56,"dataGaLocation":814},1777493600834]