Publier et maintenir un site web

Un site web a besoin d’un dossier de projet contenant tous les fichiers utilisés par les visiteurs. C’est la racine du site. La publication est bien plus facile lorsque ce dossier constitue un site complet et transportable : aucune image empruntée au dossier Téléchargements et aucune feuille de style laissée dans le dossier d’un autre projet.

Donne une place à chaque type de fichier

Un petit atelier de réparation pourrait utiliser cette organisation :

riverside-bikes/
  index.html
  prices.html
  contact.html
  404.html
  css/styles.css
  scripts/menu.js
  images/logo.svg
  images/workshop-800.jpg
  images/workshop-1600.jpg
  blog/index.html
  blog/winter-checklist.html

Les pages HTML contiennent le contenu, css/ contient les styles, scripts/ les fichiers JavaScript et images/ les images prêtes pour les visiteurs. Un site sans scripts n’a pas besoin de dossier de scripts. Des dossiers distincts facilitent la recherche des fichiers liés sans modifier la manière dont le navigateur les utilise.

La plupart des serveurs web envoient index.html lorsqu’un visiteur demande un dossier. L’adresse https://www.example.com/ ouvre la page d’accueil à la racine. L’adresse https://www.example.com/blog/ ouvre blog/index.html. Un fichier nommé home.html reste une page, mais le serveur ne le choisit généralement pas pour l’adresse du site seule.

Choisis les noms avant la mise en ligne

Utilise des lettres minuscules, des tirets entre les mots et l’extension correcte. opening-hours.html et team-photo.jpg sont des noms explicites. Les espaces peuvent apparaître sous la forme %20 dans les URL, ce qui rend une adresse plus difficile à lire et à saisir. Les noms deviennent une partie des adresses publiques du site : choisis-les donc en fonction du contenu qu’ils désignent.

L’extension doit correspondre au fichier : .html pour le HTML, .css pour le CSS, .js pour les scripts et une extension d’image adaptée comme .jpg, .webp ou .svg. Le serveur envoie un champ d’en-tête HTTP Content-Type qui décrit le format du fichier. Les systèmes d’hébergement utilisent généralement les extensions pour choisir ce type. Renommer une photo de .jpg en .webp ne convertit pas son contenu ; exporte-la dans le nouveau format avec un outil d’image.

La plupart des serveurs distinguent les majuscules des minuscules. Un lien vers Logo.svg peut échouer lorsque le fichier téléversé est logo.svg, même s’il fonctionnait sur un ordinateur dont le système de fichiers ne distingue pas la casse. Prendre l’habitude d’utiliser des noms en minuscules évite ce problème dans les nouveaux projets.

Sépare les fichiers publics des fichiers de travail

Garde les originaux de l’appareil photo, les fichiers de conception et les notes hors de la racine du site, par exemple dans riverside-bikes-originals/. Exporte uniquement les images préparées pour le Web dans images/. Les fichiers du dossier publié peuvent être téléchargés même si aucune page ne contient de lien vers eux. Ne place pas de mots de passe, de documents privés ni de données personnelles dans ce dossier.

Avant le téléversement, vérifie que chaque ressource locale liée se trouve dans le projet. Une photo à une adresse personnelle file:// existe sur ton ordinateur ; elle ne suit pas le site à moins que tu ne la copies dans le dossier publié. Après l’avoir déplacée, mets à jour le lien et teste-le à nouveau.

Une structure stable protège aussi les liens après la mise en ligne. Déplacer prices.html vers une nouvelle adresse casse les anciens favoris, sauf si l’hébergeur redirige l’ancienne adresse vers la nouvelle page.

Un chemin indique au navigateur où chercher un fichier. Pour l’écrire correctement, repère à la fois le fichier demandé et l’emplacement à partir duquel le navigateur résoudra le chemin.

Pars du dossier du fichier qui contient le chemin

Un chemin relatif part du dossier de la page courante. Dans le site de l’atelier de vélos, index.html contient un lien vers prices.html avec href="prices.html", vers le logo avec src="images/logo.svg" et vers un article avec href="blog/winter-checklist.html".

Depuis blog/winter-checklist.html, le parcours change :

<link rel="stylesheet" href="../css/styles.css">
<a href="../index.html">Home</a>
<img src="../images/logo.svg" alt="Riverside Bike Repair">
<a href="autumn-tips.html">Autumn tips</a>

Pour le logo, remonte d’abord depuis blog/ avec ../, puis entre dans images/. Pour un fichier dans le même dossier, seul son nom est nécessaire. Pour remonter de deux niveaux, utilise ../../. Utilise toujours des barres obliques / dans les chemins web, y compris lorsque tu écris sous Windows.

Un chemin dans un fichier CSS part du dossier du fichier CSS. Dans css/styles.css, la règle background-image: url("../images/pattern.svg"); remonte depuis css/, puis descend dans images/. Elle ne part pas de la page HTML qui charge la feuille de style.

Distingue trois formes d’adresse

Une URL absolue comprend le schéma d’URL et le nom d’hôte. Utilise-la pour un autre site web. Les chemins relatifs permettent de déplacer ton propre site entre un serveur local, une adresse de prévisualisation et son domaine final sans remplacer le domaine dans chaque lien.

Une barre oblique initiale a un sens précis. À l’adresse https://username.github.io/riverside-bikes/, /css/styles.css demande https://username.github.io/css/styles.css. Le dossier du projet disparaît de l’adresse. Depuis la page à la racine du site, css/styles.css conserve ce dossier et atteint le fichier voulu.

Teste l’adresse réellement utilisée par le navigateur

Ouvrir directement le HTML depuis le disque donne une adresse file://. Les liens vers des dossiers et les chemins commençant par / peuvent s’y comporter différemment. Lance un serveur de développement local depuis le dossier du site, par exemple avec python3 -m http.server, ou utilise l’aperçu en direct d’un éditeur de code. Ouvre ensuite l’adresse HTTP locale fournie.

Sur un serveur, href="blog/" ouvre blog/index.html. Si un lien ou une image ne fonctionne pas, ouvre les outils de développement avant de recharger et trouve sa requête dans le panneau Réseau. Une erreur 404 signifie que la ressource demandée est introuvable. Lis l’URL complète demandée et compare chaque dossier, barre oblique, lettre et extension aux fichiers téléversés. Une majuscule ou un ../ manquant suffit à envoyer le navigateur ailleurs. Un chemin d’ordinateur personnel copié depuis un explorateur de fichiers ne peut pas servir les visiteurs ; remplace-le par un chemin à l’intérieur du site.

Les navigateurs essaient d’afficher les pages même lorsque le code contient des erreurs. Cette récupération est utile aux visiteurs, mais elle peut masquer des problèmes à la personne qui a écrit le code. La validation vérifie que le HTML ou le CSS respecte les règles de sa norme, indépendamment de l’apparence de la page.

Utilise le vérificateur adapté au langage

Le W3C Nu Html Checker vérifie le HTML. Le W3C CSS Validation Service vérifie le CSS. Tu peux soumettre une URL publiée, téléverser un fichier ou coller du code. Les vérifications intégrées à un éditeur sont utiles pendant la rédaction ; les vérificateurs en ligne permettent aussi de contrôler la copie publiée.

Lis la ligne et la colonne associées à chaque message. Une erreur enfreint une règle et doit être corrigée. Un avertissement ou un message d’information attire ton attention, mais peut décrire du code autorisé. Lis son contenu avant de décider si une modification est nécessaire.

