Étude de cas
Un site de tombola immobilière avec trois moyens de paiement et un tirage dont le site ne désigne pas le gagnant
Les participants achètent des tickets numérotés pour un tirage dont le lot est un bien immobilier. Par carte, par virement bancaire ou en crypto, avec ou sans compte, en trois langues.
Mon rôle
Celui-ci est le produit d'un client, pas le mien, et je ne nomme pas le client ici. La tombola, les lots, le règlement et les acheteurs sont ceux du client. Ma part, c'est le logiciel : je suis le seul développeur dans son dépôt, 321 commits sur sept mois en 2026, et j'en assure toujours la maintenance.
La situation
Le client organisait déjà ces tirages sur un thème de boutique en ligne, avec le paiement renvoyé vers un lien externe. Seulement, une tombola pour un bien immobilier n'est pas une boutique. Un acheteur veut un ticket numéroté et la preuve qu'il existe, l'organisateur doit savoir exactement combien de tickets sont en circulation et qui les détient, et le jour du tirage tout le monde doit pouvoir constater que le numéro gagnant était un vrai ticket, payé.
La contrainte
L'argent entre par trois portes et doit finir dans un seul compteur. Un paiement par carte se confirme tout seul en quelques secondes. Un virement bancaire attend qu'une personne le valide. Un paiement en crypto attend que le prestataire de paiement rappelle. Les trois doivent aboutir à la même chose : un ticket numéroté émis exactement une fois, et jamais un ticket de plus que ce que le tirage contient.
Le tirage doit être crédible, donc le site ne désigne pas le gagnant. Le tirage a lieu en dehors du site, et l'administrateur enregistre ensuite le numéro gagnant. Le rôle du site, c'est la moitié ennuyeuse qui compte : refuser un numéro qui n'est pas un vrai ticket payé, enregistrer le gagnant et clôturer le tirage en une seule et même opération, et publier une page de preuve que n'importe qui peut ouvrir.
Un acheteur n'a pas besoin de compte. C'est bon pour les ventes et difficile pour tout le reste : le ticket doit parvenir à un invité sous une forme qu'il peut conserver, ses achats doivent se rattacher à un compte s'il en crée un plus tard, et un formulaire de commande public doit tenir face aux robots.
Ce que j'ai construit
Le site est en production et je continue d'y livrer. Ce que fait le site :
- Un site public en trois langues qui s'ouvre dans la langue du visiteur : les tirages, une page par tirage, les gagnants, la FAQ, un blog, les pages légales.
- Un achat en trois étapes : choisir des tickets ou un pack, répondre à une question de compétence chronométrée, payer. En invité ou depuis un compte, pour soi ou pour offrir.
- La carte, le virement bancaire avec une référence qu'un administrateur valide et qui expire toute seule si l'argent n'arrive jamais, et la crypto via un prestataire hébergé dont les rappels sont vérifiés par signature.
- Un seul allocateur de tickets commun aux trois : des numéros séquentiels à six chiffres, une confirmation traitée une seule fois, et le refus de vendre au-delà de la taille du tirage. Le ticket arrive en PDF par email, et une tâche de fond retente les emails qui ne sont pas partis.
- Des coupons, des codes partenaires et des liens de parrainage, avec un ticket gratuit après un nombre défini de parrainages payés.
- L'enregistrement du tirage : le site vérifie que le numéro gagnant est un ticket payé, enregistre le gagnant et verrouille le tirage dans la même opération, puis affiche une page de preuve publique.
- Une console d'administration en deux langues : tirages, participants, virements et commandes crypto à valider, paiements, remboursements, coupons, liens de paiement, exports et un outil de newsletter avec désinscription en un clic.
- Ce qui ne se voit pas : un contrôle anti-robots et des limites de débit sur les commandes, une sauvegarde quotidienne avec une alerte le matin si elle manque, et une surveillance qui repère les commandes bloquées, du type « payée mais email non envoyé ».
Les chiffres
- 3moyens de paiement (carte, virement bancaire, crypto)
- 3langues sur le site public
- 10tâches de fond planifiées
- 153cas de test automatisés, dans 16 fichiers
- 321commits sur sept mois en 2026
Ce sont des comptages techniques, lus dans les fichiers et l'historique du projet. Il n'y a sur cette page ni nombre de tickets, ni chiffre d'affaires, ni nombre d'acheteurs, ni nom de partenaire, ni nom de client. Tout cela appartient au client, et c'est à lui de le publier.
Ce que j'ai fait et ce que je n'ai pas fait
C'est l'activité de quelqu'un d'autre. Je n'ai pas conçu la tombola, choisi les lots, écrit le règlement ni procédé au tirage, et rien sur cette page n'affirme quoi que ce soit sur la façon dont les tirages se sont passés. Ce qu'elle montre est plus étroit : je sais prendre une activité qui manipule l'argent des autres, remplacer le site sur lequel elle repose, et le faire tourner seul pendant sept mois.
Je suis la seule personne dans le dépôt, et je travaille tous les jours avec un assistant de code IA. L'autre moitié de cette habitude, c'est la relecture : le code de paiement est passé par quatre séries de relecture le jour de son lancement et dans les deux jours qui ont suivi, et chaque constat a été clos dans son propre commit.
Ce que je ferais autrement : écrire les tests avant l'argent. Les trois moyens de paiement sont passés en production le 8 mai 2026 et le premier fichier de tests automatisés est arrivé le 25 mai.
Vous voulez la même chose ?
Dites-moi ce que vous construisez, ou ce que vous faites encore à la main, et je vous dirai comment je m'y prendrais. Sans engagement.