# Recette de site web avant mise en ligne : checklist, preuves et décision go/no-go

Publication prévue par Edikka le 18 août 2026.  
Page canonique : https://www.edikka.com/insights/developpement-web/recette-site-web-avant-mise-en-ligne  
Matrice XLSX : https://www.edikka.com/docbd/data/matrice-recette-site-web-avant-mise-en-ligne.xlsx  
Licence : Creative Commons Attribution 4.0 International — https://creativecommons.org/licenses/by/4.0/deed.fr  
URL de licence : https://creativecommons.org/licenses/by/4.0/

## 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 ligne exploitable contient au minimum :

1. le contrôle à exécuter ;
2. le critère d’acceptation observable ;
3. la preuve attendue ;
4. le responsable ;
5. le statut du test ;
6. la règle de blocage.

Un contrôle non testé n’est pas réussi. 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.

## Les six champs minimaux

| Champ | Question | 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 permet de rejouer ou contester le résultat ? | « Testé par l’agence » |
| Responsable | Qui exécute, corrige et accepte ? | « L’équipe projet » |
| Statut | Le contrôle 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 » |

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.

## Les sept familles de contrôle

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.

| 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.

Les trois nombres annoncés ne décrivent pas le même périmètre : **54** contrôles composent la matrice complète avant mise en ligne, **18** contrôles représentatifs sont détaillés dans l’article et **15** contrôles supplémentaires organisent le suivi à J+1, J+7 et J+30. Les 15 contrôles post-lancement ne sont pas inclus dans les 54.

## Trois portes go/no-go

### 1. Parcours métier

Une action utile doit aboutir du navigateur jusqu’au système cible : formulaire, devis, inscription, téléchargement, authentification, paiement ou candidature. Le succès, les erreurs, les notifications et les données créées sont contrôlés de bout en bout.

### 2. Sécurité, données et reprise

Le site ne doit pas divulguer ce qui doit rester protégé et doit pouvoir 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é.

### 3. Accès public et découvrabilité

Les humains et robots autorisés doivent atteindre la bonne version des contenus. Codes HTTP, redirections, canonicals, robots, sitemaps, données structurées, langues, liens et contenus publics sont contrôlés sur la destination finale, CDN et pare-feu compris.

Une moyenne ne peut pas compenser un formulaire qui perd les demandes, un traceur déclenché sans consentement ou un site entièrement en `noindex`.

## Matrice critique avant mise en ligne

Le caractère bloquant doit être décidé avant la recette selon les parcours, les obligations et les risques du projet.

| 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](https://www.edikka.com/insights/developpement-web/formulaire-accessible-erreurs-contacts-perdus) | 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](https://www.edikka.com/insights/developpement-web/audit-accessibilite-reel-tests-humains-outils) | 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](https://www.edikka.com/insights/developpement-web/audit-accessibilite-reel-tests-humains-outils) | 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 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 | Sauvegarde, point de restauration, décideur et 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 |

## Préproduction et production ne prouvent pas la même chose

| En préproduction | À rejouer 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. |

La preuve finale doit être datée et localisée : URL, heure, environnement, profil, données de test et résultat cible.

## Trois scénarios de no-go à rejouer

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 : Edikka ne publie 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é

| Dimension | Valeurs autorisées | Règle |
|---|---|---|
| Statut | **Réussi / Échoué / Non applicable / Non testé** | « Non testé » n’est jamais réussi. « Non applicable » exige une justification. |
| Sévérité | **Critique / Majeure / Mineure** | La sévérité décrit l’impact ; elle ne remplace pas le blocage convenu. |
| Blocage | **Oui / Non / Conditionnel** | La condition figure dans le critère d’acceptation, jamais 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 attendue et un acceptant. |

La matrice calcule une alerte, mais elle ne signe pas la décision à la place des responsables du projet.

## Processus en sept passages

1. **Figer** la version testée, l’environnement et le périmètre.
2. **Attribuer** l’exécution, la correction, l’acceptation et la décision.
3. **Préparer** les comptes, données, états d’erreur et résultats attendus.
4. **Tester** sans modifier le critère après avoir observé le résultat.
5. **Qualifier** séparément l’échec, la sévérité, le blocage et la responsabilité.
6. **Contre-tester** après correction et rechercher les effets de bord.
7. **Décider** du go, du no-go ou des réserves avant la bascule.

## Procès-verbal et réserves

Une décision exploitable contient :

- la version livrée et les environnements ;
- la période de test et les participants ;
- les contrôles non applicables ;
- les échecs ouverts et l’état des trois portes ;
- les réserves acceptées, avec responsable et date ;
- la fenêtre de mise en ligne ;
- la procédure de retour arrière ;
- les signataires autorisés.

Une réserve acceptable documente son impact, un responsable identifié, une échéance, le résultat attendu du contre-test et la personne autorisée à l’accepter.

## Contrôles post-lancement

| É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. | 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 et coûts d’exploitation. | Comparer à l’état de référence sans attribuer automatiquement les évolutions à la refonte. |

## Limite volontaire

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.

La matrice ne certifie ni la conformité, ni la sécurité, ni la performance d’un site. 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.

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.

## Licence et réutilisation

La matrice XLSX et cette version Markdown sont proposées sous licence Creative Commons Attribution 4.0 International. Elles peuvent être adaptées et redistribuées, y compris commercialement, à condition de créditer Edikka et de relier la page canonique de cet article.

## Sources officielles

Sources consultées le 14 août 2026.

- W3C, Web Content Accessibility Guidelines 2.2 : https://www.w3.org/TR/WCAG22/
- DINUM, RGAA 4.1.2 : https://accessibilite.numerique.gouv.fr/
- Google Search Central, Site moves and migrations : https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
- web.dev, Core Web Vitals thresholds : https://web.dev/articles/defining-core-web-vitals-thresholds
- CNIL, Cookies et traceurs : que dit la loi ? : https://www.cnil.fr/fr/cookies-et-autres-traceurs/que-dit-la-loi
- OWASP, Application Security Verification Standard 5.0 : https://owasp.org/www-project-application-security-verification-standard/
- OpenAI, Publishers and Developers FAQ : https://help.openai.com/en/articles/12627856-publishers-and-developers-faq

## Ressources Edikka

- Offre de refonte : https://www.edikka.com/refonte-site-internet
- Cahier des charges de refonte B2B : https://www.edikka.com/insights/strategie-digitale/cahier-des-charges-refonte-site-internet
- Protocole de migration SEO : https://www.edikka.com/insights/seo/migration-seo-refonte-site-internet