Ce qu’il faut vérifier avant de lancer un site Web : la liste ultime avant la mise en ligne

1. UI/UX et adaptation mobile

Votre site doit fonctionner sans accroc sur toutes les tailles d’écran, tous les navigateurs et tous les appareils. Une mise en page parfaite sur votre portable peut être pénible sur un téléphone.

Avant le lancement, vérifiez ceci :

• Éliminer le défilement horizontal sur toutes les tailles d’écran.
• Corriger les débordements et les éléments qui se chevauchent sur mobile.
• Ajouter un menu de navigation mobile fonctionnel.
• S’assurer que chaque page est optimisée pour les appareils mobiles.
• Tester le site sur un téléphone Android d’entrée de gamme.
• Rendre le logo cliquable et le lier à la page d’accueil.
• Retirer les éléments de navigation inutilisés.
• Retirer tout texte de remplissage et tout contenu inachevé.
• Corriger les boutons brisés et les interactions qui ne fonctionnent pas.
• Ajouter un favicon.
• Corriger l’année du droit d’auteur.
• Créer une page 404 professionnelle pour les pages introuvables.
• Créer une page d’erreur 500 pour les erreurs serveur.

À retenir : un design adaptatif ne consiste pas à rapetisser les éléments. Il s’agit de garder le site utilisable sur tous les appareils.

2. Liens, boutons et fonctionnement du site

Chaque élément interactif visible doit faire ce que l’utilisateur attend.

• Trouver et corriger les liens internes et externes brisés.
• Vérifier chaque lien du pied de page.
• Rendre les numéros de téléphone cliquables avec tel:.
• Rendre les adresses courriel cliquables avec mailto:.
• Tester chaque bouton et chaque appel à l’action.
• Afficher un message de confirmation après chaque action réussie.
• Afficher des messages d’erreur clairs quand quelque chose échoue.
• Tester les formulaires, menus déroulants, menus et autres composantes interactives.
• S’assurer que les gens peuvent vous joindre par un moyen de contact fonctionnel.
• Vérifier que chaque élément de navigation mène au bon endroit.

Ne laissez jamais des boutons qui ont l’air fonctionnels mais qui ne font rien quand on clique dessus.

3. SEO et métadonnées pour les réseaux sociaux

Les moteurs de recherche et les réseaux sociaux ont besoin d’information exacte sur votre site et ses pages.

Avant le lancement :

• Donner à chaque page importante un titre unique et descriptif.
• Ajouter des méta-descriptions pertinentes.
• Configurer les balises meta appropriées.
• Ajouter des métadonnées Open Graph et une image OG pour de beaux aperçus de liens sur X et ailleurs.
• Définir les URL canoniques au besoin.
• Vérifier que les pages importantes peuvent être indexées.
• Générer un plan de site XML.
• Configurer correctement robots.txt.
• Corriger les liens brisés et éviter les chaînes de redirections inutiles.

Le SEO ne garantit pas un classement, mais de bonnes bases techniques aident les moteurs de recherche à comprendre votre site.

4. Vitesse et performance du site

Les sites lents frustrent les utilisateurs et peuvent nuire aux conversions. Testez la performance avant le lancement, pas après les premières plaintes.

• Compresser et optimiser les images.
• Utiliser WebP ou AVIF au besoin.
• Retirer le JavaScript, le CSS et les dépendances inutilisés.
• Optimiser le chargement des polices.
• Charger en différé les images non essentielles.
• Configurer la mise en cache et la compression.
• Tester le site sur des connexions mobiles lentes.
• Mesurer les Core Web Vitals.
• Examiner les pages et les actions qui prennent plus de trois secondes à charger.
• Vérifier si des scripts tiers ralentissent le site.

Ne présumez pas qu’un site est rapide simplement parce qu’il charge vite sur votre propre ordinateur.

5. Clés d’API, variables d’environnement et secrets

L’une des règles de sécurité les plus importantes est simple : n’exposez jamais de clés d’API privées ni d’identifiants dans le code front-end.

• Garder les clés d’API privées sur le serveur.
• Stocker les secrets dans des variables d’environnement ou un gestionnaire de secrets.
• Ne jamais versionner de secrets dans Git.
• Renouveler tout identifiant exposé ou versionné dans un dépôt.
• Retirer les secrets exposés de l’historique Git au besoin.
• Ajouter les fichiers d’environnement contenant des secrets à .gitignore.
• Utiliser des identifiants distincts pour le développement et la production.
• Revoir les variables d’environnement du déploiement.
• Ne jamais exposer d’identifiants de base de données privilégiés ni de clés « service role » dans le code client.
• N’utiliser des clés de base de données publiques que si la plateforme est conçue pour cela et que des politiques d’accès appropriées sont appliquées.

