Le recettage site web sert à vérifier, avant mise en ligne, que le site fonctionne vraiment dans les conditions prévues. Pas seulement sur Chrome, pas seulement quand le développeur est à côté. On contrôle les parcours, les contenus, le responsive, le SEO technique, la performance, l’accessibilité, la sécurité et la conformité. Le but n’est pas de promettre zéro bug. Le but est de réduire le risque sur les points qui coûtent cher dès le lancement.
Qu’est-ce que le recettage d’un site web ?
Le recettage d’un site web, ou recette web, est la phase de vérification qui intervient quand le site est suffisamment avancé pour être testé en conditions proches du réel. On ne code plus une idée. On vérifie une livraison.
Concrètement, l’équipe passe le site au crible à partir du cahier des charges, des maquettes, des spécifications fonctionnelles, de l’arborescence et des contenus validés. Chaque élément attendu doit être contrôlé : formulaire, bouton, page de service, tunnel de conversion, affichage mobile, balises SEO, cookies, temps de chargement, accès administrateur, emails transactionnels si le site en envoie.
Bon, il faut être clair : le recettage n’est pas de la maintenance post-lancement. Ce n’est pas non plus une session vague où chacun clique au hasard pendant une heure. Une bonne recette repose sur des scénarios, des critères d’acceptation et des retours centralisés.
Pourquoi le recettage est une étape critique avant la mise en ligne
Un bug visible le jour du lancement abîme la confiance. Un formulaire qui n’envoie pas les demandes, une page en 404 après refonte, un bouton masqué sur mobile ou une meta title oubliée ne sont pas de petits détails. Ce sont des pertes potentielles de leads, de trafic, de crédibilité.
La recette sert donc à protéger trois choses : l’expérience utilisateur, la visibilité SEO et la qualité technique. Elle force aussi client, agence et développeurs à se mettre d’accord sur une question simple : le site livré correspond-il à ce qui a été validé ?
J’insiste sur ce point parce que c’est souvent là que les projets dérapent. Une recette n’est pas un moment pour rouvrir tous les choix de design ou ajouter cinq nouvelles fonctionnalités. Si une demande sort du périmètre validé, elle doit être traitée comme une évolution. Sinon, la mise en production devient un marécage de tickets.
Préparer le recettage : documents, environnements et critères d’acceptation
La qualité d’une recette se joue avant le premier test. Si personne ne sait ce qui doit être validé, le recettage devient subjectif. Et le subjectif, en fin de projet web, coûte cher.
Commencez par rassembler les documents utiles :
- cahier des charges ou backlog validé ;
- maquettes desktop et mobile ;
- spécifications fonctionnelles ;
- arborescence et gabarits de pages ;
- contenus définitifs ou clairement identifiés comme provisoires ;
- règles SEO, redirections et plan de migration si refonte ;
- liste des rôles utilisateurs, surtout pour un espace client, un extranet ou un e-commerce.
L’environnement de test doit être une vraie préproduction, pas une version bricolée. Même PHP, même cache, mêmes plugins critiques, mêmes scripts tiers si possible. Sinon, vous validez un décor, pas le futur site.
Définissez aussi les navigateurs, appareils et profils à tester. Exemple simple : Chrome, Safari, Firefox, Edge, iPhone récent, Android courant, tablette si le trafic le justifie, compte administrateur, compte client, utilisateur non connecté.
Le point le plus utile reste le critère d’acceptation. Pour une fonctionnalité, écrivez ce qui doit se passer pour qu’elle soit validée. Pas « le formulaire marche ». Plutôt : « quand un visiteur soumet le formulaire avec des champs valides, le message de confirmation s’affiche, l’email arrive à l’équipe commerciale et les données sont stockées dans le CRM ». Là, on peut tester.
Pour le suivi, choisissez un seul outil : Notion, Trello, Jira, Linear, Markup.io, peu importe. Mais pas des captures dans Slack, deux emails et un Google Doc oublié. C’est le meilleur moyen de corriger trois fois la même anomalie.
Les tests indispensables dans une recette de site web
Une recette complète ne se limite pas aux fonctionnalités. Un site peut « marcher » et rester lent, inaccessible, mal indexable ou pénible sur mobile. C’est exactement le genre de livraison que je préfère refuser plutôt que maquiller.
| Famille de tests | Ce qu’on vérifie | Exemple d’anomalie | Outil ou livrable recommandé |
|---|---|---|---|
| Fonctionnel | Parcours, formulaires, compte, panier, recherche, emails | Le formulaire affiche un succès mais aucun email n’arrive | Cahier de recette, tickets qualifiés |
| Affichage | Responsive, composants, typographies, cohérence avec les maquettes | Un bouton CTA disparaît sur mobile | Tests multi-devices, capture annotée |
| SEO technique | Titles, metas, Hn, indexabilité, redirections, sitemap | Une ancienne URL stratégique renvoie une 404 | Crawl, plan de redirection, sitemap |
| Performance | LCP, CLS, INP, poids images, scripts, cache | Une image hero de 3 Mo ralentit la page service | Lighthouse, PageSpeed, suivi Core Web Vitals |
| Conformité | RGPD, cookies, mentions, HTTPS, accessibilité de base | Le bandeau cookies charge les scripts avant consentement | Checklist RGPD, tests clavier, contrôle HTTPS |
Tests fonctionnels
Commencez par les parcours qui font vivre le site. Demande de devis, contact, inscription, téléchargement, achat, recherche interne, création de compte, changement de mot de passe, changement de langue. Chaque parcours doit être testé avec des données valides et invalides. Un formulaire qui accepte tout sans message d’erreur n’est pas validé. Un formulaire qui bloque sans expliquer pourquoi non plus.
Tests d’affichage et responsive
Le responsive mérite plus qu’un coup d’œil rapide. Vérifiez les menus, les CTA, les cartes, les tableaux, les formulaires, les modales, les images et les espacements. Sur mobile, les problèmes sont souvent bêtes : bouton trop bas, titre qui coupe, bloc collé au bord, bannière cookies qui cache le CTA. Bête, mais visible par tout le monde.
Tests SEO technique
Sur une création ou une refonte, la recette SEO doit contrôler les fondamentaux : title, meta description, Hn, canonical, noindex, robots.txt, sitemap XML, données structurées si utiles, maillage interne, pagination, redirections 301 et pages 404. Pour les sujets de performance, gardez aussi un œil sur les Core Web Vitals, parce qu’ils touchent à la fois l’expérience et le référencement.
Tests de performance et Core Web Vitals
Un site prêt à publier doit charger correctement sur une connexion normale, pas seulement sur la fibre du bureau. Contrôlez le poids des images, les polices, les scripts tiers, le cache, le lazy loading et les principales métriques Lighthouse. Une image trop lourde en haut de page peut suffire à plomber le LCP. Un carrousel mal codé peut créer du CLS. Un script marketing ajouté à la dernière minute peut dégrader l’INP. Classique. Agaçant. Évitable.
Tests accessibilité, sécurité et conformité
Sans transformer la recette en audit RGAA complet, vérifiez au minimum les contrastes, la navigation clavier, les alternatives des images utiles, les labels de champs, les messages d’erreur, le HTTPS, les permissions admin, les sauvegardes, les mentions légales, la politique de confidentialité et le consentement cookies. Le RGPD ne se règle pas avec un plugin installé au hasard. Franchement, c’est encore trop fréquent.
Comment documenter les anomalies sans bloquer tout le projet
Une anomalie mal écrite crée une deuxième anomalie : personne ne sait quoi corriger. Le ticket doit permettre de reproduire le problème sans refaire l’enquête.
Modèle court de ticket d’anomalie
Classez ensuite chaque retour. Quatre niveaux suffisent dans la plupart des projets :
- Bloquant : empêche la mise en ligne ou un parcours critique.
- Majeur : dégrade fortement l’expérience, le SEO, la sécurité ou la conversion.
- Mineur : gêne réelle, mais contournable ou peu visible.
- Évolution : demande nouvelle, hors périmètre de la recette.
Le dernier niveau est vital. Beaucoup de tensions viennent de là. Une évolution peut être pertinente, mais elle ne doit pas se déguiser en bug pour entrer de force avant lancement.
Après correction, prévoyez des tests de régression. C’est le moment où l’on vérifie qu’un bug corrigé n’en a pas créé un autre. Exemple très courant : on corrige le bouton mobile sur la page contact, puis le même composant casse sur une page service. Oui, c’est pénible. Non, ce n’est pas optionnel.
Checklist de recettage site web avant publication
Voici la version courte à garder sous la main avant le go live. Elle ne remplace pas le cahier de recette, mais elle évite les oublis absurdes.
- Les fonctionnalités critiques sont testées avec succès.
- Les formulaires envoient les bons emails et affichent les bons messages.
- Les pages clés sont relues, sans contenu provisoire oublié.
- Le mobile, la tablette et les navigateurs cibles sont contrôlés.
- Les balises title, meta, Hn, canonical et noindex sont vérifiées.
- Les redirections fonctionnent, surtout après refonte.
- Le sitemap XML est propre et accessible.
- Les pages principales chargent avec une performance acceptable.
- Les contrastes, labels, alternatives images et navigation clavier de base sont testés.
- Le bandeau cookies, les mentions légales, la politique de confidentialité et le HTTPS sont en place.
- Les anomalies bloquantes sont fermées.
- Les anomalies majeures sont corrigées ou arbitrées par écrit.
- Le PV de recette ou la validation formelle est prêt.
Petite règle personnelle : si une anomalie peut empêcher un visiteur de contacter l’entreprise, acheter ou être indexé correctement, elle n’est pas mineure. Point.
Quand signer le PV de recette et passer en production ?
Le PV de recette sert à formaliser que le site livré est conforme au périmètre validé. Il ne dit pas que le site sera parfait pour toujours. Il dit que les critères d’acceptation définis avant la recette sont atteints, ou que les écarts restants sont acceptés.
Avant de signer, vérifiez trois choses : zéro bug bloquant, anomalies majeures corrigées ou arbitrées, évolutions sorties du périmètre et planifiées après mise en ligne. Ajoutez un gel raisonnable des changements juste avant le lancement. Modifier un menu, un formulaire ou une redirection à la dernière minute sans retest, c’est jouer avec une grenade tiède.
Après la mise en production, gardez une phase de monitoring : erreurs 404, formulaires, logs, analytics, indexation, performance, remontées utilisateurs. La recette prépare le lancement. Elle ne remplace pas la surveillance des premiers jours.
Recettage et sobriété numérique : le contrôle qualité ne s’arrête pas aux bugs
Un site peut être fonctionnel et rester trop lourd. C’est là que l’approche GreenCodeLab change la lecture du recettage. La qualité web ne se limite pas à « ça clique ». Elle inclut le poids des pages, le nombre de requêtes, les scripts tiers, les images, la lisibilité, l’accessibilité et l’impact sur les terminaux des utilisateurs.
Pour une agence web éco-responsable, la recette est aussi un moment de sobriété numérique. On ne cherche pas à tout optimiser jusqu’à l’obsession, ce serait contre-productif. On cible les corrections qui améliorent à la fois l’UX, le SEO et l’empreinte numérique : compression d’images, suppression de scripts inutiles, composants plus simples, meilleure hiérarchie de contenu, pages moins lourdes.
Quand le contexte le justifie, ajoutez un contrôle EcoIndex ou Lighthouse à votre recette. Pas pour afficher un score comme une médaille. Pour décider quoi corriger avant que le site ne soit exposé à de vrais utilisateurs.
Besoin d’un regard externe avant mise en ligne ?
Si votre site arrive en fin de développement et que les arbitrages deviennent flous, un regard externe peut éviter une mise en ligne fragile. GreenCodeLab peut intervenir en conseil technique web pour cadrer la recette, prioriser les anomalies et vérifier les points sensibles avant publication.
Pour les projets où performance, accessibilité et sobriété numérique comptent vraiment, l’audit numérique responsable permet aussi de contrôler ce que la recette fonctionnelle ne voit pas toujours : poids des pages, scripts, expérience réelle et impact technique des choix front-end.
