Mettre à jour un site HTML sur une connexion lente : n'envoyer que les fichiers modifiés

Mettre à jour un site HTML sur une connexion lente : n'envoyer que les fichiers modifiés

Le 10 octobre 2026, je devais mettre en ligne quelques retouches sur mon comparateur. Ma connexion passait par le partage de connexion d'un téléphone, à environ 17 ko par seconde. L'envoi du site complet a échoué trois fois de suite. Voici ce qui a fini par marcher : n'envoyer que ce qui avait changé.

Ce qui coinçait

D'habitude, je mets mon site en ligne d'un bloc : tout le site dans une archive, 3,6 Mo, envoyée chez Hostinger, qui remplace l'ancien site par le nouveau. C'est simple et sûr : en ligne, on a exactement ce qu'on a chez soi.

Mais à 17 ko par seconde, 3,6 Mo, c'est plusieurs minutes d'envoi sans la moindre coupure. Trois fois, l'envoi s'est interrompu au bout d'environ 7 minutes, sur une erreur de reprise. Vingt minutes perdues, et rien en ligne.

Le constat : presque rien n'avait changé

En regardant de près, mes retouches ne touchaient qu'une petite partie du site : quelques pages, une image, le plan du site. Le reste était identique à la version en ligne. Je renvoyais 3,6 Mo pour en changer une petite fraction.

La méthode

  1. Garder une copie de chaque version mise en ligne. Chaque archive envoyée est rangée dans un dossier de sauvegarde. Elle me dit exactement ce qui est en ligne.
  2. Comparer fichier par fichier. Un petit programme compare le site que je viens de fabriquer avec cette archive. Il calcule une empreinte de chaque fichier : si l'empreinte change, le fichier a changé. Il en sort la liste des fichiers modifiés ou nouveaux.
  3. Envoyer ces fichiers un par un. Un petit fichier qui échoue se renvoie en quelques secondes. Mon programme réessaie jusqu'à trois fois avant de signaler un échec.

Résultat : 18 fichiers envoyés en 3 minutes, là où l'archive complète échouait au bout de 7.

Le piège du numéro de version

Ma première liste contenait presque toutes les pages, alors que je n'en avais retouché que quelques-unes. La raison : chaque page appelle le fichier de style avec un numéro de version, qui change à chaque retouche du style. Il sert à forcer le CDN de Hostinger à prendre le nouveau fichier. Mais ce numéro change dans toutes les pages à la fois.

J'ai donc fait ignorer ce numéro lors de la comparaison. Les pages non renvoyées gardent l'ancien numéro, ce qui n'a aucune conséquence : l'ancien fichier de style reste valable pour elles.

L'ordre d'envoi compte

Pendant l'envoi, le site est à moitié ancien, à moitié nouveau. Pour qu'un visiteur ne tombe jamais sur un lien cassé, j'envoie :

  1. d'abord le style, les images et les fichiers à télécharger ;
  2. ensuite les pages nouvelles ou modifiées ;
  3. en dernier, le blog, l'accueil et le plan du site, qui font des liens vers les nouvelles pages.

Ainsi, aucun lien ne pointe vers une page qui n'est pas encore en ligne.

Les limites de la méthode

  • Elle n'efface rien. Une page supprimée chez moi reste en ligne : il faut la retirer à part.
  • Elle repose sur une archive à jour. Si je compare avec une vieille version, la liste est fausse.
  • L'envoi complet reste la méthode normale. Je ne passe aux fichiers un par un que si l'envoi complet échoue deux fois.

Côté sécurité, l'envoi utilise des clés temporaires données par Hostinger. Mon programme les range dans un fichier qu'il vide à la fin, et ne les affiche jamais.

Ce que j'en retiens

  • Garder une copie de ce qui est en ligne sert à bien plus qu'aux sauvegardes.
  • Sur une connexion fragile, mieux vaut beaucoup de petits envois qu'un seul gros.
  • Après l'envoi, un contrôle rapide dans le navigateur : les nouvelles pages, l'accueil, une ancienne adresse.

Si vous ne voulez pas vous occuper de ces mises à jour vous-même, c'est exactement ce que couvre ma prestation de maintenance de site internet. Et pour la première mise en ligne d'un site HTML, tout est raconté dans mon article sur l'hébergement chez Hostinger.

Tarmou