Ce qu’un export HTML propre doit vraiment contenir.

Le mot “export” recouvre des réalités très différentes. Certains outils fournissent une capture figée, d’autres un HTML qui continue de charger la moitié du site depuis leur infrastructure, et d’autres encore produisent un projet complet mais impossible à lire. Un export propre se juge moins au nombre de fichiers qu’à son autonomie et à sa clarté.

1. Définir ce que “HTML propre” signifie

Un bon export doit pouvoir être copié sur un hébergement statique et fonctionner sans le compte du builder. Les pages, styles, scripts et médias essentiels doivent être présents. Le code doit également offrir une base raisonnable pour les futures modifications : titres identifiables, sections cohérentes, noms de classes stables et interactions séparées du contenu.

2. Commencer par une structure de fichiers prévisible

La racine du ZIP doit être évidente. L’hébergeur doit trouver un index.html sans avoir à deviner quel sous-dossier publier. Les pages secondaires peuvent être organisées en dossiers avec leur propre fichier d’index, ou en fichiers HTML explicites. Les deux approches sont valides si les liens sont cohérents.

votre-site/
├── index.html
├── contact/index.html
├── blog/index.html
├── assets/
│   ├── images/
│   ├── fonts/
│   ├── icons/
│   └── videos/
├── css/styles.css
├── js/app.js
├── robots.txt
├── sitemap.xml
└── README.md

Évitez les noms opaques lorsque ce n’est pas nécessaire. Un hash est utile pour le cache d’un fichier généré, mais une image appelée hero-studio.webp est plus simple à remplacer qu’un fichier sans contexte. Le README doit indiquer comment lancer le site localement, où se trouvent les points de configuration et quelles fonctions demandent un backend.

3. Vérifier le HTML sémantique

Le HTML doit décrire la page, pas seulement reproduire sa géométrie. Utilisez un seul titre principal par page, une hiérarchie logique de sous-titres, des éléments nav, main, section, article et footer lorsque leur rôle est réel. Les boutons déclenchent des actions ; les liens changent de destination.

• Chaque page possède une langue, un titre et une description uniques.
• Les titres suivent une hiérarchie compréhensible sans dépendre de leur taille visuelle.
• Les images informatives ont un texte alternatif utile ; les images décoratives ont un attribut alternatif vide.
• Les champs de formulaire ont des labels et les erreurs sont annoncées correctement.
• Les liens internes fonctionnent avec et sans slash final selon la stratégie choisie.

4. Rendre les assets et les polices réellement locaux

Un export peut sembler autonome tout en gardant des URL temporaires dans le CSS, les balises d’image, les sources vidéo ou les déclarations de polices. Recherchez les domaines du builder dans tous les fichiers. Vérifiez aussi les variantes responsive : une image principale peut être locale tandis qu’un srcset continue de pointer vers l’extérieur.

Conservez les formats modernes lorsque le navigateur les supporte, mais prévoyez des dimensions cohérentes. Une image de 5000 px utilisée dans une card de 320 px ralentit inutilement la page. Pour les polices, gardez uniquement les graisses réellement utilisées, déclarez font-display: swap et utilisez une pile de repli proche pour limiter le changement de mise en page.

5. Demander un CSS maintenable, pas seulement minifié

La minification réduit le poids, mais elle ne rend pas un fichier propre. Un CSS maintenable centralise les couleurs, rayons, espacements et ombres dans des variables, regroupe les composants et limite les règles extrêmement spécifiques. Les styles responsive doivent correspondre à des changements de composition réels, pas à une accumulation de correctifs.

:root {
  --ink: #202326;
  --paper: #f7f7f7;
  --accent: #fd3a25;
  --radius-card: 28px;
  --shadow-card: 0 18px 60px rgb(0 0 0 / 8%);
}

.card {
  border-radius: var(--radius-card);
  background: var(--paper);
  box-shadow: var(--shadow-card);
}

Inspectez aussi les propriétés qui provoquent des débordements : largeurs fixes, transforms très larges, éléments positionnés hors écran et filtres coûteux. Le site doit rester utilisable à 320 px de large et lorsqu’un utilisateur zoome le texte.

6. Isoler le JavaScript des contenus

Le JavaScript doit améliorer l’expérience, pas être nécessaire pour afficher le texte principal. Les interactions doivent cibler des attributs stables comme data-accordion ou data-modal, plutôt que des classes générées susceptibles de changer à chaque export.

Supprimez les scripts de prévisualisation, d’édition et de tracking que vous ne souhaitez pas conserver. Pour chaque script tiers restant, documentez sa fonction, son propriétaire et la manière de le désactiver. Une dépendance distante non expliquée est un point de panne futur.

• Le menu mobile fonctionne au clavier et restitue l’état aria-expanded.
• Les animations au scroll utilisent un mécanisme efficace et cessent d’observer les éléments terminés.
• Les formulaires empêchent les doubles soumissions et affichent un état de chargement.
• Les erreurs sont capturées sans bloquer le reste de la page.

7. Contrôler accessibilité, SEO et données sociales

Un export visuel ne doit pas effacer les informations invisibles qui rendent la page compréhensible. Testez la navigation au clavier, le contraste, le focus, l’ordre de lecture et les labels. Vérifiez ensuite les balises canoniques, l’aperçu social, les données structurées utiles et les fichiers robots.txt et sitemap.xml.

Les pages de prévisualisation ne doivent pas être indexées par erreur. À l’inverse, la production ne doit pas conserver un noindex hérité d’un environnement de test. Le domaine canonique doit être mis à jour lorsque le site change d’hébergement.

8. Mesurer la performance et réduire la surface de risque

Mesurez le projet sur un serveur, pas en ouvrant simplement un fichier local. Contrôlez le poids total, la taille des images au-dessus de la ligne de flottaison, les polices, le JavaScript non utilisé et les requêtes tierces. Chargez les médias secondaires de manière différée et donnez des dimensions aux images pour éviter les déplacements de contenu.

Ajoutez des en-têtes de sécurité adaptés à votre hébergeur et ne placez jamais de secret dans le ZIP. Les clés privées, tokens et identifiants d’administration n’ont rien à faire dans un projet statique livré au navigateur.

9. Checklist finale avant livraison

• Le ZIP s’ouvre directement sur un index.html à la racine.
• Aucune ressource critique ne dépend du domaine du builder d’origine.
• Les pages et redirections ont été testées avec un vrai serveur local.
• Le HTML reste lisible, sémantique et modifiable par une autre équipe.
• Le CSS contient des tokens et ne repose pas sur une cascade incontrôlable.
• Le JavaScript est documenté, limité aux interactions utiles et sans secret.
• Les formulaires, le clavier, le focus, le SEO et les aperçus sociaux ont été vérifiés.
• Un README indique le déploiement, les dépendances et les limites connues.

Le meilleur export est celui que vous pouvez confier à un développeur six mois plus tard sans devoir lui redonner accès au builder. Il doit comprendre le projet depuis les fichiers eux-mêmes et pouvoir le déployer ailleurs sans reconstruction complète.