Ouvrir un site — Obtenir un projet Next.js sur disque

Il y a quelque temps, j'ai dû restaurer l'interface d'un site web marketing dont le code source avait disparu avec le contractant. Plus précisément, le client n'avait plus qu'un lien de production. Auparavant, j'aurais passé une soirée à copier manuellement la mise en page, mais cette fois j'ai découvert un projet qui le fait en une minute. Et pas via LLM, ce qui m'a surpris.

Qu'est-ce que ditto.site

ditto.site — un compilateur TypeScript open source qui prend une URL publique et la transforme en projet autonome. Par défaut, il génère du Next.js App Router, sur demande — Vite React. Les styles viennent via Tailwind ou du CSS pur.

Je vais clarifier ce que l'auteur entend par « clonage ». Il n'y a pas de git clone ici : vous n'avez pas besoin du dépôt du site ni de son code source. Vous avez seulement besoin d'un lien accessible depuis un navigateur. L'outil ouvre la page, enregistre ce que le navigateur a réellement rendu, et écrit un nouveau projet à partir de cela.

L'auteur qualifie explicitement son système de « pipeline capture-to-code » et souligne que le compilateur n'est pas un LLM qui crée des pages. La même copie capturée produit toujours une sortie byte-for-byte identique. D'ailleurs, le déterminisme est présenté comme la fonctionnalité principale, ce qui est plus honnête qu'une génération neuronale mystérieuse où chaque exécution diffère.

Le projet compte déjà 1580 étoiles et 214 forks sur GitHub, sous licence MIT. Le projet est récent, mais la communauté se forme rapidement autour de lui.

Comment l'utiliser

Trois approches. La plus directe est l'interface CLI locale :

git clone https://github.com/ion-design/ditto.site.git
cd ditto.site
npm ci
npx playwright install chromium
npm run clone -- https://example.com/ --out=./output

Après avoir installé Chromium, la commande npm run clone ouvre la page, capture l'état et place l'application prête dans output/<site>/app. J'apprécie ce détail : sans le flag --out, les résultats vont dans runs/<site>/<timestamp>/, et le lien symbolique runs/<site>/latest pointe toujours vers le dernier clone. Les scripts n'ont pas besoin d'être réécrits pour le nouveau timestamp.

Il existe aussi des modes différés :

npm run clone -- https://example.com/ --serve   # клонирует и сразу поднимает dev-сервер
npm run clone -- https://example.com/ --open    # плюс открывает браузер

La deuxième option est une API REST à api.ditto.site. On génère une clé via un formulaire ou curl avec vérification par email, on l'exporte vers DITTO_API_KEY, puis on lance une tâche :

curl -sS -X POST "$DITTO_API_URL/v1/clones" \
  -H "authorization: Bearer $DITTO_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "url": "https://example.com/",
    "options": {
      "mode": "single",
      "styling": "tailwind",
      "framework": "next"
    }
  }'

La réponse inclut une carte des fichiers avec le chemin, la taille et le SHA-256 de chaque fichier. Le décompresseur CLI facilite l'extraction de l'arborescence sur le disque, et le projet complet peut être téléchargé en une seule archive via /bundle?format=tgz.

La troisième option est un serveur MCP, et honnêtement, c'est la partie la plus intéressante pour moi. ditto.site se connecte aux agents comme un outil MCP ordinaire, et le serveur est conçu pour être économe : d'abord l'agent reçoit seulement l'ID de tâche et les métadonnées, et lit les fichiers selon les besoins. Des outils comme clone_website, list_clone_files et read_clone_files permettent à l'agent de lancer un clone lui-même, d'attendre la fin, et de lire sélectivement package.json ou un composant spécifique.

Ce qui se retrouve dans le projet généré

Le résultat n'est pas juste la mise en page. D'après le README, l'application inclut :

• pages restaurées et modules de routes ;
• assets capturés, polices, icônes, manifestes et métadonnées ;
• robots, sitemap, llms.txt et JSON-LD si détectés ;
• petits helpers runtime pour les interactions et animations reconnues ;
• AGENTS.md et ARCHITECTURE.md générés pour le transfert du projet.

