# Checklist de lancement de site web : ce qui distingue la qualité du travail bâclé après la mise en ligne > URL: https://4eck-media.de/fr/blog/checklist-de-lancement-de-site-web-ce-qui-distingue-la-qualite-du-travail-bacle-apres-la-mise-en-ligne/ > Language: fr > Description: Il existe un mot qui déclenche une petite ovation dans chaque chat de projet : « live ». Le domaine pointe vers le nouveau serveur, le cadenas s'affiche dans le navigateur, la pag… --- Il existe un mot qui déclenche une petite ovation dans chaque chat de projet : « live ». Le domaine pointe vers le nouveau serveur, le cadenas s’affiche dans le navigateur, la page d’accueil se charge. Et c’est précisément à ce moment-là que survient, dans de nombreux projets, une erreur silencieuse : tout le monde célèbre et plus personne ne vérifie. Or c’est maintenant seulement que commence la phase décisive, celle qui détermine si le projet sera clôturé proprement ou si le client passera les semaines suivantes à travailler comme testeur non rémunéré. Je n’accorde que peu de crédit à la phrase « Mettons le site en ligne, nous verrons bien si quelque chose ressort encore. » Bien sûr que quelque chose ressortira. Après son lancement, un site web fonctionne dans des conditions différentes de celles de l’environnement de développement : domaine réel, SSL réel, mise en cache publique, serveurs de messagerie réels, gestion du consentement, moteurs de recherche, bots, visiteurs. Ces différences sont normales. Ce qui ne l’est pas, c’est de les laisser au hasard. ![Image de couverture de la checklist de lancement de site web avec presse-papiers, ballon de football et points de contrôle après la mise en ligne](https://4eck-media.de/wp-content/uploads/2026/07/website-launch-checkliste-nach-go-live-cover.avif "Checklist de lancement de site web : étapes importantes après la mise en ligne") C’est pourquoi nous tenons une deuxième liste. Tout ce qui [doit être contrôlé avant la publication](https://4eck-media.de/fr/blog/checklist-de-site-web-avant-le-go-live-ce-que-nous-verifions-avant-quun-site-puisse-etre-mis-en-ligne/), je l’ai décrit dans la première partie. Cet article commence là où la partie 1 s’arrête : sur le domaine réel, dans des conditions réelles. Et cette liste n’a rien d’un secret non plus : toute personne qui exploite elle-même un site WordPress peut la parcourir point par point. Aucun outil d’agence magique n’est nécessaire. Il faut du temps, des responsabilités clairement attribuées et la volonté de ne pas enjoliver les résultats désagréables. Nous ne lançons d’ailleurs jamais un vendredi à 16 h 55. Une mise en ligne a lieu lorsque les développeurs, la direction de projet et, en cas de besoin, l’hébergeur sont joignables. Ensuite, on ne fête pas : on vérifie. On pourra faire la fête plus tard, et bien plus détendu. Et pour celles et ceux qui ne se contentent pas d’un lancement mais planifient une refonte complète : le volet stratégique figure depuis 2023 dans notre grande [checklist de refonte sur TutKit](https://www.tutkit.com/de/blog/203-relaunch-checkliste-fuer-online-shops-buchungs-und-corporate-websites). Ces deux articles en sont le prolongement pratique. En ligne ne veut pas dire terminé - L’environnement de production modifie le domaine, le SSL, le cache, les e-mails, le tracking et les services externes. - Les réglages préparés sont à nouveau contrôlés sur l’URL réelle. - Les fonctions critiques ne sont pas seulement observées, elles sont exécutées intégralement. - Le lancement bénéficie d’un créneau horaire avec des responsables joignables. - Une case n’est cochée que lorsque le résultat est documenté et reproductible. ## Désactiver le site de développement : le site web doit être réellement public Le premier point paraît presque risible, jusqu’au jour où l’on constate à quelle fréquence il est oublié. Après le lancement, plus aucune page de maintenance, page « bientôt disponible » ou protection par mot de passe ne doit se trouver devant le site web. Et je ne vérifie surtout pas cela dans mon navigateur habituel : les cookies et ma session WordPress peuvent m’y faire voir le site réel, alors que chaque nouveau visiteur reste bloqué devant un verrou. Donc : fenêtre de navigation privée, deuxième appareil, si possible une autre connexion. Et pas seulement la page d’accueil, mais aussi des sous-pages, un article, un formulaire. L’ancien environnement de préproduction reste malgré tout en vie, mais proprement séparé : protégé, en noindex, hors du sitemap. Une copie du site librement accessible produit du contenu dupliqué, contient souvent des données de test et constitue une surface d’attaque inutile. Lors d’une refonte, je contrôle en plus quelle version le domaine délivre réellement à cet instant : le DNS et les caches ont besoin de temps, et certains visiteurs peuvent encore voir l’ancien site. On ne peut pas l’empêcher à la minute près, mais il faut le savoir avant de collecter les rapports d’erreur. ## Autoriser l’indexation : la case à cocher la plus dangereuse de WordPress WordPress propose, sous Réglages → Lecture, une option discrète : « Demander aux moteurs de recherche de ne pas indexer ce site ». En développement, cette case est utile. Après le lancement, une case oubliée à cet endroit est l’erreur isolée la plus coûteuse qu’un nouveau site web puisse comporter : il est alors en ligne, fonctionne parfaitement et n’existe tout simplement pas pour Google. Je ne me fie pas pour autant au libellé affiché dans le back-office. L’option n’est qu’un signal ; des extensions et des règles serveur peuvent générer leurs propres directives noindex. Je contrôle donc le code source des principaux types de pages, l’en-tête HTTP X-Robots-Tag, le fichier robots.txt et le sitemap XML. L’objectif n’est pas d’ouvrir tout en bloc, mais de prendre une décision claire par type de page : la page d’accueil, les pages de prestations et les articles doivent être indexables ; les pages de recherche interne, le panier ou les archives techniques restent délibérément à l’écart selon le projet. Après un changement de domaine, je recherche en outre les restes de l’adresse de développement : les balises canoniques, les images OG, les données structurées, les liens internes et les URL du sitemap ne doivent plus pointer vers dev. ou vers un sous-domaine d’agence. Une seule balise canonique erronée raconte à Google que le site fraîchement lancé n’est que la copie d’une adresse de test. Pour conclure ce point, j’utilise l’inspection d’URL dans la Google Search Console. Le test en direct répond à la question décisive : Google peut-il récupérer la page, celle-ci peut-elle être indexée et quelle URL canonique est reconnue ? Juste après le lancement, l’index affiche souvent encore l’ancien état. Ce n’est pas un problème, c’est de la physique. Le test en direct permet de distinguer un banal « pas encore recrawlé » d’une véritable erreur technique. Le sitemap est soumis et, dans les semaines qui suivent, je consulte régulièrement les rapports d’indexation et les statistiques de 404. Qui n’ouvre la Search Console que trois mois plus tard passe trois mois à côté d’un problème pourtant soluble. ## Finaliser Yoast : contrôler les modèles plutôt que les pages isolées Les réglages de base de Yoast sont déjà contrôlés avant le lancement. C’est l’objet de la partie 1. Sur le domaine réel, il s’agit maintenant du rendu : j’ouvre plusieurs contenus représentatifs et je vérifie que les titres sont construits de façon pertinente, que le domaine est correct partout et qu’aucun texte générique ne reste visible. Ce sont les modèles qui sont déterminants : un article isolé soigneusement optimisé ne prouve rien si les catégories, les pages de prestations ou tout un type de contenu personnalisé héritent de métadonnées erronées ou d’un noindex involontaire. Je contrôle au minimum la page d’accueil, un contenu ordinaire, une archive et chaque type de contenu important, et ce dans chaque langue sur les sites multilingues. Pour moi, la couleur du feu tricolore de Yoast est une indication, pas un jugement de qualité. Un texte peut être vert et sonner malgré tout de façon interchangeable. Le rendu technique compte davantage : le titre est-il univoque ? Une page centrale n’a-t-elle pas de description ? L’aperçu social affiche-t-il la bonne image ? ## Accessibilité sur le domaine réel : la bannière de cookies est la première impression Pourquoi contrôler à nouveau l’accessibilité si elle a déjà été vérifiée avant le lancement ? Parce que la mise en ligne fait apparaître de nouveaux éléments : bannières de cookies, boîtes de dialogue de tracking, captchas, chats, solutions de sécurité. Et c’est justement la fenêtre de consentement qui se superpose à l’ensemble du site web. Elle est donc fonctionnellement plus importante que presque n’importe quel bloc de contenu. Si la première boîte de dialogue du site n’est pas utilisable au clavier, si le focus disparaît derrière elle ou si le bouton « Refuser » est à peine lisible, la plus belle des sous-pages accessibles située derrière n’a plus aucune valeur. Je relance donc AccessibilityChecker et AccessScan sur le site de production et j’enregistre le résultat avec sa date. Un tel rapport n’est pas un certificat à vie : la prochaine mise à jour d’extension peut déjà changer la situation. Il documente un instant précis, et c’est exactement à cela qu’il sert. S’y ajoutent les manipulations manuelles de la partie 1, cette fois sur le site en ligne : naviguer sans souris, suivre le focus, provoquer des erreurs de formulaire, tester le zoom. Si vous avez besoin d’aide sur ce point, notre approche est présentée sous [Accessibilité des sites web](https://4eck-media.de/fr/competences/accessibilite-pour-vos-sites-web-agence-de-webdesign/). ![Audit WCAG 2.2 du site web de Bolzakademie avec 90 points sur 100 et zéro erreur critique](https://4eck-media.de/wp-content/uploads/2026/07/barrierefreiheit-wcag-audit-website-bolzakademie-rostock.avif) ## PageSpeed en production : seul le domaine réel dit la vérité Vous connaissez les valeurs cibles grâce à la [partie 1](https://4eck-media.de/fr/blog/checklist-de-site-web-avant-le-go-live-ce-que-nous-verifions-avant-quun-site-puisse-etre-mis-en-ligne/) : au minimum 90, l’objectif visé étant 94, 95 et plus. La marge est volontaire. Ce qui est nouveau après le lancement, c’est l’environnement. Sur le domaine réel se combinent le CDN, les règles de mise en cache, le gestionnaire de consentement et tous les scripts tiers qui manquaient souvent en préproduction ou y fonctionnaient en mode test. Une mesure réalisée avant l’activation du gestionnaire de consentement n’est tout simplement pas comparable à une mesure effectuée après. Je mesure avec [PageSpeed Insights](https://pagespeed.web.dev/) séparément sur mobile et sur ordinateur, et à plusieurs reprises : d’abord l’appel à froid, puis l’appel répété. Si les résultats varient fortement, la variation est elle-même le constat : un site web rapide ne l’est pas seulement dans le meilleur des cas. Et je ne mesure pas uniquement la page d’accueil : page de prestations, article de blog, page de synthèse, contact, et pour les boutiques la fiche produit et le tunnel de commande. Chaque modèle charge des images et des scripts différents ; une page d’accueil ultrarapide ne prouve rien au sujet d’un filtre produit de plusieurs mégaoctets de JavaScript. Les données de terrain d’utilisateurs réels manquent d’ailleurs encore juste après le lancement, ou se rapportent à l’ancien site. C’est également normal. Pour la première semaine, ce sont les données de laboratoire et les causes qui les expliquent qui comptent : LCP, INP, CLS. Les détails de notre approche figurent sur la page consacrée à l’[optimisation PageSpeed et aux Core Web Vitals](https://4eck-media.de/fr/competences/optimisation-pagespeed-rendre-les-sites-mesurablement-plus-rapides/). ![Rapport Google PageSpeed Insights du site web de Bolzakademie avec évaluation du temps de chargement](https://4eck-media.de/wp-content/uploads/2026/07/pagespeed-optimierung-ladezeit-website-bolzakademie-rostock.avif) Notre marge PageSpeed - 90 points constituent notre valeur minimale, 94 à 95 ou plus notre objectif de départ. - Le mobile et l’ordinateur sont mesurés séparément et sur plusieurs types de pages. - Le LCP, l’INP et le CLS sont plus importants qu’un score global isolé. - Plusieurs mesures montrent si le résultat est stable ou seulement bon par hasard. - La marge protège la zone verte des images et des scripts marketing ajoutés plus tard. ## En-têtes de sécurité : vérifier la protection sans courir après une note Les en-têtes de sécurité sont des règles que le serveur transmet au navigateur : imposer le HTTPS, empêcher l’intégration par des tiers, limiter les sources de scripts. Beaucoup d’entre eux ne peuvent être vérifiés utilement que sur le domaine public. Nous utilisons pour cela [SecurityHeaders.com](https://securityheaders.com/), et je le dis honnêtement : la note obtenue est une indication, pas une fin en soi. Une Content Security Policy extrêmement stricte qui bloque au passage le prestataire de paiement, la vidéo ou le gestionnaire de consentement n’est pas une mesure de sécurité réussie. C’est une nouvelle erreur, mieux notée. J’évalue au minimum Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy et la protection contre l’affichage en cadre. Et après chaque modification, le site web est testé fonctionnellement : formulaire, vidéos, cartes, consentement, polices, ainsi qu’un coup d’œil dans la console du navigateur à la recherche de ressources bloquées. Les en-têtes sont des règles actives, pas de la décoration. C’est précisément pour cela qu’il ne faut ni les ignorer, ni les copier sans réfléchir depuis un modèle. ![Rapport Security Headers du site web de Bolzakademie avec la meilleure note A+ et tous les en-têtes actifs](https://4eck-media.de/wp-content/uploads/2026/07/sicherheit-security-header-website-bolzakademie-bestnote.avif) ## Favicon et données structurées : deux contrôles en direct brefs mais bien réels J’ai décrit le favicon dans la partie 1 comme le point le plus fidèlement oublié. Sur le domaine en ligne s’ajoute une particularité : les navigateurs mettent les favicons en cache avec une ténacité étonnante. Le fait que mon navigateur affiche la nouvelle icône ne signifie pas qu’un nouveau visiteur la reçoive aussi, ou inversement. Donc : fenêtre de navigation privée, deuxième appareil, adresse favicon.ico directe, interface de navigateur claire et sombre. En ce qui concerne les données structurées, l’enjeu après le lancement porte surtout sur une chose : les restes. Après une refonte, les graphes Schema contiennent volontiers encore d’anciennes adresses d’images, des URL de préproduction ou des identifiants de l’environnement de test : le contenu visible se trouve sur le nouveau domaine, mais le balisage raconte une autre histoire. Je valide les URL publiques avec le [Schema.org Validator](https://validator.schema.org/) et, lorsque Google prend un type en charge, avec le [Rich Results Test](https://search.google.com/test/rich-results). Le principe de la partie 1 reste inchangé : valide ne veut pas encore dire vrai. Le nom, l’adresse, les numéros de téléphone et les images doivent correspondre à ce qui est visible sur la page. Le balisage après le lancement - Contrôler l’URL publique avec le Schema.org Validator et les outils de Google. - Évaluer séparément les erreurs, les avertissements et les indications contradictoires. - Rechercher les URL de préproduction, les anciens identifiants, les images erronées et les coordonnées obsolètes. - Ne baliser que des informations visibles, réelles et démontrables. - Relier les entités en un graphe compréhensible à l’aide d’identifiants stables. ## E-mails et formulaires : sur le domaine en ligne, tout change Les formulaires ont été testés avant le lancement et sont entièrement retestés après. Ce n’est pas de la pédanterie : avec le domaine changent l’adresse d’expéditeur, la cohérence SPF et DKIM, la configuration SMTP, les clés de captcha et parfois la boîte de réception compétente. C’est précisément pour cela qu’un formulaire peut fonctionner en préproduction et perdre des messages en production : silencieusement, derrière un aimable message de succès en vert. Je remplis chaque formulaire important comme un véritable utilisateur : d’abord en laissant les champs obligatoires vides, puis avec une adresse e-mail invalide, puis avec une demande valide. Celle-ci doit arriver dans la bonne boîte de réception, non pas quelque part sur le serveur de messagerie, mais chez la personne censée la traiter. Dans la boîte de réception, je contrôle le nom de l’expéditeur, l’objet, le champ Reply-To et tous les champs transmis ; une réponse doit pouvoir être adressée au visiteur sans qu’une adresse serveur figure dans le destinataire. Le dossier spam fait autant partie du test que les journaux d’envoi. Et sur les sites multilingues, chaque version linguistique est testée individuellement, y compris la confirmation automatique, sa langue et ses liens. Pour finir, la question inconfortable que presque personne ne pose : que se passe-t-il si le service de messagerie est brièvement indisponible ? La demande est-elle enregistrée, renvoyée ou silencieusement rejetée ? Pour les formulaires critiques pour l’activité, « cela devrait fonctionner » ne suffit pas. Le client doit savoir où il peut détecter une panne. ## Sauvegardes : les mettre en place, les vérifier et procéder une fois à une véritable restauration De nombreux hébergeurs font la promotion de sauvegardes automatiques. Très bien. Mais cela ne répond pas aux questions qui comptent en cas d’urgence : à quelle fréquence la sauvegarde a-t-elle lieu ? Combien de temps est-elle conservée ? Se trouve-t-elle sur la même infrastructure que celle qui vient de tomber en panne ? La base de données et les fichiers sont-ils inclus ? Qui a le droit de restaurer, et combien de temps cela prend-il ? Notre principe de base : l’hébergeur peut assurer le premier niveau, rapide ; en complément, une sauvegarde part au moins quotidiennement vers un stockage distinct, le compte cloud du client ou, sur accord, notre infrastructure. Une copie sur le même espace web ne protège pas contre un compte compromis. Et vient ensuite l’étape qui manque presque partout : je procède au moins à une restauration par sondage, dans un environnement sécurisé. Les archives peuvent être incomplètes, endommagées ou dépendre d’une version d’extension. Qui ne le découvre qu’en pleine panne ne dispose pas d’une stratégie de sauvegarde, mais d’une collection de fichiers. Une sauvegarde sans test de restauration n'est qu'un espoir - Convenir d’une sauvegarde d’hébergement complétée par une sauvegarde externe distincte. - Sauvegarder au moins une fois par jour ; adapter l’intervalle en cas de transactions. - Prendre en compte conjointement les fichiers et la base de données. - Documenter la conservation, le chiffrement, les responsabilités et la protection des données. - Tester une véritable restauration dans un environnement sécurisé. ## Seobility après le lancement : explorer intégralement le site public Avant le lancement, nous procédons par sondages ; après le lancement, je fais explorer intégralement le site public. Le crawler travaille avec le domaine réel, les protocoles réels et toutes les versions linguistiques, et il trouve les restes de lancement typiques : anciens liens de développement, titres en double, descriptions manquantes, ressources qui se chargent encore via HTTP. Je contrôle également si le HTTP redirige systématiquement vers le HTTPS et si les variantes avec et sans www se comportent de façon univoque. Il ne doit pas exister plusieurs versions du même site accessibles publiquement. Concernant la structure, je regarde moins les feux rouges que la question de savoir si le crawler trouve le même site qu’un être humain : les prestations centrales sont-elles plus proches de la page d’accueil que d’anciens communiqués de presse ? Existe-t-il des pages orphelines ? Les filtres ou les archives génèrent-ils des milliers d’URL inutiles ? Seobility n’est pas pour nous une machine à produire un joli pourcentage, mais une liste de tâches structurée : traiter les constats pertinents, relancer l’exploration, documenter les exceptions assumées. Une erreur ignorée sans justification n’est pas de la gestion de la qualité. Pour la vue d’ensemble complète, il y a l’[audit SEO avec contrôle technique et éditorial](https://4eck-media.de/fr/competences/audit-seo-pour-votre-site-analyse-plan-doptimisation/). ![Analyse Seobility du site web de Bolzakademie avec un score On-Page de 96 pour cent](https://4eck-media.de/wp-content/uploads/2026/07/seo-onpage-optimierung-analyse-website-bolzakademie.avif) ## Agent Ready : rendre le site web lisible pour les systèmes d’IA Après le contrôle SEO classique, nous vérifions désormais une seconde lisibilité : celle destinée aux systèmes d’IA. De nouveaux outils existent pour cela : extensions Agent Ready, llms.txt, analyses comme Ranketic. Ma position sur le sujet est mesurée : de tels outils rendent visibles les lacunes techniques et complètent les signaux. Ils ne transforment pas des slogans publicitaires interchangeables en informations spécialisées solides. Les systèmes d’IA ont besoin d’affirmations univoques : qui propose quoi, pour qui, dans quelle région, avec quelles preuves ? Ces réponses doivent figurer dans le contenu visible et correspondre au balisage. Concrètement, je contrôle les points suivants après le lancement : les crawlers d’IA pertinents ont-ils le droit de récupérer les contenus selon le fichier robots.txt ? Les prestations, l’organisation et les personnes sont-elles clairement nommées dans le HTML ? Le balisage Schema est-il cohérent et relié par des identifiants stables ? Et, point particulièrement important, une extension supplémentaire ne génère-t-elle pas de balises meta, de sitemaps ou de blocs Schema en double ? Sur un site WordPress, Yoast, le thème et des fonctions de données structurées sur mesure sont souvent déjà à l’œuvre ; un outil supplémentaire peut aider ou restituer une seconde fois la même information autrement. Plus de code ne signifie pas automatiquement plus de visibilité. Le volet stratégique de ce sujet figure dans notre [framework GEO pour la visibilité et les recommandations par l’IA](https://4eck-media.de/fr/blog/le-4eck-geo-framework-pour-la-visibilite-et-les-recommandations-ia/). ![Scan Cloudflare du site web de Bolzakademie avec le niveau 5 Agent-Native et un score de 86](https://4eck-media.de/wp-content/uploads/2026/07/ki-optimierung-agent-native-website-bolzakademie-cloudflare.avif) ## AI-Bot-Logger : mesurer qui vient réellement Si nous voulons savoir si les crawlers d’IA visitent le site web, il nous faut des données et non des impressions. Un AI-Bot-Logger enregistre les accès des user agents connus. Après le lancement, je vérifie trois choses : fonctionne-t-il vraiment ? Les données sont-elles plausibles ? Et ne ralentit-il pas le site ? À cela s’ajoute une réserve honnête : un user agent n’est pas une identité certifiée, il peut être falsifié. La statistique est un instrument d’observation, pas une liste de visiteurs. Et une mise en garde contre la nouvelle métrique de vanité : dix mille appels de bots ne constituent pas un succès commercial. Une seule recommandation qualifiée peut valoir davantage. L’objectif n’est pas d’attirer le plus de machines possible, mais d’alimenter les systèmes pertinents avec des informations claires, à jour et citables. La protection des données s’applique aussi aux journaux : la finalité, les accès et le délai de suppression doivent être clarifiés. Nous ne conservons pas tout indéfiniment simplement parce que c’est techniquement possible. ## Tracking et cookies : le consentement doit produire un effet technique Le tracking n’est mis en place que s’il est prévu et juridiquement clarifié. En Allemagne, les technologies qui ne sont pas techniquement nécessaires requièrent en règle générale un consentement valable ; cette distinction est également expliquée par la [Commissaire fédérale à la protection des données et à la liberté d’information](https://www.bfdi.bund.de/DE/Buerger/Inhalte/Telemedien/Cookies.html). Ce que cela signifie en pratique : afficher une bannière tout en chargeant immédiatement Analytics n’est pas un consentement, c’est de la décoration. Après le lancement, je teste donc trois états : aucune décision, refus, acceptation. Avant l’acceptation, les scripts, requêtes et enregistrements soumis à consentement ne doivent pas avoir lieu, et pas davantage après un refus ; je le contrôle dans les outils du navigateur, et non dans l’affichage de l’extension de consentement. S’y ajoute une observation que je fais étonnamment souvent : une bannière de cookies en allemand sur une page en anglais ou en polonais. Un consentement ne peut être éclairé que si l’utilisateur comprend ce sur quoi il se prononce. Les catégories, les boutons et les mentions doivent être dans la langue de la page, un lien vers les paramètres de cookies doit figurer sur chaque version linguistique, et le refus ne doit pas être artificiellement compliqué par la couleur ou par des clics supplémentaires. Et si le tracking fonctionne, il doit aussi être juste : les pages vues arrivent-elles dans le bon compte ? Les accès internes sont-ils filtrés ? Les événements liés aux formulaires et aux achats fonctionnent-ils ? Un identifiant Analytics techniquement intégré ne constitue pas encore un plan de mesure. Et ce qu’une bannière de cookies mal implémentée peut provoquer sur un site en ligne, ce court exemple tiré de la pratique le montre bien : une erreur SEO qui coûte des clics et de la visibilité : [Dieser SEO-Fehler kostet dich Klicks & Sichtbarkeit](https://www.youtube-nocookie.com/embed/Gj0skAo7-wI?feature=oembed) ## Exécuter les redirections en direct : maintenant, ce sont les codes de statut qui comptent, pas les plans La redirect map a été préparée dans la partie 1. Elle est maintenant exécutée et testée dans des conditions réelles. Je contrôle le code de statut et la cible : en règle générale directement en 301 vers l’URL HTTPS définitive, sans chaînes passant par HTTP, www et étapes intermédiaires. Les liens internes sont ensuite basculés vers les URL définitives, afin que le site ne navigue pas durablement au travers de redirections. Le schéma de la partie 1 montre à quoi ressemblent les chaînes et les boucles et pourquoi elles sont nuisibles. [Google recommande, lors de déménagements avec changement d’URL](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=de), de maintenir les redirections pendant au moins un an, et dans la plupart des projets il n’y a aucune raison de les supprimer rapidement ensuite. Les anciens liens continuent de vivre dans des documents, des e-mails et des annuaires. Important : une fois le lancement effectué, la map n’est pas « réglée ». Les appels 404 réels des premières semaines viennent la compléter : si un ancien chemin de valeur manque, la redirection est ajoutée puis testée à nouveau. Une refonte perd rarement de la visibilité à cause d’une seule grosse erreur. Le plus souvent, ce sont de nombreuses petites URL oubliées. ## Protection anti-spam : d’abord le honeypot, ensuite seulement l’artillerie lourde Dès qu’un formulaire est public, les bots le trouvent. Ce n’est pas une question de si, seulement de quand. Notre première couche de protection est un honeypot : un champ invisible pour les humains, que seuls les bots remplissent. Pour les utilisateurs réels, cela ne représente aucun travail supplémentaire. Après le lancement, je teste les deux faces : une demande normale doit passer, un schéma de bot simulé doit rester bloqué. Une protection trop agressive est une erreur au même titre qu’une absence de protection : si les demandes des clients disparaissent, le site web a manqué son objectif, même si le dossier spam reste exemplairement vide. Je ne déploie reCAPTCHA et les services similaires que lorsque le honeypot, le contrôle temporel et les règles côté serveur ne suffisent plus. Les captchas externes coûtent en clarté sur la protection des données, en accessibilité et en temps de chargement, et leurs clés sont liées à des domaines. Là encore, il s’agit d’un test en direct, pas d’un test en préproduction. Durant les premiers jours, nous observons le volume de spam réel et ajustons le niveau de protection en conséquence. La sécurité n’est pas un interrupteur, mais un rapport entre protection et facilité d’utilisation. ## Les premières 24 heures : observer, prioriser, ne pas s’affoler La checklist immédiate est traitée au bout de quelques heures. Commence ensuite l’observation : journaux d’erreurs, appels 404, distribution des formulaires, mise en cache, disponibilité. Pour les boutiques s’y ajoutent les commandes, les paiements, les e-mails transactionnels ; pour les portails, l’inscription et la réinitialisation du mot de passe. Et parce que des constats vont immanquablement s’accumuler à ce stade, ils ont besoin de priorités, sans quoi la liste produit de l’activité au lieu de la qualité. ![Vue d'ensemble des priorités d'erreurs après le lancement : P0 critique immédiatement, P1 élevé sous 24 heures, P2 normal documenté et planifié](https://4eck-media.de/wp-content/uploads/2026/07/launch-priorities-p0-p1-p2.avif) Chaque constat a besoin d’une preuve exploitable : URL, appareil ou navigateur, étapes de reproduction, comportement attendu et comportement réel. « Le formulaire ne marche pas » n’est pas une tâche. « Le formulaire de contact sur iPhone/Safari affiche une boucle sans fin après un envoi valide ; le message n’est pas distribué » en est une. Après la correction, la vérification n’est pas assurée uniquement par la personne qui l’a mise en œuvre, et je teste aussi immédiatement les fonctions adjacentes : une modification du gestionnaire de consentement peut réparer le tracking et bloquer au passage une vidéo. Les systèmes techniques sont faits de relations. Au bout d’une semaine s’ajoutent les données réelles : Search Console, journaux serveur, Analytics utilisé de façon licite, demandes au support. Je n’attends pas une courbe parfaite : les positions fluctuent pendant une migration, les crawlers ont besoin de temps, les utilisateurs apprennent une nouvelle navigation. Ce sont les tendances qui importent : les erreurs 404 augmentent-elles fortement ? Les envois de formulaires s’effondrent-ils ? Le LCP mobile se dégrade-t-il ? De telles évolutions appellent une cause, pas une excuse. ## Le protocole de lancement : qui, quand, avec quelle preuve Au bout de quelques semaines, quelqu’un demandera immanquablement : le formulaire a-t-il vraiment été testé après le lancement ? Quelles valeurs PageSpeed avions-nous ? Les redirections étaient-elles complètes ? Sans protocole, chacun répond de mémoire, et les souvenirs sont remarquablement souples dans le quotidien d’un projet. Notre protocole de lancement est volontairement simple : point de contrôle, personne responsable, date et heure, URL vérifiée, résultat, preuve. Une preuve, c’est une capture d’écran avec son contexte, un rapport d’outil, un e-mail de test reçu. Elle doit correspondre à l’affirmation. Une image de formulaire en vert ne prouve aucune distribution ; le message reçu, si. L’heure n’est d’ailleurs pas de la pédanterie : un test PageSpeed effectué avant l’activation du gestionnaire de consentement documente un autre site web que celui d’après. Nous documentons également les écarts assumés : peut-être une page n’atteint-elle que 92 points au lieu de 95 en raison d’un service de réservation indispensable ; dans ce cas, le protocole mentionne la décision professionnelle, et non un simple « ignoré ». Le protocole protège d’ailleurs moins l’agence que l’exploitation : si un problème surgit six mois plus tard, nous voyons l’état de l’époque et ne cherchons pas dans le brouillard. Et le client reçoit une remise de projet avec laquelle un prestataire ultérieur pourra travailler. Un bon travail doit pouvoir être transmis. La remise comprend enfin des accès bien ordonnés : chaque personne uniquement avec les droits dont elle a besoin, les comptes de test supprimés et une introduction compréhensible aux gestes du quotidien : gérer les contenus, préparer les images, rédiger les textes alternatifs, retrouver les entrées de formulaire. La meilleure base technique est abîmée lorsqu’un rédacteur téléverse des images de 12 mégaoctets parce que personne ne lui a expliqué la différence. Le client valide les aspects métier et donne son accord sur les contenus. Il n’a pas pour mission de trouver nos chaînes de redirections. Le client doit pouvoir utiliser le site web, pas terminer de tester le travail de l’agence. Mon exigence après le lancement - Le domaine en ligne est traité comme un nouvel environnement technique et contrôlé intégralement. - Aucun message de succès ne remplace la distribution, l’indexabilité ou le fonctionnement réel. - Les scores aident à chercher, mais ne décident pas à eux seuls de la qualité. - Les constats critiques reçoivent un responsable, un délai et un contre-test indépendant. - Le client reprend un site web documenté et non un chantier ouvert. ## La checklist complète de l’après-mise en ligne en un coup d’œil Comme dans la partie 1, le principe reste le même : cette vue d’ensemble est la version condensée de notre liste interne, la copier est bienvenu, et chaque point a besoin d’un nom. Une boutique y ajoute les tests de paiement et de commande, un portail les rôles et les droits, un site international le changement de langue et les formulaires localisés. | Point de contrôle | Ce qui est concrètement contrôlé | Conséquence en cas d’oubli | | --- | --- | --- | | Site de développement | Mode maintenance, protection par mot de passe et disponibilité publique | Les visiteurs voient un verrou ou une version erronée | | Indexation | Réglage de lecture WordPress, noindex, robots.txt, canonical, sitemap | Les moteurs de recherche ne peuvent pas intégrer correctement les pages centrales | | Yoast | Titres, descriptions, canonicals, aperçu social, types de pages | Signaux de recherche erronés ou dupliqués | | Accessibilité | Scanners, clavier, focus, formulaires et couche de consentement | Des utilisateurs sont exclus ; risques juridiques et qualitatifs | | PageSpeed | Mobile, ordinateur, modèles, LCP, INP, CLS | Utilisation lente et aucune marge pour les contenus ultérieurs | | En-têtes de sécurité | HSTS, CSP, règles Referrer, Permissions et Frame | Surface d’attaque évitable ou fonctions bloquées par des règles erronées | | Favicon | Navigateur, fichier direct, interface claire et sombre | Image de marque inachevée | | Données structurées | Schema.org, Rich Results, contenu visible, identifiants stables | Signaux machine contradictoires ou non exploitables | | Formulaires et e-mail | Validation, envoi, distribution, Reply-To, langues | Des demandes se perdent sans que personne s’en aperçoive | | Sauvegardes | Intervalle, stockage externe, conservation et restauration | Une panne se transforme en perte de données | | Seobility | Technique & méta, structure et contenu | Les restes de lancement et les problèmes d’exploration restent invisibles | | Agent Ready | Crawlers d’IA, contenus, Schema, llms.txt et conflits d’extensions | Le site web est plus difficile à situer pour les systèmes d’IA | | AI-Bot-Logger | Fonctionnement, plausibilité, protection des données et conservation | Aucune donnée fiable sur les accès des bots | | Tracking et cookies | Acceptation, refus, blocage des scripts et langue | Données erronées et risques pour la protection des données | | Redirect map | Cibles 301, chaînes, boucles et appels 404 réels | Visiteurs et signaux de recherche perdus | | Protection anti-spam | Honeypot, demandes légitimes, captcha si nécessaire | Déluge de spam ou clients bloqués | ## Conclusion : après la mise en ligne, on voit si le site web est terminé ou seulement en ligne Le véritable lancement dure plus longtemps que le changement de DNS. Désactiver le site de développement, autoriser l’indexation, vérifier l’accessibilité et le PageSpeed sur le domaine réel, les en-têtes de sécurité, le balisage, les e-mails, les sauvegardes avec test de restauration, l’exploration, la lisibilité pour l’IA, le consentement, les redirections, la protection anti-spam, le protocole : seul cet ensemble transforme un site web publié en un projet abouti. La différence entre la qualité et le travail bâclé n’est d’ailleurs pas l’absence d’erreurs. Les sites web sont complexes, les appareils variés, les services externes changeants. La différence, c’est la responsabilité : chercher systématiquement les erreurs probables, prouver le bon fonctionnement des fonctions critiques, se tenir prêt à de nouveaux constats. Une mauvaise remise ressemble à ceci : « Le site est en ligne, faites-nous signe s’il y a quelque chose. » Une bonne remise contient des résultats de contrôle, des points ouverts, des responsabilités et un interlocuteur joignable. Si vous prévoyez un site WordPress, souhaitez le refondre ou le faire auditer en toute indépendance, vous en apprendrez davantage sur notre travail sous [Design UI/UX et développement web](https://4eck-media.de/fr/competences/agence-ui-ux-developpement-web-4eck-media/), ou vous pouvez [échanger directement avec nous](https://4eck-media.de/fr/contact/), volontiers aussi avec votre propre checklist. Des questions concrètes sont presque toujours bon signe. Et si le site fraîchement lancé doit devenir multilingue : notre article complet sur le workflow montre comment nous [traduisons WPML avec l’IA](https://4eck-media.de/fr/blog/traduire-wordpress-avec-lia-rapide-economique-et-sans-les-tracas-de-wpml-notre-workflow-complet/), y compris les contrôles avec lesquels nous vérifions chaque langue. ## Questions fréquentes sur la checklist de lancement de site web Que faut-il vérifier immédiatement après le lancement d'un site web ? Immédiatement après le lancement, la disponibilité publique, l’indexation, les canonicals, le sitemap, Yoast, les formulaires et la distribution des e-mails, le PageSpeed, l’accessibilité, les en-têtes de sécurité, les données structurées, les sauvegardes, les redirections, le tracking et la protection anti-spam figurent sur la liste. Pour les boutiques et les portails s’y ajoutent les fonctions spécifiques critiques pour l’activité. Pourquoi le contrôle effectué avant la mise en ligne ne suffit-il pas ? L’environnement de production modifie le domaine, le SSL, la mise en cache, les e-mails, les scripts externes, la gestion du consentement et la disponibilité publique. De nombreux réglages préparés ne peuvent être entièrement confirmés que sur le domaine réel. Dans quel délai le contrôle après la mise en ligne doit-il avoir lieu ? Les contrôles techniques de base et ceux qui sont critiques pour l’activité ont lieu immédiatement après le changement de domaine. Les journaux, l’indexation, l’évolution des 404, les Core Web Vitals réels et les données d’utilisation sont ensuite suivis pendant des jours et des semaines. Quelle valeur PageSpeed est bonne après le lancement ? Chez 4eck Media, 90 constitue la valeur minimale. Nous démarrons si possible avec 94 à 95 points ou plus, afin que des images, des vidéos ou des scripts marketing ajoutés plus tard ne fassent pas immédiatement sortir de la zone verte. Le LCP, l’INP, le CLS et plusieurs types de pages sont en outre évalués. Chaque site WordPress a-t-il besoin d'une sauvegarde externe ? Nous recommandons, en plus de la sauvegarde de l’hébergeur, une copie distincte chez le client ou dans un cloud convenu. L’intervalle adapté, la durée de conservation, la protection des données et une restauration testée sont déterminants. Une sauvegarde sur le même espace web ne protège pas contre toutes les pannes. Que signifie Agent Ready pour un site web ? Un site web compatible avec les agents est techniquement accessible aux crawlers d’IA et décrit sans ambiguïté l’organisation, les personnes, les prestations et l’expertise dans le HTML visible et dans le balisage structuré. Les extensions et llms.txt peuvent apporter un soutien, mais ne remplacent pas des contenus concrets et dignes de confiance. Une bannière de cookies suffit-elle pour un tracking conforme à la protection des données ? Non. Les scripts soumis à consentement doivent rester techniquement bloqués avant l’acceptation et après un refus. La bannière doit être compréhensible, accessible, révocable et, sur les sites multilingues, disponible dans la bonne langue. Combien de temps les redirections doivent-elles être maintenues après une refonte ? Google recommande de conserver les redirections aussi longtemps que possible lors d’un déménagement de site web, et en général au moins un an. Une durée plus longue est souvent judicieuse, car d’anciens liens issus de documents, d’annuaires et de favoris continuent d’être utilisés.