Retirer une clé de votre code ne suffit pas si elle a déjà été exposée. Révoquez-la ou renouvelez-la d’abord.

6. Authentification, autorisation et sécurité de la base de données

Un tableau de bord caché ou un bouton qui a l’air protégé ne rendent pas une application sécuritaire.

• Appliquer l’authentification côté serveur pour chaque route protégée et chaque point d’accès d’API.
• Vérifier l’autorisation pour chaque opération sensible.
• Configurer la sécurité au niveau des lignes (RLS) quand c’est possible.
• Restreindre l’accès à la base de données selon la propriété des données et les permissions.
• Empêcher les utilisateurs de modifier des champs protégés comme les rôles ou les identifiants de propriétaire.
• Sécuriser les témoins de session avec les bons réglages HttpOnly, Secure et SameSite.
• Hacher les mots de passe avec un algorithme de hachage approprié.
• Chiffrer les données sensibles en transit et au repos au besoin.
• Configurer l’expiration des sessions et la révocation des jetons.
• Limiter le débit des points d’accès de connexion, d’inscription et de réinitialisation du mot de passe.
• Ajouter une protection contre les robots là où c’est pertinent.

Testez toujours l’accès avec différents comptes. Un utilisateur ordinaire ne devrait jamais pouvoir consulter les données privées d’un autre simplement en changeant un identifiant dans une URL ou une requête d’API.

7. Validation des entrées et gestion des erreurs

Ne faites jamais confiance à une entrée simplement parce qu’elle vient de l’interface de votre propre site.

• Valider toutes les entrées sur le serveur.
• Utiliser des requêtes paramétrées ou des méthodes d’ORM sécuritaires.
• Afficher le contenu généré par les utilisateurs de façon sécuritaire pour prévenir les attaques XSS.
• Restreindre les téléversements par type, taille et contenu.
• Empêcher les mises à jour de champs non autorisées et l’assignation de masse.
• Ne renvoyer que les données d’API que chaque utilisateur a le droit de voir.
• Utiliser les bons codes d’état HTTP.
• Empêcher les messages d’erreur d’exposer des traces d’exécution, des détails de la base de données ou des identifiants.
• Configurer les en-têtes de sécurité, dont une Content Security Policy appropriée.
• Imposer HTTPS.
• Revoir les réglages CORS.

La validation côté front-end améliore l’expérience utilisateur, mais la validation côté serveur est essentielle à la sécurité.

8. Limitation du débit et contrôle des coûts d’API d’IA

Si votre site utilise des modèles d’IA ou des API tierces payantes, une utilisation non contrôlée peut coûter très cher très vite.

• Limiter le débit des points d’accès coûteux.
• Fixer des plafonds de dépenses ou des alertes de budget chez votre fournisseur d’IA, s’il y a lieu.
• Configurer des quotas d’utilisation.
• Limiter la taille des requêtes, le nombre de jetons et la concurrence.
• Fixer des délais d’expiration raisonnables.
• Mettre en cache les requêtes répétées au besoin.
• Surveiller l’utilisation et les coûts des API.
• Garder les appels d’API privilégiés sur le serveur.
• Détecter les habitudes d’utilisation suspectes.
• Configurer des alertes en cas de pic inhabituel de requêtes ou de dépenses.

Ne présumez pas qu’un abonnement payant à une IA couvre l’utilisation de son API. L’abonnement et la facturation de l’API peuvent être séparés.

9. Surveillance, sauvegardes et reprise

Un site n’est pas prêt pour la production si vous ne pouvez ni détecter les pannes ni vous en remettre.

• Mettre en place le suivi des erreurs de l’application.
• Configurer la surveillance de la disponibilité.
• Ajouter des alertes pour les pannes critiques.
• Éviter de journaliser les mots de passe, les jetons d’accès et les renseignements personnels inutiles.
• Sauvegarder la base de données régulièrement.
• Tester la restauration d’une sauvegarde.
• Définir la durée de conservation des sauvegardes.
• Documenter vos objectifs de reprise.
• Préparer un plan de retour en arrière pour les déploiements ratés.
• Tester la procédure de retour en arrière.
• Analyser les dépendances pour les vulnérabilités connues.

