Thai Break

Ce que c’est

Thai Break est la troisième édition d’un match qui oppose deux amis depuis 2019. Pas un club, pas une fédération, pas un événement ouvert au public : deux personnes qui se sont mises d’accord un soir de 2019 et qui n’ont jamais vraiment arrêté.

Les règles ne sont écrites nulle part, mais elles se sont stabilisées au fil des éditions :

• La discipline change à chaque fois : savate en 2019, MMA en 2023, chessboxing en 2026.
• Les alias ne changent jamais : Gary la Bête contre Saad El Chungo, depuis le premier jour.
• Il faut un vrai dispositif : un arbitre, un juge, des rounds chronométrés, une décision qui compte.
• Il faut une affiche : un logo dédié, un événement en ligne, un live.

Trois éditions à ce jour. La première s’est tenue au Carré Magique, un coin de l’INSA Lyon qu’on a nous-mêmes baptisé ainsi, et que tout le campus appelle encore comme ça aujourd’hui sans savoir d’où vient le nom. C’était de la savate, et Saad l’a emporté aux points.

La deuxième, OneForce, tenait son nom de la rivalité professionnelle qu’on transposait sur le ring : moi chez Salesforce, Saad chez Onepoint. Cette fois c’était du MMA, et j’ai gagné aux points.

La troisième, Thai Break, c’est du chessboxing : des rounds de boxe anglaise alternés avec des parties d’échecs. C’est aussi celle qui a demandé le plus de logistique. On est partis à douze à Ko Samui, choisie après avoir épluché la météo de la Thaïlande, et on a loué un club de boxe entier pour l’occasion. Elle s’est jouée au temps. Et c’est pour elle que j’ai développé une application.

L’application

Cette édition a surtout été un terrain pour monter en compétence sur le développement agentique. J’ai construit l’application avec Claude Code, en quelques jours là où le même travail m’aurait pris des mois. Et c’est autant cette manière de développer que le combat lui-même qui m’intéressait ici. Je reviens en détail plus bas sur la façon dont elle a été construite ; pour l’instant, juste ce qu’elle fait.

L’app gère tout le déroulé d’un combat de chessboxing : le chronométrage des rounds de boxe et d’échecs, et la capture automatique des coups depuis un échiquier connecté.

• Échiquier connecté Chessnut : connexion d’un Chessnut Air / Air+ en Bluetooth pour capturer automatiquement chaque coup légal et basculer le trait sans y toucher. C’est la pièce maîtresse de l’app, et le sujet sur lequel je reviens plus bas (build de dev iOS/Android).
• Pendules individuelles : temps par joueur (9 min par défaut) et incrément (0 par défaut).
• Configuration des rounds : round d’échecs (3 min), round de boxe (3 min), intervalle (1 min).
• Tap pour changer de trait : pendant les rounds d’échecs, chaque joueur tape son panneau une fois qu’il a joué.
• Pause : mettre le match en pause et le reprendre à tout moment.
• Restitution de secondes : ajouter +5, +10 ou +15 s à un joueur (usage arbitre).
• Historique des parties : parties sauvegardées avec date, vainqueur, temps et round atteint ; export JSON.
• Signal de round : bip sonore à chaque changement de phase.
• Musique d’intervalle personnalisée : assigner ses propres audios aux intervalles 1 à 10 (iOS/Android).
• Multiplateforme : web, iOS et Android.

C’est l’artefact technique de Thai Break. Sans elle, le format serait impossible à arbitrer proprement : deux horloges d’échecs, deux minuteurs de boxe et des transitions à ne pas rater.

La partie

C’est cette application qui a chronométré la troisième édition, le 29 avril. Voici la partie qu’elle a enregistrée, à rejouer coup par coup.

8

7

6

5

4

3

2

1 a

b

c

d

e

f

g

h

|« ‹ Position de départ › »|

Le niveau de jeu n’a rien à voir avec ce dont on est capables à tête reposée. C’est le piège du format : entre les parties, on encaisse des rounds de boxe anglaise, et calculer coûte alors beaucoup plus cher. Nos coups tombent nettement en dessous de notre vrai niveau, on multiplie les erreurs, on vérifie deux fois chaque variante parce qu’on ne se fait plus confiance, et c’est souvent le chrono qui finit par trancher. J’ai d’ailleurs perdu au temps dans une position gagnante, ce qui est sans doute la façon la plus juste de comprendre ce sport.

Construire l’app avec Claude Code

Je l’ai dit plus haut : cette édition était autant un prétexte pour monter en compétence sur le développement agentique que pour me battre. L’app, je l’ai écrite avec Claude Code, en dialoguant avec lui plutôt qu’en tapant chaque ligne. Trois choses m’ont marqué, et la dernière touche directement mon métier.

L’UI

Le plus bête d’abord, mais le plus visible : l’interface. Boutons, pendules, écran de configuration, historique des parties : tout ce qui prend d’habitude des heures de mise en forme est sorti quasiment juste du premier coup, en NativeWind (Tailwind sur React Native). Je décrivais l’écran, il posait la structure et les classes, j’ajustais.

Le cross-platform

Une seule base de code pour le web, iOS et Android, via Expo. Claude Code connaît les pièges propres à chaque cible (le module Bluetooth indisponible sur le web, le stockage qui doit basculer sur un fallback fichier sur iOS) et les gère sans que j’aie à les découvrir un par un.

L’intégration, le vrai sujet