Pars de la première erreur et descends dans la liste, puis relance le vérificateur après la correction. Un guillemet manquant ou un élément mal fermé peut donner l’impression que le code qui suit appartient à un autre endroit et produire de nombreux messages en cascade.

Corrige la structure en HTML

Examine ces éléments mal imbriqués :

<p>Open <strong>daily</p></strong>

L’élément intérieur <strong> doit être fermé avant l’élément extérieur <p> :

<p>Open <strong>daily</strong></p>

Pour une photo porteuse de sens, fournis un attribut alt qui décrit son contenu pertinent, par exemple alt="Mechanic adjusting the brakes of a city bike". Une image décorative utilise un attribut vide alt="". Chaque id doit aussi être unique dans sa page. Utilise une classe commune lorsque plusieurs éléments ont besoin du même style.

Il est aussi utile de vérifier la déclaration de type de document, le titre de la page, les guillemets complets des attributs et la présence des éléments de liste à l’intérieur d’une liste. Un <div> ne peut pas se trouver dans un paragraphe. Le navigateur ferme ce paragraphe avant l’élément div et un </p> placé plus loin peut devenir une balise de fermeture isolée. La structure corrigée par le navigateur peut différer du texte que tu as écrit.

Corrige les déclarations en CSS

Un nombre et son unité CSS vont ensemble : écris width: 100px;, sans espace entre 100 et px. La propriété de couleur du texte est color. Une propriété inconnue est ignorée.

Un point-virgule manquant peut aussi endommager la déclaration suivante :

.card {
  margin: 10px
  padding: 5px;
}

Le navigateur lit les deux lignes comme une seule déclaration invalide. Ajoute le point-virgule manquant après 10px, puis vérifie à nouveau. Les navigateurs ignorent généralement les déclarations invalides sans afficher d’erreur sur la page.

Associe les vérifications du code à celles de la page

Réussir la validation ne prouve pas que la page est accessible, rapide, utile ou que son contenu est exact. Essaie la navigation au clavier, examine la mise en page dans les navigateurs et vérifie le contenu lui-même. Si le vérificateur CSS signale une fonctionnalité très récente, consulte sa spécification et les informations de compatibilité sur MDN avant de supprimer du code qui fonctionne ; les vérificateurs peuvent prendre du retard sur les nouvelles fonctionnalités.

Valide après des modifications importantes et avant la publication. Après le téléversement, soumets l’adresse en ligne et vérifie que le contenu le plus récent est visible. Une ancienne page valide peut passer la validation aussi facilement que la page mise à jour.

Les outils de développement, souvent appelés DevTools, montrent comment le navigateur interprète ta page. Fais un clic droit sur un élément et choisis Inspecter. Tu peux aussi utiliser F12 ou Ctrl+Shift+I sous Windows et Linux, ou Cmd+Option+I sous macOS. Dans Safari, active d’abord « Afficher les fonctionnalités pour les développeurs web » dans Réglages, Avancés.

Inspecte la structure du navigateur

Le panneau Éléments, appelé Inspecteur dans Firefox, affiche le DOM : la structure construite à partir du HTML. Le navigateur peut avoir corrigé un balisage invalide : ce n’est donc pas toujours une copie directe du code source. Un <div> écrit dans un paragraphe apparaît en dehors de celui-ci dans le DOM, car le navigateur ferme d’abord le paragraphe.

Sélectionne l’élément qui présente le problème. Le panneau Styles liste les règles CSS correspondantes et renvoie à leurs fichiers source et à leurs numéros de ligne. Une déclaration barrée n’est pas active. Une autre règle peut l’emporter sur elle, ou une icône d’avertissement peut indiquer que la déclaration est invalide. Le panneau Calculé montre les valeurs finales des propriétés après l’application de ces règles par le navigateur.

Analyse une règle de couleur qui ne l’emporte pas

Supposons que ce lien apparaisse en bleu marine alors que sa classe de bouton demande du blanc :

<a class="btn" href="contact.html">Contact us</a>

#main a { color: navy; }
.btn { color: white; }

Les deux règles correspondent lorsque le lien se trouve dans id="main". Le sélecteur d’identifiant rend #main a plus spécifique : sa spécificité est de (1, 0, 1), contre (0, 1, 0) pour .btn. Dans ces règles ordinaires, placer .btn plus loin ne suffit pas à surmonter cette différence.

Une correction ciblée consiste à utiliser #main .btn, de spécificité (1, 1, 0). Une autre consiste à remplacer la règle générale avec identifiant par une classe de lien comme .nav-link. Deux sélecteurs comportant chacun une seule classe ont la même spécificité : leur ordre peut donc décider de la couleur. Remplacer #main a par .main a laisse une spécificité de (0, 1, 1), qui l’emporte sur .btn. Inspecte la règle qui l’emporte réellement avant de choisir la plus petite correction utile.

Mesure toute la boîte

Le schéma du modèle de boîte distingue le contenu, la marge intérieure, la bordure et la marge extérieure. Avec box-sizing: content-box, un contenu de 300 px de large, une marge intérieure de 20 px de chaque côté et des bordures de 2 px occupent :

La boîte, bordures comprises, mesure donc 344 px, avant toute marge extérieure. Avec box-sizing: border-box, la largeur de toute la boîte, bordures comprises, reste de 300 px ; celle de son contenu devient :

Utilise le schéma pour expliquer un espace ou un débordement plutôt que de modifier les largeurs à répétition au jugé. Les badges Flexbox et de grille peuvent aussi afficher les pistes, lignes et espaces de la mise en page.

Essaie une modification, puis enregistre-la

Désactive une déclaration, modifie une valeur ou ajoute une règle dans Styles. Force :hover ou :focus pour examiner un état sans maintenir le pointeur ou le focus clavier en place. Ces modifications sont temporaires : les modifications ordinaires dans les outils de développement ne mettent pas à jour tes fichiers de projet. Reporte la modification qui fonctionne dans le code source, enregistre et recharge. Si la correction disparaît, elle n’a pas encore été enregistrée dans la copie chargée par le navigateur.

Une page est assemblée à partir de plusieurs requêtes. Le HTML peut arriver correctement alors que le chargement d’une feuille de style ou d’une image échoue. Les messages de la console et le panneau Réseau montrent ces résultats distincts.

Ouvre les outils avant de recharger

La console signale les erreurs et les avertissements, notamment les échecs de script, les ressources manquantes et le contenu mixte. Les messages renvoient souvent au fichier et à la ligne concernés. Même un site en HTML et CSS peut produire des messages utiles dans la console.

Le panneau Réseau enregistre les requêtes de la page lorsque les outils de développement sont ouverts. Ouvre-les, recharge, puis filtre par CSS, images ou polices pour réduire la liste. Lis l’URL demandée, le statut, le type, la taille et la durée. Sélectionne une entrée pour inspecter les champs d’en-tête HTTP et le contenu de sa réponse.

Un statut de la série 400 concerne la requête ; un statut de la série 500 concerne le serveur. Une erreur 404 n’indique pas qu’il faut modifier la mise en page CSS.

Recherche la cause d’un logo manquant

La page en ligne présente un emplacement d’image vide. Dans le panneau Réseau, sa requête est https://www.example.com/images/Logo.svg et renvoie 404. Le fichier téléversé est images/logo.svg. Le L majuscule demandé ne correspond pas au véritable nom en minuscules. Corrige le chemin HTML, déploie la page et vérifie que la requête réussit maintenant.

