Intégrer un créateur de sites dans votre produit : comment les pièces s'assemblent

Marque blanche / Builder intégré

Si vous éditez un produit SaaS pour des salons, des salles de sport, des artisans ou des restaurants, vos clients demandent un site web et vous préféreriez qu'ils ne partent pas en chercher un ailleurs. Le choix entre intégrer et rediriger est traité sur notre page plateformes SaaS et dans la comparaison marque blanche vs API. Cette page s'adresse à l'équipe qui a déjà décidé d'intégrer : comment fonctionne la poignée de main de session, ce qu'il faut verrouiller, quelles fonctions exposer, ce qui casse dans une iframe et comment écouter les événements.

Réserver une démo · Les tarifs sont adaptés à votre volume et à votre configuration, et vous obtenez votre prix exact pendant l'appel. 0% de frais de transaction.

Mis à jour : 25 octobre 2026

En bref

Votre serveur demande un jeton de session de courte durée avec un client ID et un secret ; votre front-end ne transmet que ce jeton au script d'intégration. Le secret n'atteint jamais le navigateur.
Chaque configuration d'intégration liste les origines HTTPS autorisées à l'utiliser, les panneaux du builder visibles, le thème, le logo et les limites par utilisateur.
Attendez-vous à des problèmes propres aux iframes : blocage des cookies tiers dans Safari et Firefox, votre propre politique frame-ancestors et les vérifications d'origine de postMessage.
Les webhooks au niveau de la marque sont signés en HMAC-SHA256 avec un horodatage, retentés en cas d'échec, puis désactivés après des échecs répétés. Réservez une démo pour voir la console d'intégration.

Partez de la décision que vous avez déjà prise

Il existe trois façons de donner un site web à vos utilisateurs : les envoyer vers un builder à votre marque sur sa propre adresse, appeler une API et construire votre propre interface, ou intégrer un builder prêt à l'emploi dans votre produit. Les compromis sont traités sur notre page plateformes SaaS et dans marque blanche vs API, et la référence des endpoints se trouve sur la page API. Ici, nous supposons que vous voulez que le builder apparaisse dans votre propre application, sous votre propre navigation, connecté en tant que votre utilisateur.

Écran Embedded SDK dans la console de la marque, avec un bouton Nouvelle configuration d'intégration et un état vide expliquant que chaque configuration a ses propres identifiants client et options de personnalisation

*La section Embedded SDK de la console de la marque. Chaque configuration d'intégration reçoit ses propres identifiants client.*

La poignée de main de session

C'est à la connexion qu'une intégration échoue le plus souvent. Le schéma utilisé par We.Inc garde vos utilisateurs connectés uniquement à votre produit, sans second compte à gérer :

Votre back-end appelle l'endpoint de session d'intégration avec le client ID de la configuration, son secret client et l'ID de votre propre utilisateur (e-mail et nom facultatifs).
La réponse contient un jeton de session, l'adresse du builder, l'ID de projet de cet utilisateur et une heure d'expiration.
Votre back-end ne renvoie que le jeton de session à votre front-end.
Votre front-end charge le script d'intégration, le fait pointer vers un élément conteneur et l'initialise avec le jeton. Des callbacks optionnels se déclenchent quand le builder est prêt, quand un projet est enregistré, en cas d'erreur et à l'expiration de la session.
À l'expiration, votre front-end demande un nouveau jeton à votre back-end, exactement comme à l'étape 1.

Les règles qui en découlent :

Le secret client est un secret serveur. Gardez-le dans votre coffre de secrets, jamais dans du code front-end, des applications mobiles ou un dépôt public. Il n'est affiché qu'une fois, à la création de la configuration.
L'ID de votre utilisateur est la clé. Le même ID renvoie le projet du même utilisateur : utilisez un ID interne stable, pas une adresse e-mail susceptible de changer.
Ne mettez pas de jetons en cache d'un utilisateur à l'autre. Demandez-en un par session utilisateur.

Origines autorisées

Chaque configuration d'intégration a une liste d'origines autorisées : les adresses HTTPS exactes (ou des modèles de sous-domaines avec joker) des pages de votre produit qui hébergeront le builder. Si une demande de session arrive avec un en-tête d'origine absent de la liste, elle est refusée.

Prévoyez la liste par environnement. Une erreur fréquente est une configuration unique utilisée par la production, la préproduction et le développement local, ce qui oblige la configuration de production à autoriser des adresses de test. Créez plutôt une configuration par environnement, chacune avec ses propres identifiants, pour que révoquer la préproduction ne touche jamais la production.

Ce qu'il faut exposer

Chaque configuration choisit les panneaux du builder dont disposent vos utilisateurs. Les choix dans la console :