Je note le dernier point séparément. L'auteur s'attend clairement à ce qu'un humain ou un agent IA travaille sur le code ensuite, et inclut immédiatement des instructions sur les fichiers sûrs à modifier : src/app/content.ts et src/app/components/. C'est un niveau de soin rare pour un générateur.

Comment ça fonctionne en interne

Le pipeline ressemble à ceci : URL → capture navigateur → rendu intermédiaire normalisé → sortie déterministe → génération d'application → matérialisation des assets → validation optionnelle.

La capture écrit le DOM, les styles calculés, les boîtes de mise en page, le CSS source, les polices, les captures d'écran et les états d'interaction. Les animations reproductibles sont aussi capturées si observables. Cependant, le JavaScript tiers arbitraire, l'authentification, les paiements et la personnalisation ne sont pas reproduits. C'est une limitation logique : l'outil fonctionne avec ce qui est visible dans le navigateur, pas la logique côté serveur.

Le dépôt a une architecture solide : compilateur, API REST Hono avec serveur MCP, schéma Drizzle avec migrations, worker de file d'attente de tâches, stockage d'artefacts pour S3/R2. Vous pouvez lancer tout en local via docker compose avec Postgres et MinIO, ou exécuter un mode inline simplifié sans base de données en une seule commande. Il y a aussi un point de terminaison MCP à localhost:8787/mcp pour l'API locale.

J'aime qu'il y ait des options verify et asyncVerify : le projet généré peut être validé et vous obtenez une confirmation qu'il se construit au moins et rend similairement à l'original.

Où c'est utile

Le premier scénario est évident : restaurer un site quand il n'y a pas de sources. Une landing page abandonnée, des sources de contractant perdues, une page legacy qui doit être migrée vers une stack moderne. Ici, l'outil résout le problème en quelques minutes.

Le deuxième scénario est le prototypage. Un client montre « Je veux quelque chose comme ici » et partage un lien. Au lieu de discussions abstraites, vous obtenez un projet fonctionnel avec une structure Next.js en quelques minutes, puis vous discutez des différences dedans. Pour un freelancer qui estime le travail à partir d'une référence de quelqu'un d'autre, cela accélère le démarrage.

Le troisième scénario est l'automatisation via MCP. Un agent peut se voir confier la tâche : « clone ce site comme application Next.js, attends la fin, lis les fichiers générés ». Le format « seuls les fichiers nécessaires » économise le contexte de l'agent, et les auteurs ont clairement réfléchi à cela.

L'autre côté et les règles du jeu

Il y a des mises en garde. La CLI réside actuellement dans le dépôt et n'est pas publiée sur npm, donc npx ditto ne fonctionnera pas — vous devez cloner tout le dépôt. Ce n'est pas quelque chose que vous pouvez ajouter à CI avec une seule ligne, mais les auteurs avertissent honnêtement de cela.

Ensuite, il y a l'éthique. Le README rappelle constamment : n'utilisez l'outil que là où vous avez le droit de copier et transformer le contenu. Le phishing, l'usurpation de marque, la contournement d'authentification et la capture massive des sites d'autrui sont explicitement interdits, et le projet dispose d'un document séparé RESPONSIBLE_USE.md. C'est juste : la technologie elle-même est neutre, mais il vaut mieux l'appliquer à vos propres projets ou avec la permission des propriétaires.

Une dernière chose. En russe comme en anglais, le mot « clonage » semble audacieux, mais en réalité c'est une reconstruction de la partie visible de la page. Ne vous attendez pas à ce que l'outil extraie le code côté serveur, une base de données ou la logique métier — il l'indique honnêtement dans le README.

Qui devrait l'essayer

Si vous construisez des landing pages, migrez des sites vers une nouvelle stack, ou voulez donner à un agent IA un outil propre pour travailler avec les interfaces web, jetez un œil à ditto.site. Commencez avec la CLI locale, elle ne nécessite pas de clés : npm run clone -- https://example.com/ --serve, et en quelques minutes vous avez un serveur de développement en cours d'exécution sur le projet restauré. Et si vous voulez intégrer cela dans votre pipeline, l'API REST et le serveur MCP sont déjà inclus. Pour un designer ou un tech lead qui reçoit souvent « fais-le comme ça », l'outil semble être une réponse honnête à un point douloureux très courant.