Recherche la cause d’une page sans style

Cherche d’abord la requête CSS. Si aucune requête n’apparaît, inspecte l’élément <link>, y compris rel="stylesheet". Si la requête renvoie 404, compare son URL à l’emplacement du fichier téléversé.

Un statut 200 indique seulement que la réponse a réussi, pas qu’elle contient du CSS. Vérifie la console et le champ Content-Type de la réponse, qui doit valoir text/css. Un hébergeur peut renvoyer par erreur une page d’erreur HTML avec le statut 200, et le navigateur refusera de l’appliquer comme feuille de style. Une fois le bon CSS reçu avec le bon type, inspecte les déclarations invalides et les sélecteurs qui ne correspondent pas à l’élément concerné.

Écarte la copie enregistrée par le navigateur

Un cache stocke des fichiers pour les réutiliser. Il économise du temps de téléchargement, mais une ancienne copie peut donner l’impression qu’une mise à jour réussie manque. Les outils de développement ouverts, active « Désactiver le cache » dans le panneau Réseau et recharge. Dans Chrome, Edge et Firefox, Ctrl+Shift+R sous Windows et Linux ou Cmd+Shift+R sous macOS force un rechargement complet. Inspecte le contenu renvoyé avant de conclure que le téléversement a échoué.

Les colonnes de taille et de durée aident aussi à repérer les problèmes de vitesse. Une image de 3,6 Mo parmi de minuscules fichiers texte est un bon point de départ. La limitation du débit réseau simule une connexion plus lente. Une page HTTPS qui demande un fichier avec http:// peut déclencher un avertissement de contenu mixte ; inspecte l’URL exacte de la ressource pour trouver la référence non sécurisée.

Un rapport de bogue utile décrit une différence observable : « À 360 px de largeur, la page de contact défile horizontalement. » C’est plus facile à examiner que « la mise en page sur mobile est cassée ». Note l’adresse de la page, le navigateur, la largeur de l’écran, le résultat obtenu et le résultat attendu.

Suis les indices en cinq étapes

1. Reproduis. Fais réapparaître le problème dans les mêmes conditions.
2. Recueille des indices. Lis la console et le panneau Réseau, valide le code et inspecte l’élément concerné.
3. Isole. Désactive une règle ou retire temporairement un petit morceau de code pour cerner la cause.
4. Modifie une seule chose. Vérifie si cette modification explique le résultat.
5. Enregistre et teste à nouveau. Applique la correction dans le code source, recharge et vérifie dans d’autres conditions.

Modifier plusieurs choses à la fois rend le résultat difficile à interpréter. Une modification peut résoudre le problème initial tandis qu’une autre en crée un nouveau. Garde le cas qui échoue à disposition pour pouvoir comparer avant et après.

Traite un débordement sur écran étroit

Une page tient sur un ordinateur portable, mais défile horizontalement avec une zone d’affichage de 360 px. Ouvre le mode adaptatif à cette largeur. Survole les éléments dans Éléments et observe leurs boîtes mises en évidence. Une image est plus large que sa colonne ; son HTML lui donne une grande largeur intrinsèque et aucun CSS ne la limite.

Essaie cette règle :

img {
  max-width: 100%;
  height: auto;
}

La largeur maximale permet à l’image de rétrécir pour tenir dans son conteneur. La hauteur automatique conserve ses proportions. Si le débordement disparaît, enregistre cette règle dans la bonne feuille de style et recharge. Teste ensuite l’image à des largeurs plus grandes aussi. Masquer le débordement horizontal de la page pourrait cacher une partie de l’image sans la faire tenir dans son conteneur.

Si la modification ne change rien, sers-toi des indices pour cerner l’étape suivante. La règle apparaît-elle dans Styles ? Une autre l’emporte-t-elle sur elle ? Le navigateur a-t-il chargé le fichier que tu as modifié ? Parmi les causes courantes figurent des noms de classe différents, des chemins incorrects, des accolades ou des points-virgules manquants, des fichiers non enregistrés et des copies en cache.

Teste les moteurs comme les tailles de fenêtre

Le mode adaptatif modifie la largeur de la zone d’affichage et peut simuler le tactile, mais il ne reproduit pas tous les détails de vitesse, de police ou de rendu d’un vrai téléphone. Vérifie les points de rupture des requêtes média et les largeurs intermédiaires, puis utilise au moins un vrai téléphone.

Chrome et Edge utilisent Blink, Firefox utilise Gecko et Safari utilise WebKit. Deux navigateurs utilisant le même moteur n’offrent pas une couverture de test aussi large que des navigateurs utilisant des moteurs différents. Safari est particulièrement pertinent pour les nombreux navigateurs sur iPhone qui utilisent WebKit. Consulte les informations de compatibilité de MDN avant de compter sur une fonctionnalité récente.

Vérifie la version publiée

Le comportement du serveur peut révéler des erreurs masquées sur le disque : noms sensibles à la casse, fichiers non téléversés et chemins qui ignorent un sous-dossier de projet. Ouvre l’adresse en ligne, suis les liens et inspecte les requêtes échouées sur cette version.

Avant de publier, valide le HTML et le CSS, inspecte les erreurs de la console, cherche les erreurs 404 involontaires, essaie les largeurs d’un téléphone, d’une tablette et d’un ordinateur, et vérifie au moins deux moteurs de navigateur. Utilise le clavier pour parcourir la navigation et activer les contrôles. Après le déploiement, répète les vérifications sur le site en ligne là où la fonctionnalité modifiée est utilisée.

Une image optimisée est un fichier léger qui reste satisfaisant à ses dimensions d’affichage. Commence par le format, les dimensions en pixels et la compression. Réduire une photo trop grande avec CSS change son apparence, mais le navigateur télécharge et décode toujours le fichier original.

Adapte le format au contenu

Les images matricielles stockent des pixels. Agrandir une petite image matricielle fait apparaître du flou, car aucun détail supplémentaire n’est créé. Le SVG stocke des formes et des lignes : il convient donc à un logo, mais pas à une photo prise avec un appareil. Les principaux navigateurs actuels prennent en charge WebP et AVIF. Pour l’animation, un format d’image moderne ou une courte vidéo produit souvent un fichier plus léger que le GIF.

La compression sans perte conserve les valeurs des pixels. La compression avec perte supprime certains détails pour économiser davantage d’octets. Une qualité inférieure finit par produire des zones en blocs ou des contours flous. Compare l’exportation à ses dimensions d’affichage réelles. Effectue chaque nouvelle exportation à partir de l’original, en évitant les enregistrements répétés avec perte d’une copie déjà compressée.

Redimensionne pour le plus grand usage

Une photo affichée avec une largeur maximale de 800 pixels CSS nécessite environ 800 pixels d’image sur un écran de densité standard et 1 600 sur un écran utilisant deux pixels de l’appareil par pixel CSS. Prépare des variantes adaptées au lieu d’envoyer l’original de l’appareil photo à tout le monde.

L’original de l’atelier de vélos mesure 4 000 × 3 000 pixels et pèse 3,6 Mo. Une exportation en 1 600 × 1 200 donne :

pixels, soit 16 % des 12 millions de l’original. Une exportation JPEG à la qualité 80 peut peser environ 240 Ko ; la taille réelle dépend de la photo. Dans cet exemple, le fichier économise environ 93 % des octets.

