Pourquoi les échecs m'occupent autant

Les échecs ont ce point commun avec l'architecture logicielle : on passe son temps à évaluer des compromis sous incertitude, avec des ressources limitées (le temps à la pendule, la complexité qu'on peut se permettre dans un système). Dans les deux cas, la meilleure décision n'est presque jamais la plus ambitieuse : c'est celle qui tient compte de ce qu'on peut réellement maintenir, calculer ou défendre jusqu'au bout.

Un terrain d'entraînement pour la rigueur

Ce qui me plaît dans le jeu, ce n'est pas tant la compétition que la discipline qu'il impose. On ne peut pas bluffer une position : soit le plan tient face à l'analyse, soit il s'effondre à la première réfutation. C'est un excellent rappel, transposé au code, de ce que signifie vraiment « avoir testé » une idée avant de s'y engager.

Plusieurs casquettes autour du jeu

Mon rapport au jeu ne se limite pas à jouer : je suis aussi parent accompagnateur au Club Échecs Bois-Colombes, j'aide à l'organisation de tournois, et je fais partie de la ligue des échecs des Hauts-de-Seine. Cette proximité avec la logistique réelle d'un tournoi (appariements, suivi des Elo, publication des résultats) est ce qui m'a donné envie de coder EloChessPlanner : un outil que j'aurais aimé avoir sous la main plutôt que de tout faire à la main.

Ce n'est pas un hasard si plusieurs de mes projets personnels tournent autour du jeu : EloChessPlanner pour organiser des tournois, OpeningBook pour explorer des répertoires d'ouvertures en famille, kotlin-chess-tournament pour industrialiser la logique de classement en une librairie réutilisable. Ce sont autant de prétextes pour coder sur un domaine que je comprends intuitivement, sans avoir besoin d'un cahier des charges client pour savoir si le résultat est bon.

Ce que ça m'apprend encore

Le jeu continue de me rappeler une leçon utile en tant que tech lead : la qualité d'une décision se juge à la clarté du raisonnement qui l'a produite, pas au résultat immédiat. On peut jouer un excellent coup et perdre quand même la partie ; on peut livrer une bonne architecture et se faire rattraper par un imprévu métier. Dans les deux cas, ce qui reste, c'est la rigueur du raisonnement qu'on peut rejouer et expliquer après coup.