Une sauvegarde qui n’a jamais été restaurée est un plan de reprise non vérifié.

10. Conformité juridique et vie privée

Les exigences juridiques dépendent de votre territoire, de votre public et du fonctionnement de votre site. Ne copiez pas les documents juridiques d’un autre site sans vérifier s’ils s’appliquent à votre entreprise.

Revoyez ceci :

• Publier une politique de confidentialité exacte.
• Publier des conditions d’utilisation appropriées.
• Mettre en place des restrictions ou une vérification d’âge quand la loi l’exige.
• Revoir les polices tierces et envisager de les héberger vous-même quand c’est pratique.
• Désactiver les outils d’enregistrement de session inutiles ou configurer le consentement et le masquage des champs.
• Revoir les outils d’analytique et de suivi selon les exigences de consentement applicables.
• Inclure un lien de désabonnement dans les courriels de marketing.
• Inclure l’identification de l’expéditeur et l’adresse postale requises dans les courriels de marketing.
• Afficher clairement le prix de l’abonnement, la fréquence de facturation, les conditions de renouvellement et d’annulation à côté du bouton d’abonnement.
• Prévoir des processus pour les demandes relatives à la vie privée et la suppression des données.
• Revoir les lois applicables sur la vie privée, la protection du consommateur et le pourriel (au Canada, notamment la LPRPDE et la LCAP).

11. Délivrabilité des courriels

Votre site peut fonctionner parfaitement pendant que ses courriels finissent dans les indésirables.

Avant le lancement :

• Tester les courriels de vérification de compte.
• Tester les courriels de réinitialisation du mot de passe.
• Tester les courriels transactionnels et les reçus de paiement.
• Configurer SPF, DKIM et DMARC.
• Vérifier votre domaine d’envoi.
• Tester la livraison chez les principaux fournisseurs de courriel.
• Inclure une fonction de désabonnement appropriée dans les courriels de marketing.
• Surveiller les courriels rejetés et les plaintes pour pourriel.
• Éviter les courriels en double quand une requête est relancée.

Testez les courriels du début à la fin, jusqu’à leur arrivée réelle dans la boîte de réception du destinataire.

12. Analytique et suivi des conversions

Lancer un site sans analytique rend plus difficile de comprendre comment les gens l’utilisent.

• Configurer une plateforme d’analytique.
• Suivre les événements importants comme l’inscription, la connexion, le paiement et l’envoi de formulaires.
• Repérer où les utilisateurs abandonnent les parcours importants.
• Surveiller les transactions échouées et les erreurs de formulaire.
• Configurer les contrôles de confidentialité et le consentement au besoin.
• Exclure les renseignements sensibles des événements d’analytique.
• Vérifier que les événements sont enregistrés correctement.
• Établir des mesures de référence pour la performance et les conversions.

Ne recueillez que les données dont vous avez besoin et traitez-les de façon responsable.

13. Tests de bout en bout

Testez le site comme un vrai utilisateur le vivrait.

• Tester l’inscription et la vérification du compte.
• Tester la connexion et la déconnexion.
• Tester la récupération du mot de passe.
• Tester les paiements réussis et refusés.
• Tester l’annulation et le renouvellement des abonnements, s’il y a lieu.
• Vérifier les permissions des différents rôles d’utilisateurs.
• Tester les téléversements et les téléchargements de fichiers.
• Vérifier les mises en page mobile, tablette et ordinateur.
• Tester la navigation au clavier et l’accessibilité.
• Vérifier les erreurs de la console du navigateur et les requêtes réseau échouées.
• Tester les parcours critiques dans l’environnement de production.
• Confirmer que la version de production n’expose ni secrets ni information de débogage.

Ne testez pas seulement le scénario idéal. Paiements refusés, formulaires invalides, sessions expirées et requêtes non autorisées doivent aussi être testés.

14. Liste finale avant le déploiement

Avant de rendre votre site public :

• Vérifier toutes les variables d’environnement de production.
• Confirmer HTTPS et la configuration du domaine.
• Exécuter les vérifications de sécurité et des dépendances.
• Appliquer les migrations de base de données de façon sécuritaire.
• Vérifier que les sauvegardes fonctionnent.
• Confirmer que la surveillance et les alertes sont actives.
• Préparer et tester votre plan de retour en arrière.
• Vérifier toutes les pages et tous les points d’accès d’API critiques.
• Tester l’inscription, les paiements et la récupération du mot de passe en production.
• Noter la version déployée et tout problème connu.