Panneau	Ce qu'il fait	Choix typique pour un SaaS vertical
Chat IA	Les utilisateurs décrivent des modifications en langage courant et l'IA les applique	Activé : c'est le principal mode d'édition pour les utilisateurs non techniques
Aperçu	Aperçu en direct du site	Activé
Arborescence	Parcourir les fichiers du projet	Désactivé pour la plupart des publics
Terminal	Accès terminal dans le builder	Désactivé sauf si vos utilisateurs sont développeurs
Déploiement	Publier le site	Activé, ou désactivé si vous publiez depuis votre propre interface
Export	Télécharger le code source	À vous de voir : activé, il offre une porte de sortie ; désactivé, il garde les utilisateurs dans votre produit

Les configurations portent aussi un thème (couleur principale, police, arrondi des coins, mode sombre), un logo personnalisé facultatif, un interrupteur pour la mention « powered by », un nombre maximal de projets par utilisateur et un nombre maximal de messages IA par session. Réglez délibérément le plafond de messages IA ; c'est le principal levier sur le coût d'usage d'une offre qui inclut des sites web.

Écran API et Webhooks avec des sections pour les clés API et les endpoints de webhooks, toutes deux vides

*Les clés API et les endpoints de webhooks se trouvent à côté des réglages d'intégration dans la console de la marque.*

Ce qui casse dans une iframe

Les builders intégrés s'exécutent dans un cadre sur votre page. Anticipez ces points avant le lancement, pas après le premier ticket de support.

Cookies tiers. Total Cookie Protection de Firefox et la protection contre le pistage de Safari isolent ou bloquent les cookies définis par un site encadré d'un autre domaine. Une poignée de main par jeton de session évite de dépendre des cookies de l'utilisateur sur le domaine du builder, mais testez le parcours complet dans les versions actuelles de Safari et Firefox, fenêtres privées comprises, pendant votre pilote.
Votre propre politique de cadres. Si votre application définit une Content Security Policy, son frame-src (ou child-src) doit autoriser l'adresse du builder. Si le builder est un jour servi sous votre domaine, vérifiez frame-ancestors et X-Frame-Options pour ne pas vous bloquer vous-même.
Messages entre cadres. Le script d'intégration et le builder communiquent via postMessage. Si vous ajoutez vos propres écouteurs, suivez les règles habituelles : vérifiez l'origine de l'événement par rapport à l'adresse du builder, validez la forme du message et n'envoyez jamais de données sensibles avec une cible joker.
Hauteur et défilement. Donnez au conteneur une hauteur explicite. Un builder dans une boîte de 400 pixels au sein d'une page qui défile est pénible sur un ordinateur portable ; la plupart des produits lui donnent toute la zone de contenu.
Mobile. Modifier un site web sur un téléphone à l'intérieur d'une autre application est difficile pour tout le monde. Beaucoup de produits affichent l'aperçu et le chat IA sur mobile et réservent l'édition détaillée à l'ordinateur.

Écouter les événements

Deux types d'événements comptent pour un produit qui intègre le builder.

Dans la page : les callbacks du script d'intégration (prêt, enregistré, erreur, session expirée) permettent à votre interface de réagir immédiatement, par exemple en affichant « Enregistré » dans votre propre en-tête.

Sur votre serveur : les webhooks au niveau de la marque signalent les événements clients : client inscrit, premier site créé, site publié, rien publié sept jours après l'arrivée, client a recommandé quelqu'un, paiement reçu et client mis en pause. Chaque envoi est un corps JSON avec un ID de livraison (stable d'une tentative à l'autre), le nom de l'événement, un horodatage et les données.

Réglages des webhooks avec un champ d'URL, des cases d'événements et une note indiquant que les envois échoués sont retentés

*Choix des événements webhook. La note à droite indique la règle de nouvelle tentative et de désactivation automatique.*

Comment les recevoir en toute sécurité :

Vérifiez la signature. Chaque requête porte une signature HMAC-SHA256 du corps (l'en-tête d'origine) et une seconde signature portant sur l'horodatage et le corps, plus l'horodatage lui-même. Vérifiez celle qui inclut l'horodatage et rejetez les requêtes de plus de quelques minutes, ce qui bloque les rejeux.
Soyez idempotent. Les nouvelles tentatives réutilisent l'ID de livraison ; stockez les ID traités et ignorez les doublons.
Répondez vite. Accusez réception rapidement et faites le travail lent dans une tâche d'arrière-plan. Les envois échoués sont retentés jusqu'à six fois sur environ quinze heures, et un endpoint qui échoue quinze fois de suite est désactivé, avec un e-mail au propriétaire de la marque.

Usages typiques : marquer le compte comme « site en ligne » dans votre produit à l'arrivée de site publié ; lancer une relance d'onboarding sur rien publié après sept jours ; synchroniser les clients en pause avec votre propre état d'abonnement.

Permissions et reste de la plateforme

