Curling IO fonctionnait auparavant sur Debian configuré avec Ansible. Cette installation marchait. Elle installait les paquets, configurait Caddy et le pare-feu, créait les services systemd et préparait nos emplacements de déploiement bleu-vert.

Le problème venait du fait qu’un serveur fonctionnel et modifiable nous permettait de conserver une description incomplète. Ansible pouvait décrire le serveur, mais d’anciens fichiers restaient sous /etc. Des outils de compilation avaient été installés autrement. Les choix du fournisseur sur les disques et le RAID existaient en dehors du playbook. Un provisionnement pouvait réussir parce qu’une exécution antérieure avait déjà laissé le bon élément en place.

NixOS tolère beaucoup moins ces lacunes. Cette rigueur est parfois agaçante, mais constitue aussi son principal avantage. Elle nous oblige à décider qui est responsable d’un fichier, d’un service, d’un secret, d’un paquet ou d’un élément nécessaire à la récupération.

Le passage d’Ansible à NixOS nous a montré combien de validations et de nettoyages manquaient à l’ancienne approche. Il a exposé la différence entre un serveur qui continue de fonctionner et un serveur qu’on peut recréer à partir d’éléments déclarés.

Voici ce que nous avons trouvé utile en reconstruisant un serveur physique OVH à partir de disques vides, en restaurant son état et en rendant le processus assez sûr pour être répété.

Cet article fait partie de notre série d’aperçus de Curling IO v3, où nous explorons certaines fonctions offertes dans la prochaine version.

Les clubs de curling vendent bien plus que des ligues et des bonspiels. Ils organisent des ateliers, louent de la glace, attribuent des casiers, tiennent des camps juniors, vendent des tables de banquet et recueillent des dons.

Aujourd’hui, chaque offre doit entrer dans un des types prédéfinis de Curling IO. Cela fonctionne, mais parfois seulement parce que le club choisit la catégorie la plus proche. Un camp d’été junior actif est stocké comme produit, avec ses dates d’août dans le nom. Une location de piste complète est stockée comme programme, car elle exige une date, une capacité et une liste d’attente. Un don est stocké comme frais.

Dans Curling IO v3, l’organisation décide des types dont elle a besoin. Un club peut créer Camps, Ateliers, Locations de glace, Locations de casiers, Collectes de fonds ou toute autre catégorie adaptée à ses activités, puis choisir ce que chaque type permet.

Nous savons que plusieurs de nos clubs utilisent WordPress ou Joomla pour leur site web. Ces plateformes sont populaires pour de bonnes raisons : elles sont souples et ne manquent ni de tutoriels ni d’extensions. Mais cette popularité a un sérieux revers. Les systèmes de gestion de contenu généralistes, ou CMS, sont des cibles importantes, et les clubs gérés par des bénévoles n’ont souvent personne pour surveiller les correctifs de sécurité. Voici ce que vous devez savoir.

Imaginez que vous êtes gestionnaire de club et préparez la prochaine saison. Vous ouvrez votre agent IA et écrivez, ou dites simplement :

Prépare un rabais d’inscription hâtive pour la Ligue du mardi soir. Un rabais de 15 % pour les inscriptions avant le 1er septembre.

Cinq secondes plus tard, c’est fait. Aucun onglet de navigateur, aucun formulaire, aucun menu à parcourir. Avec Curling IO v3, vous pourrez le faire.

Cet article fait partie de notre série d’aperçus de Curling IO v3, où nous explorons certaines fonctions offertes dans la prochaine version.

Les formulaires d’inscription de Curling IO ont toujours recueilli les renseignements de base : nom d’équipe, alignement, niveau de jeu et coordonnées. Mais chaque club fonctionne un peu différemment. Certains ont besoin de contacts d’urgence. D’autres veulent connaître les restrictions alimentaires pour planifier un banquet. Un bonspiel peut demander les coordonnées de l’équipe alors qu’une ligue n’en a pas besoin.

Dans la version 2, les administrateurs peuvent déjà choisir les questions affichées et en créer. La nouveauté de la version 3 est le contrôle de la mise en page : la position et la largeur de chaque question, ainsi que l’organisation du formulaire en sections.

Le panneau d’administration de Curling IO devrait réagir instantanément lorsqu’un gestionnaire prépare une saison. Activer un paramètre, enregistrer un rabais, passer d’une section de produit à l’autre : la page devrait répondre sans rechargement complet.

La version 2 fonctionne, mais chaque envoi de formulaire recharge la page. L’administration de la version 3 est un seul composant serveur Lustre sur BEAM : une connexion WebSocket et un processus Erlang de longue durée par session. Chaque interaction passe par ce WebSocket et revient sous forme de modification du DOM. La page ne se recharge jamais, sans cadriciel JavaScript côté client.

Vous êtes prévenus : cet article contient des opinions qui seront controversées et qui pourraient mal vieillir. Terrain dangereux.

Les agents de programmation IA comme Claude Code, OpenAI Codex et Google Gemini peuvent écrire du code, l’exécuter, lire les erreurs et réessayer. Tout repose sur cette boucle. Plus elle est rapide et informative, plus l’agent devient utile. Après avoir développé Curling IO version 3 en Gleam avec des agents de programmation IA, je suis convaincu que Gleam est le meilleur langage pour cette méthode de travail. Les agents n’écrivent pas un meilleur Gleam, car les données d’entraînement sont moins nombreuses. Mais son compilateur leur permet de se corriger sans attendre un humain.

En écrivant l’article précédent sur nos bases SQLite par test, je décrivais comment chaque test reçoit sa propre base en mémoire, sans connexion ni état partagé. Une idée m’est venue : si rien n’est partagé, pouvons-nous simplement tous les exécuter en même temps?

Nous pouvions, et notre suite de tests serveur est passée d’environ 4 secondes à environ 0,85 seconde pour quelque 800 tests. Aucun changement dans les tests eux-mêmes. Un seul module Erlang de 25 lignes.

Toutes les associations provinciales et territoriales de curling du Canada utilisent Curling IO. Ce sont 14 associations membres sur la même plateforme, avec leurs clubs affiliés. Curling IO prend aussi en charge les inscriptions et la gestion des compétitions au niveau national.

Les tests de Curling IO n’ont besoin ni d’une base de données de test partagée, ni de fonctions de nettoyage, ni d’astuces transactionnelles. Chaque test a sa propre base de données. Il peut donc réussir seul ou dans la suite complète pour la même raison : rien d’autre ne peut toucher ses données.

Cela découle d’un choix de la version 3 : SQLite fonctionne dans le processus de l’application. Chaque test obtient une base SQLite en mémoire complètement indépendante, clonée depuis un modèle en quelques microsecondes avec l’API de sauvegarde de SQLite.