Cahier de recette d’un site web : scénarios, preuves et décision

Ce que la recette permet de décider

La recette d’un site web consiste à rapprocher un périmètre convenu d’observations vérifiables avant d’accepter sa remise. Elle ne se réduit pas à une liste « responsive, SEO, formulaire ». Il faut savoir quelle version a été contrôlée, quel résultat était attendu, ce qui a été réellement observé et qui peut décider de la suite.

Ce guide fournit un registre en dix rubriques et six scénarios complets. Ils prennent pour exemple une entreprise fictive qui prépare un site de présentation Webflow avec des offres, des réalisations autorisées, des ressources CMS et un contact. Aucune des vérifications décrites n’a été exécutée pour un client : les fiches définissent les contrôles à mener, avec le statut « non testé ».

Relier chaque contrôle à une exigence convenue

Le cahier des charges du site définit le besoin et les responsabilités. La recette vérifie des conditions observables issues de ce cadrage. Si une nouvelle fonction apparaît pendant la recette, elle peut constituer une évolution de périmètre ; elle n’est pas automatiquement un défaut de la réalisation.

Une exigence comme « recevoir une demande exploitable à la destination choisie » doit préciser ce qu’exploitable signifie, les informations nécessaires et qui en contrôle la réception. À l’inverse, « le site doit être performant » ne fournit pas à lui seul un critère de décision.

Nommer l’environnement et la version

Une maquette, une prévisualisation, un sous-domaine de test et le domaine public ne donnent pas les mêmes preuves. Des scripts, destinations, contenus ou paramètres peuvent différer. Nommez la version exacte et ce qui est activé pour votre contrôle ; ne présentez pas un succès de prévisualisation comme preuve de réception publique.

La documentation du sous-domaine de staging Webflow explique cet environnement de publication. Il doit être distingué du domaine public du projet. La publication et les contrôles publics restent des décisions et actions séparées de la préparation d’un cahier de recette.

Les dix rubriques du registre d’acceptation

Une fiche textuelle suffit si ses dix rubriques restent complètes et faciles à rapprocher. Vous pouvez reprendre les libellés suivants dans votre outil de projet ; aucun téléchargement ou tableur n’est nécessaire pour utiliser les exemples fournis ici.

1. Identifiant

Donnez une référence stable au contrôle, comme REC-02. Utilisez-la pour relier observation, anomalie, correction et recontrôle sans confondre plusieurs parcours.

2. Exigence d’origine

Indiquez le besoin convenu et sa référence dans le cadrage. Si ce besoin n’est pas défini, consignez la décision manquante au lieu de rédiger après coup un critère qui justifie le résultat obtenu.

3. Périmètre et version

Nommez pages, fonctions, langue si nécessaire, environnement et version. Un contrôle sur un brouillon ou un environnement de test ne prouve pas la version publique.

4. Préconditions

Précisez les données, droits, appareils ou configurations nécessaires. Un destinataire de test, une preuve autorisée ou un contenu CMS long peuvent changer le sens du résultat.

5. Étapes

Décrivez les actions dans l’ordre pour qu’une autre personne puisse reprendre le contrôle. Une action qui envoie, modifie ou publie exige le périmètre et l’autorisation adaptés ; la présence dans une fiche n’est pas cette autorisation.

6. Résultat attendu

Écrivez ce qui doit être observé, avec les limites du contrôle. « Atteindre Contact » et « recevoir une demande » sont deux attendus différents.

7. Preuve ou absence de preuve

Conservez une référence de capture, relevé ou reçu pertinent, sans exposer de secret ni de donnée personnelle. Si la preuve manque, dites-le : un attendu n’est pas une observation.

8. Statut et réserve

Utilisez des états distincts : satisfait, non satisfait, non testé, non applicable ou réserve à arbitrer. Un « non applicable » doit être justifié ; une réserve indique le risque ou la décision encore nécessaire.

9. Responsable de correction

Désignez le rôle qui peut examiner ou corriger l’écart. Le responsable du contenu, l’intégrateur et le responsable de la destination d’un formulaire n’ont pas les mêmes moyens d’action.

10. Clôture et décideur

