# Départ d’un prestataire : jetons, accès et abilities à révoquer systématiquement

> Quels accès survivent réellement au départ d'un prestataire technique ? Une liste exhaustive, incluant les abilities accordées à des agents IA, souvent oubliées dans ce type de transition.

- Auteur : Clément Hadrot
- Publié le : 2026-08-04
- Mis à jour le : 2026-08-04
- Catégorie : Sécurité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/depart-prestataire-jetons-acces-abilities-a-revoquer/

## L’essentiel

- Un changement de prestataire laisse presque toujours des accès actifs plus longtemps que prévu
- Les abilities accordées à un agent IA du prestataire précédent sont rarement incluses dans la checklist classique
- La révocation doit être vérifiée activement, pas seulement demandée par courriel

Quels accès un prestataire technique conserve-t-il réellement après la fin officielle de sa mission ? La réponse, dans la majorité des transitions observées, est : plus que ce que tout le monde imagine. Une checklist de fin de mission qui se limite aux accès WordPress classiques (comptes utilisateur, FTP) laisse presque toujours de côté des catégories entières d'accès plus discrètes mais tout aussi sensibles, notamment celles liées aux agents IA connectés par ce même prestataire.

Voici une liste organisée par catégorie, pensée pour être suivie point par point lors de chaque changement de prestataire, plutôt que reconstituée de mémoire au moment de la transition.

## Accès WordPress classiques

1. Comptes administrateur créés spécifiquement pour ce prestataire
2. Mots de passe d'application générés sur des comptes existants, y compris ceux dont personne ne se souvient précisément de l'usage
3. Rôles personnalisés créés pour ce prestataire, à supprimer si plus aucun compte ne les utilise

## Accès serveur et infrastructure

1. Comptes SSH nominatifs ou clés publiques ajoutées au serveur pour ce prestataire
2. Accès au panneau d'hébergement et aux outils de déploiement associés
3. Accès au registraire de domaine et aux réglages DNS, souvent oubliés car gérés séparément du reste

> L'essentiel à retenir : Un changement de prestataire laisse presque toujours des accès actifs plus longtemps que prévu ; Les abilities accordées à un agent IA du prestataire précédent sont rarement incluses dans la checklist classique ; La révocation doit être vérifiée activement, pas seulement demandée par courriel

## Accès liés aux agents IA et abilities

1. Jetons d'application créés spécifiquement pour un agent IA configuré par ce prestataire
2. Abilities accordées à cet agent, à réviser une par une plutôt que révoquées en bloc sans vérification
3. Accès aux serveurs MCP configurés par ce prestataire, y compris ceux hébergés en dehors de l'infrastructure principale du site

### Pourquoi cette dernière catégorie est souvent oubliée

Un agent IA configuré par un prestataire externe fonctionne fréquemment sur une infrastructure distincte de celle du site lui-même, ce qui le rend invisible lors d'une revue classique limitée à WordPress et à l'hébergement. Le jeton utilisé par cet agent continue pourtant de fonctionner tant qu'il n'est pas explicitement révoqué, indépendamment de la fin du contrat de prestation.

```
wp user application-password list --user=agent-ia-prestataire --format=table
wp user application-password delete --user=agent-ia-prestataire --uuid=UUID_DU_JETON
```

## Vérifier, pas seulement demander

Une demande de désactivation envoyée par courriel au prestataire sortant ne constitue jamais une preuve de révocation effective. Chaque élément de cette liste doit être vérifié activement, après la date annoncée de fin de mission, par une personne de l'équipe qui reprend le projet : connexion tentée avec les identifiants supposés révoqués, appel test sur une ability supposée retirée, requête sur le jeton d'application supposé supprimé.

- Tester une tentative de connexion avec un compte supposé désactivé
- Vérifier la liste effective des mots de passe d'application actifs, pas seulement ceux mentionnés par le prestataire
- Confirmer auprès de chaque service tiers (hébergeur, registraire, outils de CI) que les accès associés au prestataire sont bien retirés de leur côté également

> Un accès qu'on suppose révoqué et un accès réellement révoqué produisent exactement le même silence tant que personne ne teste concrètement la différence.

## Ce que cette checklist ne couvre pas

Les aspects contractuels d'une fin de mission — clauses de propriété du code, transfert de licence des extensions premium, obligations de restitution documentaire — relèvent d'un cadre distinct, généralement traité par la personne en charge des aspects juridiques du contrat plutôt que par l'équipe technique qui applique cette checklist.

## En résumé

Un changement de prestataire technique laisse, dans l'immense majorité des cas observés, des accès actifs plus longtemps que ce que tout le monde suppose, en particulier lorsque ce prestataire avait configuré un agent IA avec ses propres jetons et abilities. Neuf catégories d'accès, vérifiées activement plutôt que simplement présumées révoquées, réduisent considérablement le risque qu'un accès oublié survive silencieusement à la fin officielle de la mission.