Écrire une question qui peut être tranchée
Commencez par l’événement exact que le marché mesure. « Le réseau sera-t-il lancé cette année ? » peut désigner un test public, une version de production ou une ouverture sans restriction. Précisez l’événement admissible, la source de preuve, l’heure limite et le fuseau horaire. Donnez un exemple qui satisfait la condition et un autre qui ne la satisfait pas. Demandez à une personne extérieure au projet d’interpréter le texte. Si deux lecteurs raisonnables arrivent à des réponses différentes, clarifiez la règle avant d’accepter des positions.
Prévoir les cas difficiles avant leur arrivée
Une spécification utile traite les reports, annonces annulées, changements de nom, sites indisponibles et corrections de données. Décidez si une source de remplacement est autorisée et qui la choisit. Expliquez le traitement d’un résultat publié après la limite, même si l’événement a eu lieu auparavant. Ces décisions doivent être visibles avant la participation. Conservez le texte dans un historique de versions et rattachez sa version au marché. Une correction éditoriale ultérieure ne doit jamais modifier discrètement les conditions des positions déjà ouvertes.
Séparer proposition et règlement définitif
La documentation de l’oracle UMA distingue une réponse proposée, une période de contestation et un parcours de litige. Quel que soit le mécanisme choisi, représentez explicitement ses étapes. La fermeture des échanges ne doit pas créer automatiquement un résultat définitif. Une proposition indique ses preuves et sa date ; un résultat accepté indique quelle règle accomplie lui donne ce statut. Définissez les personnes autorisées à chaque transition et les contrôles du serveur. Les interfaces clients et opérateurs doivent lire le même état durable, sans reconstruire séparément leur propre interprétation.
Rendre les contestations compréhensibles
Un participant doit pouvoir comprendre le point contesté, la fin du délai de réponse et l’étape suivante. Distinguez la proposition initiale, l’argument contraire et leurs pièces justificatives. Évitez un champ de notes modifiable qui efface le raisonnement précédent. Prévoyez un processus clair pour signaler un lien cassé ou une règle ambiguë sans promettre une décision particulière. Les droits administratifs demandent la même rigueur : examiner les preuves, proposer une correction et autoriser le règlement doivent rester des actions identifiables avec un historique exploitable.
Tester séparément les mouvements de fonds
Construisez les tests de règlement à partir de positions enregistrées et d’un résultat convenu. Vérifiez les arrondis, positions partielles, soldes réservés, remboursements prévus et notifications répétées. Un traitement qui redémarre à mi-parcours ne doit pas payer deux fois certaines positions. Rapprochez les montants libérés, conservés et restitués avec le registre initial. Ajoutez des écritures interrompues et des réponses tardives du fournisseur aux exemples de réception. Une réponse correcte à la question ne suffit pas si les écritures qui suivent ne peuvent pas être reproduites et expliquées.
Livrer les preuves avec l’interface
La page finale doit conserver la question, la version des règles, les échéances, le résultat et les preuves. Présentez honnêtement l’attente de résolution et distinguez-la d’une requête technique échouée. Vérifiez les dates dans chaque langue et sur petit écran : une traduction ne doit pas masquer l’heure limite réelle. Avant le lancement, faites parcourir un résultat normal et un résultat contesté aux équipes produit, exploitation et développement. Le livrable attendu est une décision reproductible, accompagnée de traces attribuables, d’une interface claire et d’une politique de fonctionnement explicite.