Développement web
Recette de site web avant mise en ligne : checklist, preuves et décision go/no-go
Une recette de site web ne devrait pas produire une note moyenne. Elle doit montrer si les parcours, les données et l’accès public sont assez vérifiés pour autoriser la mise en ligne.
Cette méthode répartit 54 contrôles en sept familles et trois portes go/no-go, puis prévoit 15 contrôles post-lancement. Chaque ligne relie un critère d’acceptation à une preuve, un responsable et une règle de blocage. La matrice XLSX est accessible sans formulaire.
Épisode long
Approfondir l’analyse avec l’épisode Edikka.
Une version longue pour replacer les chiffres, les arbitrages et les conséquences opérationnelles de cette analyse.
Durée : 7:43.
Compagnon de l’épisode 13
Une recette ne valide pas une impression : elle relie un contrôle à une preuve.
Un site peut sembler prêt dans un navigateur tout en perdant les demandes commerciales, en déclenchant des traceurs trop tôt ou en restant fermé aux moteurs. La décision de mise en ligne devient défendable lorsque chaque contrôle décrit un résultat observable et la preuve qui permettra de le rejouer.
| Champ | Question à trancher | Exemple pour un formulaire commercial |
|---|---|---|
| Contrôle | Quelle action précise est testée ? | L’envoi valide du formulaire commercial principal. |
| Critère | Quel résultat observable vaut réussite ? | Une demande est créée dans le CRM et les confirmations prévues sont émises. |
| Preuve | Que conserve-t-on pour rejouer le test ? | Heure, identifiant de test, enregistrement CRM et notifications reçues. |
| Responsabilité | Qui exécute, corrige et accepte ? | Les trois rôles restent nommés, même lorsqu’ils appartiennent à la même équipe. |
| Statut | Quel vocabulaire commun décrit le résultat ? | Réussi, échoué, non applicable ou non testé. |
| Blocage | L’écart interdit-il la mise en ligne ? | Oui, non ou conditionnel, avec une condition écrite avant le test. |
Décider sans moyenne trompeuse
Trois portes protègent la décision GO/NO-GO.
Les 54 contrôles ne produisent pas une note globale. Une moyenne pourrait masquer un seul défaut critique. La matrice regroupe donc les résultats dans trois portes indépendantes : un échec bloquant ou un contrôle bloquant non testé suffit à fermer la porte concernée.
L’action utile aboutit-elle jusqu’au système cible ?
Formulaires, inscriptions, authentification, téléchargement ou paiement sont contrôlés de bout en bout, erreurs et notifications comprises.
Les accès, les données et le retour arrière sont-ils maîtrisés ?
La recette vérifie le périmètre convenu et empêche de reporter les points critiques au dernier moment. Elle ne remplace pas un audit de sécurité.
Les humains et les robots autorisés atteignent-ils la bonne version ?
Codes HTTP, redirections, canonicals, robots, sitemaps, langues et données structurées sont vérifiés sur la destination finale.
Rendre la réserve exécutable
Un GO sous réserves exige quatre informations, pas une promesse vague.
| Exigence | Contenu attendu | Risque évité |
|---|---|---|
| Impact | Conséquence connue pour les utilisateurs, les données ou l’exploitation. | Minimiser un écart dont la portée n’a pas été examinée. |
| Responsable | Personne chargée de la correction et personne autorisée à l’accepter. | Laisser une anomalie sans propriétaire. |
| Échéance | Date et fenêtre de correction compatibles avec le risque. | Transformer le provisoire en dette permanente. |
| Contre-test | Scénario, preuve attendue et personne qui clôturera la réserve. | Déclarer la correction sans vérifier ses effets. |
La décision finale reste humaine. L’indicateur de la matrice signale les no-go, les arbitrages et les contrôles non testés ; il ne connaît ni le contrat, ni les obligations exactes, ni les personnes habilitées à accepter le risque.
Passer de l’épisode à la preuve
Télécharger la matrice, puis relier recette, migration et cahier des charges.
Réponse courte
La recette d’un site web relie chaque contrôle à un résultat attendu, une preuve et une décision de mise en ligne.
Une recette utile ne consiste pas à parcourir quelques pages avant de cliquer sur « publier ». Elle vérifie des parcours, des contenus, des données, des réponses serveur et des responsabilités définis avant le test.
Chaque ligne doit comporter au minimum un contrôle, un critère d’acceptation, une preuve attendue, un responsable, un statut et une règle de blocage. Un contrôle non testé n’est pas réussi. Un défaut critique accepté oralement ne devient pas non bloquant.
Une porte bloquante échouée ou non testée entraîne un no-go. Une réserve non bloquante doit être attribuée, datée et acceptée avant le go.
Définition opérationnelle
La recette répond à une question plus exigeante que « le site fonctionne-t-il ? ».
Elle doit déterminer si le périmètre convenu est suffisamment vérifié pour être exposé aux utilisateurs, aux moteurs, aux outils métier et aux équipes internes. Cette décision ne repose ni sur une impression générale ni sur la moyenne de résultats hétérogènes.
Le cahier des charges définit les engagements et leurs critères d’acceptation. La recette rejoue ces critères dans un environnement connu, conserve les traces et attribue les écarts. Lorsque les URL changent, le protocole de migration SEO fournit la décision URL par URL ; la recette vérifie son exécution.
| Champ | Question à laquelle il répond | Formulation insuffisante |
|---|---|---|
| Contrôle | Que teste-t-on exactement ? | « Vérifier le formulaire » |
| Critère d’acceptation | Quel résultat observable valide le contrôle ? | « Le formulaire marche » |
| Preuve | Quelle trace permettra de rejouer ou contester le résultat ? | « Testé par l’agence » |
| Responsable | Qui exécute, corrige et accepte ? | « L’équipe projet » |
| Statut | Le résultat est-il réussi, échoué, non applicable ou non testé ? | « Presque bon » |
| Blocage | L’échec interdit-il la mise en ligne ? | « À voir après lancement » |
Taxonomie contrôlée
Sept familles rendent les 54 contrôles lisibles sans les réduire à une note.
Chaque contrôle de la matrice appartient à une seule famille et à une seule porte de décision. Une famille peut toutefois réunir des contrôles relevant de plusieurs portes. Cette double lecture permet de préparer les compétences nécessaires, puis de décider le go ou le no-go selon la fonction vitale concernée.
| Famille | Contrôles | Périmètre couvert | Répartition par porte |
|---|---|---|---|
| Contenus, navigation et administration | 8 | Pages, navigation, recherche, ressources publiques et publication éditoriale. | 7 Parcours métier · 1 Accès public et découvrabilité |
| Parcours fonctionnels et intégrations | 6 | Formulaires, notifications, CRM, comptes et échanges avec les systèmes cibles. | 6 Parcours métier |
| Accessibilité et compatibilité | 5 | Responsive, navigateurs, clavier, lecteur d’écran, reflow et zoom. | 5 Parcours métier |
| Performance et observabilité | 3 | Seuils reproductibles, régressions bloquantes, logs et alertes critiques. | 2 Parcours métier · 1 Sécurité, données et reprise |
| Sécurité, données, consentement et reprise | 15 | Transport, accès, données, consentement, obligations, sauvegarde et rollback. | 15 Sécurité, données et reprise |
| SEO, GEO et accès public | 15 | Migration, indexabilité, exploration, langues, métadonnées et accès aux outils. | 15 Accès public et découvrabilité |
| Mesure et attribution | 2 | Événements de conversion, paramètres autorisés et continuité de l’attribution. | 2 Accès public et découvrabilité |
| Total avant mise en ligne | 54 | Une ligne appartient à une seule famille et une seule porte. | 20 Parcours métier · 16 Sécurité, données et reprise · 18 Accès public et découvrabilité |
Le nombre de contrôles reflète la surface technique à couvrir, pas le poids dans la décision : le blocage se lit dans les portes, pas dans les volumes.
54 contrôles composent la matrice complète avant mise en ligne. 18 contrôles représentatifs sont détaillés dans l’article. 15 contrôles supplémentaires organisent le suivi à J+1, J+7 et J+30 ; ils ne sont pas inclus dans les 54.
Trois portes de décision
Un site ne devrait pas passer en production si une seule de ses trois fonctions vitales reste non démontrée.
Parcours métier
Une action utile aboutit du navigateur jusqu’au système cible.
Formulaire, demande de devis, inscription, téléchargement, authentification ou candidature : le succès, les erreurs, les notifications et les données créées sont contrôlés de bout en bout.
Sécurité, données et reprise
Le site ne divulgue pas ce qui doit rester protégé et peut revenir à un état sûr.
Accès, rôles, données de test, traceurs, sauvegarde, restauration et retour arrière sont vérifiés sur le périmètre convenu. La recette ne remplace pas un audit de sécurité.
Accès public et découvrabilité
Les humains et robots autorisés atteignent la bonne version des contenus.
Codes HTTP, redirections, canonicals, robots, sitemaps, données structurées, langues, liens et contenus publics sont vérifiés sur la destination finale, CDN et pare-feu compris.
Une moyenne peut masquer un formulaire qui perd les demandes, un traceur déclenché sans consentement ou un site entièrement en noindex. Ces défauts ne sont pas compensés par vingt contrôles cosmétiques réussis.
Matrice critique
Dix-huit contrôles représentatifs à rattacher au périmètre réel du site.
Les lignes ci-dessous forment un socle de discussion, pas une conformité automatique. Le caractère bloquant doit être décidé avant la recette selon les parcours, les obligations et les risques du projet. La matrice XLSX téléchargeable contient le protocole complet et les colonnes de preuve.
| Domaine | Famille | Critère d’acceptation observable | Preuve minimale | Blocage indicatif |
|---|---|---|---|---|
| Pages critiques | Contenus, navigation et administration | Accueil, offres, contact, pages légales et parcours prioritaires répondent sans erreur 5xx ni boucle. | Crawl daté et réponses HTTP. | Oui |
| Navigation | Contenus, navigation et administration | Navigation principale, pied de page, fil d’Ariane et liens des parcours déclarés critiques mènent à leur destination finale. | Crawl des liens et contrôle humain. | Conditionnel |
| Formulaire principal | Parcours fonctionnels et intégrations | Un envoi valide crée la donnée attendue, confirme l’action et déclenche les notifications prévues. | Scénario horodaté et donnée visible dans le système cible. | Oui |
| Erreurs de formulaire | Parcours fonctionnels et intégrations | Sur un parcours déclaré critique, chaque erreur est annoncée, reliée au champ concerné et ne supprime pas les données valides déjà saisies. | Capture ou vidéo clavier et lecteur d’écran. | Oui |
| Intégrations | Parcours fonctionnels et intégrations | Les intégrations déclarées critiques — CRM, emailing, recrutement, paiement ou API — reçoivent les champs, formats et consentements convenus. | Journal de test et enregistrement cible. | Conditionnel |
| Clavier et focus | Accessibilité et compatibilité | Les parcours prioritaires sont opérables au clavier, sans piège, avec un focus visible et logique. | Scénario manuel daté. | Oui |
| Lecteur d’écran | Accessibilité et compatibilité | Titres, repères, commandes, champs, états et messages critiques sont nommés et annoncés utilement. | Compte rendu du test et environnement précisé. | Oui |
| Responsive | Accessibilité et compatibilité | Les gabarits et parcours prioritaires restent lisibles et opérables aux largeurs et zooms convenus. | Matrice appareils, navigateurs et captures ciblées. | Conditionnel |
| Performance | Performance et observabilité | Les pages, conditions et seuils contractuels sont respectés ; le résultat laboratoire n’est pas présenté comme une donnée terrain. | Rapport reproductible et contexte de mesure. | Conditionnel |
| Consentement | Sécurité, données, consentement et reprise | Aucun traceur soumis au consentement n’est lu ou déposé avant le choix ; accepter, refuser et retirer restent accessibles. | Inspection réseau et stockage avant/après chaque choix. | Oui |
| Accès et rôles | Sécurité, données, consentement et reprise | Chaque profil accède seulement aux contenus, données et actions prévus. | Scénarios par rôle et journal des écarts. | Oui |
| Sauvegarde et retour arrière | Sécurité, données, consentement et reprise | La sauvegarde, le point de restauration, le décideur et la procédure de rollback sont identifiés et testés selon le périmètre convenu. | Journal du test, durée et résultat observé. | Oui |
| Redirections | SEO, GEO et accès public | Chaque URL critique reçoit la décision validée et atteint directement sa destination finale sans chaîne évitable. | Matrice approuvée et crawl post-bascule. | Oui |
| Indexabilité | SEO, GEO et accès public | Les pages à indexer répondent en 200, exposent la canonique attendue et ne conservent aucun blocage de préproduction. | HTML final, en-têtes HTTP et test d’URL. | Oui |
| Robots et IA | SEO, GEO et accès public | robots.txt, CDN et pare-feu appliquent la politique décidée à Googlebot, Bingbot et OAI-SearchBot sur les pages publiques. | Requêtes avec user-agent et réponses finales. | Conditionnel |
| Données structurées | SEO, GEO et accès public | Le JSON-LD est valide, cohérent avec le contenu visible et ne référence pas des ressources absentes. | Validation, extraction du graphe et contrôle humain. | Conditionnel |
| Mesure | Mesure et attribution | Les événements déclarés critiques remontent une seule fois avec les paramètres attendus et respectent le choix de consentement. | Débogueur analytics et événement visible. | Conditionnel |
| Administration | Contenus, navigation et administration | Un éditeur autorisé peut créer, prévisualiser, corriger et publier un contenu représentatif sans intervention technique. | Test utilisateur et contenu publié puis restauré. | Conditionnel |
Deux environnements, deux preuves
Une recette en préproduction ne prouve pas le comportement de la destination finale.
| En préproduction | À rejouer obligatoirement en production | Pourquoi |
|---|---|---|
| Gabarits, contenus, composants, rôles, erreurs, responsive et scénarios métier avec données de test. | DNS, TLS, cache, CDN, pare-feu, réponses HTTP, redirections et domaine canonique. | Ces couches dépendent de l’infrastructure finale. |
| Plan de marquage, consentement simulé et événements en mode debug. | Traceurs réels, domaines tiers, déduplication et réception dans la propriété de production. | Les identifiants et politiques peuvent différer. |
| robots.txt et métadonnées prévues. | Absence de noindex résiduel, politique robots finale, sitemap public et accès des crawlers autorisés. | Un blocage de staging est parfois déployé avec le site. |
| Tests de charge ciblés et mesures laboratoire. | Temps de réponse, erreurs, cache froid/chaud et collecte future des données terrain. | Le trafic, le réseau et l’infrastructure changent le résultat. |
Une capture sans URL, heure, environnement, profil, données de test ou résultat cible documente rarement assez pour rejouer le contrôle.
Scénarios de rupture
Trois scénarios de no-go doivent être rejoués sur la destination finale.
Dans la méthode Edikka, ces scénarios sont vérifiés après la bascule technique, car une préproduction fonctionnelle ne démontre pas le comportement du domaine final. Ils ne sont pas présentés comme les incidents les plus fréquents : nous ne publions pas encore de comptage consolidé permettant de l’affirmer.
| Scénario | Observation trompeuse | Preuve à conserver | Décision |
|---|---|---|---|
| Blocage de préproduction résiduel | La page s’affiche dans un navigateur déjà autorisé, mais conserve un noindex, une authentification ou un filtrage des robots. | HTML et réponse finale datés, puis requêtes avec les user-agents autorisés à travers le CDN et le pare-feu. | NO-GO pour les pages destinées à être publiques. |
| Confirmation de formulaire sans donnée créée | L’interface affiche un succès, mais aucune demande exploitable n’apparaît dans le CRM ou le système cible. | Envoi horodaté, identifiant de test, enregistrement cible et notifications reçues. | NO-GO lorsqu’il s’agit d’un parcours métier critique. |
| Traceur actif avant le choix | La bannière est visible, mais un traceur soumis au consentement est déjà appelé, lu ou déposé. | Inspection réseau et stockage avant choix, après refus, après acceptation puis après retrait. | NO-GO lorsque le traceur exige un consentement préalable. |
Vocabulaire contrôlé
Séparer le résultat observé, la sévérité et la décision évite les arbitrages cachés.
| Dimension | Valeurs autorisées | Règle |
|---|---|---|
| Statut du test | Réussi · Échoué · Non applicable · Non testé | « Non testé » ne peut jamais être interprété comme réussi. « Non applicable » exige une justification. |
| Sévérité | Critique · Majeure · Mineure | La sévérité décrit l’impact de l’anomalie ; elle ne remplace pas la règle de blocage convenue. |
| Blocage | Oui · Non · Conditionnel | La condition figure dans le critère d’acceptation, pas dans un statut libre. |
| Décision | GO · NO-GO · GO sous réserves | Toute réserve contient un propriétaire, une échéance, une preuve de correction attendue et un acceptant. |
La matrice calcule une alerte à partir des statuts et règles de blocage, mais elle ne remplace pas la signature des décideurs. Un contrôle « Conditionnel » requiert un arbitrage explicite ; il ne doit pas devenir une voie automatique vers le go.
Processus de recette
Sept passages transforment la checklist en décision traçable.
Figer
Nommer la version testée et le périmètre de la recette.
Build, date, environnement, gabarits, parcours, langues, navigateurs, appareils, comptes et données de test.
Attribuer
Séparer exécution, correction, acceptation et décision.
Une même personne peut cumuler des rôles, mais chaque responsabilité reste visible.
Préparer
Créer les données et conditions qui rendent le scénario rejouable.
Profils, consentements, états d’erreur, contenus, emails, enregistrements cibles et résultat attendu.
Tester
Exécuter le scénario sans modifier le critère après observation.
Le résultat, l’environnement et la preuve sont saisis au moment du test.
Qualifier
Distinguer échec, sévérité, blocage et responsabilité.
Un ticket relie l’anomalie à sa ligne de recette et conserve la décision prise.
Contre-tester
Rejouer le contrôle après correction et vérifier les effets de bord.
Une anomalie corrigée n’est close qu’après observation du résultat attendu.
Décider
Signer le go, le no-go ou les réserves avant la bascule.
La décision nomme les portes ouvertes, les réserves, les responsables, le rollback et la fenêtre de surveillance.
Procès-verbal et réserves
Le procès-verbal ne remplace pas les preuves : il en synthétise l’état au moment de décider.
Une décision exploitable contient la version livrée, les environnements, la période de test, les participants, les contrôles non applicables, les échecs ouverts, les trois portes, les réserves acceptées, la fenêtre de mise en ligne, la procédure de retour arrière et les signataires autorisés.
| Élément | Question de contrôle | Signal d’arrêt |
|---|---|---|
| Impact | L’effet sur les utilisateurs, les données, la visibilité et l’exploitation est-il décrit ? | « Faible » sans scénario ni périmètre. |
| Responsable | Une personne peut-elle engager la correction et rendre la preuve ? | « Agence » ou « client » sans nom ni rôle. |
| Échéance | La date est-elle compatible avec le risque et la période de surveillance ? | « Après lancement » sans date. |
| Contre-test | Le résultat attendu et la personne qui l’acceptera sont-ils connus ? | Ticket fermé sur déclaration du correcteur. |
J+1, J+7 et J+30
La mise en ligne termine la recette de bascule, pas l’observation du site réel.
| Échéance | Contrôles prioritaires | Décision associée |
|---|---|---|
| J+1 | Erreurs serveur, formulaires réels, emails, CRM, consentement, analytics, redirections critiques, indexabilité, sitemap, cache et sauvegarde. | Corriger immédiatement ou déclencher le rollback prévu. |
| J+7 | Logs, 404, chaînes de redirection, événements, recherche interne, retours des équipes, couverture d’indexation et réserves ouvertes. | Prioriser les écarts réels et fermer les réserves contre-testées. |
| J+30 | Données terrain disponibles, conversions comparables, requêtes et pages, stabilité, incidents, coûts d’exploitation et tâches éditoriales. | Comparer à l’état de référence sans attribuer automatiquement les évolutions à la refonte. |
Ressource ouverte
Télécharger la matrice XLSX de recette et de décision go/no-go.
Le classeur contient un mode d’emploi, une matrice préremplie, une synthèse sans score global, les contrôles post-lancement, les vocabulaires contrôlés et les sources officielles. Les formules signalent les portes bloquantes échouées ou non testées ; elles ne signent pas la décision à la place du projet.
Matrice de recette de site web avant mise en ligne
Contrôles, critères, preuves, responsables, sévérités, statuts, blocage, réserves et suivi J+1 à J+30.
La matrice et sa version Markdown publique sont proposées sous licence Creative Commons Attribution 4.0 International. Attribution demandée : Edikka, avec un lien vers cette page canonique.
Limite volontaire
Cette matrice ne certifie ni la conformité, ni la sécurité, ni la performance d’un site.
Edikka est une agence de refonte : cette ressource décrit une méthode que nous utilisons et n’est pas un référentiel indépendant. Elle ne remplace pas le contrat, un audit RGAA, une validation juridique, un test d’intrusion, l’ASVS complet, une analyse de risques ou les critères spécifiques du projet.
Les seuils de performance, navigateurs, appareils, parcours, obligations et règles de blocage doivent être définis avant le test. La réussite d’une recette prouve seulement que les contrôles documentés ont obtenu les résultats consignés dans les conditions indiquées.
Sources officielles
Références utilisées pour construire les familles de contrôle.
- W3C · Web Content Accessibility Guidelines 2.2 — critères testables et évaluation automatisée complétée par des vérifications humaines.
- DINUM · RGAA 4.1.2 — référentiel français d’évaluation de l’accessibilité numérique en vigueur à la date de préparation.
- Google Search Central · Site moves and migrations — mapping, redirections directes, liens internes, sitemaps et suivi de migration.
- web.dev · Core Web Vitals thresholds — LCP, INP et CLS, seuils et lecture au 75e percentile des visites.
- CNIL · Cookies et traceurs : que dit la loi ? — consentement préalable, choix réel et retrait.
- OWASP · Application Security Verification Standard 5.0 — base ouverte pour spécifier et vérifier les contrôles techniques de sécurité.
- OpenAI · Publishers and Developers FAQ — accès d’OAI-SearchBot aux contenus publics et suivi du trafic de référence.
Sources consultées le 14 août 2026. Les référentiels, versions et politiques doivent être revérifiés à chaque projet.
Conclusion
La qualité d’une recette se mesure à la décision qu’elle permet de justifier.
Un site prêt à être lancé ne possède pas nécessairement zéro anomalie. Il possède un périmètre connu, des portes critiques ouvertes, des preuves consultables, des réserves acceptées et un retour arrière préparé. C’est cette discipline qui transforme une mise en ligne en décision contrôlable.
Position Edikka
Une mise en ligne se décide avec des portes critiques, pas avec une moyenne.
Le contrôle devient utile lorsque le résultat attendu, la preuve, la responsabilité et la règle de blocage sont connus avant le test.
Rejouer un résultat attendu
Chaque scénario part de conditions connues et produit un résultat observable.
Conserver une trace contestable
URL, environnement, heure, profil et preuve rendent le contrôle rejouable.
Signer le go ou le no-go
Les portes critiques et réserves attribuées rendent l’arbitrage explicite.
Pour aller plus loin sur ce sujet
Des réponses complémentaires pour clarifier les points essentiels abordés dans cet article.
