Corthex · Atelier de lancement / validation
Avant le lancement, montrez ce qui a réellement réussi.
Une bonne réponse en aperçu constitue une observation. Avant le lancement, il faut aussi vérifier l’identité sur la vraie boutique, les outils indisponibles, les sources modifiées et la capacité de l’équipe à assurer le suivi.
Utilisez l’atelier pour consigner vos tests. Il conserve échecs et cas non testés au lieu de transformer une liste non vérifiée en certificat de lancement.
Séparez la répétition du test réel.
Préparer un environnement délimité
Choisissez une boutique ou une page de test contrôlée, des clients et commandes fictifs, des règles validées et un responsable de vérification. Consignez l’assistant, la version de l’extension ou du module et les réglages concernés. Définissez les actions autorisées avant de commencer. N’utilisez pas une commande client réelle au seul motif qu’elle est pratique et n’effectuez ni paiement ni envoi à un vrai client pour une vérification de démonstration.
Écrivez le résultat attendu avant de poser la question
Pour chaque question, indiquez la source ou l’outil à utiliser, les faits pouvant être divulgués et l’action devant rester indisponible. Un refus attendu est une véritable réussite de test. Une réponse soignée qui révèle les données d’un autre client échoue, même si l’explication produit est juste. Définissez les limites critiques avant d’examiner les réponses pour ne pas confondre assurance et exactitude.
Consignez le résultat et ses limites
Conservez une capture expurgée, un résultat d’outil ou une référence de rapport avec le résultat attendu. Une simulation locale illustre une règle de décision ; elle ne prouve pas la bonne association de la boutique réelle. Un aperçu des connaissances dans le tableau de bord ne prouve pas l’accès authentifié aux commandes. Un vrai test doit utiliser le même point d’entrée, le même rôle client et le même parcours de connexion que le visiteur. Notez le type de preuve recueillie.
Consignez aussi les cas difficiles.
Une note de preuve est nécessaire pour qu’un test marqué réussi constitue une vérification complète enregistrée. Cette page ne teste ni ne modifie automatiquement votre installation.
Bilan déclaratif. Cette fiche n’exécute aucun test IA, boutique ou sécurité. Les saisies restent dans cet onglet ; téléchargez-les pour les conserver. Utilisez des preuves fictives ou expurgées, jamais d’identifiants secrets ni de dossiers clients privés.
Gardez visibles les cas non résolus et non testés. Une réussite sans preuve n’est pas une vérification terminée.
Choisissez des critères d’arrêt que vous respecterez.
Arrêtez le déploiement si un test franchit le périmètre d’un client, invente un statut de commande, annonce une modification non effectuée ou promet une réponse humaine indisponible. Ces constats nécessitent un responsable et une correction, pas une meilleure capture. Après correction, répétez la question échouée et le cas de refus voisin. Corriger l’accès à sa propre commande doit, par exemple, être suivi des tests en invité et avec un autre client.
« Non testé » est un constat. Ce n’est pas une validation implicite.
Pour les problèmes d’affichage non critiques, consignez la limite et décidez qui la corrige et quand. Séparez cette décision d’un échec d’accès. L’atelier ne produit volontairement aucun score de sécurité et ne certifie aucune boutique. Il sert à rendre la vérification traçable, y compris les preuves encore absentes.
Testez la plateforme réellement installée.
Pour WooCommerce natif, vérifiez l’association, les outils e-commerce actifs et l’identité connectée pour ses propres commandes. L’e-mail ou le numéro d’un invité ne remplace pas cette identité. Pour PrestaShop, vérifiez le module et le Webservice en lecture seule ; n’attendez pas de modification de commande. Pour une intégration générique, testez connaissances et affichage sans supposer d’accès aux commandes privées. Une action de site sur mesure nécessite sa propre prise en charge réelle par l’hôte et son parcours de consentement.
Pour le transfert, testez une équipe disponible, personne de disponible et une demande déjà en attente. Vérifiez ce que voit le visiteur et ce que l’équipe retrouve réellement dans la boîte de réception. Disponible ne signifie pas réponse immédiate. Pour le mobile et le clavier, vérifiez l’ouverture, la fermeture, la visibilité du focus, la lisibilité des sources et une réponse longue. Une capture sur ordinateur ne suffit pas à établir ces comportements.
Retestez lorsque les conditions de réponse changent.
Une nouvelle source, un nouveau modèle, une version d’extension, un réglage d’autorisation ou une action de site peut modifier le résultat d’un test auparavant réussi. Conservez le bilan téléchargé comme document daté, puis créez-en un nouveau pour l’installation modifiée. Ne remplacez pas un échec antérieur par une réussite sans conserver les changements effectués. Analysez l’usage réel du pilote séparément des prévisions et ne déduisez pas des ventes ou des demandes résolues des seuls volumes d’activité.
Cette fiche aide à déterminer les preuves encore nécessaires. Publier un site ou modifier une intégration de production reste une étape autorisée distincte, avec vos contrôles habituels de mise en ligne. Remettez au responsable un bilan clair : tests réalisés, exclusions volontaires et parcours d’assistance conservé si la connexion réelle échoue.
Identifiez le responsable de l’installation avant de répéter le test de la boutique : comparer l’extension WordPress et le widget. Avant d’élargir le pilote, calculer un budget à partir des hypothèses de conversation testées.