[{"data":1,"prerenderedAt":708},["ShallowReactive",2],{"/fr-fr/blog/basics-of-gitlab-ci-updated/":3,"navigation-fr-fr":36,"banner-fr-fr":456,"footer-fr-fr":468,"Itzik Gan Baruch":680,"next-steps-fr-fr":693},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":16,"config":26,"_id":29,"_type":30,"title":31,"_source":32,"_file":33,"_stem":34,"_extension":35},"/fr-fr/blog/basics-of-gitlab-ci-updated","blog",false,"",{"title":9,"description":10,"ogTitle":9,"ogDescription":10,"noIndex":6,"ogImage":11,"ogUrl":12,"ogSiteName":13,"ogType":14,"canonicalUrls":12,"schema":15},"Intégration continue : créez votre premier pipeline CI avec GitLab ","Vous débutez dans l'intégration continue ? Apprenez à créer votre premier pipeline CI avec GitLab. Lisez notre guide complet.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662061/Blog/Hero%20Images/cicdcover.png","https://about.gitlab.com/blog/basics-of-gitlab-ci-updated","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Intégration continue : créez votre premier pipeline CI avec GitLab \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2020-12-10\",\n      }",{"title":9,"description":10,"authors":17,"heroImage":11,"date":19,"body":20,"category":21,"tags":22,"updatedDate":25},[18],"Itzik Gan Baruch","2020-12-10","Imaginons que vous ne connaissiez rien au concept d’[intégration continue (CI)](https://about.gitlab.com/fr-fr/topics/ci-cd/benefits-continuous-integration/ \"Qu'est-ce que l'intégration continue (CI) ?\") ni à son rôle clé dans le cycle de vie du développement logiciel.\n\nÀ présent, supposons que vous travaillez sur un projet pour lequel l'intégralité du code est répartie dans seulement deux fichiers. Pour garantir le bon fonctionnement de ce projet, il est impératif que la concaténation de ces deux fichiers contienne la phrase « Hello world ».\n\nToute la réussite du projet repose sur cette simple phrase, car sans elle, tout serait compromis.\n\nConscient de cet enjeu, votre meilleur développeur logiciel a décidé de créer un script qui s'exécute dès qu’un nouveau morceau de code est envoyé aux clients.\n\nVoici à quoi cela ressemble  :\n\n```bash\ncat file1.txt file2.txt | grep -q \"Hello world\"\n```\n\nMême si, en l'état, ce script permet d'exécuter notre tâche, son déclenchement reste manuel. Et, avec une équipe de développement composée de 10 personnes, vous n'êtes pas à l'abri d'une erreur humaine qui pourrait vous coûter très cher. \n\nLa preuve en est, pas plus tard que la semaine dernière, un nouveau membre de votre équipe a oublié d'exécuter le script, provoquant des erreurs de compilation pour trois de vos clients.\n\nVous prenez donc la décision de résoudre ce problème, une bonne fois pour toutes, en utilisant le pipeline d'[intégration et de livraison continues](https://about.gitlab.com/fr-fr/solutions/continuous-integration/ \"Intégration et livraison continues\") de GitLab. Par chance, votre code est déjà sur la plateforme. Il ne vous reste plus qu'à vous lancer.  \n\n## Effectuer un premier test dans le pipeline CI de GitLab\n\nÀ la lecture de la documentation de GitLab, nous savons qu'il suffit de réunir deux lignes de code dans un fichier appelé `.gitlab-ci.yml`:\n\n```yaml\ntest:\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n```\n\nNous le validons et constatons que la compilation s'est déroulée avec succès\n\n![Compilation réussie dans le pipeline d’intégration continue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/build_succeeded.png)\n\nMaintenant, remplaçons « world » par « Africa » dans le deuxième fichier et voyons ce qui se passe :\n\n![Échec de compilation dans le pipeline CI GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/build_failed.png)\n\nComme nous pouvions le prévoir, la compilation a échoué.\n\nNous avons désormais mis en place l'automatisation des tests.  \n\nÀ partir de maintenant, [GitLab CI](https://about.gitlab.com/fr-fr/blog/ci-deployment-and-environments/ \"Comment déployer du code dans des environnements multiples avec GitLab CI\") exécutera notre script de test dès que nous effectuerons un push du code vers le dépôt de code source dans l'environnement [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Que signifie DevOps ?\"). \n\nRemarque : dans l'exemple ci-dessus, nous supposons que file1.txt et file2.txt existent sur l'hôte du runner. Pour exécuter cet exemple dans GitLab, utilisez le code ci-dessous, qui crée d'abord les fichiers, puis exécute le script.\n\n```yaml\ntest:\nbefore_script:\n      - echo \"Hello \" > | tr -d \"\\n\" | > file1.txt\n      - echo \"world\" > file2.txt\nscript: cat file1.txt file2.txt | grep -q 'Hello world'\n```\n\nPour simplifier notre démonstration, nous partons du principe que ces fichiers existent déjà sur l'hôte. Nous n'allons donc pas les créer dans les étapes suivantes.\n\n## Rendre les résultats des compilations téléchargeables\n\nLa prochaine étape consiste à empaqueter le code avant de l'envoyer aux clients. Alors, pourquoi ne pas automatiser aussi cette partie du processus de développement logiciel ?\n\nPour cela, tout ce que nous devons faire est de définir un autre job pour l'intégration continue. \n\nCommençons par nommer notre job « package » :\n\n```yaml\ntest:\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n\npackage:\n  script: cat file1.txt file2.txt | gzip > package.gz\n```\n\nNous avons maintenant deux onglets : \n\n![Deux onglets - générés par deux jobs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/two_tabs.png)\n\nCependant, nous avons oublié de spécifier que le nouveau fichier est un artefact de compilation, afin qu’il puisse être téléchargé. Nous pouvons corriger cela en ajoutant une section `artefacts` :\n\n```yaml\ntest:\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n\npackage:\n  script: cat file1.txt file2.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n```\n\nVérifions que tout est en place :\n\n![Artefact de compilation téléchargeable dans le pipeline CI/CD de GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/artifacts.png)\n\nFélicitations ! Tout semble fonctionnel. En revanche, dans la configuration actuelle, les jobs s'exécutent en parallèle. Cela signifie que notre application pourra être empaquetée, et ce, même si les tests échouent. Pour éviter que cela ne se produise, nous allons devoir exécuter les jobs de manière séquentielle.  \n\n## Exécuter des jobs de manière séquentielle\n\nPour éviter d'empaqueter une application contenant des erreurs, nous allons faire en sorte d'exécuter le job « package » uniquement si les tests sont préalablement réussis. Pour commencer, définissons l'ordre d'exécution en établissant des étapes spécifiques  :\n\n```yaml\nstages:\n  - test\n  - package\n\ntest:\n  stage: test\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n\npackage:\n  stage: package\n  script: cat file1.txt file2.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n```\n\nCela devrait maintenant fonctionner.\n\nNous souhaitons également garantir que la compilation (qui est représentée par la concaténation dans notre exemple) ne s'exécute qu'une seule fois. En effet, cette étape pouvant être chronophage, il serait dommage de l'exécuter inutilement.\n\nPour éviter cela, définissons une étape supplémentaire :\n\n```yaml\nstages:\n  - compile\n  - test\n  - package\n\ncompile:\n  stage: compile\n  script: cat file1.txt file2.txt > compiled.txt\n  artifacts:\n    paths:\n    - compiled.txt\n\ntest:\n  stage: test\n  script: cat compiled.txt | grep -q 'Hello world'\n\npackage:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n```\n\nJetons un œil à nos artefacts :\n\n![Artefacts de compilation dans le pipeline CI de GitLab](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/clean-artifacts.png)\n\nTout a l'air de fonctionner. En revanche, il faudrait éviter de rendre le fichier « compile » téléchargeable. Pour cela, nous allons rendre nos artefacts temporaires expirables en définissant `expire_in` à « 20 minutes ».  \n\n```yaml\ncompile:\n  stage: compile\n  script: cat file1.txt file2.txt > compiled.txt\n  artifacts:\n    paths:\n    - compiled.txt\n    expire_in: 20 minutes\n```\n\nMaintenant, notre configuration semble plutôt complète : \n- Nous avons trois étapes séquentielles pour compiler, tester et empaqueter notre application. \n- Nous transmettons également l'application compilée aux étapes suivantes pour ne pas exécuter la compilation à deux reprises (ce qui accélère le processus). \n- Et nous stockons une version empaquetée de notre application dans les artefacts de compilation pour une utilisation ultérieure.\n\n## Savoir quelle image Docker utiliser\n\nJusqu'ici, tout va bien. Cependant, en regardant de plus près, nos compilations semblent toujours lentes. Prenons un moment pour regarder les journaux (logs) :\n\n![Image ruby 3.1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/ruby-31.png)\n\nEn observant de plus près, nous remarquons la mention suivante : `ruby:3.1`. Cela signifie que GitLab.com utilise des images Docker pour [exécuter nos compilations](https://about.gitlab.com/blog/shared-runners/), et qu’il utilise [par défaut](https://docs.gitlab.com/ee/user/gitlab_com/#shared-runners), l'image [`ruby:3.1`](https://hub.docker.com/_/ruby/).\n\nCette image contient certainement de nombreux paquets dont nous n'avons pas besoin. Dans un souci d'optimisation de notre pipeline CI, il serait donc préférable de changer d'image. Après une courte recherche sur Google, nous découvrons qu'il existe une image Linux presque vierge appelée [`alpine`](https://hub.docker.com/_/alpine/). Nous allons alors l'utiliser. Pour cela, nous devrons ajouter `image: alpine` au fichier `.gitlab-ci.yml`.\n\nEt voilà !  Nous avons maintenant réduit le temps de compilation de presque trois minutes :\n\n![Vitesse de compilation améliorée dans le pipeline de GitLab](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/speed.png)\n\nVous pouvez également trouver des images libres de droits sur [mysql](https://hub.docker.com/_/mysql/), [Python](https://hub.docker.com/_/python/), [Java](https://hub.docker.com/_/java/) et [php](https://hub.docker.com/_/php/). Il est facile, alors, d'en choisir une pour notre pile technologique. \n\nNote : il sera toujours préférable d'utiliser une image qui ne contient aucun logiciel supplémentaire dont vous n'avez pas besoin, car cela minimise grandement le temps de téléchargement.\n\n## Gérer des scénarios complexes \n\nImaginons maintenant un scénario un peu plus complexe. Par exemple, un nouveau client souhaite que nous empaquetions notre application au format `.iso` plutôt qu'en `.gz`. \n\nÉtant donné que le pipeline d'intégration continue gère tout le processus, et que les images ISO peuvent être créées avec la commande `mkisofs`, il suffit d'ajouter un job supplémentaire.\n\nVoici à quoi notre configuration devrait ressembler :\n\n```yaml\nimage: alpine\n\nstages:\n  - compile\n  - test\n  - package\n\n# ... \"compile\" and \"test\" jobs are skipped here for the sake of compactness\n\npack-gz:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n\npack-iso:\n  stage: package\n  script:\n  - mkisofs -o ./packaged.iso ./compiled.txt\n  artifacts:\n    paths:\n    - packaged.iso\n```\n\nNotez que les noms des jobs ne doivent pas être nécessairement identiques. S'ils l'étaient, il serait impossible de faire s'exécuter les jobs en parallèle dans la même étape du processus de développement logiciel. \n\nAinsi, dans l'exemple qui suit, ignorez le fait que les jobs et étapes portent le même nom.\n\nQuoi qu'il en soit, la compilation échoue :\n\n![Echec de compilation dans le pipeline de GitLab](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/mkisofs.png)\n\nLe problème vient de  `mkisofs` qui n'est pas inclus dans l'image `alpine`. Nous devons donc d'abord l'installer.\n\n## Gérer des logiciels et des paquets manquants \n\nSelon le [site Web d’Alpine Linux](https://pkgs.alpinelinux.org/contents?file=mkisofs&path=&name=&branch=edge&repo=&arch= \"Site Web Alpine Linux\"), `mkisofs` fait partie des paquets `xorriso` et `cdrkit`. Voici les commandes que nous devons exécuter pour installer un paquet :\n\n```bash\necho \"ipv6\" >> /etc/modules  # enable networking\napk update                   # update packages list\napk add xorriso              # install package\n```\n\nCes commandes s'exécutent de la même manière que toute autre commande au sein du processus d'intégration continue. La liste complète des commandes que nous devons transmettre à la section `script` devrait ressembler à ceci :\n\n```yml\nscript:\n- echo \"ipv6\" >> /etc/modules\n- apk update\n- apk add xorriso\n- mkisofs -o ./packaged.iso ./compiled.txt\n```\n\nCependant, pour des raisons sémantiques, plaçons les commandes liées à l'installation du paquet dans `before_script`. \n\nNotez que si vous utilisez `before_script` au niveau supérieur d'une configuration, alors les commandes s'exécuteront avant tous les jobs. Dans notre cas, nous voulons simplement qu'elles s'exécutent avant un job spécifique.\n\n## Graphes acycliques orientés pour des pipelines CI plus rapides et flexibles\n\nPlus haut, nous avons configuré des étapes pour que les jobs d'empaquetage ne s'exécutent qu'à la condition que les tests réussissent. Mais, que se passerait-il si nous voulions bouleverser le séquencement des étapes en exécutant certains jobs plus tôt qu'initialement prévu ? \n\nDans certains cas, le séquencement traditionnel des étapes peut ralentir la durée globale d'exécution du [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"). Pour éviter cela, nous pouvons choisir de personnaliser le séquencement de nos jobs. \n\nPar exemple : imaginons que notre étape de test comprenne des tests lourds, prenant beaucoup de temps à s'exécuter. Supposons aussi que ces tests ne soient pas nécessairement liés aux jobs d’empaquetage. Dans ce cas, il serait préférable que les jobs d’empaquetage puissent démarrer sans attendre la fin de ces tests. C'est là qu'interviennent les [graphes acycliques orientés](https://about.gitlab.com/blog/directed-acyclic-graph/ \"Graphes acycliques orientés\"). Ces derniers visent à rompre l'ordre normal d'exécution des jobs (ordre séquentiel) grâce à la création de dépendances entre certains jobs. Vous pouvez ainsi définir un ordre personnalisé pour exécuter les différents jobs de votre pipeline CI.\n\nGrâce au mot-clé `needs`, GitLab crée des dépendances entre les jobs et leur permet de s'exécuter plus tôt, dès que leurs jobs dépendants sont terminés.\n\nDans l'exemple ci-dessous, les jobs d’empaquetage commenceront à s'exécuter dès que le test sera terminé. Ainsi, à l'avenir, si quelqu'un ajoute d'autres tests à l'étape de test, les jobs d’empaquetage commenceront à s'exécuter avant la fin des nouveaux tests :\n\n```yaml\npack-gz:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.gz\n\npack-iso:\n  stage: package\n  before_script:\n  - echo \"ipv6\" >> /etc/modules\n  - apk update\n  - apk add xorriso\n  script:\n  - mkisofs -o ./packaged.iso ./compiled.txt\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.iso\n```\n\nVoici notre version définitive de `.gitlab-ci.yml`:\n\n```yaml\nimage: alpine\n\nstages:\n  - compile\n  - test\n  - package\n\ncompile:\n  stage: compile\n  before_script:\n      - echo \"Hello  \" | tr -d \"\\n\" > file1.txt\n      - echo \"world\" > file2.txt\n  script: cat file1.txt file2.txt > compiled.txt\n  artifacts:\n    paths:\n    - compiled.txt\n    expire_in: 20 minutes\n\ntest:\n  stage: test\n  script: cat compiled.txt | grep -q 'Hello world'\n\npack-gz:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.gz\n\npack-iso:\n  stage: package\n  before_script:\n  - echo \"ipv6\" >> /etc/modules\n  - apk update\n  - apk add xorriso\n  script:\n  - mkisofs -o ./packaged.iso ./compiled.txt\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.iso\n```\n\nNous venons de créer un pipeline ! Ainsi, nous avons trois étapes séquentielles avec les \njobs `pack-gz` et `pack-iso` qui s'exécutent en parallèle à l'intérieur de l'étape d'empaquetage :\n\n![Représentation d'un artefact de compilation d'un pipeline CI](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/pipeline.png)\n\n## Améliorer votre pipeline CI\n\nNous allons maintenant découvrir comment améliorer notre pipeline d'intégration continue.\n\n### Intégrer des tests automatisés dans vos pipelines CI\n\nL'objectif clé du développement logiciel avec une approche DevOps est de réussir à créer des applications offrant une excellente expérience utilisateur. \n\nAvec cet objectif en tête, pourquoi ne pas renforcer le cycle de développement logiciel en cherchant à détecter d'éventuels bogues dès le début du processus ? Pour ce faire, ajoutons des tests à notre pipeline CI. De cette façon, nous pourrons résoudre les problèmes le plus tôt possible.\n\nPar chance, le pipeline CI de GitLab nous facilite la tâche en proposant des templates de tests prêts à l'emploi. Tout ce que nous avons à faire, c'est d'inclure ces templates dans la configuration de notre pipeline CI.\n\nDans cet exemple, nous allons réaliser des [tests d'accessibilité](https://docs.gitlab.com/ee/ci/testing/accessibility_testing.html \"Test d'accessibilité\") :\n\n```yaml\nstages:\n  - accessibility\n\nvariables:\n  a11y_urls: \"https://about.gitlab.com https://www.example.com\"\n\ninclude:\n  - template: \"Verify/Accessibility.gitlab-ci.yml\"\n```\n\nPersonnalisez la variable `a11y_urls` pour répertorier les URL des pages web à tester avec [Pa11y](https://pa11y.org/ \"Pa11y\") et GitLab [Code Quality](https://docs.gitlab.com/ee/ci/testing/code_quality.html \"Code Quality\"). \n\n```yaml\n   include:\n   - template: Jobs/Code-Quality.gitlab-ci.yml\n```\n\nGitLab facilite la consultation du rapport de test directement dans la zone du widget de la [merge request](https://docs.gitlab.com/ee/user/project/merge_requests/ \"Merge request\"). Ce widget vous permet de voir la revue de code, l'état du pipeline et les résultats des tests au même endroit. La capture d'écran ci-dessous montre à quel point ce widget facilite le travail de vos équipes. \n\n![Exemple de rapport d'accessibilité dans le pipeline CI/CD de GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-02_at_10.56.41.png)\n\u003Ccenter>\u003Ci>Widget pour les merge requests en matière d'accessibilité\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n![Exemple de rapport de test sur la qualité du code suite à une merge request dans GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-02_at_11.00.25.png)\n\u003Ccenter>\u003Ci>Widget de merge request pour GitLab Code Quality\u003C/i>\u003C/center>\n\n### Matrice des compilations\n\nDans certains cas, nous devons tester notre application dans différentes configurations, versions de systèmes d'exploitation et langages de programmation. Nous utilisons alors la compilation « [parallel:matrix](https://docs.gitlab.com/ee/ci/yaml/#parallelmatrix \"parallel:matrix\") ». Cela nous permet de tester notre application à travers diverses combinaisons en parallèle dans un seul job. Maintenant, testons notre code avec différentes versions de Python et avec le mot-clé « matrix ».\n\n```yaml\npython-req:\n  image: python:$VERSION\n  stage: lint\n  script:\n    - pip install -r requirements_dev.txt\n    - chmod +x ./build_cpp.sh\n    - ./build_cpp.sh\n  parallel:\n    matrix:\n      - VERSION: ['3.8', '3.9', '3.10', '3.11']   # https://hub.docker.com/_/python\n```\n\nLors de l'exécution du pipeline, ce job s'exécute en parallèle quatre fois, chaque fois en utilisant une image Python différente comme indiqué ci-dessous :\n\n![Exécution de jobs en parallèle dans le pipeline CI/CD](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-02_at_11.12.48.png)\n\n### Tests unitaires\n\n#### Que sont les tests unitaires ?\n\nLes tests unitaires sont des tests ciblés et de petite envergure qui vérifient des composants ou des fonctions d'un logiciel. Ces tests permettent d'assurer qu'il fonctionne comme prévu. Ils sont essentiels pour vérifier que chaque partie du code fonctionne correctement et permettent de détecter les bogues le plus tôt possible dans le processus de développement logiciel. \n\nExemple : imaginez que vous développiez une application de calculatrice. Un test unitaire pour la fonction « addition » va vérifier si le résultat d'un calcul comme 2 + 2 est bien égale à 4. Si ce test est concluant, nous avons confirmation que la fonction « addition » fonctionne correctement.\n\n#### Tests unitaires : les bonnes pratiques\n\nMettre en place des tests unitaires, c'est bien, mais il est possible d'aller encore plus loin pour faciliter la vie de vos équipes de développement.\n\nPar exemple, lorsqu'un test échoue, vos équipes reçoivent une notification. S'engage alors un long processus de vérification des job logs afin de trouver et de corriger les erreurs. Ce processus est long et pourrait être optimisé.\n\nIl est possible de configurer votre job pour qu'il utilise des [rapports de tests unitaires](https://docs.gitlab.com/ee/ci/testing/unit_test_reports.html \"Rapports de tests unitaires\") (rapports détaillés des erreurs permettant de les traiter plus efficacement). GitLab affiche ces rapports dans la merge request et sur la page de détails des pipelines CI. Cela facilite l'identification des échecs, car il n'y a alors plus besoin de consulter l'intégralité du journal.\n\n#### Rapport de test JUnit\n\nCi-dessous un exemple de rapport de test JUnit : \n\n![Rapport de test JUnit dans un pipeline d'intégration continue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674097/Blog/Content%20Images/pipelines_junit_test_report_v13_10.png){: .shadow.center}\n\n### Stratégies d'intégration et de tests de bout en bout\n\nAfin de s'assurer que toutes les parties de notre code fonctionnent en harmonie (y compris les [microservices](https://about.gitlab.com/fr-fr/topics/microservices/ \"Que sont les microservices ?\"), les tests d'interface utilisateur), il est capital de configurer un pipeline dédié à l'intégration et aux tests de bout en bout.\n\nCes tests sont exécutés [chaque nuit](https://docs.gitlab.com/ee/ci/pipelines/schedules.html) et il est possible de configurer le système pour que les [résultats soient automatiquement envoyés vers un canal Slack dédié](https://docs.gitlab.com/ee/user/project/integrations/gitlab_slack_application.html#notification-events). Ainsi, lorsque les équipes de développement arrivent le matin, elles peuvent rapidement travailler sur les problèmes identifiés la veille. L'objectif étant de détecter et de corriger les problèmes le plus tôt possible dans le processus de développement logiciel.\n\n### Environnement de test\n\nDans certains cas, nous avons besoin d'un environnement dédié pour tester correctement nos applications. On parle alors d'environnement de test. Avec le pipeline CI/CD de GitLab, nous pouvons automatiser le déploiement des environnements de test, et ainsi gagner un temps considérable. \n\nComme cet article se concentre principalement sur les pipelines d'intégration continue, nous ne nous attarderons pas sur ce point ici. En revanche, libre à vous de consulter la section dédiée à ce sujet dans la [documentation GitLab](https://docs.gitlab.com/ee/topics/release_your_application.html).\n\n## Implémenter des scans de sécurité dans un pipeline CI\n\nVoici comment mettre en œuvre des scans de sécurité dans un pipeline CI.\n\n### Intégration des SAST et des DAST\n\nAvant toute chose, nous souhaitons garder notre code en sécurité. S'il y a la moindre vulnérabilité dans nos dernières modifications, nous voulons en être informés dès que possible. C'est pourquoi il est judicieux d'ajouter des scans de sécurité à votre pipeline CI. \nCes scans vérifient le code à chaque commit et vous alertent dès qu'une faille est détectée. \n\nIl existe deux types de scan : \n- les tests statiques de sécurité des applications ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/ \"SAST\"))\n- les tests dynamiques de sécurité des applications ([DAST](https://docs.gitlab.com/ee/user/application_security/dast/ \"DAST\"))\n\nCi-dessous, consultez notre guide interactif qui vous montre comment ajouter des scans de sécurité à votre pipeline CI. \n\nCliquez sur l'image ci-dessous pour commencer. \n\n[![Scans product tour](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-14_at_13.44.42.png)](https://gitlab.navattic.com/gitlab-scans)\n\nGrâce à l'IA et à ses capacités d'analyse, nous pouvons également obtenir des suggestions sur la manière dont les vulnérabilités peuvent être corrigées. Consultez cette démonstration pour plus d'informations.\n\nCliquez sur l'image ci-dessous pour commencer. \n\n[![product tour explain vulnerability ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-14_at_13.50.24.png)](https://tech-marketing.gitlab.io/static-demos/pt-explain-vulnerability.html)\n\n## Récapitulatif\n\nDans cet article, nous avons volontairement simplifié les exemples afin de faciliter l'intégration des différents concepts de GitLab CI.\n\nRésumons rapidement ce que nous avons appris :\n1. Pour déléguer certaines tâches à GitLab CI, vous devez définir un ou plusieurs [jobs](https://docs.gitlab.com/ee/ci/jobs/) dans `.gitlab-ci.yml`.\n2. Les jobs doivent avoir des noms, de préférence facilement identifiables.\n3. Chaque job contient un ensemble de règles et d'instructions pour le pipeline de GitLab. Ces derniers sont définis par des mots-clés spécifiques.\n4. Les jobs peuvent s'exécuter de manière séquentielle, en parallèle, ou dans l'ordre de votre choix grâce aux graphes acycliques orientés. \n5. Vous pouvez transférer des fichiers entre les jobs et les stocker dans des artefacts de compilation afin de pouvoir les télécharger depuis l'interface de GitLab CI.\n6. Ajoutez [des tests et des scans de sécurité](https://docs.gitlab.com/ee/development/integrations/secure.html \"Tests et scans de sécurité\") au pipeline CI pour garantir la qualité et la sécurité de votre application.\n\nCi-dessous se trouvent des descriptions des termes et des mots-clés que nous avons abordés dans cet article.\n\n### Mots-clés, descriptions et documentation\n\n{: #keywords}\n\n| Mots-clés/termes       | Description |\n|---------------|--------------------|\n| [.gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/) | Fichier contenant toutes les explications sur la façon dont votre projet doit être construit |\n| [script](https://docs.gitlab.com/ee/ci/yaml/#script)        | Définit un script shell à exécuter |\n| [before_script](https://docs.gitlab.com/ee/ci/yaml/#before_script) | Utilisé pour définir la commande qui doit être exécutée avant tous les jobs |\n| [image](https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#what-is-image) | Définit l’image Docker à utiliser |\n| [stages](https://docs.gitlab.com/ee/ci/yaml/#stages)         | Définit une étape du pipeline CI (par défaut : `test`) |\n| [artifacts](https://docs.gitlab.com/ee/ci/yaml/#artifacts)     | Définit une liste d'artefacts de compilation |\n| [artifacts:expire_in](https://docs.gitlab.com/ee/ci/yaml/#artifactsexpire_in) | Utilisé pour supprimer les artefacts téléchargés après une durée spécifiée |\n| [needs](https://docs.gitlab.com/ee/ci/yaml/#needs) | Permet de définir les dépendances entre les jobs et permet d'exécuter des jobs dans l'ordre de votre choix |\n| [pipelines](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/) | Un pipeline est un groupe de compilations exécutées par étapes (batch) |\n\n## En savoir plus sur les pipelines CI/CD\n\n- [Quelles sont les meilleures pratiques CI/CD à connaître ?](https://about.gitlab.com/fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices/ \"Quelles sont les meilleures pratiques CI/CD à connaître ?\")\n- [Le guide CI/CD de GitLab pour les débutants](https://about.gitlab.com/blog/beginner-guide-ci-cd/)\n- [Obtenez des pipelines plus rapides et plus flexibles avec un graphe acyclique orienté](https://about.gitlab.com/blog/directed-acyclic-graph/)\n- [Réduisez le temps de compilation avec une image Docker personnalisée](http://beenje.github.io/blog/posts/gitlab-ci-and-conda/)\n- [Présentation de la version bêta du catalogue GitLab CI/CD](https://about.gitlab.com/blog/introducing-the-gitlab-ci-cd-catalog-beta/)\n\n## FAQ sur le pipeline d’intégration continue\n\n### Comment choisir entre l'exécution séquentielle et parallèle des jobs dans un pipeline CI ?\n\nIl y a plusieurs considérations à prendre en compte pour choisir entre l'exécution séquentielle et parallèle des jobs dans un pipeline CI. Ainsi, il faut considérer les dépendances entre les jobs, la disponibilité des ressources, les temps d'exécution, les interférences potentielles, la structure de la séquence de tests ou encore les coûts que cela implique. \n\nPar exemple, si vous avez un job de compilation qui doit se terminer avant qu'un job de déploiement puisse démarrer, vous exécuterez ces jobs de manière séquentielle pour garantir le bon ordre d'exécution. En revanche, les tâches telles que les tests unitaires et les tests d'intégration peuvent généralement s'exécuter en parallèle, car elles ne dépendent pas de l'achèvement des autres.\n\n### Que sont les graphes acycliques orientés dans GitLab et comment améliorent-ils la flexibilité du pipeline CI ?\n\nUn graphe acyclique orienté dans un pipeline CI permet d'exécuter des jobs en fonction de leurs dépendances, plutôt que dans un ordre strictement séquentiel. Ce graphe vous permet ainsi de définir un ordre d'exécution des jobs pour que ceux des étapes ultérieures commencent dès que les jobs des étapes précédentes se terminent. Cela réduit le temps d'exécution global du pipeline, améliore l'efficacité et laisse même à certains jobs la possibilité de se terminer plus tôt que s'ils avaient été exécutés dans un ordre purement séquentiel (du premier au dernier dans la liste).\n\n### Pourquoi est-il important de choisir la bonne image Docker pour les jobs d'un pipeline CI GitLab ?\n\nGitLab utilise des images Docker pour exécuter des jobs dont l'image par défaut est ruby 3.1. Pour optimiser votre pipeline CI, il sera cependant crucial de choisir l'image la plus appropriée à vos besoins. Comprenez que les jobs téléchargent d'abord l'image Docker spécifiée. Si l'image contient des paquets supplémentaires inutiles, cela augmentera les temps de téléchargement et d'exécution. Il est donc important de s'assurer que l'image choisie contient uniquement les paquets essentiels afin d'éviter des retards inutiles dans l'exécution des jobs.\n\n### Prochaines étapes\n\nPour moderniser davantage vos pratiques de développement logiciel, consultez le [catalogue GitLab CI/CD](https://docs.gitlab.com/ee/architecture/blueprints/ci_pipeline_components/) pour savoir comment standardiser et réutiliser les composants CI/CD.\n","engineering",[23,24],"CI","tutorial","2025-01-07",{"slug":27,"featured":6,"template":28},"basics-of-gitlab-ci-updated","BlogPost","content:fr-fr:blog:basics-of-gitlab-ci-updated.yml","yaml","Basics Of Gitlab Ci Updated","content","fr-fr/blog/basics-of-gitlab-ci-updated.yml","fr-fr/blog/basics-of-gitlab-ci-updated","yml",{"_path":37,"_dir":38,"_draft":6,"_partial":6,"_locale":7,"data":39,"_id":452,"_type":30,"title":453,"_source":32,"_file":454,"_stem":455,"_extension":35},"/shared/fr-fr/main-navigation","fr-fr",{"logo":40,"freeTrial":45,"sales":50,"login":55,"items":60,"search":393,"minimal":429,"duo":443},{"config":41},{"href":42,"dataGaName":43,"dataGaLocation":44},"/fr-fr/","gitlab logo","header",{"text":46,"config":47},"Commencer un essai gratuit",{"href":48,"dataGaName":49,"dataGaLocation":44},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":51,"config":52},"Contacter l'équipe commerciale",{"href":53,"dataGaName":54,"dataGaLocation":44},"/fr-fr/sales/","sales",{"text":56,"config":57},"Connexion",{"href":58,"dataGaName":59,"dataGaLocation":44},"https://gitlab.com/users/sign_in/","sign in",[61,105,204,209,314,374],{"text":62,"config":63,"cards":65,"footer":88},"Plateforme",{"dataNavLevelOne":64},"platform",[66,72,80],{"title":62,"description":67,"link":68},"La plateforme DevSecOps alimentée par l'IA la plus complète",{"text":69,"config":70},"Découvrir notre plateforme",{"href":71,"dataGaName":64,"dataGaLocation":44},"/fr-fr/platform/",{"title":73,"description":74,"link":75},"GitLab Duo (IA)","Créez des logiciels plus rapidement en tirant parti de l'IA à chaque étape du développement",{"text":76,"config":77},"Découvrez GitLab Duo",{"href":78,"dataGaName":79,"dataGaLocation":44},"/fr-fr/gitlab-duo/","gitlab duo ai",{"title":81,"description":82,"link":83},"Choisir GitLab","10 raisons pour lesquelles les entreprises choisissent GitLab",{"text":84,"config":85},"En savoir plus",{"href":86,"dataGaName":87,"dataGaLocation":44},"/fr-fr/why-gitlab/","why gitlab",{"title":89,"items":90},"Démarrer avec",[91,96,101],{"text":92,"config":93},"Ingénierie de plateforme",{"href":94,"dataGaName":95,"dataGaLocation":44},"/fr-fr/solutions/platform-engineering/","platform engineering",{"text":97,"config":98},"Expérience développeur",{"href":99,"dataGaName":100,"dataGaLocation":44},"/fr-fr/developer-experience/","Developer experience",{"text":102,"config":103},"MLOps",{"href":104,"dataGaName":102,"dataGaLocation":44},"/fr-fr/topics/devops/the-role-of-ai-in-devops/",{"text":106,"left":107,"config":108,"link":110,"lists":114,"footer":186},"Produit",true,{"dataNavLevelOne":109},"solutions",{"text":111,"config":112},"Voir toutes les solutions",{"href":113,"dataGaName":109,"dataGaLocation":44},"/fr-fr/solutions/",[115,141,164],{"title":116,"description":117,"link":118,"items":123},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":119},{"icon":120,"href":121,"dataGaName":122,"dataGaLocation":44},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[124,128,132,137],{"text":125,"config":126},"CI/CD",{"href":127,"dataGaLocation":44,"dataGaName":125},"/fr-fr/solutions/continuous-integration/",{"text":129,"config":130},"Développement assisté par l'IA",{"href":78,"dataGaLocation":44,"dataGaName":131},"AI assisted development",{"text":133,"config":134},"Gestion du code source",{"href":135,"dataGaLocation":44,"dataGaName":136},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":138,"config":139},"Livraison de logiciels automatisée",{"href":121,"dataGaLocation":44,"dataGaName":140},"Automated software delivery",{"title":142,"description":143,"link":144,"items":149},"Securité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":145},{"href":146,"dataGaName":147,"dataGaLocation":44,"icon":148},"/fr-fr/solutions/security-compliance/","security and compliance","ShieldCheckLight",[150,154,159],{"text":151,"config":152},"Sécurité et conformité",{"href":146,"dataGaLocation":44,"dataGaName":153},"Security & Compliance",{"text":155,"config":156},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":157,"dataGaLocation":44,"dataGaName":158},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":160,"config":161},"Conformité et gouvernance",{"href":162,"dataGaLocation":44,"dataGaName":163},"/fr-fr/solutions/continuous-software-compliance/","Compliance and governance",{"title":165,"link":166,"items":171},"Mesures",{"config":167},{"icon":168,"href":169,"dataGaName":170,"dataGaLocation":44},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[172,176,181],{"text":173,"config":174},"Visibilité et mesures",{"href":169,"dataGaLocation":44,"dataGaName":175},"Visibility and Measurement",{"text":177,"config":178},"Gestion de la chaîne de valeur",{"href":179,"dataGaLocation":44,"dataGaName":180},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":182,"config":183},"Données d'analyse et informations clés",{"href":184,"dataGaLocation":44,"dataGaName":185},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":187,"items":188},"GitLab pour",[189,194,199],{"text":190,"config":191},"Entreprises",{"href":192,"dataGaLocation":44,"dataGaName":193},"/fr-fr/enterprise/","enterprise",{"text":195,"config":196},"PME",{"href":197,"dataGaLocation":44,"dataGaName":198},"/fr-fr/small-business/","small business",{"text":200,"config":201},"Secteur public",{"href":202,"dataGaLocation":44,"dataGaName":203},"/fr-fr/solutions/public-sector/","public sector",{"text":205,"config":206},"Tarifs",{"href":207,"dataGaName":208,"dataGaLocation":44,"dataNavLevelOne":208},"/fr-fr/pricing/","pricing",{"text":210,"config":211,"link":213,"lists":217,"feature":301},"Ressources",{"dataNavLevelOne":212},"resources",{"text":214,"config":215},"Afficher toutes les ressources",{"href":216,"dataGaName":212,"dataGaLocation":44},"/fr-fr/resources/",[218,251,273],{"title":219,"items":220},"Premiers pas",[221,226,231,236,241,246],{"text":222,"config":223},"Installation",{"href":224,"dataGaName":225,"dataGaLocation":44},"/fr-fr/install/","install",{"text":227,"config":228},"Guides de démarrage rapide",{"href":229,"dataGaName":230,"dataGaLocation":44},"/fr-fr/get-started/","quick setup checklists",{"text":232,"config":233},"Apprentissage",{"href":234,"dataGaLocation":44,"dataGaName":235},"https://university.gitlab.com/","learn",{"text":237,"config":238},"Documentation sur le produit",{"href":239,"dataGaName":240,"dataGaLocation":44},"https://docs.gitlab.com/","product documentation",{"text":242,"config":243},"Vidéos sur les bonnes pratiques",{"href":244,"dataGaName":245,"dataGaLocation":44},"/fr-fr/getting-started-videos/","best practice videos",{"text":247,"config":248},"Intégrations",{"href":249,"dataGaName":250,"dataGaLocation":44},"/fr-fr/integrations/","integrations",{"title":252,"items":253},"Découvrir",[254,259,263,268],{"text":255,"config":256},"Histoires de succès client",{"href":257,"dataGaName":258,"dataGaLocation":44},"/fr-fr/customers/","customer success stories",{"text":260,"config":261},"Blog",{"href":262,"dataGaName":5,"dataGaLocation":44},"/fr-fr/blog/",{"text":264,"config":265},"Travail à distance",{"href":266,"dataGaName":267,"dataGaLocation":44},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":269,"config":270},"TeamOps",{"href":271,"dataGaName":272,"dataGaLocation":44},"/fr-fr/teamops/","teamops",{"title":274,"items":275},"Connecter",[276,281,286,291,296],{"text":277,"config":278},"Services GitLab",{"href":279,"dataGaName":280,"dataGaLocation":44},"/fr-fr/services/","services",{"text":282,"config":283},"Communauté",{"href":284,"dataGaName":285,"dataGaLocation":44},"/community/","community",{"text":287,"config":288},"Forum",{"href":289,"dataGaName":290,"dataGaLocation":44},"https://forum.gitlab.com/","forum",{"text":292,"config":293},"Événements",{"href":294,"dataGaName":295,"dataGaLocation":44},"/events/","events",{"text":297,"config":298},"Partenaires",{"href":299,"dataGaName":300,"dataGaLocation":44},"/fr-fr/partners/","partners",{"backgroundColor":302,"textColor":303,"text":304,"image":305,"link":309},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":306,"config":307},"carte promo The Source",{"src":308},"/images/navigation/the-source-promo-card.svg",{"text":310,"config":311},"Lire les articles les plus récents",{"href":312,"dataGaName":313,"dataGaLocation":44},"/fr-fr/the-source/","the source",{"text":315,"config":316,"lists":318},"Société",{"dataNavLevelOne":317},"company",[319],{"items":320},[321,326,332,334,339,344,349,354,359,364,369],{"text":322,"config":323},"À propos",{"href":324,"dataGaName":325,"dataGaLocation":44},"/fr-fr/company/","about",{"text":327,"config":328,"footerGa":331},"Emplois",{"href":329,"dataGaName":330,"dataGaLocation":44},"/jobs/","jobs",{"dataGaName":330},{"text":292,"config":333},{"href":294,"dataGaName":295,"dataGaLocation":44},{"text":335,"config":336},"Leadership",{"href":337,"dataGaName":338,"dataGaLocation":44},"/company/team/e-group/","leadership",{"text":340,"config":341},"Équipe",{"href":342,"dataGaName":343,"dataGaLocation":44},"/company/team/","team",{"text":345,"config":346},"Manuel",{"href":347,"dataGaName":348,"dataGaLocation":44},"https://handbook.gitlab.com/","handbook",{"text":350,"config":351},"Relations avec les investisseurs",{"href":352,"dataGaName":353,"dataGaLocation":44},"https://ir.gitlab.com/","investor relations",{"text":355,"config":356},"Centre de confiance",{"href":357,"dataGaName":358,"dataGaLocation":44},"/fr-fr/security/","trust center",{"text":360,"config":361},"Centre pour la transparence de l'IA",{"href":362,"dataGaName":363,"dataGaLocation":44},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":365,"config":366},"Newsletter",{"href":367,"dataGaName":368,"dataGaLocation":44},"/company/contact/","newsletter",{"text":370,"config":371},"Presse",{"href":372,"dataGaName":373,"dataGaLocation":44},"/press/","press",{"text":375,"config":376,"lists":377},"Nous contacter",{"dataNavLevelOne":317},[378],{"items":379},[380,383,388],{"text":51,"config":381},{"href":53,"dataGaName":382,"dataGaLocation":44},"talk to sales",{"text":384,"config":385},"Aide",{"href":386,"dataGaName":387,"dataGaLocation":44},"/support/","get help",{"text":389,"config":390},"Portail clients GitLab",{"href":391,"dataGaName":392,"dataGaLocation":44},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":394,"login":395,"suggestions":402},"Fermer",{"text":396,"link":397},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":398,"config":399},"gitlab.com",{"href":58,"dataGaName":400,"dataGaLocation":401},"search login","search",{"text":403,"default":404},"Suggestions",[405,408,413,415,420,425],{"text":73,"config":406},{"href":78,"dataGaName":407,"dataGaLocation":401},"GitLab Duo (AI)",{"text":409,"config":410},"Suggestions de code (IA)",{"href":411,"dataGaName":412,"dataGaLocation":401},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":125,"config":414},{"href":127,"dataGaName":125,"dataGaLocation":401},{"text":416,"config":417},"GitLab sur AWS",{"href":418,"dataGaName":419,"dataGaLocation":401},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":421,"config":422},"GitLab sur Google Cloud ",{"href":423,"dataGaName":424,"dataGaLocation":401},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":426,"config":427},"Pourquoi utiliser GitLab ?",{"href":86,"dataGaName":428,"dataGaLocation":401},"Why GitLab?",{"freeTrial":430,"mobileIcon":435,"desktopIcon":440},{"text":431,"config":432},"Commencer votre essai gratuit",{"href":433,"dataGaName":49,"dataGaLocation":434},"https://gitlab.com/-/trials/new/","nav",{"altText":436,"config":437},"Icône GitLab",{"src":438,"dataGaName":439,"dataGaLocation":434},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":436,"config":441},{"src":442,"dataGaName":439,"dataGaLocation":434},"/images/brand/gitlab-logo-type.svg",{"freeTrial":444,"mobileIcon":448,"desktopIcon":450},{"text":445,"config":446},"En savoir plus sur GitLab Duo",{"href":78,"dataGaName":447,"dataGaLocation":434},"gitlab duo",{"altText":436,"config":449},{"src":438,"dataGaName":439,"dataGaLocation":434},{"altText":436,"config":451},{"src":442,"dataGaName":439,"dataGaLocation":434},"content:shared:fr-fr:main-navigation.yml","Main Navigation","shared/fr-fr/main-navigation.yml","shared/fr-fr/main-navigation",{"_path":457,"_dir":38,"_draft":6,"_partial":6,"_locale":7,"title":458,"titleMobile":458,"button":459,"config":463,"_id":465,"_type":30,"_source":32,"_file":466,"_stem":467,"_extension":35},"/shared/fr-fr/banner","La plateforme GitLab Duo Agent est maintenant en bêta publique !",{"text":84,"config":460},{"href":461,"dataGaName":462,"dataGaLocation":44},"/fr-fr/gitlab-duo/agent-platform/","duo banner",{"layout":464},"release","content:shared:fr-fr:banner.yml","shared/fr-fr/banner.yml","shared/fr-fr/banner",{"_path":469,"_dir":38,"_draft":6,"_partial":6,"_locale":7,"data":470,"_id":676,"_type":30,"title":677,"_source":32,"_file":678,"_stem":679,"_extension":35},"/shared/fr-fr/main-footer",{"text":471,"source":472,"edit":478,"contribute":483,"config":488,"items":493,"minimal":667},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":473,"config":474},"Afficher le code source de la page",{"href":475,"dataGaName":476,"dataGaLocation":477},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":479,"config":480},"Modifier cette page",{"href":481,"dataGaName":482,"dataGaLocation":477},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":484,"config":485},"Veuillez contribuer",{"href":486,"dataGaName":487,"dataGaLocation":477},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":489,"facebook":490,"youtube":491,"linkedin":492},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[494,517,571,604,638],{"title":62,"links":495,"subMenu":500},[496],{"text":497,"config":498},"Plateforme DevSecOps",{"href":71,"dataGaName":499,"dataGaLocation":477},"devsecops platform",[501],{"title":205,"links":502},[503,507,512],{"text":504,"config":505},"Voir les forfaits",{"href":207,"dataGaName":506,"dataGaLocation":477},"view plans",{"text":508,"config":509},"Pourquoi choisir GitLab Premium ?",{"href":510,"dataGaName":511,"dataGaLocation":477},"/fr-fr/pricing/premium/","why premium",{"text":513,"config":514},"Pourquoi choisir GitLab Ultimate ?",{"href":515,"dataGaName":516,"dataGaLocation":477},"/fr-fr/pricing/ultimate/","why ultimate",{"title":518,"links":519},"Solutions",[520,525,528,530,535,540,544,547,550,555,557,559,561,566],{"text":521,"config":522},"Transformation digitale",{"href":523,"dataGaName":524,"dataGaLocation":477},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":151,"config":526},{"href":146,"dataGaName":527,"dataGaLocation":477},"security & compliance",{"text":138,"config":529},{"href":121,"dataGaName":122,"dataGaLocation":477},{"text":531,"config":532},"Développement agile",{"href":533,"dataGaName":534,"dataGaLocation":477},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":536,"config":537},"Transformation cloud",{"href":538,"dataGaName":539,"dataGaLocation":477},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":541,"config":542},"SCM",{"href":135,"dataGaName":543,"dataGaLocation":477},"source code management",{"text":125,"config":545},{"href":127,"dataGaName":546,"dataGaLocation":477},"continuous integration & delivery",{"text":177,"config":548},{"href":179,"dataGaName":549,"dataGaLocation":477},"value stream management",{"text":551,"config":552},"GitOps",{"href":553,"dataGaName":554,"dataGaLocation":477},"/fr-fr/solutions/gitops/","gitops",{"text":190,"config":556},{"href":192,"dataGaName":193,"dataGaLocation":477},{"text":195,"config":558},{"href":197,"dataGaName":198,"dataGaLocation":477},{"text":200,"config":560},{"href":202,"dataGaName":203,"dataGaLocation":477},{"text":562,"config":563},"Formation",{"href":564,"dataGaName":565,"dataGaLocation":477},"/fr-fr/solutions/education/","education",{"text":567,"config":568},"Services financiers",{"href":569,"dataGaName":570,"dataGaLocation":477},"/fr-fr/solutions/finance/","financial services",{"title":210,"links":572},[573,575,577,579,582,584,588,590,592,594,596,598,600,602],{"text":222,"config":574},{"href":224,"dataGaName":225,"dataGaLocation":477},{"text":227,"config":576},{"href":229,"dataGaName":230,"dataGaLocation":477},{"text":232,"config":578},{"href":234,"dataGaName":235,"dataGaLocation":477},{"text":237,"config":580},{"href":239,"dataGaName":581,"dataGaLocation":477},"docs",{"text":260,"config":583},{"href":262,"dataGaName":5},{"text":585,"config":586},"Histoires de réussite client",{"href":587,"dataGaLocation":477},"/customers/",{"text":255,"config":589},{"href":257,"dataGaName":258,"dataGaLocation":477},{"text":264,"config":591},{"href":266,"dataGaName":267,"dataGaLocation":477},{"text":277,"config":593},{"href":279,"dataGaName":280,"dataGaLocation":477},{"text":269,"config":595},{"href":271,"dataGaName":272,"dataGaLocation":477},{"text":282,"config":597},{"href":284,"dataGaName":285,"dataGaLocation":477},{"text":287,"config":599},{"href":289,"dataGaName":290,"dataGaLocation":477},{"text":292,"config":601},{"href":294,"dataGaName":295,"dataGaLocation":477},{"text":297,"config":603},{"href":299,"dataGaName":300,"dataGaLocation":477},{"title":315,"links":605},[606,608,610,612,614,616,618,622,627,629,631,633],{"text":322,"config":607},{"href":324,"dataGaName":317,"dataGaLocation":477},{"text":327,"config":609},{"href":329,"dataGaName":330,"dataGaLocation":477},{"text":335,"config":611},{"href":337,"dataGaName":338,"dataGaLocation":477},{"text":340,"config":613},{"href":342,"dataGaName":343,"dataGaLocation":477},{"text":345,"config":615},{"href":347,"dataGaName":348,"dataGaLocation":477},{"text":350,"config":617},{"href":352,"dataGaName":353,"dataGaLocation":477},{"text":619,"config":620},"Sustainability",{"href":621,"dataGaName":619,"dataGaLocation":477},"/sustainability/",{"text":623,"config":624},"Diversité, inclusion et appartenance (DIB)",{"href":625,"dataGaName":626,"dataGaLocation":477},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":355,"config":628},{"href":357,"dataGaName":358,"dataGaLocation":477},{"text":365,"config":630},{"href":367,"dataGaName":368,"dataGaLocation":477},{"text":370,"config":632},{"href":372,"dataGaName":373,"dataGaLocation":477},{"text":634,"config":635},"Déclaration de transparence sur l'esclavage moderne",{"href":636,"dataGaName":637,"dataGaLocation":477},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":375,"links":639},[640,643,645,647,652,657,662],{"text":641,"config":642},"Échanger avec un expert",{"href":53,"dataGaName":54,"dataGaLocation":477},{"text":384,"config":644},{"href":386,"dataGaName":387,"dataGaLocation":477},{"text":389,"config":646},{"href":391,"dataGaName":392,"dataGaLocation":477},{"text":648,"config":649},"Statut",{"href":650,"dataGaName":651,"dataGaLocation":477},"https://status.gitlab.com/","status",{"text":653,"config":654},"Conditions d'utilisation",{"href":655,"dataGaName":656},"/terms/","terms of use",{"text":658,"config":659},"Déclaration de confidentialité",{"href":660,"dataGaName":661,"dataGaLocation":477},"/fr-fr/privacy/","privacy statement",{"text":663,"config":664},"Préférences en matière de cookies",{"dataGaName":665,"dataGaLocation":477,"id":666,"isOneTrustButton":107},"cookie preferences","ot-sdk-btn",{"items":668},[669,671,674],{"text":653,"config":670},{"href":655,"dataGaName":656,"dataGaLocation":477},{"text":672,"config":673},"Politique de confidentialité",{"href":660,"dataGaName":661,"dataGaLocation":477},{"text":663,"config":675},{"dataGaName":665,"dataGaLocation":477,"id":666,"isOneTrustButton":107},"content:shared:fr-fr:main-footer.yml","Main Footer","shared/fr-fr/main-footer.yml","shared/fr-fr/main-footer",[681],{"_path":682,"_dir":683,"_draft":6,"_partial":6,"_locale":7,"content":684,"config":688,"_id":690,"_type":30,"title":18,"_source":32,"_file":691,"_stem":692,"_extension":35},"/en-us/blog/authors/itzik-gan-baruch","authors",{"name":18,"config":685},{"headshot":686,"ctfId":687},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658921/Blog/Author%20Headshots/iganbaruch-headshot.jpg","iganbaruch",{"template":689},"BlogAuthor","content:en-us:blog:authors:itzik-gan-baruch.yml","en-us/blog/authors/itzik-gan-baruch.yml","en-us/blog/authors/itzik-gan-baruch",{"_path":694,"_dir":38,"_draft":6,"_partial":6,"_locale":7,"header":695,"eyebrow":696,"blurb":697,"button":698,"secondaryButton":702,"_id":704,"_type":30,"title":705,"_source":32,"_file":706,"_stem":707,"_extension":35},"/shared/fr-fr/next-steps","Commencez à livrer des logiciels de meilleurs qualité plus rapidement","Plus de 50 % des entreprises du classement Fortune 100 font confiance à GitLab","Découvrez comment la plateforme DevSecOps intelligente\n\n\npeut aider votre équipe.\n",{"text":46,"config":699},{"href":700,"dataGaName":49,"dataGaLocation":701},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":51,"config":703},{"href":53,"dataGaName":54,"dataGaLocation":701},"content:shared:fr-fr:next-steps.yml","Next Steps","shared/fr-fr/next-steps.yml","shared/fr-fr/next-steps",1753475388213]