# Checklist de site web avant le go-live : ce que nous vérifions avant qu’un site puisse être mis en ligne > URL: 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/ > Language: fr > Description: Il y a un moment que connaît toute personne qui construit des sites web. Le projet est « terminé ». Les couleurs sont bonnes, les images sont en place, le client a salué le design… --- Il y a un moment que connaît toute personne qui construit des sites web. Le projet est « terminé ». Les couleurs sont bonnes, les images sont en place, le client a salué le design en réunion, et dans le chat de projet apparaît la question : « Pouvons-nous mettre en ligne cette semaine ? » Tout en moi veut dire oui. C’est exactement à cet endroit que commence la partie de notre travail dont presque personne ne parle. Car entre « cela a l’air terminé » et « c’est terminé », il y a une liste. La nôtre s’est étoffée au fil des années, et presque chaque point qui y figure a son histoire : une image hero qui coupait la tête du directeur sur l’iPad. Un formulaire de contact qui affichait un message de succès vert et qui ne délivrait pourtant pas un seul e-mail. Un titre qui débordait de l’écran à cause d’un seul mot allemand très long. Rien de tout cela n’était visible dans la maquette. Tout cela était visible en ligne. ![](https://4eck-media.de/wp-content/uploads/2026/07/website-checkliste-vor-go-live-qualitaet-statt-pfusch-cover.avif) Pour le client, à un tel moment, le site n’est pas terminé à 95 %. Il est cassé. Il ne fait pas la différence entre design, frontend, hébergement et gestion des contenus. Il voit un site web, et chaque erreur porte le logo de son entreprise. C’est pourquoi nous publions ici notre checklist interne complète pour la période précédant le go-live. Ce n’est pas un savoir secret, et c’est précisément le point : la différence entre un site professionnel et un projet du dimanche tient rarement au talent. Elle tient à la discipline. Chez nous, dans l’agence, il n’y a pas de « ça ira » ni de « ça a l’air bien ». Un point est traité ou il ne l’est pas. Entre les deux, il n’y a rien. Cet article traite de tout ce qui est vérifié avant la publication. Pour la période qui suit, il existe une deuxième liste et un [article dédié aux vérifications après le go-live](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/), car un site en ligne est encore loin d’être terminé. Les deux parties prolongent et approfondissent ce que Matthias a commencé en 2023 dans notre grande [checklist de refonte pour boutiques en ligne, sites de réservation et sites corporate](https://www.tutkit.com/de/blog/203-relaunch-checkliste-fuer-online-shops-buchungs-und-corporate-websites). Terminé n'est pas la même chose que vérifié - La validation du design signifie : la direction est la bonne. Elle ne signifie pas que chaque appareil a été testé. - Un test de go-live évalue ensemble la fonction, l’affichage, la technique et la trouvabilité. - Avant le lancement, on prépare ; après le lancement, on confirme dans des conditions de production réelles. - Chaque point de contrôle a besoin d’une personne responsable et d’un résultat traçable. - Si c’est le client qui trouve l’erreur en premier, l’assurance qualité n’était pas terminée. ## Un design, quatre vérités : desktop, ordinateur portable, tablette, smartphone Les sites web sont construits sur de grands écrans calmes et utilisés sur de petits appareils agités. C’est le problème de fond de presque chaque validation de design. La maquette a été présentée et validée sur 27 pouces. Le visiteur, lui, arrive avec un smartphone vieux de trois ans, le tient d’une seule main et dispose d’une demi-minute de patience. C’est pourquoi nous contrôlons chaque projet sur quatre catégories d’appareils, et pas seulement la page d’accueil. Pages de prestations, articles de blog, formulaires, pages de listing, et pour les boutiques la fiche produit et le tunnel de commande : chaque template a ses propres points de rupture. Ne contrôler que la page d’accueil n’est pas un contrôle de site web. C’est un contrôle de page d’accueil. ![Webdesign responsive de la Bolzakademie sur tablette et smartphone avec une page d'accueil identique](https://4eck-media.de/wp-content/uploads/2026/07/responsive-webdesign-bolzakademie-tablet-smartphone-startseite.avif) ### Desktop et ordinateur portable : le premier écran décide Sur les grands écrans, je surveille les lignes de texte trop longues, les contenus perdus dans d’immenses surfaces blanches et les conteneurs qui s’étirent sans largeur maximale. Une mise en page équilibrée sur 1 440 pixels peut se déliter sur un écran de 27 pouces. L’ordinateur portable n’est pas pour autant un desktop miniature. Sur 13 à 15 pouces, c’est la hauteur qui pose vraiment problème : la barre du navigateur et le système d’exploitation prennent de la place, et un hero élégant sur un grand moniteur occupe la totalité de la zone visible sur un portable. Je vérifie donc le premier écran comme le ferait un visiteur : comprend-on immédiatement de quoi il s’agit ? Le bouton le plus important est-il accessible, ou est-il masqué par la bannière de cookies et le sticky header ? Voit-on seulement que la page continue plus bas ? ### Tablette : l’entre-deux inconfortable Dans beaucoup de projets, les tablettes sont testées en dernier. Le desktop est important, le mobile est important, et entre les deux, ça passera bien. C’est précisément là que naissent les erreurs les plus laides : une tablette est assez large pour activer les règles du desktop, mais trop étroite pour en accueillir proprement les contenus. Deux colonnes se retrouvent comprimées, la navigation ne tient plus tout à fait sur une ligne, les images perdent leur point focal. Notre liste retient pour cela l’iPad mini et l’iPad Pro, non par amour de la marque, mais parce que nous avons besoin de deux classes de tailles nettement différentes et de conditions de test reproductibles. Et je fais délibérément pivoter l’appareil : un iPad Pro en paysage est presque un ordinateur portable. Le même iPad en portrait impose des contraintes totalement différentes au hero, aux tableaux et aux rangées de cartes. ### Smartphone : pas plus étroit, mais différent Sur le téléphone, un site web s’utilise avec le pouce, sous la pression du temps, souvent en déplacement. Empiler simplement une mise en page desktop ne suffit pas. Les contenus doivent être hiérarchisés, les boutons ont besoin de véritables zones tactiles, les formulaires doivent ouvrir le bon clavier, les numéros de téléphone doivent pouvoir être touchés du doigt. Nous prenons comme référence l’iPhone 12 et l’iPhone 14 Pro, plus des viewports simulés dans le navigateur. Les appareils réels restent malgré tout obligatoires, car aucune simulation ne reproduit entièrement les barres de navigateur, le comportement tactile et les performances réelles. Un seul élément à largeur fixe rend toute la page déplaçable horizontalement. Une pop-up dont la croix de fermeture se trouve hors de l’écran bloque complètement le visiteur. Et la question du test n’est jamais seulement « tout est-il visible ? », mais : l’essentiel arrive-t-il assez tôt ? Atteint-on le lien sans toucher celui d’à côté ? Le message d’erreur apparaît-il au niveau du champ concerné ou quelque part en dehors de la zone visible ? Beaucoup de problèmes de qualité ne sont pas assez spectaculaires pour un rapport de bug. Ils créent simplement des frictions, et dans Analytics on ne voit ensuite qu’un taux de conversion plus faible. ## Images hero : la demi-heure que personne ne voit dans le devis J’adore nos designers. Vraiment. Mais une image occupant toute la largeur de l’écran est presque toujours un compromis technique et régulièrement un petit combat. Dans la maquette, le hero s’inscrit parfaitement dans sa surface fixe. Dans le navigateur, cette surface n’existe pas : un visiteur tient une tablette en portrait, le suivant est assis devant un écran ultra-large, et tous deux doivent voir le même visage, le même produit, la même ligne au bon endroit. Techniquement, nous résolvons cela avec plusieurs tailles d’image : notre thème travaille avec six paliers de mise en page, une base mobile et les largeurs à partir de 576, 768, 992, 1 200 et 1 710 pixels. Via srcset et sizes, le navigateur choisit la variante AVIF adaptée au lieu de charger partout l’original le plus grand. Le poids du fichier est ainsi réglé. La composition de l’image, non : avec object-fit, la surface est remplie, mais quelque chose est toujours coupé. Avec object-position, je détermine quelle zone survit. Cela ne fonctionne que si je regarde vraiment le motif dans plusieurs rapports d’aspect. S’y ajoute une conversation que j’ai régulièrement : « Nous vous avons pourtant envoyé du matériel haute résolution. » Il s’agit en réalité de Full HD. 1 920 sur 1 080 pixels, cela paraît grand, mais c’est tout simplement insuffisant pour une image pleine surface sur un grand écran Retina, et s’il faut encore choisir un cadrage, il reste encore moins de pixels réels pour la surface visible. Le résultat est un hero net sur l’ordinateur portable et flou sur le grand moniteur. Bien sûr, l’IA peut agrandir. Cela sauve certains motifs, mais invente des détails : les cheveux, les mains, le texte et les façades sont des zones à problèmes typiques. Si le matériel ne fournit pas la résolution nécessaire, je ne promets pas de magie : nous changeons alors le cadrage, la surface ou le type de hero. Ce n’est pas une défaite du design. C’est une décision honnête. Pour un seul hero difficile, on arrive vite à 30 minutes au total : vérifier le fichier, générer les variantes, définir le point focal, faire pivoter la tablette, tester l’ultra-large, corriger le contraste, réexporter. Cette demi-heure, personne ne la voit ensuite. Quand elle manque, tout le monde le voit. Notre règle pour les hero - Un hero pleine largeur a besoin d’un motif disposant d’une réserve suffisante, jusqu’à la 4K en cas de doute. - L’original n’est pas chargé partout : le thème, srcset et l’AVIF délivrent les variantes adaptées. - Le cadrage et la position de l’objet sont vérifiés sur mobile, tablette, ordinateur portable, desktop et ultra-large. - L’upscaling par IA est contrôlé pour détecter les artefacts et n’est pas confondu avec une véritable résolution de détail. - La pleine largeur est privilégiée sur la page d’accueil ; les pages secondaires reçoivent un second type de hero plus robuste. ## Test des navigateurs : Chrome seul ne vaut pas validation Chaque développeur a un navigateur préféré, et c’est le plus souvent celui dans lequel il développe. C’est normal. Cela devient problématique quand ce même navigateur constitue en même temps l’unique contrôle qualité. Chrome, Firefox, Safari et Edge parlent aujourd’hui largement les mêmes standards, mais pas dans le moindre détail : les polices sont rendues différemment, les champs de formulaire n’ont pas la même apparence, les éléments sticky réagissent différemment dans les cas limites, et Safari cultive ses particularités historiques. Notre checklist mentionne donc explicitement les quatre navigateurs, et nous contrôlons les composants présentant le plus grand risque d’erreur : navigation, menus déroulants, sliders, vidéo, bannière de cookies, formulaires, accordéons, onglets, fenêtres modales, éléments sticky, animations. Nous testons Safari sur un véritable appareil Apple : une simulation Chromium ne remplace pas le moteur WebKit. Trouvailles typiques : une police qui ne se charge pas et décale toutes les césures ; une vidéo qui reste figée à cause des règles de lecture automatique ; un état de focus qui disparaît. Nous n’essayons pas pour autant de servir chaque version de navigateur des dix dernières années ; ce qui est pertinent est défini avant le début du projet. Mais ne tout simplement pas ouvrir les navigateurs actuellement répandus n’est pas une décision technique. C’est de l’espoir. ## Titres longs et ­ : l’erreur qui apparaîtra à coup sûr chez le client Les mots composés allemands sont brutaux pour les écrans étroits. « Suchmaschinenoptimierungsstrategie » ou « Barrierefreiheitsstärkungsgesetz » font exploser des mises en page entières. La césure automatique en CSS aide, mais dépend du navigateur, de la langue et du dictionnaire. Elle n’est pas partout aussi fiable. C’est pourquoi nous plaçons à la main des points de césure conditionnels dans les titres critiques : le caractère invisible ­. Tant qu’il y a de la place, on ne voit rien. Si le navigateur doit couper, il le fait au bon endroit et affiche un trait d’union. ![Affichage défectueux de mots longs sur un smartphone sans césures conditionnelles définies](https://4eck-media.de/wp-content/uploads/2026/07/exec-c87f6807-ca83-4308-bb28-8c5279f93b3f.avif) Pourquoi cet effort ? Parce que cette erreur a une propriété particulière : elle n’apparaît jamais sur mon appareil de test. Elle attend le seul client avec la seule largeur d’écran et la police système agrandie, et arrive ensuite la capture d’écran accompagnée de l’aimable question de savoir où nous avions bien pu regarder. Avec des titres allemands longs, « ça finira bien par passer à la ligne » n’est pas une procédure de test. ![Graphique avant-après : un mot long sort de l'écran du smartphone sans césure conditionnelle, avec shy il passe proprement à la ligne](https://4eck-media.de/wp-content/uploads/2026/07/soft-hyphen-long-headlines-mobile.avif) ## Mentions légales, protection des données, déclaration d’accessibilité et favicon Un site web peut être graphiquement excellent et démarrer malgré tout en vol à l’aveugle sur le plan juridique. Avant le go-live, les mentions légales et la politique de confidentialité doivent être créées, liées et accessibles depuis chaque page, et les liens ne doivent surtout pas être masqués par la bannière de cookies. Il faut y ajouter la page de déclaration d’accessibilité, que nous créons pour chaque projet : elle documente le niveau atteint par le site et a sa place dans le pied de page, au même titre que les mentions légales et la politique de confidentialité. L’honnêteté sur les responsabilités est ici essentielle : nous construisons la base technique, intégrons les textes fournis et vérifions les liens. Nous ne remplaçons pas la validation juridique des textes légaux. Et le texte relatif à la protection des données doit correspondre au site réel : analytics, vidéos externes, cartes, newsletter, captcha, ce qui est effectivement intégré doit aussi être décrit. Un texte portant sur un site standard théorique n’aide pas si le site en production présente d’autres flux de données. Et puis il y a le favicon, le plus petit point de la liste et le plus fidèlement oublié. S’il manque, l’onglet affiche une icône générique ou celle de l’environnement de développement : rien n’est cassé pour autant, mais cela fait quand même inachevé. Je vérifie l’onglet, les favoris et l’affichage mobile. Et le motif doit survivre à la réduction : un lettrage fin n’est plus qu’une tache en 16 sur 16 pixels. ## Accessibilité : la validation du design ne suffit pas L’accessibilité commence dans le design (contrastes, tailles de police, états de focus, structure logique) et ne s’y arrête pas. Pendant le développement et la gestion des contenus, de nouveaux problèmes apparaissent : un rédacteur téléverse une image sans texte alternatif, un titre saute des niveaux, un formulaire reçoit un libellé ambigu. C’est pourquoi nous effectuons avant le go-live un nouveau contrôle automatisé (notre liste mentionne AccessibilityChecker et AccessScan) et complétons les scanners par des vérifications manuelles par sondage. Car un scanner peut mesurer si un texte alternatif existe. Il ne sait pas s’il décrit l’image de manière pertinente. Je navigue donc moi-même sans souris dans la navigation, les formulaires et les boîtes de dialogue, je suis le focus visible, je vérifie la hiérarchie des titres et je provoque des erreurs de formulaire : le message apparaît-il au niveau du champ, et le comprend-on ? La page reste-t-elle utilisable en cas de zoom et de police agrandie ? Depuis la loi allemande sur le renforcement de l’accessibilité (Barrierefreiheitsstärkungsgesetz) du 28 juin 2025, c’est aussi une question juridique pour de nombreuses offres. Les obligations concrètes dépendent de l’entreprise et doivent, en cas de doute, être clarifiées sur le plan juridique. Ma position pratique en est indépendante : l’accessibilité fait aujourd’hui partie du développement web professionnel au même titre que le HTTPS. Ce n’est d’ailleurs pas un facteur de classement Google général, mais beaucoup de ce qu’elle exige (structure propre, utilisabilité mobile, contenus compréhensibles) profite aussi aux moteurs de recherche et à la conversion. Si vous souhaitez aborder le sujet sérieusement, vous trouverez notre approche sous [sites web accessibles](https://4eck-media.de/fr/competences/accessibilite-pour-vos-sites-web-agence-de-webdesign/). ![Audit WCAG 2.2 du site de la 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) ## Données OG : la première impression naît souvent dans WhatsApp Avant qu’un visiteur ne voie le site web, il n’en voit souvent que l’aperçu : sous forme de lien partagé dans WhatsApp, LinkedIn, Slack ou Teams. Cet aperçu est construit par les données Open Graph : og:title, og:description et surtout og:image. Si elles ne sont pas renseignées, la messagerie tire une image quelconque de la page, coupe le titre ou n’affiche tout simplement rien. La première impression du nouveau site est alors un cadre gris. ![Graphique comparatif : aperçu de lien dans une messagerie sans données OG sous forme de cadre gris, avec données OG sous forme de carte avec image, titre et description](https://4eck-media.de/wp-content/uploads/2026/07/og-data-link-preview-messenger.avif) Avant le go-live, je vérifie donc pour chaque template : une image d’aperçu est-elle définie, a-t-elle la bonne taille (1 200 sur 630 pixels en standard), montre-t-elle ce qu’il faut, et le titre et la description sont-ils corrects ? Particulièrement important après une refonte : les URL OG ne doivent plus pointer vers le domaine de développement. Le test est simple : jeter le lien dans une messagerie ou un outil d’aperçu et regarder ce qui apparaît réellement. Cela prend quelques minutes et détermine l’allure de chaque recommandation partagée du site. ![Contrôle OpenGraph du site de la Bolzakademie avec une image OG correctement intégrée](https://4eck-media.de/wp-content/uploads/2026/07/og-image-seo-monitor-mockup-16x9-1-e1784893939736.avif) ## Données structurées : le mode d’emploi destiné aux machines Avec les données structurées, nous décrivons le site web de telle sorte que les machines ne voient pas seulement des mots, mais des relations : « 4eck Media » n’est alors plus une suite de caractères, mais une organisation avec une adresse, des prestations, des personnes et des avis. L’approche minimale répandue (installer un plugin SEO, déposer un logo, terminé) produit une ossature de base. Nous allons nettement plus loin et modélisons le site réel : organisation, fondateurs, collaborateurs, catalogues de prestations, articles avec auteur et date, fils d’Ariane, FAQ. Non pas avec des données inventées, mais avec des données vérifiables. C’est précisément dans le contexte de la recherche par IA que cela paie : des systèmes comme ChatGPT, Gemini ou Perplexity doivent pouvoir attribuer sans ambiguïté entreprises, personnes et prestations. Les données structurées ne garantissent aucune recommandation. Elles réduisent l’ambiguïté. Avant le go-live, je valide avec le validateur Schema.org et, là où Google prend en charge un type, avec le test des résultats enrichis. Vient ensuite le contrôle qu’aucun validateur ne prend en charge : la confrontation avec la réalité. Si le pied de page indique un numéro de téléphone différent de celui du balisage, le code est techniquement valide et factuellement faux. Le balisage n’est en outre pas un code décoratif posé une fois pour toutes : si l’adresse, l’équipe ou les prestations changent, le niveau lisible par les machines doit suivre, sinon il finit par produire des informations obsolètes particulièrement précises. Balisage : notre exigence minimale - Modéliser non seulement WebSite et Organization, mais toutes les entités réelles pertinentes. - Relier entre eux entreprises, personnes, prestations, articles, navigation, fils d’Ariane et FAQ. - Ne baliser que des informations visibles, correctes et vérifiables. - Vérifier le JSON-LD avec le Schema.org Validator et, le cas échéant, avec le Rich Results Test de Google. - Entretenir le balisage lors des modifications au même titre que les contenus visibles. ## PageSpeed : 90 est le seuil minimal, pas l’objectif PageSpeed est le point sur lequel je négocie difficilement. Chez nous, un nouveau site démarre dans le vert : au moins 90 points dans Google PageSpeed Insights, l’objectif visé étant 94, 95 et plus. Non pas parce qu’un monde sépare 93 de 95, mais parce que nous avons besoin de réserve. Après la livraison, le site continue de vivre : le client téléverse un jour une photo de 12 mégaoctets, intègre une vidéo, ajoute un script marketing. Qui démarre à exactement 90 passe au jaune dès la première modification imprudente. Qui démarre à 95 encaisse le quotidien. Je mesure le mobile et le desktop séparément, et le mobile est le test le plus honnête : processeur plus faible, réseau moins bon, images plus grandes. Derrière le score, je regarde les Core Web Vitals : le LCP (quand le plus grand élément est-il visible ? Le plus souvent, c’est justement l’image hero évoquée plus haut), l’INP (à quelle vitesse la page réagit-elle ?) et le CLS (la mise en page saute-t-elle au chargement ?). Un score de 100 avec un affichage cassé ne vaut rien, mais la phrase inverse, « PageSpeed n’est qu’un outil », ne vaut pas non plus chez moi : l’outil montre des risques réels. Les grands classiques sont presque toujours les mêmes : images trop lourdes, JavaScript bloquant, polices chargées tardivement, scripts tiers. La façon dont nous abordons cela de manière systématique figure sur notre page consacrée à l’[optimisation PageSpeed](https://4eck-media.de/fr/competences/optimisation-pagespeed-rendre-les-sites-mesurablement-plus-rapides/). ![Rapport Google PageSpeed Insights du site de la Bolzakademie avec évaluation du temps de chargement](https://4eck-media.de/wp-content/uploads/2026/07/pagespeed-optimierung-ladezeit-website-bolzakademie-rostock.avif) ## Yoast et Seobility : les outils trouvent ce que l’œil ne voit pas Avant le go-live, nous contrôlons les réglages de base de Yoast et faisons en plus crawler l’intégralité du site web. Nous utilisons Seobility pour cela. Le crawler répond à une question à laquelle aucun humain ne peut répondre à l’œil nu : y a-t-il quelque part une page qui sort du rang ? Un exemple tiré d’un de nos derniers projets : la rubrique « Technique et méta » était à 98 %. Cela sonne comme terminé. Les deux pour cent manquants correspondaient à deux méta-descriptions problématiques, une anomalie de titre et trois attributs alt absents : exactement la poignée d’erreurs concrètes pour lesquelles ce contrôle existe. Un score global élevé n’est pas une raison d’ignorer le reste de la liste. C’est la raison pour laquelle cette liste est courte. Dans Yoast, je vérifie en outre les modèles : un seul article bien renseigné ne prouve rien si un type de contenu personnalisé entier est par mégarde en noindex ou génère automatiquement des titres inutilisables. Et dans le crawl, je fais attention à la structure : des pages importantes enterrées à cinq clics de profondeur ; des textes de lien comme « en savoir plus » qui n’indiquent à personne où ils mènent ; des pages orphelines. Un outil mesure des chemins. C’est un humain qui décide si ces chemins ont du sens. Pour aller plus loin : le grand tour d’horizon, c’est l’[audit SEO](https://4eck-media.de/fr/competences/audit-seo-pour-votre-site-analyse-plan-doptimisation/) ; avant le go-live, il s’agit des erreurs évidentes qu’il est encore peu coûteux de corriger maintenant. ![Analyse Seobility du site de la Bolzakademie avec un score on-page de 96 %](https://4eck-media.de/wp-content/uploads/2026/07/seo-onpage-optimierung-analyse-website-bolzakademie.avif) ## Formulaires et e-mails : envoyer n’est pas encore délivrer Le formulaire de contact est l’endroit où un test apparemment réussi est le plus dangereux. Le développeur le remplit, voit le message de succès vert, coche la case. Une seule chose est ainsi prouvée : le frontend a accepté la demande. Savoir si un e-mail est bien arrivé dans la bonne boîte de réception, si la confirmation est partie vers l’expéditeur, si les données ont été enregistrées : tout cela reste ouvert. Nous avons connu le cas dans la pratique : formulaire vert, boîte de réception vide. Le client ne s’en aperçoit que lorsqu’il s’étonne que plus personne ne le contacte depuis deux semaines. Je teste donc le parcours complet : les champs obligatoires doivent fonctionner, les saisies non valides être interceptées de façon compréhensible, le message doit arriver dans la boîte de réception prévue (et non dans les spams), et le nom de l’expéditeur, l’objet, le Reply-To et tous les champs doivent être mis en forme de manière cohérente. Pour une délivrabilité fiable, nous mettons en place une voie SMTP ou un service de mails transactionnels ; SPF, DKIM et DMARC se situent en partie en dehors de WordPress, mais déterminent aussi si le message est jugé digne de confiance. Les formulaires critiques pour l’activité, je les teste avec plusieurs adresses et sur le téléphone. Et la protection anti-spam est préparée, mais elle ne doit pas bloquer de vraies personnes. Le réglage fin suit après le lancement. ## Plan de redirections : planifier avant la refonte, ne pas improviser après Pour un nouveau domaine sans prédécesseur, ce point est mineur. Lors d’une refonte, le plan de redirections est l’un des documents les plus importants du projet : chaque ancienne URL pertinente reçoit une nouvelle destination cohérente, non pas la page d’accueil par défaut, mais le remplacement le plus proche sur le fond. Je collecte les anciennes URL dans le sitemap, les statistiques, la Search Console et le crawl, nous attribuons les destinations et marquons ce qui disparaît volontairement. Les chaînes et les boucles sont dangereuses : si A pointe vers B et B ensuite vers C, cela crée des détours inutiles ; mieux vaut faire pointer A directement vers C. Une boucle rend la destination totalement inaccessible. Le plan est préparé avant le go-live ; il est testé définitivement sur le domaine de production. Nous prenons ainsi les décisions au calme et non au moment où l’ancien site est déjà coupé. ![Schéma : chaîne de redirection de A vers B puis vers C, redirection directe de A vers C et boucle de redirection entre A et B](https://4eck-media.de/wp-content/uploads/2026/07/redirect-chains-loops-diagram.avif) ## Mises à jour, nettoyage, chemin de connexion et photos de preuve Avant le go-live, nous amenons WordPress, le thème et les extensions à un état cohérent et à jour, mais pas cinq minutes avant la fin de la journée et jamais sans point de restauration. Les mises à jour modifient du code ; elles comblent des failles et peuvent tout aussi bien introduire de nouveaux conflits. Donc : sauvegarde, mise à jour dans l’environnement de développement, répétition des tests critiques. Le nettoyage est tout aussi important : les extensions de test, les imports de démonstration et les thèmes inutilisés dégagent. Le meilleur nombre d’extensions n’est pas zéro, mais le plus petit nombre qui remplit de manière fiable les tâches convenues. Notre liste prévoit en outre de faire passer le chemin de connexion de /wp-login à un chemin propre au projet. Cela tient à distance le bruit de fond automatisé et n’est expressément pas un concept de sécurité. Une connexion cachée avec le mot de passe « admin123 » n’est pas sûre. Des mots de passe forts, l’authentification à deux facteurs, la limitation des tentatives de connexion et des droits minimaux restent la véritable protection ; les comptes de test sont supprimés avant le lancement. Et lors de chaque refonte, nous prenons des captures d’écran de l’ancien site : page d’accueil, pages importantes, navigation, formulaires. Cela sonne nostalgique et constitue une protection très concrète : après la bascule, l’ancien état a disparu, et sinon commence la discussion de mémoire : ce texte était-il déjà ainsi avant ? Cette mention existait-elle ? Une comparaison avant-après répond à ce genre de questions en quelques secondes. ## Traductions : chaque langue est un site web à part entière Sur un site web multilingue, il ne suffit pas de contrôler la version allemande et de faire confiance à l’extension de traduction. Les textes n’ont pas la même longueur : un bouton allemand concis devient large en français, un titre anglais tient sur une ligne, le polonais en demande trois. Les menus, les formulaires, les champs SEO et les textes alternatifs peuvent présenter des lacunes propres à chaque langue. Je traite donc chaque langue comme un site web à part entière : navigation, sélecteur de langue, pages centrales, formulaires, métadonnées, hreflang. Un seul bouton en allemand dans un parcours de demande en anglais suffit pour que le visiteur comprenne : ici, le travail n’a pas été mené à son terme. Et la leçon la plus importante tirée de notre propre pratique : le statut « complet » dans l’outil de traduction n’est pas une preuve ; nous avons vu des champs marqués comme traduits et pourtant vides. La façon dont nous traduisons aujourd’hui de grands sites web avec XLIFF et l’IA tout en nous contrôlant nous-mêmes est décrite dans le [guide complet de la traduction WordPress avec l’IA](https://4eck-media.de/fr/blog/traduire-wordpress-avec-lia-rapide-economique-et-sans-les-tracas-de-wpml-notre-workflow-complet/). ## Comment nous contrôlons : des noms, des priorités, des preuves La meilleure des checklists ne sert à rien si elle repose à côté du projet sous forme de tableau anonyme. Chez nous, chaque point a un nom : qui contrôle les formulaires, qui les traductions, qui les appareils. Et un point connaît quatre états : contrôlé, erreur trouvée, corrigée, contrôlée à nouveau. Un bug n’est pas réglé parce que quelqu’un écrit qu’il l’a corrigé ; la correction peut casser quelque chose de nouveau ailleurs. Seul le test de contrôle clôt le point. Les erreurs sont priorisées, sinon quelqu’un passe trois heures à peaufiner un écart de deux pixels pendant que le formulaire n’envoie aucun mail : est critique ce qui bloque un parcours utilisateur central. Est grave ce qui touche une catégorie d’appareils importante ou des obligations légales. Le reste est documenté et planifié. Et chaque constat a besoin d’une preuve exploitable : « le mobile est cassé » n’est pas une information. « En 390 sur 844 pixels dans Safari, le bouton des cookies recouvre le bouton d’envoi » se laisse reproduire et corriger. Encore deux règles qui nous ont souvent sauvés. Premièrement : celui qui a construit une fonctionnalité ne la valide pas seul ; le constructeur sait où il faut cliquer, et c’est précisément pour cela qu’il passe à côté des obstacles. Pour les parcours centraux, le principe des quatre yeux s’applique. Deuxièmement : la validation du client ne remplace pas notre contrôle. Le client valide le design et les contenus ; il n’est pas notre assurance qualité non rémunérée. S’il passe son temps de relecture sur des bugs de navigateur que nous aurions dû trouver nous-mêmes, nous avons gaspillé son attention. Matthias montre dans cette vidéo à quoi ressemble un tel contrôle dans la pratique : un site web construit par IA, démonté de façon professionnelle : 10 erreurs en 20 minutes. [KI-Website besser als 95 % der Webdesigner? 10 Fehler in 20 Minuten aufgedeckt.](https://www.youtube-nocookie.com/embed/j6MsRVOb2do?feature=oembed) Mon exigence avant le go-live - Aucun appareil n’est coché avec la phrase « ça ira bien ». - Aucun score d’outil ne remplace le contrôle visuel et fonctionnel. - PageSpeed démarre au vert et avec de la réserve pour la maintenance ultérieure. - Le balisage, l’accessibilité et le SEO font partie du développement, ce ne sont pas des décorations ajoutées ensuite. - Le site web ne passe en ligne que lorsque je peux aussi expliquer le résultat sur l’appareil du client. ## La checklist complète avant mise en ligne en un coup d’œil Ce tableau est la version condensée de notre liste de travail interne. Dans le projet, elle est complétée par des fonctionnalités spécifiques : un site d’entreprise n’a pas besoin de test du tunnel de commande, une boutique en a besoin de bien davantage. La copie est expressément souhaitée. Et attribuez un nom à chaque point. Une case cochée sans responsable n’est qu’une cellule vide. | Point de contrôle | Ce qui doit être concrètement confirmé | Conséquence typique en l’absence de contrôle | | --- | --- | --- | | Design desktop | Espacements, conteneurs, largeurs de texte, rythme de page et tous les templates | La page d’accueil fait bonne impression, les pages secondaires semblent inachevées | | Design sur ordinateur portable | Première zone visible, hauteur du hero, sticky header et boutons | Un contenu important se trouve entièrement sous la ligne de flottaison | | Tablette petite et grande | Format portrait et paysage, colonnes, navigation, tableaux, sliders | Mises en page intermédiaires comprimées et motifs coupés | | Mobile | Zones tactiles, ordre des contenus, pop-ups, formulaires et défilement horizontal | Les visiteurs ne peuvent pas utiliser des fonctions centrales | | Images hero | Résolution, variantes responsives, cadrage, point focal et contraste | Images floues, artefacts ou motifs principaux disparus | | Mentions légales et protection des données | Contenus fournis, liens présents partout, services techniques pris en compte | Risques juridiques et risques pour la confiance | | Accessibilité | Scanner, plus tests au clavier, du focus, de la structure et du zoom | Exclusion d’utilisateurs, coûts de correction et risques juridiques possibles | | Favicon | Onglet du navigateur, affichage mobile et réduction adaptée | Le site paraît visiblement inachevé | | Données structurées | Entités réelles modélisées de façon complète, valide et sans contradiction | Les moteurs de recherche et l’IA reçoivent des signaux flous ou erronés | | PageSpeed mobile | Au moins 90, objectif 94-95+, causes et Core Web Vitals contrôlées | Utilisation lente et aucune marge pour les contenus ultérieurs | | PageSpeed desktop | Test dédié, ressources, décalages de mise en page et scripts contrôlés | Les problèmes sont masqués par la machine de développement rapide | | Yoast | Indexation, canonical, templates, title et description | Des types de contenu entiers sont mal indexés | | Seobility | Technique, structure et contenu crawlés ; anomalies évaluées | Les erreurs en série et les pages oubliées passent inaperçues | | Formulaires et e-mails | Validation, délivrabilité, Reply-To, confirmation et mobile | Les demandes disparaissent malgré un message de succès vert | | Plan de redirections | Anciennes URL collectées et associées chacune à une destination pertinente | Erreurs 404, pertes de positionnement et utilisateurs existants frustrés | | WordPress et extensions | Mis à jour de façon contrôlée, testés et composants inutiles supprimés | Failles de sécurité et conflits juste après le lancement | | Navigateurs | Chrome, Firefox, Safari et Edge avec les fonctions critiques | L’erreur touche précisément les utilisateurs en dehors du navigateur de développement | | Connexion et utilisateurs | Chemin, 2FA, mots de passe, droits et comptes de test | Surface d’attaque inutile et droits d’accès trop étendus | | Captures d’écran de l’ancien site | Pages et fonctions importantes documentées avant la bascule | Les questions avant-après ne peuvent plus trouver de réponse | | Traductions | Chaque langue contrôlée visuellement, fonctionnellement et dans les champs SEO | Mélange de langues, césures cassées et parcours utilisateurs incomplets | | ­ dans les titres | Doter les mots allemands longs de points de césure pertinents | Un smartphone quelconque trouvera à coup sûr la coupure embarrassante | ## Ce qui distingue la qualité du bricolage technique Le bricolage technique est rarement spectaculaire. Le plus souvent, c’est un hero qui coupe la tête sur l’iPad. Une demande qui n’a jamais été délivrée. Un H1 qui déborde de l’écran à cause d’un mot long. Chaque erreur prise isolément peut être minimisée. Ensemble, elles déterminent si un visiteur fait confiance au site web. Pour moi, la qualité ne signifie pas l’absence d’erreurs pour l’éternité. La qualité signifie : contrôler systématiquement les risques connus, documenter les décisions et passer en ligne avec un état que l’on peut défendre en toute bonne conscience. On peut effectuer ce travail soi-même. C’est précisément pour cela que la liste figure ici dans son intégralité. Il faut de la patience, de vrais appareils et la volonté de reconsidérer d’un œil critique une page prétendument terminée. Si vous préférez confier cela à d’autres, vous pouvez [faire développer un site web professionnel](https://4eck-media.de/fr/competences/agence-ui-ux-developpement-web-4eck-media/) ou nous solliciter pour un contrôle technique via la [page de contact de 4eck Media](https://4eck-media.de/fr/contact/). Et une fois le site web en ligne ? C’est alors que commence la seconde moitié du travail : libérer l’indexation, en-têtes de sécurité, sauvegardes avec test de restauration, tracking et consentement, redirections en conditions réelles. Tout cela figure dans la deuxième partie : la [checklist de lancement pour la période après le go-live](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/). D’ailleurs : dans les projets multilingues, la traduction fait aussi partie du contrôle qualité. La façon dont 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/) (rapidement, à moindre coût et de manière vérifiablement complète) est décrite dans notre article complet sur le workflow. ## Questions fréquentes sur la checklist de site web avant le go-live Que faut-il contrôler avant le go-live d'un site web ? Au minimum l’affichage sur desktop, ordinateur portable, tablette et mobile, les principaux navigateurs, les formulaires et la délivrabilité des e-mails, le PageSpeed, l’accessibilité, les bases SEO, les données structurées, les pages légales, les extensions, les redirections et (pour les sites web multilingues) chaque version linguistique. Les fonctionnalités spécifiques au projet s’y ajoutent. Combien de temps dure un contrôle professionnel de site web avant le lancement ? Cela dépend de l’ampleur et des fonctionnalités. Un petit site web peut être contrôlé en quelques heures ; une boutique, un portail ou une refonte multilingue demande nettement plus de temps. À elle seule, une image hero pleine largeur difficile peut occasionner environ une demi-heure de travail supplémentaire entre le cadrage, les variantes responsives et les tests sur appareils. Suffit-il de tester le site web dans Chrome ? Non. Chrome, Firefox, Safari et Edge continuent de se différencier sur le rendu, les formulaires et certaines fonctions CSS ou JavaScript. Les composants critiques doivent être exécutés dans les navigateurs cibles convenus. Safari devrait être contrôlé sur un véritable appareil Apple. Quelle valeur PageSpeed est bonne avant le go-live ? Notre valeur minimale est 90, notre objectif se situe entre 94 et 95 ou plus. Cet écart supplémentaire crée une réserve lorsque des images plus grandes, des vidéos ou des scripts marketing s’ajoutent par la suite. Au-delà du score, ce sont les causes et les Core Web Vitals LCP, INP et CLS qui sont déterminantes. L'accessibilité est-elle un facteur de classement Google direct ? Google ne qualifie pas l’accessibilité, de manière générale, de facteur de classement direct isolé. Les Core Web Vitals sont toutefois utilisées dans les systèmes de classement, et de nombreuses caractéristiques d’un site web accessible (utilisabilité mobile, structure claire, sémantique et contenus compréhensibles) améliorent en même temps l’utilisabilité et la capacité de traitement technique. Pourquoi les données structurées sont-elles si importantes avant le lancement ? Les données structurées décrivent les entreprises, les personnes, les prestations, les articles et leurs relations de manière lisible par les machines. Cela réduit l’ambiguïté pour les moteurs de recherche et les systèmes d’IA. Le balisage ne garantit aucun classement, mais il devrait être complet, correct, valide et cohérent avec les informations visibles du site web. Que faut-il prendre en compte en plus dans une checklist de refonte de site web ? Lors d’une refonte s’ajoutent notamment l’export des anciennes URL, un plan de redirections, la mise en correspondance d’Analytics et de la Search Console, les captures d’écran de l’ancien site ainsi que le contrôle des canonical, du sitemap, de l’indexation et des positionnements existants. Le contrôle visuel et fonctionnel avant mise en ligne reste malgré tout intégralement en vigueur.