Une agence qui revend de la production a un seul vrai point de rupture : le moment où son client apprend, par hasard, qu’une partie du travail a été faite ailleurs. Et ce n’est presque jamais une indiscrétion qui déclenche la découverte. C’est un readme.txt oublié dans un dossier de plugin, un sous-domaine de recette indexé par Google, une adresse d’auteur dans l’historique Git, un prénom inconnu dans un fil de commentaires.
La marque blanche n’est pas une promesse morale, c’est une discipline opérationnelle. Elle se joue sur des dizaines de détails techniques — dont beaucoup apparaissent après la livraison, quand personne ne regarde plus — et sur trois points juridiques qu’il faut au contraire assumer. Cet article liste les traces à surveiller, dans l’ordre où elles se créent, puis dit ce qui ne peut pas être caché.
Discrétion commerciale, transparence juridique : la distinction qui structure tout
Deux notions sont régulièrement confondues, et la confusion coûte cher. La discrétion commerciale consiste à ne pas faire apparaître un tiers dans la relation : votre client achète à votre agence, parle à votre agence, reçoit des livrables à votre nom. C’est légitime, et c’est le principe même de la production en marque blanche depuis Tanger. La transparence juridique, elle, porte sur la chaîne de traitement des données personnelles et sur les engagements contractuels que vous avez signés. Elle n’est pas négociable.
Autrement dit : votre client n’a pas à connaître le nom de votre prestataire pour choisir votre agence, mais son délégué à la protection des données doit pouvoir reconstituer qui touche quoi. Les deux coexistent sans difficulté dès lors qu’on sait où passe la frontière. Les problèmes commencent quand une agence cache ce qui relève du second registre, ou déballe tout parce qu’elle a peur de mal faire.
Ce que la loi n’exige pas
Les mentions légales d’un site professionnel doivent identifier l’éditeur, le directeur de la publication et l’hébergeur, avec ses coordonnées. L’agence qui a réalisé le site n’a aucune obligation d’y figurer, et son prestataire encore moins : l’éditeur est l’entité qui contrôle le contenu et sa publication, et confondre les deux rôles est une erreur de conformité fréquente — le manquement aux obligations d’identification expose à un an d’emprisonnement et 75 000 euros d’amende. Le lien de courtoisie « site réalisé par » n’a lui non plus aucun fondement légal : c’est une pratique commerciale, rien d’autre.
Les traces techniques que personne ne pense à effacer
C’est le gros du travail, et le plus mécanique. Un prestataire sérieux applique une procédure de nettoyage avant chaque livraison, pas une relecture improvisée.
Dans les fichiers du site
Les en-têtes des thèmes et des plugins sur mesure sont la première source de fuite : les champs Author et Author URI du style.css d’un thème enfant, le bloc de commentaires en tête du fichier principal d’un plugin, les clés author d’un package.json ou d’un composer.json. Viennent ensuite les noms de dossiers : un répertoire de thème ou de plugin portant le nom du prestataire se lit dans le code source de n’importe quelle page. Les fichiers résiduels comptent aussi : readme.txt, CHANGELOG.md, LICENSE, configurations locales.
Le piège le plus discret reste la source map. Un fichier .css.map ou .js.map livré en production embarque les chemins absolus de la machine de compilation : le prénom de l’utilisateur, l’arborescence des projets, parfois le nom d’un autre client. Ces fichiers n’ont rien à faire sur un serveur de production.
Dans l’infrastructure
Le sous-domaine de recette est le classique absolu. Il est indexé parce que personne n’a posé de protection par mot de passe, il ressort sur une recherche de marque, et il porte le nom du prestataire. Pire : depuis 2018, les navigateurs n’acceptent plus un certificat TLS qui n’a pas été publié dans les journaux publics de Certificate Transparency. Chaque sous-domaine pour lequel un certificat a été émis devient donc interrogeable par n’importe qui, définitivement, même après suppression du site. Un recette-clientX.nomduprestataire.com créé un mardi soir reste consultable des années plus tard.
Dans la même famille : un enregistrement MX qui révèle le relais de messagerie, un WHOIS non anonymisé sur un domaine technique, un panneau d’hébergement dont l’adresse d’accès est un sous-domaine du prestataire.
Dans le dépôt et les documents
Un transfert de code vers le client final avec l’historique complet livre la liste des contributeurs, leurs adresses, leurs horaires et leurs volumes. Deux réponses possibles : neutraliser les identités de commit en amont, ou livrer une archive sans historique. La seconde est plus simple, la première est plus propre quand vous voulez un renfort PHP ou Laravel qui travaille durablement dans votre dépôt.
Les documents suivent la même logique. Un PDF d’exploitation porte un champ « Producteur » et un champ « Auteur » ; un fichier Word ou Excel conserve le nom du dernier utilisateur ayant enregistré ; un fil de commentaires sur une maquette expose les comptes invités — à vérifier systématiquement quand vous faites intégrer une maquette Figma par un tiers. Les captures d’écran de documentation méritent un regard : barre de favoris, langue du système, notification d’un outil interne dans un coin.
Dans les e-mails et les licences
Les e-mails transactionnels d’un site — confirmation de commande, réinitialisation de mot de passe, formulaire de contact — partent souvent par le relais SMTP configuré pendant le développement. Le Return-Path et le domaine de signature DKIM restent visibles dans les en-têtes, et certaines messageries affichent un « envoyé via » explicite. Côté licences, une extension premium activée avec la clé du prestataire affiche son compte dans l’écran de licence, et les e-mails de renouvellement arrivent chez lui.
Les traces humaines, les plus difficiles à tenir
Le technique se corrige avec une checklist. L’humain demande une règle d’organisation, parce qu’une fuite se produit en une seconde dans un fil de discussion.
La règle qui fonctionne : un seul canal de production entre votre agence et votre prestataire, et aucun compte du prestataire dans les outils partagés avec le client final. Pas d’invité dans l’espace projet, pas d’accès direct à la Search Console du client, pas de visioconférence client. Tout passe par un interlocuteur de votre agence. Cela paraît lourd ; c’est moins coûteux que de recoller les morceaux après une question embarrassante en réunion.
Restent deux angles morts. D’abord les rythmes : un jour férié qui n’est pas celui de votre pays, une absence collective inexpliquée, une réponse à 7 h du matin, cela finit par soulever des questions chez un client attentif. Une équipe de production WordPress déléguée doit donc annoncer son calendrier annuel en début de collaboration, pour que votre agence l’absorbe dans ses propres plannings. Ensuite la vitrine du prestataire : un projet publié dans ses réalisations, une étude de cas, un profil nommant le client final. Le NDA doit interdire cette publication, sans limite de durée et sans exception « sous réserve d’accord », qui ne sert qu’à ouvrir la discussion plus tard.
Ce que vous ne pouvez pas cacher, et ne devez pas essayer
Voici la partie qui déplaît, et la plus importante. Trois choses ne relèvent pas de la marque blanche, et l’agence qui les traite comme telles s’expose plus qu’elle ne se protège.
La chaîne de sous-traitance des données personnelles. Si le projet implique un traitement de données personnelles — un formulaire, un compte client, une commande —, votre agence est sous-traitant au sens du RGPD et votre prestataire devient sous-traitant ultérieur. L’article 28 exige une autorisation écrite préalable, spécifique ou générale, du responsable de traitement, c’est-à-dire de votre client. En régime d’autorisation générale, vous devez l’informer de tout ajout ou remplacement de prestataire et lui laisser une possibilité effective d’objection. Votre agence impose au prestataire les mêmes obligations et reste pleinement responsable de leur exécution. Ce point n’est pas contournable par un NDA : le NDA protège une identité commerciale, pas une obligation de documentation.
La localisation du traitement. Le Maroc ne fait pas l’objet d’une décision d’adéquation de la Commission européenne. Un transfert de données personnelles depuis l’Union européenne doit donc être encadré, en pratique par les clauses contractuelles types adoptées le 4 juin 2021 — décision d’exécution (UE) 2021/914, les anciennes clauses n’étant plus utilisables depuis le 27 décembre 2022 — accompagnées d’une analyse d’impact du transfert. Quatre modules existent selon la qualité des parties ; une relation agence-prestataire relève du module 3, de sous-traitant à sous-traitant. Dans l’autre sens, une sortie de données hors du Maroc suppose une autorisation de la CNDP, instruite en deux mois. Rien de cela n’empêche la discrétion commerciale : ces documents vivent dans le dossier de conformité, pas sur la page d’accueil.
Une déclaration écrite fausse. C’est le vrai danger. Écrire « l’intégralité du développement est réalisée dans nos locaux » alors que ce n’est pas le cas transforme une discrétion légitime en affirmation mensongère dans un document contractuel ou une réponse à appel d’offres. Beaucoup de contrats cadres et la quasi-totalité des marchés publics comportent de surcroît une clause d’agrément des sous-traitants : passer outre est une faute contractuelle, indépendamment du résultat technique. La bonne formulation est simple : votre agence est responsable de la production, elle s’engage sur le résultat, elle mobilise ses équipes et des partenaires sous sa responsabilité, et elle documente la chaîne de traitement sur demande. Cette phrase est vraie, elle ne nomme personne, elle résiste à un audit.
La checklist de sortie, avant chaque mise en production
À faire passer au prestataire, et à vérifier soi-même par échantillon :
- En-têtes de thèmes, thèmes enfants et plugins sur mesure : champs auteur neutralisés.
- Noms de dossiers et de préfixes : aucun identifiant de prestataire dans une URL publique.
- Source maps, readme, changelog et configurations locales retirés de la production.
- Recherche plein texte du nom du prestataire et de son domaine dans tous les fichiers, minifiés compris.
- Comptes du back-office : aucun compte au nom ou au domaine du prestataire.
- Licences d’extensions premium transférées sur le compte de l’agence ou du client.
- Relais SMTP et adresses d’expédition basculés sur le domaine du client.
- Sous-domaines de recette protégés par mot de passe, en noindex, détruits après recette.
- MX et WHOIS vérifiés sur tous les domaines techniques du projet.
- Métadonnées des livrables documentaires, et captures d’écran relues une par une.
- Historique Git neutralisé, ou livraison sans historique.
- Accès du prestataire aux outils du client final : révoqués.
Côté contrat, quatre clauses à exiger avant le premier échange technique : NDA signé avant toute transmission de brief, interdiction permanente de publication en portfolio, cession de la propriété du code dès la livraison sans clause de réserve, et nettoyage des signatures inscrit dans la définition du livrable — pas dans un e-mail de courtoisie.
Questions fréquentes
Un NDA suffit-il à garantir qu’aucune trace ne subsiste dans le code livré ?
Non. Un NDA est un engagement de confidentialité : il crée une responsabilité en cas de divulgation, il ne nettoie aucun fichier. Les traces décrites plus haut sont des sous-produits du travail, pas des indiscrétions. Ce qui les élimine, c’est une étape de nettoyage inscrite dans la définition du livrable et une vérification par échantillon de votre côté. Le NDA couvre ce qui se dit ; la checklist couvre ce qui se code.
Que répondre à un client qui demande où se trouvent les développeurs ?
La vérité, sans nommer de tiers : votre agence pilote la production, s’engage sur le résultat, et travaille avec des équipes internes et des partenaires sous sa responsabilité, y compris hors de France. Cette réponse est exacte, elle ne divulgue rien, et elle vous évite d’avoir affirmé par écrit quelque chose de faux. Si le client insiste parce que ses propres obligations l’imposent — marché public, politique de groupe —, vous n’êtes plus dans la discrétion commerciale mais dans la conformité : il faut documenter la chaîne.
Faut-il un avenant RGPD par projet ou une fois pour toutes ?
Les deux mécanismes sont prévus. L’autorisation générale, signée une fois, évite de recommencer à chaque projet mais vous oblige à informer le client de tout changement de prestataire et à lui laisser un droit d’objection. L’autorisation spécifique, projet par projet, est plus lourde mais plus lisible. En pratique, une agence qui délègue régulièrement gagne à traiter le sujet une fois dans ses conditions générales, puis à tenir à jour une liste de ses prestataires communicable sur demande.
Comment vérifier soi-même qu’un site livré ne porte aucune signature ?
Quatre contrôles en dix minutes : rechercher le nom et le domaine du prestataire dans le code source des principales pages et dans les fichiers CSS et JavaScript ; interroger un moteur sur le domaine du client pour repérer un sous-domaine de recette indexé ; lire les en-têtes d’un e-mail transactionnel envoyé par le site ; ouvrir la liste des utilisateurs du back-office. Ces quatre vérifications attrapent la grande majorité des oublis.
La marque blanche tient moins à la confiance qu’à la méthode : une procédure de nettoyage appliquée à chaque livraison, une règle de canal unique, un NDA qui couvre la publication en portfolio, et un dossier de conformité à jour pour la partie qui, elle, doit rester visible. Une agence qui tient ces quatre points peut déléguer n’importe quel poste de production sans exposer son prestataire. C’est le cadre dans lequel Euroweb Digital travaille avec les agences de France, de Belgique et de Suisse depuis plus de dix ans, que le besoin porte sur une boutique WooCommerce livrée sans signature ou sur un renfort durable. Pour cadrer un premier chantier, parlons de votre prochain projet.
