{"meta":{"title":"Donner à l’agent cloud GitHub Copilot l’accès aux ressources de votre organisation","intro":"Tirez davantage de Copilot en lui donnant accès aux serveurs MCP approuvés et aux paquets internes.","product":"GitHub Copilot","breadcrumbs":[{"href":"/fr/enterprise-cloud@latest/copilot","title":"GitHub Copilot"},{"href":"/fr/enterprise-cloud@latest/copilot/tutorials","title":"Tutoriels"},{"href":"/fr/enterprise-cloud@latest/copilot/tutorials/cloud-agent","title":"Agent de cloud"},{"href":"/fr/enterprise-cloud@latest/copilot/tutorials/cloud-agent/give-access-to-resources","title":"Accorder l’accès aux ressources"}],"documentType":"article"},"body":"# Donner à l’agent cloud GitHub Copilot l’accès aux ressources de votre organisation\n\nTirez davantage de Copilot en lui donnant accès aux serveurs MCP approuvés et aux paquets internes.\n\n```\n          Agent cloud Copilot peut se connecter aux serveurs MCP, utiliser des packages privés et accéder aux services externes, mais uniquement si les référentiels de votre organisation sont configurés pour l’autoriser.\n```\n\nBien que la majeure partie de la configuration ci-dessous soit effectuée au niveau du référentiel, les propriétaires de l'organisation contrôlent quelles ressources sont incluses dans la portée et qui peut configurer l'accès à celles-ci.\n\n## Exemple de scénario\n\nVotre organisation utilise Sentry pour suivre les bogues dans votre application Node. De nouvelles exceptions sont soulevées en tant que problèmes sur GitHub, et vos développeurs souhaitent attribuer ces derniers à Copilot.\n\nVous souhaitez Copilot :\n\n* Connectez-vous au serveur MCP Sentry afin qu’il puisse accéder aux détails de votre instance Sentry\n* Installer des dépendances, y compris des packages privés hébergés sur GitHub, pour générer votre application et exécuter des tests\n* Suivez les conventions de votre organisation pour la gestion des erreurs\n\n## Stockage sécurisé des secrets\n\nPar défaut, l’étendue du Copilotjeton d’authentification est limitée au référentiel où il est en cours d’exécution. Cela signifie que Copilot ne pourra pas s’authentifier auprès de systèmes externes ni accéder à des packages privés dans le périmètre de l'organisation.\n\nLes administrateurs du référentiel doivent ajouter les variables et secrets nécessaires à l'environnement dédié Copilot`copilot`GitHub Actions.\nCopilot peut accéder à ces données dans son installation et son exécution de tâche. Il ne pourra pas accéder aux variables ou secrets en dehors de cet environnement, tels que les secrets à l’échelle GitHub Actions de l’organisation.\n\n### Exemple : Enregistrer un secret\n\nUn administrateur de référentiel enregistre un jeton d’authentification pour l’instance Sentry de l’organisation.\n\n1. Accédez à la section **Environnements** des paramètres du référentiel.\n2. Créez un environnement appelé `copilot`.\n3. Enregistrez un jeton d’accès pour votre instance Sentry dans un secret d’environnement appelé `COPILOT_MCP_SENTRY_ACCESS_TOKEN`.\n\n> \\[!TIP] Nous n’avons pas besoin d’enregistrer un jeton pour notre registre privé GitHub Packages , auquel nous accéderons à l’aide de la norme GitHub Actions`GITHUB_TOKEN`. Toutefois, vous souhaitez enregistrer un jeton d’authentification si vous utilisiez un registre de packages externe.\n\n## Configuration de l’accès aux serveurs MCP\n\nLes propriétaires d’entreprise et d’organisation peuvent définir une stratégie pour permettre aux utilisateurs de configurer l’accès aux serveurs MCP. Si cette stratégie est activée, les utilisateurs peuvent configurer des serveurs MCP dans Agent cloud Copilot les paramètres du référentiel ou dans des profils d’agent personnalisés. Pour une cohérence à l’échelle de l’organisation, nous vous recommandons de créer des **profils d’agent personnalisés** au niveau de l’organisation ou de l’entreprise.\n\nUne session utilisant un agent personnalisé a accès aux serveurs MCP configurés **dans les** paramètres du référentiel et dans le profil de l’agent. Toutefois, plus vous couvrez les cas d’usage avec des agents personnalisés à l’échelle de l’organisation, moins les utilisateurs devront configurer l’accès ad hoc aux serveurs MCP dans les paramètres du référentiel.\n\nNous vous recommandons de parcourir le [GitHub Registre MCP](https://github.com/mcp) pour trouver des options approuvées et hautement évaluées.\n\n### Exemple : Créer un agent personnalisé\n\nUn propriétaire de l’organisation crée un profil d’agent personnalisé pour l’agent Sentry. Il a accès au serveur MCP Sentry et aux instructions personnalisées pour les conventions de gestion des erreurs de l’organisation.\n\n1. Créez un référentiel appelé `.github-private` dans votre organisation. Si vous le souhaitez, un propriétaire d’entreprise peut définir ce référentiel comme source pour tous les agents personnalisés de l’entreprise.\n\n2. Dans le référentiel, ajoutez un `agent.md` fichier avec un profil comme suit. Cela inclut la configuration du serveur MCP, qui fait référence au secret que nous avons enregistré.\n\n   ```text\n   ---\n   name: sentry-error-fixer\n   description: Proposed fixes for exception issues raised from Sentry\n   mcp-servers:\n     sentry:\n       type: 'local'\n       command: 'npx'\n       args: ['@sentry/mcp-server@latest']\n       env:\n         SENTRY_ACCESS_TOKEN: ${{ secrets.COPILOT_MCP_SENTRY_ACCESS_TOKEN }}\n   ---\n\n   You are an error resolution specialist. When you're assigned an issue created by our Sentry integration, check for error details and stack traces using the MCP server, then propose a fix.\n\n   Make sure you check that your proposed fix works by building the site with `npm run build` and running the test suite in `npm test`.\n   ```\n\n3. Lorsque les développeurs attribuent un problème Copilot, ils peuvent sélectionner l’agent personnalisé dans une liste déroulante.\n\n## Installation de packages privés\n\nLa meilleure façon de donner Copilot accès aux dépendances d’un projet consiste à les installer dans un `copilot-setup-steps.yml` fichier de flux de travail. Ce fichier définit la configuration de l’environnement avant Copilot de commencer à fonctionner.\n\nPour permettre au workflow de tirer vos packages privés à portée organisationnelle `GITHUB_TOKEN`, vous allez mettre à jour les paramètres du package pour vous assurer que le dépôt a accès au package. C'est plus sécurisé que l'utilisation d'une clé à durée de vie longue personal access token avec les autorisations de l'organisation.\n\n### Exemple : Installer les dépendances de Node.js\n\nUn développeur crée un flux de travail pour installer les dépendances node définies dans le fichier d’un `package-lock.json` dépôt. Cela inclut des paquets privés à l'échelle de l'organisation hébergés sur GitHub.\n\n1. Le développeur crée un `copilot-setup-steps.yml` fichier dans le référentiel.\n\n2. Ils ajoutent des étapes pour installer les dépendances du projet. Par exemple:\n\n   ```yaml\n   # ...\n\n   jobs:\n     copilot-setup-steps:\n       # ...\n\n       # You can define any steps you want, and they will run before the agent starts.\n       # If you do not check out your code, Copilot will do this for you.\n       steps:\n         - name: Checkout code\n           uses: actions/checkout@v6\n\n         - name: Set up Node.js\n           uses: actions/setup-node@v4\n           with:\n             node-version: \"20\"\n             cache: \"npm\"\n\n         - name: Install JavaScript dependencies\n           run: npm ci\n   ```\n\n3. Un administrateur d’organisation garantit que le référentiel a accès aux packages privés de l’organisation en lui accordant l’accès au référentiel dans les paramètres de chaque package. Consultez « [Configuration du contrôle d’accès et de la visibilité d’un package](/fr/enterprise-cloud@latest/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#github-actions-access-for-packages-scoped-to-organizations) ».\n\n> \\[!TIP] Si vous devez accéder aux packages hébergés en interne au sein de votre réseau d’entreprise, vous devrez peut-être exécuter Agent cloud Copilot sur des exécuteurs auto-hébergés GitHub Actions .\n\n## Contrôler qui peut configurer ces paramètres\n\nVous avez maintenant vu comment l’accès aux ressources est contrôlé au niveau du référentiel et de l’organisation, tenez compte de l’étendue que vous souhaitez donner aux utilisateurs pour gérer ces paramètres.\n\n1. ```\n          **Choisissez les référentiels auxquels**Agent cloud Copilotils ont accès. Si vous êtes préoccupé par un référentiel spécifique, vous pouvez le bloquer pour tous les utilisateurs.\n   ```\n2. ```\n          **Considérez qui obtient l’accès administrateur** à ces référentiels. Vous pouvez contrôler cela au niveau de l’organisation en créant une équipe avec le rôle personnalisé **administrateur de tous les référentiels** . Ces utilisateurs pourront gérer les _paramètres_ de configuration, tels que la configuration MCP et `copilot` les environnements, dans chaque référentiel.\n   ```\n3. ```\n          **Utilisez des ensembles de règles et des fichiers CODEOWNERS** pour contrôler les modifications des _fichiers_ de configuration, tels que `copilot-setup-steps.yml`, que toute personne disposant d’un accès en écriture peut modifier par défaut.\n   ```\n4. ```\n          **Passez en revue le pare-feu par défaut**. Le pare-feu n’affecte pas les connexions aux serveurs MCP ou les étapes de configuration, `copilot-setup-steps.yml`mais il limite Copilotl’accès à Internet pendant l’exécution de la tâche. Consultez « [AUTOTITLE](/copilot/how-tos/use-copilot-agents/cloud-agent/customize-the-agent-firewall) ».\n   ```"}