À 10 Mbit/s, en utilisant les Mo décimaux, le temps de transfert idéal de l’original est de :

secondes. L’exportation de 0,24 Mo prend environ 0,19 seconde. Ce sont uniquement des temps de transfert ; le chargement réel comprend aussi les délais de connexion et de réponse du serveur. Avec un décodage à 4 octets par pixel, l’utilisation de mémoire passe de 48 Mo à 7,68 Mo. Un fichier encodé plus léger et un nombre inférieur de pixels décodés sont deux gains distincts.

Exporte une copie publique

Utilise les commandes d’exportation d’un éditeur d’image ou un outil comme Squoosh. Garde l’original hors du dossier publié et donne aux exportations des noms explicites comme workshop-800.jpg et workshop-1600.jpg. Supprime les métadonnées de l’appareil à l’exportation ; elles peuvent comprendre la date de la photo, les informations sur l’appareil et la position GPS.

Pour un SVG, un outil d’optimisation comme SVGO supprime les données laissées par le logiciel de dessin. La compression du texte sur le serveur peut réduire encore sa taille transférée. Quel que soit le format, inspecte l’image terminée : une photo enregistrée en PNG peut être inutilement lourde, tandis qu’un logo contenant beaucoup de texte enregistré en JPEG peut présenter des contours brouillés.

Une image peut être assez légère pour se télécharger rapidement tout en faisant sauter la page. Le navigateur doit connaître ses proportions avant son arrivée et disposer de choix adaptés aux différents écrans.

Réserve l’espace avec les dimensions

Écris les attributs numériques width et height sans unité :

<img src="images/workshop-800.jpg"
     width="800" height="600"
     alt="Mechanic adjusting the brakes of a city bike">

Ces dimensions indiquent au navigateur le rapport largeur-hauteur de 4:3. Avec max-width: 100%; height: auto; en CSS, l’image rétrécit pour tenir dans une colonne étroite. Dans une colonne de 360 px de large, sa hauteur est de :

pixels. Réserver cet espace empêche le texte situé en dessous de descendre lorsque l’image se charge. L’absence de dimensions peut produire des décalages de mise en page, les mouvements inattendus mesurés par le CLS.

Propose des largeurs que le navigateur peut choisir

Pour une même photo en deux tailles, utilise des descripteurs de largeur et une description de sa largeur d’affichage :

<img src="images/workshop-800.jpg"
     srcset="images/workshop-800.jpg 800w,
             images/workshop-1600.jpg 1600w"
     sizes="(max-width: 840px) 100vw, 800px"
     width="800" height="600"
     alt="Mechanic adjusting the brakes of a city bike">

800w et 1600w indiquent les largeurs réelles des fichiers. Dans cette mise en page, sizes indique que l’image occupe la largeur de la zone d’affichage jusqu’à 840 px et mesure 800 px au-delà. Le navigateur utilise la largeur déclarée de l’emplacement, la densité de l’écran et ses règles de sélection pour choisir un fichier. Fais correspondre sizes à la mise en page réelle ; annoncer toute la largeur de la zone d’affichage pour une colonne bien plus étroite peut entraîner des téléchargements inutiles.

Propose des formats avec un contenu de repli

<picture>
  <source srcset="images/workshop.avif" type="image/avif">
  <source srcset="images/workshop.webp" type="image/webp">
  <img src="images/workshop.jpg" width="800" height="600"
       alt="Mechanic adjusting the brakes of a city bike">
</picture>

Le navigateur choisit le premier format source pris en charge. L’élément <img> obligatoire fournit le contenu de repli, les dimensions et l’alternative textuelle. Il s’agit d’un choix de format ; srcset avec des descripteurs de largeur résout le problème lié du choix d’une largeur adaptée en pixels.

Diffère les images qui ne sont pas encore nécessaires

Utilise loading="lazy" pour les images situées plus bas dans une page. Le navigateur peut attendre que le visiteur s’en approche, ce qui économise des données pour les images jamais atteintes. Garde le chargement immédiat pour les images visibles dès le premier affichage, en particulier la grande image principale. Différer son chargement retarde le contenu que les visiteurs attendent de voir. Une image principale dans le HTML est découverte tôt ; fetchpriority="high" permet de demander une priorité de récupération plus élevée pour elle.

Rédige l’alternative textuelle alt selon la fonction de l’image dans son contexte. Une image décorative reçoit alt="". Les photos et les schémas porteurs de sens doivent figurer dans le HTML sous forme d’images ; un arrière-plan CSS convient à la décoration et ne possède ni attribut alt ni attribut loading natif.

Le poids de la page est la quantité totale de données téléchargées pour une page. Le HTML entraîne des requêtes pour le CSS, les images, les scripts et les polices. La taille des fichiers, le nombre de requêtes, la vitesse de connexion et les performances de l’appareil contribuent tous à l’expérience.

Trouve la plus grande part

La page d’accueil de l’atelier de vélos télécharge 15 Ko de HTML, 30 Ko de CSS, deux polices de 40 Ko, une image principale de 2 400 Ko et trois photos de 350 Ko :

Ko. Les images représentent 3 450 Ko, soit environ 96,5 %. Avec une image principale de 220 Ko et trois photos de 45 Ko, le total devient :

Ko, soit environ 87 % de moins. À 10 Mbit/s, le temps de transfert idéal passe d’environ 2,86 secondes à 0,38 seconde. La réponse du serveur et l’établissement de la connexion ajoutent du temps. Supprimer quelques espaces du CSS aurait peu d’effet à côté de cette économie sur les images.

Lis les mesures de l’expérience

Les Core Web Vitals, en octobre 2026, mesurent différents problèmes :

De bonnes performances sur le terrain respectent chaque seuil au 75e percentile. Le CLS peut prendre en compte une bannière qui déplace le contenu après le chargement, et pas seulement une image qui arrive pendant le chargement initial.

Lighthouse dans Chrome ou Edge effectue un test de laboratoire avec des scores et des corrections proposées. PageSpeed Insights effectue des tests en ligne et, lorsqu’il existe assez d’observations, affiche des données de terrain issues de visites réelles sur Chrome. Un score de laboratoire correspond à un test dans des conditions choisies. Répète les comparaisons avec les mêmes réglages et examine les visites réelles lorsqu’elles sont disponibles.

Améliore d’abord les éléments les plus coûteux

Prépare d’abord les images et leur balisage. Réduis ensuite les familles et les graisses de police inutiles, utilise des polices WOFF2 et font-display: swap pour afficher le texte dans une police de repli pendant le chargement de la police. Ajoute defer aux scripts externes adaptés afin que leur téléchargement ne bloque pas l’analyse syntaxique du HTML et qu’ils s’exécutent après celle-ci. Les grandes cartes, les lecteurs vidéo et les autres contenus tiers intégrés peuvent être chargés à la demande.

La minification supprime les espaces et les commentaires du code. La compression gzip ou Brotli réduit le nombre d’octets de texte transférés. Ces méthodes aident, mais les images JPEG, WebP et AVIF déjà compressées gagnent peu à subir une compression supplémentaire de type texte.

