Les problèmes du jour du lancement sont rarement exotiques. C’est un site de préproduction mis en ligne avec les moteurs de recherche bloqués, un formulaire de contact qui se soumet avec succès sans avertir personne, et une carte de redirections qui couvrait les pages dont quelqu’un se souvenait.
Voici treize vérifications, dans l’ordre où nous les faisons. Les deux premières expliquent l’essentiel des dégâts que l’on nous a appelés à réparer.
1. Faites correspondre chaque ancienne URL à une nouvelle
S’il s’agit d’une relance plutôt que d’un premier lancement, c’est la vérification qui protège tout ce que vous avez déjà gagné. Explorez le site en ligne, exportez chaque URL, et associez chacune à exactement une adresse du nouveau site. Les documents comptent. Les PDF se positionnent et attirent des liens externes pour eux-mêmes.
Utilisez des redirections permanentes, un seul saut chacune, jamais de chaîne. Puis appelez chaque ancienne URL et confirmez qu’elle aboutit à une page vivante plutôt qu’à une erreur 404 ou à une autre redirection. Un tableur qui affirme que la carte est complète n’équivaut pas à un test qui le prouve.
2. Retirez le noindex de préproduction, et lisez le robots.txt
L’erreur de lancement la plus coûteuse sous WordPress consiste à mettre en ligne avec l’option « Demander aux moteurs de recherche de ne pas indexer ce site » toujours cochée dans Réglages, Lecture. Des sites sont restés invisibles pendant des mois ainsi, et le symptôme ressemble exactement à celui d’un site qui n’est simplement pas encore positionné.
Vérifiez le réglage, puis appelez /robots.txt et lisez-le. Confirmez qu’il n’interdit rien que vous vouliez indexer, et qu’il pointe vers votre plan de site. Vérifiez ensuite quelques gabarits à la recherche d’une balise noindex oubliée par une extension ou une option de thème.
3. Relisez tout, à voix haute, dans chaque langue publiée
Lisez à voix haute, parce que l’œil saute ce que l’oreille attrape. Faites relire par quelqu’un qui n’a pas écrit le texte. Vérifiez les endroits que personne ne relit : étiquettes de formulaires, messages d’erreur, écrans de confirmation, libellés de boutons, page 404, gabarits de courriel et titres de pages.
Si vous publiez dans deux langues, vérifiez que chaque page française est bel et bien française. Les gabarits partiellement traduits, avec des messages de validation en anglais, sont extrêmement courants et immédiatement visibles pour les gens que vous cherchez à servir.
4. Testez chaque formulaire de bout en bout, courriel compris
Soumettre un formulaire et voir un message de remerciement prouve que l’interface fonctionne. Cela ne prouve rien sur la livraison. Soumettez chaque formulaire pour de vrai et confirmez que la notification arrive, à la bonne adresse, avec les valeurs des champs intactes et une adresse de réponse à laquelle vous pouvez réellement répondre.
Vérifiez le dossier de pourriel, parce qu’un nouveau site qui envoie du courrier depuis un nouveau serveur y atterrit fréquemment. Si vous avez des enregistrements SPF, DKIM et DMARC, validez-les maintenant plutôt que de découvrir le problème par les demandes que vous n’avez jamais reçues. Testez aussi les chemins d’échec : soumettez avec des champs obligatoires vides et confirmez que les erreurs sont claires et annoncées aux technologies d’assistance.
5. Faites un passage d’accessibilité
L’outillage automatisé détecte environ le tiers des problèmes : lancez-le, puis faites la partie manuelle. Parcourez chaque gabarit au clavier seul et confirmez que vous atteignez et actionnez tout, que le focus reste toujours visible, et que rien ne vous piège. Vérifiez le contraste des couleurs contre l’exigence de 4,5:1 pour le texte courant. Confirmez que les images porteuses de sens ont un texte alternatif et que les images décoratives ont un attribut alt vide.
Si vous avez une obligation envers une norme précise, qu’il s’agisse des WCAG 2.2 niveau AA, du SGQRI 008 3.0 au Québec ou de la LAPHO en Ontario, consignez le résultat par critère plutôt qu’en réussite ou échec global.
6. Un seul H1, un titre et une description uniques par page
Chaque page a besoin d’exactement un H1, et les titres doivent descendre dans l’ordre sans sauter de niveau, parce que cette structure est la façon dont naviguent les utilisateurs de lecteurs d’écran autant que la façon dont les moteurs lisent la page.
Chaque page a aussi besoin de sa propre balise titre et de sa propre méta description. Les doublons à l’échelle d’un site constituent le problème le plus fréquent que nous trouvons, et ils viennent généralement d’une valeur par défaut de gabarit que personne n’a remplacée. Les mots-clés méta sont morts depuis des années : ignorez toute extension qui propose encore le champ.
7. Vérifiez les Core Web Vitals sur les gabarits qui comptent
Testez la page d’accueil, une page de contenu, une page de liste et tout formulaire ou tunnel de paiement, sur un téléphone de milieu de gamme plutôt que sur votre portable. Largest Contentful Paint sous 2,5 secondes, Interaction to Next Paint sous 200 millisecondes, Cumulative Layout Shift sous 0,1.
Le décalage de mise en page est celui qu’on manque le plus souvent avant le lancement, et il vient habituellement d’images sans attributs de largeur et de hauteur, de polices web qui se substituent tardivement, ou d’une bannière injectée au-dessus du contenu après le rendu.
8. Optimisez les images et donnez-leur un vrai texte alternatif
Servez des formats modernes, dimensionnez les images à la taille réelle d’affichage, et activez le chargement différé sous la ligne de flottaison tout en l’excluant explicitement pour votre plus grande image visible d’emblée. Vérifiez sur une connexion lente, pas sur le réseau du bureau.
Le texte alternatif décrit la fonction de l’image dans son contexte, pas son contenu. Si une image est purement décorative, un attribut alt vide est la bonne réponse, et vaut mieux qu’un nom de fichier.
9. Vérifiez sur de vrais navigateurs et de vrais appareils
Les versions courantes de Chrome, Safari, Firefox et Edge, plus Safari sur un véritable iPhone et Chrome sur un véritable appareil Android. Le rendu n’a pas à être identique au pixel près. Tout doit fonctionner.
Testez en mode sombre si les appareils de vos visiteurs peuvent y être, et testez à 200 pour cent de zoom du navigateur, ce qui est à la fois une exigence d’accessibilité et un moyen rapide de trouver les mises en page qui cassent.
10. Installez et validez les statistiques et la Search Console
Mettez les statistiques en place avant le lancement pour disposer d’une base de référence dès le premier jour. Confirmez que le suivi se déclenche sur chaque gabarit et non uniquement sur la page d’accueil, et qu’une bannière de consentement ne le bloque pas silencieusement.
Validez la propriété dans la Google Search Console en même temps. Si vous avez changé de domaine, ajoutez les deux propriétés et utilisez l’outil de changement d’adresse. Définissez ce qu’est une conversion et confirmez que vous pouvez en voir une avant d’avoir à en rendre compte.
11. Soumettez le plan de site XML
Appelez le plan de site et lisez-le. Confirmez qu’il liste les pages que vous voulez indexer et qu’il ne liste pas de brouillons, d’URL de préproduction, de pages de pièces jointes ni de doublons paginés. Soumettez-le ensuite dans la Search Console et revenez quelques jours plus tard vérifier les erreurs de couverture, là où une mauvaise configuration se révèle en premier.
12. Construisez une page 404 qui récupère la visite
Quelqu’un arrivera sur une URL qui n’existe plus, si bonne que soit votre carte de redirections. Une page 404 qui propose la recherche, vos grandes sections et un chemin vers le contact transforme un cul-de-sac en visite récupérée. Confirmez qu’elle renvoie un véritable code 404 plutôt qu’un 200, parce qu’un faux 404 embrouille les moteurs et vous cache le problème dans vos rapports.
13. Sauvegardez, puis prouvez que la sauvegarde se restaure
Une sauvegarde non testée est une croyance, pas une protection. Prenez une sauvegarde complète des fichiers et de la base de données, conservée ailleurs que sur le serveur d’origine, puis restaurez-la réellement quelque part et confirmez que le site se relève.
Pendant que vous sécurisez : confirmez que le HTTPS est imposé sur tout le site sans avertissement de contenu mixte, supprimez le compte administrateur par défaut et les comptes de test, activez l’authentification à deux facteurs pour les administrateurs, et notez qui détient le domaine, le DNS et les accès d’hébergement.
Les petites choses, rapidement
- Favicon en place, aux tailles attendues par les navigateurs modernes et les signets mobiles.
- Le logo mène à la page d’accueil.
- Les balises Open Graph, vérifiées en collant une URL dans la plateforme où elle sera partagée.
- Un seul nom d’hôte canonique, avec www et sans www qui aboutissent à l’un des deux.
- Des styles d’impression, si quelqu’un imprime vos pages. Les visiteurs du secteur public le font.
- Politique de confidentialité, avis de témoins et pages légales réellement liées, pas seulement publiées.
Le lendemain
Le lancement ne termine pas la liste. Durant la première semaine, surveillez les erreurs d’exploration et les changements de couverture dans la Search Console, surveillez les 404 issues de trafic réel dans vos journaux de serveur, confirmez que l’indexation progresse, et vérifiez que les formulaires livrent toujours. Attendez-vous à un creux temporaire de visibilité après une relance. Ce qui doit inquiéter, c’est un creux qui ne se résorbe pas, et qui remonte presque toujours à la vérification numéro un ou à la numéro deux.
Si vous préférez que quelqu’un d’autre exécute cette liste, notre page développement WordPress sur mesure explique comment nous construisons et lançons, et ce que nous remettons.