[{"data":1,"prerenderedAt":770},["ShallowReactive",2],{"/fr-fr/blog/secure-rust-development-with-gitlab":3,"navigation-fr-fr":37,"banner-fr-fr":442,"footer-fr-fr":452,"blog-post-authors-fr-fr-Fernando Diaz":662,"blog-related-posts-fr-fr-secure-rust-development-with-gitlab":676,"assessment-promotions-fr-fr":721,"next-steps-fr-fr":761},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":26,"isFeatured":12,"meta":27,"navigation":12,"path":28,"publishedDate":24,"seo":29,"stem":33,"tagSlugs":34,"__hash__":36},"blogPosts/fr-fr/blog/secure-rust-development-with-gitlab.yml","Secure Rust Development With Gitlab",[7],"fernando-diaz",null,"engineering",{"slug":11,"featured":12,"template":13},"secure-rust-development-with-gitlab",true,"BlogPost",{"title":15,"description":16,"authors":17,"tags":19,"heroImage":23,"category":9,"date":24,"body":25},"Rust : développement sécurisé avec GitLab","Découvrez comment GitLab prend en charge le développement en Rust grâce à ses capacités CI/CD, ses analyses de sécurité, ses intégrations dédiées et ses fonctionnalités d'IA.",[18],"Fernando Diaz",[20,21,22],"community","open source","tutorial","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314674/tct6zf6evw0xgddd2vo3.png","2025-11-06","Rust s'est imposé comme l'un des langages de programmation les plus appréciés grâce à ses performances,\nsa mémoire sécurisée et ses fonctionnalités attractives. Alors que l'adoption de Rust continue de croître,\nde nombreux développeurs recherchent des plateformes CI/CD robustes pour prendre en charge leurs projets Rust.\n\nPour les équipes de développement qui utilisent Rust, l'attrait de GitLab va bien au-delà du simple hébergement de code. La plateforme offre\ndes capacités [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") robustes qui s'alignent parfaitement avec l'accent mis par Rust sur la sécurité, les performances et la fiabilité. GitLab facilite la création de dépôts et l'utilisation de conteneurs Docker prêts à l'emploi\npour exécuter des jobs CI personnalisés. Les équipes peuvent facilement configurer des tests automatisés, des compilations multiplateformes et la génération de documentation. L'approche intégrée de la plateforme DevSecOps résonne avec la philosophie de Rust qui consiste à fournir des outils complets prêts à l'emploi.\n\n## À propos de l'application de démonstration\n\nNous nous intéressons à l'impact des taux hypothécaires sur les paiements mensuels et à la difficulté d'acheter une maison dans le contexte actuel, c'est pourquoi nous avons décidé d'écrire un [calculateur de prêt hypothécaire](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/rust/mortgage-calculator) en Rust, que nous utiliserons comme exemple tout au long de ce tutoriel. N'hésitez pas à [importer ce projet](https://docs.gitlab.com/user/project/import/repo_by_url/) pour mieux suivre la démonstration.\n\nLe calculateur de prêt hypothécaire aidera les utilisateurs à calculer les paiements mensuels d'un prêt hypothécaire, qui incluent le capital, les intérêts, les taxes foncières, l'assurance, l'assurance du prêt hypothécaire privée et les frais d'association de propriétaires. Il fournit une interface graphique moderne et intuitive au moyen du framework [egui](https://www.egui.rs/), ainsi qu'une interface de ligne de commande pour l'exécuter dans le terminal.\n\n![Interface graphique du calculateur de prêt hypothécaire](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314538/l5bjnzqvpoyikuyxpx2a.png)\n\nCette application contient un fichier [`.gitlab-ci.yml`](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/rust/mortgage-calculator/-/blob/main/.gitlab-ci.yml?ref_type=heads) qui génère un pipeline, lequel va construire, tester, empaqueter, analyser et déployer le logiciel. Nous examinerons cette définition du pipeline en détail dans les sections ci-dessous.\n\n![Pipeline du calculateur de prêt hypothécaire](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314540/llmsfoaupedhkem0hjqp.png)\n\n## Compilation et test des applications Rust\n\nLe système CI/CD basé sur Docker de GitLab excelle dans les workflows de développement Rust, car il fournit une base robuste\npour la compilation, les tests et les vérifications de qualité du code. Les mécanismes de mise en cache de la plateforme\nsont particulièrement précieux pour les projets Rust, qui peuvent avoir des temps de compilation longs en raison des\nprocessus approfondis d'optimisation et de vérification de sécurité du langage.\n\n### Compilation\n\nLes excellentes capacités de compilation croisée de Rust combinées au système CI/CD flexible de GitLab\ncréent une solution puissante pour construire des applications sur plusieurs plateformes. Cette combinaison est particulièrement utile pour les applications Rust qui doivent fonctionner sur divers systèmes d'exploitation et architectures sans impacter les performances ou nécessiter du code spécifique à la plateforme.\n\n**Remarque :** vous pouvez en apprendre davantage sur le fichier `.gitlab-ci.yml` en consultant la [référence dédiée à la syntaxe YAML CI/CD](https://docs.gitlab.com/ci/yaml/).\n\n```yaml\n# Cache configuration to speed up builds by reusing dependencies\ncache:\n  key: $CI_COMMIT_REF_SLUG                               # Use branch name as cache key\n  paths:\n    - .cargo/                                            # Cache Cargo registry and git dependencies\n    - target/                                            # Cache compiled artifacts\n\n# Base template for Rust jobs - shared configuration\n.rust-template:\n  image: rust:$RUST_VERSION-slim                         # Use slim Rust image for faster downloads\n  before_script:\n    # Install system dependencies required for building the Rust application\n    - apt-get update && apt-get install -y pkg-config libssl-dev libgtk-3-dev libxcb-shape0-dev libxcb-xfixes0-dev\n\n# Template for cross-compilation build jobs\n.build-template:\n  extends: .rust-template                                # Inherit from rust-template\n  stage: build                                           # Execute during build stage\n  script:\n    - rustup target add $TARGET                          # Add the target platform for cross-compilation\n    - cargo build --release --target $TARGET             # Build optimized release binary for target platform\n\n# Build for Linux x86_64 (primary target platform)\nbuild-linux:\n  extends: .build-template                               # Use build template configuration\n  variables:\n    TARGET: x86_64-unknown-linux-gnu                     # Linux 64-bit target\n  artifacts:\n    paths:\n      - target/$TARGET/release/mortgage-calculator       # Save the compiled binary\n    expire_in: 1 week                                    # Keep artifacts for 1 week\n  allow_failure: false                                   # This build must succeed\n\n# Build for Windows x86_64 (cross-compilation)\nbuild-windows:\n  extends: .build-template                               # Use build template configuration\n  variables:\n    TARGET: x86_64-pc-windows-gnu                        # Windows 64-bit target\n  artifacts:\n    paths:\n      - target/$TARGET/release/mortgage-calculator       # Save the compiled binary\n    expire_in: 1 week                                    # Keep artifacts for 1 week\n  allow_failure: true                                    # Allow this build to fail (cross-compilation can be tricky)\n\n# Build for macOS x86_64 (cross-compilation)\nbuild-macos:\n  extends: .build-template                               # Use build template configuration\n  variables:\n    TARGET: x86_64-apple-darwin                          # macOS 64-bit target\n  artifacts:\n    paths:\n      - target/$TARGET/release/mortgage-calculator       # Save the compiled binary\n    expire_in: 1 week                                    # Keep artifacts for 1 week\n  allow_failure: true\n```\n\nCette configuration GitLab CI définit trois jobs de compilation qui compilent de manière croisée une application\nde calculateur de prêt hypothécaire Rust pour différentes plateformes :\n\n* `build-linux` crée un binaire Linux x86_64 (requis pour réussir)\n* `build-windows` crée des binaires Windows (autorisés à échouer)\n* `build-macos` crée des binaires macOS x86_64 (autorisés à échouer)\n\nToutes les compilations utilisent des templates partagés pour la mise en cache des dépendances et des environnements de compilation cohérents.\n\n### Tests\n\nGitLab CI/CD simplifie les tests de code grâce à son système de pipeline intégré qui déclenche automatiquement\nles suites de tests chaque fois qu'un push du code est effectué vers le dépôt. Les développeurs peuvent définir plusieurs types de tests (tests unitaires, tests d'intégration, linting et vérifications de formatage) dans un seul fichier de configuration `.gitlab-ci.yml`. Chaque test s'exécute dans des conteneurs Docker isolés pour garantir des environnements cohérents.\n\n```yaml\n  # Run unit tests\ntest:unit:\n  extends: .rust-template                                # Use Rust template configuration\n  stage: test                                            # Execute during test stage\n  script:\n    - cargo test --verbose                               # Run all unit tests with verbose output\n\n# Run integration tests using the compiled binary\ntest:integration:\n  extends: .rust-template                                # Use Rust template configuration\n  stage: test                                            # Execute during test stage\n  script:\n    # Test the compiled binary with sample inputs and verify expected output\n    - target/x86_64-unknown-linux-gnu/release/mortgage-calculator --cli calculate --property-value 350000 --down-payment 70000 --interest-rate 5.0 | grep -q \"TOTAL MONTHLY PAYMENT\"\n  needs:\n    - build-linux                                        # Depends on Linux build job completing\n\n# Run Clippy linter for code quality checks\ntest:clippy:\n  extends: .rust-template                                # Use Rust template configuration\n  stage: test                                            # Execute during test stage\n  script:\n    - rustup component add clippy                        # Install Clippy linter\n    - cargo clippy -- -D warnings                       # Run Clippy and treat warnings as errors\n  allow_failure: true                                    # Allow linting failures (can be improved over time)\n\n# Check code formatting\ntest:format:\n  extends: .rust-template                                # Use Rust template configuration\n  stage: test                                            # Execute during test stage\n  script:\n    - rustup component add rustfmt                       # Install Rust formatter\n    - cargo fmt -- --check                              # Check if code is properly formatted\n  allow_failure: true                                    # Allow formatting failures (can be improved over time)\n```\n\nCette configuration GitLab CI crée quatre jobs de test qui valident l'application de calculateur de prêt hypothécaire Rust :\n\n* `test:unit` exécute les tests unitaires\n* `test:integration` exécute le binaire Linux compilé avec des intrants d'exemple pour vérifier la fonctionnalité\n* `test:clippy` effectue le linting de la qualité du code (autorisé à échouer)\n* `test:format` vérifie la conformité du formatage du code (autorisé à échouer)\n\n## Registres de paquets et de conteneurs\n\nLe [registre de paquets](https://docs.gitlab.com/user/packages/package_registry/) de GitLab fournit une solution sécurisée au partage de bibliothèques internes et de code propriétaire au sein des organisations. Cette fonctionnalité est essentielle pour les entreprises et équipes qui doivent maintenir des artefacts et continuer à utiliser l'écosystème Rust au sens large.\n\nLe registre prend en charge les [artefacts génériques](https://docs.gitlab.com/user/packages/generic_packages/) avec des contrôles d'accès granulaires en fonction des permissions de projet de GitLab. Les équipes peuvent donc partager des bibliothèques en toute sécurité entre les projets ainsi que respecter la protection de la propriété intellectuelle et les exigences de conformité.\n\nDe plus, nous pouvons conteneuriser notre application et stocker les images de conteneur dans\nle [registre des conteneurs](https://docs.gitlab.com/user/packages/container_registry/) intégré de GitLab.\n\n### Publication vers le registre de paquets GitLab\n\nCette section de notre `.gitlab-ci.yml` démontre comment packager et publier des applications Rust\nsous forme d'archives tar vers le registre de paquets génériques de GitLab au moyen de l'automatisation CI/CD.\n\n```yaml\n# Package application as tar archive\npackage:tar:\n  image: alpine/curl:8.12.1                             # Lightweight image with curl for uploading\n  stage: package                                         # Execute during package stage\n  variables:\n    PACKAGE_NAME: mortgage-calculator.tar.gz             # Name of the archive file\n  script:\n    # Create tar archive of the Linux binary\n    - tar -czvf $PACKAGE_NAME target/x86_64-unknown-linux-gnu/release/mortgage-calculator\n    # Upload archive to GitLab Package Registry using API\n    - |\n      curl -v --location --header \"JOB-TOKEN: $CI_JOB_TOKEN\" \\\n      --upload-file $PACKAGE_NAME \\\n      \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/packages/generic/tar/$CI_COMMIT_BRANCH/$PACKAGE_NAME\"\n  artifacts:\n    paths:\n      - target/x86_64-unknown-linux-gnu/release/mortgage-calculator  # Save binary\n      - mortgage-calculator.tar.gz                      # Save archive\n    expire_in: 1 week                                    # Keep artifacts for 1 week\n  needs:\n    - build-linux                                        # Depends on Linux build completing\n```\n\nCette configuration GitLab CI définit un job d'empaquetage `package:tar` qui crée une archive tar compressée\ndu binaire de calculateur de prêt hypothécaire Linux et l'importe vers le registre de paquets de GitLab, et sauvegarde à la fois le binaire et l'archive comme artefacts de pipeline.\n\n![Registre de paquets](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314541/uqnejcipnge3r1dngotm.png)\n\n### Publication vers le registre de conteneurs GitLab\n\nLe bloc de code ci-dessous montre le processus de création de Dockerfiles et de publication d'images Docker vers le registre de conteneurs de GitLab avec un ajout de tags et une authentification appropriés.\n\n```yaml\n# Package application as Docker image\npackage:docker:\n  image: docker:24.0                                     # Use Docker image for building containers\n  stage: package                                         # Execute during package stage\n  services:\n    - docker:24.0-dind                                   # Docker-in-Docker service for building images\n  before_script:\n    # Login to GitLab Container Registry\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n  script:\n    - docker build -t $DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG .  # Build Docker image with commit SHA tag\n    - docker tag $DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG $DOCKER_IMAGE_NAME:latest  # Also tag as latest\n    - docker push $DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG  # Push tagged image to registry\n    - docker push $DOCKER_IMAGE_NAME:latest             # Push latest image to registry\n```\n\nCette configuration GitLab CI définit un job d'empaquetage Docker `package:docker` qui crée une image Docker de l'application de calculateur de prêt hypothécaire, ajoute les tags « commit SHA » et « latest », puis pousse les deux versions avec un tag vers le registre de conteneurs de GitLab.\n\n![Registre de conteneurs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314537/nlodhvdnpqccf0cryfqu.png)\n\n## Scanning de sécurité\n\nLe scanning de sécurité GitLab fournit une protection complète qui va au-delà des garanties de sécurité mémoire intégrées de Rust. Bien que Rust prévienne de nombreuses vulnérabilités de sécurité courantes au moment de la compilation, les applications ont encore besoin de protection contre les vulnérabilités des dépendances, les blocs de code non sécurisés et les problèmes de sécurité logiques.\n\nLes tests statiques de sécurité des applications ([SAST])(https://docs.gitlab.com/user/application_security/sast/) de la plateforme s'intègrent parfaitement avec la chaîne d'outils de Rust et fournissent une analyse de sécurité automatisée dans le pipeline CI/CD. Cette approche proactive détecte les problèmes de sécurité avant qu'ils n'arrivent en production afin de répondre à la fois aux exigences de conformité et aux pratiques de développement sécurisé.\n\nLes fonctionnalités de sécurité complètes de GitLab, y compris les tests SAST, l'analyse des dépendances et la détection des secrets peuvent facilement être implémentées via des modèles, comme illustré ci-dessous.\n\n**Remarque :**  une configuration supplémentaire est requise pour [activer les tests SAST pour Rust](https://docs.gitlab.com/user/application_security/sast/#scan-a-rust-application).\n\n```yaml\n# Include GitLab's security scanning templates for DevSecOps\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml                    # Static Application Security Testing\n  - template: Jobs/Dependency-Scanning.latest.gitlab-ci.yml  # Scan dependencies for vulnerabilities\n  - template: Jobs/Container-Scanning.gitlab-ci.yml      # Scan Docker containers for vulnerabilities\n  - template: Jobs/SAST-IaC.gitlab-ci.yml               # Infrastructure as Code security scanning\n  - template: Jobs/Secret-Detection.gitlab-ci.yml        # Detect secrets in source code\n```\n\nLes scanners de sécurité peuvent être configurés de manière similaire à n'importe quel job sur GitLab :\n\n```yaml\n# Configure Semgrep SAST scanning for Rust files\nsemgrep-sast:\n  rules:\n    - if: $CI_COMMIT_BRANCH                              # Run on any branch\n      exists:\n        - \"**/*.rs\"                                      # Only if Rust files exist\n  variables:\n    SAST_EXCLUDED_PATHS: \".cargo/**\"                     # Exclude Cargo cache from scanning\n\n# Scan Docker container for security vulnerabilities\ncontainer_scanning:\n  stage: container-security                              # Execute during container-security stage\n  variables:\n    CS_IMAGE: $DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG      # Image to scan\n    CS_DOCKERFILE_PATH: Dockerfile                       # Path to Dockerfile for context\n  needs:\n    - package:docker                                     # Depends on Docker image being built\n```\n\nLorsque des vulnérabilités sont détectées dans une merge request (MR), vous pouvez toutes les afficher et utiliser les informations fournies pour les résoudre ou les rejeter.\n\n![Affichage des vulnérabilités dans la MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314544/gcicke3ltvbcv57mr8zr.png)\n\nVous pouvez également ajouter des [stratégies de sécurité](http://docs.gitlab.com/user/application_security/policies/) pour exiger une approbation avant que du code vulnérable puisse être fusionné, ou pour forcer l'exécution des scanners indépendamment de ce qui se trouve dans le `.gitlab-ci.yml`.\n\n![Politique d'approbation des merge requests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314538/c95nwocol03lonrr6r4n.png)\n\nVous pouvez trier toutes les vulnérabilités trouvées dans votre branche par défaut au moyen du [rapport de vulnérabilités](https://docs.gitlab.com/user/application_security/vulnerability_report/) :\n\n![Rapport de vulnérabilités](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314544/b0nctigbv1ddpzizkp9x.png)\n\n## Documentation avec GitLab Pages\n\n[GitLab Pages](https://docs.gitlab.com/user/project/pages/) fournit une excellente plateforme pour héberger la documentation Rust, car il s'intègre parfaitement avec la génération de documentation intégrée de Cargo. Ce workflow puissant génère et déploie la documentation API, les guides de projet et les exemples automatiquement à chaque modification de code.\n\nLa combinaison de `cargo doc` et GitLab Pages permet aux équipes de maintenir une documentation à jour sans intervention manuelle afin que la documentation soit synchronisée avec les modifications de code. Cette fonctionnalité est particulièrement utile pour les projets Rust où une documentation complète est essentielle pour comprendre les API complexes et les contrats de sécurité.\n\n### Déploiement automatisé de la documentation\n\nLe code ci-dessous montre la configuration CI/CD nécessaire pour générer et déployer automatiquement la documentation Rust au moyen de `cargo doc` et GitLab Pages.\n\n```yaml\n# Generate and publish documentation using GitLab Pages\nbuild-documentation:\n  extends: .rust-template                                # Use Rust template configuration\n  stage: build                                           # Execute during build stage\n  variables:\n    GIT_SUBMODULE_STRATEGY: recursive                    # Clone submodules recursively if needed\n  pages: true                                            # Enable GitLab Pages deployment\n  script:\n    - cargo doc --no-deps                                # Generate documentation without dependencies\n    - mv target/doc public                               # Move docs to public directory for Pages\n  artifacts:\n    paths:\n      - public                                           # GitLab Pages serves from public directory\n  rules:\n    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH     # Only run on default branch (main/master)\n  environment:\n    name: documentation                                  # Environment name for tracking\n    url: $CI_PAGES_URL/mortgage_calculator/index.html   # Documentation URL\n  allow_failure: true                                    # Allow documentation build to fail\n```\n\nUne fois le job terminé, vous pouvez consulter la documentation déployée en accédant à l'[environnement GitLab](https://docs.gitlab.com/ci/environments/) où il a été déployé.\n\n![Environnement Pages](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314541/aofa6wwjugeyeshuwg9r.png)\n\nDe cette manière, vous pouvez gérer plusieurs versions de la documentation dans différents environnements. La documentation sera déployée de manière cohérente avec les données de sortie de `cargo doc` :\n\n![Compilation de GitLab Pages](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314541/go0tmljjzoxq5bujsdbv.png)\n\n## Déploiement dans tous les environnements\n\nL'une des plus grandes forces de GitLab est son approche indépendante de l'infrastructure pour le déploiement. Que votre organisation fonctionne sur des serveurs traditionnels sur site, sur des plateformes cloud modernes, sur des environnements hybrides ou sur une infrastructure edge computing, le système CI/CD de GitLab peut déployer des applications Rust de manière harmonieuse dans n'importe quel environnement cible.\n\nLa flexibilité de déploiement de GitLab découle de son approche axée sur les conteneurs et de son écosystème d'intégration étendu. La plateforme prend en charge le déploiement sur presque toutes les infrastructures capables d'exécuter des conteneurs, des machines virtuelles ou des applications sur serveur physique dédié. Cette polyvalence est particulièrement utile pour les applications Rust, qui doivent souvent fonctionner dans des environnements allant des systèmes embarqués avec des ressources limitées aux clusters cloud haute performance.\n\n### Déploiement dans Kubernetes\n\nGitLab simplifie les déploiements dans Kubernetes avec une intégration de cluster intégrée et des images Docker préconfigurées qui incluent des outils essentiels comme Helm et kubectl. Les équipes de développement n'ont alors plus besoin de configurer des environnements de déploiement complexes.\n\n```yaml\n# Deploy application to Kubernetes cluster\ndeploy:kubernetes:\n  stage: deploy                                          # Execute during deploy stage\n  image: registry.gitlab.com/gitlab-org/cluster-integration/helm-install-image:helm-3.10.0-kube-1.24.6-alpine-3.15  # Image with Helm and kubectl\n  variables:\n    HELM_HOST: \"localhost:44134\"                         # Helm host configuration\n    HELM_DEPLOY_NAME: mortgage-calc-$CI_COMMIT_REF_NAME  # Deployment name based on branch\n    HELM_DEPLOY_NAMESPACE: calc-app                      # Kubernetes namespace for deployment\n    KUBE_CONTEXT: $CI_PROJECT_PATH:rust-mortgage-calculator  # Kubernetes context to use\n  script:\n    - kubectl config use-context $KUBE_CONTEXT          # Set the kubectl context\n    # Deploy using Helm with custom values and Docker image\n    - helm upgrade --install $HELM_DEPLOY_NAME chart -f chart/values.yaml\n      --namespace $HELM_DEPLOY_NAMESPACE\n      --create-namespace\n      --set image=$DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG\n      --set calc.name=$HELM_DEPLOY_NAME\n  needs:\n    - package:docker                                     # Depends on Docker image being available\n```\n\nCette configuration GitLab CI définit un job de déploiement `deploy:kubernetes` qui utilise Helm pour déployer l'application de calculateur de prêt hypothécaire sur un cluster Kubernetes, avec la création ou la mise à niveau du déploiement dans un espace de nommage dédié avec l'image Docker construite dans l'étape d'empaquetage précédente.\n\n![Données de sortie Kubernetes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314538/bgmbh4qyfxcnnlqvsitc.png)\n\n## Fonctionnalités d'IA de GitLab Duo\n\nLes fonctionnalités d'IA de [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/) offrent des avantages significatifs pour le développement Rust grâce à des suggestions de code intelligentes et des explications spécifiquement adaptées à la syntaxe et aux modèles uniques du langage. Rust est l'un des [langages directement pris en charge](https://docs.gitlab.com/user/project/repository/code_suggestions/supported_extensions/#supported-languages-by-ide) de la plateforme GitLab pour chaque IDE et garantit une complétion et une génération de code de haute qualité qui comprend le modèle de propriété de Rust, les principes de sécurité mémoire et les modèles idiomatiques.\n\n### Suggestions de code de GitLab Duo\n\nLa capacité de GitLab Duo à fournir des suggestions de code en contexte pendant l'écriture aide les équipes de développement à naviguer plus efficacement dans la syntaxe parfois complexe de Rust, à réduire la courbe d'apprentissage pour les nouveaux venus et à accélérer la productivité des développeurs expérimentés.\n\n![Suggestions de code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314538/uvy6hmzvyd0mnqeic9tq.png)\n\n### GitLab Duo Chat\n\n[GitLab Duo Chat](https://about.gitlab.com/fr-fr/blog/gitlab-duo-chat-gets-agentic-ai-makeover/) complète les suggestions de code : il offre une assistance conversationnelle pour expliquer les sections de code Rust, déboguer les erreurs du compilateur et fournir des conseils sur les meilleures pratiques. Cette aide est particulièrement précieuse dans le développement Rust où les messages d'erreur du compilateur, bien qu'utiles, peuvent parfois surcharger les équipes de développement habituées à d'autres langages.\n\nL'IA peut aider à interpréter les messages d'erreur détaillés de Rust et suggérer des corrections afin d'accélérer le processus de développement en réduisant le temps passé à déchiffrer les problèmes de compilation.\n\n![GitLab Duo Chat](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756314537/depxztu1h89bez3ylwk3.png)\n\nGitLab Duo Chat peut également être utilisé directement depuis le rapport de vulnérabilités pour fournir des explications sur un élément détecté. La fonctionnalité d'[explication des vulnérabilités](https://about.gitlab.com/fr-fr/the-source/ai/understand-and-resolve-vulnerabilities-with-ai-powered-gitlab-duo/) de GitLab Duo représente une avancée significative qui renforce la sécurité des applications pour les équipes de développement. Plutôt que de simplement signaler des problèmes potentiels avec des codes d'erreur peu clairs ou du jargon technique, l'IA décompose la nature de chaque vulnérabilité, son impact potentiel et les étapes de remédiation en termes que les développeurs de tous niveaux peuvent rapidement comprendre.\n\nCette démocratisation des connaissances en sécurité accélère le processus de remédiation, réduit les allers-retours entre les équipes de sécurité et de développement et aide les organisations à livrer du code plus sécurisé plus rapidement :\n\n![Explication de vulnérabilité 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756405091/rrcenbfazhhulmrp99yx.png)\n\n\u003Cp>\u003C/p>\n\n![Explication de vulnérabilité 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756405094/b3o4lkexyn9lp41ib8ye.png)\n\n\u003Cp>\u003C/p>\n\n![Explication de vulnérabilité 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756405095/y56wq8j5tg10t4dgbgfq.png)\n\n\u003Cp>\u003C/p>\n\n![Explication de vulnérabilité 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756405090/mpc1mst4ydijpqdtlljm.png)\n\n\u003Cp>\u003C/p>\n\nAvec GitLab Duo, vous avez également accès à [GitLab Duo Agentic Chat](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/), un assistant de développement intelligent pour les applications Rust, qui offre une aide contextuelle tout au long du cycle de développement. Les équipes de développement peuvent tirer parti de son interface conversationnelle pour générer des extraits de code Rust et générer automatiquement des structures de code pour de nouveaux projets Rust avec des configurations `Cargo.toml` adaptées, entre autres.\n\n### Résolution des vulnérabilités avec GitLab Duo\n\nLa fonctionnalité de [résolution des vulnérabilités](https://docs.gitlab.com/user/application_security/vulnerabilities/#vulnerability-resolution) de GitLab Duo utilise l'IA pour générer automatiquement des corrections de code spécifiques pour les problèmes de sécurité détectés qui réduisent le temps de remédiation de plusieurs heures à quelques minutes. L'IA analyse les coding patterns vulnérables et propose des correctifs précis adaptés au contexte, au langage de programmation et aux dépendances du projet tout en maintenant la fonctionnalité du code et le style.\n\nCette automatisation est particulièrement efficace pour les vulnérabilités courantes comme l'injection SQL et le cross-site scripting, car elle permet aux équipes de développement de maintenir leur vélocité tout en améliorant significativement leur posture de sécurité sans perturber le workflow de développement.\n\n![Exemple de remédiation de GitLab Duo 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756405090/blpwclp68igekkecbyna.png)\n\n\u003Cp>\u003C/p>\n\n![Exemple de remédiation de GitLab Duo 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756405090/avvncsspwyirtk14jdbe.png)\n\n\u003Cp>\u003C/p>\n\n### Revue de code de GitLab Duo\n\nLa [revue de code alimentée par l'IA](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#have-gitlab-duo-review-your-code) de GitLab Duo améliore le processus de développement grâce à des commentaires intelligents et automatisés dans les merge requests avant toute intervention de réviseurs humains. L'IA analyse les modifications de code pour détecter les bogues potentiels, les vulnérabilités de sécurité, les problèmes de performance et l'adhérence aux normes de codage. De plus, elle fournit des suggestions contextuelles et des explications qui aident les équipes à détecter les problèmes tôt.\n\nEn renforçant les revues humaines traditionnelles avec des informations d'IA cohérentes et immédiates, cette fonctionnalité réduit la charge sur les développeurs seniors, accélère le cycle de revue et garantit que les vérifications de qualité de base sont appliquées de manière cohérente à toutes les contributions de code. La qualité du code est ainsi améliorée, et les réviseurs humains peuvent se concentrer sur l'architecture et la logique métier de plus haut niveau.\n\n![Revue de code de GitLab Duo 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756405090/hewxrp2f22mf2fe4daaa.png)\n\n\u003Cp>\u003C/p>\n\n![Revue de code de GitLab Duo 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756405091/qbw1gi0l4ngysnyjwoy8.png)\n\n\u003Cp>\u003C/p>\n\nCe ne sont là que quelques-unes des fonctionnalités IA qui peuvent être utilisées pour vous permettre de livrer des logiciels Rust plus sécurisés plus rapidement que jamais. Pour en savoir plus sur toutes les fonctionnalités d'IA de GitLab, consultez la [page de solution GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/).\n\n## Rust : l'avantage de GitLab\n\nGitLab fournit une plateforme de développement complète en synergie avec l'approche globale de Rust :\n\n**Workflow intégré :**\n- **Plateforme unique :** code, CI/CD, sécurité et déploiement en un seul endroit\n- **Optimisation pour Rust :** compilations basées sur Docker parfaites pour la chaîne d'outils Rust\n- **Sécurité d'abord :** analyse de sécurité intégrée\n- **Niveau entreprise :** infrastructure évolutive pour les grandes équipes\n\n**Avantages de performance :**\n- **Mise en cache efficace :** accélération des temps de compilation plus longs de Rust\n- **Compilations parallèles :** optimisation de l'efficacité de GitLab Runner\n- **Gestion des artefacts :** distribution de binaires rationalisée\n\n**Expérience développeur :**\n- **Outils familiers :** outils Rust standard (Cargo, Clippy, rustfmt)\n- **Retour visuel :** tableaux de bord et rapports complets\n- **Automatisation :** réduction des coûts de déploiement et de test manuels\n- **IA GitLab Duo :** livraison de logiciels plus sécurisés plus rapidement avec l'IA tout au long du cycle du développement logiciel\n\nLes capacités de la plateforme GitLab complètent parfaitement les avantages de Rust pour créer un écosystème où la sécurité, la performance et la productivité des développeurs convergent. Les applications Rust sur GitLab représentent la pointe du développement logiciel et sont alimentées par une plateforme qui comprend et améliore l'expérience de développement Rust.\n\nPour en savoir plus sur les avantages de GitLab, inscrivez-vous pour un [essai gratuit de GitLab Ultimate avec Duo Enterprise](https://about.gitlab.com/fr-fr/free-trial/).\n","yml",{},"/fr-fr/blog/secure-rust-development-with-gitlab",{"config":30},{"noIndex":31,"title":15,"description":32},false,"Découvrez comment GitLab prend en charge le développement en Rust avec fonctionnalités CI/CD, analyses de sécurité, intégrations dédiées et fonctionnalités IA.","fr-fr/blog/secure-rust-development-with-gitlab",[20,35,22],"open-source","mBjrpOkyctQwPn3BBAgmjGo4BN-KugTQVi940xXdmtw",{"data":38},{"logo":39,"freeTrial":44,"sales":49,"login":54,"items":59,"search":368,"minimal":403,"duo":422,"pricingDeployment":432},{"config":40},{"href":41,"dataGaName":42,"dataGaLocation":43},"/fr-fr/","gitlab logo","header",{"text":45,"config":46},"Commencer un essai gratuit",{"href":47,"dataGaName":48,"dataGaLocation":43},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr&glm_content=default-saas-trial/","free trial",{"text":50,"config":51},"Contacter l'équipe commerciale",{"href":52,"dataGaName":53,"dataGaLocation":43},"/fr-fr/sales/","sales",{"text":55,"config":56},"Connexion",{"href":57,"dataGaName":58,"dataGaLocation":43},"https://gitlab.com/users/sign_in/","sign in",[60,87,184,189,289,349],{"text":61,"config":62,"cards":64},"Plateforme",{"dataNavLevelOne":63},"platform",[65,71,79],{"title":61,"description":66,"link":67},"La plateforme d'orchestration intelligente pour le DevSecOps",{"text":68,"config":69},"Découvrir notre plateforme",{"href":70,"dataGaName":63,"dataGaLocation":43},"/fr-fr/platform/",{"title":72,"description":73,"link":74},"GitLab Duo Agent Platform","L'IA agentique pour l'ensemble du cycle de développement logiciel",{"text":75,"config":76},"Découvrir GitLab Duo",{"href":77,"dataGaName":78,"dataGaLocation":43},"/fr-fr/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":80,"description":81,"link":82},"Choisir GitLab","Découvrez les principales raisons pour lesquelles les entreprises choisissent GitLab",{"text":83,"config":84},"En savoir plus",{"href":85,"dataGaName":86,"dataGaLocation":43},"/fr-fr/why-gitlab/","why gitlab",{"text":88,"left":12,"config":89,"link":91,"lists":95,"footer":166},"Produit",{"dataNavLevelOne":90},"solutions",{"text":92,"config":93},"Voir toutes les solutions",{"href":94,"dataGaName":90,"dataGaLocation":43},"/fr-fr/solutions/",[96,121,144],{"title":97,"description":98,"link":99,"items":104},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":100},{"icon":101,"href":102,"dataGaName":103,"dataGaLocation":43},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[105,109,112,117],{"text":106,"config":107},"CI/CD",{"href":108,"dataGaLocation":43,"dataGaName":106},"/fr-fr/solutions/continuous-integration/",{"text":72,"config":110},{"href":77,"dataGaLocation":43,"dataGaName":111},"gitlab duo agent platform - product menu",{"text":113,"config":114},"Gestion du code source",{"href":115,"dataGaLocation":43,"dataGaName":116},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":118,"config":119},"Livraison de logiciels automatisée",{"href":102,"dataGaLocation":43,"dataGaName":120},"Automated software delivery",{"title":122,"description":123,"link":124,"items":129},"Sécurité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":125},{"href":126,"dataGaName":127,"dataGaLocation":43,"icon":128},"/fr-fr/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[130,134,139],{"text":131,"config":132},"Tests de sécurité des applications",{"href":126,"dataGaName":133,"dataGaLocation":43},"Application security testing",{"text":135,"config":136},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":137,"dataGaLocation":43,"dataGaName":138},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":140,"config":141},"Conformité logicielle",{"href":142,"dataGaName":143,"dataGaLocation":43},"/fr-fr/solutions/software-compliance/","Software Compliance",{"title":145,"link":146,"items":151},"Mesures",{"config":147},{"icon":148,"href":149,"dataGaName":150,"dataGaLocation":43},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[152,156,161],{"text":153,"config":154},"Visibilité et mesures",{"href":149,"dataGaLocation":43,"dataGaName":155},"Visibility and Measurement",{"text":157,"config":158},"Gestion de la chaîne de valeur",{"href":159,"dataGaLocation":43,"dataGaName":160},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":162,"config":163},"Données d'analyse et informations clés",{"href":164,"dataGaLocation":43,"dataGaName":165},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":167,"items":168},"GitLab pour",[169,174,179],{"text":170,"config":171},"Entreprises",{"href":172,"dataGaLocation":43,"dataGaName":173},"/fr-fr/enterprise/","enterprise",{"text":175,"config":176},"PME",{"href":177,"dataGaLocation":43,"dataGaName":178},"/fr-fr/small-business/","small business",{"text":180,"config":181},"Secteur public",{"href":182,"dataGaLocation":43,"dataGaName":183},"/fr-fr/solutions/public-sector/","public sector",{"text":185,"config":186},"Tarifs",{"href":187,"dataGaName":188,"dataGaLocation":43,"dataNavLevelOne":188},"/fr-fr/pricing/","pricing",{"text":190,"config":191,"link":193,"lists":197,"feature":276},"Ressources",{"dataNavLevelOne":192},"resources",{"text":194,"config":195},"Afficher toutes les ressources",{"href":196,"dataGaName":192,"dataGaLocation":43},"/fr-fr/resources/",[198,231,249],{"title":199,"items":200},"Premiers pas",[201,206,211,216,221,226],{"text":202,"config":203},"Installation",{"href":204,"dataGaName":205,"dataGaLocation":43},"/fr-fr/install/","install",{"text":207,"config":208},"Guides de démarrage",{"href":209,"dataGaName":210,"dataGaLocation":43},"/fr-fr/get-started/","quick setup checklists",{"text":212,"config":213},"Apprentissage",{"href":214,"dataGaLocation":43,"dataGaName":215},"https://university.gitlab.com/","learn",{"text":217,"config":218},"Documentation sur le produit",{"href":219,"dataGaName":220,"dataGaLocation":43},"https://docs.gitlab.com/","product documentation",{"text":222,"config":223},"Vidéos sur les bonnes pratiques",{"href":224,"dataGaName":225,"dataGaLocation":43},"/fr-fr/getting-started-videos/","best practice videos",{"text":227,"config":228},"Intégrations",{"href":229,"dataGaName":230,"dataGaLocation":43},"/fr-fr/integrations/","integrations",{"title":232,"items":233},"Découvrir",[234,239,244],{"text":235,"config":236},"Témoignages clients",{"href":237,"dataGaName":238,"dataGaLocation":43},"/fr-fr/customers/","customer success stories",{"text":240,"config":241},"Blog",{"href":242,"dataGaName":243,"dataGaLocation":43},"/fr-fr/blog/","blog",{"text":245,"config":246},"Travail à distance",{"href":247,"dataGaName":248,"dataGaLocation":43},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":250,"items":251},"Connecter",[252,257,261,266,271],{"text":253,"config":254},"Services GitLab",{"href":255,"dataGaName":256,"dataGaLocation":43},"/fr-fr/services/","services",{"text":258,"config":259},"Communauté",{"href":260,"dataGaName":20,"dataGaLocation":43},"/community/",{"text":262,"config":263},"Forum",{"href":264,"dataGaName":265,"dataGaLocation":43},"https://forum.gitlab.com/","forum",{"text":267,"config":268},"Événements",{"href":269,"dataGaName":270,"dataGaLocation":43},"/events/","events",{"text":272,"config":273},"Partenaires",{"href":274,"dataGaName":275,"dataGaLocation":43},"/fr-fr/partners/","partners",{"backgroundColor":277,"textColor":278,"text":279,"image":280,"link":284},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":281,"config":282},"carte promo The Source",{"src":283},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":285,"config":286},"Lire les articles les plus récents",{"href":287,"dataGaName":288,"dataGaLocation":43},"/fr-fr/the-source/","the source",{"text":290,"config":291,"lists":293},"Société",{"dataNavLevelOne":292},"company",[294],{"items":295},[296,301,307,309,314,319,324,329,334,339,344],{"text":297,"config":298},"À propos",{"href":299,"dataGaName":300,"dataGaLocation":43},"/fr-fr/company/","about",{"text":302,"config":303,"footerGa":306},"Carrières",{"href":304,"dataGaName":305,"dataGaLocation":43},"/jobs/","jobs",{"dataGaName":305},{"text":267,"config":308},{"href":269,"dataGaName":270,"dataGaLocation":43},{"text":310,"config":311},"Leadership",{"href":312,"dataGaName":313,"dataGaLocation":43},"/company/team/e-group/","leadership",{"text":315,"config":316},"Équipe",{"href":317,"dataGaName":318,"dataGaLocation":43},"/company/team/","team",{"text":320,"config":321},"Manuel",{"href":322,"dataGaName":323,"dataGaLocation":43},"https://handbook.gitlab.com/","handbook",{"text":325,"config":326},"Relations avec les investisseurs",{"href":327,"dataGaName":328,"dataGaLocation":43},"https://ir.gitlab.com/","investor relations",{"text":330,"config":331},"Centre de confiance",{"href":332,"dataGaName":333,"dataGaLocation":43},"/fr-fr/security/","trust center",{"text":335,"config":336},"Centre pour la transparence de l'IA",{"href":337,"dataGaName":338,"dataGaLocation":43},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":340,"config":341},"Newsletter",{"href":342,"dataGaName":343,"dataGaLocation":43},"/company/contact/#contact-forms","newsletter",{"text":345,"config":346},"Presse",{"href":347,"dataGaName":348,"dataGaLocation":43},"/press/","press",{"text":350,"config":351,"lists":352},"Nous contacter",{"dataNavLevelOne":292},[353],{"items":354},[355,358,363],{"text":50,"config":356},{"href":52,"dataGaName":357,"dataGaLocation":43},"talk to sales",{"text":359,"config":360},"Portail d’assistance",{"href":361,"dataGaName":362,"dataGaLocation":43},"https://support.gitlab.com","support portal",{"text":364,"config":365},"Portail clients GitLab",{"href":366,"dataGaName":367,"dataGaLocation":43},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":369,"login":370,"suggestions":377},"Fermer",{"text":371,"link":372},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":373,"config":374},"gitlab.com",{"href":57,"dataGaName":375,"dataGaLocation":376},"search login","search",{"text":378,"default":379},"Suggestions",[380,382,387,389,394,399],{"text":72,"config":381},{"href":77,"dataGaName":72,"dataGaLocation":376},{"text":383,"config":384},"Suggestions de code (IA)",{"href":385,"dataGaName":386,"dataGaLocation":376},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":106,"config":388},{"href":108,"dataGaName":106,"dataGaLocation":376},{"text":390,"config":391},"GitLab sur AWS",{"href":392,"dataGaName":393,"dataGaLocation":376},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":395,"config":396},"GitLab sur Google Cloud ",{"href":397,"dataGaName":398,"dataGaLocation":376},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":400,"config":401},"Pourquoi utiliser GitLab ?",{"href":85,"dataGaName":402,"dataGaLocation":376},"Why GitLab?",{"freeTrial":404,"mobileIcon":409,"desktopIcon":414,"secondaryButton":417},{"text":405,"config":406},"Commencer votre essai gratuit",{"href":407,"dataGaName":48,"dataGaLocation":408},"https://gitlab.com/-/trials/new/","nav",{"altText":410,"config":411},"Icône GitLab",{"src":412,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":410,"config":415},{"src":416,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":418,"config":419},"Commencer",{"href":420,"dataGaName":421,"dataGaLocation":408},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr/compare/gitlab-vs-github/","get started",{"freeTrial":423,"mobileIcon":428,"desktopIcon":430},{"text":424,"config":425},"En savoir plus sur GitLab Duo",{"href":426,"dataGaName":427,"dataGaLocation":408},"/fr-fr/gitlab-duo/","gitlab duo",{"altText":410,"config":429},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":431},{"src":416,"dataGaName":413,"dataGaLocation":408},{"freeTrial":433,"mobileIcon":438,"desktopIcon":440},{"text":434,"config":435},"Retour aux tarifs",{"href":187,"dataGaName":436,"dataGaLocation":408,"icon":437},"back to pricing","GoBack",{"altText":410,"config":439},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":441},{"src":416,"dataGaName":413,"dataGaLocation":408},{"title":443,"button":444,"config":449},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":445,"config":446},"Regarder GitLab Transcend maintenant",{"href":447,"dataGaName":448,"dataGaLocation":43},"/fr-fr/events/transcend/virtual/","transcend event",{"layout":450,"icon":451},"release","AiStar",{"data":453},{"text":454,"source":455,"edit":461,"contribute":466,"config":471,"items":476,"minimal":653},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":456,"config":457},"Afficher le code source de la page",{"href":458,"dataGaName":459,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":462,"config":463},"Modifier cette page",{"href":464,"dataGaName":465,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":467,"config":468},"Veuillez contribuer",{"href":469,"dataGaName":470,"dataGaLocation":460},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":472,"facebook":473,"youtube":474,"linkedin":475},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[477,500,554,586,621],{"title":61,"links":478,"subMenu":483},[479],{"text":480,"config":481},"Plateforme DevSecOps",{"href":70,"dataGaName":482,"dataGaLocation":460},"devsecops platform",[484],{"title":185,"links":485},[486,490,495],{"text":487,"config":488},"Voir les forfaits",{"href":187,"dataGaName":489,"dataGaLocation":460},"view plans",{"text":491,"config":492},"Pourquoi choisir GitLab Premium ?",{"href":493,"dataGaName":494,"dataGaLocation":460},"/fr-fr/pricing/premium/","why premium",{"text":496,"config":497},"Pourquoi choisir GitLab Ultimate ?",{"href":498,"dataGaName":499,"dataGaLocation":460},"/fr-fr/pricing/ultimate/","why ultimate",{"title":501,"links":502},"Solutions",[503,508,511,513,518,523,527,530,533,538,540,542,544,549],{"text":504,"config":505},"Transformation digitale",{"href":506,"dataGaName":507,"dataGaLocation":460},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":509,"config":510},"Sécurité et conformité",{"href":126,"dataGaName":133,"dataGaLocation":460},{"text":118,"config":512},{"href":102,"dataGaName":103,"dataGaLocation":460},{"text":514,"config":515},"Développement agile",{"href":516,"dataGaName":517,"dataGaLocation":460},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":519,"config":520},"Transformation cloud",{"href":521,"dataGaName":522,"dataGaLocation":460},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":524,"config":525},"SCM",{"href":115,"dataGaName":526,"dataGaLocation":460},"source code management",{"text":106,"config":528},{"href":108,"dataGaName":529,"dataGaLocation":460},"continuous integration & delivery",{"text":157,"config":531},{"href":159,"dataGaName":532,"dataGaLocation":460},"value stream management",{"text":534,"config":535},"GitOps",{"href":536,"dataGaName":537,"dataGaLocation":460},"/fr-fr/solutions/gitops/","gitops",{"text":170,"config":539},{"href":172,"dataGaName":173,"dataGaLocation":460},{"text":175,"config":541},{"href":177,"dataGaName":178,"dataGaLocation":460},{"text":180,"config":543},{"href":182,"dataGaName":183,"dataGaLocation":460},{"text":545,"config":546},"Formation",{"href":547,"dataGaName":548,"dataGaLocation":460},"/fr-fr/solutions/education/","education",{"text":550,"config":551},"Services financiers",{"href":552,"dataGaName":553,"dataGaLocation":460},"/fr-fr/solutions/finance/","financial services",{"title":190,"links":555},[556,558,561,563,566,568,571,574,576,578,580,582,584],{"text":202,"config":557},{"href":204,"dataGaName":205,"dataGaLocation":460},{"text":559,"config":560},"Guides de démarrage rapide",{"href":209,"dataGaName":210,"dataGaLocation":460},{"text":212,"config":562},{"href":214,"dataGaName":215,"dataGaLocation":460},{"text":217,"config":564},{"href":219,"dataGaName":565,"dataGaLocation":460},"docs",{"text":240,"config":567},{"href":242,"dataGaName":243},{"text":569,"config":570},"Histoires de réussite client",{"href":237,"dataGaLocation":460},{"text":572,"config":573},"Histoires de succès client",{"href":237,"dataGaName":238,"dataGaLocation":460},{"text":245,"config":575},{"href":247,"dataGaName":248,"dataGaLocation":460},{"text":253,"config":577},{"href":255,"dataGaName":256,"dataGaLocation":460},{"text":258,"config":579},{"href":260,"dataGaName":20,"dataGaLocation":460},{"text":262,"config":581},{"href":264,"dataGaName":265,"dataGaLocation":460},{"text":267,"config":583},{"href":269,"dataGaName":270,"dataGaLocation":460},{"text":272,"config":585},{"href":274,"dataGaName":275,"dataGaLocation":460},{"title":290,"links":587},[588,590,593,595,597,599,601,605,610,612,614,616],{"text":297,"config":589},{"href":299,"dataGaName":292,"dataGaLocation":460},{"text":591,"config":592},"Emplois",{"href":304,"dataGaName":305,"dataGaLocation":460},{"text":310,"config":594},{"href":312,"dataGaName":313,"dataGaLocation":460},{"text":315,"config":596},{"href":317,"dataGaName":318,"dataGaLocation":460},{"text":320,"config":598},{"href":322,"dataGaName":323,"dataGaLocation":460},{"text":325,"config":600},{"href":327,"dataGaName":328,"dataGaLocation":460},{"text":602,"config":603},"Sustainability",{"href":604,"dataGaName":602,"dataGaLocation":460},"/sustainability/",{"text":606,"config":607},"Diversité, inclusion et appartenance (DIB)",{"href":608,"dataGaName":609,"dataGaLocation":460},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":330,"config":611},{"href":332,"dataGaName":333,"dataGaLocation":460},{"text":340,"config":613},{"href":342,"dataGaName":343,"dataGaLocation":460},{"text":345,"config":615},{"href":347,"dataGaName":348,"dataGaLocation":460},{"text":617,"config":618},"Déclaration de transparence sur l'esclavage moderne",{"href":619,"dataGaName":620,"dataGaLocation":460},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":350,"links":622},[623,626,631,633,638,643,648],{"text":624,"config":625},"Échanger avec un expert",{"href":52,"dataGaName":53,"dataGaLocation":460},{"text":627,"config":628},"Aide",{"href":629,"dataGaName":630,"dataGaLocation":460},"/support/","get help",{"text":364,"config":632},{"href":366,"dataGaName":367,"dataGaLocation":460},{"text":634,"config":635},"Statut",{"href":636,"dataGaName":637,"dataGaLocation":460},"https://status.gitlab.com/","status",{"text":639,"config":640},"Conditions d'utilisation",{"href":641,"dataGaName":642},"/terms/","terms of use",{"text":644,"config":645},"Déclaration de confidentialité",{"href":646,"dataGaName":647,"dataGaLocation":460},"/fr-fr/privacy/","privacy statement",{"text":649,"config":650},"Préférences en matière de cookies",{"dataGaName":651,"dataGaLocation":460,"id":652,"isOneTrustButton":12},"cookie preferences","ot-sdk-btn",{"items":654},[655,657,660],{"text":639,"config":656},{"href":641,"dataGaName":642,"dataGaLocation":460},{"text":658,"config":659},"Politique de confidentialité",{"href":646,"dataGaName":647,"dataGaLocation":460},{"text":649,"config":661},{"dataGaName":651,"dataGaLocation":460,"id":652,"isOneTrustButton":12},[663],{"id":664,"title":18,"body":8,"config":665,"content":667,"description":8,"extension":26,"meta":671,"navigation":12,"path":672,"seo":673,"stem":674,"__hash__":675},"blogAuthors/en-us/blog/authors/fernando-diaz.yml",{"template":666},"BlogAuthor",{"name":18,"config":668},{"headshot":669,"ctfId":670},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659556/Blog/Author%20Headshots/fern_diaz.png","fjdiaz",{},"/en-us/blog/authors/fernando-diaz",{},"en-us/blog/authors/fernando-diaz","lxRJIOydP4_yzYZvsPcuQevP9AYAKREF7i8QmmdnOWc",[677,691,706],{"content":678,"config":689},{"tags":679,"category":9,"date":682,"heroImage":683,"authors":684,"body":686,"description":687,"title":688},[680,681],"product","inside GitLab","2025-12-16","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1764108112/tyntnsy3xotlmehtnfkb.png",[685],"John Skarbek","Chaque jour, GitLab déploie des modifications de code sur GitLab.com, la plus grande instance GitLab au monde, et ce jusqu'à 12 fois sans aucun temps d'arrêt. Nous utilisons la plateforme [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"CI/CD\") de GitLab elle-même afin de gérer ces déploiements qui impactent des millions d'équipes de développement à travers le monde. Cette fréquence de déploiement constitue notre principal critère de qualité et notre test de charge. Résultat : nos clients profitent des nouvelles fonctionnalités quelques heures seulement après leur développement au lieu d'attendre des semaines ou des mois. Lorsque des organisations s'appuient sur GitLab pour leurs workflows [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"DevOps\"), elles utilisent une plateforme évolutive et éprouvée.    \n\nDans cet article, vous découvrirez comment nous avons construit un pipeline de déploiement automatisé en utilisant les fonctionnalités principales de GitLab CI/CD afin de gérer cette complexité de déploiement.\n\n## L'impératif métier de la vélocité de déploiement\n\nPour GitLab, la fréquence de déploiement ne représente pas simplement un indicateur technique, il s'agit au contraire d'un impératif métier. Des cycles de déploiement rapides nous permettent de répondre aux retours clients en quelques heures, de déployer immédiatement des correctifs de sécurité et de valider les nouvelles fonctionnalités en production avant de les déployer à grande échelle.\n\nPour nos clients, chaque déploiement vers GitLab.com valide les pratiques de déploiement que nous recommandons à nos utilisateurs. Lorsque vous utilisez les fonctionnalités de déploiement de GitLab, vous utilisez la même approche éprouvée qui gère quotidiennement des millions d'opérations [git](https://about.gitlab.com/fr-fr/blog/2024/10/08/what-is-git/ \"Git\"), de [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Pipeline CI/CD\") et d'interactions utilisateurs. Vous bénéficiez ainsi des avantages suivants :\n\n- Disponibilité immédiate des dernières fonctionnalités : les nouvelles fonctionnalités vous parviennent quelques heures après leur finalisation, et non dans des cycles trimestriels.\n- Fiabilité éprouvée à grande échelle : si une fonctionnalité fonctionne sur GitLab.com, il en ira de même pour votre environnement.\n- Valeur complète de GitLab : les déploiements sans interruption garantissent un accès constant à votre [plateforme DevOps](https://about.gitlab.com/fr-fr/solutions/devops-platform/ \"Plateforme DevOps\"), même pendant les mises à jour.\n- Pratiques testées en conditions réelles : notre documentation de déploiement ne relève pas de la théorie et reflète exactement la manière dont nous exploitons la plus grande instance GitLab existante.\n\n\n## Architecture du flux de code\n\n\nNotre pipeline de déploiement suit une progression structurée à travers plusieurs étapes, chacune agissant comme un point de contrôle sur le parcours allant de la proposition de code au déploiement en production.\n```mermaid\n  graph TD\n      A[Code proposé] --> B[Merge request créée]\n      B --> C[Pipeline déclenché]\n      C --> D[Build et test]\n      D --> E{Spécifications/intégration/tests QA réussis ?}\n      E -->|Non| F[Boucle de rétroaction]\n      F --> B\n      E -->|Oui| G[Merge vers la branche par défaut]\n      G -->|Périodiquement| H[Branche déployée automatiquement]\n\n      subgraph \"Pipeline de déploiement\"\n          H --> I[Création de paquet]\n          I --> K[Environnement canari]\n          K --> L[Validation QA]\n          L --> M[Environnement principal]\n\n      end\n```\n\n## Composition du pipeline de déploiement\n\nNotre approche de déploiement utilise les capacités CI/CD natives de GitLab afin d'orchestrer des déploiements complexes sur une infrastructure hybride.\nVoici comment nous procédons.\n\n\n### Build\n\n\nLe build de GitLab constitue en soi un sujet complexe, c'est pourquoi nous en aborderons les détails à un niveau général.\n\nNous construisons à la fois notre paquet Omnibus et nos images Cloud Native GitLab (CNG). Les paquets Omnibus se déploient sur notre flotte Gitaly (notre couche de stockage Git), tandis que les images CNG exécutent tous les autres composants sous forme de charges de travail conteneurisées. D'autres services dynamiques comme Postgres et Redis ont pris une telle ampleur que nous disposons d'équipes dédiées qui les gèrent séparément. Pour GitLab.com, ces systèmes ne sont pas déployés lors de nos procédures de déploiement automatique.\n\n\nNous disposons d'un pipeline planifié qui examine régulièrement `gitlab-org/gitlab` et recherche le commit le plus récent sur la branche par défaut avec un pipeline réussi (« vert »). Les pipelines verts signalent que chaque composant de GitLab a réussi sa suite de tests complète. Nous créons ensuite une **branche déployée automatiquement** à partir de ce commit.\n\n\nUne séquence d'événements est déclenchée : nous devons construire ce paquet et tous les composants qui font partie de notre monolithe. Un autre pipeline planifié sélectionne le dernier paquet construit et initie le pipeline de déploiement, ce qui ressemble à ceci :\n\n```mermaid\n  graph LR\n      A[Créer une branche] --> B[Build]\n      B --> C[Choisir le paquet construit]\n      C --> D[Démarrer le pipeline de déploiement]\n```\n\nLe build prend un certain temps et, étant donné que les déploiements peuvent varier en raison de diverses circonstances, nous choisissons le dernier build à déployer. Techniquement, nous construisons plus de versions de GitLab pour GitLab.com que nous n'en déploierons jamais. Cela nous permet de toujours disposer d'un paquet prêt à être utilisé, ce qui nous rapproche le plus possible d'un produit entièrement livré en continu pour GitLab.com.\n\n\n### Validation basée sur l'environnement et stratégie canari\n\nL'assurance qualité (QA) ne constitue pas ici une simple réflexion après coup : elle est intégrée à chaque couche, du développement au déploiement. Notre processus QA exploite des suites de tests automatisées qui incluent des tests unitaires, des tests d'intégration et des tests de bout en bout qui simulent les interactions réelles des utilisateurs avec les fonctionnalités de GitLab. Mais plus important encore pour notre pipeline de déploiement, notre processus QA fonctionne en synergie avec notre stratégie canari via une validation basée sur l'environnement .\n\n\nDans le cadre de notre approche de validation, nous exploitons les [déploiements canari](https://docs.gitlab.com/user/project/canary_deployments/) natifs de GitLab. Ces derniers permettent une validation contrôlée des modifications avec une exposition limitée au trafic avant le déploiement complet en production. Environ 5 % de l'ensemble du trafic passe par [l'étape canari](https://handbook.gitlab.com/handbook/engineering/infrastructure/environments/canary-stage/#environments-canary-stage). Cette approche augmente la complexité des migrations de base de données, mais des étapes canari réussies garantissent le déploiement d'un produit fiable de manière transparente.\n\nLes fonctionnalités de déploiement canari que vous utilisez dans GitLab ont été affinées grâce à la gestion de l'un des scénarios de déploiement les plus complexes en production. Lorsque vous implémentez des déploiements canari pour vos applications, vous utilisez des modèles éprouvés à très grande échelle.\nNotre processus de déploiement suit une stratégie de déploiement progressif :\n1. **Préproduction canari :** environnement de validation initial\n2. **Production canari :** trafic de production limité\n3. **Préproduction environnement principal :** déploiement complet de l'environnement de préproduction\n4. **Production environnement principal :** déploiement complet en production\n```mermaid\n  graph TD\n      C[Déploiement préproduction canari]\n      C --> D[QA – smoke tests étape environnement principal]\n      C --> E[QA – smoke tests étape canari]\n      D --> F\n      E --> F{Tests réussis ?}\n      F -->|Oui| G[Déploiement production canari]\n      G --> S[QA – smoke tests étape environnement principal]\n      G --> T[QA – smoke tests étape canari]\n      F -->|Non| H[Création de ticket]\n      H --> K[Correction et rétroportage]\n      K --> C\n\n      S --> M[Surveillance trafic canari]\n      T --> M[Période de stabilisation surveillance trafic canari]\n      M --> U[Vérifications de sécurité production]\n      U --> N[Préproduction environnement principal]\n      N --> V[Production environnement principal]\n```\nNotre validation QA intervient à plusieurs points de contrôle tout au long de ce processus de déploiement progressif : après chaque déploiement canari, puis de nouveau après les migrations post-déploiement. Cette approche multi-couches garantit que chaque phase de notre stratégie de déploiement dispose de son propre filet de sécurité. Vous pouvez en apprendre davantage sur [l'approche de test complète de GitLab](https://handbook.gitlab.com/handbook/engineering/testing/) dans notre handbook.\n\n## Pipeline de déploiement\n\nVoici les défis que nous relevons avec notre pipeline de déploiement.\n\n### Considérations relatives à l'architecture technique\n\nGitLab.com représente une complexité de déploiement réelle à grande échelle. En tant que plus grande instance GitLab connue, les déploiements utilisent notre chart Helm GitLab officiel et le paquet Linux officiel, soit les mêmes artefacts que nos clients utilisent. Vous pouvez en apprendre davantage sur [l'architecture de GitLab.com](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#gitlab-com-architecture) dans notre manuel. Cette approche hybride signifie que notre pipeline de déploiement doit gérer intelligemment à la fois les services conteneurisés et les services Linux traditionnels au sein du même cycle de déploiement.\n\n**Utilisation de nos fonctionnalités à grande échelle (dogfooding) :** nous déployons en utilisant les mêmes procédures que nous documentons pour les [mises à niveau sans temps d’arrêt](https://docs.gitlab.com/update/zero_downtime/). Si certaines fonctionnalités ne fonctionnent pas correctement pour nous, nous ne les recommandons pas à nos clients. Cette contrainte que nous nous imposons stimule l'amélioration continue de nos outils de déploiement.\n\nLes étapes suivantes sont exécutées pour toutes les mises à niveau d'environnement et d'étape :\n```mermaid\n  graph LR\n      a[Préparation] --> c[Migrations régulières – étape canari uniquement]\n      a --> f[Actifs – étape canari uniquement]\n      c --> d[Gitaly]\n      d --> k8s\n\n      subgraph subGraph0[\"Charges de travail MV\"]\n        d[\"Gitaly\"]\n      end\n\n      subgraph subGraph1[\"Charges de travail Kubernetes\"]\n        k8s[\"k8s\"]\n      end\n\n      subgraph fleet[\"Flotte\"]\n        subGraph0\n        subGraph1\n      end\n```\n\n**Détails des étapes :**\n\n\n- **Préparation :** cette étape valide la préparation du déploiement et effectue des vérifications de pré-déploiement.\n\n- **Migrations :** cette étape exécute les migrations régulières de base de données, uniquement pendant l'étape canari. Étant donné que les étapes canari et environnement principal partagent la même base de données, ces modifications sont déjà disponibles lorsque l'étape environnement principal se déploie, ce qui signifie qu'il n'est plus nécessaire de répéter ces tâches.\n\n- **Actifs :** nous exploitons un bucket GCS pour tous les actifs statiques. Si de nouveaux actifs sont créés, nous les importons vers notre bucket de sorte qu'ils soient immédiatement disponibles pour notre étape canari. Comme nous exploitons WebPack pour les actifs et utilisons correctement les SHA dans le nommage de nos actifs, nous pouvons être sûrs que nous n'écrasons pas un actif plus ancien. Par conséquent, les anciens actifs restent disponibles pour les déploiements plus anciens et les nouveaux actifs sont immédiatement disponibles lorsque l'étape canari commence son déploiement. Cela se produit uniquement pendant le déploiement de l'étape canari. Étant donné que l'étape canari et l'étape environnement principal partagent le même stockage d'actifs, ces modifications sont déjà disponibles lorsque l'étape environnement principal se déploie.\n\n- **Gitaly :** cette étape met à jour la couche de stockage de la machine virtuelle Gitaly via notre paquet Linux Omnibus sur chaque nœud Gitaly. Ce service est unique car nous [le regroupons avec `git`](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/git-execution-environments.md). Par conséquent, nous devons garantir que ce service soit capable de procéder à des mises à niveau atomiques. Nous exploitons un [encapsuleur autour de Gitaly](https://gitlab.com/gitlab-org/gitaly/-/tree/master/cmd/gitaly-wrapper), qui nous permet d'installer une version plus récente de Gitaly et d'utiliser la bibliothèque [`tableflip`](https://github.com/cloudflare/tableflip) afin de faire pivoter proprement le Gitaly en cours d'exécution, et de garantir la haute disponibilité de ce service sur chacune de nos instances.\n\n- **[Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Kubernetes\") :** déploie les composants GitLab conteneurisés via notre chart Helm. Notez que nous déployons sur de nombreux clusters répartis sur plusieurs zones pour des questions de redondance, ces étapes sont donc généralement divisées en leurs propres étapes afin de minimiser les dommages et de nous permettent d'arrêter un déploiement en cours si des problèmes critiques sont détectés.\n\n\n### Compatibilité multi-versions : le défi caché\n\n\nÀ la lecture de nos processus, vous remarquerez qu'il existe une période pendant laquelle notre schéma de base de données est en avance sur le code que l'étape environnement principal connaît. Cette situation se produit parce que l'étape canari a déjà déployé le nouveau code et exécute des migrations régulières de base de données, mais l'étape environnement principal exécute toujours la version précédente du code qui ne connaît pas encore ces nouvelles modifications de base de données.\n\n**Exemple concret :** imaginons que nous ajoutons un nouveau champ `merge_readiness` aux merge requests. Pendant le déploiement, certains serveurs exécutent du code qui s'attend à ce champ, tandis que d'autres ignorent son existence. Si nous gérons mal cette situation, GitLab.com sera inutilisable pour des millions d'utilisateurs. Si nous la gérons bien, personne ne remarquera quoi que ce soit.\n\nCette situation se produit également avec la plupart des autres services. Par exemple, si un client envoie plusieurs requêtes, il est possible que l'une d'entre elles aboutisse dans notre étape canari ; d'autres requêtes pourraient être dirigées vers l'étape environnement principal. Ce n'est pas très différent d'un déploiement, car il faut un temps considérable pour parcourir les quelques milliers de pods qui exécutent nos services.\n\n\nÀ quelques exceptions près, la grande majorité de nos services exécutera une version légèrement plus récente de ce composant dans l'étape canari pendant une certaine période. Dans un sens, ces scénarios sont tous des états transitoires. Mais ils peuvent souvent persister pendant plusieurs heures ou jours dans un environnement de production actif. Par conséquent, nous devons les traiter avec le même soin que les états permanents. Pendant tout déploiement, plusieurs versions de GitLab s'exécutent simultanément, et elles doivent toutes cohabiter harmonieusement.\n\n## Opérations de base de données\n\nLes migrations de base de données présentent un défi unique dans notre modèle de déploiement canari. Nous avons besoin de modifier le schéma afin de prendre en charge les nouvelles fonctionnalités et de maintenir notre capacité à effectuer un retour à la version précédente si des problèmes surviennent. Notre solution implique une séparation minutieuse des préoccupations :\n\n- **Migrations régulières :** exécutées pendant l'étape canari, conçues pour être rétrocompatibles, constituées uniquement de modifications réversibles.\n\n- **Migrations post-déploiement :** les migrations « point de non-retour » qui se produisent uniquement après plusieurs déploiements réussis.\n\n\nLes modifications de base de données sont gérées avec précision et selon des procédures de validation approfondies :\n\n```mermaid\n  graph LR\n      A[Migrations régulières] --> B[Déploiement étape canari]\n      B --> C[Déploiement étape environnement principal]\n      C --> D[Migrations post-déploiement]\n\n```\n### Migrations post-déploiement\n\n\nLes déploiements GitLab impliquent de nombreux composants. La mise à jour de GitLab n'est pas atomique, c'est pourquoi de nombreux composants doivent être rétrocompatibles.\n\n\nLes migrations post-déploiement contiennent souvent des modifications qui ne peuvent pas être facilement annulées, comme les transformations de données, les suppressions de colonnes ou les modifications structurelles qui entraîneraient une rupture dans les versions de code plus anciennes. En les exécutant _après_ plusieurs déploiements réussis, nous garantissons les aspects suivants :\n\n\n1. **Le nouveau code est stable** et il est peu probable que nous ayons besoin de devoir retourner à la version précédente.\n\n2. **Les caractéristiques de performance** sont bien comprises en production.\n\n3. **Tous les cas marginaux** ont été découverts et traités.\n\n4. **Le rayon d'impact** est minimisé en cas de problème.\n\n\nCette approche offre un équilibre optimal entre un déploiement rapide des fonctionnalités via les releases canari et des capacités de retour à la version précédente jusqu'à ce que nous ayons suffisamment confiance dans la stabilité du déploiement.\n\n\n**Modèle étendre-migrer-réduire :** nos modifications de compatibilité de base de données, frontend et application suivent une approche en trois phases soigneusement orchestrée.\n\n\n1. **Étendre :** ajouter de nouvelles structures (colonnes, index) tout en gardant les anciennes fonctionnelles.\n\n2. **Migrer :** déployer le nouveau code d'application qui utilise les nouvelles structures.\n\n3. **Réduire :** supprimer les anciennes structures dans les migrations post-déploiement une fois que tout est stable.\n\n**Exemple concret :** lors de l'ajout d'une nouvelle colonne `merge_readiness` aux merge requests :\n\n1. **Étendre :** ajouter la nouvelle colonne avec une valeur par défaut ; le code existant l'ignore.\n\n2. **Migrer :** déployer le code qui lit et écrit dans la nouvelle colonne tout en prenant en charge l'ancienne approche.\n\n3. **Réduire :** après plusieurs déploiements réussis, supprimer l'ancienne colonne dans une migration post-déploiement\n\nToutes les opérations de base de données, le code d'application, le code frontend et bien d'autres, sont soumis à un ensemble de directives que les équipes d’ingénieries doivent respecter, que vous pouvez consulter dans notre [documentation sur la compatibilité multi-versions](https://docs.gitlab.com/development/multi_version_compatibility/).\n\n\n## Résultats et impact\n\nNotre infrastructure de déploiement offre des avantages mesurables :\n\n**Pour GitLab**\n\n* Jusqu'à 12 déploiements quotidiens sur GitLab.com\n* Déploiements sans temps d’arrêt au service de millions de développeurs\n* Application de correctifs de sécurité en production en quelques heures au lieu de plusieurs jours\n* Nouvelles fonctionnalités validées en production à grande échelle avant la disponibilité générale\n\n**Pour nos clients**\n\n* Modèles de déploiement éprouvés que vous pouvez adopter pour vos propres applications\n* Fonctionnalités testées en conditions réelles sur la plus grande instance GitLab au monde avant d'atteindre votre environnement\n* Documentation qui reflète les pratiques de production réelles, et non des bonnes pratiques théoriques\n* Fiabilité des procédures de mise à niveau recommandées par GitLab à toute échelle\n\n## Points clés pour les équipes d'ingénierie\n\nLe pipeline de déploiement de GitLab représente un système sophistiqué qui met en jeu la vélocité de déploiement et la fiabilité opérationnelle. Le modèle de déploiement progressif, l'intégration complète des tests et les capacités robustes de retour à la version précédente fournissent une base pour une livraison logicielle fiable à grande échelle.\n\n\nLes équipes d'ingénierie qui implémentent des systèmes similaires doivent avoir les points clés suivants en tête :\n\n\n- **Tests automatisés :** couverture de tests complète tout au long du pipeline de déploiement\n\n- **Déploiement progressif :** déploiements par étapes afin de minimiser les risques et permettre une récupération rapide\n\n- **Intégration de la surveillance :** observabilité complète à travers toutes les étapes de déploiement\n\n- **Réponse aux incidents :** capacités de détection et de résolution rapides pour les problèmes de déploiement\n\n\nL'architecture de GitLab démontre comment des systèmes CI/CD modernes peuvent gérer la complexité de déploiements à grande échelle tout en maintenant la vélocité requise pour un développement logiciel compétitif.\n\n\n## Note importante sur la portée\n\n\nCet article couvre spécifiquement le pipeline de déploiement pour les services qui font partie du **paquet GitLab Omnibus** et du **chart Helm**, soit le monolithe GitLab principal et ses composants étroitement intégrés.\n\n\nCependant, le paysage d'infrastructure de GitLab s'étend au-delà de ce qui est décrit ici. D'autres services, notamment nos **services d'IA** et les services qui pourraient faire partie d'une **étude de faisabilité**, suivent une approche de déploiement différente au moyen de notre plateforme interne Runway.\n\n\nSi vous travaillez avec ces services ou souhaitez en savoir plus, vous pouvez obtenir plus d'informations dans notre [documentation dédiée à Runway](https://docs.runway.gitlab.com).\n\n\nD'autres offres, telles que [GitLab Dedicated](https://about.gitlab.com/fr-fr/dedicated/ \"GitLab Dedicated\"), sont déployées de manière plus alignée avec ce que nous attendons que les clients soient capables de réaliser eux-mêmes au moyen de **GitLab Environment Toolkit**. Si vous souhaitez en savoir plus, consultez le [projet GitLab Environment Toolkit](https://gitlab.com/gitlab-org/gitlab-environment-toolkit).\n\n\nLes stratégies de déploiement, les considérations architecturales et les complexités de pipeline décrites dans cet article représentent l'approche éprouvée que nous utilisons pour notre plateforme principale, mais comme toute grande organisation d'ingénierie, nous disposons de plusieurs stratégies de déploiement adaptées aux différents types de services et niveaux de maturité.\n\nPour plus de documentation sur le déploiement automatique et nos procédures, vous pouvez consulter les liens ci-dessous :\n- [Déploiements d'ingénierie](https://handbook.gitlab.com/handbook/engineering/deployments-and-releases/deployments/)\n- [Documentation sur les procédures de release](https://gitlab-org.gitlab.io/release/docs/)","Plongez au cœur du pipeline de déploiement de GitLab.com, des déploiements progressifs, des stratégies canari aux migrations de base de données en passant par la compatibilité multi-versions.","Comment déployer la plus grande instance GitLab 12 fois par jour",{"featured":31,"template":13,"slug":690},"continuously-deploying-the-largest-gitlab-instance",{"content":692,"config":704},{"tags":693,"category":9,"body":696,"date":697,"title":698,"description":699,"heroImage":700,"authors":701},[22,694,106,695],"git","migration","La migration d'Azure DevOps vers GitLab peut sembler complexe, mais avec la bonne approche et les bons outils, le processus sera fluide et efficace. Ce guide détaille toutes les étapes pour migrer avec succès vos projets, dépôts et pipelines d'Azure DevOps vers GitLab.\n\n## Vue d'ensemble\n\nGitLab propose à la fois [Congregate](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/) (maintenu par les [Services professionnels de GitLab](https://about.gitlab.com/fr-fr/professional-services/)) et [une importation intégrée des dépôts Git](https://docs.gitlab.com/user/project/import/repo_by_url/) pour migrer des projets depuis Azure DevOps (ADO). Ces options prennent en charge la migration dépôt par dépôt ou de façon groupée et préservent l'historique des commits [git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\"), les branches et les tags. Elles prennent également en charge des éléments supplémentaires tels que les [wikis](https://about.gitlab.com/fr-fr/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management/ \"GitLab Wiki\"), les éléments de travail, les [variables CI/CD](https://about.gitlab.com/fr-fr/blog/demystifying-ci-cd-variables/), les images de conteneurs, les paquets, les pipelines et bien plus encore ([matrice de fonctionnalités](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/ado-migration-features-matrix.md)). Utilisez ce guide pour planifier et exécuter votre migration, puis accomplir les tâches de suivi post-migration.\n\nLes entreprises qui migrent d'Azure DevOps vers GitLab suivent généralement une approche en plusieurs étapes :\n\n* Elles migrent les dépôts d'Azure DevOps vers GitLab à l'aide de Congregate ou de la migration de dépôt intégrée à GitLab.\n* Elles migrent les pipelines d'Azure Pipelines vers GitLab CI/CD.\n* Elles migrent les éléments restants tels que les tableaux, les éléments de travail et les artefacts vers les tickets, registres de paquets et de conteneurs GitLab.\n\nPhases de migration principales :\n\n\n```mermaid\ngraph LR\n    subgraph Prérequis\n        direction TB\n        A[\"Configurer le fournisseur d'identité (IdP)\u003Cbr/>et provisionner les utilisateurs\"]\n        A --> B[\"Configurer les runners et\u003Cbr/>les intégrations tierces\"]\n        B --> I[\"Former les utilisateurs et\u003Cbr/>gérer le changement\"]\n    end\n    \n    subgraph MigrationPhase[\"Phase de migration\"]\n        direction TB\n        C[\"Migrer le code source\"]\n        C --> D[\"Préserver les contributions et\u003Cbr/>l'historique du format\"]\n        D --> E[\"Migrer les éléments de travail,\u003Cbr/>mapper vers \u003Ca href=\"https://docs.gitlab.com/topics/plan_and_track/\">GitLab Plan\u003Cbr/>et suivre le travail\"]\n    end\n    \n    subgraph PostMigration[\"Étapes post-migration\"]\n        direction TB\n        F[\"Créer ou traduire les\u003Cbr/>pipelines ADO vers GitLab CI\"]\n        F --> G[\"Migrer les autres actifs,\u003Cbr/>paquets et images de conteneurs\"]\n        G --> H[\"Introduire des améliorations SDLC et de \u003Ca href=\"https://docs.gitlab.com/user/application_security/secure_your_application/\">sécurité\u003C/a>\u003Cbr/>\"]\n    end\n    \n    Prérequis --> MigrationPhase\n    MigrationPhase --> PostMigration\n\n    style A fill:#FC6D26\n    style B fill:#FC6D26\n    style I fill:#FC6D26\n    style C fill:#8C929D\n    style D fill:#8C929D\n    style E fill:#8C929D\n    style F fill:#FFA500\n    style G fill:#FFA500\n    style H fill:#FFA500\n```\n\n\n## Planifiez votre migration\n\n**Pour planifier votre migration, posez-vous ces questions :**\n\n* Dans quels délais devons-nous achever la migration ?\n* Comprenons-nous ce qui sera migré ?\n* Qui exécutera la migration ?\n* Quelle structure organisationnelle souhaitons-nous mettre en place dans GitLab ?\n* Existe-t-il des contraintes, limitations ou pièges à prendre en compte ?\n\nDéterminez votre calendrier, car il dictera en grande partie votre approche de migration. Identifiez des spécialistes ou des groupes familiarisés avec les plateformes Azure DevOps et GitLab (comme les « Early adopters ») pour faciliter l'adoption et fournir des conseils.\n\n**Faites l'inventaire de ce que vous devez migrer :**\n\n* Le nombre de dépôts, de pull requests et de contributeurs\n* Le nombre et la complexité des éléments de travail et des pipelines\n* Les tailles de dépôts et les relations de dépendance\n* Les intégrations critiques et les exigences relatives aux runners (pools d'agents dotés de capacités spécifiques)\n\nUtilisez l'outil [Evaluate](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate#beta-azure-devops) des Services professionnels de GitLab pour produire un inventaire complet de toute votre organisation Azure DevOps avec les dépôts, le nombre de pull requests, les listes de contributeurs, le nombre de pipelines, les éléments de travail, les variables CI/CD et bien plus encore. Si vous travaillez avec l'équipe des Services professionnels de GitLab, partagez ce rapport avec votre responsable de mission ou votre architecte technique pour faciliter la planification de la migration.\n\nLe calendrier de migration est principalement déterminé par le nombre de pull requests, la taille des dépôts et le volume de contributions (par exemple, les commentaires dans les pull requests, les éléments de travail, etc.). 1 000 petits dépôts avec un nombre limité de pull requests et de contributeurs peuvent migrer beaucoup plus rapidement qu'un ensemble plus restreint de dépôts contenant des dizaines de milliers de pull requests et des milliers de contributeurs. Utilisez vos données d'inventaire pour estimer l'effort et planifier des tests avant de procéder aux migrations de production.\n\nComparez l'inventaire avec le calendrier souhaité et décidez si vous allez migrer tous les dépôts à la fois ou par lots. Si les équipes ne peuvent pas migrer simultanément, organisez les migrations par lots et échelonnez-les pour vous aligner sur les calendriers des équipes. Par exemple, lors des missions des Services professionnels, nous organisons des migrations par vagues de 200 à 300 projets pour limiter la complexité et respecter les limites de débit des API, à la fois dans [GitLab](https://docs.gitlab.com/security/rate_limits/) et [ADO](https://learn.microsoft.com/en-us/azure/devops/integrate/concepts/rate-limits?view=azure-devops).\n\nL'[outil d'importation de dépôt intégré](https://docs.gitlab.com/user/project/import/repo_by_url/) de GitLab migre les dépôts Git (commits, branches et tags) un par un. Congregate est conçu pour préserver les pull requests (appelées merge requests dans GitLab), les commentaires et les métadonnées associées lorsque cela est possible ; l'importation simple de dépôt intégrée se concentre uniquement sur les données Git (historique, branches et tags).\n\n**Éléments nécessitant généralement une migration distincte ou une recréation manuelle :**\n\n* Pipelines Azure : créez des pipelines GitLab CI/CD équivalents (consultez la [documentation YAML CI/CD](https://docs.gitlab.com/ci/yaml/) et/ou les [composants CI/CD](https://docs.gitlab.com/ci/components/)). Vous pouvez également envisager d'utiliser la conversion de pipelines basée sur l'IA disponible dans Congregate.\n* Éléments de travail et tableaux : mappez-les vers les tickets, epics et tableaux de tickets de GitLab.\n* Artefacts, images de conteneurs (ACR) : migrez-les vers le registre de paquets ou le registre de conteneurs de GitLab.\n* Hooks de service et intégrations externes : recréez-les dans GitLab.\n* Les [modèles de permissions](https://docs.gitlab.com/user/permissions/) diffèrent entre ADO et GitLab ; examinez et planifiez le mappage des permissions plutôt que de supposer une préservation exacte.\n\nExaminez ce que chaque outil (Congregate vs importation intégrée) va migrer et choisissez celui qui correspond à vos besoins. Dressez une liste de toutes les données ou intégrations qui doivent être migrées ou recréées manuellement.\n\n**Qui exécutera la migration ?**\n\nLes migrations sont généralement exécutées par un propriétaire de groupe GitLab ou un administrateur d'instance, ou par une personne désignée ayant obtenu les permissions nécessaires relatives au groupe/projet de destination. Congregate et les API d'importation GitLab nécessitent des tokens d'authentification valides pour Azure DevOps et GitLab.\n\n* Décidez si un propriétaire/administrateur de groupe effectuera les migrations ou si vous accorderez un accès délégué à une équipe/personne spécifique.\n* Assurez-vous que la personne dédiée à la migration a correctement configuré les tokens d'accès personnels (Azure DevOps et GitLab) avec les portées requises par votre outil de migration choisi (par exemple, les portées api/read_repository et toute exigence spécifique à l'outil).\n* Testez les tokens et les permissions avec une petite migration pilote.\n\n**Remarque :** Congregate exploite la fonctionnalité d'importation basée sur des fichiers pour les migrations ADO et nécessite des permissions d'administrateur d'instance pour s'exécuter ([consultez notre documentation](https://docs.gitlab.com/user/project/settings/import_export/#migrate-projects-by-uploading-an-export-file)). Si vous migrez vers GitLab.com, envisagez de faire appel aux Services professionnels. Pour plus d'informations, consultez leur [catalogue complet](https://about.gitlab.com/professional-services/catalog/). Un compte non-administrateur ne peut pas préserver l'attribution des contributions !\n\n**Quelle structure organisationnelle souhaitons-nous dans GitLab ?**\n\nBien qu'il soit possible de mapper directement la structure ADO vers la structure GitLab, il est recommandé de rationaliser et de simplifier la structure pendant la migration. Réfléchissez à la façon dont les équipes travailleront dans GitLab et concevez la structure de façon à faciliter la collaboration et la gestion des accès. Voici un exemple de mappage de la structure ADO vers la structure GitLab :\n\n\n```mermaid\ngraph TD\n    subgraph GitLab\n        direction TB\n        A[\"Groupe principal\"]\n        B[\"Sous-groupe (facultatif)\"]\n        C[\"Projets\"]\n        A --> B\n        A --> C\n        B --> C\n    end\n\n    subgraph AzureDevOps[\"Azure DevOps\"]\n        direction TB\n        F[\"Organisations\"]\n        G[\"Projets\"]\n        H[\"Dépôts\"]\n        F --> G\n        G --> H\n    end\n\n    style A fill:#FC6D26\n    style B fill:#FC6D26\n    style C fill:#FC6D26\n    style F fill:#8C929D\n    style G fill:#8C929D\n    style H fill:#8C929D\n```\n\n\nApproche recommandée :\n\n* Mappez chaque organisation ADO à un groupe GitLab (ou un petit ensemble de groupes), et non à de nombreux petits groupes. Évitez de créer un groupe GitLab pour chaque projet d'équipe ADO et utilisez la migration comme une opportunité de rationaliser votre structure GitLab.\n* Utilisez des sous-groupes et des permissions au niveau du projet pour regrouper les dépôts associés.\n* Gérez l'accès à des ensembles de projets en utilisant les groupes et l'appartenance aux groupes (groupes et sous-groupes) de GitLab plutôt qu'un groupe par projet d'équipe.\n* Examinez les [permissions](https://docs.gitlab.com/ee/user/permissions.html) de GitLab et utilisez les [liens de groupe SAML](https://docs.gitlab.com/user/group/saml_sso/group_sync/) pour mettre en œuvre un modèle de contrôle d'accès basé sur les rôles (RBAC) d'entreprise pour votre instance GitLab (ou un espace de nommage GitLab.com).\n\n**Tableaux ADO et éléments de travail : état de la migration**\n\nIl est important de comprendre comment les éléments de travail migrent d'ADO vers GitLab Plan (tickets, epics et tableaux).\n\n* Les tableaux et éléments de travail ADO sont mappés vers les tickets, epics et tableaux de tickets de GitLab. Planifiez comment vos workflows et configurations de tableaux seront migrés.\n* Les epics et fonctionnalités ADO deviennent des epics GitLab.\n* Les autres types d'éléments de travail (user stories, tâches, bogues) deviennent des tickets au niveau du projet.\n* La plupart des champs standard sont préservés ; certains champs personnalisés sélectionnés peuvent être migrés lorsqu'ils sont pris en charge.\n* Les relations parent-enfant sont conservées afin que les epics référencent tous les tickets associés.\n* Les liens vers les pull requests sont convertis en liens de merge requests pour maintenir la traçabilité du développement.\n\nExemple d'une migration d'un élément de travail individuel vers un ticket GitLab, avec conservation des champs et relations :\n\n![Exemple d'une migration d'un élément de travail individuel vers un ticket GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764769188/ztesjnxxfbwmfmtckyga.png)\n\nConseils pour la migration par lots :\n\n* Si vous devez exécuter des migrations par lots, utilisez votre nouvelle structure de groupe/sous-groupe pour définir les lots (par exemple, par organisation ADO ou par domaine produit).\n* Utilisez les rapports d'inventaire pour orienter la sélection des lots et testez chaque lot avec une migration pilote avant d'effectuer la migration complète.\n\n**Migration des pipelines**\n\nCongregate a [récemment introduit](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/merge_requests/1298) une conversion basée sur l'IA pour les pipelines YAML multi-étapes d'Azure DevOps vers GitLab CI/CD. Cette conversion automatisée fonctionne avant tout pour les pipelines simples avec un fichier unique et est conçue pour fournir un point de départ fonctionnel plutôt qu'un fichier `.gitlab-ci.yml` prêt pour la production. L'outil génère un pipeline GitLab équivalent sur le plan fonctionnel que vous pouvez ensuite affiner et optimiser selon vos besoins.\n\n*  Conversion automatique des pipelines YAML Azure au format `.gitlab-ci.yml`\n* Mieux adapté pour les configurations de pipeline simples avec un fichier unique\n* Fichier passe-partout fourni pour accélérer la migration, pas un artefact de production final\n* Revue et ajustement requis pour les scénarios complexes, les tâches personnalisées ou les exigences de l'entreprise\n* Pas de prise en charge de pipelines de version classiques Azure DevOps, [conversion en YAML multi-étapes](https://learn.microsoft.com/fr-fr/azure/devops/pipelines/release/from-classic-pipelines?view=azure-devops) nécessaire\n\nLes propriétaires de dépôts doivent consulter la [documentation GitLab CI/CD](https://docs.gitlab.com/ci/) pour optimiser et améliorer davantage leurs pipelines après la conversion initiale.\n\nExemple de pipelines convertis :\n\n\n```yml \n\n# azure-pipelines.yml\n\ntrigger:\n  - main\n\nvariables:\n  imageName: myapp\n\nstages:\n  - stage: Build\n    jobs:\n      - job: Build\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          - task: Docker@2\n            displayName: Build Docker image\n            inputs:\n              command: build\n              repository: $(imageName)\n              Dockerfile: '**/Dockerfile'\n              tags: |\n                $(Build.BuildId)\n\n  - stage: Test\n    jobs:\n      - job: Test\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          # Example: run tests inside the container\n          - script: |\n              docker run --rm $(imageName):$(Build.BuildId) npm test\n            displayName: Run tests\n\n  - stage: Push\n    jobs:\n      - job: Push\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          - task: Docker@2\n            displayName: Login to ACR\n            inputs:\n              command: login\n              containerRegistry: '\u003Cyour-acr-service-connection>'\n\n          - task: Docker@2\n            displayName: Push image to ACR\n            inputs:\n              command: push\n              repository: $(imageName)\n              tags: |\n                $(Build.BuildId)\n\n```\n\n```yaml\n\n# .gitlab-ci.yml\n\nvariables:\n  imageName: myapp\n\nstages:\n  - build\n  - test\n  - push\n\nbuild:\n  stage: build\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker build -t $imageName:$CI_PIPELINE_ID -f $(find . -name Dockerfile) .\n  only:\n    - main\n\ntest:\n  stage: test\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker run --rm $imageName:$CI_PIPELINE_ID npm test\n  only:\n    - main\n\npush:\n  stage: push\n  image: docker:latest\n  services:\n    - docker:dind\n  before_script:\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n  script:\n    - docker tag $imageName:$CI_PIPELINE_ID $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n    - docker push $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n  only:\n    - main\n\n```\n\n\n**Liste de contrôle finale :**\n\n* Décidez du calendrier et de la stratégie par lots.\n* Produisez un inventaire complet des dépôts, pull requests et contributeurs.\n* Choisissez Congregate ou l'importation intégrée en fonction de la portée (pull requests  et métadonnées vs données Git uniquement).\n* Décidez qui exécutera les migrations et assurez-vous que les tokens/permissions sont configurés.\n* Identifiez les éléments qui doivent être migrés séparément (pipelines, éléments de travail, artefacts et hooks) et planifiez ces migrations.\n* Effectuez des migrations pilotes, validez les résultats, puis passez à la migration complète selon votre calendrier.\n\n## Exécutez vos migrations\n\nUne fois la planification terminée, exécutez les migrations par étapes, en commençant par des migrations d'essai, qui permettent de faire remonter les problèmes spécifiques à l'organisation tôt et de mesurer la durée, de valider les résultats et d'affiner votre approche avant la production.\n\nUtilisez les migrations d'essai pour valider les éléments suivants :\n\n* Succès de la migration d'un dépôt donné et des éléments associés (historique, branches, tags ; ainsi que les merge requests/commentaires si vous utilisez Congregate)\n* Utilisation immédiate de la destination (permissions, runners, variables CI/CD, intégrations)\n* Durée de chaque lot (afin de définir les calendriers et les attentes des parties prenantes)\n\nConseils concernant les temps d'arrêt :\n\n* L'importation Git intégrée de GitLab et Congregate ne nécessitent pas intrinsèquement de temps d'arrêt.\n* Pour les vagues de production, gelez les modifications dans ADO (protections de branches ou lecture seule) pour éviter les commits manqués, les mises à jour de pull requests ou les éléments de travail créés en cours de migration.\n* Les essais n'ont pas besoin d'être gelés et peuvent être exécutés à tout moment.\n\nConseils pour la migration par lots :\n\n* Exécutez des lots d'essai consécutifs pour raccourcir le temps écoulé ; laissez les équipes valider les résultats de manière asynchrone.\n* Utilisez votre structure de groupe/sous-groupe planifiée pour définir les lots et respectez les limites de débit des API.\n\nÉtapes recommandées :\n\n1. Créez une destination de test dans GitLab pour les essais :\n\n* GitLab.com : créez un groupe/espace de nommage dédié (par exemple, my-org-sandbox).\n* Instance auto-gérée : créez un groupe de niveau supérieur ou une instance de test distincte si nécessaire.\n\n2. Préparez l'authentification :\n\n* PAT Azure DevOps avec les portées requises.\n* Token d'accès personnel GitLab avec api et read_repository (plus accès administrateur pour les importations basées sur des fichiers utilisées par Congregate).\n\n3. Exécutez des migrations d'essai :\n\n* Dépôts uniquement : utilisez l'importation intégrée de GitLab (dépôt par URL).\n* Dépôts + pull requests/merge requests et actifs supplémentaires : utilisez Congregate.\n\n4. Suivi post-essai :\n\n* Vérifiez l'historique du dépôt, les branches, les tags ; les merge requests (si elles ont été migrées), les tickets/epics (s'ils ont été migrées), les labels et les relations.\n* Vérifiez les permissions/rôles, les branches protégées, les approbations requises, les runners/tags, les variables/secrets, les intégrations/webhooks.\n* Validez les pipelines (`.gitlab-ci.yml`) ou les pipelines convertis le cas échéant.\n\n5. Demandez aux utilisateurs de valider la fonctionnalité et la fidélité des données.\n6. Résolvez les problèmes découverts lors des essais et mettez à jour vos runbooks.\n7. Réseau et sécurité :\n\n* Si votre destination utilise des listes d'IP autorisées, ajoutez les IP de votre hôte de migration et tous les runners/intégrations requis afin de garantir la réussite des importations.\n\n8. Exécutez les migrations de production par vagues :\n\n* Appliquez des gels de modifications dans ADO pendant chaque vague.\n* Surveillez la progression et les logs ; réessayez ou ajustez les tailles de lots si vous atteignez les limites de débit.\n\n9. Facultatif : supprimez le groupe de l'environnement sandbox ou archivez-le après avoir terminé.\n\n\u003Cfigure class=\"video_container\">\n      \u003Ciframe src=\"https://www.youtube.com/embed/ibIXGfrVbi4?si=ZxOVnXjCF-h4Ne0N\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n    \u003C/figure>\n\n## Références terminologiques pour GitLab et Azure DevOps\n\n| GitLab                                                           | Azure DevOps                                 | Similitudes et différences clés                                                                                                                                          |\n| ---------------------------------------------------------------- | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Groupe                                                            | Organisation                                 | Espace de nommage principal, adhésion, politiques. Une organisation ADO contient des projets ; un groupe GitLab contient des sous-groupes et des projets.                                                   |\n| Groupe ou sous-groupe                                                | Projet                                      | Conteneur logique, limite de permissions. Un projet ADO contient de nombreux dépôts ; les groupes/sous-groupes GitLab contiennent de nombreux projets.                                                |\n| Projet (inclut un dépôt Git)                                    | Dépôt (à l'intérieur d'un projet)                | Historique Git, branches, tags. Dans GitLab, un « projet » est le dépôt plus les tickets, CI/CD, wiki, etc. Un dépôt par projet.                                                  |\n| Merge Request (MR)                                               | Pull Request (PR)                            | Revue de code, discussions, approbations. Les règles des MR incluent les approbations, les pipelines requis, les propriétaires de code.                                                                     |\n| Branches protégées, règles d'approbation des MR, vérifications de statut             | Politiques des branches                              | Imposent des revues et des vérifications. GitLab combine les protections + les règles d'approbation + les vérifications de statut requises.                                                                    |\n| GitLab CI/CD                                                     | Pipelines Azure                             | Pipelines YAML, étapes/jobs, logs. ADO a également des pipelines UI classiques ; GitLab se concentre sur .gitlab-ci.yml.                                                               |\n| .gitlab-ci.yml                                                   | azure-pipelines.yml                          | Définit les étapes/jobs/déclencheurs. La syntaxe/les fonctionnalités diffèrent ; map job, variables, artefacts et déclencheurs.                                                                   |\n| Runners (partagés/spécifiques)                                        | Agents / pools d'agents                         | Exécutent les jobs sur des machines/conteneurs. Ciblent via des demandes (ADO) ou tags (GitLab). L'enregistrement/la portée diffère.                                                         |\n| Variables CI/CD (projet/groupe/instance), protégées/masquées       | Variables de pipeline, groupes de variables, bibliothèque | Transmettent la configuration/les secrets aux jobs. GitLab prend en charge l'héritage de groupe et les flags de masquage/protection.                                                                          |\n| Intégrations, variables CI/CD, clés de déploiement                       | Connexions de service                          | Authentification externe vers les services/clouds. Map vers les intégrations ou les variables ; des assistants spécifiques au cloud sont disponibles.                                                                 |\n| Environnements et déploiements (environnements protégés)                      | Environnements (avec approbations)                | Suivent les cibles/l'historique de déploiement. Approbations via environnements protégés et jobs manuels dans GitLab.                                                                                 |\n| Versions (tag + notes)                                           | Versions (classiques ou pipelines)              | Notes/artefacts versionnés. La version GitLab est liée aux tags ; les déploiements sont suivis séparément.                                                                               |\n| Artefacts de job                                                    | Artefacts de pipeline                           | Inscrivent de manière permanente les sorties de job. La rétention/l'expiration sont configurées par job ou par projet.                                                                                                  |\n| Registre de paquets (NuGet/npm/Maven/PyPI/Composer, etc.)           | Artefacts Azure (NuGet/npm/Maven, etc.)      | Hébergement de paquets. L'authentification/l'espace de nommage diffère ; migrez par type de paquets.                                                                                                     |\n| Registre de conteneurs GitLab                                        | Registre de conteneurs Azure (ACR) ou autres     | Images OCI. GitLab fournit des registres par projet/groupe.                                                                                                             |\n| Tableaux de tickets                                                     | Tableaux                                       | Affichent les tâches dans des colonnes. Les tableaux GitLab sont pilotés par des labels ; plusieurs tableaux par projet/groupe.                                                                         |\n| Tickets (types/labels), epics                                     | Éléments de travail (user story/bogue/tâche)             | Suivent les unités de travail. Mappent les types/champs ADO vers les labels/champs personnalisés ; epics au niveau du groupe.                                                                              |\n| Epics, tickets parent/enfant                                       | Epics/fonctionnalités                               | Hiérarchie du travail. Le schéma diffère ; utilisation des epics + relations de tickets.                                                                                                   |\n| Jalons et itérations                                        | Chemins d'itération                              | Temps limité. Itérations GitLab (fonctionnalité de groupe) ou jalons par projet/groupe.                                                                                       |\n| Labels (labels à portée)                                           | Chemins de domaine                                   | Catégorisation/propriété. Remplacement des domaines hiérarchiques par des labels à portée.                                                                                              |\n| Wiki de projet/groupe                                               | Wiki de projet                                 | Wiki Markdown. Sauvegardes avec des dépôts dans les deux ; la mise en page/l'authentification diffère légèrement.                                                                                                  |\n| Rapports de test via CI, gestion des exigences/tests, intégrations  | Plans/cas/exécutions de test                        | QA des preuves/de la traçabilité. Pas de correspondance 1:1 avec les plans de test ADO ; utilisent souvent les rapports CI + tickets/exigences.                                                                     |\n| Rôles (propriétaire/chargé de maintenance/développeur/rapporteur/invité) + rôles personnalisés | Niveaux d'accès + permissions granulaires         | Contrôlent la lecture/l'écriture/l'administration. Les modèles diffèrent ; exploitation de l'héritage de groupe et des ressources protégées.                                                                          |\n| Webhooks                                                         | Hooks de service                                | Intégrations basées sur les événements. Les noms/charges utiles d'événements diffèrent ; reconfiguration des points de terminaison.                                                                                        |\n| Recherche avancée                                                  | Recherche de code                                  | Recherche dans le dépôt en texte intégral. GitLab Self-Managed peut nécessiter Elasticsearch/OpenSearch pour les fonctionnalités avancées.","2025-12-08","Migrer d'Azure DevOps vers GitLab :  le guide complet","Découvrez comment migrer d'Azure DevOps vers GitLab à l'aide des outils de migration des Services professionnels de GitLab, de la planification à l'exécution en passant par les tâches de suivi post-migration.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658924/Blog/Hero%20Images/securitylifecycle-light.png",[702,703],"Evgeny Rudinsky","Michael Leopard",{"featured":31,"template":13,"slug":705},"migration-from-azure-devops-to-gitlab",{"content":707,"config":719},{"title":708,"description":709,"authors":710,"heroImage":713,"date":714,"body":715,"category":9,"tags":716},"GitLab transforme les cycles de test des systèmes embarqués","Découvrez comment les environnements de cycle de vie gérés rationalisent et automatisent les tests virtuels grâce à un retour rapide sans multiplication des environnements ni augmentation des coûts.",[711,712],"Matt DeLaney","Darwin Sanoy","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099203/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2820%29_2bJGC5ZP3WheoqzlLT05C5_1750099203484.png","2025-10-28","Les équipes de développement des systèmes embarqués connaissent bien ce cycle : elles écrivent du code, attendent des jours ou des semaines pour le tester sur un banc de test matériel, découvrent des bogues, les corrigent, puis attendent à nouveau. Les environnements de test virtuels promettent un retour plus rapide, mais la plupart des implémentations créent de nouveaux problèmes tels que la multiplication des environnements et l'augmentation des coûts.\n\nLes environnements de cycle de vie gérés de GitLab permettent de résoudre ces défis liés aux tests virtuels. Grâce à l'automatisation des environnements virtuels, GitLab accélère les cycles de développement des systèmes embarqués sans configuration complexe ni augmentation des coûts.\n\n> **[→ Essayez GitLab Ultimate et GitLab Duo Enterprise gratuitement.](https://about.gitlab.com/fr-fr/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr)**\n\n## Défis posés par les tests virtuels\n\nLes environnements de test virtuels sont des configurations matérielles simulées qui reproduisent le comportement des systèmes embarqués dans des conditions réelles. De plus, ils offrent la possibilité de réduire les goulots d'étranglement matériels. Les équipes peuvent tester un micrologiciel sur des processeurs simulés, exécuter des tests Model-in-the-Loop (MIL) dans MATLAB/Simulink ou vérifier le logiciel sur des systèmes embarqués virtuels sans attendre l'accès au matériel physique.\n\nCependant, les équipes implémentent souvent les environnements virtuels au moyen de deux approches courantes, qui entraînent des défis non viables.\n\n### Première approche : environnements de cycle de vie des pipelines\n\n**Les environnements de cycle de vie des pipelines recréent l'ensemble de la configuration de test pour chaque exécution [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce qu'un pipeline CI/CD ?\").** Lorsque des modifications de code déclenchent votre pipeline CI/CD, le système provisionne l'infrastructure, installe les simulations logicielles et configure tout depuis le début avant d'exécuter les tests.\n\nCette approche fonctionne pour des scénarios simples, mais perd en efficacité à mesure que la complexité augmente. Prenons par exemple les tests Software-in-the-Loop (SIL) dans un environnement virtuel complexe. Chaque exécution de pipeline nécessite une recréation complète de l'environnement avec provisionnement des processeurs virtuels, installations des chaînes d'outils et configurations cibles. **Ces processus peuvent prendre un temps considérable.**\n\nDe plus, à mesure que les systèmes embarqués nécessitent des configurations matérielles virtuelles plus sophistiquées, les **coûts de provisionnement augmentent rapidement.**\n\nPour éviter les coûts liés aux configurations et les délais, de nombreuses équipes se tournent vers des environnements avec une longue durée de vie qui persistent entre les exécutions de tests, mais ces derniers présentent des inconvénients.\n\n### Seconde approche : environnements avec une longue durée de vie\n\n**Les environnements avec une longue durée de vie sont persistants** pour éviter une reconstruction constante. Les équipes de développement commencent par demander ces environnements aux équipes informatiques ou [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Qu'est-ce que le DevOps ?\"). Ils doivent ensuite attendre leur approbation, puis ont besoin que quelqu'un provisionne manuellement l'infrastructure. Ces environnements sont liés à des développeurs ou équipes plutôt qu'à des modifications de code spécifiques, et ils prennent en charge le travail de développement continu sur plusieurs projets.\n\nBien que cette approche élimine les coûts de reconstruction, **elle multiplie les environnements**, qui s'accumulent sans date de fin claire. Les coûts d'infrastructure augmentent à mesure que les environnements consomment des ressources.\n\nLes environnements avec une longue durée de vie souffrent également d'une **dégradation de configuration** : les environnements conservent des paramètres, des données en cache ou des versions logicielles de tests précédents qui peuvent affecter les résultats ultérieurs. Un test qui devrait échouer finit par réussir en raison des données persistantes issues des tests précédents.\n\nEn fin de compte, la gestion des environnements avec une longue durée de vie est un processus manuel qui ralentit la vélocité de développement et augmente les coûts opérationnels.\n\n**GitLab propose une troisième approche** : les « environnements de cycle de vie gérés », qui offrent les avantages des deux premières approches, sans les inconvénients.\n\n## Solution : les environnements de cycle de vie gérés\n\nLes environnements de cycle de vie gérés de GitLab associent les configurations de test virtuelles aux merge requests ([MR](https://docs.gitlab.com/user/project/merge_requests/)) plutôt qu'aux exécutions de pipeline ou aux équipes de développement. Ils peuvent être considérés comme des « environnements de test MR gérés ». Lorsque vous créez une merge request pour une nouvelle fonctionnalité, GitLab orchestre automatiquement le provisionnement des environnements de test virtuels nécessaires, qui sont maintenus tout au long du processus de développement de la fonctionnalité.\n\n### Avantages clés\n\n* **Environnements persistants sans reconstruction :** le même environnement virtuel gère plusieurs exécutions de pipeline pendant que vous itérez sur votre fonctionnalité. Que vous exécutiez des tests MIL dans MATLAB/Simulink ou des tests SIL sur des processeurs embarqués spécialisés, l'environnement reste configuré et prêt.\n\n* **Nettoyage automatique :** lorsque vous fusionnez votre fonctionnalité et supprimez la branche, GitLab déclenche automatiquement le nettoyage de l'environnement pour éliminer la multiplication des environnements.\n\n* **Source unique de vérité :** la merge request enregistre tous les résultats de compilation, les résultats des tests et les métadonnées des environnements en un seul endroit. Les membres de l'équipe peuvent suivre les progrès et collaborer sans jongler entre différents outils ou feuilles de calcul.\n\nRegardez cette vidéo pour découvrir comment les environnements de cycle de vie gérés fonctionnent en pratique :\n\n\u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/9tfyVPK5DuI?si=Kj_xXNo02bnFBDhy\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe> \u003C/figure>\n\nGitLab automatise l'ensemble du workflow de test. Chaque fois que vous exécutez des tests de micrologiciel, GitLab orchestre les tests dans l'environnement virtuel adéquat, enregistre les résultats et fournit une visibilité complète sur chaque exécution de pipeline. Cette approche transforme les tests virtuels complexes d'un processus manuel sujet aux erreurs en workflows automatisés et fiables.\n\n**Résultat :** les équipes profitent d'environnements réutilisables sans coûts incontrôlés. Elles augmentent l'efficacité et maintiennent des configurations de test propres et isolées pour chaque fonctionnalité.\n\nDécouvrez une démonstration des environnements de cycle de vie gérés avec un test de micrologiciel sur du matériel virtuel :\n\n\u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/iWdY-kTlpH4?si=D6rpoulr9sv6Sl6E\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe> \u003C/figure>\n\n## Impact métier\n\nLes environnements de cycle de vie gérés de GitLab entraînent des améliorations mesurables dans les workflows de développement de systèmes embarqués. Les équipes qui exécutent des tests MIL dans MATLAB/Simulink et des tests SIL sur des processeurs spécialisés comme Infineon AURIX ou les systèmes BlackBerry QNX n'ont plus à gérer des reconstructions constantes d'environnements ou la multiplication incontrôlée des environnements. Ces configurations de test virtuelles complexes persistent tout au long du développement des fonctionnalités et exécutent un nettoyage automatique une fois terminées. Leurs avantages sont nombreux :\n\n* Cycles de développement produit plus rapides\n* Délai de mise sur le marché plus court\n* Coûts d'infrastructure réduits\n* Assurance qualité supérieure\n\n> **[→ Essayez GitLab Ultimate et GitLab Duo Enterprise gratuitement.](https://about.gitlab.com/fr-fr/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr)**\n",[680,717,718],"embedded DevOps","testing",{"featured":12,"template":13,"slug":720},"how-gitlab-transforms-embedded-systems-testing-cycles",{"promotions":722},[723,737,749],{"id":724,"categories":725,"header":727,"text":728,"button":729,"image":734},"ai-modernization",[726],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":730,"config":731},"Get your AI maturity score",{"href":732,"dataGaName":733,"dataGaLocation":243},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":735},{"src":736},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":738,"categories":739,"header":741,"text":728,"button":742,"image":746},"devops-modernization",[680,740],"devsecops","Are you just managing tools or shipping innovation?",{"text":743,"config":744},"Get your DevOps maturity score",{"href":745,"dataGaName":733,"dataGaLocation":243},"/assessments/devops-modernization-assessment/",{"config":747},{"src":748},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":750,"categories":751,"header":753,"text":728,"button":754,"image":758},"security-modernization",[752],"security","Are you trading speed for security?",{"text":755,"config":756},"Get your security maturity score",{"href":757,"dataGaName":733,"dataGaLocation":243},"/assessments/security-modernization-assessment/",{"config":759},{"src":760},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":762,"blurb":763,"button":764,"secondaryButton":768},"Commencez à développer plus rapidement dès aujourd'hui","Découvrez ce que votre équipe peut accomplir avec la plateforme d'orchestration intelligente pour le DevSecOps.\n",{"text":45,"config":765},{"href":766,"dataGaName":48,"dataGaLocation":767},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/fr-fr/","feature",{"text":50,"config":769},{"href":52,"dataGaName":53,"dataGaLocation":767},1772652094248]