La prochaine version de Curling IO

Mise à jour : 1er octobre 2026

Cet article présente notre exploration initiale de Gleam pour Curling IO v3. Nous avons finalement choisi Rust et TypeScript. Pourquoi nous avons choisi Rust pour la version 3 explique cette décision et ce que nous avons conservé de cette exploration.

À propos de cet article

Cet aperçu porte sur les fondations techniques explorées pour Curling IO v3. Il s’adresse aux ingénieurs logiciels et aux autres personnes qui s’intéressent à l’architecture des applications. Il aborde Gleam, la BEAM, SQLite, l’hébergement et la mise à l’échelle plus en détail que nos articles habituels sur le produit.

La prochaine version de Curling IO devrait vous sembler familière : les mêmes inscriptions, horaires, pointages et tâches d’administration du club, avec plus de rapidité et moins de risques de panne. Le travail se fait surtout sous le capot, mais les avantages sont concrets : moins de ralentissements aux pointes d’inscription, une meilleure fiabilité pendant les événements en direct et une plateforme que nous pourrons continuer d’améliorer longtemps.

Cette série explique ce qui change, ce qui reste et pourquoi nous faisons ce pari.

Les effets pour vous

Pour les gestionnaires de club : de votre point de vue, Curling IO ne change pas. Nous modernisons le système en coulisses : aucune interruption, aucune perturbation, aucune action requise de votre part. Vos données restent exactement où elles sont. Lorsque la mise à niveau sera prête, vous retrouverez le Curling IO que vous connaissez, avec des pages plus rapides et moins d’éléments à exploiter de notre côté.

Pour les curleurs : vous ne remarquerez pas le changement de technologie. Inscriptions, pointages, horaires et résultats fonctionneront comme avant. Les pages pourraient vous sembler plus rapides, surtout aux périodes de pointe des inscriptions ou lorsque vous consultez les pointages en direct de grandes compétitions.

Pourquoi de nouvelles fondations?

Curling IO sert les clubs de curling depuis la fin de 2014. Nous avons déjà modernisé la plateforme en 2019, et notre système de version 2 fonctionne avec succès sur Rails depuis. Tout fonctionne, les clubs sont satisfaits et la croissance est forte. Pourquoi investir dans de nouvelles fondations?

Parce que nous comptons rester longtemps. Le système actuel fonctionne, mais la prochaine décennie lui en demandera davantage : plus de pointages en direct, plus d’automatisation, plus de pointes de trafic et plus de façons pour les clubs de gérer leur travail sans passer leurs soirées devant des formulaires.

Trois raisons principales :

1. Des API pour les agents IA. Nous ajoutons des API conçues pour les agents IA. Votre interface web actuelle ne change pas. Les clubs auront ainsi une autre façon d’effectuer des tâches structurées, comme créer des ligues, vérifier le nombre d’inscriptions ou produire des rapports.

2. Concurrence et exactitude. Les pointes de trafic liées aux inscriptions et aux pointages en direct peuvent mettre le système à rude épreuve. Nous voulons un ensemble de technologies qui gère bien ces pointes et détecte davantage d’erreurs avant la mise en production du code.

3. Une intégration plus simple des développeurs. Nous voulons un code qu’on peut modifier en toute sécurité sans des années de connaissance interne. La sûreté des types et les approches fonctionnelles facilitent la compréhension du système par les développeurs et les outils de programmation IA.

Choisir les technologies

Ces objectifs exigent un ensemble de technologies qui offre :

Ce que nous cherchons

• Sûreté des types : détecter les erreurs à la compilation plutôt qu’en production.
• Concurrence élevée : traiter des milliers d’inscriptions simultanées.
• Approches fonctionnelles : du code prévisible et testable que les développeurs peuvent comprendre.
• Types partagés : les mêmes structures de données côté client et côté serveur.
• Une utilisation éprouvée à grande échelle : des technologies utilisées en production par de grandes entreprises.

Pourquoi Gleam?

Gleam répond à nos besoins. Ce langage fonctionnel à typage sûr se compile en Erlang pour le serveur et en JavaScript pour le client. Il offre :

• La fiabilité de la machine virtuelle BEAM : le même environnement d’exécution que WhatsApp et Discord, avec une tolérance aux pannes intégrée et des processus légers.
• Un système de types de la famille ML : plus fort que celui d’Elixir, il détecte des catégories entières de bogues à la compilation.
• Lustre pour l’interface : un cadriciel Gleam fondé sur l’architecture d’Elm qui se compile en JavaScript. Nous aimons déjà Elm pour nos applications d’interface actuelles. Lustre apporte cette architecture partout, avec les mêmes types de la base de données à l’interface, le tout avec un typage sûr.
• Un langage simple : ciblé, cohérent et facile à comprendre. Idéal pour créer des API déterministes.

Et les autres options?

Nous n’avons pas choisi Gleam d’emblée. Nous avons sérieusement envisagé plusieurs autres ensembles de technologies :

PostgREST + Elm/Lustre. Cette option très sérieuse utilisait des outils que nous connaissons déjà. PostgREST fournit instantanément des API à partir du schéma PostgreSQL, et Elm/Lustre fournit une interface à typage sûr. Il aurait toutefois fallu autre chose pour les tâches en arrière-plan, comme Go. Les outils de création, de débogage et de test des fonctions PostgreSQL ne sont pas excellents. Cet assemblage de plusieurs langages nous semblait fragmenté.