Précisez le recontrôle attendu et la personne qui accepte la clôture ou la remise sous réserve. Une mention « corrigé » sans preuve rapprochée ne remplace pas cette décision.

Six scénarios remplis pour un site de présentation

Le cas fictif utilise la version de test V3 d’un site avec trois offres, un CMS de ressources et un contact. Les fonctions et règles décrites sont des exigences pédagogiques, pas des caractéristiques vérifiées du site Gemme Studio. Les dix rubriques sont renseignées dans chaque fiche ; la preuve reste explicitement à produire lors d’un futur contrôle autorisé.

REC-01 — Comprendre une offre, examiner une preuve puis contacter

1. Identifiant : REC-01. 2. Exigence : depuis une ressource, un acheteur doit trouver l’offre Diagnostic, en comprendre le périmètre et rejoindre un contact adapté. Référence fictive CAD-01.

3. Périmètre et version : ressource, page Diagnostic, réalisation autorisée et Contact, environnement de test V3. 4. Préconditions : contenus de ces pages validés dans le cas, réalisation autorisée et chemins de navigation disponibles ; aucune soumission nécessaire.

5. Étapes : entrer sur la ressource ; rejoindre Diagnostic ; identifier livrable et exclusions ; ouvrir la preuve annoncée ; rejoindre Contact. 6. Attendu : les destinations correspondent aux libellés, la preuve est accessible et la page Contact explique la suite. Le parcours ne démontre pas la réception d’une demande.

7. Preuve : relevé de version, chemins, textes et destinations à produire. 8. Statut et réserve : non testé ; la disponibilité d’une preuve non encore autorisée serait une réserve de contenu, pas un succès de navigation.

9. Responsable : responsable de contenu pour périmètre et preuves ; intégrateur pour une destination erronée. 10. Clôture et décideur : reprendre le parcours sur la version corrigée et rapprocher les preuves ; responsable de projet décide si le contenu et le chemin répondent à CAD-01.

REC-02 — Recevoir une demande et traiter une erreur de saisie

1. Identifiant : REC-02. 2. Exigence : une demande complète atteint la destination convenue avec les informations prévues ; une erreur de saisie permet une correction compréhensible. Référence fictive CAD-02.

3. Périmètre et version : formulaire Contact V3 et destination de test identifiée par son responsable ; aucune conclusion sur le domaine public. 4. Préconditions : autorisation explicite d’envoi, données synthétiques, destinataire de test et effets prévus sur un éventuel contact connu ; ces conditions ne sont pas acquises par la lecture de cet article.

5. Étapes : ouvrir Contact ; utiliser un cas complet synthétique autorisé ; comparer navigateur, traitement choisi et destination ; reprendre un cas de saisie invalide autorisé ; examiner l’erreur et le retour vers une saisie correcte. Avant toute répétition, vérifier les effets du premier envoi. 6. Attendu : données et destination correspondent au cadrage ; l’erreur est compréhensible et n’est pas présentée comme un succès ; la qualification commerciale reste hors contrôle.

7. Preuve : références anonymisées des traces, version, heure et relevé du cas invalide à produire ; aucun envoi réel n’est décrit ici. 8. Statut et réserve : non testé ; réception, notification et cas de contact connu restent à vérifier séparément.

9. Responsable : intégrateur pour le parcours ; responsable du traitement ou du CRM pour les données reçues ; responsable messagerie pour une notification. 10. Clôture et décideur : rapprochement des traces et du cas d’erreur après correction ; responsable du parcours de demande accepte le résultat ou attribue une réserve.

Si la demande manque, isoler une rupture dans le parcours de demande évite de modifier plusieurs outils avant d’avoir identifié la dernière trace disponible.

REC-03 — Afficher un contenu CMS long et un champ facultatif vide

1. Identifiant : REC-03. 2. Exigence : les ressources prévues au CMS restent lisibles avec titres longs, corps complet et champ de crédit facultatif vide. Le cadrage fictif prévoit de ne pas afficher un crédit vide. Référence CAD-03.

3. Périmètre et version : ressource de test V3 et sa carte, sans publication d’un contenu réel. 4. Préconditions : données de test autorisées avec un titre long, plusieurs sections, une séquence numérotée, un lien et une fin identifiable ; crédit laissé vide selon le cas.