La mise en cache permet aux visiteurs qui reviennent de réutiliser des fichiers ; elle est contrôlée par des champs d’en-tête HTTP comme Cache-Control. Un réseau de diffusion de contenu conserve des copies dans différentes régions pour réduire la distance parcourue par les requêtes. Lorsqu’une ressource conservée longtemps en cache change, un nom comme styles-v2.css ou une adresse comme styles.css?v=2 en fait une nouvelle requête. Teste avec une limitation du débit réseau et sur un téléphone ; un ordinateur portable rapide en Wi-Fi peut masquer une expérience lente sur mobile.

Chaque page doit expliquer sa propre fonction dans son HTML. Les moteurs de recherche lisent ce balisage, et les onglets du navigateur, les favoris et les lecteurs d’écran en dépendent aussi. Une structure claire commence par le contenu que les visiteurs peuvent réellement lire.

Nomme la page dans l’en-tête du document

L’élément <title> se place dans <head>. Donne à chaque page son propre titre descriptif, avec le nom du site après le sujet précis :

<title>Repair Prices – Riverside Bike Repair</title>
<meta name="description"
      content="Prices for flat repairs, brake adjustments and full services at Riverside Bike Repair. Walk in Monday to Saturday or book online.">

Le titre apparaît dans l’onglet du navigateur et les favoris, et fournit généralement le titre des résultats de recherche. Le HTML n’impose aucune limite de longueur au titre, mais les résultats de recherche coupent le texte pour l’adapter à l’affichage : place donc les mots utiles en premier. Un titre générique comme « Accueil » donne peu d’informations lorsqu’il est séparé du site.

La méta-description est un résumé lisible de la page en une ou deux phrases. Les moteurs de recherche peuvent l’utiliser pour l’extrait d’un résultat, mais ils peuvent aussi choisir du texte de la page. Adapte la description au contenu de cette page. Copier une même description sur toutes les pages masque leurs différences ; une liste de mots-clés répétés n’est pas un résumé utile. Google ignore l’ancienne balise meta keywords.

Déclare la langue et les caractères

Utilise <html lang="en"> pour une page en anglais. Cela aide les lecteurs d’écran à choisir la prononciation et les navigateurs à gérer les fonctions liées à la langue. Google identifie la langue à partir du texte visible et ignore cet attribut : ne le considère donc pas comme un réglage de langue pour Google.

Place <meta charset="utf-8"> tôt dans l’en-tête du document pour que les caractères comme é et le tiret demi-cadratin s’affichent correctement. Inclus la balise meta de la zone d’affichage utilisée pour les pages adaptatives :

<meta name="viewport" content="width=device-width, initial-scale=1">

Fais correspondre le plan aux idées

Utilise un <h1> clair pour le sujet principal de la page, des <h2> pour ses grandes sections et des <h3> pour les sous-sections. Sur la page des tarifs, « Services » est un titre h2, avec les titres h3 « Service de base » et « Service complet » en dessous. Choisis les niveaux de titre selon cette relation ; ajuste leur taille visuelle avec CSS.

Les éléments sémantiques indiquent les rôles : <nav> pour la navigation, <main> pour le contenu principal, ainsi que des éléments <header>, <article>, <section> et <footer> adaptés. Utilise de véritables listes, des liens pour la navigation et des boutons pour les actions. Une page composée de divisions génériques perd ces indications de rôle. Garde les mots importants comme les tarifs, les horaires d’ouverture et les titres dans le texte HTML, où ils sont disponibles sous forme de texte pour les visiteurs et les outils.

Prépare un aperçu utile pour le partage de liens

Les balises Open Graph décrivent un aperçu de lien dans les applications sociales et de messagerie. Les propriétés courantes sont og:title, og:description et og:image :

<meta property="og:title" content="Repair Prices">
<meta property="og:image"
      content="https://www.example.com/images/workshop-800.jpg">

Utilise une URL HTTPS complète pour l’image d’aperçu. Ces balises décrivent la carte de partage ; elles ne remplacent ni les titres visibles de la page ni son titre et sa description ordinaires.

L’exploration consiste à récupérer des pages, souvent en suivant des liens. L’indexation consiste à stocker des informations sur ces pages pour les résultats de recherche.

Donne accès à chaque page par un lien

Relie chaque page depuis au moins une autre page avec un lien <a href> ordinaire. Un texte descriptif comme « tarifs de réparation » indique aux visiteurs et aux robots d’exploration ce que contient la page cible. Un chemin lisible comme /blog/winter-checklist.html donne plus de contexte que /page7.html.

Un plan de site liste les URL complètes à privilégier que tu souhaites voir découvertes. Une entrée XML peut ressembler à ceci :

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/prices.html</loc>
    <lastmod>2026-10-01</lastmod>
  </url>
</urlset>

La date facultative de dernière modification doit correspondre à un changement important. Mets à jour le plan de site lorsque les pages changent. Un petit site bien relié peut être découvert sans plan de site.

Distingue les contrôles d’exploration et d’indexation

Un fichier robots.txt à la racine du domaine indique aux robots d’exploration qui le respectent les chemins qu’il leur est demandé de ne pas récupérer :

User-agent: *
Disallow: /drafts/
Sitemap: https://www.example.com/sitemap.xml

Cela ne verrouille pas le dossier. Les personnes peuvent ouvrir ses adresses et une URL bloquée peut quand même apparaître dans les résultats si d’autres pages y renvoient. Sans fichier robots.txt, les robots sont autorisés à récupérer les pages. Une ligne Disallow: / copiée bloque l’exploration de tout le site : supprime donc ce blocage provenant d’un site de test avant la mise en ligne si le site doit être exploré.

Pour demander l’exclusion des résultats de recherche, place ceci dans l’en-tête du document :

<meta name="robots" content="noindex">

Le robot doit récupérer la page pour lire cette instruction. Bloquer la même URL dans robots.txt peut l’empêcher de découvrir noindex. Aucun de ces réglages ne rend une page privée : le contenu privé nécessite un contrôle d’accès ou doit rester hors du site public.

Choisis une adresse pour le contenu dupliqué

Une page peut répondre à des adresses HTTP et HTTPS, avec et sans www, ou à la fois sur /blog/ et /blog/index.html. Un lien canonique indique l’adresse à privilégier :

<link rel="canonical" href="https://www.example.com/blog/">

Utilise l’URL absolue complète. Le balisage canonique est une forte indication ; une redirection qui envoie réellement les visiteurs vers l’adresse privilégiée est un signal plus fort. Fais correspondre les liens internes et les URL du plan de site à cette adresse pour éviter d’envoyer des signaux contradictoires.

Vérifie ce que les moteurs de recherche peuvent voir

Google Search Console et Bing Webmaster Tools acceptent les plans de site et montrent les problèmes d’indexation et d’exploration après vérification que tu contrôles le site. Une recherche site:example.com donne une vue approximative des pages indexées. Les nouveaux sites peuvent mettre des jours ou des semaines à apparaître. Un plan de site, un balisage propre ou un paiement ne peuvent pas garantir un classement élevé ; ces outils t’aident à trouver les obstacles techniques et à comprendre ce qui a été traité.

Un site statique sert des fichiers HTML, CSS, image et script préparés. Son contenu peut être mis à jour chaque fois que tu publies de nouveaux fichiers ; « statique » décrit la manière dont l’hébergeur les sert. Le serveur d’hébergement continue de les distribuer lorsque ton propre ordinateur est éteint.

Sache ce que fournit l’hébergeur