L'intégration est une porte d'entrée parmi d'autres. Le même compte de marque comporte aussi des comptes clients avec des interrupteurs par client (publication, domaine propre, affichage du code, blog, boutique, formulaires, SEO et approbation avant publication), un journal d'audit des actions de l'organisation, et un portail à votre marque utilisable en parallèle de l'intégration pour les utilisateurs qui préfèrent un onglet séparé.

Réglages d'un client avec des interrupteurs pour la publication, le domaine personnalisé, l'accès au code, le blog, la boutique, les formulaires, le SEO et l'approbation avant publication

*Interrupteurs par client dans la console de la marque, indépendants de la configuration d'intégration.*

Le builder sous la marque, avec un site modèle chargé dans l'aperçu

*Le builder lui-même, ici sur l'adresse propre de la marque. Intégré, le même builder se trouve dans votre produit.*

Les sites sont du vrai code (React, Vite, TypeScript, Tailwind), et le code de chaque site peut être téléchargé ou synchronisé avec GitHub, ce qui compte si vous changez un jour de plateforme ou si un client demande ses fichiers.

Panneau de code avec une arborescence de fichiers et le source d'un composant ouvert

*Le panneau de code : le site est du code source, pas un format verrouillé.*

Checklist avant lancement

Copiez-la dans votre ticket de lancement.

[ ] Une configuration d'intégration par environnement, chacune avec ses propres identifiants et origines.
[ ] Secret client stocké uniquement côté serveur ; procédure de rotation écrite.
[ ] ID utilisateurs internes stables transmis à l'appel de session.
[ ] Le callback de session expirée récupère un nouveau jeton sans recharger la page.
[ ] Panneaux choisis par niveau d'offre ; terminal et arborescence désactivés sauf besoin.
[ ] Plafond de messages IA et projets par utilisateur définis pour chaque offre.
[ ] Votre CSP autorise le builder dans frame-src ; testé dans Chrome, Safari et Firefox, fenêtre privée comprise.
[ ] L'endpoint webhook vérifie la signature horodatée et stocke les ID de livraison.
[ ] « Site publié » et « rien publié après 7 jours » reliés à votre produit ou à votre CRM.
[ ] Script de support pour « mon site ne se charge pas » qui vérifie d'abord l'origine, l'expiration du jeton et les réglages de confidentialité du navigateur.
[ ] Décision consignée sur la possibilité pour les utilisateurs d'exporter leur code, et sur le sort des sites quand un client résilie.

Pour aller plus loin

Si vous hésitez encore entre l'intégration et un portail à votre marque, commencez par la page plateformes SaaS. Si vous avez besoin du détail des endpoints pour le provisionnement des clients, consultez la page API. Si vous êtes prêt à essayer l'intégration avec votre propre produit dans un environnement de test, réservez une démo et nous créerons une configuration avec vous.

Sources

Dernière vérification le 2026-10-25.

MDN Web Docs, Content-Security-Policy: frame-ancestors directive.
MDN Web Docs, Window: postMessage() method, considérations de sécurité.
MDN Web Docs, Third-party cookies.

Configurez une intégration pour votre produit

Réservez une démo de 30 minutes. Nous vous montrons le créateur à votre marque, examinons combien de sites clients vous prévoyez de gérer et vous donnons votre prix exact.

Réserver une démo

Envie de voir la visite complète d'abord ? Découvrir le créateur de sites web en marque blanche

Les questions que posent les acheteurs

Mes utilisateurs ont-ils besoin d'un identifiant séparé pour le builder intégré ?

Non. Votre serveur demande un jeton de session de courte durée pour l'ID de votre propre utilisateur avec le client ID et le secret de la configuration, et votre front-end initialise l'intégration avec ce jeton.

Puis-je masquer certaines parties du builder à mes utilisateurs ?

Oui. Chaque configuration d'intégration choisit les panneaux visibles : chat IA, aperçu, arborescence, terminal, déploiement et export. Elle définit aussi le thème, le logo, la mention powered by, les projets par utilisateur et les messages IA par session.

Comment les webhooks sont-ils sécurisés ?

Chaque envoi est signé en HMAC-SHA256, dont une version qui signe un horodatage avec le corps pour que vous puissiez rejeter les rejeux. Les envois portent un ID stable pour la déduplication et sont retentés jusqu'à six fois sur environ quinze heures.

L'intégration fonctionnera-t-elle dans Safari ?

La poignée de main par jeton de session évite de dépendre des cookies propres au builder, mais les navigateurs durcissent sans cesse le stockage tiers : testez le parcours complet dans les versions actuelles de Safari et Firefox, fenêtres privées comprises, avant le lancement.

Est-ce différent de l'API We.Inc ?

L'API vous permet de construire votre propre interface et de provisionner des clients depuis vos systèmes. L'intégration place le builder prêt à l'emploi dans votre produit. Beaucoup d'équipes utilisent l'API pour le provisionnement et l'intégration pour l'édition.