La crainte est légitime. Un sous-traitant qui apparaît dans un email de notification ou une signature mal configurée, et c'est la relation client qui prend un coup : vous aviez vendu « tout en interne ». La bonne nouvelle : les fuites sont presque toujours techniques, donc presque toujours évitables. Voici la check-list que j'applique (la marque blanche fait partie de mon périmètre par défaut) et que vous pouvez exiger de n'importe quel prestataire.
1. Pourquoi les emails sortants sont-ils la fuite n° 1 ?
Parce que WordPress envoie des emails sans qu'on le lui demande. Par défaut, la fonction wp_mail() expédie depuis wordpress@votredomaine via le serveur. Mais dès qu'un plugin SMTP est configuré, c'est l'identité du compte SMTP qui part. Si votre sous-traitant a branché *son* compte d'envoi pour tester un formulaire, votre client peut recevoir un email signé d'un domaine inconnu.
Les points à verrouiller :
- Expéditeur des notifications WP (réinitialisations de mot de passe, commentaires, mises à jour) : adresse et nom d'expéditeur au domaine du client ou de votre agence, jamais celui du prestataire.
- SMTP transactionnel : le compte (Brevo, Mailjet, SMTP de l'hébergeur) appartient à votre agence ou au client. Le sous-traitant le configure, il n'en est pas titulaire.
- Adresse email d'administration WP (
Réglages > Général) : c'est elle qui reçoit les alertes. Elle doit pointer vers vous. - Tests de formulaires : exiger que les tests soient faits vers une adresse de votre agence, jamais vers une adresse personnelle du développeur (qui finirait dans les logs ou les entrées de formulaire visibles du client).
2. Quels comptes utilisateurs créer pour le sous-traitant ?
Un compte nominatif générique, à votre domaine. Le bon réglage : créez dev@votre-agence.fr (ou tech@), donnez-le au sous-traitant, et c'est ce compte qui apparaît partout (auteur des pages, historique des révisions, logs d'activité). Trois erreurs classiques à éviter :
- Laisser le sous-traitant créer son propre compte avec son email : son identité entre dans la base de données (et dans les exports, les notifications, les plugins de log).
- Le nom d'affichage : WordPress affiche le nom de l'auteur sur certains thèmes et dans les flux RSS. Mettez le nom de votre agence ou un prénom neutre.
- Les révisions et l'autorat des contenus : réattribuez les contenus au compte de l'agence avant livraison si le client a un accès admin.
3. Où le nom d'un prestataire se cache-t-il dans le code ?
Dans les endroits que personne ne relit : l'en-tête du thème enfant (Author: dans style.css), les commentaires de fichiers PHP, les composer.json/package.json (champ author), les readme, les commits Git si le dépôt est livré, et les chaînes de traduction personnalisées. La consigne à donner, et à vérifier par un grep sur le nom du prestataire avant chaque livraison, tient en une ligne : aucun nom, aucune URL, aucun email du sous-traitant dans aucun fichier livré. L'en-tête du thème porte le nom de votre agence. C'est aussi un réflexe à appliquer sur tout développement custom livré, par exemple un configurateur ou un module sur mesure, où les fichiers ajoutés sont autant de points de fuite potentiels.
4. Les URL de staging trahissent-elles le sous-traitant ?
Oui, si le staging tourne sur le domaine du prestataire (projet-client.agence-soustraitante.com). Le jour où vous partagez l'URL de recette avec votre client pour validation, tout est visible. Deux solutions propres : un staging sur un sous-domaine de votre agence (recette-client.votre-agence.fr), ou un staging chez l'hébergeur du client (la plupart des offres infogérées en proposent un en un clic). Vérifiez aussi que le staging est désindexé (Discourage search engines plus authentification HTTP). Une URL de recette indexée par Google est une fuite publique, pas seulement une fuite client.
5. Quid des outils de gestion à distance et des plugins « signés » ?
Deux vecteurs discrets :
- Outils de maintenance multi-sites (ManageWP, MainWP, WP Umbrella) : ils installent un plugin worker visible dans la liste des extensions. Si le compte maître appartient au sous-traitant, son identité peut apparaître dans les rapports de maintenance générés. Le compte maître doit être celui de votre agence. Les rapports sont à vos couleurs (la plupart de ces outils proposent le white-label nativement).
- Plugins ou thèmes premium sous licence : une licence enregistrée au nom du sous-traitant apparaît dans les écrans d'administration du plugin. Les licences appartiennent à l'agence ou au client.
6. Comment gérer tickets, fichiers et captures d'écran partagés ?
Le canal de collaboration est une fuite si le client y a un jour accès. Règles simples :
- Le client final n'est jamais dans le même espace (Slack, Trello, Notion, email) que le sous-traitant. Vous êtes le seul pont : c'est aussi ce qui protège votre valeur ajoutée.
- Les fichiers livrés (PDF de recette, exports, captures d'écran) sont vérifiés : nom d'auteur dans les métadonnées des PDF et des documents Office, barre de favoris ou onglets visibles dans les captures d'écran. Un détail, mais c'est précisément par les détails que la marque blanche casse.
- Les visioconférences avec le client final se font sans le sous-traitant. Ou alors il y apparaît comme membre de votre équipe, point à cadrer contractuellement (voir ci-dessous).
Sept réglages à vérifier avant chaque livraison, c'est exactement le genre de check-list qui saute un soir de rush. Si vous voulez déléguer une prestation WordPress en étant certain qu'aucune trace ne remonte à votre client, je travaille sous votre marque par défaut : comptes, emails, staging, code et rapports à vos couleurs, du premier brief à la livraison.
Parlez-moi de votre projet →7. Que reste-t-il dans le DNS, le whois et les en-têtes ?
Le dernier kilomètre, souvent oublié. Si le sous-traitant héberge le site, son nom peut apparaître dans le whois de l'IP, les serveurs DNS (ns1.prestataire.com), les enregistrements SPF (include: au domaine du prestataire) ou les en-têtes HTTP personnalisés. La règle : l'hébergement appartient au client ou à votre agence, le sous-traitant y reçoit un accès, jamais l'inverse. C'est aussi votre assurance le jour où la collaboration s'arrête. La même logique de propriété des accès s'applique quand vous devez reprendre un site WordPress orphelin : tout doit finir au nom du client ou de l'agence.
Et le contrat dans tout ça ?
Les sept réglages ci-dessus sont techniques. Ils se doublent d'une clause de confidentialité et de non-sollicitation dans le contrat de sous-traitance : interdiction de contacter le client final, interdiction de référencer le projet (portfolio, réseaux sociaux, études de cas), et procédure en cas de contact accidentel. Un prestataire sérieux propose cette clause de lui-même. C'est même un bon test lors du premier échange.
Check-list récapitulative avant chaque livraison
| # | Point | Vérification |
|---|---|---|
| 1 | Emails sortants | Expéditeur + SMTP au nom de l'agence/client |
| 2 | Comptes WP | Compte générique à votre domaine, autorat réattribué |
| 3 | Code | grep du nom du prestataire = zéro résultat |
| 4 | Staging | Sous-domaine agence/client, désindexé, protégé |
| 5 | Outils distants | Comptes maîtres et rapports white-label à l'agence |
| 6 | Fichiers/canaux | Métadonnées nettoyées, client jamais dans le canal sous-traitant |
| 7 | DNS/whois | Hébergement au nom du client ou de l'agence |
En bref
La marque blanche ne se décrète pas, elle se vérifie point par point avant chaque livraison. Sept réglages techniques et une clause contractuelle suffisent à la rendre étanche. Le client qui ne voit que vous est un client qui reste avec vous.
FAQ
Qu'est-ce que la sous-traitance WordPress en marque blanche ?
C'est une prestation où le sous-traitant produit le travail mais reste totalement invisible pour le client final. Tous les éléments visibles (emails, comptes, code, staging, rapports) portent le nom de l'agence donneuse d'ordre. Le client croit que tout a été réalisé en interne.
Comment être sûr que mon client ne découvrira pas mon sous-traitant ?
En verrouillant les sept points techniques de cet article avant le premier brief : emails sortants, comptes utilisateurs, métadonnées du code, URL de staging, outils de gestion à distance, fichiers partagés et traces DNS/whois. Les fuites en marque blanche sont presque toujours techniques, donc évitables si la check-list est appliquée systématiquement.
Un sous-traitant peut-il mettre mon projet dans son portfolio ?
Pas s'il existe une clause de non-référencement dans le contrat de sous-traitance. Cette clause interdit de citer le projet en portfolio, sur les réseaux sociaux ou en étude de cas. Un prestataire sérieux la propose de lui-même, ce qui est un bon signal lors du premier échange.
Faut-il un contrat écrit pour une marque blanche WordPress ?
Oui. Les réglages techniques ne suffisent pas seuls : ils se doublent d'une clause de confidentialité et de non-sollicitation interdisant tout contact direct avec le client final, plus une procédure en cas de contact accidentel. Le technique ferme les fuites, le contrat couvre l'intention.
Comment vérifier qu'aucun nom de prestataire ne traîne dans le code livré ?
Lancez un grep du nom, du domaine et de l'email du prestataire sur l'ensemble des fichiers avant livraison. Vérifiez en priorité l'en-tête du thème (style.css), les commentaires PHP, les champs author des fichiers composer.json et package.json, les readme et les commits Git si le dépôt est livré. L'objectif : zéro résultat.