Un site web dynamique construit les réponses sur le serveur, souvent à partir d’une base de données. Un petit site d’information ou un portfolio créé en HTML et CSS peut utiliser un hébergement statique sans programmation côté serveur. Ajouter le balisage d’un formulaire de contact ne crée pas à lui seul un service qui stocke ou envoie par courriel les données soumises. Cela nécessite une prise en charge des formulaires par l’hébergeur ou un service distinct.

Les hébergeurs statiques fournissent généralement une adresse temporaire, des commandes de publication et HTTPS. Beaucoup servent les fichiers par un réseau de diffusion de contenu qui conserve des copies régionales. GitHub Pages, Netlify, Cloudflare Pages et Vercel en sont des exemples, avec des conditions d’offre et des méthodes de travail différentes. L’hébergement mutualisé est une autre possibilité et prend souvent en charge le transfert sécurisé de fichiers.

Une page statique peut quand même exécuter du JavaScript dans le navigateur du visiteur, par exemple pour l’interaction avec un menu. L’hébergeur sert toujours un fichier de script préparé. Sans code d’application du site ni base de données exécutés sur le serveur, il y a moins de composants applicatifs à attaquer ; le compte d’hébergement et les fichiers publics doivent tout de même être protégés.

Un site utilisateur GitHub Pages utilise l’adresse racine https://username.github.io/ à partir d’un dépôt nommé username.github.io. Un site de projet utilise un sous-dossier comme /riverside-bikes/. Cette structure d’adresse compte lors du test des chemins de ressources relatifs à la racine.

Compare les besoins avec l’offre actuelle

Lis les limites et les conditions de l’offre avant de choisir. Vérifie :

• Les capacités de stockage et de transfert mensuel de données.
• Si l’offre autorise l’usage commercial.
• La prise en charge des domaines personnalisés et HTTPS automatique.
• Une méthode de publication que tu peux utiliser de manière fiable.
• Les pages d’erreur personnalisées, les redirections et le retour à un déploiement précédent.
• La prise en charge des formulaires si les visiteurs doivent envoyer des informations.
• La facilité avec laquelle tu peux transférer tes fichiers vers un autre hébergeur.

Le portfolio d’un photographe composé de six pages et de 40 photos préparées respecte les limites de taille de nombreuses offres statiques gratuites. Toutefois, s’il attire des contrats rémunérés, sa finalité commerciale compte aussi. La taille seule ne prouve pas qu’une offre gratuite l’autorise. Les conditions changent : vérifie donc le service et l’offre réels plutôt que de te fier à une ancienne comparaison.

Choisis une méthode de publication que tu peux gérer

La publication par glisser-déposer peut convenir à un petit projet : tu téléverses le dossier par l’interface de l’hébergeur. Une connexion à un dépôt publie depuis une source de code enregistrée choisie et peut déployer les mises à jour lorsque les modifications sont envoyées. Les outils en ligne de commande offrent une autre possibilité. L’hébergement mutualisé prend souvent en charge SFTP, une méthode chiffrée de transfert de fichiers. FTP simple expose les identifiants et les fichiers pendant le transfert : utilise donc une méthode sécurisée.

Avec GitHub Pages sur une offre gratuite, la publication est possible à partir de dépôts publics. Tout le monde peut lire les fichiers du dépôt. Les ressources publiées sont également publiques, même si la navigation ne contient pas de lien vers elles. Limite le téléversement aux fichiers destinés au public et protège le compte d’hébergement avec l’authentification à deux facteurs.

Vérifie une fonctionnalité dans son utilisation réelle

Si le site comprend un formulaire de contact, repère le point de réception du formulaire ou la fonctionnalité de l’hébergeur qui le reçoit. Confirme que l’offre comprend cette fonctionnalité et envoie un message de test après la mise en ligne. Un formulaire qui semble complet peut pourtant ne disposer d’aucune destination pour les données. Si une page 404 personnalisée ou une redirection permanente est importante, confirme la méthode de configuration exacte de l’hébergeur avant de compter dessus.

Déployer consiste à publier les fichiers actuels du site chez un hébergeur. Le répertoire de publication devient la racine du site en ligne. Pour du HTML et du CSS sans outil de compilation, il n’y a pas d’étape de compilation : sélectionne le dossier contenant le fichier index.html terminé et ses ressources.

Effectue la première publication

Pour un hébergeur qui accepte le glisser-déposer :

1. Ouvre le dossier que tu comptes publier et vérifie que index.html s’y trouve directement.
2. Valide les pages et teste leurs liens et leur mise en page au moyen d’un serveur local.
3. Téléverse ce dossier avec l’interface de publication de l’hébergeur.
4. Attends que l’hébergeur indique que le déploiement est en ligne.
5. Ouvre l’adresse web fournie et vérifie le site à cette adresse.

Si la page d’accueil n’apparaît qu’à /riverside-bikes/index.html, tu as peut-être téléversé le dossier situé un niveau trop haut. Le répertoire de publication voulu est riverside-bikes/, pas le dossier qui le contient. Corrige le choix du répertoire et publie à nouveau ; envoyer simplement les visiteurs vers l’adresse du sous-dossier laisse l’adresse d’accueil principale incorrecte.

Publie depuis un dépôt

Dans GitHub Pages, ouvre les paramètres du dépôt, puis Pages. Choisis « Deploy from a branch », sélectionne la branche et le dossier de publication, soit sa racine, soit /docs, puis enregistre. Lorsqu’une nouvelle version est envoyée à cette source de publication, Pages la déploie à nouveau. Vérifie l’adresse Pages affichée une fois le déploiement terminé. L’URL d’un projet peut inclure le nom du dépôt : teste donc les chemins à cet emplacement réel.

Les autres hébergeurs possèdent leurs propres réglages de connexion au dépôt et de répertoire. Pour un site composé de fichiers simples, n’ajoute pas de commande de compilation simplement parce que l’interface propose un champ pour celle-ci.

Vérifie la version distribuée

Ouvre chaque page, suis les liens internes et inspecte la console et le panneau Réseau pour repérer les ressources dont le chargement a échoué. Force un rechargement complet pour ne pas confondre les fichiers en cache avec la nouvelle version. Essaie le site sur un vrai téléphone. Vérifie que la modification que tu voulais publier est visible, sans te contenter de l’absence de message d’erreur.

Configure une page 404.html personnalisée lorsque l’hébergeur le permet. Elle doit indiquer au visiteur que l’adresse est introuvable et lui proposer un moyen utile de revenir à l’accueil. Essaie une adresse inexistante inventée pour vérifier que l’hébergeur l’utilise réellement. Une page d’erreur utile ne remplace pas une redirection lorsque le contenu a été déplacé.

Garde une source que tu peux restaurer

Le projet local ou le dépôt connecté est la source de référence, la copie à partir de laquelle les versions futures sont publiées. Une correction rapide dans l’éditeur web d’un hébergeur peut disparaître au téléversement suivant si tu ne la reportes pas aussi dans cette source.

Utilise un déploiement de prévisualisation lorsqu’il est disponible pour tester une mise à jour avant qu’elle n’atteigne les visiteurs. Si une mise à jour casse le site en ligne, un retour à une version antérieure chez l’hébergeur peut restaurer un déploiement précédent. Corrige ensuite aussi la source, sans quoi la publication suivante risque de réintroduire le défaut.

