Pour les agencesMis à jour le 5 min de lecture
Comment fonctionne le développement en marque blanche pour une agence
Un développeur en marque blanche construit ce que votre agence vend, et le travail sort sous votre nom. Votre client voit votre équipe, votre processus et votre facture, et ne me voit jamais.
Je travaille en white label pour des agences qui ont besoin de capacité dev senior sans embaucher. Voici comment je m'y prends, dans l'ordre où les dirigeants d'agence posent leurs questions.
Qui reste invisible, et comment ?
Sous NDA. Votre nom sur le livrable, toujours.
Deux règles rendent l'invisibilité réelle. Un NDA est signé avant le premier geste, et votre nom figure sur tout ce qui sort de mes mains : le dépôt de code, les liens de préproduction, la documentation, le build lui-même. Pas de mention, pas de filigrane, pas de « réalisé par » dans un pied de page ou un commit.
C'est toute la raison d'acheter en marque blanche plutôt que de référer le mandat. Une référence envoie votre client chez quelqu'un d'autre. La marque blanche garde le client, la marque et la marge chez vous, et ajoute la capacité qui vous manquait.
Qui parle au client ?
Je ne parle jamais à vos clients. La relation vous appartient.
Vous. Pas pendant le mandat, pas après, pas s'ils le demandent. Si une question exige le client, elle passe par vous, dans vos mots. Si vous voulez que je participe à un appel comme membre de votre équipe, c'est votre décision et votre présentation.
En pratique, la plupart des agences me gardent complètement hors de la pièce et relaient. Ça fonctionne parce que les builds parlent d'eux-mêmes : vous n'êtes jamais en train de décrire un avancement que vous n'avez pas vu.
Comment est-ce facturé ?
Jalons fixes, pas de surprises horaires.
Le projet est découpé en jalons à prix fixe, convenus avant que le premier ne commence. La facturation à l'heure transfère sur vous le risque de mes estimations ; les jalons fixes gardent ce risque chez moi, là où il doit être.
Un changement de périmètre devient un nouveau jalon, par écrit, avant que le travail soit fait. Jamais une découverte sur une facture.
Comment est-ce que je suis l'avancement ?
Vous voyez des builds fonctionnels tôt et souvent, pas une révélation à la fin.
Chaque jalon se termine par un build déployé que vous pouvez parcourir, et il y en a généralement plusieurs en cours de route. Le lien de préproduction porte votre nom : vous pouvez le présenter vous-même à votre client, à votre rythme.
Les builds précoces font remonter les problèmes pendant qu'ils sont encore peu coûteux. Une révélation à la fin les fait remonter quand ils ne le sont plus.
Qu'est-ce que j'obtiens à la fin ?
La maquette est livrée au pixel près.
La fidélité à la maquette approuvée est le livrable, pas une approximation. Le code est documenté et structuré pour que votre prochain développeur, à l'interne ou non, puisse le reprendre sans moi. La passation fait partie du dernier jalon, ce n'est pas une faveur demandée après coup.
Je travaille en français comme en anglais, et la documentation aussi.
Avec qui est-ce que je contracte ?
Contrat et facturation via 36N Group LLC (Wyoming). Vous payez une société américaine.
Le contrat, le NDA et les factures sont tous au nom d'une société américaine. Votre comptabilité voit un fournisseur nord-américain, et votre client, s'il regarde un jour, ne voit rien du tout.
Quel genre de mandat convient ?
Du SaaS en production, et le travail navigateur que la plupart des développeurs refusent : vidéo en temps réel, WebGL, moteurs Canvas, et le sauvetage de plateformes livrées à moitié. Un build complet, une fonctionnalité difficile à l'intérieur de votre build, ou le projet qu'un autre développeur a laissé à quatre-vingts pour cent.
Y a-t-il un moyen d'essayer sans s'engager ?
Si un client vous demande en plein pitch si quelque chose est faisable, transférez-moi la question : réponse la même journée, vous la signez. C'est gratuit, et ça me donne l'occasion de vous montrer comment je travaille.
Un mandat qui déborde ? Écrivez-moi, ou réservez 25 minutes.