Faire vérifier cette liste par l’IA

Copiez cette requête dans Claude Code, Cursor ou un autre assistant de code IA ouvert dans votre projet, et remplissez la partie « À propos de mon site ». Il passe en revue les 14 sections, pointe les fichiers et les pages exacts à corriger et attend votre approbation avant de changer quoi que ce soit.

Tu révises mon site Web avant son lancement. Ne modifie encore aucun code. Inspecte d’abord le projet, puis fais ton rapport.

À propos de mon site (à remplir) :
- Ce que c’est (portfolio, site d’entreprise, boutique, SaaS, application Web) :
- Pile technologique et hébergement :
- Y a-t-il des comptes utilisateurs, des paiements, des formulaires ou des fonctions d’IA? (énumère-les)
- URL en ligne ou de préproduction (s’il y a lieu) :

Passe en revue cette liste avant la mise en ligne :

1. UI/UX et mobile : aucun défilement horizontal, aucun élément qui déborde ou se chevauche, menu mobile fonctionnel, texte et zones tactiles lisibles, mise en page cohérente selon les tailles d’écran.
2. Liens et fonctionnement : liens brisés, boutons qui ne font rien, formulaires qui échouent, page 404 manquante, texte de remplissage ou liens « # » oubliés.
3. SEO et métadonnées sociales : titres et descriptions uniques, images Open Graph et Twitter, favicon, sitemap.xml, robots.txt, URL canoniques, textes de remplacement, un seul H1 par page.
4. Vitesse et performance : taille et format des images, chargement différé, JavaScript et CSS inutilisés, chargement des polices, en-têtes de cache, tout ce qui nuirait aux Core Web Vitals.
5. Secrets : clés d’API ou mots de passe dans le code front-end, variables d’environnement publiques (NEXT_PUBLIC_, VITE_) contenant des secrets, fichiers .env ou clés versionnés dans git.
6. Authentification et sécurité de la base de données : chaque route protégée et chaque API vérifiées sur le serveur, impossibilité d’accéder aux données d’un autre en changeant un identifiant, actions admin réservées aux admins, règles de base de données (RLS Supabase, règles Firebase) activées.
7. Validation des entrées et erreurs : validation côté serveur pour chaque formulaire et chaque API, messages d’erreur sûrs (aucune trace d’exécution ni détail interne), risques d’injection SQL et de XSS.
8. Limitation du débit et coûts d’IA : limites sur la connexion, l’inscription, les formulaires de contact et les points d’accès d’IA, plafonds de dépenses ou limites d’utilisation sur les API payantes.
9. Surveillance, sauvegardes et reprise : suivi des erreurs, surveillance de la disponibilité, sauvegardes de la base de données et test de restauration.
10. Juridique et vie privée : politique de confidentialité, conditions d’utilisation, consentement aux témoins au besoin, données personnelles recueillies et où elles vont.
11. Courriels : SPF, DKIM et DMARC pour le domaine d’envoi, courriels transactionnels qui arrivent dans la boîte de réception, adresse de réponse fonctionnelle.
12. Analytique : analytique installée et respectant le consentement, conversions clés (inscriptions, achats, envois de formulaires) suivies.
13. Tests de bout en bout : inscription, connexion, réinitialisation du mot de passe, paiement et autres parcours critiques, y compris les échecs (mauvais mot de passe, paiement refusé, session expirée).
14. Déploiement final : variables d’environnement de production, HTTPS et domaine, vérifications de sécurité et des dépendances, migrations, plan de retour en arrière.

Pour chaque problème, donne :
- La section de la liste et un titre d’une ligne
- La gravité : À corriger avant le lancement / À corriger bientôt / Souhaitable
- La preuve : chemin du fichier et ligne, URL de la page ou point d’accès
- La correction la plus simple

Règles :
- Ne signale que ce que tu peux confirmer. Mets ce que tu ne peux pas vérifier dans le code (par exemple les enregistrements DNS des courriels ou les réglages d’hébergement) sous « À vérifier manuellement », avec la façon de le vérifier.
- Marque les sections qui ne s’appliquent pas à ce site comme « Sans objet ».

Termine par un tableau des 14 sections (Prêt / À améliorer / Sans objet / À vérifier manuellement), puis les points « à corriger avant le lancement » dans l’ordre où je devrais les faire.

Attends mon approbation avant de modifier du code.