Lorsqu’une page change d’adresse, ajoute une redirection 301 permanente de l’ancienne URL vers la nouvelle avec les règles de redirection de l’hébergeur. Teste l’ancienne adresse après publication : elle doit mener à la nouvelle page voulue. Sur Netlify, un fichier _redirects est une méthode de configuration ; les autres hébergeurs utilisent d’autres réglages.

Un nom de domaine est un nom lisible comme example.com. Le DNS associe ce nom à des informations comme l’adresse IP d’un hébergeur. L’enregistrement te donne le droit d’utiliser le nom pendant une période ; ce n’est pas un achat définitif.

Lis une adresse web

Dans https://www.example.com/prices.html, https est le schéma d’URL, www.example.com est le nom d’hôte et /prices.html est le chemin. Lis les labels DNS de droite à gauche : .com est le domaine de premier niveau ; example est le nom enregistré sous celui-ci ; www est un sous-domaine.

Les domaines de premier niveau génériques comprennent .com, .org, .net, .dev, .shop et .studio. Les domaines de premier niveau nationaux utilisent deux lettres, comme .de, .fr, .jp, .ca et .au. Certains noms sont enregistrés sous une catégorie de deuxième niveau, comme .co.uk.

Certaines extensions imposent des conditions d’admissibilité. .ca exige un lien avec le Canada ; .eu accepte les citoyens, résidents et organisations établies admissibles de l’UE ou de l’EEE ; .us exige un lien avec les États-Unis. Vérifie les règles du registre avant de choisir une extension soumise à des conditions. Les extensions .dev et .app exigent HTTPS dans les navigateurs.

Sache qui gère l’enregistrement

Un bureau d’enregistrement inscrit ton enregistrement auprès du registre qui gère le domaine de premier niveau. L’ICANN coordonne le système des domaines de premier niveau génériques et accrédite leurs bureaux d’enregistrement ; les registres nationaux fixent leurs propres règles. Les enregistrements durent généralement de un à dix ans et doivent être renouvelés.

Choisis un nom court, facile à prononcer et à écrire, et proche du nom du projet ou de l’entreprise. Évite les chiffres et les tirets qui prêtent à confusion et vérifie que le nom n’utilise pas la marque d’autrui. Si le nom en .com que tu préfères est déjà pris, compare un nom plus long mais clair, une extension locale adaptée ou une extension générique pertinente. La seule disponibilité d’un nom ne t’autorise pas à utiliser le nom d’une autre entreprise.

Compare les engagements dans la durée

Vérifie le prix du renouvellement ainsi que l’offre de la première année. Les services supplémentaires, dont la messagerie, peuvent être facturés séparément. Le domaine et l’hébergement du site web peuvent provenir d’entreprises différentes ; enregistrer un domaine ne téléverse pas automatiquement un site web.

Fournis des informations exactes sur le titulaire et ses coordonnées, et réponds au courriel de vérification du bureau d’enregistrement. Des coordonnées non confirmées peuvent entraîner une suspension. Pour les informations d’enregistrement des domaines de premier niveau génériques, RDAP est devenu en janvier 2025 le moyen public de consultation de référence, en remplacement des anciennes exigences relatives au service WHOIS. La consultation publique masque généralement les données personnelles ; le bureau d’enregistrement a toujours besoin d’informations exactes.

Laisse le titulaire garder le contrôle

Le responsable du projet ou le patron de l’entreprise doit contrôler le compte du titulaire du nom de domaine, même lorsqu’un concepteur crée le site. Active l’authentification à deux facteurs et garde les informations de récupération à jour. Pour changer de bureau d’enregistrement, suis la procédure de transfert, notamment l’obtention d’un code de transfert et le déverrouillage du domaine lorsque celui-ci est admissible.

Note la date d’expiration, active le renouvellement et veille à ce que le moyen de paiement reste valide. Un enregistrement expiré peut interrompre le site web et la messagerie du domaine ; après les périodes de grâce et de suppression applicables, une autre personne peut enregistrer le nom. Les sauvegardes de l’hébergement ne peuvent pas préserver un enregistrement de domaine que tu laisses expirer.

Le système de noms de domaine, ou DNS, stocke des enregistrements associés à des noms. Un résolveur recherche ces enregistrements et conserve souvent une réponse en cache. Les serveurs de noms faisant autorité sont responsables des informations DNS du domaine. Effectue les modifications chez le fournisseur dont les serveurs de noms desservent réellement le domaine.

Choisis le type d’enregistrement

Les adresses IP et le nom en .example présentés ici sont des valeurs réservées à la documentation. Pour une connexion réelle, utilise les valeurs fournies par ton hébergeur pour ton site.

Le domaine racine est le nom racine enregistré, comme example.com. Le DNS standard n’y autorise pas de CNAME, car le domaine racine a aussi besoin d’autres enregistrements, dont NS. Utilise les valeurs A et AAAA de l’hébergeur, ou une fonctionnalité ALIAS, ANAME ou d’aplatissement CNAME prise en charge par le fournisseur. Un sous-domaine comme www utilise généralement un CNAME.

Connecte deux formes d’une adresse

Supposons qu’un hébergeur demande un enregistrement A pour le domaine racine et un CNAME pour www. Un fournisseur qui utilise @ pour le domaine racine pourrait afficher :

Type    Name    Value                           TTL
A       @       192.0.2.44                       3600
CNAME   www     riverside-bikes.pages.example    3600

Saisis aussi le domaine personnalisé dans les paramètres d’hébergement. L’hébergeur doit reconnaître le nom demandé et l’attribuer au site. Choisis l’adresse principale et configure l’autre forme pour qu’elle y redirige.

Lis les instructions du fournisseur pour le champ du nom. S’il ajoute automatiquement example.com, saisir www.example.com peut créer www.example.com.example.com. Supprime les enregistrements d’adresse obsolètes lorsque tu changes d’hébergeur ; conserver à la fois les anciennes et les nouvelles valeurs peut envoyer les visiteurs vers différents serveurs.

Laisse expirer les réponses en cache

Le TTL, ou durée de vie, indique le nombre de secondes pendant lesquelles une réponse DNS peut être conservée en cache. Un TTL de 3 600 correspond à une heure ; 86 400 correspond à 24 heures. Après une mise à jour, différents visiteurs peuvent temporairement recevoir des réponses différentes. Les modifications peuvent mettre 24 heures ou plus à être visibles partout.

Pour un déplacement planifié, réduis le TTL à 300 secondes au moins une durée de l’ancien TTL avant le changement. Le réduire au moment du changement ne peut pas raccourcir la durée de vie d’une réponse déjà en cache avec l’ancien TTL.

Déplace le DNS sans perdre les autres services

Tu peux laisser le DNS chez le bureau d’enregistrement et modifier les enregistrements, ou remplacer les serveurs de noms par ceux d’un nouveau fournisseur. Un changement de serveurs de noms ne copie pas les enregistrements. Recrée et vérifie les enregistrements MX, TXT et autres nécessaires chez le nouveau fournisseur avant le changement, surtout lorsque la messagerie du domaine fonctionne déjà.

Vérifie les réponses avec nslookup www.example.com, dig example.com A +short ou un service de consultation DNS, puis compare-les aux paramètres de l’hébergeur. N’ajoute des enregistrements génériques que volontairement et lorsque l’hébergeur les prend en charge. Lorsque tu retires un site hébergé, supprime aussi les enregistrements DNS qui pointent vers lui ; un alias oublié peut permettre à une autre personne de revendiquer la cible abandonnée chez l’hébergeur.