F# SAFE Stack. F# est un langage fonctionnel solide doté de l’écosystème .NET. La pile SAFE (Suave/Saturn, Azure/AWS, Fable, Elmish) offre la sûreté des types de bout en bout avec l’architecture Elm (TEA) pour l’interface. Cette option nous plaisait, mais nous avons choisi Gleam pour les avantages de sa machine virtuelle BEAM et la simplicité de son déploiement.

TypeScript + Node + React. Le choix évident vu son vaste écosystème et la quantité de ressources accessibles aux agents IA. Nous utilisons React à l’occasion depuis 2014 et aimons Redux, inspiré d’Elm, pour l’interface. Mais certains problèmes de JavaScript et TypeScript nous bloquaient : des valeurs nulles partout, un système de types qui semble greffé après coup (on peut contourner la sûreté de TypeScript avec any, as et !), le renouvellement incessant des bibliothèques et les vulnérabilités récurrentes de la chaîne d’approvisionnement npm. La popularité est un réel avantage, mais elle ne compensait pas l’exactitude et la simplicité que nous recherchions.

BEAM a fait pencher la balance. Aucune des autres options n’offrait cette combinaison de concurrence, de tolérance aux pannes et de déploiement simple. Gleam nous donne BEAM côté serveur et des approches fonctionnelles familières, comme Elm, côté client, dans un seul langage.

Pourquoi ne pas garder Rails?

Soyons clairs : nous aimons Ruby on Rails. Il a été formidable pour développer rapidement et a bien suivi l’évolution de nos besoins. Pour les fonctions interactives plus exigeantes, nous utilisons déjà Elm dans les applications d’interface comme le créateur de tableaux éliminatoires, la planification des horaires et les widgets de pointage et de résultats, avec PostgREST pour fournir des API claires côté serveur. Cette approche fonctionnelle a très bien fonctionné.

Mais pour la suite, nous avons besoin :

• De sûreté à la compilation (Ruby est typé dynamiquement).
• Du niveau de concurrence de BEAM (Rails en est très loin).
• De types partagés entre client et serveur (Rails est limité au serveur).
• D’approches fonctionnelles intégrées (Rails est orienté objet).

Nous développons avec Rails depuis sa version 1.2, et rien d’autre ne permet d’itérer aussi vite. Au fil du temps, nous nous sommes toutefois tournés vers des langages fonctionnels, compilés et typés, car les erreurs d’exécution sont les pires à diagnostiquer et à corriger. Gleam nous donne cette exactitude sans sacrifier l’expérience de développement que nous aimons dans Rails.

SQLite plutôt que PostgreSQL

Ce choix nous a surpris.

Curling IO version 2 utilise PostgreSQL. Nous pensions garder Postgres pour la version 3. Nous misons plutôt sur SQLite.

Pourquoi SQLite?

• Des bases de données isolées : une séparation claire des responsabilités avec des fichiers de base de données distincts.
• La rapidité dans le même processus : aucune latence réseau entre l’application et la base de données.
• La simplicité d’exploitation : aucun serveur de base de données à gérer, régler ou organiser en grappe.
• Des économies : un coût inférieur de plusieurs ordres de grandeur à celui de Postgres géré.
• Les sauvegardes Litestream : une réplication continue vers un stockage hors site.

Et la mise à l’échelle?

Avec le même budget d’infrastructure que Rails + PostgreSQL, nous visons :

• 1 000 fois plus de connexions simultanées.
• 100 fois plus de données.
• 100 fois le débit aux périodes de pointe (inscriptions, pointages en direct).

Ces chiffres semblent ambitieux. Nous les traitons donc comme des cibles à démontrer plutôt que comme des arguments marketing acquis. Les processus BEAM occupent environ 2 Ko chacun contre environ 1 Mo pour les fils d’exécution Rails. C’est de là que vient le multiplicateur de 1 000 pour les connexions. L’élimination des allers-retours réseau vers un serveur de base de données distinct compte aussi, puisque SQLite fonctionne dans le processus de l’application.

Nous validerons le tout par des bancs d’essai et des tests de charge en conditions réelles au fil du développement.

Si SQLite ne passe pas à l’échelle comme prévu, nous garderons PostgreSQL.

Privilégier la mise à l’échelle verticale

Notre stratégie est simple : commencer sur un seul serveur puissant, puis augmenter sa capacité.

• Un serveur où l’application et la base de données cohabitent, soit un seul ensemble à déployer, sauvegarder et surveiller.
• Un serveur de secours prêt à prendre la relève et des sauvegardes hors site continues.
• Plus de processeurs et de mémoire vive à mesure que nous grandissons.
• Aucune complexité liée aux systèmes distribués avant d’en avoir réellement besoin.

Si nous dépassons un jour la capacité d’un seul serveur, nous avons une voie claire pour répartir les éléments. Avec la concurrence de BEAM et la rapidité de SQLite dans le processus, nous pensons toutefois que ce jour est encore loin.

La suite

Nous développerons cette nouvelle version en parallèle de la plateforme actuelle. Curling IO version 2 reste en place et continue de fonctionner et de recevoir des mises à jour comme d’habitude. Lorsque la version 3 sera prête et bien testée, nous transférerons tout le monde en une seule transition coordonnée. Nous attendrons d’être certains que tout est solide avant de le faire.

---

Cet article est le premier de la série sur les fondations de Curling IO. À suivre : le bilinguisme avec des garanties à la compilation.