Vous devez pouvoir partir. Voici exactement ce qui part avec vous

Marque blanche / Export du code

La plupart des créateurs de sites permettent d'exporter quelque chose : un fichier XML d'articles, un dossier HTML, un CSV de pages. Rares sont ceux qui vous laissent partir avec un site qui fonctionne encore. Sur We.Inc, chaque site est un vrai projet React, et le code vous appartient : vous pouvez le télécharger ou l'envoyer sur GitHub. Cette page est la réponse pour vos achats : ce que vous obtenez, comment le tester avant de signer, et ce qui n'est pas inclus.

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

Chaque site est un projet React + Vite + TypeScript + Tailwind, pas un format de page propriétaire.
Le panneau Code télécharge un ZIP. Les fichiers propres à l'éditeur sont retirés et le projet se compile avec un simple npm install et npm run build.
L'export GitHub crée un dépôt (privé par défaut) ; la synchronisation bidirectionnelle peut rapatrier les modifications. La synchronisation est disponible sur les forfaits supérieurs et réservée au propriétaire du projet.
Les services back-end que vous avez activés (formulaires, boutique, connexions, hébergement) ne voyagent pas dans le ZIP. Prévoyez-les.

Pourquoi la dépendance est la première question des achats

Quiconque a quitté un créateur de sites hébergé connaît le scénario. Le fournisseur augmente ses prix ou arrête une gamme ; l'export se révèle être du texte sans mise en page ; l'agence reconstruit chaque site à la main et absorbe le coût. Les acheteurs publics et les grandes organisations inscrivent désormais des clauses de sortie dans leurs contrats pour cette raison. Notre guide du plan de sortie fournisseur couvre ces clauses. Cette page couvre ce que le produit vous permet réellement d'emporter.

De quoi est fait un site We.Inc

Un site créé sur We.Inc, que ce soit par l'IA, à partir d'un modèle ou à la main, est du code source : des composants React en TypeScript, stylés avec Tailwind, assemblés avec Vite. Les fichiers affichés par l'éditeur sont ceux que vous exportez. Aucune base de données de mise en page cachée dont le code dépendrait.

Panneau Code dans l'éditeur We.Inc affichant l'arborescence du projet et le code source du composant Hero, avec un bouton Télécharger

*Le panneau Code : la vraie arborescence et le code source d'un site client. Télécharger produit un ZIP du projet.*

Vue rapprochée du panneau Code montrant le code source de Hero.tsx avec des imports de framer-motion et du module de contenu

*Le code source de la section hero. Le texte que les clients modifient visuellement est réécrit dans ces fichiers.*

Trois portes de sortie

Méthode	Ce que vous obtenez	Qui peut l'utiliser	Idéal pour
Télécharger le ZIP	Le projet complet, sans les fichiers propres à l'éditeur	Toute personne disposant de la permission « voir le code » sur ce site	Confier un site au développeur d'un client, archiver en fin de contrat
Exporter vers GitHub	Un nouveau dépôt avec le projet, privé par défaut	Le propriétaire du projet, avec une application GitHub connectée ou un jeton d'accès personnel	Les équipes qui veulent un historique de versions hors de We.Inc
Synchronisation GitHub bidirectionnelle	Envoyer depuis l'éditeur, rapatrier les modifications faites dans GitHub	Le propriétaire du projet, forfaits supérieurs uniquement (vérifié côté serveur)	Les développeurs qui modifient dans leurs propres outils entre deux modifications IA ou visuelles

Fenêtre Exporter le projet avec les onglets GitHub, ZIP, Vercel et Domaine, un champ de nom de dépôt et une case Dépôt privé

*La fenêtre d'export. Un nom de dépôt, une option de dépôt privé, et un onglet ZIP à côté.*

Ce qui est retiré du ZIP, et pourquoi

Tant qu'un site est dans l'éditeur, il embarque deux outils qui n'ont de sens que dans We.Inc : un petit plugin de build qui étiquette les éléments pour que l'éditeur visuel les retrouve, et un pont d'aperçu qui permet à l'éditeur de dialoguer avec l'aperçu. Aucun des deux ne sert ailleurs, et le pont serait un risque chez un autre hébergeur. Le ZIP retire les deux et débranche le plugin de la configuration de build, pour que le projet exporté se compile avec un simple npm install && npm run build. La synchronisation GitHub les conserve, car une synchronisation qui rapatrierait une configuration sans le plugin désactiverait l'édition visuelle de ce site.

Ce qui ne part PAS avec le code

Soyez honnête avec vos clients sur cette liste. C'est là que les migrations tournent mal.

