# Checklist avant de confier le support d’une extension à une agence tierce

> Déléguer l'assistance ne veut pas dire vendre son code en marque blanche. Avant la passation, une série de vérifications garantit que l'agence tierce peut vraiment répondre aux tickets.

- Auteur : Clément Hadrot
- Publié le : 2026-09-14
- Mis à jour le : 2026-09-14
- Catégorie : Extensions
- URL : https://wpmoderne.dev.wordpress-developpement.fr/extensions/checklist-support-extension-agence-tierce/

## L’essentiel

- L'agence tierce doit pouvoir reproduire un bug sans accès au code source complet
- Un accès en lecture seule suffit dans la majorité des tickets de support
- La passation doit inclure un historique des tickets déjà traités

Déléguer le support de premier niveau d'une extension à une agence tierce ne revient pas à lui céder le code en marque blanche : l'éditeur reste propriétaire, reste responsable des évolutions, et ne transmet qu'un périmètre défini d'assistance aux utilisateurs. Cette distinction, pourtant simple sur le papier, se perd souvent au moment de la passation si les accès et la documentation ne sont pas cadrés en amont.

Cette checklist s'adresse à un éditeur d'extension qui externalise l'assistance aux tickets, sans céder la propriété ni les droits de revente du code. Elle ne traite pas la vente en marque blanche, qui implique un tout autre cadre contractuel.

## 1. Distinguer précisément ce que l'agence peut voir et modifier

Un ticket de support ne nécessite dans la grande majorité des cas qu'un accès en lecture au code et à la configuration du site concerné, pas un accès en écriture au dépôt source de l'extension elle-même. Confondre les deux revient à donner, sans le vouloir, un droit de modification sur le produit vendu à des tiers alors que seule l'assistance aux utilisateurs finaux était prévue.

- Accès en lecture seule au code de l'extension, pour comprendre le comportement signalé.
- Accès en écriture limité à l'environnement de test du client qui a ouvert le ticket, jamais au dépôt source.
- Aucun accès au système de licence ou de facturation de l'extension elle-même.

## 2. Fournir un guide de diagnostic pour les tickets récurrents

> L'essentiel à retenir : L'agence tierce doit pouvoir reproduire un bug sans accès au code source complet ; Un accès en lecture seule suffit dans la majorité des tickets de support ; La passation doit inclure un historique des tickets déjà traités

Une agence qui découvre un produit sans historique passe un temps disproportionné à comprendre des symptômes déjà rencontrés des dizaines de fois par l'éditeur d'origine. Un guide de diagnostic, même sommaire, qui liste les messages d'erreur les plus fréquents avec leur cause probable et la question à poser en premier au client, réduit ce temps d'appropriation de façon spectaculaire.

```
// Extrait du guide de diagnostic transmis à l'agence
// Symptôme : "Erreur critique" à l'activation
// Cause la plus fréquente : conflit de version PHP, vérifier avec :
wp eval 'echo PHP_VERSION;'
// Si version inférieure à 8.1, orienter vers une mise à jour serveur avant tout autre diagnostic.
```

## 3. Transmettre l'historique des tickets déjà traités

Sans historique, l'agence tierce répète des questions déjà posées par les mêmes clients, ce qui dégrade immédiatement la qualité perçue du support aux yeux des utilisateurs finaux. Un export structuré des tickets précédents, même anonymisé pour les parties non pertinentes, donne à l'agence une base de connaissance immédiatement exploitable plutôt qu'un départ à vide.

## 4. Définir un canal d'escalade clair vers l'éditeur

Certains tickets dépasseront nécessairement le périmètre de l'agence — un bug réel dans le code de l'extension, une demande d'évolution, un cas limite jamais rencontré. Un canal d'escalade défini à l'avance, avec un délai de réponse convenu et un format de rapport standardisé, évite que ces cas ne s'enlisent entre deux structures qui se renvoient la responsabilité.

| Type de ticket | Traité par l'agence | Escaladé à l'éditeur |
| --- | --- | --- |
| Question de configuration | Oui | Non |
| Conflit avec une autre extension | Diagnostic initial | Si cause confirmée dans le code source |
| Bug reproductible dans le code | Reproduction et rapport | Oui, correctif réservé à l'éditeur |

## 5. Vérifier que l'agence peut reproduire un bug sans le code source complet

Un environnement de démonstration, isolé du code source réel, avec des données représentatives mais fictives, permet à l'agence de reproduire la majorité des symptômes signalés sans jamais avoir besoin d'un accès complet au dépôt. Cet environnement doit être maintenu à jour à chaque nouvelle version publiée de l'extension, sous peine de devenir rapidement obsolète et donc inutile pour le diagnostic.

```
wp plugin install mon-extension.zip --activate
wp eval-file bin/generer-donnees-demonstration.php
```

## En résumé

Cinq vérifications suffisent à cadrer une délégation de support sans dérive vers une cession de code non désirée : périmètre d'accès précisément défini, guide de diagnostic transmis, historique des tickets disponible, canal d'escalade formalisé, et environnement de démonstration permettant la reproduction sans accès complet au code source. La réussite de cette passation se mesure moins à la rapidité de la mise en place qu'à l'absence de confusion, quelques mois plus tard, sur qui est responsable de quoi.