// OUTIL GRATUIT · FICHIER HTML → VRAI LIEN
Héberger un fichier HTML
Déposez un fichier .html et voyez-le rendu exactement comme un navigateur le rendra, avec la liste de ce qui cesse de fonctionner à la seconde où le fichier quitte votre disque. Ensuite vous le publiez gratuitement sur une vraie adresse HTTPS : deux commandes, sans inscription, et rien de cette page n’est envoyé où que ce soit.
Aussi enEnglishDeutschEspañolFrançais日本語Português (Brasil)繁體中文
Déposez ici un fichier .html, ou choisissez-en un. Il est lu en local avec FileReader et ne quitte pas cet onglet.
La vérification suit votre frappe. L’aperçu se redessine un tiers de seconde après que vous vous arrêtez.
Rendu dans un cadre isolé, scripts autorisés et aucun accès à cette page. Les fichiers de votre propre dossier ne se résolvent pas ici ; ils le feront une fois déployés à côté de la page.
Mettre un fichier HTML en ligne en trois étapes
La vérification et l’aperçu se passent sur cette page ; la publication tient en deux commandes, dans votre terminal ou directement depuis l’agent avec lequel vous codez. Rien n’est téléversé ici : le vérificateur est un script qui tourne dans votre propre navigateur.
- Ouvrez le fichier. Faites glisser votre .html sur la zone, choisissez-le avec le sélecteur de fichiers, ou collez le code. Il est lu en local avec FileReader et rendu dans un cadre isolé : vous voyez donc exactement ce que verrait un visiteur.
- Réglez les bloquants. Chaque constat porte son numéro de ligne. Les bloquants sont ce qui se comporte autrement dès que le fichier est servi en HTTPS depuis un domaine : références vers votre propre disque, sous-ressources en http://, viewport ou titre manquants. Le reste vaut la peine d’être ajouté avant que quelqu’un ne fasse un lien vers la page.
- Publiez. Placez le fichier dans un dossier sous le nom index.html, réservez un identifiant gratuit avec clize claim, puis lancez clize deploy sur le dossier. L’adresse HTTPS est là dans la minute, et le même dossier peut être redéployé autant de fois que vous voulez.
Ce qui casse quand le fichier quitte votre disque
Un fichier ouvert depuis file:///Users/vous/Bureau/page.html et le même fichier servi depuis https://votrenom.clize.app/ ne vivent pas dans le même monde. Les quatre différences ci-dessous expliquent la quasi-totalité des « pourtant en local ça marchait », et le vérificateur de cette page les trouve toutes sans envoyer votre fichier nulle part.
| Ce que fait le fichier | En local | Une fois en ligne |
|---|---|---|
src="file:///Users/vous/…" | L’image s’affiche | Cassé pour tout le monde sauf vous : le chemin est sur votre machine |
src="http://cdn…" | Se charge | Bloqué comme contenu mixte sur une page HTTPS, sans erreur visible |
href="style.css", src="img/entete.png" | Vient du dossier | Ne se charge que si ces fichiers ont été déployés à côté |
Pas de <meta name="viewport"> | Personne ne le remarque | Tous les téléphones la rendent en largeur bureau, puis la rétrécissent |
Le vérificateur signale deux choses de plus, invisibles jusqu’à ce qu’il soit trop tard : un <title> manquant, qui devient le texte de tous les liens que l’on fera un jour vers la page, et un og:image manquant, qui explique pourquoi certains liens ont une vignette dans une conversation et pas le vôtre. Si vous voulez seulement regarder le fichier plutôt que le publier, la visionneuse HTML fait le même rendu, avec trois largeurs et sans parler de mise en ligne.
Le  qui apparaît partout : la signature d’un texte français mal encodé
C’est le bug le plus français qui soit, et il ne se déclenche jamais en local — seulement une fois la page servie. Vous ouvrez votre fichier sur le bureau, tout va bien. Vous le mettez en ligne, et la page se couvre de  : « Bonjour Â! », « Tarifs Â: », « « bienvenue » ». Parfois les accents partent aussi, en é et è.
La cause tient en une phrase : votre fichier est enregistré en Windows-1252 (ou ISO-8859-1) alors que le serveur annonce charset=utf-8. En local, le navigateur ouvre le fichier lui-même, regarde les octets et devine juste. Servi par un serveur, il n’a plus le droit de deviner : il obéit à l’en-tête, et chaque octet non ASCII se transforme en une paire de caractères.
Pourquoi ce  est-il un problème typiquement français ? Parce que le français est la langue qui met une espace insécable avant les signes doubles — ! ? ; : — et à l’intérieur des guillemets « ». Cette espace, c’est U+00A0, soit l’octet 0xA0, qui en UTF-8 se lit  suivi d’une espace. Word, InDesign et la plupart des CMS francophones l’insèrent tout seuls. Un texte anglais, lui, n’en contient pratiquement pas : le même fichier mal encodé passerait presque inaperçu.
| Vous avez écrit | Ce qui s’affiche | Octet d’origine |
|---|---|---|
espace insécable avant ! | Â suivi d’une espace | 0xA0 |
| é | é | 0xE9 |
| « » | « » | 0xAB et 0xBB |
| œ | Å“ | 0x9C |
La correction se fait une fois pour toutes : convertissez le fichier en UTF-8 — iconv -f WINDOWS-1252 -t UTF-8 page.html > page-utf8.html, ou « Enregistrer sous → UTF-8 » dans n’importe quel éditeur sérieux — puis mettez <meta charset="utf-8"> en toute première ligne du <head>. Le vérificateur ci-dessus signale l’absence de cette balise ; en revanche il ne peut pas deviner l’encodage réel de vos octets, et nous préférons le dire plutôt que de laisser croire le contraire.
Deux détails de typographie tant qu’on y est. L’espace fine insécable U+202F, recommandée devant ! ? ; et à l’intérieur des guillemets, n’existe pas du tout en Windows-1252 : elle n’a de sens qu’en UTF-8, ce qui est une raison de plus de convertir. Et <html lang="fr"> ne sert pas qu’aux lecteurs d’écran : c’est aussi ce qui donne au navigateur les bonnes règles de coupure et les bons guillemets pour l’élément <q>.
Enfin, un point que cet outil ne traite pas : un site professionnel français doit afficher des mentions légales et, s’il traite des données personnelles, une politique de confidentialité. Nous ne les générons pas. Ce sont des pages à écrire vous-même — et comme clize deploy publie un dossier, elles partent en ligne avec le reste.
Deux commandes, et le fichier a une adresse
Publier n’est pas un formulaire. Vous installez une fois, puis réserver un nom gratuit et déployer font une commande chacun — les deux mêmes commandes que votre agent de code exécute quand vous lui demandez de mettre la page en ligne, puisque c’est la même CLI.
$ npm i -g @clize/clize && clize login
$ clize claim vieuxfour
✓ vieuxfour.clize.app est à vous ; la page provisoire est en place.
$ clize deploy ./site --domain vieuxfour.clize.app
{
"host": "vieuxfour.clize.app",
"url": "https://vieuxfour.clize.app",
"files": 2,
"notFound": "spa (auto)",
"geo": { "sitemap": "…/sitemap.xml", "llms": "…/llms.txt", "robots": "…/robots.txt" }
}L’identifiant est attribué au premier arrivé et reste le vôtre jusqu’à ce que vous le libériez. clize deploy attend un dossier : mettez donc votre fichier dans un dossier et nommez-le index.html — c’est toute la cérémonie du « fichier unique ». Attachez le dossier une fois avec clize init --handle vieuxfour et les déploiements suivants n’ont plus besoin de --domain. Toutes les commandes sont dans la référence des commandes (en anglais).
Ce que couvre exactement l’hébergement HTML gratuit ici
Gratuit veut dire : l’identifiant, le certificat et les déploiements — pas une période d’essai. Voici toute la surface, pour décider avant de taper quoi que ce soit :
- Une vraie adresse.
votrenom.clize.appen HTTPS, certificat émis automatiquement. Vous pourrez faire pointer votre propre domaine dessus plus tard sans déplacer les fichiers. - Des sites à plusieurs fichiers, pas seulement une page. Tout ce qui est dans le dossier monte : pages, CSS, images, polices. Jusqu’à 90 Mo par fichier et 5 Go par site.
- De vrais 404 quand vous en voulez. Ajoutez un
404.htmlet les chemins inconnus renvoient un vrai 404 ; sans lui, ils retombent surindex.htmlavec un 200, ce qui est exactement ce qu’attend une application monopage.--not-foundtranche dans les deux sens. - Des URL propres.
/atelier/sert directement/atelier/index.html, sans saut de redirection. Les réponses sont mises en cache publiquement pendant cinq minutes. - Une surface lisible par les machines, générée pour vous. Chaque déploiement répond à
/sitemap.xml,/llms.txtet/robots.txtà partir de la liste des fichiers ; publiez les vôtres sous ces noms et ce sont les vôtres qui gagnent. - Une boîte mail au même nom, si vous voulez.
clize claim votrenom --emailouvre en plussupport@votrenom.clize.apppour le courrier entrant.
Ce que ce n’est pas : il n’y a pas d’éditeur visuel, et aucune page publicitaire ne s’intercale devant la vôtre. Vous écrivez ou générez le HTML — à la main, ou en le demandant à l’agent que vous utilisez déjà — et le déploiement publie exactement ces octets.
// Questions fréquentes
Comment mettre un fichier HTML en ligne ?
Mettez le fichier dans un dossier, nommez-le index.html et publiez ce dossier. Avec Clize ce sont deux commandes : clize claim votrenom réserve l’identifiant gratuit votrenom.clize.app, et clize deploy ./dossier --domain votrenom.clize.app place les fichiers derrière, en HTTPS. Avant cela, passez le fichier dans le vérificateur de cette page : il trouve les références qui ne fonctionnent que sur votre propre machine.
L’hébergement HTML proposé ici est-il vraiment gratuit ?
Oui. L’identifiant sur votrenom.clize.app, le certificat HTTPS et les déploiements ne coûtent rien et ne demandent pas de carte. Un compte Clize est nécessaire pour être propriétaire du nom, ce qui empêche deux personnes de réclamer le même. On ne paie que pour ce qui coûte de l’argent ailleurs, comme enregistrer son propre domaine — et le prix est annoncé et confirmé avant tout prélèvement.
Puis-je héberger un seul fichier .html ou faut-il un site entier ?
Un seul fichier suffit. La commande de déploiement prend un répertoire et non un fichier : mettez donc votre fichier unique dans un dossier et appelez-le index.html. Tout le reste du dossier monte avec lui, ce qui permet d’ajouter plus tard une feuille de style ou des images sans rien changer à l’adresse.
Pourquoi ma page se remplit-elle de  une fois en ligne ?
Parce que le fichier est enregistré en Windows-1252 alors que le serveur annonce charset=utf-8. En français, l’espace insécable placée avant les points d’exclamation, d’interrogation, les deux-points et dans les guillemets vaut l’octet 0xA0, qui se relit alors comme  suivi d’une espace. Convertissez le fichier en UTF-8 avec iconv, puis mettez meta charset utf-8 en première ligne du head.
Mon fichier est-il téléversé quand je l’ouvre dans ce vérificateur ?
Non. Le fichier est lu dans votre navigateur avec FileReader et rendu dans une iframe isolée de la même page. Rien n’est envoyé à un serveur, il n’y a pas de compte, et la page continue de fonctionner sans réseau une fois chargée.
Pourquoi mes images disparaissent-elles une fois la page en ligne ?
Presque toujours pour l’une de deux raisons. Soit le src pointe vers un chemin de votre propre disque, du type file:///Users/vous/Bureau/photo.jpg, qui n’existe pour personne d’autre ; soit c’est une URL http://, qu’une page HTTPS bloque comme contenu mixte sans afficher d’erreur. Le vérificateur signale les deux avec le numéro de ligne.
Puis-je utiliser mon propre domaine au lieu de l’identifiant gratuit ?
Oui. Achetez ou importez un domaine avec clize domain, puis déployez dessus avec --domain votredomaine.fr ; l’enregistrement DNS et le certificat sont mis en place à cette occasion. L’identifiant gratuit continue de fonctionner : vous pouvez donc publier d’abord et choisir un nom ensuite.
Donnez au fichier une adresse qu’il pourra garder.
Une installation, un nom, un déploiement. L’identifiant est à vous jusqu’à ce que vous le libériez, le certificat est automatique, et le même dossier peut être republié autant de fois que vous voulez.
$ npm i -g @clize/clize && clize login $ clize claim votrenom $ clize deploy ./site --domain votrenom.clize.app[ Démarrer avec Clize → ]