[{"data":1,"prerenderedAt":766},["ShallowReactive",2],{"/fr-fr/blog/meet-regulatory-standards-with-gitlab":3,"navigation-fr-fr":40,"banner-fr-fr":444,"footer-fr-fr":454,"blog-post-authors-fr-fr-Abubakar Siddiq Ango":664,"blog-related-posts-fr-fr-meet-regulatory-standards-with-gitlab":678,"assessment-promotions-fr-fr":719,"next-steps-fr-fr":757},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":26,"isFeatured":11,"meta":27,"navigation":28,"path":29,"publishedDate":22,"seo":30,"stem":34,"tagSlugs":35,"__hash__":39},"blogPosts/fr-fr/blog/meet-regulatory-standards-with-gitlab.yml","Meet Regulatory Standards With Gitlab",[7],"abubakar-siddiq-ango",null,"security",{"featured":11,"template":12,"slug":13},false,"BlogPost","meet-regulatory-standards-with-gitlab",{"tags":15,"category":9,"authors":19,"heroImage":21,"date":22,"body":23,"description":24,"title":25},[16,17,9,18],"DevSecOps","DevSecOps platform","public sector",[20],"Abubakar Siddiq Ango","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1750098739/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_282096522_securitycompliance.jpeg_1750098739024.jpg","2026-02-09","Des principes directeurs sous forme de normes ont toujours permis de garantir la livraison sécurisée et fiable de produits et services aux clients. Ces normes, généralement appliquées par des organismes légalement mandatés, réglementent les secteurs d'activité et empêchent la diffusion de produits de qualité inférieure.\n\nDans le secteur des technologies de l'information, le respect des normes va au-delà de la livraison du produit final ; il englobe l'ensemble du cycle de vie de la solution. Étant donné que tous les secteurs d'activité exploitent de plus en plus diverses formes de technologies afin d'accélérer les processus et d'améliorer l'efficacité, de vastes quantités de données souvent sensibles sont générées, stockées et transmises au moyen d'outils et de services informatiques. Le traitement inapproprié de ces données peut entraîner de graves conséquences et conduire à des pertes financières [de l'ordre de centaines de millions de dollars](https://tech.co/news/data-breaches-updated-list).\n\nCe guide complet présente des normes de conformité du monde entier et explique comment respecter les normes réglementaires avec la gestion des politiques de conformité et de sécurité de GitLab.\n## Normes de conformité informatiques courantes\n\nLes normes de conformité réglementaire prennent diverses formes et dépendent du secteur d'activité ou de la région dans laquelle une organisation opère. Nous examinerons d'abord les normes de conformité courantes, suivies des normes spécifiques à certaines régions et à certains secteurs.\n\n### RGPD\n\nLe [Règlement général sur la protection des données (RGPD)](https://gdpr-info.eu/) est une loi importante de l'Union européenne qui régit la protection des données personnelles. Mis en œuvre en 2018, le RGPD établit des directives strictes pour les organisations qui traitent les informations personnelles des résidents de l'UE. Il accorde aux individus un contrôle accru sur leurs données, notamment le droit d'accéder, de rectifier et d'effacer les informations personnelles détenues par les entreprises. Le RGPD exige que les organisations obtiennent un consentement explicite avant de collecter ou de traiter des données personnelles et qu'elles expliquent clairement l'objectif de la collecte de données. Le non-respect peut entraîner des sanctions financières importantes.\n\nBien qu'il s'agisse d'une réglementation de l'UE, le RGPD a des implications dans le monde entier et concerne toute organisation qui traite les données des résidents de l'UE. Cette législation a entraîné des changements généralisés dans les pratiques de traitement des données et a sensibilisé le monde entier aux questions de confidentialité.\n\n### NIST SSDF\n\nLe framework relatif au développement de logiciels sécurisés NIST, SSDF [(NIST Secure Software Development Framework, SSDF)](https://csrc.nist.gov/Projects/ssdf)  est un guide qui aide les organisations à créer des logiciels plus sûrs. Créé par le National Institute of Standards and Technology, ce framework propose [des pratiques de base pour le développement sécurisé de logiciels](https://about.gitlab.com/blog/comply-with-nist-secure-supply-chain-framework-with-gitlab/).\n\nLe SSDF se concentre sur quatre domaines principaux : préparer l'organisation, protéger le logiciel, créer des logiciels sécurisés et gérer les vulnérabilités. Il aide les entreprises à intégrer la sécurité, y compris les protocoles de sécurité, pendant le développement et tout au long de la chaîne d'approvisionnement logicielle.\n\nEn suivant ces directives, les organisations peuvent créer des logiciels avec moins de points faibles et gérer les problèmes plus efficacement. Le SSDF est flexible et peut fonctionner avec différentes méthodes de développement logiciel, il est donc utile pour de nombreuses organisations.\n\n### PCI DSS\n\nLa norme de sécurité de l’industrie des cartes de paiement [(Payment Card Industry Data Security Standard, PCI DSS)](https://www.pcisecuritystandards.org/lang/fr-fr/) représente un ensemble de règles de sécurité pour les organisations qui traitent des informations de cartes de crédit. Créée par les principales sociétés de cartes de crédit, elle vise à protéger les données des titulaires de cartes et à prévenir la fraude. La norme PCI DSS exige que les entreprises mettent en place et maintiennent un réseau sécurisé, protègent les données des titulaires de cartes, utilisent des mesures strictes de contrôle d'accès, surveillent et testent régulièrement les réseaux et maintiennent une politique de sécurité de l'information. Ces règles s'appliquent à toute entreprise qui accepte, traite, stocke ou transmet des données de cartes de crédit.\n\nLa conformité à la norme PCI DSS est obligatoire pour ces entreprises, quelle que soit leur taille ou leur volume de transactions. En suivant cette norme, les entreprises peuvent mieux protéger les informations financières sensibles, réduire le risque de violations de données et maintenir la confiance des clients. Des audits réguliers garantissent le respect continu de ces mesures de sécurité importantes.\n\n### ISO 27000\n\nLa norme [ISO/IEC 27000](https://www.iso.org/fr/standard/iso-iec-27000-family) fournit le cadre fondamental de la famille de normes ISO/IEC 27000 et offre un aperçu complet des systèmes de gestion de la sécurité de l'information. Elle établit un vocabulaire normalisé grâce à des termes et concepts clés qui garantissent une compréhension cohérente entre les organisations dans le domaine de la sécurité de l'information.\n\nLa norme décrit les composants et processus essentiels qui établissent et maintiennent des systèmes de gestion de la sécurité de l'information efficaces. Ces directives permettent aux organisations de gérer systématiquement les risques liés à la sécurité de l'information et protègent les données confidentielles ainsi que la propriété intellectuelle.\n\nL'adhésion à la norme ISO/IEC 27000 permet aux organisations de construire des systèmes de gestion de la sécurité de l'information robustes, de renforcer leur résilience face aux menaces liées à la cybersécurité, de protéger des informations précieuses et de favoriser la confiance des parties prenantes.\n\n> [Découvrez comment GitLab peut vous aider dans votre parcours de conformité à la norme ISO 27001.](https://about.gitlab.com/fr-fr/blog/how-gitlab-can-support-your-iso-compliance-journey/)\n\n### HIPAA\n\nLa loi sur la portabilité et la responsabilité des assurances-maladie [(Health Insurance Portability and Accountability Act, HIPAA)](https://www.hhs.gov/hipaa/index.html) est une législation importante qui a un impact sur le secteur de la santé aux États-Unis. L'objectif principal de la loi HIPAA, adoptée en 1996, est de protéger les informations sensibles de santé des patients contre toute divulgation sans qu'ils n'y aient consenti ou n'en aient connaissance.\n\nIl est essentiel de préserver la confidentialité des patients, de garantir la sécurité des données et de normaliser les transactions électroniques des soins de santé. La loi HIPAA a contraint les prestataires de soins de santé, les assureurs et les entités connexes à mettre en œuvre des mesures strictes de protection des données afin de réduire considérablement l'accès non autorisé aux dossiers médicaux et de renforcer la confiance des patients.\n\n## Normes de conformité mondiales et régionales\n\n### Réglementations nationales/régionales\n\nBien que des normes de conformité comme la loi HIPAA et le RGPD soient connues dans le monde entier, il s'agit respectivement de normes américaines et européennes. Elles influencent d'autres normes régionales dans le monde, mais ne sont requises que pour les entreprises qui traitent des données provenant, par exemple, de l'UE. Plusieurs pays ont des normes de conformité qui doivent être respectées si une entreprise opère dans ces pays. Voici quelques autres normes spécifiques à certains pays :\n\n- [SOX](https://fr.wikipedia.org/wiki/Loi_Sarbanes-Oxley) (États-Unis, sociétés cotées) : Sarbanes-Oxley Act. Cette loi impose une tenue et une déclaration appropriées des documents comptables pour les sociétés cotées.\n\n- [LPRPDE](https://www.priv.gc.ca/fr/sujets-lies-a-la-protection-de-la-vie-privee/lois-sur-la-protection-des-renseignements-personnels-au-canada/la-loi-sur-la-protection-des-renseignements-personnels-et-les-documents-electroniques-lprpde/) (Canada, entreprises commerciales) : Loi sur la protection des renseignements personnels et les documents électroniques. Elle régit la manière dont les organisations du secteur privé collectent, utilisent et divulguent les informations personnelles.\n\n- [PDPA](https://www.pdpc.gov.sg/overview-of-pdpa/the-legislation/personal-data-protection-act) (Singapour, toutes les organisations) : Personal Data Protection Act. Cette loi sur la protection des données personnelles régit la collecte, l'utilisation et la divulgation de données personnelles par les organisations.\n\n- [APPI](https://www.ppc.go.jp/files/pdf/Act_on_the_Protection_of_Personal_Information.pdf) (Japon, tous les secteurs) : Act on the Protection of Personal Information. Cette loi sur la protection des informations personnelles réglemente l'utilisation d'informations personnelles au Japon.\n\n- [LGPD](https://lgpd-brazil.info/) (Brésil, tous les secteurs) : Lei Geral de Proteção de Dados. La loi brésilienne sur la protection des données est similaire au RGPD.\n\n- [FISMA](https://www.cisa.gov/topics/cyber-threats-and-advisories/federal-information-security-modernization-act) (États-Unis, agences fédérales) : Federal Information Security Management Act. Cette loi sur la gestion de la sécurité des informations fédérales définit un cadre pour la gestion de la sécurité de l'information des systèmes d'information fédéraux.\n\n- [POPI Act](https://popia.co.za/) (Afrique du Sud, tous les secteurs) : Protection of Personal Information Act. Cette loi sur la protection des données personnelles promeut la protection des informations personnelles traitées par des organismes publics et privés.\n\n- [PDPA](https://www.pwc.com/th/en/tax/personal-data-protection-act.html) (Thaïlande, tous les secteurs) : Personal Data Protection Act. Comme le RGPD, cette loi sur la protection des données personnelles réglemente la collecte, l'utilisation et la divulgation de données personnelles en Thaïlande.\n\n- [PIPL](https://en.wikipedia.org/wiki/Personal_Information_Protection_Law_of_the_People%27s_Republic_of_China) (Chine, tous les secteurs) : Personal Information Protection Law. La première loi complète sur la protection des données de la Chine est similaire au RGPD.\n\n- [NDPR](https://nitda.gov.ng/wp-content/uploads/2021/01/NDPR-Implementation-Framework.pdf) (Nigeria, tous les secteurs) : Nigeria Data Protection Regulation. Ce règlement sur la protection des données au Nigéria protège les droits des personnes physiques à la confidentialité des données.\n\n- [DIFC Data Protection Law](https://www.difc.ae/business/laws-and-regulations/legal-database/difc-laws/data-protection-law-difc-law-no-5-2020) (Dubaï, entreprises du Dubai International Financial Centre) : cette loi sur la protection des données du DIFC réglemente le traitement des données personnelles dans la zone franche du DIFC.\n\n- [PDPA](https://www.pdp.gov.my/jpdpv2/laws-of-malaysia-pdpa/personal-data-protection-act-2010/?lang=en) (Malaisie, transactions commerciales) : Personal Data Protection Act. Cette loi sur la protection des données personnelles réglemente le traitement des données personnelles dans les transactions commerciales.\n\n- [Privacy Act](https://www.ag.gov.au/rights-and-protections/privacy) (Australie, agences gouvernementales et certaines organisations du secteur privé). Cette loi relative à la confidentialité réglemente la manière dont les informations personnelles sont traitées par les agences gouvernementales australiennes et certaines organisations du secteur privé.\n\n- [KVKK](https://www.kvkk.gov.tr/Icerik/6649/Personal-Data-Protection-Law) (Turquie, tous les secteurs) : Turkish Personal Data Protection Law. La loi sur la protection des données personnelles turque réglemente le traitement des données personnelles et protège les droits individuels.\n\nCes normes reflètent la préoccupation croissante concernant la confidentialité et la sécurité des données. De nombreux pays développent leurs propres frameworks inspirés de réglementations établies comme le RGPD. Chaque norme est adaptée au contexte juridique, culturel et économique spécifique de son pays.\n\n### Normes spécifiques aux secteurs\n\n- [PCI DSS](https://www.pcisecuritystandards.org/lang/fr-fr/) (services financiers) : cette norme s'applique à toutes les organisations qui traitent des informations de cartes de crédit dans le monde entier.\n\n- [ISO 27001](https://www.iso.org/fr/standard/iso-iec-27000-family) (tous les secteurs) : cette norme de système de gestion de la sécurité de l'information fournit un framework pour les pratiques de gestion de la sécurité de l'information.\n\n- [GAMP 5](https://qbdgroup.com/en/blog/gamp-categories/) (secteur pharmaceutique) : Good Automated Manufacturing Practice. Directives pour les systèmes informatiques dans la fabrication pharmaceutique.\n\n- [ISO 13485](https://www.iso.org/fr/standard/59752.html) (dispositifs médicaux) : cette norme précise les exigences d'un système de gestion de la qualité pour les fabricants de dispositifs médicaux.\n\n- [COBIT](https://www.isaca.org/resources/cobit) (gestion informatique) : Control Objectives for Information and Related Technologies. Framework pour la gestion informatique et la gouvernance informatique.\n\n- [ITIL](https://fr.wikipedia.org/wiki/Information_Technology_Infrastructure_Library) (services informatiques) : Information Technology Infrastructure Library. Ensemble de pratiques détaillées pour la gestion des services informatiques.\n\n- [NIST CSF](https://www.nist.gov/cyberframework) (cybersécurité) : National Institute of Standards and Technology Cybersecurity Framework. Conseils pour gérer et réduire les risques liés à la cybersécurité.\n\n- [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/fr) (accessibilité Web) : Web Content Accessibility Guidelines. Ces directives dédiées à l’accessibilité des contenus Web visent à rendre le Web plus accessible aux personnes handicapées.\n\n- [Basel III](https://www.bis.org/bcbs/basel3_fr.htm) (secteur bancaire). Dispositif réglementaire international pour les banques, qui comprend des exigences de gestion des risques informatiques.\n\n- [TISAX](https://portal.enx.com/en-US/TISAX/) (secteur automobile) : Trusted Information Security Assessment Exchange. Mécanisme d'évaluation et d'échange de sécurité de l'information pour l'industrie automobile.\n\nCes normes s'appliquent dans le monde entier à des secteurs spécifiques, et garantissent des pratiques cohérentes et des mesures de sécurité dans leurs domaines respectifs.\n\n## Importance de la conformité continue\n\nLes organisations doivent mettre en œuvre des systèmes qui assurent la conformité aux exigences réglementaires pertinentes. Elles peuvent y parvenir grâce à [la conformité continue des logiciels](https://about.gitlab.com/fr-fr/solutions/compliance/), un principe essentiel à tous les secteurs qui garantit la surveillance, l'évaluation et l'ajustement continus des systèmes, processus et pratiques d'une organisation afin de garantir que ces derniers respectent à tout moment les normes et réglementations pertinentes.\n\nLa conformité continue n'est pas seulement une case à cocher en matière de réglementation, mais une nécessité stratégique pour le développement logiciel aujourd'hui. Elle permet aux organisations de naviguer de manière proactive face aux menaces émergentes, aux changements technologiques et aux évolutions réglementaires, tout en favorisant la confiance des parties prenantes, l'efficacité opérationnelle et l'avantage concurrentiel dans un environnement commercial de plus en plus complexe.\n\n## Conformité réglementaire ou normes auto-imposées ?\n\nLa conformité réglementaire et les normes auto-imposées sont deux approches distinctes de la gouvernance organisationnelle. La conformité réglementaire implique le respect de lois et de réglementations obligatoires établies par des autorités externes, qui ont une portée large et des conséquences juridiques potentielles en cas de non-respect. Elle se concentre sur le respect des exigences légales minimales et est généralement moins flexible. Le RGPD et la loi HIPAA en sont des exemples.\n\nEn revanche, les normes auto-imposées sont des directives volontaires adoptées par les organisations pour améliorer la qualité, la sécurité ou les performances. Elles peuvent être adaptées à des besoins spécifiques et visent généralement à dépasser les exigences minimales. Bien que le non-respect des normes auto-imposées puisse avoir un impact sur la réputation d'une organisation, il n'entraîne généralement pas de conséquences juridiques. Les principales différences résident dans leur origine, leur motivation, leur adaptabilité et leur portée. De nombreuses organisations mettent en œuvre les deux approches pour créer une stratégie complète de gestion de la qualité, de la sécurité et des performances.\n\n## Gestion de la conformité\n\nPour respecter des normes, les organisations doivent évaluer les [indicateurs de conformité](https://advisory.kpmg.us/articles/2018/compliance-metrics.html) appropriés et les intégrer dans leurs procédures opérationnelles standard. L'objectif est de fournir des informations permettant la détection et la prévention précoces des risques de conformité actuels et futurs. La gestion de la conformité doit être efficace et représente bien plus qu'une simple liste de contrôle avec des tâches à effectuer périodiquement ; il s'agit d'un processus continu complet à l'échelle de l'organisation.\n\n## Gestion de la conformité avec GitLab\n\nAvec GitLab, les organisations peuvent créer des [frameworks de conformité](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html), des [politiques de sécurité](https://docs.gitlab.com/ee/user/application_security/policies/) et une [gestion des audits](https://docs.gitlab.com/ee/administration/audit_reports.html). GitLab permet également aux équipes de conformité ou de direction de surveiller les indicateurs de conformité avec les [rapports de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_report/index.html).\n\n### Frameworks et pipelines de conformité\n\nLes organisations peuvent créer un [framework de conformité](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html) qui identifie les projets dans GitLab avec des exigences de conformité définies, qui peuvent être appliquées au moyen de [pipelines de conformité](https://docs.gitlab.com/ee/user/group/compliance_pipelines.html). Par exemple, une entreprise FinTech peut créer un [framework de conformité par défaut](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html#default-compliance-frameworks) pour tous les projets afin de garantir que chaque étape de son cycle de développement logiciel respecte les exigences PCI DSS pour le traitement des données des titulaires de cartes.\n\nCes exigences sont ensuite appliquées en veillant à ce que chaque modification introduite dans le code source soit suffisamment testée automatiquement avec les [fonctionnalités de sécurité des applications](https://docs.gitlab.com/ee/user/application_security/) de GitLab, qui couvrent le code source, les dépendances, les licences, les vulnérabilités dans l'application en cours d'exécution et les configurations d'infrastructure. Vous pouvez en savoir plus sur la façon dont GitLab vous aide à atteindre la conformité PCI et d'autres [normes de conformité réglementaires](https://about.gitlab.com/fr-fr/solutions/continuous-software-compliance/) avec les frameworks de conformité.\n\nLes vidéos suivantes vous aident à configurer et à utiliser des frameworks et pipelines de conformité.\n\n**Tutoriel vidéo : créer des frameworks de conformité**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/IDswzRI-8VQ\" title=\"Comment configurer les frameworks et pipelines de conformité dans GitLab\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Tutoriel vidéo : appliquer des pipelines de conformité**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/jKA_e_jimoI\" title=\"GitLab Compliance Pipelines & Overriding Settings\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Gestion des politiques de sécurité\n\nLes équipes de sécurité et de conformité peuvent utiliser GitLab pour appliquer les exigences de conformité en veillant à ce que des scanners de sécurité s'exécutent dans certains pipelines ou exigent une approbation sur les merge requests lorsque les [politiques de sécurité](https://docs.gitlab.com/ee/user/application_security/policies/) sont enfreintes. GitLab prend en charge les politiques d'[exécution des scans](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) et de [résultats des scans](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html). Ces politiques sont définies dans un [projet de politique de sécurité](https://docs.gitlab.com/ee/user/application_security/policies/#security-policy-project) dédié qui sépare les responsabilités entre les équipes de sécurité et de développement. Les politiques de sécurité peuvent être appliquées de manière granulaire au niveau du groupe, du sous-groupe et du projet. Les politiques peuvent être modifiées en mode règle, qui utilise l'[éditeur de politique](https://docs.gitlab.com/ee/user/application_security/policies/#policy-editor), ou en mode yaml.\n\n#### Politiques d'exécution des scans\n\nLes politiques d'exécution des scans peuvent être configurées pour s'exécuter sur un [GitLab Runner](https://docs.gitlab.com/runner/) spécifié :\n\n- [Test statique de sécurité des applications (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)\n- [Infrastructure as Code](https://docs.gitlab.com/ee/user/application_security/iac_scanning/)\n- [Test dynamique de sécurité des applications (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/)\n- [Détection des secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/)\n- [Analyse des conteneurs](https://docs.gitlab.com/ee/user/application_security/container_scanning/)\n- [Analyse des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\n\nLes jobs de scans peuvent être exécutés selon un calendrier ou chaque fois qu'un pipeline s'exécute. Les équipes de conformité et de sécurité peuvent utiliser les politiques d'exécution des analyses pour vérifier périodiquement et prévenir de manière proactive l'escalade des vulnérabilités dans le cadre d'une stratégie de gestion des vulnérabilités. Elles peuvent également renforcer les contrôles lorsque de nouvelles tendances sont observées à partir des résultats des scans.\n\n**Tutoriel vidéo : configurer des politiques d'analyse de sécurité dans GitLab**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZBcqGmEwORA\" title=\"Comment configurer des politiques des scans de sécurité dans GitLab\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### Politiques de résultats des scans\n\nLes politiques de résultats des scans ajoutent une révision et une approbation requises pour les merge requests lorsque les résultats des analyses de sécurité spécifiées enfreignent les règles des politiques. Par exemple, une politique peut exiger qu'un membre de l'équipe de sécurité prenne des mesures lorsqu'une nouvelle vulnérabilité SAST critique est détectée. De cette façon, les membres des équipes de sécurité et de conformité peuvent venir en aide aux développeurs tout en veillant à ce que les modifications introduites dans la base de code soient sécurisées et respectent les exigences de conformité.\n\n**Tutoriel vidéo : aperçu des politiques de résultats des scans de GitLab**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/w5I9gcUgr9U\" title=\"Aperçu des politiques de résultats des scans de GitLab\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### Politiques d'approbation des licences\n\nLors de la sélection des types de scans pour les règles de politique de résultats des scans, vous pouvez choisir entre le scan de sécurité, le comportement par défaut pour les politiques de résultats d'analyse, et l'analyse de licence, qui aide à garantir la conformité des licences. L'analyse des licences dépend des résultats du job [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/) d'[analyse des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) qui vérifie si les licences identifiées correspondent aux critères spécifiés, puis ajoute des exigences d'approbation avant qu'une merge request ouverte puisse être fusionnée. Cette étape est cruciale pour garantir que seules les dépendances avec des licences approuvées sont utilisées dans votre organisation.\n\n**Démonstration vidéo : politiques d'approbation des licences**\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/34qBQ9t8qO8\" title=\"Démonstration des politiques d'approbation des licences\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Gestion des audits\n\n#### Préparation aux audits\n\nLes audits sont essentiels pour la gestion de la conformité, car ils permettent de comprendre la posture de sécurité et de conformité de votre organisation. Les audits externes requis par les régulateurs sont souvent détaillés et exhaustifs. Pour s'y préparer, les organisations doivent :\n\n- Déterminer les réglementations ou normes qui seront évaluées et les domaines de l'organisation qui seront examinés.\n- Analyser les résultats d'audit passés et s'assurer que tous les problèmes précédemment identifiés ont été résolus.\n- Collecter toutes les politiques, procédures et dossiers pertinents qui démontrent la conformité.\n- Effectuer un audit interne avant l'audit officiel pour identifier et combler toute lacune de conformité potentielle.\n- Informer les employés du processus d'audit et de leurs rôles. Effectuer une formation si nécessaire.\n- S'assurer que toute la documentation requise est facilement accessible et bien organisée.\n- Veiller à ce que toutes les politiques et procédures liées à la conformité soient à jour et alignées sur les réglementations actuelles.\n- Vérifier que toutes les mesures de protection techniques et tous les contrôles sont en place et fonctionnent correctement.\n- Identifier le personnel clé qui pourrait être interrogé et le briefer sur les questions potentielles.\n- Traiter les problèmes connus : s'il existe des problèmes de conformité connus, élaborer et documenter des plans d'action pour y remédier.\n\nPour faciliter votre préparation, les [événements d'audit](https://docs.gitlab.com/ee/administration/audit_events.html) et le [Centre de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/index.html) de GitLab offrent une vue détaillée de la conformité de l'organisation.\n\n#### Utilisation efficace des journaux d'audit GitLab\n\nLes [événements d'audit](https://docs.gitlab.com/ee/administration/audit_events.html) vous permettent de connaître chaque action effectuée sur l'instance GitLab. Les rapports d'audit indiquent chaque événement significatif avec son auteur et le moment où il a été effectué. Vous pouvez également générer des rapports détaillés à partir des événements d'audit en utilisant les [rapports d'audit](https://docs.gitlab.com/ee/administration/audit_reports.html), ce qui vous permet de prouver votre conformité aux auditeurs ou aux régulateurs.\n\n![Événements d'audit](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098755/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098755493.png)\n\n[Le Centre de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_report/index.html#compliance-violations-report) est un composant important de la gestion des audits dans GitLab qui offre une visibilité sur la posture de conformité de votre organisation. Les rapports de conformité détaillent chaque violation découverte avec le [rapport sur les violations de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_violations_report.html) et les frameworks utilisés par les projets au sein de votre organisation avec le [rapport sur les frameworks de conformité](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_frameworks_report.html).\n\n![Respect des exigences réglementaires – image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098756/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098755493.png)\n\n\u003Ccenter>\u003Ci>Exemple d'un rapport sur les violations de conformité d'un groupe GitLab parent\u003C/i>\u003C/center>\n\n![Respect des exigences réglementaires – image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098755/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098755495.png)\n\n\u003Ccenter>\u003Ci>Exemple d'un rapport de framework de conformité pour tous les projets dans un groupe\u003C/i>\u003C/center>\n\n#### Streaming des événements d'audit\n\nLa plupart des organisations disposent de systèmes pour surveiller les activités dans leurs systèmes en temps réel. Avec le [streaming des événements d'audit](https://docs.gitlab.com/ee/administration/audit_event_streaming/index.html) de GitLab, vous pouvez intégrer des solutions tierces comme Splunk pour la surveillance d'infrastructure ou DataDog pour la surveillance des flux afin d'obtenir des analyses des événements d'audit en temps réel. Toutes les données d'événements d'audit sont envoyées à la destination de streaming (il est essentiel de diffuser vers un service de confiance). Le streaming des événements d'audit peut être [configuré au niveau des groupes principaux](https://docs.gitlab.com/ee/administration/audit_event_streaming/index.html#top-level-group-streaming-destinations) et au [niveau de l'instance](https://docs.gitlab.com/ee/administration/audit_event_streaming/#instance-streaming-destinations) pour les instances GitLab autogérées.\n\n## Bonnes pratiques pour la gestion de la conformité\n\nVoici quelques bonnes pratiques pour une gestion efficace de la conformité :\n\n- Établissez une solide culture de conformité qui favorise la sensibilisation à la conformité au sein de l'organisation et garantit l'engagement et le soutien de la direction.\n- Développez un programme de conformité complet avec des politiques et procédures claires et révisez-le régulièrement pour refléter les changements réglementaires.\n- Mettez en œuvre l'évaluation et la gestion des risques pour identifier et évaluer régulièrement les risques de conformité, en hiérarchisant les risques en fonction de l'impact potentiel et de la probabilité.\n- Organisez régulièrement des formations sur la conformité adaptée aux rôles et responsabilités spécifiques pour tous les employés.\n- Mettez en œuvre une gestion de la conformité pour automatiser la surveillance de la conformité et les rapports de conformité dans la mesure du possible.\n- Effectuez des audits internes pour identifier les lacunes et les domaines d'amélioration. Il est également essentiel de considérer les audits externes de manière impartiale et d'utiliser les résultats d'audit pour affiner et améliorer les processus de conformité.\n- Tenez-vous informé des changements réglementaires en assignant à une personne ou équipe la surveillance des mises à jour réglementaires et en rejoignant des associations ou en participant à des forums du secteur.\n- Intégrez la conformité dans les processus métier, intégrez des contrôles de conformité dans les workflows opérationnels et prenez en compte la conformité dans la prise de décision stratégique. Alignez les objectifs de conformité avec les objectifs commerciaux.\n- Développez des plans de réponse pour les violations potentielles de conformité et effectuez des scénarios fictifs pour tester la préparation aux incidents et violations.\n\n## En savoir plus\n\nLa conformité est un processus continu de gestion efficace des risques, qui implique la mise en œuvre de garde-fous et la surveillance des indicateurs de conformité. GitLab permet aux organisations de respecter les normes réglementaires avec des fonctionnalités de [gestion de la conformité](https://about.gitlab.com/fr-fr/solutions/compliance/). Avec GitLab, vous pouvez améliorer l'expérience de la chaîne d'approvisionnement logicielle, créer des logiciels plus sécurisés plus rapidement et maintenir la confiance de vos utilisateurs, de vos clients et de votre communauté.\n\n> Pour en savoir plus sur la conformité et la gestion des politiques de sécurité, consultez le [tutoriel GitLab DevSecOps](https://gitlab-da.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/), qui couvre le cycle de vie complet de la sécurité des applications dans GitLab.\n\n## Pour aller plus loin\n\n- [GitLab Dedicated pour le secteur public](https://about.gitlab.com/blog/introducing-gitlab-dedicated-for-government/)\n- [Comment garantir la séparation des tâches et appliquer la conformité avec GitLab](https://about.gitlab.com/fr-fr/blog/ensuring-compliance/)\n- [Accès avec le principe de moindre privilège avec GitLab : notre guide](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/)","La conformité est un processus continu de gestion des risques qui requiert la mise en œuvre de garde-fous et le suivi d'indicateurs spécifiques. Découvrez la marche à suivre dans ce guide complet.","Sécurité et conformité : respectez les normes réglementaires avec GitLab","yml",{},true,"/fr-fr/blog/meet-regulatory-standards-with-gitlab",{"config":31,"ogImage":21,"description":32,"title":33},{"noIndex":11},"La conformité requiert la mise en œuvre de garde-fous et le suivi d'indicateurs spécifiques. Découvrez la marche à suivre dans ce guide complet.","Sécurité et conformité : respect des normes avec GitLab","fr-fr/blog/meet-regulatory-standards-with-gitlab",[36,37,9,38],"devsecops","devsecops-platform","public-sector","smeuLSFou7qMSj3ty6ot4pi4mDNUFrXXvba57uEA9cQ",{"data":41},{"logo":42,"freeTrial":47,"sales":52,"login":57,"items":62,"search":371,"minimal":406,"duo":425,"pricingDeployment":434},{"config":43},{"href":44,"dataGaName":45,"dataGaLocation":46},"/fr-fr/","gitlab logo","header",{"text":48,"config":49},"Commencer un essai gratuit",{"href":50,"dataGaName":51,"dataGaLocation":46},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr&glm_content=default-saas-trial/","free trial",{"text":53,"config":54},"Contacter l'équipe commerciale",{"href":55,"dataGaName":56,"dataGaLocation":46},"/fr-fr/sales/","sales",{"text":58,"config":59},"Connexion",{"href":60,"dataGaName":61,"dataGaLocation":46},"https://gitlab.com/users/sign_in/","sign in",[63,90,186,191,292,352],{"text":64,"config":65,"cards":67},"Plateforme",{"dataNavLevelOne":66},"platform",[68,74,82],{"title":64,"description":69,"link":70},"La plateforme d'orchestration intelligente pour le DevSecOps",{"text":71,"config":72},"Découvrir notre plateforme",{"href":73,"dataGaName":66,"dataGaLocation":46},"/fr-fr/platform/",{"title":75,"description":76,"link":77},"GitLab Duo Agent Platform","L'IA agentique pour l'ensemble du cycle de développement logiciel",{"text":78,"config":79},"Découvrir GitLab Duo",{"href":80,"dataGaName":81,"dataGaLocation":46},"/fr-fr/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":83,"description":84,"link":85},"Choisir GitLab","Découvrez les principales raisons pour lesquelles les entreprises choisissent GitLab",{"text":86,"config":87},"En savoir plus",{"href":88,"dataGaName":89,"dataGaLocation":46},"/fr-fr/why-gitlab/","why gitlab",{"text":91,"left":28,"config":92,"link":94,"lists":98,"footer":169},"Produit",{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"Voir toutes les solutions",{"href":97,"dataGaName":93,"dataGaLocation":46},"/fr-fr/solutions/",[99,124,147],{"title":100,"description":101,"link":102,"items":107},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":46},"AutomatedCodeAlt","/fr-fr/solutions/delivery-automation/","automated software delivery",[108,112,115,120],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":46,"dataGaName":109},"/fr-fr/solutions/continuous-integration/",{"text":75,"config":113},{"href":80,"dataGaLocation":46,"dataGaName":114},"gitlab duo agent platform - product menu",{"text":116,"config":117},"Gestion du code source",{"href":118,"dataGaLocation":46,"dataGaName":119},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":121,"config":122},"Livraison de logiciels automatisée",{"href":105,"dataGaLocation":46,"dataGaName":123},"Automated software delivery",{"title":125,"description":126,"link":127,"items":132},"Sécurité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":46,"icon":131},"/fr-fr/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[133,137,142],{"text":134,"config":135},"Tests de sécurité des applications",{"href":129,"dataGaName":136,"dataGaLocation":46},"Application security testing",{"text":138,"config":139},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":140,"dataGaLocation":46,"dataGaName":141},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":143,"config":144},"Conformité logicielle",{"href":145,"dataGaName":146,"dataGaLocation":46},"/fr-fr/solutions/software-compliance/","Software Compliance",{"title":148,"link":149,"items":154},"Mesures",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":46},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"Visibilité et mesures",{"href":152,"dataGaLocation":46,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"Gestion de la chaîne de valeur",{"href":162,"dataGaLocation":46,"dataGaName":163},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"Données d'analyse et informations clés",{"href":167,"dataGaLocation":46,"dataGaName":168},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLab pour",[172,177,182],{"text":173,"config":174},"Entreprises",{"href":175,"dataGaLocation":46,"dataGaName":176},"/fr-fr/enterprise/","enterprise",{"text":178,"config":179},"PME",{"href":180,"dataGaLocation":46,"dataGaName":181},"/fr-fr/small-business/","small business",{"text":183,"config":184},"Secteur public",{"href":185,"dataGaLocation":46,"dataGaName":18},"/fr-fr/solutions/public-sector/",{"text":187,"config":188},"Tarifs",{"href":189,"dataGaName":190,"dataGaLocation":46,"dataNavLevelOne":190},"/fr-fr/pricing/","pricing",{"text":192,"config":193,"link":195,"lists":199,"feature":279},"Ressources",{"dataNavLevelOne":194},"resources",{"text":196,"config":197},"Afficher toutes les ressources",{"href":198,"dataGaName":194,"dataGaLocation":46},"/fr-fr/resources/",[200,233,251],{"title":201,"items":202},"Premiers pas",[203,208,213,218,223,228],{"text":204,"config":205},"Installation",{"href":206,"dataGaName":207,"dataGaLocation":46},"/fr-fr/install/","install",{"text":209,"config":210},"Guides de démarrage",{"href":211,"dataGaName":212,"dataGaLocation":46},"/fr-fr/get-started/","quick setup checklists",{"text":214,"config":215},"Apprentissage",{"href":216,"dataGaLocation":46,"dataGaName":217},"https://university.gitlab.com/","learn",{"text":219,"config":220},"Documentation sur le produit",{"href":221,"dataGaName":222,"dataGaLocation":46},"https://docs.gitlab.com/","product documentation",{"text":224,"config":225},"Vidéos sur les bonnes pratiques",{"href":226,"dataGaName":227,"dataGaLocation":46},"/fr-fr/getting-started-videos/","best practice videos",{"text":229,"config":230},"Intégrations",{"href":231,"dataGaName":232,"dataGaLocation":46},"/fr-fr/integrations/","integrations",{"title":234,"items":235},"Découvrir",[236,241,246],{"text":237,"config":238},"Témoignages clients",{"href":239,"dataGaName":240,"dataGaLocation":46},"/fr-fr/customers/","customer success stories",{"text":242,"config":243},"Blog",{"href":244,"dataGaName":245,"dataGaLocation":46},"/fr-fr/blog/","blog",{"text":247,"config":248},"Travail à distance",{"href":249,"dataGaName":250,"dataGaLocation":46},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":252,"items":253},"Connecter",[254,259,264,269,274],{"text":255,"config":256},"Services GitLab",{"href":257,"dataGaName":258,"dataGaLocation":46},"/fr-fr/services/","services",{"text":260,"config":261},"Communauté",{"href":262,"dataGaName":263,"dataGaLocation":46},"/community/","community",{"text":265,"config":266},"Forum",{"href":267,"dataGaName":268,"dataGaLocation":46},"https://forum.gitlab.com/","forum",{"text":270,"config":271},"Événements",{"href":272,"dataGaName":273,"dataGaLocation":46},"/events/","events",{"text":275,"config":276},"Partenaires",{"href":277,"dataGaName":278,"dataGaLocation":46},"/fr-fr/partners/","partners",{"backgroundColor":280,"textColor":281,"text":282,"image":283,"link":287},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":284,"config":285},"carte promo The Source",{"src":286},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":288,"config":289},"Lire les articles les plus récents",{"href":290,"dataGaName":291,"dataGaLocation":46},"/fr-fr/the-source/","the source",{"text":293,"config":294,"lists":296},"Société",{"dataNavLevelOne":295},"company",[297],{"items":298},[299,304,310,312,317,322,327,332,337,342,347],{"text":300,"config":301},"À propos",{"href":302,"dataGaName":303,"dataGaLocation":46},"/fr-fr/company/","about",{"text":305,"config":306,"footerGa":309},"Carrières",{"href":307,"dataGaName":308,"dataGaLocation":46},"/jobs/","jobs",{"dataGaName":308},{"text":270,"config":311},{"href":272,"dataGaName":273,"dataGaLocation":46},{"text":313,"config":314},"Leadership",{"href":315,"dataGaName":316,"dataGaLocation":46},"/company/team/e-group/","leadership",{"text":318,"config":319},"Équipe",{"href":320,"dataGaName":321,"dataGaLocation":46},"/company/team/","team",{"text":323,"config":324},"Manuel",{"href":325,"dataGaName":326,"dataGaLocation":46},"https://handbook.gitlab.com/","handbook",{"text":328,"config":329},"Relations avec les investisseurs",{"href":330,"dataGaName":331,"dataGaLocation":46},"https://ir.gitlab.com/","investor relations",{"text":333,"config":334},"Centre de confiance",{"href":335,"dataGaName":336,"dataGaLocation":46},"/fr-fr/security/","trust center",{"text":338,"config":339},"Centre pour la transparence de l'IA",{"href":340,"dataGaName":341,"dataGaLocation":46},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":343,"config":344},"Newsletter",{"href":345,"dataGaName":346,"dataGaLocation":46},"/company/contact/#contact-forms","newsletter",{"text":348,"config":349},"Presse",{"href":350,"dataGaName":351,"dataGaLocation":46},"/press/","press",{"text":353,"config":354,"lists":355},"Nous contacter",{"dataNavLevelOne":295},[356],{"items":357},[358,361,366],{"text":53,"config":359},{"href":55,"dataGaName":360,"dataGaLocation":46},"talk to sales",{"text":362,"config":363},"Portail d’assistance",{"href":364,"dataGaName":365,"dataGaLocation":46},"https://support.gitlab.com","support portal",{"text":367,"config":368},"Portail clients GitLab",{"href":369,"dataGaName":370,"dataGaLocation":46},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":372,"login":373,"suggestions":380},"Fermer",{"text":374,"link":375},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":376,"config":377},"gitlab.com",{"href":60,"dataGaName":378,"dataGaLocation":379},"search login","search",{"text":381,"default":382},"Suggestions",[383,385,390,392,397,402],{"text":75,"config":384},{"href":80,"dataGaName":75,"dataGaLocation":379},{"text":386,"config":387},"Suggestions de code (IA)",{"href":388,"dataGaName":389,"dataGaLocation":379},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":391},{"href":111,"dataGaName":109,"dataGaLocation":379},{"text":393,"config":394},"GitLab sur AWS",{"href":395,"dataGaName":396,"dataGaLocation":379},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":398,"config":399},"GitLab sur Google Cloud ",{"href":400,"dataGaName":401,"dataGaLocation":379},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":403,"config":404},"Pourquoi utiliser GitLab ?",{"href":88,"dataGaName":405,"dataGaLocation":379},"Why GitLab?",{"freeTrial":407,"mobileIcon":412,"desktopIcon":417,"secondaryButton":420},{"text":408,"config":409},"Commencer votre essai gratuit",{"href":410,"dataGaName":51,"dataGaLocation":411},"https://gitlab.com/-/trials/new/","nav",{"altText":413,"config":414},"Icône GitLab",{"src":415,"dataGaName":416,"dataGaLocation":411},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":413,"config":418},{"src":419,"dataGaName":416,"dataGaLocation":411},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":421,"config":422},"Commencer",{"href":423,"dataGaName":424,"dataGaLocation":411},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/fr-fr/get-started/","get started",{"freeTrial":426,"mobileIcon":430,"desktopIcon":432},{"text":427,"config":428},"En savoir plus sur GitLab Duo",{"href":80,"dataGaName":429,"dataGaLocation":411},"gitlab duo",{"altText":413,"config":431},{"src":415,"dataGaName":416,"dataGaLocation":411},{"altText":413,"config":433},{"src":419,"dataGaName":416,"dataGaLocation":411},{"freeTrial":435,"mobileIcon":440,"desktopIcon":442},{"text":436,"config":437},"Retour aux tarifs",{"href":189,"dataGaName":438,"dataGaLocation":411,"icon":439},"back to pricing","GoBack",{"altText":413,"config":441},{"src":415,"dataGaName":416,"dataGaLocation":411},{"altText":413,"config":443},{"src":419,"dataGaName":416,"dataGaLocation":411},{"title":445,"button":446,"config":451},"Découvrez comment l'IA agentique transforme la livraison logicielle",{"text":447,"config":448},"Regarder GitLab Transcend maintenant",{"href":449,"dataGaName":450,"dataGaLocation":46},"/fr-fr/events/transcend/virtual/","transcend event",{"layout":452,"icon":453,"disabled":28},"release","AiStar",{"data":455},{"text":456,"source":457,"edit":463,"contribute":468,"config":473,"items":478,"minimal":655},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":458,"config":459},"Afficher le code source de la page",{"href":460,"dataGaName":461,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":464,"config":465},"Modifier cette page",{"href":466,"dataGaName":467,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":469,"config":470},"Veuillez contribuer",{"href":471,"dataGaName":472,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":474,"facebook":475,"youtube":476,"linkedin":477},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[479,502,556,588,623],{"title":64,"links":480,"subMenu":485},[481],{"text":482,"config":483},"Plateforme DevSecOps",{"href":73,"dataGaName":484,"dataGaLocation":462},"devsecops platform",[486],{"title":187,"links":487},[488,492,497],{"text":489,"config":490},"Voir les forfaits",{"href":189,"dataGaName":491,"dataGaLocation":462},"view plans",{"text":493,"config":494},"Pourquoi choisir GitLab Premium ?",{"href":495,"dataGaName":496,"dataGaLocation":462},"/fr-fr/pricing/premium/","why premium",{"text":498,"config":499},"Pourquoi choisir GitLab Ultimate ?",{"href":500,"dataGaName":501,"dataGaLocation":462},"/fr-fr/pricing/ultimate/","why ultimate",{"title":503,"links":504},"Solutions",[505,510,513,515,520,525,529,532,535,540,542,544,546,551],{"text":506,"config":507},"Transformation digitale",{"href":508,"dataGaName":509,"dataGaLocation":462},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":511,"config":512},"Sécurité et conformité",{"href":129,"dataGaName":136,"dataGaLocation":462},{"text":121,"config":514},{"href":105,"dataGaName":106,"dataGaLocation":462},{"text":516,"config":517},"Développement agile",{"href":518,"dataGaName":519,"dataGaLocation":462},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":521,"config":522},"Transformation cloud",{"href":523,"dataGaName":524,"dataGaLocation":462},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":526,"config":527},"SCM",{"href":118,"dataGaName":528,"dataGaLocation":462},"source code management",{"text":109,"config":530},{"href":111,"dataGaName":531,"dataGaLocation":462},"continuous integration & delivery",{"text":160,"config":533},{"href":162,"dataGaName":534,"dataGaLocation":462},"value stream management",{"text":536,"config":537},"GitOps",{"href":538,"dataGaName":539,"dataGaLocation":462},"/fr-fr/solutions/gitops/","gitops",{"text":173,"config":541},{"href":175,"dataGaName":176,"dataGaLocation":462},{"text":178,"config":543},{"href":180,"dataGaName":181,"dataGaLocation":462},{"text":183,"config":545},{"href":185,"dataGaName":18,"dataGaLocation":462},{"text":547,"config":548},"Formation",{"href":549,"dataGaName":550,"dataGaLocation":462},"/fr-fr/solutions/education/","education",{"text":552,"config":553},"Services financiers",{"href":554,"dataGaName":555,"dataGaLocation":462},"/fr-fr/solutions/finance/","financial services",{"title":192,"links":557},[558,560,563,565,568,570,573,576,578,580,582,584,586],{"text":204,"config":559},{"href":206,"dataGaName":207,"dataGaLocation":462},{"text":561,"config":562},"Guides de démarrage rapide",{"href":211,"dataGaName":212,"dataGaLocation":462},{"text":214,"config":564},{"href":216,"dataGaName":217,"dataGaLocation":462},{"text":219,"config":566},{"href":221,"dataGaName":567,"dataGaLocation":462},"docs",{"text":242,"config":569},{"href":244,"dataGaName":245},{"text":571,"config":572},"Histoires de réussite client",{"href":239,"dataGaLocation":462},{"text":574,"config":575},"Histoires de succès client",{"href":239,"dataGaName":240,"dataGaLocation":462},{"text":247,"config":577},{"href":249,"dataGaName":250,"dataGaLocation":462},{"text":255,"config":579},{"href":257,"dataGaName":258,"dataGaLocation":462},{"text":260,"config":581},{"href":262,"dataGaName":263,"dataGaLocation":462},{"text":265,"config":583},{"href":267,"dataGaName":268,"dataGaLocation":462},{"text":270,"config":585},{"href":272,"dataGaName":273,"dataGaLocation":462},{"text":275,"config":587},{"href":277,"dataGaName":278,"dataGaLocation":462},{"title":293,"links":589},[590,592,595,597,599,601,603,607,612,614,616,618],{"text":300,"config":591},{"href":302,"dataGaName":295,"dataGaLocation":462},{"text":593,"config":594},"Emplois",{"href":307,"dataGaName":308,"dataGaLocation":462},{"text":313,"config":596},{"href":315,"dataGaName":316,"dataGaLocation":462},{"text":318,"config":598},{"href":320,"dataGaName":321,"dataGaLocation":462},{"text":323,"config":600},{"href":325,"dataGaName":326,"dataGaLocation":462},{"text":328,"config":602},{"href":330,"dataGaName":331,"dataGaLocation":462},{"text":604,"config":605},"Sustainability",{"href":606,"dataGaName":604,"dataGaLocation":462},"/sustainability/",{"text":608,"config":609},"Diversité, inclusion et appartenance (DIB)",{"href":610,"dataGaName":611,"dataGaLocation":462},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":333,"config":613},{"href":335,"dataGaName":336,"dataGaLocation":462},{"text":343,"config":615},{"href":345,"dataGaName":346,"dataGaLocation":462},{"text":348,"config":617},{"href":350,"dataGaName":351,"dataGaLocation":462},{"text":619,"config":620},"Déclaration de transparence sur l'esclavage moderne",{"href":621,"dataGaName":622,"dataGaLocation":462},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":353,"links":624},[625,628,633,635,640,645,650],{"text":626,"config":627},"Échanger avec un expert",{"href":55,"dataGaName":56,"dataGaLocation":462},{"text":629,"config":630},"Aide",{"href":631,"dataGaName":632,"dataGaLocation":462},"https://support.gitlab.com/hc/en-us/articles/11626483177756-GitLab-Support","get help",{"text":367,"config":634},{"href":369,"dataGaName":370,"dataGaLocation":462},{"text":636,"config":637},"Statut",{"href":638,"dataGaName":639,"dataGaLocation":462},"https://status.gitlab.com/","status",{"text":641,"config":642},"Conditions d'utilisation",{"href":643,"dataGaName":644},"/terms/","terms of use",{"text":646,"config":647},"Déclaration de confidentialité",{"href":648,"dataGaName":649,"dataGaLocation":462},"/fr-fr/privacy/","privacy statement",{"text":651,"config":652},"Préférences en matière de cookies",{"dataGaName":653,"dataGaLocation":462,"id":654,"isOneTrustButton":28},"cookie preferences","ot-sdk-btn",{"items":656},[657,659,662],{"text":641,"config":658},{"href":643,"dataGaName":644,"dataGaLocation":462},{"text":660,"config":661},"Politique de confidentialité",{"href":648,"dataGaName":649,"dataGaLocation":462},{"text":651,"config":663},{"dataGaName":653,"dataGaLocation":462,"id":654,"isOneTrustButton":28},[665],{"id":666,"title":20,"body":8,"config":667,"content":669,"description":8,"extension":26,"meta":673,"navigation":28,"path":674,"seo":675,"stem":676,"__hash__":677},"blogAuthors/en-us/blog/authors/abubakar-siddiq-ango.yml",{"template":668},"BlogAuthor",{"name":20,"config":670},{"headshot":671,"ctfId":672},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660104/Blog/Author%20Headshots/abuango-headshot.jpg","abuango",{},"/en-us/blog/authors/abubakar-siddiq-ango",{},"en-us/blog/authors/abubakar-siddiq-ango","u5Jv4JxCpfmcGQuXEU4Lr5xVBJP9LAB2NkXRMLeYwPE",[679,692,706],{"content":680,"config":690},{"tags":681,"category":9,"body":683,"date":684,"heroImage":685,"authors":686,"description":688,"title":689},[9,682],"tutorial","Les vulnérabilités dans les conteneurs n'attendent pas votre prochain\ndéploiement. Elles peuvent apparaître à tout moment, de la création d'une\nimage à l'exécution des conteneurs en production. Pour remédier à ce\nproblème, GitLab propose plusieurs approches d'analyse des conteneurs,\nchacune conçue pour une étape spécifique du cycle de développement logiciel ([SDLC](https://about.gitlab.com/fr-fr/blog/what-is-sdlc/ \"Qu'est-ce que le SDLC ?\")).\n\n\nDans ce guide, nous explorons les différents types d'analyse de conteneurs proposés par GitLab, vous expliquons comment les activer et vous partageons les configurations les plus courantes pour bien démarrer.\n\n\n## Qu'est-ce que l'analyse des conteneurs ? \n\n\nLes vulnérabilités de sécurité présentes dans les images de conteneurs constituent un risque tout au long du cycle de vie applicatif. Les images de base, les paquets de systèmes d'exploitation et les dépendances applicatives peuvent tous receler des vulnérabilités activement exploitées par des attaquants. L'analyse des conteneurs permet de détecter ces risques en amont, avant qu'ils n'atteignent l'environnement de production, et propose des pistes de remédiation le cas échéant.\n\n\nL'analyse des conteneurs est un élément essentiel de l'analyse de la composition logicielle (SCA), qui vous aide à comprendre et à sécuriser les dépendances externes dont vos applications conteneurisées dépendent.\n\n\n## 5 types d'analyses de conteneurs dans GitLab\n\n\nGitLab propose cinq approches distinctes d'analyse de conteneurs, chacune répondant à un objectif précis dans votre stratégie de sécurité.\n\n\n### 1. Analyse des conteneurs dans le pipeline\n\n\n* Fonctionnement : analyse les images de conteneurs lors de l'exécution du [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") afin de détecter les vulnérabilités avant le déploiement\n\n* Cas d'utilisation idéal : contrôles de sécurité en amont (shift-left) pour bloquer les images vulnérables avant qu'elles n'atteignent la production\n\n* Disponibilité : version gratuite de GitLab, GitLab Premium et GitLab Ultimate (avec des fonctionnalités supplémentaires dans GitLab Ultimate)\n\n* [Documentation](https://docs.gitlab.com/user/application_security/container_scanning/)\n\n\nGitLab utilise le scanner de sécurité Trivy pour analyser les images de conteneurs et rechercher de vulnérabilités connues. Lors de l'exécution du pipeline, le scanner examine vos images et génère un rapport détaillé.\n\n\n#### Activer l'analyse des conteneurs dans le pipeline\n\n\n**Option A : merge request préconfigurée**\n\n\n* Accédez à **Sécurisation > Configuration de la sécurité** dans votre projet.\n\n* Repérez la ligne « Analyse de conteneurs ».\n\n* Sélectionnez **Configurer avec une merge request**.\n\n* Une merge request intégrant la configuration nécessaire est automatiquement créée.\n\n\n**Option B : configuration manuelle**\n\n\n* Ajoutez le contenu suivant à votre fichier `.gitlab-ci.yml` :\n\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n```  \n\n\n#### Configurations courantes\n\n\n**Analyser une image spécifique :**\n\n\nPour analyser une image spécifique, remplacez la variable `CS_IMAGE` dans le job `container_scanning`.\n\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\ncontainer_scanning:\n  variables:\n    CS_IMAGE: myregistry.com/myapp:latest\n```\n\n\n**Filtrer par seuil de gravité :**\n\n\nPour n'afficher que les vulnérabilités dépassant un certain niveau de gravité, remplacez la variable `CS_SEVERITY_THRESHOLD` dans le job `container_scanning`. Dans l'exemple ci-dessous, seules les vulnérabilités d'un niveau de gravité **Élevé** ou supérieur seront affichées.\n\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\ncontainer_scanning:\n  variables:\n    CS_SEVERITY_THRESHOLD: \"HIGH\"\n```\n\n\n#### Consulter les vulnérabilités dans une merge request\n\n\nL'affichage direct des vulnérabilités détectées par l'analyse des conteneurs au sein des merge requests rend les revues de sécurité plus fluides et plus efficaces. Une fois l'analyse des conteneurs configurée dans votre pipeline CI/CD, GitLab affiche automatiquement les vulnérabilités détectées dans le [widget Sécurité](https://docs.gitlab.com/user/project/merge_requests/widgets/#application-security-scanning) de la merge request.\n\n\n![Vulnérabilités détectées lors de l'analyse des conteneurs affichées dans la merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/lt6elcq6jexdhqatdy8l.png \"Vulnérabilités détectées lors de l'analyse des conteneurs affichées dans la merge request\")\n\n\n* Accédez à n'importe quelle merge request et faites défiler jusqu'à la section « Analyse de sécurité » pour obtenir un résumé des vulnérabilités nouvellement introduites et existantes détectées dans vos images de conteneurs.\n\n* Cliquez sur une **vulnérabilité** pour accéder à des informations détaillées, notamment le niveau de gravité, les paquets affectés et les recommandations de remédiation disponibles.\n\n\n![GitLab Security – détails dans la merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/hplihdlekc11uvpfih1p.png)\n\n\n![GitLab Security – détails dans la merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/jnxbe7uld8wfeezboifs.png \"Détails d'une vulnérabilité détectée par l'analyse des conteneurs dans la merge request\")\n\n\nCette visibilité permet aux équipes de développement et de sécurité de détecter et de traiter les vulnérabilités des conteneurs avant qu'elles n'atteignent la production : la sécurité devient une composante à part entière du processus de revue de code plutôt qu'un contrôle distinct.\n\n\n#### Consulter les vulnérabilités dans le rapport de vulnérabilités\n\n\nAu-delà des revues dans les merge requests, GitLab met à disposition un [rapport de vulnérabilités](https://docs.gitlab.com/user/application_security/vulnerability_report/) centralisé, qui offre aux équipes de sécurité une visibilité complète sur l'ensemble des résultats de l'analyse des conteneurs dans votre projet.\n\n\n![Rapport de vulnérabilités avec classement selon l'analyse des conteneurs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547524/gagau279fzfgjpnvipm5.png \"Rapport de vulnérabilités avec classement selon l'analyse des conteneurs\")\n\n\n* Accédez à ce rapport via **Sécurité et conformité > Rapport de vulnérabilités** dans la barre latérale de votre projet.\n\n* Vous y trouverez une vue agrégée de toutes les vulnérabilités de conteneurs détectées dans vos branches, avec des options de filtrage permettant de trier les vulnérabilités par gravité, statut, type de scanner ou image de conteneur spécifique.\n\n* Cliquez sur une vulnérabilité pour accéder à sa page dédiée.\n\n\n![Page de vulnérabilité – vue 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547520/e1woxupyoajhrpzrlylj.png)\n\n\n![Page de vulnérabilité – vue 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547521/idzcftcgjc8eryixnbjn.png)\n\n\n![Page de vulnérabilité – vue 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547522/mbbwbbprtf9anqqola10.png \"Détails d'une vulnérabilité détectée par l'analyse des conteneurs\")\n\n\nLes [détails de la vulnérabilité](https://docs.gitlab.com/user/application_security/vulnerabilities/) indiquent précisément les images et couches de conteneurs concernées pour faciliter la traçabilité jusqu'à la source du problème. Vous pouvez assigner des vulnérabilités à des membres de l'équipe, modifier leur statut (détectée, confirmée, résolue, rejetée), ajouter des commentaires pour faciliter la collaboration et associer des tickets connexes pour suivre la remédiation.\n\n\nCe workflow transforme la [gestion des vulnérabilités](https://about.gitlab.com/fr-fr/blog/what-is-vulnerability-management/ \"Qu'est-ce que la gestion des vulnérabilités ?\"), autrefois cantonnée à des tableurs, en une composante intégrée de votre processus de développement, garantissant que les résultats de sécurité des conteneurs sont suivis, priorisés et résolus de manière systématique.\n\n\n#### Consulter la liste des dépendances\n\n\nLa [liste des dépendances](https://docs.gitlab.com/user/application_security/dependency_list/) de GitLab fournit une nomenclature logicielle complète ([SBOM](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/ \"Qu'est-ce qu'une SBOM ?\")) qui répertorie chaque composant de vos images de conteneurs afin d'offrir une transparence totale sur votre [chaîne d'approvisionnement logicielle](https://about.gitlab.com/fr-fr/blog/software-supply-chain-security-guide-why-organizations-struggle/).\n\n\n* Accédez à **Sécurité et conformité > Liste des dépendances** pour consulter l'inventaire de tous les paquets, bibliothèques et dépendances détectés par l'analyse des conteneurs dans votre projet.\n\n* Cet affichage répertorie les éléments qui s'exécutent réellement dans vos conteneurs, des paquets du système d'exploitation de base aux dépendances applicatives.\n\n\n![Liste des dépendances de GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/vjg6dk3nhajqamplroji.png \"Liste des dépendances de GitLab (SBOM)\")\n\n\nVous pouvez filtrer la liste par gestionnaire de paquets, type de licence ou statut de vulnérabilité afin d'identifier rapidement les composants qui présentent des risques de sécurité ou des problèmes de conformité. Chaque entrée de dépendance affiche les vulnérabilités associées pour traiter les problèmes de sécurité dans le contexte des composants logiciels réels, plutôt que comme des résultats isolés.\n\n\n### 2. Analyse des conteneurs pour le registre\n\n\n* Fonctionnement : analyse automatiquement les images envoyées vers le registre de conteneurs de GitLab (GitLab Container Registry) avec le tag `latest`\n\n* Cas d'utilisation idéal : surveillance continue des images du registre, sans déclenchement manuel du pipeline\n\n* Disponibilité : GitLab Ultimate uniquement\n\n* [Documentation](https://docs.gitlab.com/user/application_security/container_scanning/#container-scanning-for-registry)\n\n\nLorsque vous effectuez un push d'une image de conteneur avec le tag `latest`, le bot de politique de sécurité de GitLab déclenche automatiquement une analyse sur la branche par défaut. Contrairement à l'analyse dans le pipeline, cette approche fonctionne conjointement avec l'analyse continue des vulnérabilités pour surveiller les nouveaux avis de sécurité publiés.\n\n\n#### Activer l'analyse des conteneurs pour le registre\n\n\n1. Accédez à **Sécurisation > Configuration de la sécurité**.\n\n2. Faites défiler jusqu'à la section **Analyse des conteneurs pour le registre**.\n\n3. Activez la fonctionnalité.\n\n\n![Analyse des conteneurs pour le registre](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547512/vntrlhtmsh1ecnwni5ji.png \"Bouton d'activation de l'analyse des conteneurs pour le registre\")\n\n\n#### Prérequis\n\n\n* Rôle de Chargé de maintenance ou supérieur dans le projet\n\n* Le projet ne doit pas être vide (au moins un commit sur la branche par défaut est requis)\n\n* Les notifications du registre de conteneurs doivent être configurées\n\n* La base de données de métadonnées des paquets doit être configurée (activée par défaut sur GitLab.com)\n\n\nLes vulnérabilités apparaissent sous l'onglet **Vulnérabilités du registre de conteneurs** dans votre rapport de vulnérabilités.\n\n\n### 3. Analyse multi-conteneurs\n\n\n* Fonctionnement : analyse plusieurs images de conteneurs en parallèle au sein d'un même pipeline\n\n* Cas d'utilisation idéal : [architectures de microservices](https://about.gitlab.com/fr-fr/blog/what-are-the-benefits-of-a-microservices-architecture/ \"Qu'est-ce qu'une architecture de microservices ?\") et projets avec plusieurs images de conteneurs\n\n* Disponibilité : version gratuite de GitLab, GitLab Premium et GitLab Ultimate (actuellement en version bêta)\n\n* [Documentation](https://docs.gitlab.com/user/application_security/container_scanning/multi_container_scanning/)\n\n\nL'analyse multi-conteneurs utilise des pipelines enfants dynamiques pour exécuter des analyses simultanées afin de réduire considérablement le temps d'exécution global du pipeline lorsque plusieurs images doivent être analysées.\n\n\n#### Activer l'analyse multi-conteneurs\n\n\n1. Créez un fichier `.gitlab-multi-image.yml` à la racine de votre dépôt :\n\n\n```yaml\nscanTargets:\n  - name: alpine\n    tag: \"3.19\"\n  - name: python\n    tag: \"3.9-slim\"\n  - name: nginx\n    tag: \"1.25\"\n```\n\n\n2. Incluez le template dans votre fichier `.gitlab-ci.yml` :\n\n\n```yaml\ninclude:\n  - template: Jobs/Multi-Container-Scanning.latest.gitlab-ci.yml\n```\n\n\n#### Configuration avancée\n\n\n**Analyser des images depuis des registres privés :**\n\n\n```yaml\nauths:\n  registry.gitlab.com:\n    username: ${CI_REGISTRY_USER}\n    password: ${CI_REGISTRY_PASSWORD}\n\nscanTargets:\n  - name: registry.gitlab.com/private/image\n    tag: latest\n```\n\n\n**Inclure les informations de licence :**\n\n\n```yaml\nincludeLicenses: true\n\nscanTargets:\n  - name: postgres\n    tag: \"15-alpine\"\n```\n\n\n### 4. Analyse continue des vulnérabilités\n\n\n* Fonctionnement : crée automatiquement des vulnérabilités lors de la publication de nouveaux avis de sécurité, sans nécessiter l'exécution de pipeline\n\n* Cas d'utilisation idéal : surveillance proactive de la sécurité entre les déploiements\n\n* Disponibilité : GitLab Ultimate uniquement\n\n* [Documentation](https://docs.gitlab.com/user/application_security/continuous_vulnerability_scanning/)\n\n\nL'analyse traditionnelle ne détecte les vulnérabilités qu'au moment où elle est effectuée. Mais que se passe-t-il lorsqu'une nouvelle vulnérabilité et exposition commune (CVE) est publiée le lendemain pour un paquet analysé la veille ? L'analyse continue des vulnérabilités résout ce problème en surveillant la base de données d'avis de GitLab et en enregistrant automatiquement les vulnérabilités lorsque de nouveaux avis affectent vos composants.\n\n\n#### Fonctionnement\n\n\n1. Votre job d'analyse des conteneurs ou d'analyse des dépendances génère une SBOM CycloneDX.\n\n2. GitLab enregistre les composants de votre projet à partir de cette SBOM.\n\n3. Lors de la publication de nouveaux avis, GitLab vérifie si vos composants sont concernés.\n\n4. Les vulnérabilités sont automatiquement créées dans votre rapport de vulnérabilités.\n\n\n#### Points importants\n\n\n* Les analyses s'exécutent via des jobs en arrière-plan (Sidekiq), et non via des pipelines CI.\n\n* Seules les alertes publiées au cours des 14 derniers jours sont prises en compte pour la détection de nouveaux composants.\n\n* Les vulnérabilités utilisent « GitLab SBoM Vulnerability Scanner » comme nom de scanner.\n\n* Pour marquer des vulnérabilités comme résolues, vous devez toujours exécuter une analyse basée sur un pipeline.\n\n\n### 5. Analyse opérationnelle des conteneurs\n\n\n* Fonctionnement : analyse les conteneurs en cours d'exécution dans votre cluster [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ?\") selon une cadence planifiée\n\n* Cas d'utilisation idéal : surveillance de la sécurité après déploiement et détection des vulnérabilités au moment de l'exécution\n\n* Disponibilité : GitLab Ultimate uniquement\n\n* [Documentation](https://docs.gitlab.com/user/clusters/agent/vulnerabilities/)\n\n\nL'analyse opérationnelle des conteneurs comble l'écart entre la sécurité au moment du build et la sécurité à l'exécution. Grâce à l'agent GitLab pour Kubernetes, cette approche analyse les conteneurs réellement en cours d'exécution dans vos clusters pour détecter les vulnérabilités qui apparaissent après le déploiement.\n\n\n#### Activer l'analyse opérationnelle des conteneurs\n\n\nSi vous utilisez l'[agent GitLab pour Kubernetes](https://docs.gitlab.com/user/clusters/agent/install/), vous pouvez ajouter le contenu suivant à votre fichier de configuration de l'agent :\n\n\n```yaml\ncontainer_scanning:\n  cadence: '0 0 * * *'  # Daily at midnight\n  vulnerability_report:\n    namespaces:\n      include:\n        - production\n        - staging\n```\n\n\nVous pouvez également créer une [politique d'exécution des analyses](https://docs.gitlab.com/user/clusters/agent/vulnerabilities/#enable-via-scan-execution-policies) qui impose une analyse selon un planning défini par l'agent GitLab pour Kubernetes.\n\n\n![Politique d'exécution des analyses – analyse opérationnelle des conteneurs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547515/gsgvjcq4sas4dfc8ciqk.png \"Conditions d'une politique d'exécution des analyses pour l'analyse opérationnelle des conteneurs\")\n\n\n#### Consulter les résultats\n\n\n* Accédez à **Opération > Clusters Kubernetes**.\n\n* Sélectionnez l'onglet **Agent** et choisissez votre agent.\n\n* Sélectionnez ensuite l'onglet **Sécurité** pour consulter les vulnérabilités du cluster.\n\n* Les résultats apparaissent également sous l'onglet **Vulnérabilités opérationnelles** dans le **rapport de vulnérabilités**.\n\n\n## Renforcer la posture de sécurité avec les politiques de sécurité de GitLab\n\n\nLes politiques de sécurité de GitLab vous permettent d'appliquer des normes de sécurité cohérentes dans l'ensemble de vos workflows de conteneurs, grâce à des contrôles automatisés pilotés par des politiques. Ces politiques intègrent la sécurité en amont en intégrant les exigences directement dans votre pipeline de développement afin de garantir que les vulnérabilités sont détectées et traitées avant que le code n'atteigne l'environnement de production.\n\n\n#### Politiques d'exécution des scans et des pipelines\n\n\nLes [politiques d'exécution des scans](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/) automatisent le moment et la manière dont l'analyse des conteneurs s'exécute dans vos projets. Définissez des politiques qui déclenchent des analyses de conteneurs sur chaque merge request, planifiez des analyses récurrentes de votre branche principale, et plus encore. Ces politiques assurent une couverture complète sans que les équipes de développement aient à configurer manuellement l'analyse dans le pipeline CI/CD de chaque projet.\n\n\nVous pouvez préciser les versions de scanner à utiliser et configurer les paramètres de scan de manière centralisée pour garantir la cohérence dans toute votre organisation tout en vous adaptant aux nouvelles menaces qui pèsent sur la sécurité des conteneurs.\n\n\n![Configuration d'une politique d'exécution des scans](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/z36dntxslqem9udrynvx.png \"Configuration d'une politique d'exécution des scans\")\n\n\nLes [politiques d'exécution des pipelines](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/) offrent des contrôles flexibles pour injecter (ou remplacer) des jobs personnalisés dans un pipeline en fonction de vos besoins en matière de conformité.\n\n\nCes politiques permettent d'injecter automatiquement des jobs d'analyse des conteneurs dans votre pipeline, de faire échouer les builds lorsque les vulnérabilités de conteneurs dépassent votre seuil de tolérance au risque, de déclencher des contrôles de sécurité supplémentaires pour des branches ou des tags spécifiques, ou encore d'imposer des exigences de conformité pour les images de conteneurs destinées aux environnements de production. Les politiques d'exécution des pipelines agissent comme des garde-fous automatisés pour appliquer vos normes de sécurité de manière cohérente dans l'ensemble de vos déploiements de conteneurs, sans intervention manuelle.\n\n\n![Politique d'exécution des pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/ddhhugzcr2swptgodof2.png \"Actions d'une politique d'exécution de pipeline\")\n\n\n#### Politiques d'approbation des merge requests\n\n\nLes [politiques d'approbation des merge requests](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/) imposent des contrôles de sécurité : les approbateurs désignés examinent et valident les merge requests contenant des vulnérabilités de conteneurs.\n\n\nConfigurez des politiques qui bloquent le merge lorsque des vulnérabilités de gravité critique ou élevée sont détectées, ou qui exigent l'approbation de l'équipe de sécurité pour toute merge request introduisant de nouveaux résultats liés aux conteneurs. Ces politiques empêchent les images de conteneurs vulnérables de progresser dans votre pipeline tout en préservant la vélocité de développement pour les changements à faible risque.\n\n\n![Politique d'approbation des merge requests avec blocage dans la merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/hgnbc1vl4ssqafqcyuzg.png \"Politique d'approbation des merge requests avec blocage dans la merge request\")\n\n\n## Choisir la bonne approche\n\n\n| Type d'analyse | Utilisation | Avantage clé |\n|--------------|-------------|-------------|\n| Analyse dans le pipeline | À chaque build | Contrôles de sécurité en amont, blocage des builds vulnérables |\n| Analyse de registre | Surveillance continue | Détection des nouvelles CVE dans les images stockées |\n| Analyse multi-conteneurs | Microservices | Analyse en parallèle, pipelines plus rapides |\n| Analyse continue des vulnérabilités | Entre les déploiements | Surveillance proactive des avis |\n| Analyse opérationnelle | Surveillance en production | Détection des vulnérabilités dans l'environnement d'exécution |\n\n\nPour une approche complète en matière de sécurité, combinez plusieurs approches : l'analyse dans le pipeline pour détecter les problèmes pendant le développement, l'analyse des conteneurs pour le registre afin d'assurer une surveillance continue et l'analyse opérationnelle pour la visibilité en production.\n\n\n## Lancez-vous dès aujourd'hui\n\n\nActivez l'analyse dans le pipeline pour commencer à appliquer des mesures de sécurité dans les conteneurs :\n\n\n1. Accédez à **Sécurisation > Configuration de la sécurité** dans votre projet.\n\n2. Cliquez sur **Configurer avec une merge request** pour lancer l'analyse des conteneurs.\n\n3. Fusionnez la merge request.\n\n4. Votre prochain pipeline inclura l'analyse des vulnérabilités.\n\n\nAjoutez ensuite des analyses supplémentaires en fonction de vos exigences de sécurité et de votre abonnement GitLab.\n\n\nLa sécurité des conteneurs n'est pas une tâche ponctuelle, mais un processus continu. Grâce aux capacités complètes d'analyse des conteneurs de GitLab, vous pouvez détecter les vulnérabilités à chaque étape du cycle de vie de vos conteneurs, du build à l'exécution.\n\n\n> Pour en savoir plus sur la façon dont GitLab peut contribuer à renforcer votre posture de sécurité, consultez la [page sur les solutions de sécurité et de gouvernance de GitLab](https://about.gitlab.com/fr-fr/solutions/application-security-testing/).\n","2026-04-13","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1772721753/frfsm1qfscwrmsyzj1qn.png",[687],"Fernando Diaz","Découvrez les différentes méthodes d'analyse des conteneurs proposées par GitLab et apprenez à sécuriser vos conteneurs à chaque étape de leur cycle de vie.","Analyse des conteneurs de GitLab : le guide complet",{"featured":11,"template":12,"slug":691},"complete-guide-to-gitlab-container-scanning",{"content":693,"config":704},{"title":694,"description":695,"authors":696,"heroImage":698,"date":699,"body":700,"category":9,"tags":701},"GitLab 18.10 introduit le classement et la remédiation avec l'IA native","Découvrez les fonctionnalités de GitLab Duo Agent Platform qui réduisent le bruit, identifient les vulnérabilités les plus importantes et transforment les résultats en propositions de remédiation.",[697],"Alisa Ho","https://res.cloudinary.com/about-gitlab-com/image/upload/v1773843921/rm35fx4gylrsu9alf2fx.png","2026-03-19","GitLab 18.10 introduit de nouvelles fonctionnalités de sécurité basées sur l'IA, conçues pour améliorer la qualité et la rapidité de la [gestion des vulnérabilités](https://about.gitlab.com/fr-fr/blog/what-is-vulnerability-management/ \"Qu'est-ce que la gestion des vulnérabilités ?\"). Ensemble, ces fonctionnalités contribuent à réduire le temps que les équipes de développement consacrent à l'analyse des faux positifs et intègrent la remédiation automatisée directement dans leur workflow, afin qu'elles puissent corriger les vulnérabilités sans connaissances spécialisées dans la sécurité.\n\nVoici les nouveautés :\n\n* [**La détection des faux positifs pour les tests statiques de sécurité des applications (SAST)**](https://docs.gitlab.com/user/application_security/vulnerabilities/false_positive_detection/) **est désormais en disponibilité générale.** Ce flow utilise un [grand modèle de langage (LLM)](https://about.gitlab.com/fr-fr/blog/large-language-model/ \"Qu'est-ce qu'un LLM ?\") pour le raisonnement agentique afin de déterminer la probabilité qu'une vulnérabilité soit un faux positif et permet ainsi aux équipes de sécurité et de développement de se concentrer en priorité sur la correction des vulnérabilités critiques.\n* [**La résolution des vulnérabilités SAST avec l'IA agentique**](https://docs.gitlab.com/user/application_security/vulnerabilities/agentic_vulnerability_resolution/) **est désormais disponible en version bêta.** La résolution des vulnérabilités SAST avec l'IA agentique crée automatiquement une merge request avec un correctif proposé pour les vulnérabilités SAST vérifiées, ce qui réduit le délai de remédiation et limite le besoin d'une expertise approfondie en sécurité.\n* [**La détection des faux positifs pour les secrets**](https://docs.gitlab.com/user/application_security/vulnerabilities/secret_false_positive_detection/) **est désormais disponible en version bêta.** Ce flow applique la même réduction de bruit basée sur l'IA à la détection des secrets, en signalant les secrets factices et de test afin de réduire l'effort de revue.\n\nCes flows sont disponibles pour les clients [GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/ \"GitLab Ultimate\") qui utilisent GitLab Duo Agent Platform.\n\n## Réduire le temps de classement grâce à la détection des faux positifs SAST\n\nLes scanners SAST traditionnels signalent chaque modèle de code suspect qu'ils détectent, indépendamment de l'accessibilité des chemins de code ou de la prise en charge du risque par les frameworks. Sans contexte d'exécution, ils ne peuvent pas distinguer une véritable vulnérabilité d'un code sûr qui semble simplement dangereux.\n\nLes équipes de développement peuvent ainsi passer des heures à examiner des résultats qui s'avèrent être des faux positifs. Au fil du temps, cette situation peut éroder la confiance dans le rapport et ralentir les équipes chargées de corriger les risques réels.\n\nAprès chaque scan SAST, GitLab Duo Agent Platform analyse automatiquement les nouveaux résultats de gravité critique et élevée, et y associe :\n\n* Un score de confiance indiquant la probabilité que le résultat soit un faux positif\n* Une explication générée par l'IA qui décrit le raisonnement\n* Un badge visuel qui permet de distinguer facilement les faux positifs probables des résultats probablement réels dans l'interface utilisateur\n\nCes résultats apparaissent dans le [rapport de vulnérabilités](https://docs.gitlab.com/user/application_security/vulnerability_report/), comme illustré ci-dessous. Vous pouvez filtrer le rapport pour vous concentrer sur les résultats qui ne sont pas des faux positifs, afin que les équipes consacrent leur temps à traiter les vulnérabilités réelles plutôt qu'à classer des résultats sans importance. \n\n![Rapport de vulnérabilités](https://res.cloudinary.com/about-gitlab-com/image/upload/v1773844787/i0eod01p7gawflllkgsr.png)\n\n\nL'évaluation de GitLab Duo Agent Platform est une recommandation. Vous gardez le contrôle sur chaque faux positif pour déterminer sa validité, et vous pouvez vérifier le raisonnement de l'agent à tout moment pour renforcer votre confiance dans le modèle.\n\n\n## Transformer les vulnérabilités en correctifs automatisés\n\nSavoir qu'une vulnérabilité est réelle ne représente que la moitié du travail. La remédiation nécessite encore de comprendre le chemin de code, de rédiger un correctif sécurisé et de s'assurer que rien d'autre n'est affecté.\n\nSi la vulnérabilité est identifiée comme probablement réelle par le flow SAST False Positive Detection, le flow Agentic SAST Vulnerability Resolution effectue automatiquement les étapes suivantes :\n\n1. Lecture du code vulnérable et du contexte environnant depuis votre dépôt\n2. Génération de correctifs proposés de haute qualité\n3. Validation des correctifs par des tests automatisés\n4. Ouverture d'une merge request avec un correctif proposé comprenant :\n   * Les modifications concrètes du code\n   * Un score de confiance\n   * Une explication des changements apportés et leur justification\n\nDans cette démonstration, vous verrez comment GitLab peut automatiquement traiter une vulnérabilité SAST, de la détection jusqu'à la création d'une merge request prête à être examinée. Observez comment l'agent lit le code, génère et valide un correctif, puis ouvre une merge request avec des modifications claires et explicites, afin que les équipes de développement puissent corriger le problème plus rapidement sans être des experts en sécurité.\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1174573325?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab 18.10 AI SAST False Positive Auto Remediation\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\nComme pour toute suggestion générée par l'IA, il est recommandé d'examiner attentivement la merge request proposée avant de procéder au merge.\n\n## Identifier les secrets réels\nLa détection des secrets n'est utile que si les équipes font confiance aux résultats. Lorsque les rapports regorgent d'identifiants de test, de valeurs de remplacement et de tokens d'exemple, les équipes de développement risquent de perdre du temps à examiner des informations superflues au lieu de corriger les expositions réelles. Cette situation peut ralentir la remédiation des vulnérabilités et réduire la confiance dans le scan.\n\nLa détection des faux positifs pour les secrets aide les équipes à se concentrer sur les secrets importants afin de réduire les risques plus rapidement. Lors de l'exécution sur la branche par défaut, le flow effectue automatiquement les étapes suivantes :\n\n1. Analyse de chaque résultat pour repérer les identifiants de test, les valeurs d'exemple et les secrets factices potentiels\n2. Attribution d'un score de confiance qui indique si le résultat représente un risque réel ou un probable faux positif\n3. Génération d'une explication justifiant pourquoi le secret est considéré comme réel ou comme un faux positif\n4. Ajout d'un badge dans le rapport de vulnérabilités pour que les équipes de développement puissent voir le statut en un seul coup d'œil\n\nLes équipes de développement peuvent également déclencher cette analyse manuellement depuis le rapport de vulnérabilités en sélectionnant **« Vérifier les faux positifs »** sur n'importe quel résultat de détection de secrets, ce qui leur permet d'éliminer les résultats sans risque et de se concentrer plus rapidement sur les véritables secrets.\n\n## Adoptez la sécurité basée sur l'IA dès aujourd'hui\n\nGitLab 18.10 introduit des fonctionnalités couvrant l'ensemble du workflow de gestion des vulnérabilités, de la réduction du bruit lié aux faux positifs dans les scans SAST et la détection des secrets à la génération automatique de merge requests avec des correctifs proposés.\n\nPour découvrir comment la sécurité basée sur l'IA peut réduire le temps de revue et transformer les résultats en correctifs prêts à être fusionnés, [commencez un essai gratuit de GitLab Duo Agent Platform dès maintenant](https://about.gitlab.com/gitlab-duo-agent-platform/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_fr_blog_fr).",[702,9,703],"product","features",{"featured":11,"template":12,"slug":705},"gitlab-18-10-brings-ai-native-triage-and-remediation",{"content":707,"config":717},{"tags":708,"category":9,"body":710,"date":711,"heroImage":712,"authors":713,"description":715,"title":716},[9,682,702,709],"google","L'authentification unique (SSO) simplifie l'authentification des utilisateurs et en améliore la sécurité, car ces derniers peuvent accéder à plusieurs applications avec un seul identifiant. Pour les organisations qui utilisent à la fois GitLab et Google Workspace, l'intégration d'une authentification unique basée sur le protocole SAML rationalise la gestion des accès et garantit une collaboration fluide au sein des équipes.\n\nDans ce guide, nous vous présenterons la configuration de l'authentification SAML entre Google Workspace et GitLab.com, en incluant la synchronisation automatique des groupes qui associe les groupes Google Workspace aux rôles GitLab. À la fin de ce processus, vos utilisateurs pourront se connecter à GitLab avec leurs identifiants Google, et leurs autorisations refléteront automatiquement leurs adhésions aux groupes Google.\n\n**Remarque** : ce guide se concentre sur GitLab.com (version SaaS). Si vous utilisez GitLab Self-Managed, le processus de configuration diffère légèrement. Consultez la [documentation officielle GitLab relative au protocole SAML pour les instances auto-gérées](https://docs.gitlab.com/integration/saml/) pour obtenir des instructions détaillées.\n\n## Prérequis\n\nAvant de commencer, assurez-vous de disposer des éléments suivants :\n\n* **Google Workspace** avec un accès super-administrateur\n* **GitLab.com** avec un abonnement de niveau GitLab Premium ou GitLab Ultimate\n* **Rôle de propriétaire** dans un groupe principal GitLab\n* Des utilisateurs déjà existants dans Google Workspace (ils seront créés automatiquement dans GitLab lors de leur première connexion)\n\n## Comprendre l'architecture\n\nLorsque vous configurez l'authentification unique basée sur le protocole SAML avec la synchronisation de groupe, voici ce qui se produit :\n\n1. **Flux d'authentification** : les utilisateurs accèdent à l'URL d'authentification SSO de GitLab et sont redirigés vers Google Workspace pour s'authentifier.\n2. **Assertion SAML** : après une authentification réussie, Google envoie une réponse SAML contenant les détails de l'utilisateur et ses adhésions aux groupes.\n3. **Provisionnement automatique** : GitLab crée le compte utilisateur (si nécessaire) et l'assigne aux groupes en fonction de ses adhésions aux groupes Google.\n4. **Synchronisation des autorisations** : chaque fois que les utilisateurs se connectent, GitLab met à jour leurs adhésions aux groupes et leurs rôles pour qu'elles correspondent à leurs groupes Google actuels.\n\nCette configuration offre plusieurs avantages :\n\n* **Contrôle d'accès centralisé** : vous pouvez gérer l'accès des utilisateurs via les groupes Google Workspace.\n* **Provisionnement automatique** : les nouveaux utilisateurs obtiennent un accès à GitLab dès leur première connexion.\n* **Autorisations dynamiques** : les rôles des utilisateurs se mettent à jour automatiquement en fonction des modifications de l'adhésion aux groupes.\n* **Sécurité renforcée** : vous pouvez exploiter les fonctionnalités de sécurité d'authentification de Google.\n* **Réduction de la charge administrative** : il n'est pas nécessaire de gérer manuellement les adhésions aux groupes GitLab.\n\n## Partie 1 : obtenir vos valeurs de configuration SAML GitLab\n\nTout d'abord, vous devrez collecter certaines informations depuis GitLab que vous utiliserez lors de la création de l'application SAML dans Google Workspace. Voici les étapes à suivre :\n\n### Étape 1 : accéder aux paramètres SAML de votre groupe GitLab\n\n1. Connectez-vous à **GitLab.com**.\n2. Accédez à votre **groupe principal** (remarque : l'authentification SSO SAML ne peut être configurée qu'au niveau du groupe principal, pas dans les sous-groupes).\n3. Dans la barre latérale gauche, sélectionnez **Paramètres > Authentification unique SAML**.\n\n### Étape 2 : copier les URL requises\n\nSur la page des paramètres relatifs à l'authentification unique SAML, vous verrez trois URL importantes. Copiez-les et enregistrez-les dans un endroit accessible, vous en aurez bientôt besoin :\n\n* **URL du service consommateur d'assertion** : c'est ici que Google enverra les réponses SAML.\n\n  * Format : `https://gitlab.com/groups/your-group/-/saml/callback`\n* **Identifiant** : également appelé ID de l'entité, il identifie de manière unique votre groupe GitLab.\n\n  * Format : `https://gitlab.com/groups/your-group`\n* **URL de l'authentification unique GitLab** : c'est l'URL que vos utilisateurs utiliseront pour se connecter.\n\n  * Format : `https://gitlab.com/groups/your-group/-/saml/sso`\n\n\u003Cfigure>\n  \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769090029/lrw6jbn7ussjze6lxg5o.png\" alt=\"Paramètres d'authentification unique SAML GitLab\">\n  \u003Cfigcaption>\u003Cem>Paramètres d'authentification unique SAML GitLab\u003C/em>\u003C/figcaption>\n\u003C/figure>\n\nVous allez maintenant créer une application SAML personnalisée dans Google Workspace qui se connecte à votre groupe GitLab.\n\n### Étape 3 : accéder à la console d'administration Google\n\n1. Ouvrez un nouvel onglet de navigateur et connectez-vous à la [console d'administration Google](https://admin.google.com/) avec un compte super-administrateur.\n2. Cliquez sur l'icône **Menu** (☰) en haut à gauche.\n3. Accédez à **Applications > Applications Web et mobiles**.\n4. Cliquez sur **Ajouter une application > Ajouter une application SAML personnalisée**.\n\n\u003Cp>\u003C/p>\n\n\u003Cfigure>\n  \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769090026/c2inhqzppdbszysupjcd.png\" alt=\"Application SAML personnalisée Google\">\n  \u003Cfigcaption>\u003Cem>Application SAML personnalisée Google\u003C/em>\u003C/figcaption>\n\u003C/figure>\n\n### Étape 4 : configurer le nom de l'application\n\n1. Dans le champ **Nom de l'application**, saisissez GitLab (ou le nom de votre choix).\n2. Facultatif : téléchargez un **logo GitLab** comme icône d'application pour faciliter l'identification de l'application.\n3. Cliquez sur **Continuer**.\n\n### Étape 5 : télécharger les détails du fournisseur d'identité Google\n\nSur la page **Détails du fournisseur d'identité Google**, vous devrez enregistrer deux éléments :\n\n1. **URL d'authentification SSO** : copiez cette URL. Elle indique à GitLab où envoyer les demandes d'authentification.\n\n   * Format d'exemple : `https://accounts.google.com/o/saml2/idp?idpid=C1234abcd`\n2. **Certificat** : cliquez sur le bouton **Télécharger** pour enregistrer le fichier de certificat.\n\n   * Le fichier sera nommé comme l'exemple suivant : `GoogleIDPCertificate-gitlab.pem`.\n   * Enregistrez ce fichier dans un endroit où vous pourrez facilement le retrouver. Vous en aurez besoin dans la section suivante.\n3. Cliquez sur **Continuer**.\n\n### Étape 6 : configurer les détails du fournisseur de services\n\nC'est ici que vous utiliserez les URL GitLab que vous avez copiées à l'étape 2. Saisissez les informations suivantes :\n\n| **Champ** | **Valeur** | **Description** |\n|-----------|-----------|-----------------|\n| **URL ACS** | Votre URL du service consommateur d'assertion GitLab | Où Google envoie les réponses SAML |\n| **ID d'entité** | Votre identifiant GitLab | Identifiant unique pour votre groupe GitLab |\n| **URL de démarrage** | Laisser vide | Non requis pour cette configuration |\n| **Format de l'ID du nom** | Sélectionnez **E-MAIL** | Format de l'identifiant utilisateur |\n| **ID du nom** | Sélectionnez **Informations de base > Adresse e-mail principale** | L'adresse e-mail principale de l'utilisateur sera utilisée comme identifiant |\n| **Réponse signée** | Laissez décoché | GitLab ne requiert pas de réponses signées par défaut |\n\n\u003Cfigure style=\"margin: 24px 0;\">\n  \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769090028/kaui5vj14gkftbfgsbnz.png\" alt=\"Détails de l'application SAML GitLab\">\n  \u003Cfigcaption>\u003Cem>Détails de l'application SAML GitLab\u003C/em>\u003C/figcaption>\n\u003C/figure>\n\nCliquez sur **Continuer** une fois que vous avez terminé.\n\n### Étape 7 : configurer le mappage des attributs\n\nLe mappage des attributs indique à Google quelles informations utilisateur envoyer à GitLab. Vous configurerez à la fois les attributs des utilisateurs de base et l'adhésion aux groupes.\n\n#### Attributs de base\n\nAjoutez ces trois mappages d'attributs en cliquant sur **Ajouter un mappage** pour chacun :\n\n| **Attribut de l'annuaire Google** | **Attribut de l'application** |\n|-----------------------------------|-------------------------------|\n| Adresse e-mail principale | email |\n| Prénom | first_name |\n| Nom | last_name |\n\n#### Configuration de l'adhésion aux groupes\n\nIl s'agit de la configuration critique qui permet la synchronisation automatique des groupes :\n\n1. Faites défiler jusqu'à la section **« Adhésion aux groupes (facultatif) »**.\n2. Sous **« Groupes Google »**, cliquez sur **« Rechercher un groupe »**.\n3. Recherchez et sélectionnez chaque groupe Google Workspace que vous souhaitez synchroniser avec GitLab.\n\n   * Vous pouvez sélectionner jusqu'à 75 groupes\n   * Exemples : Ingénierie, DevOps, Équipe plateforme, Équipe sécurité\n4. Sous **« Attribut de l'application »**, saisissez exactement : `groups`.\n5. Cliquez sur **Terminer**.\n\n\u003Cp>\u003C/p>\n\n\u003Cfigure>\n  \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769090027/ksuebt9uoe3w5cdzsjkl.png\" alt=\"Mappage des attributs de l'application SAML GitLab\">\n  \u003Cfigcaption>\u003Cem>Mappage des attributs de l'application SAML GitLab\u003C/em>\u003C/figcaption>\n\u003C/figure>\n\n> **Important** : le nom de l'attribut de l'application **DOIT** être exactement `groups` (minuscules). C'est ce que GitLab s'attend à recevoir dans la réponse SAML. Toute autre valeur ou majuscule empêchera la synchronisation des groupes.\n\n### Étape 8 : activer l'application pour les utilisateurs\n\nVotre application SAML est créée mais pas encore activée. Pour la rendre disponible aux utilisateurs :\n\n1. Dans la console d'administration Google, repérez votre application **GitLab** dans la liste des applications Web et mobiles.\n2. Cliquez sur l'application pour accéder aux détails.\n3. Dans la barre latérale gauche, cliquez sur **Accès utilisateur**.\n4. Sélectionnez l'une des options suivantes :\n\n   * **ACTIVÉ pour tous** : active l'application pour tous les utilisateurs de votre organisation\n   * **ACTIVÉ pour certaines unités organisationnelles** :  sélectionnez des unités organisationnelles spécifiques\n5. Cliquez sur **Enregistrer**.\n\n**Remarque** : les modifications peuvent nécessiter jusqu'à 24 heures, mais prennent généralement effet en quelques minutes.\n\n## Partie 3 : convertir le certificat au format d'empreinte SHA-1\n\nGitLab requiert une empreinte de certificat SHA-1, mais le téléchargement du certificat de Google n'inclut pas directement ce format. Vous devrez le convertir.\n\n### Étape 9 : convertir le certificat\n\nVous avez deux options pour convertir le certificat au format requis.\n\n#### Option 1 : outil de conversion en ligne\n\nIl s'agit d'une méthode viable si vous êtes à l'aise avec l'utilisation d'un outil tiers :\n\n1. **Localisez le fichier de certificat** que vous avez téléchargé à l'étape 5 :\n\n   * Vérifiez votre dossier Téléchargements\n   * Le fichier aura un nom similaire à `GoogleIDPCertificate-gitlab.pem`\n2. **Ouvrez le fichier** dans un éditeur de texte :\n\n   * Mac : **Clic droit > Ouvrir avec > TextEdit**\n   * Windows : **Clic droit > Ouvrir avec > Bloc-notes**\n   * Linux : utilisez votre éditeur de texte préféré\n3. **Copiez TOUT le contenu** du fichier, y compris l'en-tête et le pied de page :\n\n```\n-----BEGIN CERTIFICATE-----\nMIIDdDCCAlygAwIBAgIGAXqD...\n(plusieurs lignes de texte encodé)\n...kE7RnF6yQ==\n-----END CERTIFICATE-----\n```\n\n4. **Accédez à** : un outil de conversion d'empreinte SHA-1 comme [celui-ci](https://www.samltool.com/fingerprint.php).\n5. **Collez le contenu du certificat** dans la zone de texte.\n6. **Sélectionnez « SHA-1 »** dans le menu déroulant de l'algorithme (et non SHA-256 !).\n7. Cliquez sur **« Calculer l'empreinte »**.\n8. **Copiez l'empreinte résultante** : elle sera au format : `XX:XX:XX:XX:XX:...`.\n\n#### Option 2 : conversion en ligne de commande\n\nSi vous préférez utiliser la ligne de commande :\n\n**Pour Mac, Linux ou Windows avec WSL :**\n\n```bash\ncd ~/Downloads\nopenssl x509 -noout -fingerprint -sha1 -inform pem -in \"GoogleIDPCertificate-gitlab.pem\"\n```\n\nLes données de sortie afficheront :\n\n```\nSHA1 Fingerprint=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX\n```\n\nCopiez tout ce qui se trouve après `SHA1 Fingerprint=`.\n\n## Partie 4 : finaliser la configuration SAML GitLab\n\nMaintenant que vous disposez de l'URL d'authentification SSO Google et de l'empreinte du certificat, vous pouvez finaliser la configuration côté GitLab.\n\n### Étape 10 : saisir les détails du fournisseur d'identité Google\n\nRetournez à votre onglet de navigateur GitLab (**Paramètres > Authentification unique SAML**) et procédez comme suit :\n\n1. **URL de l'authentification SSO du fournisseur d'identité** :\n\n   * Collez l'URL de l'authentification SSO que vous avez copiée depuis Google à l'étape 5.\n2. **Empreinte du certificat** :\n\n   * Collez l'empreinte SHA-1 que vous avez générée à l'étape 9.\n   * Vérifiez que le format est correct : 59 caractères avec des deux-points (XX:XX:XX:...).\n3. **Activer l'authentification SAML pour ce groupe** :\n\n   * Cochez cette case pour activer l'authentification SSO SAML.\n\n\u003Cp>\u003C/p>\n\n\u003Cfigure>\n  \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769090027/ncoeqrdu7aahyuflrq7b.png\" alt=\"Configuration SAML GitLab avec les valeurs SAML Google\">\n  \u003Cfigcaption>\u003Cem>Configuration SAML GitLab avec les valeurs SAML Google\u003C/em>\u003C/figcaption>\n\u003C/figure>\n\n### Étape 11 : configurer les paramètres de sécurité (recommandé)\n\nPour renforcer la sécurité, envisagez d'activer ces options supplémentaires :\n\n* **Mettre en œuvre l'authentification unique SSO pour l'activité Web de ce groupe**\n\n  * Cette option oblige les utilisateurs à s'authentifier via SAML pour accéder à l'interface Web GitLab.\n* **Mettre en œuvre l'authentification unique SSO pour les activités de [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") et du proxy de dépendance pour ce groupe**\n\n  * Cette option exige l'authentification SAML pour les opérations Git et l'accès au proxy de dépendances.\n\nCliquez sur **Enregistrer les modifications** pour appliquer votre configuration.\n\n### Étape 12 : tester la configuration SAML\n\nAvant de procéder à la synchronisation des groupes, vérifiez que l'authentification SAML de base fonctionne :\n\n1. Ouvrez une fenêtre de navigation privée ou incognito.\n2. Accédez à votre URL d'authentification SSO GitLab.\n\n   * Format : `https://gitlab.com/groups/your-group/-/saml/sso`\n3. Vous devriez être redirigé vers la page de connexion Google.\n4. Connectez-vous avec un compte Google Workspace qui a accès à l'application GitLab.\n5. Après une authentification réussie, vous devriez être redirigé vers GitLab.\n\n**Si le test réussit**, vous pouvez procéder à la configuration de la synchronisation des groupes.\n\n**Si le test échoue**, vérifiez les points suivants :\n\n* Vérifiez que l'empreinte du certificat est au format SHA-1 (et non SHA-256).\n* Confirmez que l'URL de l'authentification SSO est correcte.\n* Assurez-vous que l'utilisateur a accès à l'application SAML GitLab dans la console d'administration Google.\n* Vérifiez que l'URL ACS et l'ID de l'entité correspondent exactement.\n\n## Partie 5 : configurer la synchronisation des groupes SAML\n\nIl est maintenant temps de mapper vos groupes Google Workspace aux rôles GitLab afin que les autorisations soient automatiquement gérées en fonction de l'adhésion aux groupes.\n\n### Étape 13 : configurer le rôle d'adhésion par défaut\n\nComme bonne pratique de sécurité, définissez un rôle par défaut minimal pour les utilisateurs qui se connectent mais n'appartiennent à aucun groupe mappé :\n\n1. Dans votre groupe GitLab, accédez à **Paramètres > Général**.\n2. Développez la section **Permissions et fonctionnalités du groupe**.\n3. Sous **Rôle d'adhésion par défaut**, sélectionnez **Accès minimal ou Invité**.\n4. Cliquez sur **Enregistrer les modifications**.\n\n\u003Cp>\u003C/p>\n\n\u003Cfigure>\n  \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769097587/syi0jeaspzt9tki0w9nd.png\" alt=\"Paramètre d'adhésion par défaut de l'authentification SSO SAML GitLab\">\n  \u003Cfigcaption>\u003Cem>Paramètre d'adhésion par défaut de l'authentification SSO SAML GitLab\u003C/em>\u003C/figcaption>\n\u003C/figure>\n\n### Étape 14 : créer des liens de groupe SAML\n\nLes liens de groupe SAML représentent les mappages entre les groupes Google Workspace et les rôles GitLab. Voici comment les créer :\n\n1. Dans votre groupe GitLab, accédez à **Paramètres > Liens de groupe SAML**.\n2. Cliquez sur **« Ajouter un nouveau lien de groupe SAML »**.\n\nPour chaque groupe Google Workspace que vous souhaitez synchroniser :\n\n**Nom du groupe SAML** :\n\n* Saisissez le **nom exact** de votre groupe Google Workspace\n* Il est **sensible à la casse** et doit correspondre parfaitement\n* Exemple : Ingénierie (et non ingénierie)\n* Pour trouver le nom exact : Console d'administration Google > Annuaire > Groupes\n\n**Niveau d'accès** : sélectionnez le rôle GitLab approprié :\n\n* **Accès minimal** : peut voir que le groupe existe\n* **Invité** :  peut afficher les tickets et laisser des commentaires\n* **Rapporteur** : peut récupérer le code, afficher les tickets et créer de nouveaux tickets\n* **Développeur** : peut effectuer un push du code, créer des merge requests et gérer les tickets\n* **Chargé de maintenance** : peut gérer les paramètres du projet et les membres\n* **Propriétaire** : il possède le contrôle administratif complet sur le groupe\n\n3. Cliquez sur **Enregistrer**.\n4. **Répétez ce processus** pour chaque groupe Google Workspace que vous souhaitez mapper.\n\n**Remarque** : les règles de synchronisation des groupes SAML sont appliquées chaque fois qu'un utilisateur se connecte. Si l'adhésion d'un utilisateur à un groupe Google correspond à une règle de synchronisation, son rôle GitLab sera automatiquement défini sur le niveau d'accès configuré, même si vous l'avez modifié manuellement. Par exemple, si vous configurez une règle de synchronisation qui accorde un accès « Chargé de maintenance » puis que vous promouvez manuellement un utilisateur à « Propriétaire », il sera automatiquement rétrogradé à « Chargé de maintenance » » lors de sa prochaine connexion SAML.\n\n**Bonnes pratiques** : pour maintenir des niveaux d'accès personnalisés pour des utilisateurs spécifiques, effectuez l'une des actions suivantes :\n\n* Utilisez la synchronisation de groupe SAML uniquement sur votre groupe principal et gérez manuellement les autorisations dans les sous-groupes.\n* Créez des groupes Google séparés pour les utilisateurs qui nécessitent des autorisations élevées.\n* Évitez de configurer des règles de synchronisation qui entreraient en conflit avec les affectations de rôles manuelles.\n\n\u003Cfigure>\n  \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769090028/etjoaiuyhnqh4gnjqcha.png\" alt=\"Configuration des liens de groupe SAML GitLab\">\n  \u003Cfigcaption>\u003Cem>Configuration des liens de groupe SAML GitLab\u003C/em>\u003C/figcaption>\n\u003C/figure>\n\n### Exemple de configuration de mappage de groupes\n\nVoici un exemple pratique de la façon dont vous pourriez structurer vos mappages de groupes :\n\n| **Groupe Google Workspace** | **Rôle GitLab** | **Objectif** |\n|------------------------------|-----------------|--------------|\n| Administrateur GitLab | Propriétaire | Accès administratif complet |\n| Équipe d'ingénierie | Chargé de maintenance | Peut gérer les projets et les paramètres |\n| Équipe de développement | Développeur | Peut écrire et effectuer un push du code |\n| Équipe d'assurance qualité | Développeur | Peut tester et gérer les tickets |\n| Prestataires | Rapporteur | Accès en lecture seule au code |\n| Tous les employés | Accès minimal | Visibilité de base |\n\n### Étape 15 : vérifier les liens de groupe\n\nAprès avoir créé tous vos liens de groupe :\n\n1. Examinez la liste complète des liens de groupe SAML dans **Paramètres > Liens de groupe SAML**.\n2. Vérifiez que chaque **nom de groupe SAML** correspond exactement au groupe Google Workspace correspondant.\n3. Vérifiez que chaque **niveau d'accès** est approprié pour l'objectif prévu.\n4. Vérifiez les fautes de frappe ou les espaces supplémentaires.\n\n## Partie 6 : tester la configuration complète\n\nIl est maintenant temps de tester l'ensemble de la configuration, y compris la synchronisation des groupes.\n\n### Étape 16 : tester avec un utilisateur réel\n\nChoisissez un utilisateur de test qui répond à ces critères :\n\n* Possède un compte Google Workspace\n* Est membre d'au moins un groupe Google Workspace que vous avez configuré\n* A l'application SAML GitLab activée dans la console d'administration Google\n* Idéalement, est quelqu'un d'autre que vous (pour garantir un test réaliste)\n\nPour effectuer le test :\n\n1. **Ouvrez une fenêtre de navigation privée ou incognito**\n2. **Accédez à votre URL d'authentification SSO GitLab** :\n\n   * `https://gitlab.com/groups/your-group/-/saml/sso`\n3. **Connectez-vous** avec les identifiants Google Workspace de l'utilisateur de test\n4. L'utilisateur devrait être :\n\n   * Authentifié avec succès\n   * Redirigé vers GitLab\n   * Ajouté automatiquement au groupe GitLab\n   * Assigné au rôle approprié en fonction de son adhésion au groupe Google\n\n### Étape 17 : vérifier l'adhésion au groupe et l'attribution de rôle\n\nDans votre compte administrateur GitLab :\n\n1. Accédez à votre groupe dans GitLab.\n2. Sélectionnez **Gestion > Membres** dans la barre latérale gauche.\n3. Trouvez l'utilisateur de test dans la liste des membres.\n4. Vérifiez les points suivants :\n\n   * L'utilisateur apparaît dans la liste des membres.\n   * L'utilisateur a le **rôle maximum** correct en fonction de son/ses groupe(s) Google.\n   * La colonne **Source** affiche un indicateur SAML.\n\n\u003Cp>\u003C/p>\n\n\u003Cfigure>\n  \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769090026/hiov7kiukidsiyscfesg.png\" alt=\"Utilisateur SAML vérifié ajouté\">\n  \u003Cfigcaption>\u003Cem>Utilisateur SAML vérifié ajouté\u003C/em>\u003C/figcaption>\n\u003C/figure>\n\n## Partie 7 : configurer l'accès aux sous-groupes (facultatif)\n\nPour les grandes organisations, vous souhaiterez peut-être fournir un contrôle d'accès plus granulaire en utilisant les sous-groupes GitLab. Les liens de groupe SAML peuvent être configurés à n'importe quel niveau de votre hiérarchie de groupes pour vous permettre de mapper différents groupes Google Workspace à des équipes ou projets spécifiques.\n\n### Comprendre la structure des sous-groupes GitLab\n\nGitLab prend en charge les hiérarchies de groupes imbriqués qui peuvent refléter votre structure organisationnelle :\n\n```\nacme-corp/                          ← Top-level group (SAML configured here)\n├── engineering/                    ← Subgroup\n│   ├── backend/                   ← Nested subgroup\n│   └── frontend/                  ← Nested subgroup\n├── marketing/                      ← Subgroup\n└── operations/                     ← Subgroup\n```\n\n### Créer des sous-groupes\n\nSi vous devez créer des sous-groupes supplémentaires :\n\n1. Accédez à votre **groupe parent** (par exemple, acme-corp).\n2. Cliquez sur le bouton **Nouveau sous-groupe**.\n3. Configurez le sous-groupe :\n\n   * **Nom du sous-groupe** : nom affiché (par exemple, Ingénierie)\n   * **URL du sous-groupe** : slug d'URL (par exemple, ingenierie)\n   * **Niveau de visibilité** : choisissez Privé, Interne ou Public\n4. Cliquez sur **Créer un sous-groupe**.\n5. Répétez le processus pour les autres sous-groupes si nécessaire.\n\n### Configurer les liens de groupe SAML pour les sous-groupes\n\nSuivez les étapes ci-dessous pour configurer les liens de groupe SAML pour les sous-groupes.\n\n#### Ajouter de nouveaux groupes Google à l'application SAML (si nécessaire)\n\nSi vous ajoutez de nouveaux groupes Google Workspace pour l'accès aux sous-groupes :\n\n1. Accédez à **Console d'administration Google > Applications > Applications Web et mobiles > GitLab**.\n2. Cliquez sur **Mappage des attributs SAML**.\n3. Faites défiler jusqu'à **« Adhésion aux groupes (facultatif) »**.\n4. Ajoutez vos nouveaux groupes (par exemple, équipe backend, équipe frontend).\n5. Vérifiez que l'**« Attribut de l'application »** est toujours `groups`.\n6. Cliquez sur **Enregistrer**.\n\n#### Mapper les groupes Google aux sous-groupes\n\n1. **Accédez au sous-groupe spécifique** dans GitLab\n\n   * Exemple : acme-corp/engineering/backend\n2. Accédez à **Paramètres > Liens de groupe SAML**.\n3. Cliquez sur **« Ajouter un nouveau lien de groupe SAML »**.\n4. Configurez le mappage :\n\n   * **Nom du groupe SAML** : équipe backend (nom exact du groupe Google Workspace)\n   * **Niveau d'accès** : Développeur (ou le rôle de votre choix)\n5. Cliquez sur **Enregistrer**.\n\nRépétez ce processus pour tous les sous-groupes et leurs groupes Google correspondants.\n\n### Exemple d'accès multi-niveaux\n\nVoici comment les autorisations pourraient fonctionner à différents niveaux :\n\n#### Groupe principal : acme-corp\n\nLiens de groupe SAML :\n\n* « Administrateurs de l'entreprise » → Propriétaire\n* « Tous les collaborateurs » → Accès minimal\n\n#### Sous-groupe : acme-corp/engineering\n\nLiens de groupe SAML :\n\n* « Responsables ingénierie » → Propriétaire\n* « Équipe ingénierie » → Chargé de maintenance\n\n#### Sous-groupe imbriqué : acme-corp/engineering/backend\n\nLiens de groupe SAML :\n\n* « Responsables backend » → Chargé de maintenance\n* « Équipe backend » → Développeur\n\n### Héritage et combinaison des autorisations\n\nComprendre le comportement des autorisations est important :\n\n* **Calcul du rôle** : à chaque niveau, les utilisateurs reçoivent le **rôle le plus élevé** de tous leurs groupes Google.\n* **Héritage** : les autorisations plus élevées au niveau des groupes parents sont transmises aux sous-groupes enfants.\n* **Indépendance** : chaque niveau calcule les autorisations en fonction de ses propres liens de groupe et des autorisations héritées.\n* **Aucune limitation** : les autorisations inférieures au niveau des groupes parents ne restreignent PAS les autorisations supérieures au niveau des groupes enfants.\n\n**Exemples de scénarios** :\n\n**Utilisateur A** (membre de l'équipe backend uniquement) :\n\n* acme-corp : accès minimal (depuis « Tous les collaborateurs » par défaut)\n* acme-corp/engineering : accès minimal (hérité du groupe parent)\n* acme-corp/engineering/backend : Développeur (depuis le mappage « Équipe backend »)\n\n**Utilisateur B** (membre des responsables ingénierie et de l'équipe backend) :\n\n* acme-corp : accès minimal (depuis « Tous les collaborateurs » par défaut)\n* acme-corp/engineering : Propriétaire (depuis le mappage « Responsables ingénierie »)\n* acme-corp/engineering/backend : Propriétaire (hérité du groupe parent, qui est supérieur à Développeur)\n\n## Comment fonctionne la synchronisation ?\n\nComprendre les mécanismes de synchronisation des groupes SAML vous aide à gérer le système efficacement.\n\n### Calendrier de synchronisation\n\n* **Synchronisation** : les adhésions aux groupes se mettent à jour **chaque fois** qu'un utilisateur se connecte via SAML.\n* **Fréquence** : les modifications ne sont pas continues, elles ne se produisent qu'à la connexion.\n* **Direction** : la synchronisation est **unidirectionnelle** de Google Workspace vers GitLab.\n* **Première connexion** : le compte utilisateur est créé automatiquement et les groupes sont affectés.\n* **Connexions suivantes** : les adhésions aux groupes existantes sont mises à jour pour correspondre aux groupes Google actuels.\n\n### Priorité et combinaison des rôles\n\nSi un utilisateur appartient à plusieurs groupes Google Workspace :\n\n* GitLab évalue **tous** les groupes de l'utilisateur à chaque niveau de la hiérarchie.\n* L'utilisateur obtient le **rôle le plus élevé** de l'un de ses groupes.\n* Ce calcul se produit indépendamment à chaque niveau (groupe principal, sous-groupes, etc.).\n\n**Exemple** :\n\n* Utilisateur dans « Développeurs » (rôle Développeur) + « Responsables tech » (rôle Chargé de maintenance) → **Chargé de maintenance**\n\n### Modifications automatiques de rôle\n\nLe système gère automatiquement les modifications d'adhésion :\n\n* **Utilisateur ajouté à un groupe Google** : rôle mis à niveau lors de la prochaine connexion.\n* **Utilisateur supprimé d'un groupe Google** : rôle recalculé en fonction des groupes restants lors de la prochaine connexion.\n* **Utilisateur supprimé de tous les groupes mappés** : revient au rôle d'adhésion par défaut lors de la prochaine connexion.\n* **Utilisateur ajouté à des groupes supplémentaires** : obtient le rôle le plus élevé de tous les groupes lors de la prochaine connexion.\n\n### Calendrier de propagation\n\nVoici le calendrier de propagation à prendre en compte :\n\n* **Modifications Google Workspace** : peuvent prendre jusqu'à 24 heures pour se propager, bien qu'elles ne prennent généralement que quelques minutes.\n* **Synchronisation GitLab** : se produit immédiatement lorsque l'utilisateur se connecte après que les modifications Google sont actives.\n* **Tests** : demandez aux utilisateurs de se déconnecter et de se reconnecter pour tester les modifications d'autorisations.\n\n## Comprendre le cycle de vie des utilisateurs et les cas particuliers\n\n### Que se passe-t-il lorsque vous supprimez un utilisateur de GitLab ?\n\n**Suppression des autorisations uniquement** : si vous supprimez un utilisateur des projets GitLab mais laissez son compte actif et qu'il est toujours dans les groupes Google autorisés :\n\n* Il conserve le même compte (même ID d'utilisateur et nom d'utilisateur).\n* Lorsqu'il se connecte via SAML, ses adhésions aux groupes sont automatiquement restaurées.\n* Il retrouve les autorisations en fonction de ses adhésions actuelles aux groupes Google.\n\n**Blocage du compte** :\n\n* Le compte existe mais est verrouillé.\n* L'utilisateur ne peut pas se connecter même s'il est dans les groupes Google.\n* Peut être débloqué ultérieurement, en préservant tout l'historique.\n\n**Suppression du compte** :\n\n* Le compte est définitivement supprimé.\n* Si l'utilisateur se connecte à nouveau (tout en étant toujours dans les groupes Google), GitLab crée un **compte entièrement nouveau**.\n* Le nouveau compte a un ID d'utilisateur différent sans aucune connexion avec l'ancien.\n\n### Processus de désactivation approprié\n\nPour révoquer définitivement l'accès d'un utilisateur, suivez ces étapes :\n\n1. **Supprimez l'utilisateur des groupes Google Workspace** pour empêcher l'authentification.\n2. **Bloquez l'utilisateur dans GitLab** pour empêcher la recréation du compte et préserver les pistes d'audit.\n3. **Supprimez le compte (facultatif)** seulement si vous êtes certain que l'utilisateur ne reviendra pas.\n\n> **Important** : supprimer un utilisateur uniquement de GitLab sans le supprimer des groupes Google signifie qu'il peut simplement se reconnecter et obtenir un nouvel accès.\n\n### Propagation de l'adhésion aux groupes Google\n\nSelon [la documentation de Google](https://support.google.com/a/answer/11143403), les modifications d'adhésion aux groupes peuvent prendre jusqu'à 24 heures pour se propager, bien qu'elles se produisent généralement en quelques minutes.\n\n### Scénarios de recréation de compte\n\n| **Scénario** | **Utilisateur toujours dans les groupes Google ?** | **Que se passe-t-il lors de la connexion** |\n|--------------|-----------------------------------------------------|---------------------------------------------|\n| Autorisations supprimées | Oui | Même compte, adhésions aux groupes restaurées |\n| Compte bloqué | Oui | La connexion échoue |\n| Compte supprimé | Oui | Nouveau compte créé avec un nouvel ID utilisateur |\n| Suppression des groupes Google | Non | La connexion échoue chez Google |\n\n## Dépannage des problèmes courants\n\nMême une configuration minutieuse peut entraîner des problèmes. Voici des solutions pour remédier aux problèmes les plus courants.\n\n### Les utilisateurs ne sont pas ajoutés aux groupes\n\n**Problème** : l'utilisateur se connecte avec succès via SAML mais n'apparaît dans aucun groupe GitLab, ou apparaît seulement avec le rôle par défaut.\n\n**Causes possibles et solutions** :\n\n1. **Les noms de groupe ne correspondent pas exactement**\n\n   * Vérifiez l'orthographe et les majuscules dans Google Workspace et GitLab.\n   * Recherchez les espaces supplémentaires avant ou après les noms de groupe.\n   * Vérifiez le nom exact dans Console d'administration Google > Annuaire > Groupes.\n2. **L'utilisateur n'est pas réellement dans le groupe Google**\n\n   * Vérifiez l'adhésion : Console d'administration Google > Annuaire > Groupes > Groupe > Membres.\n   * N'oubliez pas que l'adhésion aux groupes imbriqués pourrait être exclue.\n3. **Les groupes ne sont pas configurés dans l'application SAML**\n\n   * Vérifiez que les groupes sont sélectionnés dans le mappage des attributs SAML Google.\n   * Confirmez que l'« Attribut de l'application » est défini sur `groups` (minuscules).\n   * Réalisez un test de connexion SAML pour inspecter la réponse SAML.\n4. **Problème de calendrier ou de cache**\n\n   * Attendez 24 heures pour que les modifications Google se propagent complètement.\n   * Demandez à l'utilisateur de se déconnecter complètement de GitLab et Google.\n   * Effacez le cache du navigateur et réessayez.\n   * L'utilisateur doit se connecter via l'URL d'authentification unique SAML, pas la connexion GitLab normale.\n\n### L'utilisateur a un rôle incorrect\n\n**Problème** : l'utilisateur a accès mais possède le mauvais niveau d'autorisation.\n\n**Causes possibles et solutions** :\n\n1. **L'utilisateur appartient à plusieurs groupes**\n\n   * Rappel : les utilisateurs obtiennent le rôle **le plus élevé** de tous leurs groupes.\n   * Vérifiez tous les groupes Google auxquels l'utilisateur appartient.\n   * Examinez toutes les configurations de liens de groupe SAML à tous les niveaux.\n2. **Lien de groupe SAML mal configuré**\n\n   * Vérifiez le paramètre Niveau d'accès dans Paramètres > Liens de groupe SAML.\n   * Recherchez les mappages de groupes en double qui pourraient entrer en conflit.\n3. **L'utilisateur ne s'est pas connecté depuis les modifications**\n\n   * Les rôles ne se mettent à jour que lorsque les utilisateurs se connectent via SAML.\n   * Demandez à l'utilisateur de se déconnecter complètement et de se reconnecter via l'URL d'authentification SSO.\n4. **Autorisations héritées des groupes parents**\n\n   * Vérifiez les liens de groupe SAML dans les groupes parents.\n   * N'oubliez pas que les rôles plus élevés au niveau des groupes parents sont transmis aux groupes enfant.\n\n### L'authentification SAML échoue complètement\n\n**Problème** : les utilisateurs ne peuvent pas du tout se connecter ou reçoivent des messages d'erreur pendant l'authentification.\n\n**Causes possibles et solutions** :\n\n1. **Empreinte de certificat incorrecte**\n\n   * Vérifiez que vous avez utilisé le format SHA-1, et non SHA-256.\n   * Vérifiez que l'empreinte a le format correct avec des deux-points.\n   * Régénérez un certificat en utilisant l'outil en ligne ou la commande OpenSSL.\n2. **URL d'authentification unique incorrecte**\n\n   * Vérifiez à nouveau l'URL d'authentification unique copiée depuis Google.\n   * Assurez-vous qu'il n'y a pas d'espaces ou de caractères supplémentaires.\n3. **Incompatibilité de l'URL ACS ou de l'ID de l'entité**\n\n   * Vérifiez que l'URL ACS dans la console d'administration Google correspond exactement à GitLab.\n   * Confirmez que l'ID de l'entité correspond entre les deux systèmes.\n4. **L'utilisateur n'a pas d'accès à l'application**\n\n   * Vérifiez les paramètres d'accès utilisateur dans la console d'administration Google.\n   * Vérifiez que l'unité organisationnelle de l'utilisateur a l'application activée.\n   * Confirmez que l'application est activée pour les utilisateurs appropriés.\n5. **Certificat expiré**\n\n   * Vérifiez les dates de validité du certificat.\n   * Téléchargez un nouveau certificat si nécessaire.\n\n### Attribut de groupe manquant dans la réponse SAML\n\n**Problème** : les utilisateurs peuvent se connecter, mais la synchronisation des groupes ne fonctionne pas.\n\n**Causes possibles et solutions** :\n\n1. **Groupes non sélectionnés dans la configuration Google**\n\n   * Retournez à **Console d'administration Google > Applications > GitLab > Mappage des attributs**.\n   * Vérifiez que les groupes sont sélectionnés sous « Adhésion aux groupes ».\n   * Confirmez que l'« Attribut de l'application » est exactement `groups` (minuscules).\n2. **L'utilisateur n'est dans aucun groupe configuré**\n\n   * Seuls les groupes auxquels l'utilisateur appartient sont envoyés dans la réponse SAML.\n   * Ajoutez l'utilisateur à au moins un groupe sélectionné pour effectuer un test.\n3. **La configuration ne s'est pas propagée**\n\n   * Attendez jusqu'à 24 heures pour que les modifications prennent effet.\n   * Essayez de vous déconnecter de la console d'administration Google et de vous reconnecter.\n4. **Faute de frappe dans le nom de l'attribut de l'application**\n\n   * Le nom de l'attribut doit être exactement `groups` (minuscules).\n   * Une lettre majuscule ou un espace supplémentaire cassera la fonctionnalité.\n\n## Bonnes pratiques pour gérer la synchronisation de groupe SAML\n\nSuivez ces recommandations pour maintenir une configuration sécurisée et efficace.\n\n### Bonnes pratiques de sécurité\n\n1. **Maintenir un accès d'urgence**\n\n   * Conservez au moins un compte Propriétaire qui utilise l'authentification par mot de passe (pas SAML).\n   * Vous aurez un accès d'urgence si la configuration SAML ne fonctionne plus.\n   * Stockez ces identifiants de façon sécurisée.\n2. **Utiliser le principe du moindre privilège**\n\n   * Définissez l'adhésion par défaut sur Accès minimal.\n   * Accordez uniquement des autorisations plus élevées via des mappages de groupes explicites.\n   * Examinez et auditez régulièrement les adhésions aux groupes.\n3. **Activer les options d'application**\n\n   * Activez les options « Mettre en œuvre l'authentification unique SSO ».\n   * Cela empêche les utilisateurs de contourner l'authentification unique.\n   * Les exceptions doivent être rares et bien documentées.\n4. **Effectuer des audits de sécurité réguliers**\n\n   * Examinez tous les trimestre les adhésions aux groupes Google Workspace.\n   * Vérifiez chaque année les mappages de liens de groupe SAML.\n   * Surveillez les journaux d'audit GitLab pour détecter les schémas d'accès inhabituels.\n\n## Résumé et prochaines étapes\n\nFélicitations ! Vous avez configuré avec succès l'authentification unique basée sur le protocole SAML et la synchronisation automatique des groupes entre Google Workspace et GitLab. Votre configuration offre désormais :\n\n* **Une authentification transparente** : les utilisateurs se connectent avec leurs identifiants Google Workspace.\n* **Un provisionnement automatique** : les comptes utilisateur sont créés lors de la première connexion sans intervention manuelle.\n* **Des autorisations dynamiques** : les adhésions aux groupes et les rôles se mettent à jour automatiquement en fonction des groupes Google Workspace.\n* **Un contrôle d'accès centralisé** : gérez tous les accès via vos groupes Google Workspace existants.\n* **Une sécurité renforcée** : exploitez l'infrastructure d'authentification de Google et appliquez des politiques cohérentes.\n* **Une réduction de la charge administrative** : éliminez la gestion manuelle des utilisateurs et des autorisations dans GitLab.\n\n### Fonctionnement correct\n\nLorsque les utilisateurs accèdent à GitLab :\n\n1. Ils accèdent à votre URL d'authentification SSO GitLab.\n2. Ils s'authentifient avec leurs identifiants Google Workspace.\n3. Ils sont automatiquement ajoutés aux groupes GitLab appropriés.\n4. Ils reçoivent des autorisations basées sur leurs adhésions aux groupes Google.\n5. Leurs autorisations se mettent à jour chaque fois qu'ils se connectent.\n\n### Ressources supplémentaires\n\n* [Documentation concernant l'authentification unique basée sur le protocole SAML de GitLab](https://docs.gitlab.com/ee/user/group/saml_sso/)\n* [Documentation concernant la synchronisation des groupes SAML GitLab](https://docs.gitlab.com/ee/user/group/saml_sso/group_sync.html)\n* [Configuration de l'application SAML sur Google Workspace](https://support.google.com/a/answer/6087519?hl=fr&sjid=14836880554957868479-NA)\n* [Outil d'empreinte de certificat SAML](https://www.samltool.com/fingerprint.php)","2026-03-12","https://res.cloudinary.com/about-gitlab-com/image/upload/v1759320418/xjmqcozxzt4frx0hori3.png",[714],"Omid Khan","Découvrez comment automatiser le provisionnement des utilisateurs et synchroniser les autorisations avec les groupes Google dans ce guide détaillé.","Comment configurer l'authentification SSO SAML GitLab avec Google Workspace",{"featured":11,"template":12,"slug":718},"how-to-set-up-gitlab-saml-sso-with-google-workspace",{"promotions":720},[721,735,746],{"id":722,"categories":723,"header":725,"text":726,"button":727,"image":732},"ai-modernization",[724],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":728,"config":729},"Get your AI maturity score",{"href":730,"dataGaName":731,"dataGaLocation":245},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":733},{"src":734},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":736,"categories":737,"header":738,"text":726,"button":739,"image":743},"devops-modernization",[702,36],"Are you just managing tools or shipping innovation?",{"text":740,"config":741},"Get your DevOps maturity score",{"href":742,"dataGaName":731,"dataGaLocation":245},"/assessments/devops-modernization-assessment/",{"config":744},{"src":745},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":747,"categories":748,"header":749,"text":726,"button":750,"image":754},"security-modernization",[9],"Are you trading speed for security?",{"text":751,"config":752},"Get your security maturity score",{"href":753,"dataGaName":731,"dataGaLocation":245},"/assessments/security-modernization-assessment/",{"config":755},{"src":756},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":758,"blurb":759,"button":760,"secondaryButton":764},"Commencez à développer plus rapidement dès aujourd'hui","Découvrez ce que votre équipe peut accomplir avec la plateforme d'orchestration intelligente pour le DevSecOps.\n",{"text":48,"config":761},{"href":762,"dataGaName":51,"dataGaLocation":763},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/fr-fr/","feature",{"text":53,"config":765},{"href":55,"dataGaName":56,"dataGaLocation":763},1777309996494]