Mettre un site en ligne sans vérifier sa performance et sa sécurité, c'est ouvrir une boutique sans serrure et avec un éclairage défaillant. Le jour du lancement, tout le monde regarde le design. Trois semaines plus tard, ce sont les lenteurs, les formulaires cassés sur mobile ou la première tentative de piratage qui rappellent que la mise en production est une étape technique — pas un simple clic.
Chez Apresta, nous livrons des sites vitrines, e-commerce et applications métier à des PME de Lille et des Hauts-de-France depuis 2011. Cette checklist performance et sécurité avant lancement regroupe les contrôles que nous exécutons systématiquement avant de basculer un projet en production. Utilisez-la telle quelle, ou comme base de recette avec votre prestataire.
Pourquoi tester avant le lancement — pas après
Les erreurs détectées en pré-production coûtent une heure de correction. Les mêmes erreurs en production coûtent une perte de confiance utilisateur, un impact SEO si Google indexe des pages cassées ou lentes, un risque juridique si des données personnelles transitent sans chiffrement, et une facture d'urgence un dimanche soir si le site est compromis.
Le lancement n'est pas la fin du projet. C'est le moment où le site cesse d'être protégé par un environnement de staging et affronte le trafic réel, les bots et les erreurs humaines.
Un e-commerce lillois que nous avons repris après un lancement bâclé affichait un LCP de 6,2 secondes sur mobile et un certificat SSL mal configuré sur le sous-domaine www. Correction post-lancement : trois semaines de travail et une perte estimée de 18 % de conversions sur la période. Ce scénario se répète trop souvent — et il est évitable.
Priorisez les contrôles dans cet ordre : performance mobile d'abord (c'est là que partent vos visiteurs), sécurité de base ensuite (HTTPS, accès admin, mises à jour), puis parcours fonctionnels. Un site rapide mais avec un tunnel de paiement cassé sur Safari ne sert à rien.
Phase 1 — Performance : Core Web Vitals et temps de chargement
La performance n'est pas un « nice to have ». Google l'intègre au référencement, et vos visiteurs partent si la page met plus de 3 secondes à devenir utilisable sur 4G. En 2026, visez un LCP inférieur à 2,5 secondes, un INP inférieur à 200 millisecondes, un CLS inférieur à 0,1, un temps total inférieur à 3 secondes sur mobile 4G simulé, et un score Lighthouse Performance de 85 minimum — 90+ si le SEO et la conversion sont stratégiques.
Testez sur mobile ET desktop : le mobile représente souvent 65 à 80 % du trafic. Exécutez Lighthouse en navigation privée, depuis un réseau throttlé (Fast 3G ou 4G simulé). Vérifiez le LCP sur l'accueil, une page produit et la page contact — ce sont les trois pages que Google et vos visiteurs jugent en premier.
La plupart des sites lents que nous auditons en Hauts-de-France souffrent des mêmes causes : images hero non compressées, scripts tiers qui bloquent le rendu, cache serveur mal configuré. Corriger ces trois points suffit souvent à gagner 20 à 30 points Lighthouse sans refonte complète.
Checklist performance :
- test mobile ET desktop, réseau throttlé (4G simulé), LCP vérifié sur accueil, produit et contact
- images compressées (WebP/AVIF, dimensions adaptées), cache navigateur et serveur actifs
- scripts non critiques différés, CSS/JS minifiés, aucune ressource externe ne bloque le rendu
Pour atteindre un score Lighthouse supérieur à 90 : notre guide détaillé. Outils : PageSpeed Insights, Lighthouse Chrome DevTools, WebPageTest, GTmetrix ou Pingdom.
Phase 2 — Sécurité : protéger le site dès le jour J
Un site fraîchement lancé est une cible. Les bots scannent les CMS populaires en permanence à la recherche de failles connues, formulaires non protégés et panneaux d'administration exposés. La sécurité ne se limite pas au certificat SSL : c'est un ensemble de réglages qui doivent être vérifiés avant la bascule.
HTTPS doit être actif sur toutes les pages, y compris www et sous-domaines, avec un certificat valide et un renouvellement automatique. La redirection HTTP vers HTTPS doit être forcée. Configurez les en-têtes de sécurité (HSTS, X-Content-Type-Options, X-Frame-Options, CSP si possible). Les mots de passe admin doivent être forts (16+ caractères), avec MFA sur tous les accès admin. L'URL d'administration doit être non standard ou protégée par restriction IP.
Sur les projets WordPress que nous reprenons en Métropole lilloise, l'erreur la plus fréquente reste le certificat SSL installé sur le domaine principal mais pas sur www — ce qui génère des avertissements navigateur et des signaux mixtes pour Google. Vérifiez les deux variantes avant toute bascule.
Checklist sécurité essentielle :
- HTTPS actif partout, certificat valide, en-têtes sécurité configurés (HSTS, X-Content-Type-Options)
- MFA activée sur tous les accès admin, CMS et plugins à jour, formulaires protégés anti-spam
- limitation tentatives connexion, sauvegardes testées, aucune donnée sensible en clair dans les logs
Pour une approche complète : sécurité web en 2026. Côté données personnelles : formulaires en HTTPS uniquement, politique de confidentialité accessible, consentement cookies avant traceurs non essentiels.
Phase 3 — Fonctionnel : tout tester comme un utilisateur réel
La performance et la sécurité ne servent à rien si le bouton « Commander » ne fonctionne pas sur Safari iOS. Naviguez sur Chrome, Firefox, Safari et Edge. Testez sur iPhone et Android — pas seulement l'émulateur. Un bug qui n'apparaît que sur un navigateur ou un appareil représente souvent 15 à 25 % de votre audience perdue.
Validez le formulaire contact (envoi, réception, confirmation), l'inscription newsletter, le tunnel achat complet (panier, checkout, paiement test, email confirmation), la recherche interne, les liens menu/footer/CTA, la page 404 personnalisée et les pop-ups cookies sur mobile. Côté SEO technique, vérifiez aussi les title/meta uniques, le H1 unique, le sitemap soumis dans Search Console, le robots.txt cohérent, les canonicals et les redirections 301 sans chaînes.
Nous recommandons de parcourir chaque parcours critique avec un compte test réel, pas en mode admin connecté — les cookies, le cache et les droits diffèrent. Un formulaire qui fonctionne pour l'administrateur mais pas pour un visiteur anonyme est un classique des recettes bâclées.
Parcours à valider :
- navigation Chrome, Firefox, Safari, Edge — desktop et mobile réel
- formulaire contact et tunnel achat complets testés, recherche interne et liens sans lien mort
- title/meta uniques, sitemap Search Console, redirections 301 propres, données structurées validées
Phase 4 — Infrastructure : hébergement, sauvegardes et monitoring
Un site performant repose sur une infrastructure solide. Dimensionnez pour le trafic attendu plus une marge 3x — pic de lancement, campagne pub, effet bouche-à-oreille. Le runtime doit être à jour, la base optimisée, le CDN activé pour les assets statiques si le trafic est national. Privilégiez un serveur en France ou UE pour la latence et le RGPD.
La sauvegarde automatique quotidienne minimum (fichiers + BDD) doit être stockée en externe au serveur principal. Testez la restauration avant le lancement — une sauvegarde non testée n'est pas une sauvegarde. Documentez qui restaure, en combien de temps, avec quels accès.
Configurez aussi une alerte uptime et une surveillance du certificat SSL. Search Console et Analytics ou Matomo doivent être installés avec consentement cookies. Sans monitoring, vous découvrez la panne via un client — pas via une alerte.
Infrastructure :
- ressources dimensionnées trafic + marge 3x, sauvegarde quotidienne externe, restauration testée
- alerte uptime, surveillance certificat SSL, Search Console et Analytics avec consentement cookies
Phase 5 — E-commerce : checklist spécifique boutique en ligne
Si vous lancez une boutique, les contrôles vitrine ne suffisent pas. Chaque moyen de paiement activé (CB, PayPal, virement) doit être testé en conditions réelles. Les emails transactionnels (confirmation, expédition, compte créé) doivent arriver en boîte de réception — pas en spam. Vérifiez les frais de port sur plusieurs scénarios, les stocks et alertes rupture, les codes promo, les pages légales (CGV, mentions, retour), la conformité des prix TTC, et effectuez un test d'achat depuis un réseau mobile.
Une boutique lilloise que nous avons accompagnée avait oublié de tester les emails transactionnels en conditions réelles : les confirmations partaient en spam faute de SPF/DKIM configurés. Résultat : 40 % des clients appelaient le SAV « pour confirmer » leur commande. Une heure de configuration DNS aurait évité des semaines de friction.
E-commerce — minimum vital :
- paiement test réussi sur chaque moyen activé, emails transactionnels reçus en test réel
- frais de port corrects, pages légales complètes, test achat depuis réseau mobile
Notre checklist complète : lancement boutique en ligne.
Phase 6 — Recette formelle et go/no-go
Ne validez pas le lancement sur un « ça a l'air bon ». Préparez un staging identique à la production, figez le périmètre, désignez un responsable recette côté client et côté prestataire. Chaque item doit être coché avec date et nom du testeur. Classez les anomalies en bloquante, majeure ou mineure. Aucune bloquante ne doit subsister au lancement.
Go : bloquantes résolues, majeures documentées avec date de correction. No-go : report même de 48 h — moins coûteux qu'un lancement raté. Le jour J, basculez en heure creuse, vérifiez post-bascule (HTTPS, formulaires, accueil, admin), et maintenez une surveillance renforcée pendant 72 h.
Une PME de Tourcoing a reporté son lancement d'une semaine pour corriger un tunnel de paiement défaillant sur iOS. Résultat : zéro commande perdue, zéro avis négatif. Le report était rentable.
Erreurs fréquentes que nous voyons en pré-lancement
Les mêmes erreurs reviennent sur les projets que nous reprenons en Hauts-de-France. Le certificat SSL installé mais www non couvert reste le piège numéro un. Viennent ensuite les images hero de 3 Mo non compressées, les plugins cache activés mais non testés (pages blanches), Analytics sans bandeau cookies (non conforme RGPD), redirections 302 au lieu de 301, emails formulaire en spam (SPF/DKIM absents), sauvegardes jamais testées en restauration, admin à l'URL par défaut (/wp-admin), mode maintenance oublié actif, robots.txt bloquant tout le site.
Chacune de ces erreurs est détectable en une heure de recette structurée. Le coût de ne pas les détecter se mesure en semaines de correction et en confiance perdue.
Pièges à éviter :
- certificat SSL incomplet (www non couvert), images hero non compressées (> 1 Mo)
- Analytics sans bandeau cookies RGPD, redirections 302 au lieu de 301 en migration
- sauvegardes activées mais jamais testées, robots.txt bloquant tout le site en production
FAQ
Quel score Lighthouse minimum avant de lancer un site ?
Visez 85 en Performance sur mobile pour un lancement acceptable, 90+ pour un site dont le SEO et la conversion sont stratégiques. Un score inférieur à 70 signale des problèmes structurels (images, scripts, hébergement) à corriger avant la mise en ligne.
Combien de temps prend une recette complète avant lancement ?
Pour un site vitrine de 10 à 15 pages : 1 à 2 jours. Pour un e-commerce de 50 à 200 produits : 3 à 5 jours. Pour une migration complexe avec redirections : ajoutez 2 à 3 jours de vérification SEO. Ces durées supposent un environnement de staging fonctionnel et un périmètre figé.
Faut-il tester la sécurité avec un audit de pénétration avant chaque lancement ?
Pas systématiquement pour un site vitrine standard. En revanche, un pentest est recommandé pour les sites qui stockent des données sensibles, les applications métier avec authentification, et tout e-commerce avec volume significatif. Un audit automatisé (OWASP ZAP, scan de vulnérabilités CMS) est un minimum viable pour tous les projets.
Qui doit valider le go/no-go : le client ou l'agence ?
Les deux. L'agence certifie la conformité technique. Le client valide le contenu, les parcours métier et l'adéquation avec ses attentes. Un lancement sans validation client explicite est une source de litige — formalisez un procès-verbal de recette signé.
Que faire si le site est lent uniquement en production, pas en staging ?
Vérifiez dans cet ordre : configuration cache serveur/CDN, différence ressources hébergement, DNS pas encore propagé, certificat SSL forçant un round-trip supplémentaire, plugins sécurité/firewall actifs en production uniquement. Comparez en-têtes HTTP et taille des pages entre les deux environnements.
Et maintenant ?
Cette checklist performance et sécurité avant lancement n'est pas une formalité administrative. C'est le filet qui évite d'apprendre vos failles via un client furieux, un piratage ou une chute de position Google. Pour aller plus loin, consultez notre guide Lighthouse 90+, la sécurité web en 2026 et la checklist lancement boutique. Agence web Lille — Contact.