Les pipelines CI/CD sont la colonne vertébrale de la livraison logicielle moderne, permettant aux équipes de déployer du code rapidement et de manière fiable. Mais, cette vitesse et cette efficacité s'accompagnent de risques de sécurité sérieux. En effet, des pipelines compromis peuvent permettre à des attaquants d'injecter du code malveillant, de dérober des données sensibles ou même d'accéder aux systèmes de production.
À mesure que les entreprises accélèrent leur transformation numérique, sécuriser les pipelines CI/CD n'est plus une option, mais un impératif pour protéger l'ensemble du processus de développement logiciel. Aujourd'hui, la sécurité CI/CD est plus critique que jamais. Par exemple, le rapport « State of Code Security 2025 » de Wiz a révélé que 35 % des grandes entreprises s'appuient sur des runners auto-hébergés avec des configurations plus faibles, les exposant à des mouvements latéraux. Prioriser la sécurité CI/CD est donc urgent, pas optionnel.
Si vous êtes ici, c'est pour découvrir comment sécuriser votre propre pipeline CI/CD et appliquer les meilleures pratiques de sécurité CI/CD — le tout sans ralentir les workflows ni freiner l'innovation de vos équipes.
Bonnes pratiques CI/CD [Fiche Mémo]
Ce guide complet vous présente des mesures concrètes pour réduire les risques de sécurité liés à vos pipelines CI/CD.
Sécurité CI/CD : rappel
Les pipelines CI/CD fluidifient le déploiement logiciel, mais introduisent aussi de multiples vulnérabilités tout au long du cycle de développement. Comme ces pipelines ont un accès direct au code source, aux environnements de production et à des identifiants sensibles, ils sont devenus des cibles de choix pour les attaquants.
Un seul composant compromis peut permettre la distribution de code malveillant à tous vos utilisateurs, provoquant des fuites de données, des interruptions de service ou des manquements de conformité. Il est donc essentiel de comprendre les principaux risques de sécurité de l'infrastructure CI/CD pour mettre en place les bonnes protections.
Composants à risque
Dans un pipeline CI/CD, les composants suivants sont exposés aux attaques :
Dépôts de code source : là où les développeurs stockent et gèrent le code.
Serveurs et workers de build : utilisés pour compiler le code en artefacts exécutables.
Dépôts d'artefacts : où les équipes conservent les artefacts de build pour le déploiement.
Environnements de déploiement : là où l'application est déployée et s'exécute.
CI runners (comme les runners hébergés par GitHub) : ces composants sont souvent sur-privilégiés et sous-surveillés.
Outils d'orchestration (comme ArgoCD ou Spinnaker) : des attaquants peuvent les exploiter pour des mouvements latéraux.
Chacun de ces composants nécessite des mesures de sécurité spécifiques pour empêcher les accès non autorisés et les altérations.
Défis de la sécurité CI/CD
Sécuriser des pipelines CI/CD pose les défis suivants :
Complexité : la diversité et l'interconnexion des composants rendent la sécurisation complexe.
Vitesse : le rythme rapide du CI/CD peut dépasser les mesures de sécurité et laisser des vulnérabilités.
Automatisation : atout majeur du CI/CD, elle devient faiblesse sans security controls automatisés.
Contrôle d'accès : l'octroi d'accès aux différents composants du pipeline est délicat, surtout avec de grandes équipes.
Prolifération des secrets : les solutions CI/CD contiennent souvent de nombreux secrets — sans contrôles d'accès adaptés, ces secrets peuvent facilement fuiter.
Sécurité de la chaîne d'approvisionnement : l'usage d'outils CI/CD SaaS comme GitLab et CircleCI peut introduire des enjeux de supply chain security.
Actions et plug-ins tiers non vérifiés : des workflows CI/CD réutilisables peuvent introduire des chevaux de Troie.
Identifiez les risques liés au code avant le déploiement
Découvrez comment Wiz Code analyse l'IaC, les conteneurs et les pipelines pour bloquer les mauvaises configurations et les vulnérabilités avant qu'elles n'atteignent votre environnement cloud.
Bonnes pratiques et recommandations pour la sécurité CI/CD
Sécuriser des pipelines CI/CD impose d'embarquer la sécurité tout au long du cycle de développement, du scan du code et de la gestion des secrets jusqu'au verrouillage de l'infrastructure et des accès.
Les bonnes pratiques suivantes aident à protéger les pipelines sans casser la vélocité :
Automatiser les analyses de sécurité
Les analyses de sécurité automatisées sont indispensables pour détecter en temps réel les vulnérabilités — d'autant plus avec la montée de la DevSecOps, qui intègre la sécurité dans le processus de développement. Elles facilitent les contrôles continus, détectent immédiatement des vulnérabilités et notifient rapidement les développeurs, réduisant ainsi le risque de publier du code compromis.
Intégrez des outils de sécurité comme SonarQube ou Checkmarx dans votre pipeline CI/CD pour réaliser des analyses statiques et dynamiques du code applicatif. Ces outils identifient des vulnérabilités comme l'injection SQL, le cross-site scripting et des références d'objets non sécurisées.
# Example of SonarQube integration in a Jenkins pipeline
pipeline {
agent any
stages {
stage('SonarQube Analysis') {
steps {
script {
def scannerHome = tool 'SonarQube Scanner';
withSonarQubeEnv('My SonarQube Server') {
sh "${scannerHome}/bin/sonar-scanner"
}
}
}
}
}
}Une fois les outils choisis, mettez en place des déclencheurs automatiques dans votre pipeline. Configurez votre système CI/CD pour lancer des scans de sécurité immédiatement après chaque commit — via des webhooks ou du polling SCM en temps réel.
Configurez vos outils de sécurité pour transmettre les alertes de vulnérabilités directement aux équipes de développement sur Slack, Microsoft Teams ou par e-mail.
Se concentrer sur le runtime
Étendez votre approche au-delà de l'analyse statique grâce à la surveillance runtime et à des outils de réponse aux incidents. Exemples :
Outils SIEM/SOAR : connectez les logs et événements de votre pipeline CI/CD à des plateformes de Security Information and Event Management (SIEM) ou de Security Orchestration, Automation, and Response (SOAR) comme Splunk ou IBM QRadar pour détecter des activités suspectes et déclencher des réponses automatisées.
Détection d'anomalies : déployez des systèmes de détection d'anomalies basés sur le machine learning qui établissent un comportement de référence pour vos opérations CI/CD et alertent les équipes sécurité en cas de schémas inhabituels (commits hors horaires, configurations de pipeline anormales, consommation atypique de ressources).
Playbooks de réponse aux incidents : créez des playbooks spécifiques au CI/CD décrivant précisément les actions des équipes sécurité lors de suspicions de compromission, avec des procédures d'isolement des composants compromis, de rollback des déploiements suspects et d'investigation forensique.
Mesures de confinement automatisées : configurez le pipeline pour placer automatiquement en quarantaine des builds suspects et déclencher des contrôles de sécurité supplémentaires en cas de comportement anormal, afin d'éviter que du code potentiellement compromis n'atteigne la production.
Intégrez des tests dynamiques de sécurité des applications (DAST) à votre pipeline pour scanner automatiquement les applications en cours d'exécution et détecter des vulnérabilités à l'exécution que l'analyse statique peut manquer, avant la mise en production.
Gérer efficacement les secrets
Les organisations qui utilisent des pipelines CI/CD doivent mettre en place une gestion des secrets efficace pour les clés API, les identifiants et les secrets de configuration afin de protéger les données sensibles contre les accès non autorisés.
De bonnes solutions de gestion des secrets empêchent aussi des identifiants divulgués de provoquer des incidents. Des outils comme HashiCorp Vault ou AWS Secrets Manager offrent des fonctionnalités telles que des secrets dynamiques, la révocation de secrets et des journaux d'audit détaillés qui renforcent la posture de sécurité. Par ailleurs, des hooks pre-commit et des outils de secret scanning imposent des standards de code et évitent le hardcoding de secrets dans votre codebase.
Effectuez une rotation régulière des secrets et des clés en vous appuyant sur des politiques automatisées et les API de vos outils de gestion des secrets. Cela réduit la fenêtre d'opportunité des acteurs malveillants.
Mettre en œuvre une infrastructure immuable
Structurez vos dépôts de code avec des frontières de sécurité claires, mettez en place des pipelines de validation rigoureux qui scannent les vulnérabilités et sécurisez vos fichiers d'état et variables sensibles. Une détection régulière du drift aide à repérer des changements non autorisés, tandis que des pratiques GitOps garantissent que toute modification d'infrastructure passe par des revues de sécurité appropriées et conserve des pistes d'audit complètes. Ensemble, ces pratiques transforment la gestion d'infrastructure en un processus sûr et reproductible, réduisant l'erreur humaine et renforçant votre posture.
Pour y parvenir, utilisez des outils de conteneurisation comme Docker et des plateformes d'orchestration comme Kubernetes afin d'obtenir des déploiements uniformes et immuables sur différents environnements. Des outils d'Infrastructure as Code (IaC) comme Terraform ou AWS CloudFormation garantissent également des déploiements d'infrastructure cohérents et sécurisés.
Concevez des stratégies de rollback qui recréent des environnements entièrement à partir des définitions IaC afin de revenir à un état sûr et connu en cas de problème.
Mettre en place le RBAC
Un contrôle d'accès basé sur les rôles (RBAC) efficace commence par une définition claire des rôles et un périmétrage précis des permissions selon le principe du moindre privilège (PoLP). Les organisations qui réussissent leur RBAC mettent souvent en place des niveaux de permissions sur des plateformes comme Jenkins et sécurisent des comptes d'automatisation via la rotation régulière des identifiants et des restrictions d'IP. Nombre d'implémentations robustes dissocient aussi l'approbation et le déploiement afin qu'aucune personne ne contrôle à elle seule l'ensemble de la release.
De plus, des approches multicouches intègrent souvent le principe des quatre yeux pour les opérations critiques, exigeant des approbations indépendantes pour les actions sensibles. Des environnements CI/CD bien sécurisés s'appuient également sur des comptes d'automatisation aux frontières de privilèges strictes et sur une journalisation centralisée qui surveille les activités inhabituelles. Cette architecture défensive multicouche répond aux menaces internes potentielles tout en préservant l'efficacité des workflows des équipes de développement.
Planifiez des revues d'accès périodiques pour confirmer la pertinence des permissions, activez la détection automatisée des comptes inactifs, demandez des certifications managériales des besoins d'accès et déployez des workflows simplifiés pour ajuster rapidement les accès lors de changements de rôle. Ces défenses en profondeur protègent l'infrastructure CI/CD tout en préservant la vélocité et l'efficacité opérationnelle.
Sensibiliser et former les équipes
Au lieu de traiter la sécurité comme une fonction séparée, faites des développeurs une partie intégrante de votre dispositif de sécurité. La sécurité fonctionne mieux quand vous impliquez les développeurs tôt et souvent, plutôt que de la reléguer en fin de cycle.
Investissez donc dans des formations qui permettent aux équipes de développement et d'exploitation d'identifier les risques au fil de la construction. La création de champions sécurité dans les équipes de développement contribue aussi à instaurer une culture où la sécurité est l'affaire de tous, et pas seulement de l'équipe sécurité.
En plus des scans automatisés, réalisez des évaluations de sécurité et des tests d'intrusion réguliers en présence des équipes de développement. Cette collaboration permet d'identifier des vulnérabilités potentielles dans vos pipelines et sert de mise en situation concrète pour renforcer la sensibilisation sécurité des développeurs.
Créez des consignes et une documentation de sécurité claires auxquelles les équipes peuvent se référer facilement lorsqu'elles construisent et maintiennent des pipelines CI/CD, ou mettez en place des commentaires contextuels dans les pull requests.
Les différents types de pipelines CI/CD
Chaque pipeline CI/CD apporte ses propres défis de sécurité à mesure qu'il évolue avec les workflows de développement. Si vos équipes sécurité comprennent le fonctionnement des différentes architectures, elles peuvent mieux adapter leurs défenses et appliquer les bonnes pratiques plus efficacement.
Voici cinq types à connaître :
1. Pipelines CI/CD traditionnels
Ces pipelines enchaînent des étapes automatisées pour builder, tester et déployer des applications. On les retrouve souvent sur des outils comme Jenkins ou Atlassian Bamboo.
Principales préoccupations de sécurité :
Contrôler les accès aux déclencheurs du pipeline et aux secrets ;
Sécuriser l'environnement de build contre les altérations ou les changements non autorisés ;
Garantir l'intégrité des artefacts tout au long du pipeline (via des checksums ou des signatures numériques).
2. Pipelines GitOps
Les pipelines GitOps utilisent des dépôts Git comme source de référence pour gérer les configurations applicatives et d'infrastructure, généralement de façon déclarative avec des outils comme ArgoCD ou Flux. Ils offrent de vrais avantages de sécurité, comme la gestion versionnée des changements et des pistes d'audit claires.
Cependant, des risques apparaissent si :
les équipes stockent des secrets ou identifiants directement dans Git (par exemple en YAML en clair) ;
les contrôles d'accès sur les dépôts et sur les agents GitOps sont trop permissifs.
Des agents GitOps compromis peuvent permettre à des attaquants de déployer une infrastructure malveillante directement en production. Des outils comme Sealed Secrets, HashiCorp Vault ou SOPS aident à gérer vos données sensibles de manière plus sûre.
3. Pipelines à base de conteneurs
Ces pipelines s'appuient sur des outils de conteneurisation comme Docker et Kubernetes pour garantir des builds et des déploiements cohérents entre environnements.
Points d'attention clés :
Scanner les images de conteneurs à la recherche de vulnérabilités ;
Durcir les registres de conteneurs et appliquer le principe du moindre privilège (PoLP) ;
Surveiller les menaces runtime dans les conteneurs déployés.
4. Pipelines serverless
Les pipelines CI/CD serverless s'appuient sur des services entièrement managés comme GitHub Actions, AWS CodeBuild ou Google Cloud Build pour orchestrer les workflows sans gérer l'infrastructure. Ils sont extensibles, réduisent la charge opérationnelle et simplifient le quotidien.
Mais ils impliquent aussi ces considérations :
Gérer des politiques IAM granulaires ;
Comprendre le modèle de responsabilité partagée ;
Empêcher l'escalade de privilèges au sein des workflows et entre comptes.
Les environnements d'exécution sont éphémères : une journalisation et une supervision solides sont donc essentielles pour maintenir la visibilité.
5. Pipelines hybrides
De nombreuses organisations combinent plusieurs approches : GitOps pour l'infrastructure, conteneurs pour les applications, et outils serverless pour l'orchestration. Résultat : un écosystème de sécurité complexe qui s'étend sur des clouds, des plateformes et des pipelines.
Par conséquent, les équipes sécurité opérant des pipelines hybrides doivent :
Maintenir la visibilité sur l'ensemble des toolchains ;
Appliquer des politiques cohérentes pour la gestion des secrets, les accès et la conformité ;
Standardiser l'identification et la remédiation des risques entre environnements.
Les politiques de sécurité doivent couvrir le code, les conteneurs, l'infrastructure et le cloud pour rester efficaces.
Bonnes pratiques de développement sécurisé [Fiche mémo]
Cette fiche mémo est conçue pour être votre ressource de référence complète afin d'intégrer la sécurité à chaque étape du développement de votre code.
Les étapes des pipelines CI/CD
Les pipelines CI/CD comportent quatre étapes reliées, chacune avec des besoins de sécurité spécifiques. Voici leur décomposition :
Étape source
Les développeurs écrivent le code dans différents environnements de programmation.
La sécurité se concentre sur les contrôles d'accès aux dépôts.
L'analyse statique du code identifie tôt les vulnérabilités de base.
Les règles de protection des branches empêchent les modifications non autorisées.
Étape build
Le code source est combiné avec des dépendances et des librairies.
Les équipes créent des exécutables et des artefacts.
Les dépendances sont vérifiées et les scripts validés.
Les composants tiers exigent une attention particulière pour prévenir les attaques de la chaîne d'approvisionnement.
Étape test
Les builds subissent des tests dynamiques approfondis.
Des contrôles de sécurité spécialisés détectent des vulnérabilités que l'analyse statique peut manquer.
Des tests de sécurité applicative interactifs (IAST) simulent des attaques réelles.
Les environnements de test reflètent la configuration de la production.
Étape déploiement
Les builds validés sont préparés pour la production.
Des security controls stricts au niveau des environnements protègent les actifs de production.
Des contrôles d'accès limitent les capacités de déploiement.
La validation de la configuration garantit des paramètres de release sûrs.
Une surveillance post-déploiement identifie des problèmes de sécurité potentiels.
Ainsi, en embarquant la sécurité à chaque étape, les organisations peuvent continuer à développer rapidement tout en minimisant le risque d'incident.
État des lieux de la sécurité du code [2025]
Des secrets exposés et dépôts publics aux pratiques CI/CD à risque, notre étude révèle que la facilité du développement moderne rend souvent la sécurité plus complexe à assurer.
Télécharger
Sécurité CI/CD : quelles sont vos responsabilités ?
Le modèle de responsabilité partagée définit qui est responsable de quoi selon les couches — le fournisseur de services cloud ou l'organisation cliente.
Si les fournisseurs assurent la sécurité physique de l'infrastructure, la disponibilité de la plateforme et la gestion des mises à jour de sécurité de base, c'est votre organisation qui porte la responsabilité de la posture globale. Concrètement, vous devez configurer des pipelines sécurisés, gérer la sécurité du code et des dépendances, mettre en place des contrôles d'accès adaptés et protéger les données sensibles dans tous les environnements.
En s'appuyant sur les étapes CI/CD décrites plus haut, voici les responsabilités de sécurité spécifiques au sein du modèle de responsabilité partagée à chaque phase :
Responsabilités à l'étape source
Faire respecter des pratiques de codage sécurisé au sein des équipes de développement.
Mettre en place des protections robustes des dépôts, y compris des politiques de branches.
Rendre obligatoires les revues de code avec des points de contrôle sécurité.
Maintenir des contrôles d'accès sûrs aux dépôts de code source.
Responsabilités à l'étape build
Sécuriser les environnements de build contre les accès non autorisés.
Scanner les dépendances et composants tiers pour détecter des vulnérabilités.
Protéger les artefacts de build contre les altérations ou modifications non autorisées.
Valider les scripts de build et les outils d'automatisation au regard de la sécurité.
Responsabilités à l'étape test
Intégrer des outils de test de sécurité complets dans les workflows de test.
Assurer une couverture adéquate des différentes classes de vulnérabilités.
Traiter les failles identifiées avant de laisser progresser le code.
Documenter les résultats des tests de sécurité pour la conformité et les audits.
Responsabilités à l'étape déploiement
Valider les configurations de sécurité avant le déploiement en production.
Mettre en place des pratiques de déploiement sûres, y compris des gates d'approbation.
Contrôler l'accès aux environnements avec des frontières de permission granulaires.
Surveiller les applications déployées pour détecter des anomalies de sécurité.
En opérations courantes, maintenez une journalisation approfondie, surveillez les anomalies de sécurité et définissez des procédures de réponse aux incidents claires pour traiter les menaces émergentes. Cette approche en couches assure une sécurité complète tout au long du cycle de développement.
Quels sont les composants de la sécurité CI/CD ?
Une stratégie complète de sécurité CI/CD inclut les composants suivants :
Static Application Security Testing (SAST) : analyse le code source pour identifier des vulnérabilités (injection SQL, cross-site scripting, patterns de code non sécurisés) avant la compilation. Intégré tôt, le SAST permet de corriger avant la production.
Software Composition Analysis (SCA) : scanne les dépendances pour les vulnérabilités connues et les questions de licences. Les outils SCA offrent de la visibilité sur les bibliothèques tierces et composants, afin de maîtriser l'open source de manière sécurisée.
DAST : détecte des vulnérabilités runtime dans les applications en cours d'exécution que l'analyse statique peut manquer. Il met aussi en évidence des problèmes d'authentification, de gestion de session et des erreurs de configuration serveur.
Scan IaC : évalue les définitions d'infrastructure pour détecter des erreurs de configuration et des problèmes de sécurité. En scannant Terraform, CloudFormation et autres fichiers IaC, vous évitez des déploiements non sécurisés avant mise en œuvre.
Scan de sécurité des conteneurs : examine les images pour des vulnérabilités, malwares et erreurs de configuration, afin d'empêcher le déploiement d'images compromises en production.
Gestion des secrets : stocker, accéder et faire tourner de façon sécurisée des identifiants tout au long du pipeline. Une bonne gestion protège vos clés API, mots de passe et autres informations sensibles contre l'exposition.
Comment évaluer la robustesse de votre sécurité CI/CD
Pour mesurer et améliorer efficacement votre posture, concentrez-vous sur ces indicateurs clés de performance (KPI) :
Taux de détection des vulnérabilités : mesure l'efficacité de vos outils à identifier les problèmes par rapport au total des vulnérabilités présentes. Établissez une référence via des tests d'intrusion périodiques, comparez les vulnérabilités découvertes à celles détectées automatiquement et comparez les taux entre outils pour repérer les angles morts.
Délai moyen de remédiation (MTTR) : indique la rapidité de résolution après détection. Suivez le MTTR en étiquetant les tickets liés à la sécurité et en enregistrant automatiquement des timestamps à chaque étape. Décliner cet indicateur par sévérité permet de prioriser les vulnérabilités critiques tout en préservant la santé globale.
Conformité aux politiques de sécurité du pipeline : pourcentage de pipelines respectant les standards de sécurité de l'organisation. Définissez des politiques claires en formats lisibles par machine et intégrez des contrôles de conformité à vos systèmes CI/CD. Des tableaux de bord montrant l'évolution de la conformité mettent en évidence les violations nécessitant une attention immédiate.
Couverture des tests de sécurité : mesure dans quelle mesure vos tests couvrent votre base de code et vos composants d'infrastructure. Générez des rapports de couverture, agrégés par type de test, et mappez la couverture à votre modèle de menace pour cibler les zones à risque élevé.
Taux d'échec des builds dû à la sécurité : mesure la fréquence à laquelle les contrôles de sécurité empêchent l'achèvement des builds, indicateur de l'application de la sécurité et de la sensibilisation des développeurs. Catégorisez les échecs dans votre système CI/CD, distinguez les échecs sécurité des problèmes fonctionnels et suivez ce taux en parallèle de la vélocité de déploiement pour éviter de freiner la livraison.
L'approche de Wiz pour la sécurité CI/CD
Mesurer et améliorer votre posture de sécurité CI/CD peut parfois ressembler à tirer dans le noir.
C'est là que Wiz intervient. Wiz Code, par exemple, replace la sécurité applicative dans le contexte de votre environnement cloud runtime. Il corrèle aussi les erreurs de configuration IaC, les vulnérabilités au niveau du code et les signaux de risque cloud afin d'aider les équipes à prioriser ce qui est exploitable, pas seulement ce qui est pré
Démo de 5 min : Comment Wiz sécurise les pipelines CI/CD
Découvrez comment Wiz se connecte à vos dépôts de code, plateformes de données, fournisseurs d'identité, pipelines CI/CD et clusters Kubernetes pour révéler les risques réels avec un contexte complet.
Voir la démo
Vous faites face à des défis CI/CD complexes ? Vous pouvez tirer parti de Wiz Code pour renforcer votre posture tout en préservant la vélocité de développement. Voici comment :
Intégration sécurité simplifiée : pour les équipes submergées par de multiples outils, Wiz fournit une solution unifiée qui s'intègre nativement aux plateformes CI/CD populaires comme Jenkins, GitLab et CircleCI, sans perturber les workflows existants.
Détection précoce des vulnérabilités : l'approche shift-left de Wiz permet d'identifier les problèmes avant la production, avec des retours immédiats sur les risques dans le code, les définitions d'infrastructure et les dépendances pendant les phases de développement.
Protection de bout en bout : pour une visibilité complète du pipeline, Wiz offre des capacités intégrées couvrant du code applicatif à l'infrastructure cloud, afin d'établir une approche de sécurité cohérente sur tout le cycle de vie applicatif.
Des outils comme le Security Graph de Wiz offrent également une visibilité globale sur votre posture CI/CD avec une représentation visuelle des vulnérabilités, de leurs relations et des chemins d'attaque potentiels. Ainsi, les équipes sécurité peuvent prioriser la remédiation selon le risque réel plutôt que sur des scores génériques.
En répondant à ces besoins critiques tout en préservant la vitesse de développement, Wiz aide les organisations à construire des pipelines CI/CD sûrs qui soutiennent leurs objectifs métier au lieu de les freiner.
Prêt à élever votre sécurité CI/CD ? Téléchargez dès aujourd'hui les Bonnes pratiques de sécurité CI/CD de Wiz pour sécuriser chaque étape de votre pipeline.
Sécurisez vos workloads, du build au runtime
Découvrez pourquoi Wiz est l'une des rares plateformes de sécurité cloud que les équipes Sécurité et DevOps adorent utiliser.
Autres bonnes pratiques de sécurité susceptibles de vous intéresser :