Convenir du périmètre et de la personne qui décide
Commencez par le brief approuvé, l’identifiant de version, l’environnement de destination et les URL remplacées. Nommez l’approbateur client, l’opérateur de publication de l’agence et un remplaçant pour chacun. Convenez de leurs disponibilités et du canal de communication qui portera la décision.
Préparez une boîte de réception de test contrôlée, des données de formulaire synthétiques, des comptes de test autorisés et un dossier de preuves à accès restreint. Décidez quels contrôles ont lieu en répétition et lesquels nécessitent la destination réelle. Fixez avant les tests un seuil bloquant le lancement : par exemple, des demandes manquantes, un accès administrateur cassé ou des différences de données inexpliquées exigent un refus.
Rédiger une petite grille de résultats observables
Utilisez une ligne par test, avec un identifiant stable. Séparez les lignes lorsque différentes personnes ou preuves sont nécessaires. Les exemples ci-dessous sont des critères à adapter, pas un dossier d’acceptation complété. Ajoutez des colonnes testeur, résultat réel, référence de preuve et décision de l’approbateur à la copie de travail.
Faites défiler horizontalement pour toutes les colonnes du tableau.
| Domaine | Résultat attendu | Preuves utiles |
|---|---|---|
| Formulaires | Une demande synthétique atteint une fois la destination convenue ; une saisie invalide reçoit une explication utilisable. | Référence de soumission et reçu expurgé. |
| Redirections | Chaque ancienne URL convenue atteint son remplacement prévu sans boucle. | URL source, chaîne de statuts et URL finale. |
| Accès | L’éditeur client peut publier dans le périmètre ; l’administration restreinte reste indisponible. | Notes de test spécifiques au rôle. |
| Tâches planifiées | L’hôte prévu exécute la tâche à l’heure convenue et produit la sortie attendue. | Enregistrement du planificateur et référence de sortie. |
| Données | Les enregistrements, envois et relations convenus survivent au déplacement. | Feuille de comparaison et contrôles fonctionnels sélectionnés. |
| Approbation | L’approbateur désigné consigne les exceptions acceptées, refusées ou explicitement acceptées. | Décision liée à la version testée. |
Suivre un formulaire au-delà de son message de réussite
Testez une soumission vide, une saisie invalide et une demande synthétique valide. Utilisez le clavier pour atteindre les champs, comprendre leurs libellés, corriger les erreurs et soumettre. Les conseils du W3C sur les formulaires expliquent que les champs obligatoires doivent être clairement identifiés et que la validation du navigateur ne remplace pas la validation côté serveur. Incluez les deux dans le périmètre de test du développeur.
Vérifiez ensuite le résultat en aval convenu avec son responsable. Un simple message de réussite dans le navigateur ne prouve pas la réception dans une boîte de réception ou un CRM. Confirmez les valeurs des champs, la destination et la gestion des doublons. Gardez les données personnelles hors des captures d’écran. Répétez une tâche appropriée en tant qu’éditeur client et vérifiez qu’une opération restreinte est refusée.
Vérifier le parcours, pas seulement la page de destination
Convenez d’une liste d’URL anciennes à nouvelles, y compris les liens de campagne importants et les paramètres de requête requis. Enregistrez la chaîne de statuts HTTP ainsi que la page atteinte. MDN distingue les redirections permanentes et temporaires et documente les différences dans la manière dont les codes de redirection traitent les méthodes de requête. Une soumission de formulaire redirigée nécessite donc son propre test ; ouvrir la destination avec une requête de page normale ne suffit pas.
Refusez les boucles, les domaines inattendus et les destinations manquantes. Évitez de placer des chaînes de requête confidentielles dans les preuves.
Donner aux traitements en arrière-plan et aux données leurs propres contrôles
Pour chaque tâche planifiée, consignez son objectif, son hôte, son identité d’exécution, son fuseau horaire, sa planification, sa sortie attendue et la personne qui reçoit les échecs. Pendant la répétition, redirigez les messages sortants vers une destination contrôlée. Établissez quand l’ancien hôte cesse d’exécuter la tâche et quand le nouvel hôte devient responsable, afin qu’une migration ne laisse pas deux planificateurs actifs.
Définissez la date limite des données et comparez les totaux d’enregistrements convenus, les valeurs de champs sélectionnées et les fichiers téléversés. Ouvrez des enregistrements représentatifs via l’application pour vérifier les relations et les permissions. Les totaux seuls ne suffisent pas : des totaux égaux peuvent contenir des enregistrements différents. Consignez toute donnée historique délibérément exclue et obtenez la décision du client.
Exemple : un lancement de catalogue qui doit attendre
Dans ce scénario fictif, une agence déplace le catalogue et le formulaire de demande d’un atelier. L’approbateur client accepte les contrôles de contenu et de redirection, mais une demande synthétique atteint une boîte aux lettres obsolète. L’import nocturne du catalogue reste aussi activé sur l’ancien hôte. Le résultat est refusé pour le lancement, les deux échecs étant attribués à l’opérateur de publication.
L’opérateur corrige le destinataire et la propriété du planificateur, puis fournit de nouvelles preuves pour ces lignes et répète les contrôles de formulaire et de données concernés. L’approbateur examine le même identifiant de version avant de modifier la décision. Un recadrage d’image mineur peut rester une exception explicite avec un responsable et une échéance si le client est d’accord ; le silence ne vaut pas acceptation.
Vérifier la décision et garder ses limites visibles
Avant de clore, confirmez que chaque ligne requise a un résultat, que chaque ligne échouée a une résolution ou une exception consignée, et que la décision de l’approbateur identifie la version et l’heure. Si la construction ou la configuration change ensuite, rouvrez les contrôles concernés. Stockez des preuves concises avec une période de conservation convenue et gardez les détails d’accès dans les systèmes sécurisés de l’équipe.
Cette liste de contrôle établit l’acceptation du projet dans son périmètre déclaré. Elle n’établit pas la conformité d’accessibilité, l’assurance de sécurité ni la disponibilité future. Organisez une revue spécialisée lorsque le projet l’exige. Ensuite, reportez la version acceptée, les exceptions ouvertes et les opérateurs nommés dans le registre de responsabilité continue.
Sources et révision
Les références techniques ont été vérifiées en septembre 12, 2026. Les exemples sont des exercices de planification ; la documentation logicielle citée n'établit pas les capacités de service PrivateHostLab.