C’est là que ça devient intéressant pour moi : mon métier, c’est l’intégration. Faire parler deux systèmes qui n’ont pas été conçus pour ça.

Le système en face, ici, c’est l’échiquier connecté Chessnut Air+. L’idée : quand un joueur joue un coup sur le vrai plateau, l’app le détecte et bascule automatiquement la pendule. Plus besoin de taper l’écran.

Sauf qu’il y a un os. Chessnut ne publie ni SDK ni documentation de son protocole. L’échiquier parle en Bluetooth, mais dans un dialecte que le constructeur garde pour lui.

Et c’est là que Claude Code m’a bluffé : de lui-même, il est allé chercher des dépôts publics où des passionnés avaient déjà rétro-conçu le protocole (rmarabini/chessnutair pour les trames, ChessnutPy pour les commandes LED), puis il a reconstruit l’intégration à partir de là. Je ne lui ai pas fourni la doc ; il est allé la trouver.

Le résultat est une boucle bidirectionnelle très classique en intégration : on écoute un flux d’événements entrant, on le transforme et on le valide, puis on renvoie un état sortant.

En clair :

1. Connexion. En Bluetooth Low Energy (react-native-ble-plx), l’app scanne, se connecte, envoie un code d’initialisation (0x21 0x01 0x00) et s’abonne aux notifications de l’échiquier.
2. Événement entrant. À chaque mouvement de pièce, l’échiquier pousse une trame : l’état complet des 64 cases.
3. Transformation. L’app décode cette trame binaire en une position lisible.
4. Validation. Elle la compare à la position précédente pour déduire le coup joué, et le fait valider par chess.js, un moteur qui connaît les règles (roque, prise en passant, promotion). Un coup illégal est ignoré.
5. Effet. Si le coup est légal : on bascule la pendule, on l’ajoute au PGN, on vérifie s’il y a mat ou nulle.

Décoder le fil binaire

Le point délicat, c’est l’étape 3. L’échiquier n’envoie pas « le cavalier va en f3 » ; il envoie 34 octets bruts. Deux d’en-tête, puis 32 qui décrivent les 64 cases, une case par demi-octet (nibble).

Chaque valeur de 0 à 12 code une pièce (0 = case vide, 7 = pion blanc, 12 = roi blanc…). L’app reconstitue une position au format FEN, la notation standard des échecs. Cette FEN devient le modèle pivot de toute l’intégration : le langage commun entre l’échiquier physique et le moteur d’échecs.

Écrire en retour : les LEDs

L’intégration ne va pas que dans un sens. L’app renvoie aussi des commandes à l’échiquier, sur ses LEDs : coup validé surligné, pièce mal placée en rouge, plateau entièrement allumé entre les rounds et à la fin du match. Même protocole reconstitué (0x0A 0x08 suivi d’un bitmap de 8 octets, un bit par case).

Et comme tout flux temps réel, il a fallu de la robustesse : un anti-rebond pour ne pas enregistrer les positions intermédiaires quand on fait glisser une pièce, la détection des corrections quand on repose une pièce mal placée, une validation de la position de départ avant de lancer la partie. Rien d’exotique pour qui fait de l’intégration, sauf que tout est sorti d’une conversation, pas d’un mois de rétro-ingénierie. Un binôme qui va lire la doc à ma place, écrit le connecteur, et me laisse sur la partie qui m’intéresse : l’architecture du flux.

De cette app à mon métier

Je suis Solution Engineer chez Postman, et ce petit projet dit quelque chose de plus large. Développer avec l’IA change la vitesse : cette app, faite en quelques jours, m’aurait pris des mois autrement. Mais ce qui marche pour un projet perso ne se transpose pas tel quel en entreprise.

Premier écart : le projet local n’existe pas. Mon app tenait sur ma machine, un seul développeur, aucune contrainte. En entreprise, tout est connecté, partagé, exposé à d’autres équipes. Il faut de la gouvernance : qui a le droit d’appeler quelle API, avec quelles limites, sous quel contrat. Sans elle, la vitesse de l’agent ne fait qu’accélérer les dégâts.

Deuxième écart : la qualité de la documentation. Si Claude Code a pu brancher l’échiquier, c’est parce que des passionnés avaient documenté le protocole. Un agent n’exploite bien un repo ou une API que si elle est correctement décrite. En entreprise, c’est la même règle : une API mal documentée est invisible pour un LLM, une API bien spécifiée devient un outil qu’il sait utiliser. C’est exactement ce que Postman adresse, documenter, spécifier et gouverner les APIs pour qu’humains comme agents puissent s’en servir.

Et puis il y a le testing. Quand un humain relit à peine le code commité, parce qu’il sort d’une conversation plutôt que d’un clavier, les tests deviennent le vrai filet. Ils ne sont plus une étape optionnelle, ils sont ce qui garantit que ce que l’agent a produit fait bien ce qu’on croit. Là aussi, c’est un terrain que Postman couvre de bout en bout.

Dernier point, plus spécifique à l’IA : tous les modèles ne se valent pas selon l’usage. On a des outils pour benchmarker les LLMs et choisir le plus pertinent sur trois critères concrets, la qualité de la réponse, le temps de réponse et le nombre de tokens consommés. Sur un projet perso, on prend le modèle qu’on a sous la main. À l’échelle, ce choix se mesure.

C’est ce qui rend ce projet intéressant au-delà du combat : le même geste, faire parler deux systèmes avec un agent, passe d’un bricolage de quelques jours à une discipline d’ingénierie dès qu’on le met en production.