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
- Comptes administrateur créés spécifiquement pour ce prestataire
- 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
- Rôles personnalisés créés pour ce prestataire, à supprimer si plus aucun compte ne les utilise
Accès serveur et infrastructure
- Comptes SSH nominatifs ou clés publiques ajoutées au serveur pour ce prestataire
- Accès au panneau d’hébergement et aux outils de déploiement associés
- Accès au registraire de domaine et aux réglages DNS, souvent oubliés car gérés séparément du reste
Accès liés aux agents IA et abilities
- Jetons d’application créés spécifiquement pour un agent IA configuré par ce prestataire
- Abilities accordées à cet agent, à réviser une par une plutôt que révoquées en bloc sans vérification
- 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.
