Lancement d'un nouveau site web : la checklist avant la mise en ligne et pour les 90 premiers jours

La checklist de lancement d'un site web est la liste ordonnée des contrôles qu'une équipe réalise avant, pendant et après la mise en ligne : relecture des contenus, formulaires, analytics et consentement, SEO et redirections, performances, accessibilité, sécurité, bascule DNS, puis surveillance des premières semaines. Elle existe parce que la plupart des problèmes coûtent peu à corriger en préproduction, et beaucoup plus une fois que Google a exploré la mauvaise version.

Cette checklist s'adresse aux équipes qui préparent le lancement d'un nouveau site web ou d'un site reconstruit, en interne ou avec une agence, et à tous ceux qui se demandent comment lancer un site internet sans perdre le trafic acquis par l'ancien. Elle suit les trois phases réelles du travail : la recette avant la mise en ligne, le jour J et les 90 jours qui suivent. Chaque point indique quoi vérifier et, quand c'est utile, avec quel outil.

Si le nouveau site remplace un ancien, lisez deux fois la partie sur les redirections. C'est elle qui décide si le trafic de recherche de l'ancien site sera conservé.

Une checklist de mise en ligne utile couvre trois phases. La recette se fait en préproduction et décide si le site est prêt. Le jour du lancement correspond à la bascule elle-même : DNS, caches et signaux d'indexation. Le suivi dure environ 90 jours et confirme que ce qui fonctionnait en préproduction fonctionne aussi avec de vrais visiteurs, de vrais navigateurs et de vrais robots d'exploration. Beaucoup de checklists publiées s'arrêtent au bouton « Publier », c'est pourquoi la troisième phase a ici sa propre partie.

Le tableau ci-dessous en donne la version courte. Vous pouvez le copier tel quel dans votre outil de gestion de projet. Attribuez chaque ligne à une personne nommée : une tâche confiée à « l'équipe » n'appartient en général à personne, et c'est celle qui reste ouverte le matin du lancement.

La relecture des contenus est la partie la moins technique de la recette d'un site web, et celle que les visiteurs remarquent en premier. Relisez chaque page en préproduction, pas dans l'éditeur du CMS, car les gabarits modifient les retours à la ligne et le recadrage des images. Vérifiez les prix, numéros de téléphone, adresses, horaires et informations légales de l'entreprise par rapport à la source, et remplacez chaque texte provisoire, lorem ipsum et image de test. Les liens internes cassés et les boutons qui ne mènent nulle part se traitent dans la même passe.

Contenus et relecture

• Chaque page a sa propre balise title, sa meta description et un seul H1
• Les images ont un texte alternatif qui les décrit et sont compressées (WebP ou AVIF)
• L'année du copyright, les liens vers les réseaux sociaux et le logo qui renvoie à l'accueil fonctionnent
• L'image et le titre Open Graph s'affichent correctement quand un lien est partagé sur Slack, LinkedIn ou WhatsApp
• Une page 404 personnalisée renvoie vers les principales rubriques

Formulaires et délivrabilité des e-mails

Un formulaire qui s'envoie n'est testé qu'à moitié. L'autre moitié consiste à vérifier que l'e-mail de notification arrive bien chez la personne qui doit répondre. Remplissez chaque formulaire avec des données réalistes, puis contrôlez la boîte de réception, le dossier spam et le CRM ou le tableur où le contact doit arriver.

Envoyez les notifications depuis un domaine authentifié ou un service d'e-mails transactionnels, pas avec la fonction mail par défaut du serveur web. Depuis février 2024, les consignes de Gmail pour les expéditeurs exigent de chaque expéditeur qu'il configure SPF ou DKIM, et de ceux qui envoient plus de 5 000 messages par jour qu'ils utilisent les deux et publient un enregistrement DMARC. Un formulaire de contact n'atteindra jamais ce volume, mais un e-mail non authentifié envoyé depuis un domaine neuf finit bien plus souvent en spam, et personne ne s'en rend compte avant qu'un client appelle pour demander pourquoi on ne lui a jamais répondu.