HTTPS transmet HTTP sur une connexion TLS chiffrée. Il protège la confidentialité et l’intégrité des données en transit et permet au navigateur d’authentifier le serveur pour le domaine demandé. HTTP simple expose les données aux personnes qui peuvent observer la connexion.

Un certificat identifie le domaine

Un certificat TLS associe un nom de domaine à une clé publique et est signé par une autorité de certification de confiance. Il liste les noms qu’il couvre et sa date d’expiration. Si les visiteurs utilisent à la fois example.com et www.example.com, le certificat doit couvrir les deux noms, même lorsque l’un redirige vers l’autre : le navigateur établit une connexion sécurisée avant de recevoir cette redirection.

Une connexion HTTPS ne permet pas de juger de l’honnêteté d’une entreprise. Un site frauduleux peut obtenir un certificat pour un nom qu’il contrôle. La protection de la connexion et la fiabilité du site sont deux questions distinctes.

Laisse l’hébergeur obtenir et renouveler le certificat

De nombreux hébergeurs statiques demandent automatiquement un certificat gratuit, souvent auprès de Let’s Encrypt, une fois que le DNS pointe vers l’hébergeur et que le domaine est configuré. L’autorité de certification vérifie le contrôle du nom, par exemple au moyen d’un enregistrement DNS ou d’un fichier récupéré sur le Web. La délivrance peut prendre de quelques minutes à environ une journée.

En octobre 2026, les certificats TLS de serveur nouvellement délivrés et reconnus publiquement ont une durée de validité maximale de 200 jours selon les règles entrées en vigueur le 15 mars 2026. Ce maximum passera à 100 jours en mars 2027 et à 47 jours en mars 2029. Les certificats classiques par défaut de Let’s Encrypt durent actuellement 90 jours ; des profils plus courts sont aussi disponibles. Le renouvellement automatique évite de répéter ce travail manuellement.

Pour un exemple de 90 jours, un certificat délivré le 1er mars 2026 expire le 30 mai. Un renouvellement effectué lorsqu’il reste 30 jours aurait lieu vers le 30 avril. La date d’expiration réelle et l’état du renouvellement sont disponibles auprès de l’hébergeur ou dans les détails du certificat ; ne suppose pas qu’un enregistrement de domaine valide signifie aussi que le certificat est à jour.

Redirige vers HTTPS et corrige les ressources non sécurisées

Active la redirection forcée vers HTTPS chez l’hébergeur. Elle redirige les requêtes http:// vers l’adresse HTTPS, généralement avec le statut 301 ou 308. Choisis aussi un nom d’hôte principal, avec ou sans www, et redirige l’autre vers celui-ci.

Il y a contenu mixte lorsqu’une page HTTPS demande une ressource par http://. Les navigateurs bloquent les scripts, feuilles de style, cadres et polices non sécurisés. Ils essaient de convertir certaines requêtes de médias en HTTPS, ce qui échoue si la source ne peut pas les servir en HTTPS. Vérifie les messages de la console et cherche http:// dans le code. Utilise des chemins relatifs pour tes propres fichiers et des URL HTTPS fonctionnelles pour les ressources externes.

HSTS, HTTP Strict Transport Security, indique aux navigateurs d’utiliser HTTPS pendant une durée définie. Active-le lorsque HTTPS fonctionne de manière fiable ; les navigateurs qui ont reçu cette politique ne reviendront pas à HTTP simple pendant cette période. Les extensions .dev et .app sont préchargées pour imposer HTTPS.

Si un avertissement de certificat apparaît après la connexion d’un domaine, vérifie le DNS, l’état de délivrance et les noms couverts. Le domaine racine peut fonctionner alors que www échoue si seul le domaine racine est couvert. Corrige la configuration et attends la délivrance si nécessaire ; les visiteurs ne doivent pas contourner un avertissement de certificat.

Un site en ligne change même lorsque ses fichiers ne changent pas. Les liens externes se déplacent, les coordonnées deviennent obsolètes, les domaines approchent de leur expiration et les widgets tiers changent. La maintenance garde le contenu exact et la distribution fiable.

Suis le même parcours pour chaque mise à jour

Modifie le projet local ou le dépôt, teste dans un navigateur, valide le code concerné, déploie et vérifie les pages en ligne. Crée une prévisualisation lorsque l’hébergeur le permet. Vérifie qu’une correction réussie figure dans la copie utilisée pour les publications futures afin qu’elle ne soit pas perdue au téléversement suivant.

Une modification de contenu mérite aussi une vérification du contenu. Confirme les dates, les horaires d’ouverture, les tarifs et les coordonnées auprès de leur source actuelle. Attribue aux pages un responsable ou une date de révision. Supprime ou remplace les informations qui ne décrivent plus le service ; l’annonce d’un ancien événement peut induire les visiteurs en erreur même si chaque balise est valide.

Vérifie les liens et les tâches des visiteurs

La dégradation des liens est la perte progressive de leur fonctionnement lorsque les pages cibles se déplacent ou disparaissent. Utilise un vérificateur de liens comme le W3C Link Checker, puis vérifie et corrige les échecs signalés. Lorsqu’une de tes pages a été déplacée, une redirection préserve les anciens liens entrants. Pour une page externe, mets à jour la cible ou supprime le lien lorsqu’il n’existe pas de remplacement utile.

Essaie de véritables tâches de visiteur. Envoie un message de test par le formulaire de contact et confirme sa réception. Parcours la navigation au clavier. Teste une mise en page sur téléphone. Une vérification de disponibilité qui reçoit une page ne peut pas prouver qu’un formulaire ou la navigation fonctionne.

Garde des copies que tu peux restaurer

Sauvegarde le code source et les ressources nécessaires à au moins deux endroits, par exemple sur un ordinateur et sur un disque externe, dans un stockage en ligne ou dans un dépôt. Un problème de compte d’hébergement ou un déploiement erroné peut supprimer la copie en ligne : l’hébergeur du site ne doit donc pas être ta seule sauvegarde. L’historique des versions peut permettre de restaurer les versions antérieures. Conserve assez d’informations pour reconnecter le domaine et republier le site.

Assure les renouvellements et l’accès aux comptes

Active le renouvellement automatique du domaine et veille à ce que le moyen de paiement reste valide. Vérifie la date d’expiration et les messages de confirmation. Assure-toi que les comptes du bureau d’enregistrement et de l’hébergeur utilisent l’authentification à deux facteurs et que leurs informations de récupération sont à jour. Le renouvellement du certificat dépend aussi d’une configuration fonctionnelle du domaine : vérifie donc HTTPS après les modifications du DNS.

Un outil de surveillance de la disponibilité vérifie le site à intervalles réguliers et t’alerte lorsqu’il cesse de répondre. Les outils pour les webmasters peuvent révéler les échecs d’exploration et les erreurs 404 provenant d’anciennes adresses. Examine ces rapports, puis teste le problème sous-jacent au lieu de supposer que toutes les alertes ont la même cause.

Planifie le travail selon le type de changement

Les polices, scripts, cartes et autres contenus tiers intégrés peuvent ralentir, changer ou disparaître indépendamment de ton site. Utilise-les en petit nombre et vérifie s’ils sont toujours nécessaires. Lorsqu’une licence le permet, héberger une copie locale d’une ressource peut réduire la dépendance à un autre serveur. Vérifie à nouveau sa licence et ses besoins de mise à jour lorsque tu la remplaces.