[{"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":469,"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\n(CI)](https://about.gitlab.com/fr-fr/topics/ci-cd/benefits-continuous-integration/\n\"Qu'est-ce que l'intégration continue (CI) ?\") ni à son rôle clé dans le\ncycle de vie du développement logiciel.\n\n\nÀ présent, supposons que vous travaillez sur un projet pour lequel\nl'intégralité du code est répartie dans seulement deux fichiers. Pour\ngarantir le bon fonctionnement de ce projet, il est impératif que la\nconcaténation de ces deux fichiers contienne la phrase « Hello world ».\n\n\nToute la réussite du projet repose sur cette simple phrase, car sans elle,\ntout serait compromis.\n\n\nConscient de cet enjeu, votre meilleur développeur logiciel a décidé de\ncréer un script qui s'exécute dès qu’un nouveau morceau de code est envoyé\naux clients.\n\n\nVoici à quoi cela ressemble  :\n\n\n```bash\n\ncat file1.txt file2.txt | grep -q \"Hello world\"\n\n```\n\n\nMême si, en l'état, ce script permet d'exécuter notre tâche, son\ndéclenchement reste manuel. Et, avec une équipe de développement composée de\n10 personnes, vous n'êtes pas à l'abri d'une erreur humaine qui pourrait\nvous coûter très cher. \n\n\nLa preuve en est, pas plus tard que la semaine dernière, un nouveau membre\nde votre équipe a oublié d'exécuter le script, provoquant des erreurs de\ncompilation pour trois de vos clients.\n\n\nVous prenez donc la décision de résoudre ce problème, une bonne fois pour\ntoutes, en utilisant le pipeline d'[intégration et de livraison\ncontinues](https://about.gitlab.com/fr-fr/solutions/continuous-integration/\n\"Intégration et livraison continues\") de GitLab. Par chance, votre code est\ndéjà sur la plateforme. Il ne vous reste plus qu'à vous lancer.  \n\n\n## Effectuer un premier test dans le pipeline CI de GitLab\n\n\nÀ la lecture de la documentation de GitLab, nous savons qu'il suffit de\nréunir deux lignes de code dans un fichier appelé `.gitlab-ci.yml`:\n\n\n```yaml\n\ntest:\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n```\n\n\nNous le validons et constatons que la compilation s'est déroulée avec succès\n\n\n![Compilation réussie dans le pipeline d’intégration\ncontinue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/build_succeeded.png)\n\n\nMaintenant, remplaçons « world » par « Africa » dans le deuxième fichier et\nvoyons ce qui se passe :\n\n\n![Échec de compilation dans le pipeline CI\nGitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/build_failed.png)\n\n\nComme nous pouvions le prévoir, la compilation a échoué.\n\n\nNous avons désormais mis en place l'automatisation des tests.  \n\n\nÀ partir de maintenant, [GitLab\nCI](https://about.gitlab.com/fr-fr/blog/ci-deployment-and-environments/\n\"Comment déployer du code dans des environnements multiples avec GitLab CI\")\nexécutera notre script de test dès que nous effectuerons un push du code\nvers le dépôt de code source dans l'environnement\n[DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Que signifie DevOps\n?\"). \n\n\nRemarque : dans l'exemple ci-dessus, nous supposons que file1.txt et\nfile2.txt existent sur l'hôte du runner. Pour exécuter cet exemple dans\nGitLab, utilisez le code ci-dessous, qui crée d'abord les fichiers, puis\nexécute le script.\n\n\n```yaml\n\ntest:\n\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```\n\n\nPour simplifier notre démonstration, nous partons du principe que ces\nfichiers existent déjà sur l'hôte. Nous n'allons donc pas les créer dans les\nétapes suivantes.\n\n\n## Rendre les résultats des compilations téléchargeables\n\n\nLa prochaine étape consiste à empaqueter le code avant de l'envoyer aux\nclients. Alors, pourquoi ne pas automatiser aussi cette partie du processus\nde développement logiciel ?\n\n\nPour cela, tout ce que nous devons faire est de définir un autre job pour\nl'intégration continue. \n\n\nCommençons par nommer notre job « package » :\n\n\n```yaml\n\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\n\nNous avons maintenant deux onglets : \n\n\n![Deux onglets - générés par deux\njobs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/two_tabs.png)\n\n\nCependant, nous avons oublié de spécifier que le nouveau fichier est un\nartefact de compilation, afin qu’il puisse être téléchargé. Nous pouvons\ncorriger cela en ajoutant une section `artefacts` :\n\n\n```yaml\n\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\n\nVérifions que tout est en place :\n\n\n![Artefact de compilation téléchargeable dans le pipeline CI/CD de\nGitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/artifacts.png)\n\n\nFélicitations ! Tout semble fonctionnel. En revanche, dans la configuration\nactuelle, les jobs s'exécutent en parallèle. Cela signifie que notre\napplication pourra être empaquetée, et ce, même si les tests échouent. Pour\néviter que cela ne se produise, nous allons devoir exécuter les jobs de\nmanière séquentielle.  \n\n\n## Exécuter des jobs de manière séquentielle\n\n\nPour éviter d'empaqueter une application contenant des erreurs, nous allons\nfaire en sorte d'exécuter le job « package » uniquement si les tests sont\npréalablement réussis. Pour commencer, définissons l'ordre d'exécution en\nétablissant des étapes spécifiques  :\n\n\n```yaml\n\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\n\nCela devrait maintenant fonctionner.\n\n\nNous souhaitons également garantir que la compilation (qui est représentée\npar la concaténation dans notre exemple) ne s'exécute qu'une seule fois. En\neffet, cette étape pouvant être chronophage, il serait dommage de l'exécuter\ninutilement.\n\n\nPour éviter cela, définissons une étape supplémentaire :\n\n\n```yaml\n\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\n\nJetons un œil à nos artefacts :\n\n\n![Artefacts de compilation dans le pipeline CI de\nGitLab](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/clean-artifacts.png)\n\n\nTout a l'air de fonctionner. En revanche, il faudrait éviter de rendre le\nfichier « compile » téléchargeable. Pour cela, nous allons rendre nos\nartefacts temporaires expirables en définissant `expire_in` à « 20 minutes\n».  \n\n\n```yaml\n\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\n\nMaintenant, notre configuration semble plutôt complète : \n\n- Nous avons trois étapes séquentielles pour compiler, tester et empaqueter\nnotre application. \n\n- Nous transmettons également l'application compilée aux étapes suivantes\npour ne pas exécuter la compilation à deux reprises (ce qui accélère le\nprocessus). \n\n- Et nous stockons une version empaquetée de notre application dans les\nartefacts de compilation pour une utilisation ultérieure.\n\n\n## Savoir quelle image Docker utiliser\n\n\nJusqu'ici, tout va bien. Cependant, en regardant de plus près, nos\ncompilations semblent toujours lentes. Prenons un moment pour regarder les\njournaux (logs) :\n\n\n![Image ruby\n3.1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/ruby-31.png)\n\n\nEn observant de plus près, nous remarquons la mention suivante : `ruby:3.1`.\nCela signifie que GitLab.com utilise des images Docker pour [exécuter nos\ncompilations](https://about.gitlab.com/blog/shared-runners/), et qu’il\nutilise [par\ndéfaut](https://docs.gitlab.com/ee/user/gitlab_com/#shared-runners), l'image\n[`ruby:3.1`](https://hub.docker.com/_/ruby/).\n\n\nCette image contient certainement de nombreux paquets dont nous n'avons pas\nbesoin. Dans un souci d'optimisation de notre pipeline CI, il serait donc\npréférable de changer d'image. Après une courte recherche sur Google, nous\ndécouvrons qu'il existe une image Linux presque vierge appelée\n[`alpine`](https://hub.docker.com/_/alpine/). Nous allons alors l'utiliser.\nPour cela, nous devrons ajouter `image: alpine` au fichier `.gitlab-ci.yml`.\n\n\nEt voilà !  Nous avons maintenant réduit le temps de compilation de presque\ntrois minutes :\n\n\n![Vitesse de compilation améliorée dans le pipeline de\nGitLab](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/speed.png)\n\n\nVous pouvez également trouver des images libres de droits sur\n[mysql](https://hub.docker.com/_/mysql/),\n[Python](https://hub.docker.com/_/python/),\n[Java](https://hub.docker.com/_/java/) et\n[php](https://hub.docker.com/_/php/). Il est facile, alors, d'en choisir une\npour notre pile technologique. \n\n\nNote : il sera toujours préférable d'utiliser une image qui ne contient\naucun logiciel supplémentaire dont vous n'avez pas besoin, car cela minimise\ngrandement le temps de téléchargement.\n\n\n## Gérer des scénarios complexes \n\n\nImaginons maintenant un scénario un peu plus complexe. Par exemple, un\nnouveau client souhaite que nous empaquetions notre application au format\n`.iso` plutôt qu'en `.gz`. \n\n\nÉtant donné que le pipeline d'intégration continue gère tout le processus,\net que les images ISO peuvent être créées avec la commande `mkisofs`, il\nsuffit d'ajouter un job supplémentaire.\n\n\nVoici à quoi notre configuration devrait ressembler :\n\n\n```yaml\n\nimage: alpine\n\n\nstages:\n  - compile\n  - test\n  - package\n\n# ... \"compile\" and \"test\" jobs are skipped here for the sake of compactness\n\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\n\nNotez que les noms des jobs ne doivent pas être nécessairement identiques.\nS'ils l'étaient, il serait impossible de faire s'exécuter les jobs en\nparallèle dans la même étape du processus de développement logiciel. \n\n\nAinsi, dans l'exemple qui suit, ignorez le fait que les jobs et étapes\nportent le même nom.\n\n\nQuoi qu'il en soit, la compilation échoue :\n\n\n![Echec de compilation dans le pipeline de\nGitLab](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/mkisofs.png)\n\n\nLe problème vient de  `mkisofs` qui n'est pas inclus dans l'image `alpine`.\nNous devons donc d'abord l'installer.\n\n\n## Gérer des logiciels et des paquets manquants \n\n\nSelon le [site Web d’Alpine\nLinux](https://pkgs.alpinelinux.org/contents?file=mkisofs&path=&name=&branch=edge&repo=&arch=\n\"Site Web Alpine Linux\"), `mkisofs` fait partie des paquets `xorriso` et\n`cdrkit`. Voici les commandes que nous devons exécuter pour installer un\npaquet :\n\n\n```bash\n\necho \"ipv6\" >> /etc/modules  # enable networking\n\napk update                   # update packages list\n\napk add xorriso              # install package\n\n```\n\n\nCes commandes s'exécutent de la même manière que toute autre commande au\nsein du processus d'intégration continue. La liste complète des commandes\nque nous devons transmettre à la section `script` devrait ressembler à ceci\n:\n\n\n```yml\n\nscript:\n\n- echo \"ipv6\" >> /etc/modules\n\n- apk update\n\n- apk add xorriso\n\n- mkisofs -o ./packaged.iso ./compiled.txt\n\n```\n\n\nCependant, pour des raisons sémantiques, plaçons les commandes liées à\nl'installation du paquet dans `before_script`. \n\n\nNotez que si vous utilisez `before_script` au niveau supérieur d'une\nconfiguration, alors les commandes s'exécuteront avant tous les jobs. Dans\nnotre cas, nous voulons simplement qu'elles s'exécutent avant un job\nspécifique.\n\n\n## Graphes acycliques orientés pour des pipelines CI plus rapides et\nflexibles\n\n\nPlus haut, nous avons configuré des étapes pour que les jobs d'empaquetage\nne s'exécutent qu'à la condition que les tests réussissent. Mais, que se\npasserait-il si nous voulions bouleverser le séquencement des étapes en\nexécutant certains jobs plus tôt qu'initialement prévu ? \n\n\nDans certains cas, le séquencement traditionnel des étapes peut ralentir la\ndurée globale d'exécution du [pipeline\nCI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce\nqu'un pipeline CI/CD ?\"). Pour éviter cela, nous pouvons choisir de\npersonnaliser le séquencement de nos jobs. \n\n\nPar exemple : imaginons que notre étape de test comprenne des tests lourds,\nprenant beaucoup de temps à s'exécuter. Supposons aussi que ces tests ne\nsoient pas nécessairement liés aux jobs d’empaquetage. Dans ce cas, il\nserait préférable que les jobs d’empaquetage puissent démarrer sans attendre\nla fin de ces tests. C'est là qu'interviennent les [graphes acycliques\norientés](https://about.gitlab.com/blog/directed-acyclic-graph/ \"Graphes\nacycliques orientés\"). Ces derniers visent à rompre l'ordre normal\nd'exécution des jobs (ordre séquentiel) grâce à la création de dépendances\nentre certains jobs. Vous pouvez ainsi définir un ordre personnalisé pour\nexécuter les différents jobs de votre pipeline CI.\n\n\nGrâce au mot-clé `needs`, GitLab crée des dépendances entre les jobs et leur\npermet de s'exécuter plus tôt, dès que leurs jobs dépendants sont terminés.\n\n\nDans l'exemple ci-dessous, les jobs d’empaquetage commenceront à s'exécuter\ndès que le test sera terminé. Ainsi, à l'avenir, si quelqu'un ajoute\nd'autres tests à l'étape de test, les jobs d’empaquetage commenceront à\ns'exécuter avant la fin des nouveaux tests :\n\n\n```yaml\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\n\nVoici notre version définitive de `.gitlab-ci.yml`:\n\n\n```yaml\n\nimage: alpine\n\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\n\nNous venons de créer un pipeline ! Ainsi, nous avons trois étapes\nséquentielles avec les \n\njobs `pack-gz` et `pack-iso` qui s'exécutent en parallèle à l'intérieur de\nl'étape d'empaquetage :\n\n\n![Représentation d'un artefact de compilation d'un pipeline\nCI](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/pipeline.png)\n\n\n## Améliorer votre pipeline CI\n\n\nNous allons maintenant découvrir comment améliorer notre pipeline\nd'intégration continue.\n\n\n### Intégrer des tests automatisés dans vos pipelines CI\n\n\nL'objectif clé du développement logiciel avec une approche DevOps est de\nréussir à créer des applications offrant une excellente expérience\nutilisateur. \n\n\nAvec cet objectif en tête, pourquoi ne pas renforcer le cycle de\ndéveloppement logiciel en cherchant à détecter d'éventuels bogues dès le\ndébut du processus ? Pour ce faire, ajoutons des tests à notre pipeline CI.\nDe cette façon, nous pourrons résoudre les problèmes le plus tôt possible.\n\n\nPar chance, le pipeline CI de GitLab nous facilite la tâche en proposant des\ntemplates de tests prêts à l'emploi. Tout ce que nous avons à faire, c'est\nd'inclure ces templates dans la configuration de notre pipeline CI.\n\n\nDans cet exemple, nous allons réaliser des [tests\nd'accessibilité](https://docs.gitlab.com/ee/ci/testing/accessibility_testing.html\n\"Test d'accessibilité\") :\n\n\n```yaml\n\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\n\nPersonnalisez la variable `a11y_urls` pour répertorier les URL des pages web\nà tester avec [Pa11y](https://pa11y.org/ \"Pa11y\") et GitLab [Code\nQuality](https://docs.gitlab.com/ee/ci/testing/code_quality.html \"Code\nQuality\"). \n\n\n```yaml\n   include:\n   - template: Jobs/Code-Quality.gitlab-ci.yml\n```\n\n\nGitLab facilite la consultation du rapport de test directement dans la zone\ndu widget de la [merge\nrequest](https://docs.gitlab.com/ee/user/project/merge_requests/ \"Merge\nrequest\"). Ce widget vous permet de voir la revue de code, l'état du\npipeline et les résultats des tests au même endroit. La capture d'écran\nci-dessous montre à quel point ce widget facilite le travail de vos\néquipes. \n\n\n![Exemple de rapport d'accessibilité dans le pipeline CI/CD de\nGitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-02_at_10.56.41.png)\n\n\u003Ccenter>\u003Ci>Widget pour les merge requests en matière\nd'accessibilité\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n\n![Exemple de rapport de test sur la qualité du code suite à une merge\nrequest dans\nGitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-02_at_11.00.25.png)\n\n\u003Ccenter>\u003Ci>Widget de merge request pour GitLab Code Quality\u003C/i>\u003C/center>\n\n\n### Matrice des compilations\n\n\nDans certains cas, nous devons tester notre application dans différentes\nconfigurations, versions de systèmes d'exploitation et langages de\nprogrammation. Nous utilisons alors la compilation «\n[parallel:matrix](https://docs.gitlab.com/ee/ci/yaml/#parallelmatrix\n\"parallel:matrix\") ». Cela nous permet de tester notre application à travers\ndiverses combinaisons en parallèle dans un seul job. Maintenant, testons\nnotre code avec différentes versions de Python et avec le mot-clé « matrix\n».\n\n\n```yaml\n\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\n\nLors de l'exécution du pipeline, ce job s'exécute en parallèle quatre fois,\nchaque fois en utilisant une image Python différente comme indiqué\nci-dessous :\n\n\n![Exécution de jobs en parallèle dans le pipeline\nCI/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\n### Tests unitaires\n\n\n#### Que sont les tests unitaires ?\n\n\nLes tests unitaires sont des tests ciblés et de petite envergure qui\nvérifient des composants ou des fonctions d'un logiciel. Ces tests\npermettent d'assurer qu'il fonctionne comme prévu. Ils sont essentiels pour\nvérifier que chaque partie du code fonctionne correctement et permettent de\ndétecter les bogues le plus tôt possible dans le processus de développement\nlogiciel. \n\n\nExemple : imaginez que vous développiez une application de calculatrice. Un\ntest unitaire pour la fonction « addition » va vérifier si le résultat d'un\ncalcul comme 2 + 2 est bien égale à 4. Si ce test est concluant, nous avons\nconfirmation que la fonction « addition » fonctionne correctement.\n\n\n#### Tests unitaires : les bonnes pratiques\n\n\nMettre en place des tests unitaires, c'est bien, mais il est possible\nd'aller encore plus loin pour faciliter la vie de vos équipes de\ndéveloppement.\n\n\nPar exemple, lorsqu'un test échoue, vos équipes reçoivent une notification.\nS'engage alors un long processus de vérification des job logs afin de\ntrouver et de corriger les erreurs. Ce processus est long et pourrait être\noptimisé.\n\n\nIl est possible de configurer votre job pour qu'il utilise des [rapports de\ntests\nunitaires](https://docs.gitlab.com/ee/ci/testing/unit_test_reports.html\n\"Rapports de tests unitaires\") (rapports détaillés des erreurs permettant de\nles traiter plus efficacement). GitLab affiche ces rapports dans la merge\nrequest et sur la page de détails des pipelines CI. Cela facilite\nl'identification des échecs, car il n'y a alors plus besoin de consulter\nl'intégralité du journal.\n\n\n#### Rapport de test JUnit\n\n\nCi-dessous un exemple de rapport de test JUnit : \n\n\n![Rapport de test JUnit dans un pipeline d'intégration\ncontinue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674097/Blog/Content%20Images/pipelines_junit_test_report_v13_10.png){:\n.shadow.center}\n\n\n### Stratégies d'intégration et de tests de bout en bout\n\n\nAfin de s'assurer que toutes les parties de notre code fonctionnent en\nharmonie (y compris les\n[microservices](https://about.gitlab.com/fr-fr/topics/microservices/ \"Que\nsont les microservices ?\"), les tests d'interface utilisateur), il est\ncapital de configurer un pipeline dédié à l'intégration et aux tests de bout\nen bout.\n\n\nCes tests sont exécutés [chaque\nnuit](https://docs.gitlab.com/ee/ci/pipelines/schedules.html) et il est\npossible de configurer le système pour que les [résultats soient\nautomatiquement envoyés vers un canal Slack\ndédié](https://docs.gitlab.com/ee/user/project/integrations/gitlab_slack_application.html#notification-events).\nAinsi, lorsque les équipes de développement arrivent le matin, elles peuvent\nrapidement travailler sur les problèmes identifiés la veille. L'objectif\nétant de détecter et de corriger les problèmes le plus tôt possible dans le\nprocessus de développement logiciel.\n\n\n### Environnement de test\n\n\nDans certains cas, nous avons besoin d'un environnement dédié pour tester\ncorrectement nos applications. On parle alors d'environnement de test. Avec\nle pipeline CI/CD de GitLab, nous pouvons automatiser le déploiement des\nenvironnements de test, et ainsi gagner un temps considérable. \n\n\nComme cet article se concentre principalement sur les pipelines\nd'intégration continue, nous ne nous attarderons pas sur ce point ici. En\nrevanche, libre à vous de consulter la section dédiée à ce sujet dans la\n[documentation\nGitLab](https://docs.gitlab.com/ee/topics/release_your_application.html).\n\n\n## Implémenter des scans de sécurité dans un pipeline CI\n\n\nVoici comment mettre en œuvre des scans de sécurité dans un pipeline CI.\n\n\n### Intégration des SAST et des DAST\n\n\nAvant toute chose, nous souhaitons garder notre code en sécurité. S'il y a\nla moindre vulnérabilité dans nos dernières modifications, nous voulons en\nêtre informés dès que possible. C'est pourquoi il est judicieux d'ajouter\ndes scans de sécurité à votre pipeline CI. \n\nCes scans vérifient le code à chaque commit et vous alertent dès qu'une\nfaille est détectée. \n\n\nIl existe deux types de scan : \n\n- les tests statiques de sécurité des applications\n([SAST](https://docs.gitlab.com/ee/user/application_security/sast/ \"SAST\"))\n\n- les tests dynamiques de sécurité des applications\n([DAST](https://docs.gitlab.com/ee/user/application_security/dast/ \"DAST\"))\n\n\nCi-dessous, consultez notre guide interactif qui vous montre comment ajouter\ndes scans de sécurité à votre pipeline CI. \n\n\nCliquez sur l'image ci-dessous pour commencer. \n\n\n[![Scans product\ntour](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\n\nGrâce à l'IA et à ses capacités d'analyse, nous pouvons également obtenir\ndes suggestions sur la manière dont les vulnérabilités peuvent être\ncorrigées. Consultez cette démonstration pour plus d'informations.\n\n\nCliquez sur l'image ci-dessous pour commencer. \n\n\n[![product tour explain vulnerability\n](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\n## Récapitulatif\n\n\nDans cet article, nous avons volontairement simplifié les exemples afin de\nfaciliter l'intégration des différents concepts de GitLab CI.\n\n\nRésumons rapidement ce que nous avons appris :\n\n1. Pour déléguer certaines tâches à GitLab CI, vous devez définir un ou\nplusieurs [jobs](https://docs.gitlab.com/ee/ci/jobs/) dans `.gitlab-ci.yml`.\n\n2. Les jobs doivent avoir des noms, de préférence facilement identifiables.\n\n3. Chaque job contient un ensemble de règles et d'instructions pour le\npipeline de GitLab. Ces derniers sont définis par des mots-clés spécifiques.\n\n4. Les jobs peuvent s'exécuter de manière séquentielle, en parallèle, ou\ndans l'ordre de votre choix grâce aux graphes acycliques orientés. \n\n5. Vous pouvez transférer des fichiers entre les jobs et les stocker dans\ndes artefacts de compilation afin de pouvoir les télécharger depuis\nl'interface de GitLab CI.\n\n6. Ajoutez [des tests et des scans de\nsécurité](https://docs.gitlab.com/ee/development/integrations/secure.html\n\"Tests et scans de sécurité\") au pipeline CI pour garantir la qualité et la\nsécurité de votre application.\n\n\nCi-dessous se trouvent des descriptions des termes et des mots-clés que nous\navons abordés dans cet article.\n\n\n### Mots-clés, descriptions et documentation\n\n\n{: #keywords}\n\n\n| Mots-clés/termes       | Description |\n\n|---------------|--------------------|\n\n| [.gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/) | Fichier contenant\ntoutes les explications sur la façon dont votre projet doit être construit |\n\n| [script](https://docs.gitlab.com/ee/ci/yaml/#script)        | Définit un\nscript shell à exécuter |\n\n| [before_script](https://docs.gitlab.com/ee/ci/yaml/#before_script) |\nUtilisé pour définir la commande qui doit être exécutée avant tous les jobs\n|\n\n|\n[image](https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#what-is-image)\n| Définit l’image Docker à utiliser |\n\n| [stages](https://docs.gitlab.com/ee/ci/yaml/#stages)         | Définit une\nétape du pipeline CI (par défaut : `test`) |\n\n| [artifacts](https://docs.gitlab.com/ee/ci/yaml/#artifacts)     | Définit\nune liste d'artefacts de compilation |\n\n|\n[artifacts:expire_in](https://docs.gitlab.com/ee/ci/yaml/#artifactsexpire_in)\n| Utilisé pour supprimer les artefacts téléchargés après une durée spécifiée\n|\n\n| [needs](https://docs.gitlab.com/ee/ci/yaml/#needs) | Permet de définir les\ndépendances entre les jobs et permet d'exécuter des jobs dans l'ordre de\nvotre choix |\n\n| [pipelines](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/) |\nUn pipeline est un groupe de compilations exécutées par étapes (batch) |\n\n\n## En savoir plus sur les pipelines CI/CD\n\n\n- [Quelles sont les meilleures pratiques CI/CD à connaître\n?](https://about.gitlab.com/fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices/\n\"Quelles sont les meilleures pratiques CI/CD à connaître ?\")\n\n- [Le guide CI/CD de GitLab pour les\ndébutants](https://about.gitlab.com/blog/beginner-guide-ci-cd/)\n\n- [Obtenez des pipelines plus rapides et plus flexibles avec un graphe\nacyclique orienté](https://about.gitlab.com/blog/directed-acyclic-graph/)\n\n- [Réduisez le temps de compilation avec une image Docker\npersonnalisée](http://beenje.github.io/blog/posts/gitlab-ci-and-conda/)\n\n- [Présentation de la version bêta du catalogue GitLab\nCI/CD](https://about.gitlab.com/blog/introducing-the-gitlab-ci-cd-catalog-beta/)\n\n\n## FAQ sur le pipeline d’intégration continue\n\n\n### Comment choisir entre l'exécution séquentielle et parallèle des jobs\ndans un pipeline CI ?\n\n\nIl y a plusieurs considérations à prendre en compte pour choisir entre\nl'exécution séquentielle et parallèle des jobs dans un pipeline CI. Ainsi,\nil faut considérer les dépendances entre les jobs, la disponibilité des\nressources, les temps d'exécution, les interférences potentielles, la\nstructure de la séquence de tests ou encore les coûts que cela implique. \n\n\nPar exemple, si vous avez un job de compilation qui doit se terminer avant\nqu'un job de déploiement puisse démarrer, vous exécuterez ces jobs de\nmanière séquentielle pour garantir le bon ordre d'exécution. En revanche,\nles tâches telles que les tests unitaires et les tests d'intégration peuvent\ngénéralement s'exécuter en parallèle, car elles ne dépendent pas de\nl'achèvement des autres.\n\n\n### Que sont les graphes acycliques orientés dans GitLab et comment\naméliorent-ils la flexibilité du pipeline CI ?\n\n\nUn graphe acyclique orienté dans un pipeline CI permet d'exécuter des jobs\nen fonction de leurs dépendances, plutôt que dans un ordre strictement\nséquentiel. Ce graphe vous permet ainsi de définir un ordre d'exécution des\njobs pour que ceux des étapes ultérieures commencent dès que les jobs des\nétapes précédentes se terminent. Cela réduit le temps d'exécution global du\npipeline, améliore l'efficacité et laisse même à certains jobs la\npossibilité de se terminer plus tôt que s'ils avaient été exécutés dans un\nordre purement séquentiel (du premier au dernier dans la liste).\n\n\n### Pourquoi est-il important de choisir la bonne image Docker pour les jobs\nd'un pipeline CI GitLab ?\n\n\nGitLab utilise des images Docker pour exécuter des jobs dont l'image par\ndéfaut est ruby 3.1. Pour optimiser votre pipeline CI, il sera cependant\ncrucial de choisir l'image la plus appropriée à vos besoins. Comprenez que\nles jobs téléchargent d'abord l'image Docker spécifiée. Si l'image contient\ndes paquets supplémentaires inutiles, cela augmentera les temps de\ntéléchargement et d'exécution. Il est donc important de s'assurer que\nl'image choisie contient uniquement les paquets essentiels afin d'éviter des\nretards inutiles dans l'exécution des jobs.\n\n\n### Prochaines étapes\n\n\nPour moderniser davantage vos pratiques de développement logiciel, consultez\nle [catalogue GitLab\nCI/CD](https://docs.gitlab.com/ee/architecture/blueprints/ci_pipeline_components/)\npour 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","/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,155,160],{"text":151,"config":152},"Application Security Testing",{"href":153,"dataGaName":154,"dataGaLocation":44},"/solutions/application-security-testing/","Application security testing",{"text":156,"config":157},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":158,"dataGaLocation":44,"dataGaName":159},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":161,"config":162},"Software Compliance",{"href":163,"dataGaName":161,"dataGaLocation":44},"/solutions/software-compliance/",{"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},"/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},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.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},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":436,"config":441},{"src":442,"dataGaName":439,"dataGaLocation":434},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.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":464,"_id":466,"_type":30,"_source":32,"_file":467,"_stem":468,"_extension":35},"/shared/fr-fr/banner","La plateforme GitLab Duo Agent est maintenant disponible en version bêta publique !",{"text":460,"config":461},"Essayer la version bêta",{"href":462,"dataGaName":463,"dataGaLocation":44},"/fr-fr/gitlab-duo/agent-platform/","duo banner",{"layout":465},"release","content:shared:fr-fr:banner.yml","shared/fr-fr/banner.yml","shared/fr-fr/banner",{"_path":470,"_dir":38,"_draft":6,"_partial":6,"_locale":7,"data":471,"_id":676,"_type":30,"title":677,"_source":32,"_file":678,"_stem":679,"_extension":35},"/shared/fr-fr/main-footer",{"text":472,"source":473,"edit":479,"contribute":484,"config":489,"items":494,"minimal":667},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":474,"config":475},"Afficher le code source de la page",{"href":476,"dataGaName":477,"dataGaLocation":478},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":480,"config":481},"Modifier cette page",{"href":482,"dataGaName":483,"dataGaLocation":478},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":485,"config":486},"Veuillez contribuer",{"href":487,"dataGaName":488,"dataGaLocation":478},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":490,"facebook":491,"youtube":492,"linkedin":493},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[495,518,572,604,638],{"title":62,"links":496,"subMenu":501},[497],{"text":498,"config":499},"Plateforme DevSecOps",{"href":71,"dataGaName":500,"dataGaLocation":478},"devsecops platform",[502],{"title":205,"links":503},[504,508,513],{"text":505,"config":506},"Voir les forfaits",{"href":207,"dataGaName":507,"dataGaLocation":478},"view plans",{"text":509,"config":510},"Pourquoi choisir GitLab Premium ?",{"href":511,"dataGaName":512,"dataGaLocation":478},"/fr-fr/pricing/premium/","why premium",{"text":514,"config":515},"Pourquoi choisir GitLab Ultimate ?",{"href":516,"dataGaName":517,"dataGaLocation":478},"/fr-fr/pricing/ultimate/","why ultimate",{"title":519,"links":520},"Solutions",[521,526,529,531,536,541,545,548,551,556,558,560,562,567],{"text":522,"config":523},"Transformation digitale",{"href":524,"dataGaName":525,"dataGaLocation":478},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":527,"config":528},"Sécurité et conformité",{"href":153,"dataGaName":154,"dataGaLocation":478},{"text":138,"config":530},{"href":121,"dataGaName":122,"dataGaLocation":478},{"text":532,"config":533},"Développement agile",{"href":534,"dataGaName":535,"dataGaLocation":478},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":537,"config":538},"Transformation cloud",{"href":539,"dataGaName":540,"dataGaLocation":478},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":542,"config":543},"SCM",{"href":135,"dataGaName":544,"dataGaLocation":478},"source code management",{"text":125,"config":546},{"href":127,"dataGaName":547,"dataGaLocation":478},"continuous integration & delivery",{"text":177,"config":549},{"href":179,"dataGaName":550,"dataGaLocation":478},"value stream management",{"text":552,"config":553},"GitOps",{"href":554,"dataGaName":555,"dataGaLocation":478},"/fr-fr/solutions/gitops/","gitops",{"text":190,"config":557},{"href":192,"dataGaName":193,"dataGaLocation":478},{"text":195,"config":559},{"href":197,"dataGaName":198,"dataGaLocation":478},{"text":200,"config":561},{"href":202,"dataGaName":203,"dataGaLocation":478},{"text":563,"config":564},"Formation",{"href":565,"dataGaName":566,"dataGaLocation":478},"/fr-fr/solutions/education/","education",{"text":568,"config":569},"Services financiers",{"href":570,"dataGaName":571,"dataGaLocation":478},"/fr-fr/solutions/finance/","financial services",{"title":210,"links":573},[574,576,578,580,583,585,588,590,592,594,596,598,600,602],{"text":222,"config":575},{"href":224,"dataGaName":225,"dataGaLocation":478},{"text":227,"config":577},{"href":229,"dataGaName":230,"dataGaLocation":478},{"text":232,"config":579},{"href":234,"dataGaName":235,"dataGaLocation":478},{"text":237,"config":581},{"href":239,"dataGaName":582,"dataGaLocation":478},"docs",{"text":260,"config":584},{"href":262,"dataGaName":5},{"text":586,"config":587},"Histoires de réussite client",{"href":257,"dataGaLocation":478},{"text":255,"config":589},{"href":257,"dataGaName":258,"dataGaLocation":478},{"text":264,"config":591},{"href":266,"dataGaName":267,"dataGaLocation":478},{"text":277,"config":593},{"href":279,"dataGaName":280,"dataGaLocation":478},{"text":269,"config":595},{"href":271,"dataGaName":272,"dataGaLocation":478},{"text":282,"config":597},{"href":284,"dataGaName":285,"dataGaLocation":478},{"text":287,"config":599},{"href":289,"dataGaName":290,"dataGaLocation":478},{"text":292,"config":601},{"href":294,"dataGaName":295,"dataGaLocation":478},{"text":297,"config":603},{"href":299,"dataGaName":300,"dataGaLocation":478},{"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":478},{"text":327,"config":609},{"href":329,"dataGaName":330,"dataGaLocation":478},{"text":335,"config":611},{"href":337,"dataGaName":338,"dataGaLocation":478},{"text":340,"config":613},{"href":342,"dataGaName":343,"dataGaLocation":478},{"text":345,"config":615},{"href":347,"dataGaName":348,"dataGaLocation":478},{"text":350,"config":617},{"href":352,"dataGaName":353,"dataGaLocation":478},{"text":619,"config":620},"Sustainability",{"href":621,"dataGaName":619,"dataGaLocation":478},"/sustainability/",{"text":623,"config":624},"Diversité, inclusion et appartenance (DIB)",{"href":625,"dataGaName":626,"dataGaLocation":478},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":355,"config":628},{"href":357,"dataGaName":358,"dataGaLocation":478},{"text":365,"config":630},{"href":367,"dataGaName":368,"dataGaLocation":478},{"text":370,"config":632},{"href":372,"dataGaName":373,"dataGaLocation":478},{"text":634,"config":635},"Déclaration de transparence sur l'esclavage moderne",{"href":636,"dataGaName":637,"dataGaLocation":478},"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":478},{"text":384,"config":644},{"href":386,"dataGaName":387,"dataGaLocation":478},{"text":389,"config":646},{"href":391,"dataGaName":392,"dataGaLocation":478},{"text":648,"config":649},"Statut",{"href":650,"dataGaName":651,"dataGaLocation":478},"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":478},"/fr-fr/privacy/","privacy statement",{"text":663,"config":664},"Préférences en matière de cookies",{"dataGaName":665,"dataGaLocation":478,"id":666,"isOneTrustButton":107},"cookie preferences","ot-sdk-btn",{"items":668},[669,671,674],{"text":653,"config":670},{"href":655,"dataGaName":656,"dataGaLocation":478},{"text":672,"config":673},"Politique de confidentialité",{"href":660,"dataGaName":661,"dataGaLocation":478},{"text":663,"config":675},{"dataGaName":665,"dataGaLocation":478,"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",1759347877038]