L'analytics doit être en place et vérifié le jour du lancement, car les données de la première semaine qui n'ont pas été collectées ne se récupèrent pas. Coller un tag ne suffit pas. Définissez les actions qui comptent comme un succès (envois de formulaire, demandes de devis, appels, achats), marquez-les comme événements clés dans GA4 et testez chacune dans DebugView ou Tag Assistant avant la bascule DNS, tant que vous pouvez encore corriger sans bruit.

Si le site reçoit des visiteurs de l'Union européenne, le bandeau cookies et l'analytics doivent fonctionner ensemble. Google impose aux sites qui mesurent des utilisateurs de l'EEE avec ses tags de recueillir le consentement et de le transmettre via le consent mode, qui a ajouté deux paramètres, ad_user_data et ad_personalization, aux signaux de stockage d'origine. En France, la CNIL est claire : refuser les cookies doit être aussi simple que les accepter, et les traceurs soumis au consentement ne doivent pas être déposés avant l'accord du visiteur. Testez les deux parcours dans une fenêtre de navigation privée et vérifiez qu'un refus bloque réellement les cookies.

Checklist du suivi

• Propriété GA4 créée, avec le trafic de vos propres bureaux exclu
• Événements clés définis pour chaque conversion qui compte pour l'entreprise
• Propriété Search Console validée avant le lancement, de préférence en propriété de domaine
• Outils de heatmap ou d'enregistrement de sessions déclarés dans le bandeau cookies et la politique de confidentialité
• Convention de nommage UTM fixée pour l'annonce du lancement et les campagnes

La plupart des problèmes SEO du jour J viennent de réglages de préproduction qui passent en production. Un site de préproduction est en général masqué aux moteurs de recherche, et ce masquage doit être levé dès la mise en ligne. Selon la documentation de Google sur le blocage de l'indexation, une page bloquée dans le robots.txt ne peut pas voir sa règle noindex lue, donc vérifiez les deux réglages ensemble plutôt que l'un après l'autre.

Signaux d'indexation

• Retirez les balises meta noindex et les en-têtes X-Robots-Tag ajoutés pour la préproduction
• Le robots.txt du domaine en ligne ne doit pas contenir Disallow: /, et il peut indiquer le sitemap avec une ligne Sitemap:
• Chaque page a une balise canonical qui pointe vers elle-même sur le domaine en ligne, pas vers l'URL de préproduction
• Une seule version du domaine (HTTPS, avec ou sans www) est la principale, et les autres redirigent vers elle
• Les données structurées passent le test des résultats enrichis de Google

Sitemap XML

Générez un sitemap qui ne liste que des URL en ligne, indexables et canoniques. Les consignes de Google sur les sitemaps limitent un fichier à 50 000 URL ou 50 Mo non compressé et précisent que Google ignore les valeurs priority et changefreq : inutile de les régler. lastmod n'est utilisé que s'il est toujours exact.

Redirections depuis l'ancien site

Si le nouveau site en remplace un ancien, le plan de redirection est le document le plus important du projet. Crawlez l'ancien site, exportez ses URL avec les pages qui ont des backlinks ou du trafic de recherche, et associez chacune à son équivalent le plus proche sur le nouveau site. Le guide de Google sur les déplacements de site demande des redirections permanentes côté serveur (301 ou 308), aucune chaîne de redirections, aucune redirection en masse vers l'accueil, et le maintien des redirections pendant au moins un an. Notre guide de migration de site internet et l'article sur le SEO pendant une refonte détaillent cette étape.

Sites multilingues

Sur un site en plusieurs langues, chaque page a besoin d'annotations hreflang qui listent toutes ses versions linguistiques, elle-même comprise, et chaque version doit renvoyer vers les autres. La documentation de Google sur les versions localisées indique que les annotations à sens unique sont ignorées. Ajoutez une entrée x-default pour le sélecteur de langue ou la page par défaut.