L'hébergement. Le ZIP est un projet, pas un site en ligne. Quelqu'un doit le compiler et l'héberger.
Les services back-end. Si un site utilise des formulaires avec réponses stockées, une boutique en ligne, des connexions membres ou une base de données, ces fonctions tournent sur des services connectés à We.Inc. Le code front-end y fait référence ; les données et le service ne sont pas dans le ZIP. Exportez les données séparément et prévoyez des remplacements.
Le domaine. Les domaines sont enregistrés séparément. Voir domaines personnalisés pour les clients.
Votre portail de marque. Les comptes clients, vos modèles, vos e-mails et vos réglages relèvent de la plateforme, pas du site.
L'historique des modifications dans l'éditeur. Utilisez l'export GitHub si vous avez besoin d'un historique à l'extérieur.

Testez avant de signer : un exercice de sortie de 30 minutes

Faites-le pendant l'évaluation, pas à la fin du contrat.

Créez un site réaliste sur un compte de démonstration (un modèle suffit).
Téléchargez le ZIP depuis le panneau Code.
Sur une machine vierge : décompressez, lancez npm install, puis npm run build.
Servez le dossier de build avec n'importe quel hébergeur statique et cliquez sur chaque page.
Notez tout ce qui appelle un service We.Inc (formulaires, boutique, connexion) et décidez de ce qui le remplacerait.
Exportez vers un dépôt GitHub privé et vérifiez que les fichiers correspondent.
Consignez le résultat dans votre plan de sortie avec la date du test.

Si une étape échoue, signalez-le pendant la démo. Nous préférons le savoir.

Contrôler qui voit le code

Tous les clients ne doivent pas voir les fichiers source ; certains seront perdus, quelques-uns casseront des choses. « Voir le code » est un réglage par client, défini par défaut au niveau de la marque et modifiable pour chaque client.

Réglages par défaut de la marque dans We.Inc, intitulés Ce que vos clients peuvent faire, avec des interrupteurs pour la publication, le domaine propre, l'accès au code et d'autres fonctionnalités

*Réglages par défaut de la marque. Désactivez l'accès au code pour tous, puis activez-le pour le client dont le développeur en a besoin.*

Questions à poser à tout fournisseur sur la sortie

Posez-les-nous, ainsi qu'à tous ceux que vous évaluez :

L'export est-il le code même sur lequel tourne le site, ou une copie convertie ?
Le projet exporté se compile-t-il sans le compte ni les paquets du fournisseur ?
Quelles fonctionnalités dépendent des services du fournisseur après l'export, et comment leurs données sont-elles exportées ?
Pouvez-vous exporter un site, tous les sites, ou les deux ? Combien de temps pour une centaine ?
Qui, dans votre organisation, peut exporter, et est-ce contrôlable par compte ?
Pouvez-vous tester l'export pendant l'essai ou la période d'évaluation ?

Sur We.Inc, l'export se fait site par site. Pour un grand réseau, prévoyez le temps d'exporter chaque site, ou gardez les sites synchronisés en continu avec GitHub pour que la copie de sortie existe déjà.

Quand d'autres plateformes conviennent mieux

Si vous avez besoin d'un CMS traditionnel où des non-développeurs gèrent des milliers de contenus via un back-office structuré, un CMS headless ou d'entreprise conviendra mieux qu'un projet React exporté. Si vos clients n'auront jamais de développeur et ne partiront jamais, l'export compte moins que le confort d'édition ; regardez plutôt l'éditeur visuel.

Réservez une démo et nous réaliserons avec vous l'exercice de sortie ci-dessus pendant l'appel.

Faites l'exercice de sortie lors d'une démo

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

Puis-je télécharger le code du site d'un client ?

Oui. Le panneau Code dispose d'un bouton Télécharger qui produit un ZIP du projet. Les fichiers propres à l'éditeur sont retirés et le projet se compile avec npm install et npm run build.

Quel framework utilise le code exporté ?

React avec TypeScript, Tailwind CSS et Vite.

La synchronisation GitHub est-elle bidirectionnelle ?

Oui. L'envoi transmet les fichiers de l'éditeur à GitHub et le rapatriement ramène les modifications faites dans GitHub. La synchronisation est réservée au propriétaire du projet et aux forfaits supérieurs, avec un contrôle côté serveur.

Les formulaires, la boutique et les connexions fonctionnent-ils encore après l'export ?

Pas tout seuls. Ces fonctionnalités tournent sur des services connectés à We.Inc. Le code part avec vous ; les services et leurs données non : prévoyez des remplacements et exportez les données séparément.

Puis-je cacher le code à mes clients ?

Oui. « Voir le code » est un réglage par client, avec une valeur par défaut pour toute la marque.