# Clés d'API (/fr/docs/platform/integrations/api-keys)





Une clé d'API permet à un script ou à un service d'appeler l'API CentralCSP sans qu'une personne se connecte.

**Paramètres** > **Clés d'API**, réservé aux **Admins** de l'espace de travail, sur un plan qui inclut l'accès API.

## Créer une clé [#créer-une-clé]

**Créer une clé d'API**, puis :

| Champ         | Notes                                                                     |
| ------------- | ------------------------------------------------------------------------- |
| Nom           | Obligatoire. Nommez-la d'après son consommateur, par exemple `CI deploy`  |
| Expiration    | Date facultative, au plus tôt demain. Vide signifie sans expiration       |
| IP autorisées | Facultatif. Adresses ou plages CIDR, une par ligne. Vide signifie partout |

<Callout type="warn" title="Le secret est affiché une seule fois">
  Copiez la clé immédiatement après sa création. Elle n'est jamais réaffichée, et il n'y a aucun moyen de la récupérer. Si vous la perdez, révoquez la clé et créez-en une autre.
</Callout>

Les IP autorisées acceptent IPv4 et IPv6, avec des préfixes CIDR facultatifs, jusqu'à 50 entrées :

```text
203.0.113.10
198.51.100.0/24
2001:db8::/32
```

<img alt="Le tableau des clés API, chaque valeur de clé masquée, avec les colonnes IP autorisées, dernière utilisation, expiration et création" src="__img0" width="1242" height="325" />

## Les clés n'ont aucun scope [#les-clés-nont-aucun-scope]

C'est le point à comprendre avant d'en créer une.

Une clé **agit comme la personne qui l'a créée**, avec les rôles actuels de cette personne, et n'atteint que l'espace de travail où elle a été créée. Il n'y a aucun moyen de donner à une clé des permissions plus étroites que celles de son créateur.

Deux conséquences :

* Une clé créée par un Admin de l'espace de travail peut atteindre **tous les sites web**, puisque les Admins le peuvent.
* Si les rôles du créateur changent, la portée de la clé change avec eux.

Pour limiter ce qu'une clé peut faire, créez-la depuis un compte qui n'a que l'accès dont l'intégration a besoin. En général, cela veut dire un Membre de l'espace de travail avec des accès sur des sites précis, pas un Admin.

## Une clé ne se modifie pas [#une-clé-ne-se-modifie-pas]

L'expiration et les IP autorisées se définissent à la création seulement. Changer l'une ou l'autre implique de révoquer la clé et d'en émettre une nouvelle.

Décidez des deux dès le départ. Une clé sans restriction et sans expiration est ce que vous obtenez en cliquant sans réfléchir, et c'est celle que vous regretterez.

## Révoquer [#révoquer]

Menu de la ligne, **Révoquer**. Les requêtes utilisant la clé sont rejetées dès l'appel suivant. Il n'y a ni annulation ni restauration.

Révoquez quand une intégration est démantelée, quand le compte créateur quitte l'organisation, ou quand une clé n'a jamais servi et que personne ne sait à quoi elle devait servir. La colonne **Dernière utilisation** affichant **Jamais** sur une vieille clé est une raison suffisante.

## Passer les clés en revue [#passer-les-clés-en-revue]

Le tableau affiche le préfixe de la clé, les IP autorisées, la dernière utilisation, l'expiration et la date de création.

À vérifier périodiquement : les clés dont le créateur a quitté l'espace de travail, les clés sans restriction d'IP ni expiration, et les clés jamais utilisées. La création comme la révocation sont enregistrées dans le journal d'audit.

## Les clés et la 2FA obligatoire [#les-clés-et-la-2fa-obligatoire]

Si l'espace de travail exige la double authentification, une clé créée par quelqu'un qui ne s'est pas enrôlé cesse de fonctionner. L'enrôlement règle le problème. Voir [2FA obligatoire](/fr/docs/platform/security/mfa).

## Étapes suivantes [#étapes-suivantes]

* [MCP](/fr/docs/platform/integrations/mcp)
* [Sécurité de la plateforme](/fr/docs/platform/security/platform-security)
* [Référence de l'API](/fr/docs/api-mcp)