Un footer, un From : l’agence n’était plus seule sur le projet.

Le client de l’agence n’avait rien demandé de particulier. Il a ouvert un courriel de confirmation, descendu jusqu’au bas de page, et lu un nom qui n’était pas celui de son agence. Parfois c’est un pied de PDF. Parfois un champ From ou Reply-To. Parfois un commentaire HTML ou un Producteur dans les métadonnées du fichier. Capture d’écran, appel au commercial : le ticket arrive souvent sous l’étiquette « anomalie d’affichage ». Ce n’est pas une anomalie d’affichage. C’est une promesse de marque blanche qui a fuité au premier livrable visible.

Le problème n’est pas le sous-traitant en soi. C’est l’architecture d’identité du projet : concrètement, qui signe le From, qui possède le DNS, qui reçoit le Reply-To — autrement dit qui apparaît sur les livrables, qui possède les comptes, et qui peut être contacté hors du canal de l’agence. Tant que ces questions restent implicites, la marque blanche tient surtout dans le devis. Elle se brise dès qu’un détail technique porte encore le nom du mauvais acteur — parce que le client final photographie précisément ce détail.

Une décision raisonnable… jusqu’au premier livrable

Dans une mission type pour une agence, le scénario illustratif est fréquent. L’agence vend le projet, conserve la relation client, et sous-traite le back-end qu’elle n’a pas en interne. Pour démarrer vite, on crée un dépôt sur le compte du freelance, on envoie des mails de test depuis une boîte perso, on ouvre le cloud ou le journal d’erreurs au nom du sous-traitant, on génère les PDF depuis la machine de développement. Aucune de ces décisions n’est absurde le jour J : elles débloquent la recette. Elles deviennent coûteuses dès qu’un accès client, un envoi transactionnel ou une exportation « officielle » réutilise le même socle.

La marque blanche n’est donc pas un tarif ni une mention contractuelle isolée. C’est un dispositif technique et organisationnel : identité visible, propriété des accès, canal de contact. Ces trois couches se confondent souvent dans la conversation (« on reste discrets »), alors qu’elles fuient par des chemins différents. Distinguer les fuites évite de « corriger » un footer alors que le vrai problème est un ticket Sentry au nom du sous-traitant, ou l’inverse.

Trois fuites qui ne se corrigent pas de la même façon

La fuite d’identité est la plus visible. Footer, lien « réalisé par », auteur Git, metadata PDF (Producteur, Auteur), signature de courriel, domaine dans le From:, parfois un User-Agent ou un namespace trop parlant. Le client n’a pas besoin d’un accès admin : il lit un livrable. Donc toute sortie destinée au métier — mail, PDF, page publique, export — doit être traitée comme un document de marque, pas comme un artefact de debug.

La dépendance technique est plus sourde. DNS, cloud, CI, coffre à secrets, org Git : si le propriétaire légal est le sous-traitant et l’agence seulement invitée, la marque blanche tient tant que la relation est bonne. Le jour d’une passation, d’un conflit ou d’une absence, l’agence découvre qu’elle ne peut pas reprendre seule. Ce n’est plus une question de logo. C’est une question de qui peut révoquer, migrer, et redéployer sans demander une faveur.

Le contact client non cadré est la troisième voie. Un Slack « pour aller plus vite », un Reply-To qui tombe chez le freelance, un ticket d’assistance ouvert directement chez un tiers : l’agence n’est plus l’unique interlocuteur. Même sans footer, le client a enregistré une adresse et un visage. Revenir en arrière coûte souvent plus cher qu’un cadre écrit au lancement — canal, horaires, sujets autorisés, sujets renvoyés à l’agence.

Ces trois classes coexistent parfois dans le même projet. Les confondre produit des correctifs cosmétiques : on retire une ligne HTML et l’on laisse le cloud au mauvais nom. Ou l’on transfère le dépôt sans revoir les mails transactionnels. Le mécanisme utile consiste à nommer laquelle des trois a cassé, puis à tester.

Tests discriminants : hypothèse, geste, résultat attendu

Avant de réécrire le contrat, on vérifie ce qui fuit vraiment. Les tests suivants sont volontaires et reproductibles ; ils ne prétendent pas couvrir tous les cas, mais ils séparent identité, propriété et contact.

