Recette d’un site internet avant mise en ligne : modèle de PV d’acceptation

Définir ce qui est recetté et sur quelle version

Référencez le devis, cahier des charges, maquettes et modifications acceptées. Notez environnement, adresse, version, date, navigateur, appareil, comptes et jeu de données. Sans cette empreinte, un résultat ne peut pas être reproduit. La recette porte sur un périmètre convenu, pas sur toutes les améliorations imaginables après livraison.

Séparez vérification du prestataire, recette utilisateur et contrôles après mise en production. Les tests automatisés peuvent sécuriser les régressions ; les utilisateurs valident les parcours métier et la compréhension. Le PV final doit dire quelles couches ont été examinées et lesquelles restent hors périmètre.

Organisez une réunion de lancement de recette avec les testeurs. Montrez comment réinitialiser les données, joindre une preuve, signaler un blocage et distinguer une demande nouvelle d’un écart au référentiel. Geler temporairement les changements non urgents stabilise l’environnement. Sinon, une correction ou une publication de contenu peut invalider silencieusement les preuves déjà recueillies.

Conservez enfin la liste des comptes et rôles utilisés pendant les essais. Un parcours conforme avec un administrateur peut échouer pour le visiteur ou le contributeur réel. Les permissions font donc partie des préconditions, du résultat attendu et de la preuve attachée au cas de test.

Construire des scénarios avec résultats attendus

Une fiche de test contient identifiant, priorité, préconditions, données, étapes, résultat attendu et preuve. Écrivez les parcours complets : trouver une offre, envoyer une demande, recevoir la confirmation, vérifier la réception interne. Ajoutez erreurs et limites : champ invalide, pièce trop lourde, paiement refusé, contenu absent, ancienne URL ou réseau lent selon le site.

L’Adimeo rappelle que la recette se prépare dès les spécifications et qu’un test doit identifier cas d’usage, données et résultat attendu. Cette discipline transforme une impression en constat. Un bouton « fonctionne » seulement si l’action attendue aboutit et si ses effets sont vérifiés des deux côtés.

Séparez gravité et priorité. La gravité décrit l’effet reproductible sur le service ; la priorité tient compte de la date, d’une solution de contournement et du risque de correction. Définissez les niveaux avant les tests avec des exemples propres au projet. Une couleur imparfaite ne doit pas masquer un paiement perdu, mais un défaut visuel peut rester bloquant s’il empêche de lire ou d’agir.

Tester contenu, navigation, SEO et mesure

Contrôlez titles, H1, textes, médias, crédits, liens, canonical, robots, sitemap, statuts et redirections. Vérifiez qu’une page profonde est atteignable par un lien HTML. Pour une refonte, comparez l’inventaire des anciennes URL. Une page jolie mais noindexée ou une redirection vers un sujet différent constitue une anomalie fonctionnelle pour le projet.

Testez les conversions de bout en bout : formulaire soumis, message affiché, email reçu, donnée enregistrée et événement analytics déclenché selon le consentement. N’acceptez pas un clic comme preuve d’un lead. Vérifiez aussi les accès : domaine, Search Console, analytics, gestionnaire de balises et CMS doivent appartenir aux responsables convenus.

Recetter mobile, clavier et accessibilité

Choisissez des appareils et navigateurs cohérents avec le public. Testez plusieurs largeurs, zoom, orientation, clavier, focus, menus, modales, formulaires et messages d’erreur. Le RGAA fournit une méthode de critères et tests ; son environnement rappelle que les combinaisons de technologies doivent suivre le contexte réel. Ne revendiquez pas une conformité globale sans audit du périmètre requis.

Conservez des captures ou vidéos courtes pour les défauts visuels et l’URL exacte. Les tests automatisés détectent certaines erreurs, mais pas une hiérarchie incompréhensible ni un piège de parcours. Une inspection humaine contradictoire reste nécessaire sur les modèles critiques.

Vérifier sécurité, données de test et mise en production

La CNIL recommande de tester les applications avant et après production et d’éviter d’exposer inutilement des données personnelles dans les environnements de test. Vérifiez comptes administrateurs, HTTPS, secrets, sauvegarde, restauration, formulaires, permissions, journaux et procédure d’incident selon les risques. Un scan automatique ne remplace pas une revue des accès et scénarios.

Préparez un plan de mise en ligne : sauvegarde, bascule, contrôle DNS, cache, formulaires, robots, monitoring et retour arrière. Attribuez chaque action et son signal d’arrêt. La décision d’ouvrir au public doit être distincte de la signature d’un PV provisoire si des réserves importantes subsistent.

Testez au moins une restauration dans l’environnement approprié au lieu de considérer l’existence d’une sauvegarde comme une preuve suffisante. Notez la dernière sauvegarde exploitable, le responsable, les étapes et les dépendances externes. Faites de même pour le retour arrière : son seuil de déclenchement doit être décidé avant l’incident, lorsque l’équipe peut encore arbitrer sereinement.

Outil 1 — cahier de recette prêt à copier

Créez un tableau : ID, zone, priorité, précondition, données, étapes, attendu, observé, preuve, statut, ticket, responsable et retest. Utilisez des statuts limités : non testé, conforme, anomalie, bloqué, non applicable. Une anomalie reçoit une gravité séparée de sa priorité de correction ; cela évite qu’un détail visible masque un parcours cassé.

Le résultat est un registre reproductible. Filtrez les tests critiques avant toute mise en ligne et conservez les non-applicables justifiés. Après correction, relancez le scénario touché puis un échantillon de régression. Ne remplacez jamais « attendu » par une appréciation comme « semble correct ».

Scénario fictif : accepter sous réserves ou refuser

Entrées fictives : site B2B de quinze pages, formulaire connecté au CRM et migration de trente anciennes URL. Les textes, navigation et mobile passent. Deux redirections mènent vers l’accueil, le message de succès s’affiche sans créer le lead et une image secondaire est mal recadrée. Le raisonnement classe les deux premiers défauts bloquants pour visibilité et conversion ; l’image reste mineure.

Résultat : refus de mise en ligne tant que redirections et réception CRM ne sont pas corrigées et retestées ; l’image peut devenir réserve datée si le support reste compréhensible. Limites : les nombres et défauts sont fictifs. Le contrat réel définit les critères, et une question juridique sur la réception doit être validée par le conseil compétent.

Rédiger le PV et organiser la levée des réserves

Le PV identifie parties, projet, version, documents de référence, période de test, environnement, synthèse, anomalies, réserves et décision. Chaque réserve indique effet, correction attendue, responsable, échéance et preuve de levée. Les signatures confirment ce qui est accepté, pas une satisfaction abstraite. Le Village de la Justice souligne que la simple mise en ligne ne suffit pas à prouver l’acceptation d’une recette.

Prévoyez un PV provisoire si le contrat l’autorise, puis une levée de réserves documentée. Après production, exécutez une vérification courte sur domaine public : HTTPS, pages clés, formulaires, mesure, robots et erreurs. Archivez preuves et version ; elles servent à distinguer défaut de livraison et évolution ultérieure.

Attribuez la surveillance des premières heures et la procédure de signalement : journaux, erreurs serveur, conversions, messages reçus et pages stratégiques. Le contrôle public ne répète pas toute la recette ; il vérifie les points que la bascule peut modifier. Une anomalie découverte alors rejoint le même registre, avec version, preuve, décision et retest traçables.