Fixer le périmètre avant de créer le module
Ce parcours aide commerçants et développeurs à livrer un composant auto-hébergé, pas un service de lots géré. Consigner responsable, dates, éligibilité, conditions de retrait et source du résultat. Choisir roue, carte à gratter ou boîtes pour la présentation ; une animation ne prouve aucune attribution. Identifier explicitement le mode local comme démonstration. Le serveur marchand doit prendre en charge authentification, probabilités, stock et retrait pour une opération réelle.
Garder un export complet intact. Héberger index.html, widget.css et widget.js ensemble, ou choisir délibérément le HTML autonome. config.json est une source modifiable, non un coffre à secrets. Les offres dans le code sont visibles et les images externes sont demandées par les navigateurs des visiteurs. N’envoyer aux outils auxiliaires que des données fictives ou expurgées, jamais de clés ou de vrais codes de retrait.
Réconcilier configuration et contrat de réponse
Construire le JSON Schema à partir des instructions de l’export courant. Vérifier version, campaignId, mode, endpoint et identifiants des lots. Contrôler séparément leur unicité et le total local exact de 100 % : une validation structurelle simple ne démontre pas ces relations. Les secteurs égaux de la roue sont visuels, pas des probabilités égales. Expliquer chaque changement de règles, libellés ou source de résultat dans la comparaison JSON. Réexporter après modification approuvée sans mélanger configuration et ancien script.
La requête contient version, campaignId et requestId. La réponse doit renvoyer le même requestId et un prizeId configuré ; les champs facultatifs suivent le contrat exporté. Valider exemples de gain et de non-gain, puis garder des exemples invalides pour les essais négatifs. Un schéma ne lance pas l’API et ne contrôle ni éligibilité ni stock. L’aperçu de l’éditeur n’appelle jamais votre API.
Examiner la lisibilité de chaque état
Mesurer les couples réels texte/fond, y compris boutons et résultats. Un contraste satisfaisant ne certifie pas toute l’accessibilité. Examiner le HTML puis confirmer dans le navigateur libellés, accès clavier, focus visible, perception du résultat et usage sans animation. Une analyse statique ne certifie ni le geste de grattage ni le cadre intégré.
Tester traductions longues, texte agrandi, images et liens de retrait. Maintenir les règles sous forme lisible, sans les cacher dans une animation. Ne pas approuver seulement l’écran initial ; inscrire les défauts d’interaction non résolus même si l’aperçu paraît soigné.
Tester le site hébergé et son intégration réelle
Déployer sur le domaine HTTPS de recette autorisé. Les rendus adaptatifs repèrent des débordements à certaines largeurs et les captures documentent une vue, pas un tirage. Ils peuvent manquer les états authentifiés et le contenu des cadres interorigines. Noter URL, dimensions et version, puis ouvrir la boutique réelle pour vérifier hauteur du cadre, défilement, clavier et liens externes.
Une route d’API relative se résout depuis l’origine du module, pas celle de la boutique hôte. Le code utilise les justificatifs de session de même origine. Configurer CORS pour une API distante ne provoque pas l’envoi de cookies interorigines ; les restrictions de cookies tiers peuvent aussi empêcher une session dans un cadre. Préférer une origine dédiée contrôlée et relire les permissions du cadre : elles permettent l’intégration marchande, sans garantir l’isolation de son code.
Tester gain, non-gain configuré, statut HTTP non réussi, JSON incorrect, prizeId inconnu, requestId incohérent et réponse au-delà du délai documenté de 15 secondes. Un échec ne doit pas attribuer un lot local. La nouvelle tentative manuelle réutilise une requête non résolue sur cette page seulement ; recharger n’est pas protégé. Le serveur doit conserver les résultats de manière transactionnelle et gérer une réponse perdue après attribution. Utiliser des résultats de test, sans consommer de vrais lots.
Transmettre une version identifiable
Calculer SHA-256 après la dernière modification. Livrer fichiers, différences, origine, contrat, preuves expurgées, points ouverts et responsables. L’empreinte identifie les octets, pas l’équité ni la fiabilité du serveur. Stock, éligibilité, retrait et autorisation de campagne restent des conditions de lancement distinctes.
Passer au parcours des liens de campagne pour suivi et QR, à la revue adaptative pour des preuves avant/après, ou au contrôle préalable Stripe pour les fichiers candidats de remise. Aucun ne remplace la recette de cette intégration marchande.