La vitesse se corrige plus facilement avant le lancement, quand les gabarits sont encore ouverts. Les Core Web Vitals de Google donnent des objectifs précis. Web.dev définit une bonne expérience, au 75e centile des chargements de pages sur mobile et sur ordinateur, par un Largest Contentful Paint de 2,5 secondes ou moins, un Interaction to Next Paint de 200 millisecondes ou moins et un Cumulative Layout Shift de 0,1 ou moins. L'INP a remplacé le First Input Delay comme Core Web Vital en 2024.

Avant le lancement, vous n'avez que des données de laboratoire. Lancez PageSpeed Insights et Lighthouse en profil mobile sur la page d'accueil et sur une page de chaque type de gabarit (page de service, article, contact, fiche produit). Corrigez d'abord ce qui pèse le plus : images d'en-tête non compressées, polices chargées depuis plusieurs sources, scripts de chat ou de suivi qui bloquent le thread principal. Notre guide pour créer un site web haute performance détaille ces corrections.

Les erreurs d'accessibilité sont fréquentes et la plupart se repèrent facilement. Le rapport WebAIM Million 2026 a relevé des échecs WCAG 2 détectables sur 95,9% du million de pages d'accueil étudiées : texte trop peu contrasté sur 83,9% d'entre elles, texte alternatif manquant sur 53,1% et libellés de formulaire absents sur 51%. Des outils automatiques comme axe ou WAVE signalent la plupart de ces erreurs en préproduction, en quelques minutes par gabarit.

Les tests automatiques en laissent passer beaucoup, ajoutez donc une passe manuelle. Parcourez chaque gabarit avec la touche Tab, vérifiez que le contour de focus reste visible et que le bandeau cookies, les menus et les fenêtres modales se ferment sans souris. Le niveau AA des WCAG 2.2 est l'objectif habituel. En France, l'European Accessibility Act a été transposé par la loi n° 2023-171 du 9 mars 2023 et le décret n° 2023-931 du 9 octobre 2023 : depuis le 28 juin 2025, plusieurs services numériques destinés aux consommateurs, dont le commerce électronique, doivent être accessibles, les microentreprises de services étant exemptées. Le RGAA reste le référentiel français pour auditer un site. Notre guide de l'accessibilité web et du RGAA liste les contrôles composant par composant.

La sécurité avant le lancement relève surtout de la configuration. Le certificat SSL doit couvrir chaque nom d'hôte servi, avec et sans www, et se renouveler automatiquement, et chaque requête HTTP doit rediriger vers HTTPS. Les en-têtes de sécurité se configurent en une heure et ferment des failles courantes : Strict-Transport-Security, une Content-Security-Policy (voir le guide CSP de MDN), X-Content-Type-Options et une Referrer-Policy. Vérifiez-les avec un scanner externe plutôt que de vous fier au panneau de l'hébergeur.

• Les comptes administrateurs ont des mots de passe uniques et la double authentification, et les comptes par défaut sont supprimés
• Le CMS, les extensions et les dépendances sont à jour
• Les sauvegardes automatiques tournent, sont stockées hors du serveur, et une restauration a été testée
• Les formulaires sont protégés contre le spam, par un champ honeypot, une limitation du nombre d'envois ou un CAPTCHA
• La surveillance de disponibilité alerte une personne nommée, pas une boîte partagée que personne ne lit

Mentions légales et pages juridiques

En France, un site édité par une entreprise doit afficher des mentions légales : dénomination sociale, siège, téléphone, numéro RCS le cas échéant, nom du directeur de la publication, et coordonnées de l'hébergeur. Cette obligation figure aujourd'hui à l'article 1-1 de la LCEN, qui a repris l'ancien article 6 III depuis la loi SREN du 21 mai 2024. Ajoutez une politique de confidentialité conforme au RGPD et une politique cookies, et liez ces pages depuis le pied de page de chaque page. La politique de confidentialité doit citer les outils réellement utilisés sur le site : rédigez-la une fois les choix d'analytics, de chat et de contenus intégrés arrêtés, pas avant.