5. Étapes : ouvrir la carte puis l’article ; comparer titre et synthèse ; parcourir début, sections et fin ; vérifier la séquence, le lien et l’espace du crédit ; refaire sur la largeur étroite choisie et relevée. 6. Attendu : le contenu est entier, les éléments lisibles et la présentation vide respecte la décision de CAD-03. Une valeur sauvegardée ne suffit pas si le rendu la coupe.

7. Preuve : référence du contenu, relevé de valeurs et captures des zones à produire ; aucune carte réelle n’est certifiée ici. 8. Statut et réserve : non testé ; distinguer une donnée absente, une séquence tronquée et un problème d’affichage.

9. Responsable : responsable de contenu pour les valeurs ; intégrateur pour la présentation ou le binding. 10. Clôture et décideur : comparer de nouveau le contenu entier et les zones corrigées ; responsable éditorial puis responsable de projet valident la portée de la clôture.

REC-04 — Naviguer sur petit écran et au clavier

1. Identifiant : REC-04. 2. Exigence : atteindre une offre, sa preuve et Contact avec les commandes retenues, sans perte de repère. Référence fictive CAD-04.

3. Périmètre et version : menu et pages du parcours V3 ; écran large puis largeur étroite réellement relevée lors du contrôle. 4. Préconditions : parcours choisi, commandes d’ouverture/fermeture définies et contenus longs disponibles ; aucun outil n’est supposé démontrer à lui seul une conformité.

5. Étapes : partir d’une page profonde ; identifier la position ; ouvrir le menu si nécessaire ; atteindre l’offre puis la preuve et Contact ; revenir ; refaire au clavier et sur petit écran en observant focus, fermeture et défilement. 6. Attendu : les contrôles restent utilisables, les destinations cohérentes et les textes non masqués par le panneau ou un chevauchement.

7. Preuve : version, dimensions, mode de commande, captures utiles et relevé des difficultés à produire. 8. Statut et réserve : non testé ; couverture limitée à ces tâches et variantes, sans conclusion générale d’accessibilité.

9. Responsable : intégrateur pour le comportement ; responsable de contenu pour un libellé ambigu. 10. Clôture et décideur : reprendre le parcours et les variantes qui avaient échoué ; responsable de projet accepte les résultats dans le périmètre retenu.

Le guide aide à vérifier les décisions du menu. Pour approfondir les contrôles manuels de parcours, utilisez la méthode spécialisée et ses limites ; cette fiche n’est pas un audit de conformité.

REC-05 — Rapprocher les destinations et anciennes URL concernées

1. Identifiant : REC-05. 2. Exigence : les liens mènent aux destinations convenues ; les anciennes URL et langues sont contrôlées seulement lorsqu’elles font partie du projet. Référence fictive CAD-05.

3. Périmètre et version : liens de V3 ; liste d’anciennes URL et variantes de langue du cadrage, si elle existe. Le comportement du domaine public est un contrôle distinct après une publication autorisée. 4. Préconditions : destinations décidées, tableau de correspondance et règles de langue disponibles pour la partie applicable. Une création sans anciennes URL peut justifier un « non applicable » pour cette seule partie.

5. Étapes : relever les liens des parcours retenus ; comparer leurs destinations ; identifier les changements d’URL concernés ; rapprocher chaque cas de la décision existante ; réserver au bon environnement les vérifications qui exigent le domaine public. 6. Attendu : aucune destination erronée dans la couverture choisie ; chaque exception ou contrôle public restant est identifié. Aucun déplacement d’URL n’est décidé par cette fiche.

7. Preuve : sources, destinations, réponses et environnement à produire ; la préparation d’une correspondance ne prouve pas son application. 8. Statut et réserve : non testé ; langues non prévues hors périmètre ; anciennes URL à classer applicable ou non applicable sur le cadrage réel.

9. Responsable : personne chargée du contenu pour les destinations attendues ; responsable technique pour les mécanismes convenus. 10. Clôture et décideur : recontrôle des destinations et exceptions sur l’environnement approprié ; responsable de projet accepte la couverture et les suites publiques.

