Donnez à votre agent IA un accès deploy — pas le mot de passe de votre panel

La mauvaise méthode : coller le mot de passe de votre panel dans un agent

Les agents IA locaux excellent exactement dans la partie répétitive de la publication de logiciels : lancer les contrôles, corriger ce qu'ils signalent, déployer, lire les logs, recommencer. Le raccourci tentant est de confier à l'agent votre identifiant du panel pour qu'il puisse « tout faire ». Votre compte du panel peut changer les moyens de paiement, supprimer des applications et toucher chaque compte CDN que vous possédez — rien de tout cela n'est nécessaire à l'agent pour publier du code. Le bon outil est un identifiant qui peut déployer et rien d'autre.

Le token deploy : affiché une fois, strictement limité

Une commande le crée. Le token en clair apparaît exactement une fois — cdn.com.tr ne stocke qu'un hash, donc personne (support inclus) ne peut le relire plus tard. Il est lié à un seul compte CDN et à la seule surface deploy : envoi de source, build, création et mise à jour d'apps, deploy, lecture d'état et de logs.

$ cdnctl deploy-token create --name "claude-code"
Deploy token (shown ONCE — save it now):
  cdnctl_T1bz••••••••••••••••••••••••

To hand it to an agent: cdnctl configure --token cdnctl_T1bz••••…
Scope: deploy only (source upload/build + app lifecycle).

Ce que le token peut et ne peut pas faire — nous avons testé chaque limite

Ce ne sont pas des intentions de conception ; chaque ligne est une vraie requête que nous avons lancée contre l'API en production avec un token fraîchement créé :

- Surface deploy sur son propre compte — fonctionne (200). - Les mêmes endpoints pour l'UUID d'un autre compte — 404. L'API ne confirme même pas que l'autre compte existe. - Endpoints hors de la surface deploy (facturation, DNS, profil utilisateur) — 401. - DELETE sur une application — 405. La route n'est tout simplement pas enregistrée sur la surface du token, donc l'agent ne peut pas détruire ce qu'il a déployé. - Toute requête après révocation — 401, immédiatement.

Le brancher dans Claude Code ou Cursor via MCP

cdnctl embarque un serveur MCP : `cdnctl mcp` parle JSON-RPC sur stdio et expose six outils — project_info, check, entitlement, deploy, apps_list et app_show. L'enregistrer signifie que votre agent appelle deploy comme il appelle n'importe quel autre outil, avec des résultats structurés plutôt que du texte de terminal gratté.

$ claude mcp add cdntr -- cdnctl mcp

# .cursor/mcp.json
{
  "mcpServers": {
    "cdntr": {
      "command": "cdnctl",
      "args": ["mcp"],
      "env": { "CDN_ACCESS_TOKEN": "cdnctl_T1bz••••…" }
    }
  }
}

La boucle d'auto-réparation en pratique

Le token en place, l'agent déroule la même boucle qu'un humain soigneux : `check` du projet, correction de ce qui est signalé, `deploy`, lecture du résultat. Dans notre test en conditions réelles, l'agent a rencontré un vrai échec — un Dockerfile qui copiait le node_modules de l'hôte dans l'image et faisait planter le conteneur — a corrigé le .dockerignore lui-même, a redéployé, et a vérifié que l'app était saine. Pas de panel, pas d'humain dans la boucle, et rien touché hors de la surface deploy.

Rotation et révocation

Les tokens sont listés avec leur préfixe, leur dernière utilisation et l'IP — de quoi auditer sans exposer le secret. La révocation tient en une commande et prend effet dès la requête suivante. Si un token atterrit un jour dans un log ou une transcription, révoquez d'abord et enquêtez ensuite ; en créer un de remplacement prend quelques secondes.

$ cdnctl deploy-token list
  name: claude-code   prefix: cdnctl_T1bz   last_used: 2026-08-25 15:46 (185.70.97.9)

$ cdnctl deploy-token revoke --id 11
  status: success