Définir la version et ses preuves
Commencez par une version nommée, un périmètre stable et les parcours critiques. Pour chaque parcours, décrivez conditions initiales, action, écritures attendues et résultat visible. Désignez une personne capable d’accepter les preuves au lieu d’une impression collective informelle. Identifiez comptes externes, accès fournisseurs, réseaux et dépendances commerciales nécessaires. Signalez explicitement ce qui manque. Une fonctionnalité qui fonctionne seulement avec la configuration privée du développeur ne démontre pas encore que l’équipe destinataire peut l’exploiter. Le dossier doit indiquer où retrouver les preuves et comment reproduire les contrôles.
Vérifier identité et permissions de bout en bout
Testez création de compte, vérification, connexion, récupération, expiration de session et retrait des accès. Couvrez clients, support, finance et administrateurs en essayant volontairement des actions interdites à chaque rôle. Si un fournisseur d’identité optionnel manque, son point d’entrée doit refléter cette indisponibilité. OWASP ASVS fournit une référence de critères explicites de vérification de la sécurité applicative. Ajoutez une revue adaptée à la réception fonctionnelle. Une connexion réussie ne prouve pas les droits corrects sur les exports, pièces jointes, fonctions internes ou requêtes directes au serveur.
Prouver le comportement lors des répétitions
Pour un paiement ou une opération d’actif, suivez demande, enregistrements durables, preuve externe, changements d’état et droits du client. Présentez deux fois le même événement, actualisez pendant le traitement, redémarrez un worker et retardez une réponse. Vérifiez l’absence de crédit ou de livraison en double. Traitez montants différents et actifs incompatibles par le parcours d’exception prévu. Rapprochez le registre final des événements acceptés. Conservez résultats attendus et observés. La réception doit expliquer aussi bien un travail interrompu qu’un succès simple, avec des références permettant de retrouver chaque cas.
Répéter la reprise avant d’en dépendre
Restaurez une sauvegarde dans un environnement isolé et vérifiez son utilisation par l’application. Une tâche de sauvegarde réussie ne démontre pas à elle seule la restauration. Testez surveillance, routage des alertes, panne fournisseur et retour documenté à une version fonctionnelle. Identifiez les changements non réversibles automatiquement, notamment après une transaction externe. Gardez des journaux utiles sans secrets ni données personnelles inutiles. Nommez le responsable de chaque alerte critique et donnez-lui les informations nécessaires pour agir sans deviner. Conservez les étapes réellement suivies pendant cette répétition.
Valider l’expérience publique
Parcourez le site publié sur téléphone et ordinateur, dans toutes les langues. Vérifiez navigation, formulaires, clavier, états vides, erreurs, titres, liens canoniques et pages publiques indexables. Mesurez la version réelle avec du contenu représentatif plutôt qu’une base vide. Contrôlez les limites d’accès et le comportement d’indexation des espaces privés et administratifs. Vérifiez la cohérence des prix, conditions de livraison, voies d’assistance et disponibilités entre catalogue et paiement. Un paiement techniquement réussi reste une mauvaise expérience si le client ne comprend pas ce qui lui sera livré ni selon quelles conditions.
Faire de la livraison un accord d’exploitation
Livrez instructions de déploiement, prérequis, migrations, tâches planifiées, responsabilités fournisseurs et limites connues. Demandez à un opérateur destinataire d’exécuter une tâche courante avec ces seuls documents. Classez les anomalies par impact et décidez lesquelles bloquent le lancement. Convenez de l’arrêt des nouvelles demandes, du traitement des opérations en cours et de la communication d’incident. L’approbation doit viser une version et ses preuves. Cette démarche ne promet pas une absence de risque ; elle rend la décision vérifiable et donne à l’équipe une base concrète pour exploiter le produit.