Lorsqu’une migration est effectivement prévue, le guide permet de vérifier le plan des anciennes URL. La recette rapproche les preuves ; elle ne remplace pas cette matrice et ne fournit aucune règle prête à importer.

REC-06 — Vérifier une tâche CMS et les informations de remise

1. Identifiant : REC-06. 2. Exigence : la personne responsable du contenu sait préparer une ressource dans les limites du CMS et retrouver les informations nécessaires à sa validation. Référence fictive CAD-06.

3. Périmètre et version : tâche CMS de test sur V3, sans publication ; droits adaptés attribués par le propriétaire dans un futur périmètre autorisé. 4. Préconditions : compte prévu, données synthétiques, documentation de la tâche et règle de validation ; aucun mot de passe transmis dans la fiche.

5. Étapes : retrouver le type de contenu ; préparer les champs de test autorisés ; relire le brouillon et sa carte lorsque disponible ; identifier qui valide et publie ; retrouver la procédure de signalement d’un problème. 6. Attendu : la tâche convenue et ses limites sont compréhensibles ; le responsable sait quand demander une intervention. Aucune autonomie sur toute la structure du site n’est promise.

7. Preuve : référence de la tâche, brouillon de test et points de documentation vérifiés à produire, sans secret ni donnée réelle. 8. Statut et réserve : non testé ; absence d’accès ou de documentation conservée comme contrôle non réalisé, sans créer un compte par défaut.

9. Responsable : propriétaire pour les droits ; intégrateur pour la structure livrée et ses repères ; responsable de contenu pour la règle de validation. 10. Clôture et décideur : reprendre la tâche autorisée et confirmer les informations de remise ; responsable de contenu puis responsable de projet acceptent la portée.

Traiter les réserves sans effacer les faits

Une réserve conserve la référence du contrôle, le fait observé, le résultat attendu, son effet sur la tâche, la personne chargée de la suite et le critère de clôture. Distinguez défaut confirmé, résultat incertain et évolution demandée. Ces situations peuvent avoir des responsables et des décisions différents.

Exemple de réserve fictive R-03 : dans une simulation pédagogique de REC-03, une liste attendue de quatre étapes n’en montre que trois sur la version examinée. Attendu : quatre étapes complètes. Effet : la procédure ne peut pas être suivie entièrement. Suite : l’intégrateur rapproche valeur stockée et rendu ; le responsable de contenu vérifie le texte. Clôture prévue : comparer les quatre étapes puis la fin d’article sur la version corrigée. Décideur : responsable éditorial pour le contenu, responsable de projet pour la remise. Cet écart illustratif n’est pas une observation du site Gemme Studio.

Après une correction, ajoutez un recontrôle lié à la même référence. Conservez le constat initial, la version corrigée, l’observation nouvelle et la décision ; ne transformez pas rétroactivement un « non testé » en « satisfait ». Si une preuve reste inaccessible, l’incertitude doit rester visible.

Décider la remise et les contrôles publics restants

Le responsable du projet rapproche les critères convenus, les résultats et les réserves. Il peut demander une correction, différer la décision ou accepter un périmètre avec des réserves explicitement attribuées. Ce qui est bloquant dépend du besoin réel et de l’accord du projet ; cet article ne fixe ni règle contractuelle universelle ni conclusion juridique.

La publication ne doit pas effacer les contrôles qui exigent le domaine public : destinations, version effectivement servie et réception configurée doivent être observées dans leur environnement pertinent. Une page en HTTP 200 ou une sauvegarde réussie ne démontrent pas l’intégrité du contenu ni les résultats d’un formulaire.

Si vous préparez un projet de présentation pour des acheteurs professionnels, Gemme Studio peut vous aider à cadrer la livraison d’un site B2B. Le périmètre doit préciser les contenus, les tâches et les responsabilités ; cette méthode ne crée pas une offre d’audit ou de certification supplémentaire.

Sources et limites

Les différences d’environnement et de traitement s’appuient sur la documentation Webflow du sous-domaine de staging et des soumissions de formulaire. Les dix rubriques, les six fiches et la réserve fictive sont développées ici comme méthode de préparation. Elles ne couvrent pas tous les risques d’un site : sécurité, conformité, performance ou besoins sectoriels peuvent demander des contrôles spécialisés distincts.