Le jour du lancement doit être ennuyeux. Choisissez une matinée en semaine où le développeur et le responsable des contenus sont disponibles toute la journée, et évitez le vendredi après-midi. Gelez les modifications de contenu sur l'ancien site la veille, pour que rien n'y soit publié qui manquerait au nouveau. Suivez ensuite les étapes dans cet ordre et cochez chacune une fois terminée.

1. Un ou deux jours avant, baissez le TTL des enregistrements DNS que vous allez modifier (300 secondes est une valeur courante). Les résolveurs gardent un enregistrement pendant le TTL qu'ils ont reçu, cela ne sert donc que si c'est fait à l'avance.
2. Faites une dernière sauvegarde de l'ancien site et du nouveau.
3. Déployez, puis basculez le DNS ou la configuration d'hébergement.
4. Purgez toutes les couches de cache (CDN, serveur, CMS) pour que personne ne reçoive une version périmée ou de préproduction.
5. Contrôlez le robots.txt et l'état noindex sur le domaine en ligne.
6. Crawlez la liste des anciennes URL pour vérifier les redirections, et ouvrez à la main les 20 pages qui ont le plus de trafic.
7. Soumettez le sitemap XML dans la Search Console et lancez l'inspection d'URL sur l'accueil et les principales pages de service. Si le domaine lui-même a changé, utilisez l'outil de changement d'adresse, que Google réserve aux déplacements entre domaines ou sous-domaines.
8. Envoyez un vrai formulaire de test et vérifiez que l'e-mail et l'événement clé GA4 arrivent tous les deux.
9. Activez la surveillance de disponibilité, puis remontez le TTL une fois la nouvelle configuration stable.

Prévoyez un délai avant que la recherche suive. Google indique que l'exploration peut prendre de quelques jours à quelques semaines, et redemander la même URL n'accélère rien. Après un déplacement de site, les positions peuvent fluctuer quelque temps, le temps que Google traite les redirections.

Le premier mois sert à rattraper ce que la recette a manqué. Les vrais visiteurs arrivent avec des navigateurs, des appareils et des parcours que personne n'a testés, et les robots trouvent d'anciennes URL que personne n'a redirigées. Consultez la Search Console tous les deux ou trois jours pendant les deux premières semaines, puis chaque semaine. Un problème corrigé dans cette période coûte peu, alors que le même problème découvert au quatrième mois a déjà coûté du trafic et des contacts.

Search Console et erreurs 404

• Dans le rapport Indexation des pages, surveillez la hausse des lignes « Introuvable (404) », « Exclue par la balise noindex » et « Page avec redirection »
• Redirigez vers les bonnes nouvelles pages les URL en 404 qui ont des backlinks ou du trafic
• Vérifiez que le sitemap apparaît comme traité, sans erreur
• Comparez les impressions sur vos principales requêtes avec la référence de l'ancien site

Analytics et conversions

• Comparez les conversions de GA4 avec ce qui est réellement arrivé dans le CRM ou la boîte mail, et trouvez la cause de l'écart avant que quiconque utilise les chiffres
• Repérez les pages d'entrée avec un taux de sortie anormalement élevé sur mobile
• Contrôlez le taux de consentement. Un taux d'acceptation d'exactement 0% ou 100% signale une erreur de configuration

Données de performance terrain

Les scores de laboratoire d'avant le lancement sont une prévision. Les données terrain viennent des vrais utilisateurs de Chrome via le Chrome UX Report, qui agrège une fenêtre glissante de 28 jours. Le premier rapport Core Web Vitals significatif arrive donc environ un mois après le lancement, et un site à faible trafic peut ne jamais avoir assez de données au niveau des pages. Dans ce cas, les données au niveau de l'origine ou votre propre mesure des utilisateurs réels (RUM) comblent le manque.