Hypothèse A — fuite d’identité dans un livrable. Test : ouvrir un PDF client, un mail transactionnel réel (pas le driver log), et le code source d’une page livrée ; chercher le nom du sous-traitant, un domaine perso, un Producteur machine, un auteur Git encore exposé. Résultat attendu si l’hypothèse tient : au moins une occurrence hors périmètre agence. Conclusion : corriger les sorties (templates, From, metadata, historique visible) avant de parler « process ».

Hypothèse B — dépendance de propriété. Test : lister qui possède le DNS, le compte cloud, l’org Git, la CI, le journal d’erreurs ; vérifier si l’agence peut inviter, révoquer et exporter sans le sous-traitant. Résultat attendu si l’hypothèse tient : owner = sous-traitant, agence = guest. Conclusion : la correction n’est pas un footer, c’est un transfert de propriété (ou un refus clair de démarrer tant que ce n’est pas le cas).

Hypothèse C — contact non cadré. Test : rejouer un envoi transactionnel et lire les en-têtes (From, Reply-To, domaine SPF/DKIM) ; vérifier si un client peut ouvrir un ticket chez un tiers ou joindre directement le freelance. Résultat attendu si l’hypothèse tient : réponse ou incident qui contourne l’agence. Conclusion : recadrer le canal avant d’ajouter de la charge utile.

Ces trois tests tiennent en une demi-journée de revue. Ils évitent le débat d’intention (« on avait dit marque blanche ») en collant à des artefacts. Quand le résultat est négatif partout, on peut parler d’autre chose — délai, qualité, dette. Quand il est positif, on sait quelle couche réparer.

Correction maintenant, prévention ensuite

La correction traite ce qui est déjà exposé. On retire ou on remplace les mentions nominatives dans les livrables. On aligne From / SPF / DKIM / DMARC sur le domaine convenu (agence ou client final, selon le contrat). On régénère les PDF avec des metadata neutres. On squash ou on transfère l’historique Git si le client a déjà un accès au dépôt. On ferme ou on renomme les espaces de supervision au nom du sous-traitant. On ne « demande pas au client d’ignorer » un footer : on le fait disparaître.

La prévention se pose au premier jour, pas la veille de la recette. Owner des comptes = agence (ou client final si c’est le modèle), sous-traitant en invité révocable. Remote Git, CI et secrets dans le périmètre agence. Modèles de mail et de PDF sans signature freelance. Règle écrite sur le contact client : par défaut aucun échange direct ; si l’agence en veut un, canal et propos sont listés. Offboarding le jour de la fin de mission : clés, invitations, tokens. La documentation de passation décrit comment déployer et relancer un traitement — pas qui est le sous-traitant.

Séparer les deux évite un piège classique : croire qu’un NDA suffit. Le NDA cadre la confidentialité ; il n’empêche pas un MAIL_FROM_ADDRESS personnel de partir en production. Inversement, un footer propre ne sauve pas une org cloud que l’agence ne possède pas. Les deux contrôles sont nécessaires, à des moments différents.

Limites et ce que ce texte n’est pas

Ce texte décrit une classe fréquente de dérives en sous-traitance agence, pas un incident nominatif. Aucun client, aucun ticket, aucun volume. Les vecteurs listés (footer, From, PDF, Git, tickets tiers, cloud) ne sont pas exhaustifs : un cookie de session trop parlant ou un tunnel de démo oublié peuvent jouer le même rôle. Le bon réflexe reste le même — hypothèse, test sur artefact, conclusion — plutôt qu’une checklist magique à recopier sans lire le projet.

La marque blanche a aussi une limite assumée : si le projet ne peut plus vivre sans le sous-traitant (accès, savoir implicite, supervision), ce n’est plus de la marque blanche, c’est une dépendance. Mieux vaut le dire et chiffrer la documentation de reprise que de laisser l’ambiguïté faire office de verrou. Quand l’agence veut au contraire un contact client direct tout en gardant un dépôt au nom du freelance, les deux règles s’annulent : le périmètre doit trancher avant le premier commit.

Si vous pilotez une agence et que le renfort back-end doit rester invisible côté client, le cadre opérationnel est décrit sur la page agences / marque blanche — identité, accès et canal inclus, pas seulement le devis.