{"meta":{"title":"Planification d’une version d’évaluation de GitHub Advanced Security","intro":"Préparez votre organisation à évaluer Advanced Security en fonction des objectifs de sécurité et d’achat clairs.","product":"Sécurité et qualité du code","breadcrumbs":[{"href":"/fr/code-security","title":"Sécurité et qualité du code"},{"href":"/fr/code-security/tutorials","title":"Tutorials"},{"href":"/fr/code-security/tutorials/trialing-github-advanced-security","title":"Essai de GitHub Advanced Security"},{"href":"/fr/code-security/tutorials/trialing-github-advanced-security/planning-a-trial-of-ghas","title":"Plan d’essai GHAS"}],"documentType":"article"},"body":"# Planification d’une version d’évaluation de GitHub Advanced Security\n\nPréparez votre organisation à évaluer Advanced Security en fonction des objectifs de sécurité et d’achat clairs.\n\n## Un essai en libre-service vous convient-il ?\n\nCet article vous aide à planifier un essai **en libre-service** de GitHub Advanced Security. Un essai en libre-service est adapté à vos besoins si les deux conditions suivantes sont remplies :\n\n* Vous souhaitez réaliser votre essai de manière indépendante, sans l’aide d’un expert ou d’un partenaire. Cela convient généralement aux petites ou moyennes organisations.\n* Vous êtes propriétaire d’une organisation éligible sur GitHub Team.\n\nSi vous souhaitez obtenir de l’aide d’expert pour votre essai, [contactez notre équipe](https://github.com/enterprise/contact).\n\nLes organisations sur GitHub Team peuvent commencer un essai avec n’importe quel mode de paiement. Pour effectuer un achat via le processus de paiement de l’essai, l’organisation doit payer par carte bancaire, PayPal ou Azure.\n\n## 1. Définir les objectifs de votre entreprise\n\nAvant de commencer une version d’évaluation, définissez son objectif et identifiez les questions clés à répondre. Gardez ces objectifs au focus lorsque vous planifiez afin que vous collectiez les informations dont vous avez besoin pour décider s’il faut mettre à niveau.\n\nSi votre entreprise utilise GitHubdéjà, tenez compte des besoins actuellement non satisfaits qui Secret Protection or Code Security peuvent être résolus. Vous devez également tenir compte de la posture actuelle de votre application en matière de sécurité et de vos objectifs à long terme. Pour plus d’inspiration, consultez [Principes de conception pour la sécurité](https://wellarchitected.github.com/library/application-security/design-principles/) des applications dans la GitHub documentation bien conçue.\n\n<div class=\"ghd-tool rowheaders\">\n\n| Exemple de besoin                                          | Fonctionnalités à explorer pendant l’essai                                                                                                                                                                                                                                                                                                                                                                                                                  |\n| ---------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Renforcer l’utilisation des fonctionnalités de sécurité    | Configurations et stratégies de sécurité. Voir [Activation des fonctionnalités de sécurité à grande échelle](/fr/code-security/concepts/security-at-scale/organization-security).                                                                                                                                                                                                                                                                           |\n| Protéger les jetons d’accès personnalisés                  | Modèles personnalisés pour secret scanning, contournement délégué pour la protection push, et vérifications de validité. Voir [Analyse de secrets](/fr/code-security/concepts/secret-security/secret-scanning).                                                                                                                                                                                                                                             |\n| Définir et appliquer un processus de développement         | Révision des dépendances, règles de triage automatique et ensembles. Consultez [Vérification des dépendances](/fr/code-security/concepts/supply-chain-security/dependency-review), [Règles de triage automatique de Dependabot](/fr/code-security/concepts/supply-chain-security/dependabot-auto-triage-rules) et [À propos des ensembles de règles](/fr/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets). |\n| Réduire la dette technique à grande échelle                | Campagnes de sécurité. Consultez [À propos des campagnes de sécurité](/fr/code-security/concepts/security-at-scale/about-security-campaigns).                                                                                                                                                                                                                                                                                                               |\n| Surveiller et suivre les tendances des risques de sécurité | Vue d’ensemble de la sécurité. Consultez « [Affichage des aperçus de sécurité](/fr/code-security/how-tos/view-and-interpret-data/analyze-organization-data/viewing-security-insights) ».                                                                                                                                                                                                                                                                    |\n\n</div>\n\n## 2. Identifier les membres de votre équipe pour l’essai\n\nGitHub Advanced Security vous permet d’intégrer des mesures de sécurité tout au long du cycle de vie du développement logiciel. Incluez des représentants de tous les domaines de votre cycle de développement afin que vous disposiez des données dont vous avez besoin pour prendre une décision.\n\nIl peut également s’avérer utile d’identifier un champion pour chaque besoin de l’entreprise que vous souhaitez étudier.\n\n## 3. Déterminer la nécessité de recherches préliminaires\n\n**Avant** de commencer votre essai, déterminez si votre équipe pourrait tirer profit d’une expérience pratique de nos fonctionnalités de sécurité gratuites. Le test de l’analyse du code et de l’analyse des secrets sur les référentiels publics peut aider les nouveaux utilisateurs à se familiariser avec les principales fonctionnalités de GitHub Advanced Security. Cela vous permet de concentrer votre période d’évaluation sur les dépôts privés et les fonctionnalités et contrôles avancés disponibles dans Secret Protection and Code Security.\n\nPour plus d’informations, consultez :\n\n* [Activation de l’analyse des secrets pour votre dépôt](/fr/code-security/how-tos/secure-your-secrets/detect-secret-leaks/enable-secret-scanning)\n* [Définition de la configuration par défaut pour l’analyse du code](/fr/code-security/how-tos/find-and-fix-code-vulnerabilities/configure-code-scanning/configure-code-scanning)\n* [Activation du graphe de dépendances](/fr/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/enable-dependency-graph)\n\nLes organisations sur GitHub Team et GitHub Enterprise peuvent exécuter un rapport gratuit pour analyser leur code et détecter les informations sensibles divulguées. Cela vous aide à évaluer l’exposition actuelle de vos dépôts aux secrets divulguées et montre le nombre de fuites de secrets existantes qui auraient pu être évitées par Secret Protection. Consultez « [Sécurité secrète avec GitHub](/fr/code-security/concepts/secret-security/secret-security-with-github) ».\n\n## 4. Déterminer les référentiels à tester\n\nIl est généralement préférable d’utiliser une organisation et des référentiels **existants** . Cela garantit que vous pouvez expérimenter les fonctionnalités du code que vous connaissez bien et dans un environnement de développement familier.\n\nSi vous le souhaitez, ajoutez du code de test ultérieurement. Toutefois, les applications délibérément non sécurisées, telles que WebGoat, ne sont pas les meilleurs tests. Ils peuvent contenir des modèles de code qui semblent non sécurisés, mais que code scanning détermine ne peuvent pas être exploités. Par conséquent, code scanning peut signaler moins de problèmes dans ces bases de code artificielles que d’autres scanneurs de sécurité.\n\n## 5. Définir les critères d’évaluation de l’essai\n\nPour chaque besoin ou objectif de l’entreprise que vous définissez pour l’essai, déterminez la façon dont vous allez mesurer le succès. Par exemple, si vous souhaitez imposer l’utilisation de fonctionnalités de sécurité, créez des cas de test pour les configurations et les politiques dans ce domaine, afin de confirmer qu’elles fonctionnent comme prévu.\n\n## 6. Commencer votre essai\n\nSi vous êtes propriétaire d’une organisation éligible sur GitHub Team, consultez [Configuration d’un essai de GitHub Advanced Security](/fr/code-security/tutorials/trialing-github-advanced-security/trial-advanced-security).\n\n> \\[!NOTE]\n> GitHub Advanced Security est gratuit pendant les essais, mais la facturation basée sur l’utilisation s’applique aux fonctionnalités qui consomment GitHub Actions des minutes ou AI credits."}