Dès le deuxième mois, il y a assez de données pour passer de la correction à l'amélioration. La question n'est plus « est-ce que quelque chose est cassé ? » mais « où les visiteurs décrochent-ils, et pourquoi ? ». Servez-vous des rapports sur les parcours de conversion et les pages d'entrée pour choisir les deux ou trois pages qui comptent le plus pour les contacts, puis observez leur usage avec des heatmaps ou des enregistrements de sessions avant de toucher à quoi que ce soit.

Modifiez une chose à la fois et mesurez-la par rapport à la référence, car des changements faits en lot ne peuvent être attribués à rien. Si le trafic le permet, menez un vrai test A/B selon le cycle décrit dans le guide du Nielsen Norman Group sur les tests A/B : une hypothèse, une variable, un indicateur défini et assez de temps pour obtenir un résultat. Sur les sites B2B à faible trafic, une comparaison avant/après propre sur plusieurs semaines est souvent l'alternative honnête. Notre guide de l'optimisation des conversions va plus loin.

Améliorations typiques dans cette période :

• Des formulaires plus courts, sans les champs que l'équipe commerciale n'utilise jamais
• Des appels à l'action plus clairs dans le premier écran sur mobile
• Des sections de page réordonnées selon la profondeur de défilement
• Des liens internes depuis les articles de blog vers les pages de service qu'ils soutiennent
• Des pages trop minces enrichies ou fusionnées avec des pages plus solides

Là où l'IA aide

Les outils d'IA sont efficaces pour la moitié analytique de cette boucle : résumer des enregistrements de sessions, regrouper des requêtes de recherche, signaler des anomalies dans l'analytics et rédiger des variantes de test. La moitié décisionnelle demande toujours quelqu'un qui connaît l'entreprise, ses marges et ses clients. Utilisez l'IA pour raccourcir le chemin entre les données et une hypothèse, et gardez une personne responsable de ce qui est mis en ligne.

La plupart des lancements ratés échouent sur le processus plutôt que sur la technique. Presque chaque problème remonte à quelque chose qui était vrai en préproduction et ne l'est plus en production, ou à une tâche que chacun croyait faite par quelqu'un d'autre. Chacune des erreurs ci-dessous se prévient à peu de frais avec un responsable nommé et un test, et coûte cher quand on la découvre un mois plus tard par une baisse des contacts.

• Une balise noindex ou un blocage robots.txt de préproduction passé en production
• Aucun plan de redirection, ou des redirections qui pointent toutes vers l'accueil
• Un analytics installé mais des événements clés jamais testés, si bien que le premier mois de données de conversion manque
• Un bandeau cookies qui charge les traceurs avant l'accord du visiteur
• Des notifications de formulaire qui arrivent en spam pendant des semaines sans que personne le voie
• Un lancement tard le vendredi, sans personne disponible avant lundi
• Considérer le lancement comme la fin du projet, sans bilan prévu au 30e ou au 90e jour

Un audit SEO environ trois mois après le lancement rattrape ce qui a échappé à la checklist, et notre guide de la maintenance de site web couvre le travail courant qui suit.

Une checklist de lancement de site fonctionne quand elle est ordonnée, attribuée et terminée. La recette décide si le site est prêt. Le jour J est une courte suite de bascules qu'il vaut mieux répéter d'abord en préproduction. Les 90 jours qui suivent montrent si le site fait son travail avec de vrais visiteurs. Notez la référence, donnez un responsable à chaque ligne et inscrivez les bilans du 30e et du 90e jour au calendrier avant la mise en ligne.

Quand Vezert réalise un site corporate ou une landing page, une checklist comme celle-ci fait partie de la livraison. Après le lancement, nos offres de maintenance de site couvrent le suivi des performances, les mises à jour de sécurité et l'appui sur les contenus, et nos services SEO prennent en charge l'indexation, les redirections, les contenus et le maillage interne. Les prix actuels sont sur la page des tarifs.