Passer au contenu principal
Les jetons d’accès personnels sont actuellement en bêta fermée et activés par feature flag. Contactez l’assistance pour demander l’accès. Les PAT ne sont pas disponibles pour les comptes SSO/enterprise.

​
Vue d’ensemble

Les jetons d’accès personnels (PAT) permettent aux utilisateurs humains de s’authentifier de manière programmatique sous leur propre identité. Contrairement aux API key d’utilisateur de service (qui s’authentifient comme un utilisateur de service non humain), un PAT s’authentifie comme vous — l’utilisateur humain qui a créé le jeton.
Type de jetonS’authentifie en tant queIdentitéAutorisations
API key d’utilisateur de serviceUtilisateur de service (non humain)L’identité de l’utilisateur de serviceLe rôle attribué à l’utilisateur de service
Jeton d’accès personnelUtilisateur (humain)Votre identité d’utilisateurVos autorisations et vos appartenances aux orgs
Tous les identifiants API utilisent le format de préfixe cog_. Les deux types de jeton s’utilisent de manière identique dans l’en-tête Authorization : 
curl "https://api.devin.ai/v3/organizations/$DEVIN_ORG_ID/sessions" \
  -H "Authorization: Bearer $YOUR_PAT"

​
Quand utiliser les PAT

Les PAT sont conçus pour les cas où vous avez besoin d’un accès programmatique à l’API en votre nom propre :
  • Scripts et outils personnels — automatisez vos propres workflows sans utilisateur de service partagé
  • Développement local — testez des intégrations d’API avec votre propre compte
  • Automatisation de courte durée — scripts ponctuels qui doivent vous être attribués
Pour les intégrations en production, les pipelines CI/CD et l’automatisation partagée, utilisez plutôt les API keys d’utilisateur de service. Les utilisateurs de service offrent une meilleure traçabilité d’audit, une gestion centralisée des clés et des contrôles RBAC.

​
Fonctionnement

  1. Générez un PAT dans les paramètres de votre compte
  2. Le jeton commence par cog_ et n’est affiché qu’une seule fois, au moment de sa création
  3. Utilisez le jeton dans l’en-tête Authorization — exactement comme une API key d’utilisateur de service
  4. Chaque appel d’API est authentifié avec votre compte utilisateur — vos autorisations, vos appartenances aux org et votre journal d’audit s’appliquent

​
Différences clés par rapport aux API key d’utilisateur de service

AspectAPI key d’utilisateur de serviceJeton d’accès personnel
IdentitéUtilisateur de service non humainVotre compte utilisateur humain
AutorisationsContrôlées par le rôle RBAC attribuéHérite de vos autorisations existantes
Piste d’auditActions attribuées à l’utilisateur de serviceActions qui vous sont attribuées
Gestion des clésGérée par les administrateurs de l’org/de l’enterpriseGérée par vous personnellement
Cas d’usageAutomatisation de production, CI/CDScripts personnels, outils locaux
DisponibilitéDisponible de manière généraleBêta fermée

​
Limitations

  • Bêta fermée : les PAT nécessitent l’activation d’un feature flag pour votre compte
  • Non disponible pour les comptes SSO/Enterprise : actuellement réservé aux comptes sans SSO
  • Périmètre personnel : les PAT sont liés à votre compte personnel et ne peuvent pas être partagés

​
Considérations de sécurité

  • Traitez les PAT avec le même soin que des mots de passe — ils donnent un accès complet à votre compte
  • Stockez les PAT dans des variables d’environnement ou des gestionnaires de secrets, jamais dans le code source
  • Révoquez immédiatement les PAT s’ils sont compromis
  • Utilisez uniquement le périmètre minimal nécessaire à votre cas d’usage
  • Privilégiez les API key d’utilisateur de service pour toute automatisation partagée ou en production

​
Prochaines étapes