AI app builder en marque blanche : livrer des apps clients sans dépendre de la plateforme

Vous êtes freelance ou agence et vous voulez livrer une app à un client sans qu'il sache (ou se soucie) avec quel outil vous l'avez construite. Vous voulez : zéro logo de plateforme, zéro mention "powered by", un repo GitHub propre, un Supabase qui appartient au client, un domaine custom dès le jour 1. Bref, vous cherchez un véritable AI app builder en marque blanche, pas un SaaS qui vous loue un slot d'hébergement avec son nom dessus.

Le problème, c'est que la plupart des outils du marché — Lovable, Bubble, Glide, Webflow — vous mettent en visibilité forcée. Le sous-domaine de preview est sur leur marque. L'app vit sur leur infra. Le code n'est pas vraiment exportable. Pour un client final, ça crée immédiatement une dépendance et fragilise votre positionnement de prestataire. Cadrant a été conçu autour de l'inverse : tout ce que vous livrez est neutre, transférable et possédé par le client.

Qu'est-ce qu'un véritable AI app builder en marque blanche ?

Le terme "marque blanche" est utilisé à toutes les sauces. Pour qu'un AI app builder soit réellement en marque blanche, il doit cocher cinq cases concrètes :

• Aucun branding visible dans l'app livrée — ni footer "Made with X", ni logo de l'outil dans l'admin, ni splash screen.
• Code source intégral exportable — repo Git complet, sans dépendance runtime à la plateforme.
• Backend hébergé chez le client — base de données, auth, stockage de fichiers sur le compte du client.
• Domaine custom dès le départ — pas de "client.outil.com" forcé pendant la phase de build.
• Plan de prix qui n'apparaît pas dans la facture client — vous payez l'outil de votre côté, le client paie l'app.

Cadrant est aujourd'hui l'un des rares outils du marché à cocher les cinq cases sans concession. Voyons comment.

Le code est 100% à vous (et donc à votre client)

Quand Cadrant génère votre app, le code produit est du Next.js + TypeScript + Supabase classique. Aucun runtime propriétaire, aucune SDK fermée, aucune bibliothèque maison qui empêcherait de continuer en interne. Vous avez à tout moment accès au repo GitHub complet — push, branches, merge, tout fonctionne comme un projet normal. Si demain le client veut continuer le développement avec son équipe, ou avec un autre prestataire, il suffit de transférer le repo : aucune migration, aucune réécriture.

Comparez avec Bubble : le code n'existe pas vraiment, l'app vit dans le runtime Bubble. Avec Webflow CMS : le contenu est séquestré dans Webflow. Avec Lovable : exporter casse une partie de l'écosystème. Avec Cadrant : ce que vous voyez dans le repo est ce qui tourne en prod. Il n'y a rien d'autre.

Le backend appartient au client dès le jour 1

C'est probablement le point le plus différenciant. Sur Cadrant, vous connectez le compte Supabase du client à la création du projet. Toutes les données — utilisateurs, contenus, fichiers, logs — vivent dans son organisation Supabase, sur sa facture, sous son contrôle. Cadrant ne joue jamais le rôle de proxy : nous ne stockons pas les données utilisateur du client, nous ne lisons pas son schéma, nous ne tarifons pas par utilisateur final.

L'avantage est triple : RGPD-compatible sans avoir à signer un DPA supplémentaire avec une plateforme intermédiaire, indépendance totale du client (il peut révoquer votre accès à son Supabase quand il veut), et facturation claire (vous payez Cadrant, le client paie Supabase, fin de l'histoire).

Domaine custom dès la phase de build

Pendant le développement, Cadrant vous donne un sous-domaine de preview (ex: monprojet.cadrant.ai) pour que le client valide. Une fois prêt, vous pouvez immédiatement publier sur un domaine custom (le sien : app.entreprise-cliente.com). Pas de migration, pas de "phase de production" payante, pas de plan supérieur à débloquer. Le client peut donc voir son URL définitive dès le sprint 1, ce qui change la perception "c'est vraiment notre outil" vs "c'est un truc construit avec un service".

Aucun branding Cadrant dans l'app livrée

L'app que vous livrez n'a aucune trace de Cadrant : pas de footer "Built with Cadrant", pas de logo dans l'admin, pas de splash screen au chargement. Vous pouvez customiser le favicon, les meta tags OG, les emails transactionnels — tout ce qui touche à l'identité visuelle du projet final est neutre. Pour un freelance qui vend une prestation premium à 10k+, c'est essentiel : le client ne doit jamais avoir l'impression d'utiliser un outil tiers.

La facturation reste de votre côté

Beaucoup d'outils "en marque blanche" facturent par espace client, par seat, ou par app live — ce qui veut dire que le client finit par voir votre fournisseur dans une ligne de facture. Cadrant facture forfaitairement le freelance, indépendamment du nombre d'apps clients que vous livrez. Vos clients ne voient jamais la facture Cadrant. Si votre client veut reprendre la main sur l'abonnement à la livraison, il ouvre simplement son propre compte Cadrant et vous lui transférez les projets.

Cas d'usage typiques en marque blanche

• Agence qui livre des CRMs custom à des PME : le CRM est branché à leur Supabase, hébergé sur leur domaine, sans aucune trace d'agence ni de plateforme.
• Freelance qui construit un portail client pour un cabinet d'avocats : auth + documents + chat, hébergé sur portail.cabinet-x.fr, sans branding tiers.
• Studio qui livre un MVP à une startup : repo transféré, Supabase de la startup, déploiement Vercel sur le compte de la startup.
• Consultant produit qui prototype rapidement pour un client corporate : démo sur sous-domaine custom dès le jour 2, validation avant signature de contrat.

Pourquoi le vendor lock-in est un problème commercial

Quand vous livrez une app construite sur une plateforme propriétaire, votre client devient captif — et vous aussi. Si la plateforme augmente ses prix de 40% (ce qui arrive régulièrement), votre client le subit. S'il y a un incident d'infra, vous êtes la personne que le client appelle, mais vous n'avez aucun levier. S'il décide de quitter la plateforme dans 2 ans, c'est vous qui devez gérer la migration. À l'inverse, livrer du Next.js + Supabase standard signifie que votre client est libre, et que vous restez un consultant, pas un point de défaillance unique.

FAQ — AI app builder marque blanche

Cadrant ajoute-t-il un footer "Made with" dans les apps publiées ? Non. Aucune mention de Cadrant n'apparaît dans le HTML de l'app livrée. Vous pouvez vérifier dans le code source.

Le client peut-il voir que l'app a été générée par IA ? Le code généré ressemble à du code écrit par un dev humain (composants, hooks, types TypeScript propres). Rien dans la structure ne révèle l'origine IA. La seule trace possible serait dans les commits Git si vous laissez les messages auto-générés — vous pouvez les réécrire.

Puis-je personnaliser les emails transactionnels (auth, reset password) ? Oui. Les templates d'emails Supabase sont entièrement éditables, et vous contrôlez l'expéditeur SMTP. Aucun email ne part depuis l'infrastructure Cadrant.

Comment je gère plusieurs clients en parallèle ? Cadrant a un système de workspaces — chaque projet client est isolé, avec son propre Supabase, son propre repo, ses propres variables d'environnement. Vous pouvez switch entre projets sans risque de fuite.

Le pari de Cadrant est simple : si l'outil est réellement en marque blanche, le freelance le recommande à ses pairs et le client revient pour le projet suivant. Le succès de la plateforme est aligné avec votre indépendance, pas avec votre captivité.