Utilisez les joueurs autonomes pour trouver des curleurs qui souhaitent rejoindre une équipe dans votre ligue ou votre bonspiel. Cette fonction ajoute une option de consentement à l’inscription et donne à vos gestionnaires une liste de personnes à contacter.

Les frais d’inscription s’appliquent toujours​

Les joueurs autonomes s’inscrivent à l’événement par votre parcours de commande habituel. Les prix, les rabais et les options de paiement habituels de l’événement s’appliquent. Choisir M’inscrire comme joueur autonome n’annule pas les frais d’inscription et ne reporte pas le paiement jusqu’à ce que la personne trouve une équipe.

Permettre aux curleurs de s’inscrire à la liste​

1. Allez à Produits et ouvrez votre ligue ou votre bonspiel.
2. Sélectionnez Information.
3. Cochez Permettre les joueurs autonomes, puis sélectionnez Enregistrer.

L’événement doit exiger un profil de participant. Si l’option n’apparaît pas, vérifiez la configuration de l’événement sous Information.

Les curleurs peuvent cocher M’inscrire comme joueur autonome pendant l’inscription. Ce choix partage le courriel et le téléphone disponibles dans le profil de participant avec les autres personnes inscrites admissibles du même événement. Le profil doit contenir un courriel ou un numéro de téléphone pour permettre de joindre la personne.

Les coordonnées proviennent du profil de participant, qui peut utiliser un courriel différent de celui du compte de connexion. Encouragez les curleurs à vérifier ces renseignements avant de s’inscrire.

Lors de la commande, choisir cette option efface les réponses de nom d’équipe et de nom du capitaine. Les autres questions dépendent toujours de votre formulaire d’inscription. Les curleurs doivent terminer la soumission de leur inscription avant d’apparaître dans la liste. Un panier inachevé n’ajoute personne à la liste.

Communiquer avec eux et composer l’alignement​

Ouvrez Joueurs autonomes pour l’événement afin de consulter le nom de chaque participant ainsi que le courriel et le téléphone disponibles dans son profil.

1. Communiquez avec le curleur pour discuter de l’équipe et de la position.
2. Ouvrez Équipes pour le même événement.
3. Créez une équipe ou modifiez celle qu’il rejoindra.
4. Sélectionnez le participant dans l’alignement de l’équipe, puis sélectionnez Enregistrer.

Une fois placé dans une équipe de cet événement, le participant disparaît automatiquement de la liste des joueurs autonomes. Vous n’avez pas à le retirer manuellement. Son inscription et ses paiements restent inchangés. S’il quitte l’alignement de l’équipe alors que son consentement est toujours actif, il peut réapparaître dans la liste. Curling IO ne place pas automatiquement les joueurs autonomes dans des équipes.

Qui peut voir les coordonnées?​

Sur le site public du club, l’onglet Joueurs autonomes de l’événement est accessible aux comptes connectés qui possèdent une inscription soumise ou payée à cet événement. L’inscription ne doit pas être annulée. Le répertoire public devient indisponible après la fin de l’événement ou si l’événement ou l’option des joueurs autonomes est désactivé.

Les visiteurs anonymes et les comptes sans inscription admissible ne peuvent pas consulter le répertoire. Les gestionnaires du club peuvent le consulter dans la page d’administration de l’événement.

Retirer une personne de la liste​

Si un curleur ne souhaite plus être contacté, sélectionnez Retirer des joueurs autonomes à côté de son nom, puis Confirmer. Cela efface son consentement actuel à figurer parmi les joueurs autonomes de cet événement et le retire de la liste de coordonnées. Cette action n’annule pas son inscription à l’événement, ne le retire pas d’une équipe, ne modifie pas ses paiements et ne produit aucun remboursement. Son profil de participant est aussi conservé.

Lorsqu’une personne trouve une équipe, enregistrez plutôt l’alignement de l’équipe. Pour annuler son inscription ou rembourser un paiement, utilisez les actions distinctes de gestion des commandes et des remboursements.

Un membre veut répartir ses frais de saison sur quelques mois. Recueillir ces paiements par virement Interac et les suivre dans un tableur peut être difficile.

Les plans de paiement permettent de répartir certains achats en versements prévus. Les membres choisissent un plan à la finalisation de la commande, SportsPay programme le prélèvement automatique des versements suivants, et chaque paiement reste lié à la commande du membre dans Curling IO.

Offrir un plan de paiement pour une inscription​

Vous choisissez quels produits offrent un plan. Les membres peuvent toujours payer en totalité. Un plan a une fin précise : une fois tous les versements payés, les prélèvements cessent.

Commencez dans Paramètres > Paiements > Politiques des plans de paiement. Choisissez les politiques du club pour l’annulation des versements restants et le remboursement des paiements déjà perçus. Ces deux choix sont obligatoires avant d’activer le plan d’un produit. Les politiques apparaissent dans l’autorisation du client à la finalisation de la commande.

Sur la page de modification du produit, activez Offrir un plan de paiement sous Tarification. Choisissez un nombre de paiements ou un montant par paiement, puis définissez le nombre de mois entre les paiements. L’aperçu montre un exemple d’échéancier pour quelqu’un qui achète aujourd’hui.

Par exemple, vous pourriez offrir trois paiements mensuels. Si vous fixez plutôt un montant par paiement, le dernier versement peut être plus petit que les autres.

L’échéancier final utilise le prix du produit après les rabais et les taxes. Les autres articles du panier et les frais applicables à la commande sont dus avec le premier versement.

Montrer aux membres ce qu’ils paieront​

Le membre choisit le plan dans son panier. Le parcours de commande montre le montant et la date d’échéance de chaque versement, le montant dû maintenant et les politiques d’annulation et de remboursement du club. Finaliser la commande autorise les prélèvements prévus.

Après la réussite du premier paiement, Curling IO configure les versements restants avec SportsPay pour leur prélèvement automatique. Curling IO envoie des rappels par courriel avant les échéances et des avis lorsqu’un versement réussit ou est refusé. Les numéros de carte restent chez le processeur de paiement; Curling IO ne les conserve pas.

Si le parcours de commande affiche Votre commande est en cours de traitement, Curling IO confirme encore le paiement. Le membre peut quitter la page et revenir à la commande plus tard. Il devrait attendre le résultat avant d’essayer un autre paiement.

Si un paiement est refusé, les versements suivants sont suspendus. Le membre peut ouvrir Compte > Plans de paiement et mettre à jour son mode de paiement. La mise à jour de la carte entraîne aussi une nouvelle tentative du versement refusé le plus ancien. Si plusieurs paiements sont en retard, le rattrapage peut entraîner plus d’un prélèvement.

Suivre les plans qui demandent votre attention​

Ouvrez Inscriptions > Plans de paiement pour voir les plans des commandes du club. Filtrez selon des états comme Échec, À vérifier ou En retard pour trouver ceux qui exigent un suivi. Ouvrez la commande d’un plan pour examiner ses versements et réessayer un paiement refusé.

Chaque ligne montre le numéro du plan, le produit, le compte, la prochaine date de paiement, les montants payés et restants et l’état. Si SportsPay signale une erreur, un message sous le plan explique le problème.

Le personnel peut aussi annuler les versements restants. Cela réduit le montant impayé, mais ne rembourse pas les paiements déjà perçus et n’annule pas l’inscription. Lisez le résultat de l’annulation avant de présumer que les prochains prélèvements ont cessé. Si la suppression dans SportsPay n’est pas confirmée, un prélèvement prévu peut encore avoir lieu et exige un suivi.

Où les plans de paiement sont offerts​

Les plans de paiement utilisent actuellement SportsPay. Les plans Stripe ne sont pas encore offerts. L’activation et la configuration des paiements en ligne donnent aussi accès à Premium. Un club qui utilise SportsPay n’a donc pas besoin d’un achat Premium distinct pour offrir ces plans.

Si votre club utilise un système de gestion de contenu (CMS), cette situation vous sera peut-être familière. Un membre du personnel ou un bénévole crée le site, mais lorsqu’il part, personne d’autre ne sait le mettre à jour. Les modifications sont reportées, et les vieilles informations restent en ligne.

Nous avons construit Studio pour permettre au personnel du club de garder son site à jour aussi facilement que possible. Votre site se trouve dans Curling IO, avec les programmes, les événements et les inscriptions du club. Vous n’avez pas à gérer un site tiers compliqué, comme WordPress, ni à payer un autre fournisseur uniquement pour l’hébergement.

Les inscriptions ouvrent, un nouveau programme a besoin d’un lien bien visible et le message d’accueil pourrait être réécrit. Studio vous donne un aperçu du site et un assistant IA pour vous aider à faire ces changements.

Décrivez ce que vous voulez changer et vérifiez le résultat dans l’aperçu avant de publier. Si vous préférez une conception antérieure, vous pouvez facilement la restaurer.

L’assistant IA intégré de Curling IO​

Le moyen le plus simple de faire un changement est de le demander à l’assistant intégré de Curling IO. Ouvrez Site web > Studio, sélectionnez Modifier, puis le bouton avec des étincelles nommé Demander de l'aide à l'IA pour cette tâche. Assurez-vous que l’onglet Assistant est sélectionné. Vous pouvez travailler à côté de l’aperçu, sans modifier vous-même les paramètres du site.

Dites-lui ce que vous voulez changer. Par exemple :

Rends notre page d’accueil plus accueillante pour les nouveaux curleurs. Rédige une courte introduction et ajoute un bouton Renseignez-vous sur l’initiation au curling qui mène à notre page de contact.

L’assistant fait le changement dans l’aperçu pour que vous voyiez immédiatement le résultat. Sélectionnez Accepter pour l’enregistrer ou Refuser pour revenir au brouillon précédent. Refuser retire le changement abandonné sans l’ajouter à l’historique du site. Votre site public reste inchangé tant que vous ne sélectionnez pas Publier.

Précisez le résultat souhaité. Dites quelle page ou section modifier, fournissez les faits nécessaires et nommez ce que vous voulez conserver. Si un programme commence à une date précise, indiquez-la. Lisez le texte proposé avant de l’accepter, surtout les noms, les dates et les affirmations sur votre club.

Vous pouvez aussi donner des images à l’assistant. Sélectionnez Ajouter une image, puis choisissez son usage. Site Web utilise l’image sur votre site. Référence montre à l’assistant une image à consulter. Une image de référence ne devient pas une image du site simplement parce que vous l’avez jointe.

Vous pouvez demander un autre ajustement dans la même conversation, par exemple raccourcir un titre qui s’intègre mal. Pour une autre tâche, sélectionnez Nouveau clavardage. Cela efface la conversation tout en gardant les modifications du site déjà acceptées.

Vous pourriez ensuite ajouter une image de bannière à une autre page, retirer un lien du menu du site ou changer l’ordre des liens. Prévisualisez et acceptez chaque changement, puis publiez une seule fois la mise à jour terminée. Donnez à l’assistant les faits de votre club et la destination de tout nouveau lien, puis vérifiez sa proposition.

Ou utilisez votre propre agent IA​

Si vous préférez travailler avec votre propre agent, sélectionnez l’onglet Mon agent dans le panneau de l’assistant. Il explique comment commencer et fournit des instructions à copier. Commencez la conversation dans votre propre assistant IA, puis donnez-lui accès à la page par une connexion de navigateur prise en charge.

Votre agent doit accéder à la page d’administration où votre session est ouverte, par une connexion de navigateur prise en charge. Coller l’adresse du club dans un clavardage ordinaire ne lui donne pas cet accès.

Sur une page qui offre des actions aux agents, ouvrez la page dans votre agent de navigateur compatible, choisissez Copier les instructions et donnez-lui ces instructions avec le changement souhaité. Les actions disponibles dépendent de la page et de vos permissions. Vous choisissez et téléversez encore vous-même les fichiers et répondez aux confirmations requises.

Nous rendons la prise en charge des agents externes accessible dans toute l’administration. La même approche vous permettra de demander de l’aide sur la page où vous travaillez. Les actions possibles dépendent de la page et de vos permissions; le panneau de connexion montre ce qui est disponible. Studio met des actions à la disposition des agents externes, comme ouvrir l’historique des modifications ou proposer un changement à vérifier. L’exemple de modification présenté ici utilise l’assistant intégré.

Pour revenir à l’assistant intégré, sélectionnez l’onglet Assistant.

Choisir le contenu de votre page d’accueil​

Studio vous permet d’organiser les sections de la page d’accueil selon ce que les visiteurs doivent trouver. Vous pouvez demander à l’assistant de changer le texte, de réorganiser les sections ou d’ajouter des composants pris en charge.

Les sections dynamiques vous évitent de maintenir une seconde copie des renseignements du club sur la page d’accueil. Elles utilisent les enregistrements publics admissibles de Curling IO. Changer la mise en page du site ne modifie pas la fiche d’événement, de produit ou de commanditaire sous-jacente.

Vous pouvez aussi choisir ce qui s’ouvre comme page d’accueil : la page d’accueil intégrée, une page publiée ou le premier type de produit automatique.

Ajouter des widgets à votre site​

Les widgets vous permettent d’ajouter du contenu et des services utiles à votre site. Vous pouvez montrer les publications sociales du club, ajouter une inscription à l’infolettre ou aider les visiteurs à trouver l’aréna sur une carte.

Pour les profils sociaux, Studio peut suggérer les comptes déjà enregistrés dans les paramètres du club. Vous pouvez changer le compte à l’ajout du widget. Les publications, les vidéos et les listes de lecture individuelles utilisent le lien précis fourni.

Par exemple, demandez à l’assistant : « Ajoute notre profil Instagram sous le message d’accueil » ou « Ajoute une inscription à l’infolettre près du bas de la page d’accueil ». Fournissez le compte, le lien ou les détails d’inscription nécessaires.

Vous avez besoin d’un widget absent de la liste? Vous pouvez demander de nouveaux widgets dans la section Feuille de route.

Personnaliser le reste du site​

Studio contrôle aussi le thème et la navigation du site. Vous pouvez organiser les liens pour que les visiteurs trouvent les ligues, les pages, le calendrier et les autres contenus publics. Les pages prises en charge ont de l’espace pour des composants supplémentaires au-dessus et au-dessous de leur contenu principal, dont des bannières et du texte d’introduction.

La personnalisation a ses limites. Studio utilise des composants et des paramètres pris en charge. Il ne laisse pas l’assistant écrire des scripts arbitraires ou remplacer les parcours d’inscription et de paiement. Demandez un changement concret, comme ajouter une introduction au-dessus d’une liste de programmes, plutôt que de présumer qu’il peut construire toutes les pages imaginables.

Si votre site utilise l’anglais et le français, vérifiez les deux langues avant de publier. Un changement qui se lit bien dans une langue doit aussi être vérifié dans l’autre.

Prévisualiser les changements sans les publier​

Vous pouvez essayer un autre titre, réorganiser les sections ou examiner plusieurs suggestions de l’IA sans changer ce que voient les visiteurs. Studio permet de prévisualiser vos changements enregistrés pendant que le site public continue de montrer sa dernière version publiée.

Sélectionnez Enregistrer pour créer un Point de contrôle, un brouillon enregistré auquel vous pouvez revenir. Accepter un changement de l’assistant crée aussi un point de contrôle. Vérifiez le résultat dans l’aperçu de Studio, faites un autre ajustement et enregistrez encore au besoin. Vous n’avez pas à publier chaque changement au fur et à mesure.

Par exemple, vous pourriez réécrire le message d’accueil et ajouter un lien d’inscription, puis vérifier leur apparence ensemble. Si le texte exige une autre retouche, continuez de modifier le brouillon. Vos visiteurs voient toujours le site existant.

Publier quand vous êtes prêt​

Après avoir vérifié le brouillon, sélectionnez Publier. Cela rend la conception enregistrée publique et lui donne un numéro de Version dans l’historique.

Vous pouvez enregistrer plusieurs points de contrôle pendant la préparation d’une mise à jour, puis publier une seule version terminée. L’historique distingue ces brouillons de travail des versions publiées. Il devient plus facile de retrouver une conception déjà publiée à restaurer.

Studio montre aussi qui détient le verrou de modification. Cela empêche deux membres du personnel de modifier le site en même temps. Libérez votre verrou quand vous avez terminé pour qu’une autre personne puisse prendre la relève.

Restaurer une conception antérieure​

Ouvrez Historique des modifications pour trouver les points de contrôle précédents. Ceux qui ont été publiés montrent aussi leur numéro de version. Comparer avec le plus récent permet d’examiner les différences de configuration technique entre un ancien point de contrôle et le point actuel.

Pour revenir à une conception antérieure :

1. Sélectionnez Restaurer à côté du point de contrôle souhaité.
2. Vérifiez la conception restaurée dans l’aperçu.
3. Sélectionnez Publier pour en faire la version publique.

Restaurer crée un nouveau point de contrôle avec l’ancienne conception. L’historique intermédiaire reste donc accessible. La restauration seule ne change pas le site public.

C’est l’historique du site, pas une sauvegarde de tous les dossiers du club. Restaurer une mise en page n’annule pas les inscriptions, les paiements ou les modifications des articles et des produits qu’elle affiche. Les sections dynamiques continuent d’utiliser les données actuelles du club.

Pour une première modification, essayez d’améliorer une introduction ou d’ajouter un lien utile. Vérifiez la proposition et l’aperçu, puis publiez quand le résultat vous convient.

Pour Curling IO v3, nous savions que nous voulions quitter la pile Ruby on Rails utilisée pour la version 2. Nous voulions un langage à typage statique avec de meilleures garanties à la compilation et moins de pièges. Nous avons d’abord exploré Gleam, qui répondait à ces critères et nous donnait accès à la BEAM. Lustre offrait un cadre d’interface typé pour le serveur et le client. Une première mise en œuvre nous a permis de voir comment cette combinaison s’intégrerait à notre architecture. Nos premiers articles sur les fondations décrivent ce que nous apprenions et construisions.

Ce travail a aidé à préciser les besoins du produit, les changements souhaités par rapport à la version 2 et la conception de l’interface. Il a aussi révélé des compromis de déploiement et d’interactions côté client qui nous ont finalement amenés à choisir Rust et TypeScript pour notre architecture, avant d’aller plus loin avec Gleam et Lustre. SQLite et la conception du produit ont été conservés. Nous avons depuis porté et enrichi nos outils SQL et construit un petit environnement d’exécution TypeScript appelé Hypertea pour les interactions côté client.

Ce changement a amélioré le déploiement, nous a donné une automatisation utile à la compilation et convenait à notre façon d’examiner et de corriger les problèmes. Malheureusement, il a aussi rendu nos compilations beaucoup plus lourdes. Il y a des aspects de Gleam et Lustre que nous préférons encore.

Ce que nous avons gardé de notre première exploration​

Les besoins du produit, les changements de comportement prévus par rapport à la version 2, la conception de l’interface et le CSS ont été conservés. SQLite aussi. Gleam et Lustre nous ont également aidés à définir l’architecture et la conception voulues. Cette exploration a inspiré ce que nous avons ensuite construit avec Rust et Hypertea.

Nous avons remplacé tout le code Gleam écrit jusque-là. Il n’en reste aucun dans l’application. Utiliser le même langage sur le serveur et le client, l’environnement d’exécution BEAM et Lustre font partie de ce à quoi nous avons renoncé.

Operations, notre système de suivi des erreurs et l’infrastructure NixOS sont arrivés après le passage à Rust.

Nos premiers articles sur les fondations décrivent la conception Gleam de l’époque. Automatiser la gestion du club avec l’IA est aussi issu de ce travail initial.

Déployer Gleam avec SQLite était compliqué​

SQLite fonctionnait très bien pour nous. Préparer sa dépendance native pour la version distribuable Erlang était plus frustrant.

Notre intégration SQLite utilisait un NIF, l’interface d’Erlang vers le code natif. Construire une version distribuable exigeait de gérer ce composant natif et sa compatibilité avec l’environnement de production. Il nous fallait un environnement de compilation Linux assez proche de la production et assez puissant pour la compilation et l’édition de liens. Notre configuration exigeait aussi des composants supplémentaires sur l’hôte de production. Nous n’aimions pas entretenir tout cela simplement pour que SQLite fonctionne dans une version distribuable.

Rust a encore des dépendances natives, dont le code C de SQLite, mais nous compilons les versions Linux nativement sur notre machine de développement, les vérifions et téléversons le paquet. La production n’a besoin ni de la chaîne d’outils Rust ni du code source de l’application.

Ce parcours de compilation pour l’autre environnement nous permet aussi de choisir explicitement la cible de la version.

Nous utilisions à peine les avantages de la BEAM​

L’application avait besoin d’un état durable des tâches dans SQLite, quel que soit l’environnement qui exécutait le travail. Les tâches en attente devaient survivre à la perte d’un processus ou d’une machine. L’environnement d’exécution ne pouvait pas remplacer ce besoin de persistance.

La BEAM offrait toujours la concurrence et la gestion des processus, mais nous n’utilisions plus assez de ses capacités distinctives pour en faire le facteur décisif. Rust avec Tokio répondait aux besoins de concurrence de notre application tout en convenant au parcours de déploiement préféré.

Tokio ne reproduit ni la supervision OTP ni l’isolation des processus de la BEAM. Pour cette charge de travail, nous étions à l’aise d’y renoncer.

Rust excelle pour les outils et le débogage​

Rust et Gleam partagent plusieurs garde-fous qui facilitent la compréhension d’un code : types statiques, valeurs facultatives explicites et filtrage exhaustif. Les agents de programmation bénéficiaient de ces vérifications dans les deux langages. Deux autres éléments favorisaient Rust dans notre expérience.

À l’époque, les agents proposaient généralement des corrections Rust plus idiomatiques. Ils pouvaient produire du code fonctionnel dans les deux langages, mais le code Rust ressemblait plus souvent à celui d’un développeur qui connaît bien le langage.

Les diagnostics détaillés du compilateur Rust ont aidé les agents à vérifier leurs corrections. Les renseignements d’erreur à l’exécution dans notre pile nous ont aussi aidés à retracer les échecs. Ces diagnostics d’exécution dépendent de nos bibliothèques et du contexte d’erreur conservé. Avec les indications du compilateur, ils aident un agent à suivre un parcours inconnu et à vérifier une correction proposée. Du point de vue d’un agent de programmation, c’est peut-être la plus grande force de Rust.

Les macros de dérivation ont aussi beaucoup compté. Serde a été très fiable pour nous. Ses dérivations produisent les implémentations de sérialisation et de désérialisation à partir des types Rust sans que nous entretenions ce code répétitif à la main. Nos outils de contrats s’appuient sur ces types pour produire le côté TypeScript des interfaces d’îlots clients.

Rust Marmot produit des appels de base de données typés à partir de SQL. C’était au départ une bibliothèque Gleam. Elle nous plaisait tellement que nous l’avons portée en Rust, puis continué à l’enrichir et à l’améliorer. Les macros de dérivation Rust ont aussi amélioré Marmot. Sa dérivation FromSqlRow produit les correspondances courantes entre les lignes de requête et les types de l’application, tandis que les conversions métier restent explicites.

Rust Proute a suivi un parcours semblable : conçu en Gleam, puis porté en Rust. Il combine la génération de routes et des paramètres typés, y compris la désérialisation dérivée. La génération de routes et le décodage dérivé remplissent des rôles différents et réduisent tous deux le code de liaison à garder synchronisé.

Entretenir les générateurs​

Marmot et Proute produisent du code applicatif qu’il faudrait autrement écrire et synchroniser nous-mêmes. Marmot produit des appels typés au-dessus de rusqlite; Proute génère le routage. Garder ces rôles précis nous aide à éviter une abstraction plus large que nécessaire. Nos bancs d’essai SQLite publiés ont aussi mesuré un meilleur débit pour Rust Marmot que pour SQLx avec les formes de requêtes testées.

Le code produit est simple. La mécanique derrière ne l’est pas toujours. Marmot doit examiner le schéma de la base de données et transformer les résultats SQL en liaisons typées. Cela exige beaucoup de code, dont l’entretien nous appartient. La génération et les vérifications du compilateur repèrent rapidement de nombreuses erreurs d’interface; elles ne prouvent pas qu’une requête applique la bonne règle métier.

Nous jugeons cette charge gérable. Les générateurs sont documentés et testés, et les diagnostics Rust aident les développeurs comme les agents à y travailler. L’application a des ADR, des règles de responsabilité et des conventions vérifiées pour guider les modifications. Ces éléments, agents compris, aident à intégrer un nouveau développeur. Le jugement appartient toujours à la personne responsable de la maintenance.

SQLite était déjà rapide avec Gleam, mais Rust a presque doublé son débit​

Nous étions déjà satisfaits des performances de SQLite dans Gleam lorsque nous avons mesuré les deux intégrations.

Nos bancs d’essai publiés sur les formes de requêtes comparent directement les intégrations :

Ces tests utilisaient des données synthétiques, des formes de requêtes tirées de la production et un serveur Ryzen 7 9700X avec 62 Gio de mémoire vive. La séquence de lecture exécute environ 26 petites requêtes indexées. La séquence d’écriture exécute une courte transaction avec WAL et synchronous=NORMAL.

Le parcours Rust Marmot utilise rusqlite. Ces mesures couvrent les intégrations complètes de base de données, y compris leurs liaisons et leur code généré. Elles n’isolent pas le coût du NIF et ne mesurent pas le débit de l’application complète. Les gains s’appliquent aux formes de requêtes testées.

Les composants serveur n’éliminaient pas le besoin d’état côté client​

Un composant serveur était pratique jusqu’à ce que l’état doive changer immédiatement sous la main de la personne.

Un panneau ou un menu déroulant géré par le serveur peut fonctionner, mais l’aller-retour n’est pas toujours agréable. Le glisser-déposer rend le problème plus évident : le pointeur et la réaction visuelle doivent rester ensemble. Envoyer chaque position au serveur et attendre une mise à jour du DOM n’était pas le modèle souhaité.

Nous utilisions des îlots clients Lustre dédiés pour les interactions importantes. Le créateur de formulaires, par exemple, avait un hôte serveur sous server/src/server/admin/product/ et son programme de navigateur sous client/src/client/form_builder/. Le paquet serveur ciblait Erlang; le paquet client ciblait JavaScript. Une seule fonctionnalité traversait deux arborescences source.

Il y avait aussi de petits comportements locaux autour des formulaires et de la mise en page. Ils s’accumulaient en fragments JavaScript. Nous aimions la structure typée de l’application et n’aimions pas en sortir pour toutes ces petites interactions.

Le modèle de composants serveur aidait l’administration, mais n’offrait pas le même avantage à notre interface MCP pour agents ou à une éventuelle application native. Cela limitait la part du produit qui pouvait en bénéficier.

Garder TEA, même pour les petits détails​

Après le passage à Rust, nous voulions garder The Elm Architecture côté client. Nous avons considéré Elm, mais voulions aussi que l’ajout d’un petit îlot coûte assez peu pour un panneau, une commande ou un comportement modeste de formulaire.

Nous avons construit Hypertea, un petit environnement d’exécution TypeScript inspiré de Hyperapp et de TEA. Nous utilisons la même structure pour les petites commandes et les grands îlots : état explicite, messages typés, fonction de mise à jour, effets et abonnements gérés. Même une petite interaction reçoit cette structure plutôt qu’un autre fragment JavaScript isolé.

TypeScript strict et l’analyse statique soutiennent ce modèle. Ils repèrent les erreurs de valeurs facultatives, imposent un traitement exhaustif là où c’est configuré et gardent les effets secondaires non gérés hors des modules applicatifs ordinaires. Ce ne sont pas toutes les garanties de Gleam ou d’Elm, et les outils sont moins élégants. Nous trouvons quand même cette façon d’écrire les comportements clients bien meilleure que l’entretien de gestionnaires d’événements dispersés dans l’interface.

Le coût des compilations Rust​

Les compilations ont été pénibles. À mesure que l’application grandissait, une petite modification Rust pouvait exiger une compilation coûteuse de la grosse crate applicative. Un changement de gabarit Maud est du code source Rust. Un changement de requête peut exiger de régénérer les liaisons et de recompiler l’application. Les dépendances en cache peuvent rester à jour, mais l’unité de compilation de l’application demeure grande.

Nous avons désactivé les renseignements de débogage et la LTO en développement. Nous utilisons la compilation incrémentale, limitons les tâches Cargo, sérialisons les vérifications de worktrees concurrents et nettoyons les sorties incrémentales périmées. Ces mesures ont réduit nos temps de compilation, mais pas beaucoup.

Lors d’un essai, un seul processus du compilateur pour un test de bibliothèque a utilisé plus de 10 Gio de mémoire physique sur un portable de 16 Gio. Même les essais de compilation des tests avec une seule tâche ont dépassé un seuil d’arrêt de 8 Gio. Un autre relevé a trouvé des répertoires de compilation de worktree entre 5,7 et 7,9 Gio. C’étaient des artefacts et des caches accumulés, pas la taille de l’exécutable déployé.

Toucher un gabarit d’administration sans changer son contenu a déclenché un cargo check de 21,38 secondes. Cela ne comprenait ni l’édition de liens du serveur, ni son redémarrage, ni l’inspection du résultat. C’était une borne inférieure favorable : le contenu source n’avait pas changé, donc le compilateur pouvait réutiliser plus de travail qu’après une vraie modification du balisage. Pour des retouches répétées de l’interface, le délai devient difficile à ignorer.

Une extraction utile​

Nos générateurs applicatifs vivaient initialement dans le même paquet Cargo que l’application. Les exécuter compilait du code applicatif dont ils n’avaient pas besoin, et une fonction de génération de contrats créait une autre identité de bibliothèque applicative.

Nous avons déplacé les générateurs dans leur propre petit paquet. Dans une comparaison d’août, les temps et l’espace disque ont changé ainsi :

La sortie générée est restée identique. La génération est devenue beaucoup moins coûteuse, même si compiler la grosse application reste cher.

Nous avons aussi étudié le cache de compilation avec sccache. L’admissibilité au cache et sa réutilisation diffèrent entre les dépendances à froid et les modifications incrémentales de l’application. Ajouter un cache ne corrige donc pas automatiquement ces dernières. Il faut mesurer la boucle dans laquelle nous passons réellement du temps.

Avec plusieurs worktrees d’agents, chaque copie de travail accumule aussi son état de compilation. Sérialiser Cargo protège le portable contre les compilateurs simultanés, mais introduit une file d’attente. Une machine de compilation dédiée pourrait éventuellement en valoir la peine. Le coût de compilation nous pousse déjà à revoir le découpage de l’application et l’endroit où nous produisons l’interface.

Nous espérons que séparer des parties de l’application en crates Rust réduira les coûts de compilation. Nous n’avons pas encore établi cet avantage. L’extraction des générateurs a amélioré un parcours précis; l’effet d’un découpage supplémentaire sur les modifications applicatives quotidiennes reste à déterminer.

Ce qui nous manque de Gleam​

Gleam est un langage agréable à utiliser. Les valeurs facultatives explicites, le filtrage exhaustif et un langage petit et cohérent donnent des garde-fous utiles sans rendre le code applicatif ordinaire pénible à écrire. Nous le trouvons encore beaucoup plus agréable à lire et à écrire que Rust. Nous nous sommes habitués à la syntaxe Rust, mais préférons encore celle de Gleam.

Lustre convenait particulièrement bien. Il apportait The Elm Architecture à Gleam : un modèle, des messages, une fonction de mise à jour et une vue. Nous pouvions utiliser cette structure dans les applications de navigateur et les composants serveur, avec des types Gleam partout. Il y avait peu de JavaScript écrit à la main et aucun langage de gabarit distinct à apprendre.

Nous avons décrit l’administration dans Une administration interactive avec Gleam et Lustre. Un processus BEAM de longue durée conservait l’état de la page, traitait les messages et envoyait les mises à jour du DOM par WebSocket. Pour les formulaires, les tableaux et les pages de configuration, c’était une façon productive de construire une interface.

L’accès à la BEAM était un autre avantage important. Ses processus, sa supervision et ses capacités à l’exécution sont de bonnes raisons de choisir cette pile. Dans notre expérience, la boucle de compilation Gleam était aussi considérablement plus légère que celle de notre application Rust, maintenant beaucoup plus grande.

En conclusion​

Gleam et Lustre auraient probablement bien fonctionné pour nous. Nous sommes heureux d’avoir choisi Rust et TypeScript : ils conviennent mieux à notre architecture et à notre façon de travailler, malgré le coût des compilations et ce qui nous manque. La souplesse d’Hypertea a aussi porté ses fruits de façons inattendues, avec WebMCP qui s’appuie directement sur sa conception TEA existante.

Le schéma habituel d’intervention humaine dans un agent IA ressemble à ceci : le modèle demande un appel d’outil, l’environnement d’exécution de l’agent s’arrête, une personne approuve l’appel, puis l’exécution reprend pour permettre à l’outil de s’exécuter.

C’est une conception généraliste raisonnable. Elle est aussi plus stricte que de laisser simplement un agent appeler tous les outils qu’il voit. Pour Curling IO, nous voulions exposer au modèle la plus petite surface possible et placer un garde-fou contrôlé par l’application sur chaque chemin menant à une écriture. Cela nous a amenés à poser une question plus stricte :

Si l’application possède déjà les détails exacts de l’appel, pourquoi redonner le contrôle à l’agent?

Au moment où nous demandons à un gestionnaire de club d’approuver une opération, Curling IO a analysé la requête du modèle, résolu chaque valeur par défaut, vérifié l’état actuel de l’application, produit un aperçu fixe et conservé les arguments exacts. Le modèle n’a plus rien d’utile à apporter à l’exécution. Nous ne le laissons donc pas exécuter l’opération et ne le relançons pas simplement pour donner suite à l’approbation.

L’agent propose. L’application transforme cette proposition en contrat. Une personne approuve le contrat. Rust l’exécute.

Le schéma d’approbation courant​

Le parcours d’intervention humaine du SDK OpenAI Agents peut suspendre une exécution lorsqu’un outil exige une approbation. L’application sérialise le RunState, enregistre les approbations ou les refus pour les appels d’outils en attente, puis reprend l’exécution initiale. L’outil approuvé s’exécute pendant cette reprise.

Les interruptions de LangGraph suivent une structure semblable. Un graphe peut s’arrêter avant un nœud d’outil, laisser une personne approuver, modifier ou refuser l’appel, puis reprendre vers l’outil ou revenir au modèle.

Ces cadres répondent à un problème général. Un agent peut avoir de nombreux outils, des agents imbriqués, du travail de longue durée et plusieurs points où une personne doit intervenir. Dans ce contexte, conserver l’appel d’outil en attente dans un état durable de l’agent est utile.

Le problème de Curling IO est plus restreint. Nous contrôlons l’application, la base de données, les règles d’autorisation, l’interface et chaque opération qu’un assistant peut proposer. Nous n’avons pas besoin qu’un environnement d’exécution générique d’agents conserve l’autorité après qu’une proposition est devenue un état de l’application.

Voici la différence :

Ne pas relancer le modèle après l’approbation a un sens précis. Pendant la préparation d’une proposition, les erreurs de validation qui peuvent être communiquées sans risque peuvent retourner dans la boucle active du modèle pour qu’il corrige sa requête. Si un gestionnaire refuse une proposition, ou si l’exécution constate un changement d’état récupérable, Curling IO enregistre un contexte de révision rédigé par l’application pour le prochain message du gestionnaire. Cela lance un nouveau tour du modèle avec un motif qui peut lui être communiqué sans risque. Un échec interne terminal est plutôt enregistré et signalé comme non réessayable. Le modèle peut s’adapter lorsque c’est utile, mais il ne contrôle jamais l’exécution du contrat approuvé.

Le premier schéma peut être mis en œuvre de façon sûre. Relancer un agent ne modifie pas automatiquement un appel approuvé. Un bon environnement d’exécution devrait conserver l’appel exact et son identité. Pour une application qui maîtrise ses propres opérations, l’exécution suspendue du modèle est un état opérationnel superflu dès que l’application a accepté une proposition complète.

L’approbation humaine ne suffit pas​

Un bouton d’approbation n’a de sens que si l’application peut dire exactement ce qui a été approuvé.

Supposons qu’un modèle demande de rembourser une commande. Une approbation peu précise pourrait afficher :

Rembourser ce client?

Presque toutes les décisions importantes restent alors cachées. Quel paiement? Quel montant? Quelle ligne de commande? Où ira l’argent? Le modèle utilise-t-il une valeur qu’il a calculée lui-même? Pourrait-il choisir une autre destination à la reprise de l’exécution?

Notre vérification de remboursement montre le participant, le produit, le rabais, le paiement, le montant, la destination et le nouveau total de la commande. Le gestionnaire n’approuve pas l’intention générale du modèle de corriger une commande. Il approuve une opération concrète et un ensemble précis d’effets.

Cela exige plus qu’un schéma d’outil. Il faut un contrat contrôlé par l’application qui définit ensemble :

• les champs que le modèle doit fournir;
• les valeurs par défaut que Rust peut résoudre;
• les combinaisons valides et invalides;
• la représentation typée conservée pour approbation;
• la présentation fixe que la personne vérifie;
• la revalidation selon l’état actuel;
• l’exécuteur;
• le résultat typé et sa restitution sûre;
• les événements d’audit de tout le cycle de vie.

Si ces éléments sont répartis entre une consigne, un schéma JSON générique, une page de vérification construite à la main et un exécuteur sans lien avec eux, ils finiront par diverger. Un nouveau champ peut influer sur l’exécution sans apparaître dans la vérification. Une consigne peut décrire une valeur par défaut autrement que l’application. Un modèle peut produire une valeur que l’interface ordinaire n’autoriserait jamais.

Dans Curling IO, tous ces éléments font partie d’une même capacité.

La plus petite surface utile​

Notre premier choix est d’éviter de présenter une large surface à l’agent, avant même de chercher à la protéger.

Chaque assistant est limité à une section de Curling IO et ne reçoit que le contexte nécessaire à la tâche en cours. L’assistant des commandes ne reçoit pas une vue de la base de données de toute l’organisation. L’assistant des courriels n’hérite pas des outils de celui des commandes. L’identité de l’organisation, les permissions, les noms internes de champs, les charges utiles des fournisseurs et les dossiers de clients sans rapport avec la tâche restent du côté de l’application.

La même règle s’applique aux opérations. Un assistant voit un petit catalogue de propositions possibles, plutôt qu’une API d’écriture générique. Les champs présentés au modèle contiennent seulement les choix qui exigent réellement une interprétation. Rust fournit la portée des ressources, résout les valeurs par défaut, calcule les valeurs dérivées, refuse les combinaisons non prises en charge et construit l’aperçu destiné à la personne.

Nous ajoutons ensuite un garde-fou sur chaque voie restante entre la sortie du modèle et l’état durable :

• un contexte limité et rédigé par l’application avant l’appel au modèle;
• des outils de lecture propres à la tâche, dont le serveur contrôle la portée par organisation;
• une analyse et une validation strictes de la requête d’opération du modèle;
• des arguments et des aperçus typés construits par Rust;
• l’approbation humaine de chaque effet important;
• la vérification de l’autorisation, de l’expiration et de l’état au moment de l’exécution;
• l’idempotence aux frontières de la proposition et de l’enregistrement métier;
• des résultats typés, avec les renseignements sensibles masqués, après l’exécution.

Aucune vérification ne garantit à elle seule toute la sécurité. L’approbation humaine ne remplace pas l’autorisation. Un type ne prouve pas que l’état actuel permet encore l’opération. La revalidation n’empêche pas un appel en double au fournisseur après une réponse perdue. La surface reste petite, et chaque frontière conserve son rôle.

La requête du modèle n’est pas la proposition conservée​

Notre assistant des commandes a une opération présentée au modèle appelée propose_payment_refund. Son entrée est volontairement petite. Le modèle identifie le paiement, la ligne de commande, le rabais et la destination demandée à partir des éléments fournis par Curling IO.

Rust ne conserve pas directement cette requête. Il la valide à partir de l’examen de la commande contrôlé par le serveur, calcule le remboursement selon les règles de l’application, résout une destination concrète et crée des arguments typés :

#[derive(Clone, Debug, PartialEq, Eq, Serialize, Deserialize)]
struct OrderRefundArguments {
    order_id: i64,
    payment_id: i64,
    line_item_id: i64,
    discount_id: i64,
    amount_cents: i64,
    refund_destination: RefundDestination,
}

Le modèle ne choisit pas amount_cents. Il ne peut pas dire « utiliser le mode de paiement initial » et remettre cette décision à plus tard. Rust résout cette expression en une valeur concrète de RefundDestination avant que le gestionnaire voie quoi que ce soit.

La présentation à vérifier a un type distinct des arguments exécutables :

#[derive(Clone, Debug, PartialEq, Eq, Serialize, Deserialize)]
struct OrderRefundPreview {
    participant_name: String,
    product_name: String,
    discount_name: String,
    payment_method: PaymentMethod,
    amount_cents: i64,
    current_order_total_cents: i64,
    resulting_order_total_cents: i64,
    currency: String,
    refund_destination: RefundDestination,
    product_configuration_unchanged: bool,
}

Les arguments contiennent ce dont l’exécution a besoin. L’aperçu contient ce dont une personne a besoin pour comprendre les conséquences. Les deux proviennent des mêmes faits métier validés et sont figés ensemble.

JSON apparaît à la frontière de la base de données, mais ce n’est pas le modèle de programmation. Une opération est reconvertie dans son type Rust avant de pouvoir être revalidée ou exécutée. Un type d’opération ne peut pas être aiguillé vers le type d’arguments d’une autre opération.

Une proposition est un état durable de l’application​

Chaque proposition reçoit un identifiant public opaque et une ligne qui contient son organisation, l’administrateur demandeur, la section, la ressource, le type d’opération, les arguments exacts, l’aperçu, l’état et l’expiration. Elle conserve aussi les renseignements sur l’approbation, l’exécution, le résultat et les échecs.

Voici une vue simplifiée du côté Rust :

struct OperationProposal<Arguments, Preview, Result> {
    public_id: ProposalId,
    interaction_id: InteractionId,
    scope: OperationScope,
    requested_by: UserId,
    operation_kind: OperationKind,
    arguments: Arguments,
    preview: Preview,
    status: ProposalStatus,
    expires_at: DateTime,
    approval: Option<Approval>,
    outcome: Option<OperationOutcome<Result>>,
}

struct OperationScope {
    organization_id: OrganizationId,
    section: AssistantSection,
    resource_id: ResourceId,
}

Arguments, Preview et Result sont les types propres à un contrat d’opération. SQLite conserve leur forme sérialisée et les événements d’audit de la proposition, mais le code de l’application ne peut pas exécuter ces valeurs sans les décoder avec le contrat correspondant.

La conversation n’est pas la source de vérité de cette opération. L’état d’exécution conservé par le fournisseur de modèles ne l’est pas non plus. Une proposition en attente survit à une déconnexion du navigateur, à un changement de modèle ou à un déploiement, puisque Curling IO peut reconstruire l’approbation à partir de ses propres enregistrements.

Cela réduit aussi beaucoup l’entrée de la demande d’approbation. Le navigateur transmet l’identifiant opaque de la proposition. Il ne transmet pas une seconde fois le montant du remboursement, sa destination, le corps du message ou toute autre valeur approuvée.

L’approbation crée un seul contrat d’exécution​

Lorsque l’administrateur sélectionne Approuver le remboursement, Curling IO vérifie de nouveau toutes les conditions habituelles de la requête :

• la personne connectée a toujours accès à l’organisation;
• la proposition appartient à cette organisation, à cette section et à cette commande;
• la proposition est encore en attente et n’a pas expiré;
• son type d’opération et ses arguments conservés peuvent encore être analysés;
• la personne actuelle est toujours autorisée à effectuer l’opération sous-jacente.

Seulement alors, la proposition passe de pending à executing. La mise à jour est atomique et produit un contrat d’exécution typé :

struct ExecutionContract<Arguments> {
    proposal_id: ProposalId,
    operation_kind: OperationKind,
    scope: OperationScope,
    arguments: Arguments,
    approved_by: UserId,
    approved_at: DateTime,
}

match proposals.approve_for_execution(proposal_id, administrator, now)? {
    Approval::Claimed(contract) => execute(contract),
    Approval::AlreadyCompleted(outcome) => present(outcome),
    Approval::NotApprovable(reason) => reject(reason),
}

Le dépôt de données ne retourne Approval::Claimed que lorsqu’il fait passer de façon atomique la proposition correspondante, non expirée, de pending à executing. Si une autre requête l’a déjà approuvée, refusée ou terminée, le gestionnaire de requête ne reçoit aucun contrat d’exécution. Il ne reçoit donc pas une seconde autorisation de l’exécuter.

Le modèle ne participe à aucune de ces étapes. L’approbation est une requête authentifiée de l’administrateur à Curling IO, plutôt qu’un autre message dans la conversation.

La revalidation fait partie de l’exécution​

Figer une proposition empêche ses arguments de changer. Cela ne fige pas le reste du monde.

Un paiement a peut-être été remboursé dans un autre onglet. Quelqu’un a pu modifier le public d’une diffusion. L’administrateur a peut-être perdu son accès. Une proposition peut être restée ouverte assez longtemps pour expirer.

L’exécuteur de remboursement recharge donc la commande et prouve que les éléments initiaux restent valides. Il vérifie que :

• la même ligne de commande et les mêmes éléments justifiant le rabais existent encore;
• le montant calculé n’a pas changé;
• le paiement sélectionné existe encore et sa valeur remboursable est suffisante;
• aucune tentative de remboursement non résolue ne rend un nouvel appel risqué;
• la destination concrète reste compatible avec le paiement et le compte.

Si un fait important a changé, l’ancienne proposition est bloquée par défaut. L’application enregistre un résultat qui exige une révision, explique le changement sans exposer de renseignements sensibles et demande au gestionnaire de préparer une nouvelle proposition. Elle ne modifie pas discrètement le montant sous une approbation qui en affichait un autre.

C’est le contrôle de concurrence optimiste exprimé en termes humains. L’aperçu affirme quelque chose sur un état précis. La revalidation prouve que cette affirmation est encore vraie lorsque l’approbation arrive.

L’idempotence doit aller jusqu’à l’enregistrement métier​

L’approbation conditionnelle empêche une même proposition en attente de démarrer deux fois, mais cela ne suffit pas pour les opérations qui ont des effets externes.

Prenons un remboursement de carte en ligne. Curling IO peut envoyer la requête au fournisseur et perdre la réponse HTTP. À ce stade, réessayer peut créer un second remboursement. Le résultat correct n’est pas un échec générique. C’est OperationOutcome::NeedsReconciliation { status_path }.

Le parcours de remboursement conserve des identités stables pour la proposition et le fournisseur, enregistre la tentative non résolue et refuse d’improviser un autre appel. La récupération vérifie la tentative initiale et finit par enregistrer le résultat faisant autorité.

Pour les opérations locales de base de données, la modification métier et le résultat réussi de la proposition sont validés dans la même transaction. Pour les opérations externes, la proposition reste dans un état d’exécution ou de rapprochement jusqu’à ce que la récupération lève l’incertitude.

Approuver de nouveau une proposition terminée retourne son résultat initial conservé. Cela ne fabrique pas un nouveau message de réussite et n’exécute pas l’opération une seconde fois. La répétition concerne la livraison du résultat, pas un nouveau résultat métier.

Cette distinction compte, puisque les réponses HTTP ne sont pas durables. L’enregistrement de l’opération l’est.

Restituer le résultat sans relancer l’agent​

L’application sait déjà ce qui s’est passé. Elle ne devrait donc pas dépenser un autre appel au modèle pour lui demander de le reformuler.

Nous utilisons un petit vocabulaire de résultats typés autour du résultat propre à chaque opération :

enum OperationOutcome<S> {
    Succeeded(S),
    NeedsReconciliation {
        status_path: String,
    },
    RevisionRequired {
        reason: RevisionReason,
    },
    TerminalFailure {
        correlation_id: String,
    },
}

Le S propre à l’opération peut identifier le remboursement et le solde de commande qui en résulte, ou indiquer qu’un brouillon de courriel a été copié dans le formulaire modifiable. L’énumération commune indique ce que la personne et le système peuvent faire ensuite sans risque.

Un résultat conservé alimente plusieurs présentations :

• une réponse localisée dans le navigateur;
• un suivi rédigé par l’application dans la conversation de l’assistant;
• un contexte limité fourni si le gestionnaire envoie un autre message;
• éventuellement, le même résultat sémantique par une API destinée aux agents logiciels.

Le modèle ne classe pas l’échec et ne décide pas si une nouvelle tentative est sûre. Rust s’en charge. Au prochain tour de la personne, un résultat récupérable donne au modèle assez de contexte sûr pour examiner de nouveau la situation ou préparer une proposition révisée.

Pour une violation d’invariant interne ou un contrat conservé corrompu, l’application enregistre elle-même l’erreur opérationnelle. Le modèle et le navigateur reçoivent un message terminal avec un identifiant de corrélation, sans trace de pile ni invitation à continuer d’essayer. Demander à l’agent de soumettre un billet de soutien ajouterait une étape sujette aux échecs tout en écartant le contexte que l’application possède déjà.

Deux assistants ont suffi à faire ressortir la frontière​

Nous avons actuellement deux contrats d’opération, volontairement différents.

L’assistant des commandes peut proposer order.refund_missing_discount. L’approbation peut mener à une opération financière avec un fournisseur externe, des réponses incertaines et du travail de rapprochement.

L’assistant des diffusions de courriel peut proposer email_broadcast.apply_draft. L’approbation copie les filtres, l’objet et le message figés dans un formulaire modifiable. Elle ne crée pas la diffusion et ne l’envoie pas. C’est une opération locale, mais elle recompte quand même les destinataires avant d’appliquer le brouillon. Si le public a changé, le gestionnaire doit obtenir une nouvelle proposition.

Cette différence nous a empêchés de construire un cadre de remboursement et de le présenter comme un cadre d’agents. La partie commune est petite : cycle de vie, identité d’approbation, sémantique des résultats, audit et restitution. Les types d’arguments, les aperçus, la revalidation et l’exécution restent dans l’opération qui les comprend.

Nous prévoyons ajouter des assistants à quelques dizaines de sections. Chaque nouvelle opération nécessitera une requête typée, des arguments figés, un aperçu destiné à une personne, un revalidateur, un exécuteur, un résultat typé et des tests ciblés pour l’expiration, l’état périmé, la répétition et la classification des échecs.

C’est plus de travail que d’ajouter un autre outil de fonction à une consigne. C’est voulu.

Ce que ce schéma apporte et ses limites​

Nous n’avons inventé ni l’approbation humaine, ni les commandes durables, ni le contrôle de concurrence optimiste, ni la sécurité par capacités, ni les clés d’idempotence. La conception emprunte à tous ces concepts. Les cadres d’agents permettent déjà de suspendre les appels d’outils pour vérification.

Le changement utile consiste à traiter la modification demandée par l’agent comme une entrée d’une commande applicative, plutôt que comme la commande elle-même. L’application matérialise un nouvel objet durable dont la sémantique est plus stricte que celle de l’appel au modèle à son origine. Dès que cet objet existe, on peut abandonner l’exécution du modèle.

Ce schéma n’est pas nécessaire pour chaque réponse d’assistant. Les réponses en lecture seule n’ont pas besoin de propositions figées. Un brouillon sans effet sur l’application peut rester un brouillon. Mais si une opération change les données d’un client, envoie quelque chose, déplace de l’argent ou modifie un accès, nous voulons une garantie plus forte que « le modèle a appelé un outil et une personne a cliqué sur Approuver ».

Nous voulons savoir exactement ce que l’application s’est engagée à faire, exactement ce que la personne a approuvé, exactement quels faits actuels ont été revérifiés et exactement ce qui s’est passé ensuite.

C’est le contrat.

Curling IO v3 comprend une assistance intégrée facultative pour la plupart des tâches d’un gestionnaire de club. Elle apparaît dans la section où le travail se fait et utilise le contexte nécessaire à ce travail.

Un assistant peut examiner un problème, expliquer ses constatations et préparer une opération à vérifier. Il exécute cette opération seulement après l’approbation explicite d’un administrateur.

Un changement par rapport à notre plan initial​

Plus tôt cette année, nous avons écrit sur la possibilité pour les clubs de connecter leur propre agent IA à Curling IO. Cette approche laissait le choix et la configuration du modèle au club. Nous avons depuis changé de direction. L’expérience principale passera par des assistants intégrés à Curling IO, avec un fournisseur de modèles externe que nous choisissons et gérons.

Gérer nous-mêmes le fournisseur nous permet de :

• contrôler précisément les renseignements et les opérations accessibles pour chaque tâche;
• exiger du fournisseur de modèles une politique de conservation nulle des données;
• éviter de demander à chaque club de configurer et de payer son propre compte de modèles.

Le fonctionnement devrait aussi coûter moins cher, puisque chaque assistant reçoit le contexte dont il a besoin au lieu de devoir découvrir le fonctionnement du système entier. Lorsqu’un assistant a besoin d’un meilleur contexte, nous pouvons améliorer sa documentation de référence et la conception de sa tâche pour tous les clubs.

Examiner une commande​

Nous avons créé cette situation dans un club de démonstration, puis l’avons traitée avec l’assistant intégré. Les réponses présentées ci-dessous n’étaient pas préparées à l’avance.

Supposons qu’un club offre un rabais Jeunesse de 50 % aux curleurs de 17 ans et moins. Ce rabais est attribué à la plupart des ligues du club, mais un administrateur en oublie une pendant la préparation de la saison.

Madison s’inscrit à cette ligue et la commande est payée au plein tarif. Plus tard, son parent appelle le club. Le gestionnaire ouvre la commande et demande :

Le parent de Madison a appelé. Il a payé le plein tarif, mais pensait que Madison devait recevoir le rabais Jeunesse. Peux-tu vérifier?

L’assistant peut consulter les renseignements pertinents à cette commande. Il vérifie l’âge de Madison au début de la saison, les conditions du rabais Jeunesse, la ligue achetée et les rabais qui lui sont attribués.

Dans ce cas, Madison respecte la condition d’âge. Le problème vient du fait que le rabais Jeunesse n’était pas attribué à la ligue. Il n’a donc pas été pris en compte dans le calcul du prix de la commande.

Cette distinction compte. Le parcours de commande a suivi la configuration du club. L’assistant a trouvé une erreur de configuration probable, mais ne présume pas que le club voulait appliquer le rabais. Le gestionnaire le confirme avant toute modification.

Préparer la correction​

Après que le gestionnaire a confirmé que la ligue devrait offrir le rabais Jeunesse, l’assistant calcule l’ajustement avec les mêmes règles de tarification que le parcours de commande. Il prépare une réduction de la commande et le remboursement correspondant sur le paiement initial. Pour l’inscription de Madison à 275 $, le remboursement proposé est de 137,50 $.

Le gestionnaire peut vérifier le calcul, le paiement à rembourser, la destination du remboursement et le solde de la commande qui en résultera. Rien ne change avant qu’il approuve l’opération. Si le remboursement doit plutôt aller au crédit du compte, il peut refuser la proposition et demander ce changement.

L’approbation corrige cette commande. Elle ne change pas la configuration de la ligue. L’assistant explique que le gestionnaire doit encore ouvrir le produit et lui attribuer le rabais Jeunesse pour que les prochaines inscriptions en bénéficient.

Après l’approbation, la commande montre la réduction de 137,50 $ et le remboursement sur le paiement initial.

Cette limite est voulue. L’assistant des commandes peut examiner et corriger cette commande. Il ne peut pas se mettre à modifier un produit parce que son examen a révélé un problème de configuration du produit.

Nous pourrions éventuellement permettre un transfert explicite de l’assistant des commandes à celui des produits. Pour le moment, chaque assistant reste dans un environnement strictement limité à sa tâche.

Préparer une diffusion de courriel​

Nous avons créé cette situation dans un club de démonstration, puis l’avons traitée avec l’assistant intégré. Les réponses présentées ci-dessous n’étaient pas préparées à l’avance.

Un gestionnaire de club peut aussi demander à l’assistant de préparer un courriel pour un public précis. L’assistant prépare les filtres de destinataires et le message, puis présente la diffusion à vérifier.

Par exemple, un gestionnaire peut demander :

Prépare un court rappel pour toutes les personnes inscrites aux Doubles mixtes du mardi cette saison. Indique que la première séance aura lieu le mardi 7 octobre à 19 h et demande-leur d’arriver 15 minutes à l’avance.

L’assistant teste les filtres demandés séparément du formulaire de diffusion, trouve quatre destinataires correspondants et prépare l’objet et le message. Il présente ensuite le brouillon complet à vérifier. Le formulaire du gestionnaire n’a pas encore changé.

Si le gestionnaire choisit Appliquer à la diffusion, Curling IO copie ces filtres et ce message exacts dans le formulaire modifiable. Le gestionnaire peut encore les modifier, vérifier les destinataires obtenus et utiliser la confirmation d’envoi habituelle lorsqu’il est prêt. Cette étape ne crée pas la diffusion et ne l’envoie pas.

Une portée limitée à la tâche en cours​

Chaque assistant est facultatif et reste inactif tant que personne ne l’utilise. Lorsqu’un gestionnaire demande de l’aide, Curling IO rassemble seulement les renseignements pertinents pour accomplir cette tâche et les fournit au modèle sous une forme limitée et structurée.

L’exemple de commande n’exige pas un accès illimité au club. Il nécessite la commande, les renseignements sur le participant et l’achat qui concernent son prix, ainsi que la configuration des rabais liée à la question. Les commandes et les renseignements sur les membres sans rapport avec cette tâche sont exclus.

Curling IO détermine aussi les outils propres à la tâche qui sont accessibles dans chaque section. L’assistant des commandes peut examiner les prix et proposer une correction de commande. Il ne peut pas modifier un produit. L’assistant des diffusions de courriel reçoit un autre ensemble d’outils de lecture seule pour préparer un public et un message et en afficher l’aperçu.

Le modèle ne peut pas appeler du code arbitraire de l’application ni ajouter des outils à sa tâche. Surtout, il ne reçoit aucun outil qui exécute une opération approuvée.

Traitement des données​

Curling IO exige que le fournisseur de modèles externe qui traite chaque demande à un assistant applique une politique de conservation nulle des données. Le fournisseur peut donc traiter les renseignements fournis pour la demande et retourner une réponse, mais ne peut ensuite conserver ni la demande ni la réponse, ni les utiliser pour entraîner des modèles. La journalisation des demandes par le fournisseur n’est pas activée.

L’approbation fait partie de l’opération​

Préparer une opération et l’exécuter sont deux étapes distinctes. L’assistant peut présenter une proposition, mais ne peut ni l’approuver ni l’exécuter.

Chaque opération a un contrat qui définit les renseignements requis, les valeurs valides, les valeurs par défaut, la présentation pour vérification et les règles d’exécution. Si l’assistant ne peut pas remplir tous les champs obligatoires à partir des renseignements disponibles et qu’aucune valeur par défaut valide n’existe, il doit recueillir d’autres renseignements ou poser une question au gestionnaire.

La proposition contient l’action exacte et tous les paramètres qui peuvent influer sur le résultat. Curling IO conserve cet instantané et utilise le contrat pour produire la présentation que vérifie le gestionnaire. L’assistant ne décide pas des champs à afficher. Pour le remboursement, la vérification comprend le participant, le produit, le rabais, le paiement à rembourser, le montant et la destination du remboursement, ainsi que le nouveau total de la commande. Pour la diffusion, elle comprend les filtres de destinataires, le nombre actuel de destinataires, l’objet et le message complet.

L’approbation transforme cette proposition figée en contrat d’exécution. C’est une requête authentifiée que l’administrateur adresse à Curling IO. Ce n’est pas une demande envoyée au modèle. Le modèle ne reprend pas après l’approbation et ne reçoit jamais de fonction qui puisse exécuter le contrat.

Curling IO charge le contrat conservé et l’exécute dans le code de l’application. Aucun modèle ne fonctionne à cette étape. Ses paramètres ne peuvent donc pas changer entre la vérification et l’exécution. Le contrat est à usage unique. Un lot, une autre action ou tout changement important exige une nouvelle proposition et une autre approbation.

L’approbation ne contourne pas le fonctionnement habituel de l’application. Curling IO vérifie les permissions de l’administrateur, valide l’état actuel et applique les mêmes règles de gestion que l’interface ordinaire. Si l’opération n’est plus valide au moment de l’approbation, elle est refusée plutôt qu’exécutée à partir de renseignements périmés.

Si le gestionnaire choisit Refuser, Curling IO enregistre cette décision et lui demande ce qu’il souhaite changer. Son prochain message poursuit la même conversation, avec le refus dans le contexte. La proposition refusée ne peut plus être approuvée par la suite.

La création de la proposition, son approbation, son refus, son exécution et l’enregistrement qui en résulte sont consignés dans un journal d’audit. Les opérations qui peuvent être réessayées conservent aussi l’identité de la proposition pour qu’une requête interrompue ne puisse pas exécuter le même contrat deux fois.

D’ici le lancement de Curling IO v3, nous ajouterons des assistants à d’autres sections. Chacun aura ses propres renseignements et contrats liés à sa tâche. La limite imposée par l’approbation restera la même.

Les clubs doivent souvent envoyer des renseignements sur les achats à des systèmes externes à Curling IO. Il peut s’agir de mettre à jour un tableur, d’aviser le personnel ou de lancer un processus dans un autre service.

Les locations en sont un exemple. Quelqu’un peut devoir préparer le salon, réserver des tables, organiser un service de traiteur ou ajouter la réservation au tableur du personnel.

Les webhooks de Curling IO v3 peuvent envoyer cet achat de produit à Zapier, n8n ou un autre point de terminaison HTTPS lorsqu’il est soumis, payé, annulé ou déplacé à une autre heure.

Choisir les produits à surveiller​

Un webhook envoie un seul type de notification à une seule destination. Un club peut envoyer :

• tous les produits;
• les produits de certains types sélectionnés, comme les locations;
• des produits individuels, comme quatre options précises de location pour entreprises.

Le filtre de produits offre ces trois portées. Si deux destinataires doivent recevoir des produits différents, l’administrateur crée un webhook distinct pour chaque destinataire et chaque portée.

Les locations et leurs extras sont des produits. La même configuration de webhook fonctionne aussi pour les adhésions, les ligues, les programmes et les autres produits.

Un webhook peut envoyer tous les produits, certains types de produits ou des produits individuels. Celui-ci envoie les achats de locations payés à Zapier.

Choisir le moment de l’envoi​

Un webhook utilise un seul déclencheur :

• Un produit est soumis après la finalisation de la commande.
• Un produit est payé en totalité la première fois que sa ligne de commande est entièrement payée.
• Un produit est annulé lorsqu’une affectation de remboursement annule la ligne de commande. Réduire sa quantité ou sa valeur n’envoie pas cette notification.
• Un produit est replanifié lorsqu’un administrateur change l’heure de début du produit acheté dans le calendrier.

Un processus qui exige plusieurs déclencheurs peut utiliser des webhooks distincts vers la même destination.

Choisir ce que reçoit le destinataire​

Le club choisit les champs d’achat envoyés par chaque webhook. Les nouveaux webhooks commencent avec 16 champs recommandés qui couvrent la commande, l’inscription, le produit, les prix et l’horaire. Les renseignements sur l’acheteur et le participant ne sont pas sélectionnés par défaut.

Les champs sont regroupés et peuvent être recherchés. Un administrateur peut sélectionner un groupe entier, le désélectionner ou revenir à la sélection recommandée. L’aperçu de la charge utile se met à jour immédiatement. Le club peut donc voir les clés JSON et des valeurs représentatives avant d’enregistrer ou d’envoyer un test.

Cet exemple utilise une petite sélection de champs pour montrer toute la charge utile. Les détails de livraison sont toujours inclus; les autres clés suivent la sélection enregistrée.

Les champs sur l’acheteur et le participant portent la mention Sensible. Les questions personnalisées sur les participants et les inscriptions portent la mention Peut être sensible, puisque cela dépend de la question. Curling IO avertit l’administrateur, mais laisse le club décider si la destination doit recevoir ces renseignements. Les mots de passe, les jetons d’authentification, les données de carte de paiement et les secrets des fournisseurs de paiement ne peuvent pas être sélectionnés.

Curling IO accepte uniquement des URL HTTPS publiques comme destinations, ce qui chiffre la requête pendant son transport. Curling IO ne contrôle pas la façon dont Zapier, n8n ou un autre service destinataire traite les données après leur livraison et n’est pas responsable de ce traitement par un tiers. Le club est responsable du choix du service et des champs qu’il lui envoie.

Tester le destinataire avant d’activer le webhook​

L’administrateur peut laisser un webhook désactivé et sélectionner Envoyer un test. Le test utilise la sélection de champs enregistrée et le véritable parcours de livraison. Il contient une location représentative pour que Zapier ou n8n puisse découvrir les champs JSON sélectionnés avant l’activation du webhook.

Dans Zapier, utilisez un déclencheur Webhooks by Zapier > Catch Hook. Dans n8n, utilisez un nœud Webhook. Copiez l’URL HTTPS du destinataire dans Curling IO, envoyez le test et associez les champs avant d’activer l’automatisation.

Fiabilité des livraisons​

Les appels de webhook s’exécutent en arrière-plan. Curling IO réessaie jusqu’à cinq fois en cas de panne réseau, de délai d’attente dépassé, de limite de débit ou d’erreur du serveur. Le destinataire peut utiliser l’identifiant stable de publication du webhook pour éliminer un doublon si une requête réussit, mais que sa réponse se perd.

Chaque requête est signée avec HMAC-SHA256 pour les destinataires qui peuvent vérifier la signature. Un déclencheur Catch Hook de Zapier repose normalement plutôt sur son URL difficile à deviner. Cette URL doit donc être traitée comme un mot de passe.

Les administrateurs peuvent consulter les Livraisons récentes, voir les tentatives et les codes d’état HTTP, réessayer une livraison échouée encore conservée, renouveler le secret de signature ou désactiver le webhook. Les données détaillées de charge utile et de livraison sont supprimées après 30 jours. Chaque livraison conserve le corps exact de sa requête, et chaque nouvelle tentative renvoie ce même corps, même si la sélection de champs ou les données d’achat changent par la suite.

Les livraisons récentes montrent les requêtes réussies, les tentatives échouées, les codes d’état HTTP et le moment où une livraison échouée peut être réessayée.

Consultez le guide de configuration des webhooks pour la charge utile, les étapes dans Zapier et n8n, les règles de nouvelle tentative et la vérification des signatures.

Curling IO v3 comprend un nouvel écran de planification des séances pour les parties d’événement. L’horaire est une grille de séances et de ressources du club, avec les parties non attribuées dans une file à côté. Vous pouvez déplacer les parties par glisser-déposer, verrouiller certains placements et utiliser Répartir et Optimiser en respectant ces verrous.

Contrairement à un générateur de modèles d’horaires distinct, cet éditeur travaille avec les vraies équipes, étapes, parties, ressources et heures de séance de l’événement. Enregistrer l’horaire met directement l’événement à jour.

Vous pouvez déjà essayer la plupart de l’interface sur CurlingSchedules.com. Elle utilise des équipes génériques et des sauvegardes locales au navigateur plutôt que les parties réelles d’un événement. La grille, le glisser-déposer, les verrous, les horaires du catalogue, l’inspection de l’équité et l’optimisation sont toutefois disponibles dès aujourd’hui.

L’éditeur de la version 3 réunit la file de parties, les commandes d’événement, les heures de séance, les ressources et les parties planifiées dans une vue.

L’outil de planification des séances​

La version 2 génère des modèles d’horaires et utilise des listes déroulantes pour placer les parties. Elle n’a ni cet éditeur, ni le catalogue canonique complet, ni les verrous de partie ou l’optimisation locale autour des changements manuels.

L’éditeur de la version 3 permet de :

• Déplacer les parties entre l’horaire et la file par glisser-déposer.
• Modifier les heures, ajouter des séances en plaçant des parties, ou supprimer une séance et remettre ses parties dans la file.
• Verrouiller une partie pour que Répartir et Optimiser la laissent en place.
• Répartir les parties de tournoi à la ronde, les parties ponctuelles et les parties de tableau selon leurs règles d’ordre distinctes, en incluant les parties en attente sur demande.
• Remplir les pistes inutilisées avec des parties de la prochaine ronde logique lorsque des séances compactes comptent davantage qu’une nouvelle rangée par ronde.
• Voir précisément les parties à l’origine des valeurs Maximum de répétitions sur une piste, Total des répétitions et Répétitions consécutives.
• Ajouter une partie ponctuelle à un tournoi à la ronde précis pour qu’elle fasse partie de ses classements et pointages.
• Importer des affectations CSV pour des parties existantes sans recréer la structure de compétition.
• Enregistrer l’arrangement actuel comme modèle d’horaire du club ou appliquer volontairement un modèle correspondant.
• Partir d’un horaire canonique validé, puis optimiser les changements propres à l’événement sans déplacer les parties verrouillées.

Ces règles sont propres au curling. Le répartiteur distingue les parties de tournoi à la ronde, ponctuelles et de tableau. Il comprend les rondes logiques qui peuvent s’étendre sur plusieurs séances, tient compte des ressources sélectionnées et des placements fixes, et mesure les retours des équipes sur une même piste, y compris les séances consécutives. Il place les parties ponctuelles après les parties de tournoi à la ronde des équipes concernées, puis les parties de tableau déverrouillées après les parties de tournoi à la ronde et ponctuelles. Une partie verrouillée échappe à ces règles de placement.

Lorsqu’un événement contient un tournoi à la ronde complet et aucun verrou incompatible, Répartir vérifie notre catalogue avant toute recherche dans le navigateur. Plusieurs itérations répètent la disposition correspondante du catalogue comme point de départ. Un modèle du club correspondant est présenté séparément et appliqué seulement si le responsable de l’horaire le choisit. Lorsque des verrous, parties ponctuelles, étapes multiples ou placements manuels changent le problème, l’optimiseur du navigateur travaille à partir de l’horaire réel.

Le verrou bleu indique un placement que la répartition automatique doit conserver. La file contient une deuxième rencontre ponctuelle entre A et B, prête à placer.

Voir le parcours de planification des séances​

Ce tutoriel montre comment configurer, répartir, modifier, inspecter, optimiser, enregistrer et réutiliser un horaire de séances d’événement.

Pour les responsables d’horaires : comment nous avons construit le catalogue​

La suite devient technique. Elle explique la notation des horaires, les algorithmes testés, les solveurs exacts et la distinction entre les meilleurs horaires trouvés et les optimums prouvés. Vous êtes prévenus!

Le système de la version 3 a deux parties de calcul. Une application Rust hors ligne cherche et valide des horaires de base et prouve parfois leur optimalité. Un optimiseur JavaScript traite les changements propres à l’événement dans le navigateur : parties verrouillées ou ponctuelles et étapes de compétition partageant les mêmes ressources.

Le travail hors ligne a produit un catalogue versionné couvrant les 736 combinaisons de 2 à 24 équipes et de 1 à 16 pistes, selon les deux modes pris en charge de regroupement dans les séances. Curling IO v3 charge directement ce catalogue pour répartir un horaire d’événement.

Le catalogue contient actuellement 449 dispositions : 419 prouvées optimales et 30 meilleurs résultats trouvés jusqu’ici. Cela comprend 448 exigences distinctes dans l’enveloppe pratique et un cas historique hors norme conservé pour compatibilité.

Objectif de planification​

Nous évaluons l’équité des pistes comme un tuple ordonné :

1. Maximum de retours : le plus grand nombre de visites supplémentaires d’une équipe sur une piste.
2. Total des retours : chaque visite de chaque équipe après sa première sur une piste.
3. Retours consécutifs : les cas où une équipe joue sur la même piste dans des séances voisines.

Plus bas est meilleur. Nous comparons le premier nombre, puis le deuxième, puis le troisième. Le temps d’exécution ne compense jamais un horaire moins bon.

Pour huit équipes et quatre pistes, (1, 24, 0) signifie qu’aucune équipe ne visite une piste plus de deux fois, qu’il y a 24 retours au total et qu’aucune ne revient sur la même piste dans des séances consécutives.

Ces 24 retours sont inévitables. Huit équipes font 56 visites équipe-piste en sept séances, pour seulement 32 combinaisons uniques. Même un horaire parfaitement équilibré a au moins 56 - 32 = 24 retours. Atteindre cette borne inférieure avec au plus une visite supplémentaire et aucun retour consécutif prouve qu’il n’y a rien à améliorer selon nos règles de notation.

Les statistiques sont inspectables dans l’éditeur. En sélectionner une met en évidence les parties et équipes qui l’ont produite.

Nous avons choisi un tuple ordonné plutôt qu’une note pondérée, car les poids cachent les compromis. Éviter la sixième visite d’une équipe sur la piste A vaut-il trois nouveaux retours consécutifs ailleurs? Une note scalaire ne répond qu’après l’invention d’un taux de conversion. Le tuple rend les priorités explicites.

L’IA est-elle bonne pour générer des horaires de séances?​

Nous avons testé si les modèles IA généralistes actuels pouvaient produire ces horaires à partir d’une demande normale de responsable d’horaire. Le test portait sur un appel direct unique au modèle, pas sur un agent ayant accès à notre validateur ou à une boucle de correction.

La formulation a demandé du travail. Les premières demandes, pourtant tout à fait naturelles, retournaient souvent des affrontements manquants ou en double, surtout avec un nombre impair d’équipes. Nous les avons affinées pour approcher les précisions qu’un responsable donnerait dans une courte conversation. La version finale indiquait le nombre de parties attendu, demandait un seul tableau Markdown et demandait au modèle de vérifier son travail. Elle ne fournissait ni liste des affrontements, ni nombre minimal de séances, ni tuple d’équité, horaire en cache, méthode du cercle ou autre algorithme.

Seuls le nombre d’équipes, le nombre de pistes, les libellés et le nombre attendu de parties changeaient pour les autres cas de test.

Nous avons envoyé cette demande figée à OpenAI et Anthropic par leurs API directes. Nous avons ajouté Gemini dans un passage distinct par OpenRouter, fixé sur Google AI Studio sans repli de fournisseur. Chaque modèle a reçu une fois les mêmes cinq cas : 8 équipes sur 4 pistes, 8 sur 2, 9 sur 4, 11 sur 5 et 14 sur 7. Chaque requête partait d’un contexte neuf d’un seul message, utilisait le raisonnement par défaut du fournisseur et avait une limite stricte de cinq minutes. Nous avons conservé toutes les réponses, y compris les dépassements de délai.

La disposition familière à 8 équipes et 4 pistes est publiée depuis des années et pourrait apparaître dans les données d’entraînement. Nous l’avons gardée comme cas d’étalonnage, pas comme preuve que le modèle avait trouvé la réponse lui-même. Nous avons aussi exclu de ce tableau les essais informels dans les applications de clavardage grand public, qui peuvent ajouter des instructions cachées, du routage de modèles et des réglages de raisonnement.

Les résultats ont été analysés et vérifiés indépendamment. Le formatage sans conséquence pouvait être normalisé, mais l’évaluateur ne pouvait pas ajouter ou retirer une partie, changer un affrontement ou améliorer une affectation de piste. Un horaire devait contenir chaque affrontement exactement une fois, limiter chaque équipe à une partie par séance et passer le même calcul d’équité que Drawmaster. Les horaires non valides ne recevaient aucune note d’équité.

Les jetons de raisonnement sont inclus dans les totaux de sortie, sans être comptés une deuxième fois. Un passage sur cinq cas constitue une base utile, mais pas un classement statistiquement robuste des modèles.

OpenAI et Claude ont retourné un horaire valide au nombre minimal de séances pour chaque cas. OpenAI a égalé ou dépassé Claude dans les cinq cas. L’équité des pistes donne toutefois un autre résultat :

Gemini a terminé chaque demande en 5,1 secondes ou moins, mais trois de ses cinq horaires étaient non valides. Les réponses 8×4 et 14×7 répétaient des affrontements malgré leur affirmation que chaque paire avait été vérifiée. La réponse 9×4 répétait deux affrontements et plaçait une équipe deux fois dans sa dernière séance. Ses deux horaires valides utilisaient le nombre minimal de séances, mais aucun n’égalait l’équité du catalogue.

Notre recherche Rust simple à départ neutre a égalé le meilleur résultat d’OpenAI dans les cinq cas, avec quelques secondes de travail local combiné par cas. Le processus hors ligne beaucoup plus lourd a ensuite produit le catalogue actuel, meilleur dans quatre cas et égal dans le cinquième.

L’IA reste utile comme générateur supplémentaire de candidats hors ligne. Elle peut trouver un horaire manqué par nos méthodes. Nous traitons simplement sa réponse comme tout candidat non fiable : l’analyser, valider chaque affrontement et conflit, calculer la note nous-mêmes et prouver l’optimalité lorsque possible. Pour les horaires personnalisés, l’optimiseur du navigateur travaille autour des verrous et parties supplémentaires dans une limite de 100 ms, plutôt que de demander à un modèle généraliste de reconstruire l’horaire à partir de texte.

Enveloppe de recherche​

Notre enveloppe pratique comprend :

• De 2 à 24 équipes.
• De 1 à 16 pistes sélectionnées.
• Un tournoi à la ronde complet.
• Une itération.
• Aucune partie verrouillée, ponctuelle ou de tableau.
• Deux comportements lorsqu’une ronde logique s’étend sur plusieurs séances : commencer chaque ronde dans une nouvelle séance ou remplir les pistes vides avec des parties de la ronde suivante.

Cela donne 23 × 16 × 2 = 736 clés de recherche.

Les deux réglages de regroupement ne produisent pas toujours des dispositions différentes. Si toutes les parties d’une ronde tiennent dans une séance, aucune piste vide ne peut accueillir la ronde suivante. Regrouper ces cas équivalents réduit l’enveloppe à 448 exigences de disposition distinctes. Le catalogue stocke 449 dispositions parce qu’il conserve aussi une forme historique hors enveloppe : 26 équipes sur 7 pistes.

Cette frontière n’était pas arbitraire. Nous avons analysé les données Curling IO. Parmi des milliers d’horaires générés d’une seule itération avec peu de pistes, 98 % avaient au plus 20 équipes et 8 pistes. Les cinq formes les plus courantes étaient 8×4, 12×6, 6×3, 10×5 et 9×4, soit 63 % de cette cohorte.

Nous avons étendu la couverture à 16 pistes, car les dispositions avec des pistes excédentaires sont peu coûteuses à stocker et utiles à prendre en charge. Nous avons ensuite porté la limite d’équipes à 24. Les cas historiques hors norme de 42 équipes ne justifiaient toujours pas d’étendre autant la cible interactive.

Banc de recherche​

L’implémentation CurlingSchedules d’origine avait déjà un générateur circulaire de tournoi à la ronde, un répartiteur glouton de pistes, des ajustements locaux et un petit cache de correspondances exactes. Nous avions aussi beaucoup expérimenté, notamment avec une branche de recuit simulé.

Le premier problème était la mesure. Des essais historiques utilisaient des poids différents, d’autres une ancienne définition du maximum de répétitions, et certains tests ne vérifiaient pas ce qu’annonçait leur nom. Les résultats de fonctions objectifs différentes n’étaient pas directement comparables.

Nous avons créé une application Rust comme banc de recherche avec :

• Un modèle d’horaire de référence et un validateur indépendant.
• Des cas de test et des graines déterministes.
• Des stratégies de recherche interchangeables.
• Des comparaisons appariées à budgets égaux.
• Des rapports texte, JSON et CSV.
• Une pondération selon les fréquences de production des données Curling IO.
• Des points de contrôle atomiques permettant de reprendre les longues recherches.
• Un catalogue versionné où chaque disposition porte sa méthode, sa graine, son effort, son temps d’exécution, sa borne inférieure et son statut de preuve.

Les horaires générés passent par la recherche heuristique, les méthodes exactes et un validateur indépendant avant d’entrer au catalogue versionné.

Les dispositions en cache servaient de cibles de comparaison, jamais d’entrées de recherche. Chaque algorithme devait produire son résultat à partir des mêmes conditions initiales générées.

Rust convenait bien à ce travail pour plusieurs des raisons de notre choix du langage côté serveur de Curling IO v3. L’exécution native permettait d’évaluer beaucoup de candidats. Le système de types rendait difficile le mélange d’un horaire partiel non valide avec un résultat censé être valide. Le même banc pouvait effectuer des comparaisons limitées ou reprendre de longues recherches exactes. C’était un petit projet de recherche appelé à changer constamment, mais l’exactitude comptait toujours.

Algorithmes évalués​

Aucun algorithme ne gagnait sur tous les cas. Le processus hors ligne final combine des méthodes aux coûts et forces différents.

Recherche locale​

L’optimiseur le plus simple essaie un échange légal de parties et le conserve seulement si le tuple s’améliore. Notre version de profondeur deux essaie un deuxième échange même si le premier est très mauvais. Elle garde les deux seulement si le résultat combiné bat l’horaire intact. Sur 20 départs neutres à huit équipes, la profondeur deux a battu la recherche à un échange 16 fois et atteint deux fois l’optimum connu.

La profondeur trois a encore amélioré les chances sans dominer la profondeur deux. Sur 1 000 départs appariés, elle a gagné 394 fois, fait égalité 310 fois et perdu 296 fois. La profondeur quatre a ensuite perdu plus souvent qu’elle n’a gagné contre la profondeur trois. De plus grands voisinages ouvraient des chemins, mais dépensaient aussi davantage du budget fixe à en explorer d’inutiles.

Le ciblage aidait plus régulièrement. Nous choisissions surtout les parties sources parmi les affectations équipe-piste qui bloquaient la prochaine réduction du maximum de répétitions. Nous avons ensuite ajouté une mémoire taboue pour parcourir des états d’équité égale encore inexplorés plutôt que de rebondir entre les mêmes arrangements.

Le cas classique 8×4 a tout de même montré la limite des déplacements locaux. Une vérification exacte a prouvé qu’un regroupement précis d’affrontements ne pouvait pas faire mieux que (1,24,5). L’optimum global était (1,24,0). Aucune permutation de pistes dans ce regroupement ne pouvait combler l’écart : il fallait regrouper les affrontements autrement entre les séances.

C’est une limite de la recherche locale. Certaines améliorations exigent de changer les parties qui partagent une séance, au-delà de leurs pistes.

Recuit simulé​

Nous avons essayé le recuit simulé deux fois : dans l’ancienne implémentation Gleam, puis dans une expérience Rust volontairement plus petite. La grande version historique avait des courbes de température, du réchauffement, des redémarrages, des poids de déplacement adaptatifs, des cycles de pistes, des rotations de séances, des déplacements ciblés et plusieurs phases. Elle conservait le meilleur candidat. Retourner un état chaud dégradé n’expliquait donc pas sa performance.

Compte tenu de l’effort consacré à comprendre et à implémenter le recuit simulé, les résultats étaient décevants. La petite version Rust rendait la comparaison plus fiable. Elle restait compétitive sur 8×4, mais perdait sur l’ensemble plus large des cas. Le recuit apportait de la diversité au portefeuille pour une forme, sans preuve suffisante pour en faire une stratégie générale.

Nous avons conservé ce résultat négatif dans le dossier de recherche. Affiner davantage les températures était moins prioritaire que les approches améliorant plus de cas avec le même budget d’évaluation.

Reconstruction et portefeuilles​

La reconstruction gloutonne conserve les séances et les règles de compétition, mais refait les affectations de pistes à partir d’un nouvel ordre déterminé par une graine. Cinq départs reconstruits indépendants ont battu cinq départs ordinaires avec le même budget total d’évaluation. Cela ne résolvait pas tous les cas, mais atteignait des bassins invisibles à la recherche par échanges seuls.

Notre portefeuille hors ligne a fini par conserver des processus de reconstruction et de population indépendants, avec une voie distincte qui exploitait le meilleur candidat validé trouvé jusqu’ici. Forcer tous les processus à repartir du meilleur résultat global réduisait la diversité sans aider. Le partage devenait utile seulement comme travail supplémentaire, sans remplacer la recherche privée de chaque processus.

Nous avons donc ajouté des points de contrôle pour l’état privé de chaque processus et le meilleur résultat global. Une longue recherche peut s’arrêter et reprendre en conservant les deux.

Méthodes exactes et constructions​

La recherche heuristique fournissait de bons candidats, mais prouver l’optimalité exigeait des méthodes exactes.

Nous les avons ajoutées par couches plutôt que de donner tout le problème à un seul solveur :

1. Affectation de pistes à séances fixes : garde les affrontements et la composition des séances, puis résout seulement la piste de chaque partie.
2. Modèles de rondes logiques : peuvent répartir de nouveau les parties entre les séances d’une ronde en conservant ses frontières.
3. Recherche de factorisation compacte : choisit le regroupement d’affrontements et les pistes pour les petits horaires à séances pleines.
4. Requêtes de réparation bornées : demandent si une cible connue est atteignable dans un rayon donné d’une bonne solution courante.
5. Constructions combinatoires : génèrent directement des familles de plans connues, comme les plans de tournois équilibrés partitionnés.

Le solveur de contraintes à séances fixes a amené plusieurs formes courantes à leur borne inférieure globale. Un passage exact ultérieur a prouvé l’optimalité de 64 des 74 dispositions à beaucoup de pistes encore non résolues, environ 86 %. La séparation-évaluation compacte a aussi prouvé la borne inférieure 10×5 à partir d’entrées générées, sans lire l’horaire en cache, et traité de petits horaires à nombre impair d’équipes avec des couplages presque parfaits.

Les résultats exacts ont aussi montré les limites de la formulation de recherche. Un tournoi à la ronde 16×8 est un plan de tournoi équilibré partitionné de côté huit. Une construction publiée de type starter-adder a produit directement la borne globale (1,112,0). La recherche locale stagnait parce qu’un bon horaire heuristique exigeait de changer au moins 41 placements partie-piste dans sa composition de séances existante.

Pour 19 équipes sur 9 pistes, la réparation bornée ne pouvait pas atteindre (1,171,17) en changeant au plus 10 cellules. Nous avons retiré les variables redondantes et encodé directement la condition de borne inférieure : chaque équipe utilise chaque piste exactement deux fois. Z3 a trouvé (1,171,0) sur la structure cyclique d’affrontements existante. La solution différait des pistes de départ dans 151 des 171 cellules de parties, environ 88 %. Le rayon de réparation locale excluait les solutions pertinentes.

Nous avons ensuite exécuté une finition exacte sur l’ordre des rondes. Chaque ronde logique complète devient un bloc. La méthode cherche le meilleur chemin entre ces blocs sans changer les affrontements, les pistes ou les parties réunies dans une séance. Cela a amélioré 28 entrées du catalogue et prouvé l’optimalité de 23. Le passage refuse délibérément les horaires compacts dont les séances traversent les frontières de rondes plutôt que de deviner les regroupements.

Un court balayage de contraintes a produit 51 preuves supplémentaires. Quarante-neuf ont terminé en moins d’une seconde sur la machine de développement. Le plus grand écart de retours consécutifs restant concernait 17 équipes sur 8 pistes : il est passé de (1,136,16) à la borne globale (1,136,0) en environ 25 secondes. Les deux modes de regroupement à 13 équipes et 4 pistes restaient non résolus après une tentative d’une minute.

Enfin, nous avons généralisé l’énumérateur de rondes complètes pour permettre des pistes excédentaires. Il a épuisé six petits espaces de recherche, prouvé les six optimums et amélioré l’entrée à 6 équipes et 5 pistes de (1,3,0) à (1,2,0). Ces preuves comptent, car la borne inférieure générique peu coûteuse n’est pas atteignable pour toutes les formes.

Dix-sept dispositions étaient encore marquées comme meilleurs résultats trouvés. La parité des degrés du graphe et une borne de transition sur une seule piste en ont prouvé 12 sans changer les horaires. Des constructions cycliques par différences d’arêtes ont ensuite résolu les formes à 9 et 13 équipes sur deux pistes. Des recherches complètes de coloration d’arêtes, d’appariement de séances et d’ordre des séances ont résolu celles de 6 et 7 équipes sur deux pistes.

Le dernier cas était 9 équipes sur 8 pistes. Les horaires complets avaient trop de symétries. Nous avons donc séparé le problème en plus petits problèmes exacts. Un modèle pseudo-booléen a d’abord affecté les 36 parties aux pistes. Une factorisation exacte a ensuite formé neuf séances légales, puis une recherche de chemin hamiltonien les a ordonnées sans retours consécutifs. Le résultat est passé de (1,5,0) à la borne globale (1,4,0).

Nous avons ensuite étendu le catalogue à 24 équipes. Des plans publiés de tournois équilibrés partitionnés ont fourni des horaires exacts à 22 équipes et 11 pistes, puis à 24 équipes et 12 pistes. Séparer leurs deux moitiés équilibrées a aussi prouvé neuf formes à pistes excédentaires. L’ordre exact des séances et la construction existante de séparation pour les nombres impairs ont prouvé 14 autres dispositions. Les nouvelles formes restantes reçoivent toujours un horaire validé en cache, mais gardent Optimiser disponible pendant leur étude hors ligne.

Couverture et statut de preuve​

La révision 23 du catalogue résout toutes les formes d’équipes et de pistes dans l’enveloppe pratique de 2 à 24 équipes et de 1 à 16 pistes. Sur les 449 dispositions stockées, 419 sont prouvées optimales et 30 gardent des meilleurs résultats trouvés validés.

Parmi les 419 dispositions prouvées, 392 atteignent la borne inférieure globale générique. Les 27 autres exigent une preuve plus précise : 16 utilisent une borne de parité des degrés du graphe, une utilise une borne de transition sur une piste et dix utilisent une recherche exhaustive. La forme impaire à cinq équipes et deux pistes en est un exemple. L’énumération exacte a prouvé que quatre retours consécutifs ne pouvaient pas être éliminés. De petites formes à pistes excédentaires donnent d’autres exemples, car des parties partageant une séance doivent encore avoir des pistes distinctes.

Chaque recherche dans l’enveloppe définie a un résultat validé en cache. Les 30 meilleurs résultats trouvés restent dans la file d’amélioration. Les dispositions prouvées restent dans la suite de régression, mais ne reçoivent plus de budget de recherche hors ligne tant que l’enveloppe ou les règles de notation ne changent pas.

Rust hors ligne et JavaScript dans le navigateur​

Précalculer les dispositions ordinaires change le rôle de l’optimiseur du navigateur. Il sert aux horaires qui ne correspondent plus aux entrées canoniques.

Un événement réel peut avoir :

• Plusieurs groupes de tournoi à la ronde qui partagent des pistes.
• Plusieurs itérations, où combiner des dispositions canoniques crée de nouveaux motifs de répétition.
• Des parties verrouillées que Répartir et Optimiser ne doivent pas déplacer.
• Des parties ponctuelles pour compléter des tournois à la ronde déséquilibrés.
• Des parties de tableau qui doivent suivre leurs prédécesseurs.

Ces combinaisons sont trop propres aux événements pour un cache global. Elles ont toujours besoin d’une optimisation immédiate et réversible dans l’éditeur.

L’optimiseur du navigateur fonctionne dans un Web Worker annulable avec une limite stricte actuelle de 100 ms. Il conserve toujours l’entrée et le meilleur résultat valide trouvé. Un temps plus long peut donc ne rien améliorer, mais ne peut pas retourner un horaire moins bon.

Son répartiteur actuel utilise trois grandes politiques :

• Ordinaire : un horaire déverrouillé qui demande une amélioration locale générale.
• Réparation sous contraintes : des verrous ou placements fixes rendent la stabilité importante.
• Compatible avec les tableaux : l’ordre des parties et les frontières fixes des séances comptent davantage qu’une reconstruction plus large.

Il consacre 70 % du délai à la recherche de profondeur deux, puis le reste à la voie de réparation choisie. La voie compatible avec les tableaux garde la profondeur deux pendant tout le délai. Sur 700 cas de banc d’essai appariés, ce répartiteur à trois politiques a battu l’ancien sélecteur à cinq voies 22 fois, fait égalité 666 fois et perdu 12 fois.

Ce résultat apparié appuyait le répartiteur plus simple. Il retourne presque toujours une réponse égale ou meilleure, travaille hors du fil principal et choisit sa politique à partir des caractéristiques visibles de l’horaire.

Les implémentations navigateur et Rust partagent le vocabulaire, les attentes du validateur, le tuple d’équité, les cas de test et les preuves. Le budget Rust hors ligne est pratiquement sans contrainte : populations, solveurs exacts, processus parallèles et points de contrôle de longues recherches sont possibles. Celui du navigateur est strict, car une optimisation plus longue nuirait visiblement à la réactivité de l’éditeur.

Distribution du catalogue et sélection à l’exécution​

Drawmaster écrit un catalogue JSON versionné. Chaque entrée contient les équipes, séances et pistes indexées, ainsi que le tuple d’équité, la borne inférieure, la méthode de production, le statut de preuve, la commande et les éléments de validation indépendante.

Notre paquet partagé de planification Curling possède le catalogue, intégré au créateur d’horaires d’événement de Curling IO v3. L’éditeur gratuit CurlingSchedules.com utilise le même artefact, mais son interface et sa persistance dans le stockage local restent distinctes de Curling IO. Une recherche 8×4 trouve le même horaire canonique aux deux endroits.

L’ordre à l’exécution est le suivant :

1. Chercher une disposition canonique exacte.
2. L’appliquer immédiatement lorsqu’elle correspond sans risque aux équipes et aux pistes choisies.
3. Répéter ou composer des dispositions pour les itérations et les groupes multiples.
4. Réparer autour des verrous, parties supplémentaires, parties de tableau et placements manuels.
5. Générer directement seulement si aucun point de départ du catalogue n’est utilisable.

Une disposition exacte d’une seule itération marquée comme prouvée optimale désactive Optimiser. Le bouton n’a rien d’utile à faire. Le format du catalogue peut toujours contenir un meilleur résultat trouvé si l’enveloppe s’élargit avant la preuve de son optimum. Dans ce cas, Optimiser reste disponible. Les horaires répétés, composés ou réparés restent aussi optimisables, car la preuve d’une seule itération ne couvre plus le résultat combiné.

Les modèles du club restent distincts. Le responsable peut appliquer volontairement un arrangement local récurrent plutôt que le choix global par défaut. La version 3 avertit avant que ce modèle déplace des parties déjà placées. Les modèles expriment la préférence d’un club. Le catalogue canonique exprime le meilleur résultat général que nous pouvons valider pour une forme numérique.

Constats​

La recherche a produit ces conclusions de travail :

• Une couverture complète validée primait sur davantage de recherche pour une disposition déjà bien comprise.
• Aucune heuristique ne dominait toutes les formes d’équipes et de pistes. Leur variance dépassait nos attentes.
• Une plus grande profondeur ne garantissait pas un meilleur résultat avec un budget fixe.
• Parcourir des plateaux de même note comptait, sans pouvoir réparer une mauvaise factorisation d’affrontements.
• La reconstruction et les portefeuilles indépendants trouvaient différents bassins plus sûrement qu’une longue marche locale.
• Le recuit simulé n’était pas assez performant pour devenir une stratégie générale.
• Les solveurs exacts devenaient pratiques après une bonne séparation du problème en couches.
• Les plans combinatoires publiés donnaient des solutions directes aux familles d’horaires applicables.
• Le statut de preuve doit accompagner chaque réponse en cache.
• Le meilleur optimiseur de production est souvent une recherche en cache suivie d’une petite réparation propre au domaine.

Le catalogue actuel couvre l’enveloppe cible de la version 3, et chaque disposition stockée est prouvée optimale. La recherche restante porte sur la réparation propre à l’événement autour des verrous, parties ponctuelles, parties de tableau et ressources partagées, ainsi que sur les futures extensions de l’enveloppe.

Curling IO v3 associe chaque disposition abstraite du catalogue aux vraies équipes, ressources, séances et parties de l’événement. Le responsable peut ensuite appliquer des modèles du club, importer des affectations, ajouter des parties ponctuelles et modifier manuellement l’horaire en préservant les placements qu’il choisit de verrouiller.

Glossaire​

• Tuple d’équité : la note ordonnée (Max, Total, Back-to-back) qui compare les horaires. Plus bas est meilleur, et les nombres sont comparés de gauche à droite.
• Heuristique : méthode conçue pour trouver rapidement un bon horaire sans prouver qu’il est le meilleur possible.
• Recherche locale : amélioration d’un horaire par des changements voisins de son arrangement actuel.
• Profondeur d’échange : nombre de déplacements évalués ensemble avant de les conserver ou non. Une recherche de profondeur deux peut garder deux déplacements dont le résultat combiné améliore l’horaire initial.
• Plateau : groupe d’horaires différents avec la même note.
• Parcours de plateau : passage par des horaires de même note pour chercher une position permettant une amélioration.
• Recherche taboue : conservation d’une courte mémoire des déplacements ou horaires récents pour éviter de les répéter en boucle.
• Recuit simulé : recherche qui accepte parfois un déplacement moins bon pour sortir d’un optimum local, généralement avec une tolérance décroissante au fil du temps.
• Bassin : région de l’espace de recherche où les déplacements voisins tendent vers le même optimum local.
• Portefeuille : plusieurs stratégies ou processus de recherche indépendants, dont on conserve le meilleur résultat validé.
• Méthode exacte ou solveur : méthode capable d’établir si une cible est atteignable ou de prouver qu’aucun meilleur horaire valide n’existe.
• Séparation-évaluation : méthode exacte qui cesse d’explorer une branche lorsque sa borne mathématique prouve qu’elle ne peut pas battre le meilleur résultat connu.
• Borne inférieure : note qu’aucun horaire valide ne peut battre. Atteindre une borne applicable prouve l’optimalité.
• Prouvé optimal : horaire validé pour lequel aucun meilleur tuple d’équité ne peut exister.
• Meilleur résultat trouvé : meilleur horaire validé trouvé jusqu’ici, sans preuve qu’il n’en existe pas de meilleur.
• Point de contrôle : état de recherche enregistré qui permet de reprendre un long processus sans repartir de zéro.

Les clubs de curling louent de la glace de pratique, des salons, des salles de réunion et d’autres ressources qu’ils définissent. Une location exige un produit et un prix, mais aussi un horaire, une ou plusieurs ressources, une disponibilité publique et une réservation enregistrée après la finalisation de la commande.

Dans Curling IO v3, un administrateur définit l’horaire de location et les ressources dans l’administration. Les plages disponibles apparaissent au calendrier public. Les curleurs peuvent en ajouter une au panier et finaliser leur commande. Cet article explique les options de location à venir et leur intégration au calendrier.

Ce qui change par rapport à la version 2​

Curling IO v2 permet déjà aux clubs de louer des lieux. La version 3 améliore grandement ce parcours et change la configuration et la gestion des locations :

• Administration des locations : créez et modifiez les locations dans Produits > Locations, avec les horaires, ressources, prix et options de réservation réunis dans l’administration.
• Gestion des ressources : les ressources remplacent les lieux de la version 2. Une ressource peut être une piste, un salon, une salle de réunion ou tout autre élément défini par l’organisation. Une section de paramètres dédiée gère les ressources utilisées par les horaires de location, les réservations manuelles, les fermetures et le calendrier.
• Capacité et listes d’attente : une location peut accepter une réservation exclusive ou plusieurs réservations par plage. La capacité et les listes d’attente concernent précisément la ressource, la date et l’heure réservées.
• Ressources groupées : plusieurs ressources peuvent former une plage. Une réservation peut réserver deux pistes ou l’ensemble des pistes.

Voir le parcours de location​

Ce tutoriel crée et réserve une location exclusive, configure une location avec capacité, puis termine avec une location groupée qui réserve deux pistes ensemble.

Le fonctionnement de l’horaire de location​

Une location commence par une ou plusieurs ressources, une date, au moins une heure de début et une durée. Elle peut avoir lieu une fois ou se répéter chaque jour, semaine, mois ou année. Un administrateur peut définir une date de fin et exclure des dates sans créer un produit distinct pour chaque plage.

Par exemple, un club peut offrir deux heures de glace de pratique sur les pistes A et B à 16 h chaque jour pendant une semaine. Chaque piste et date forment une plage réservable distincte. La location garde un prix et un ensemble de règles communs.

La location définit l’offre complète. Une plage est une ressource, une date et une heure de début qu’un curleur peut réserver. Si les pistes exigent des prix ou des règles différents, le club crée des locations distinctes.

Les locations au calendrier​

Les locations disponibles apparaissent avec les parties et les autres activités au calendrier public. Les curleurs peuvent filtrer le calendrier pour n’afficher que les locations. Le club peut partager directement cette vue filtrée pour promouvoir la glace de pratique ou les réservations de salles.

Sur ordinateur, le calendrier offre des vues par jour, semaine, mois et liste. Sur téléphone, il devient une liste quotidienne simplifiée, avec des commandes de date et une carte par événement. Pour la date actuelle, cette vue omet les événements déjà terminés.

Sélectionner une location disponible affiche sa date, son heure, sa durée, son prix et le choix de ressource. Si plusieurs pistes équivalentes sont offertes séparément, le curleur peut en choisir une disponible avant d’ajouter la plage au panier.

Ajouter une plage au panier ne la réserve pas. La disponibilité est vérifiée de nouveau à la finalisation de la commande. La ressource n’est attribuée qu’une fois la commande finalisée. Les paniers abandonnés ne changent pas la disponibilité publique.

Une fois la commande finalisée, la personne qui a réservé voit l’état Réservé. Les autres curleurs voient Réservé, sans le nom de la location ni les détails de la commande. La piste B peut rester disponible à la même heure si seule la piste A a été réservée.

Intégrer les locations au site de votre club​

Le club n’a pas à envoyer les visiteurs vers un calendrier distinct pour trouver de la glace disponible. Le widget de location place une liste ciblée des plages réservables sur sept jours directement sur le site existant du club. Les visiteurs comparent les dates, heures, ressources et prix sans quitter la page.

Le widget peut montrer toutes les locations publiques ou seulement certains produits et ressources. Un club peut consacrer une page à la glace de pratique, une autre aux salons, ou afficher seulement les pistes d’un programme. La liste reste liée au même horaire et aux mêmes conflits de ressources que le calendrier complet. Le club ne maintient donc pas la disponibilité à deux endroits.

Sélectionner Réserver mène au panier et au parcours de commande Curling IO habituel du club. C’est là que Curling IO confirme de nouveau la disponibilité et gère la connexion, les participants, les questions, les renonciations, les extras, les rabais, le paiement et la réservation finale. La liste intégrée sert à trouver une plage. Elle ne remplace pas le parcours de commande par une version simplifiée qui omet les règles du club.

La mise en page s’adapte à l’espace disponible sur la page hôte, y compris aux colonnes étroites et aux téléphones. Elle reprend aussi les couleurs Curling IO du club et protège ses commandes contre les styles contradictoires du site.

Locations exclusives et locations avec capacité​

Certaines locations sont exclusives. Une réservation prend la piste ou la salle complète pour cette plage. C’est la configuration naturelle pour de la glace de pratique.

D’autres acceptent plusieurs réservations pour la même ressource et heure. Une pratique libre pourrait utiliser la piste C à 19 h avec une capacité de quatre réservations. Après la finalisation d’une commande, la plage reste disponible pour trois autres réservations.

Le club peut aussi limiter chaque compte ou participant à un achat par plage. Si la plage est complète, une liste d’attente facultative recueille l’intérêt pour cette ressource, date et heure précises.

Lorsqu’un administrateur approuve une entrée de liste d’attente, le compte concerné peut réserver une place même si la capacité est atteinte. Cette exception est réservée à ce compte et n’augmente pas la capacité offerte aux autres.

Grouper plusieurs pistes dans une location​

La ressource louée n’est pas toujours une seule piste. Un instructeur peut vouloir deux pistes voisines, ou une ligue de location peut vouloir l’ensemble des pistes pour une période.

Un administrateur peut grouper les ressources sélectionnées pour qu’une seule réservation les réserve ensemble. La vue quotidienne montre les ressources groupées voisines comme un bloc qui s’étend sur leurs colonnes. Sélectionner le bloc montre toutes les ressources. La commande crée une réservation pour le groupe.

Un conflit sur une ressource rend toute la plage groupée indisponible. Si une partie planifiée, une fermeture, une réservation manuelle ou une réservation achetée utilise la piste A, le calendrier n’offre pas une version partielle de la location sur la piste B.

Actions du calendrier pour les administrateurs​

Le calendrier va au-delà d’une liste publique de locations. Les administrateurs peuvent ajouter des réservations manuelles et des fermetures, modifier un horaire de location et déplacer une réservation existante à partir de l’événement lui-même.

Ces éléments ont des fonctions distinctes :

• Une location est un produit public avec un prix, un horaire, un panier, une commande et un paiement.
• Une réservation manuelle retient une ressource.
• Une fermeture indique qu’une ressource est indisponible.
• Une réservation achetée est la ressource et l’heure enregistrées sur une commande.

Le calendrier combine ces éléments. Retirer une fermeture ou une réservation manuelle rend la plage de location sous-jacente de nouveau disponible sans que l’administrateur doive recréer son horaire.

Les autres fonctions de produit offertes aux locations​

Les locations utilisent les mêmes outils commerciaux de base que les autres produits Curling IO. Un club peut exiger un participant, ajouter des questions d’inscription, offrir des extras, appliquer des rabais, attribuer des taxes et des paramètres comptables, puis utiliser le parcours normal de paiement et de remboursement.

Par exemple, la réservation d’une salle peut demander les besoins d’aménagement, celle d’une pratique peut exiger un participant, et une location de toutes les pistes peut inclure un extra connexe.

Les locations seront une fonction Premium de Curling IO v3. L’horaire de location sera la source commune pour calculer la disponibilité au calendrier, valider la commande et créer la réservation enregistrée avec la commande finalisée.

Les associations membres ont parfois besoin de plus qu’une renonciation recommandée. Une police d’assurance collective peut exiger que chaque club membre présente le même texte approuvé à ses participants.

Envoyer un document Word à chaque club diffuse le texte sans en garder le contrôle. Un club peut modifier sa copie, manquer la mise à jour suivante ou continuer de recueillir des réponses à une ancienne version. L’association risque ensuite de ne pas pouvoir déterminer de façon fiable le document qu’un participant a réellement vu.

Curling IO v3 reliera ces éléments. Une association membre peut publier une renonciation verrouillée, la rendre disponible à ses clubs membres, la mettre à jour au même endroit et voir quels clubs ont des participants qui y répondent.

Voir le parcours des renonciations gérées​

Ce tutoriel montre le parcours complet : créer des modèles gérés et personnalisables, publier une nouvelle version, activer les renonciations de l’association dans un club membre et consulter les versions et les réponses.

De la police d’assurance collective à la réponse du participant​

Supposons que la police d’assurance collective de l’association de curling de démonstration exige que chaque participant adulte accepte une renonciation approuvée relative à la responsabilité civile générale. Voici comment cela fonctionnerait dans Curling IO v3.

1. L’association publie un modèle de renonciation géré​

Un modèle géré est une renonciation contrôlée par l’association que les clubs membres peuvent utiliser sans la modifier. L’association le crée une seule fois et contrôle le nom, le contenu, le texte d’acceptation et la plage d’âge inclusive. Un âge minimum de 18 ans inclut les participants de 18 ans et plus.

La renonciation peut contenir des variables pour le nom du club membre, sa province et son association membre. Curling IO les remplace pour chaque club. L’association n’a donc pas à maintenir des copies distinctes de documents autrement identiques.

2. Les clubs membres activent la renonciation de l’association​

Les renonciations gérées disponibles sont activées par défaut pour les nouveaux clubs membres. Lorsqu’une association ajoute ensuite une renonciation gérée, les clubs existants la voient désactivée dans leur liste Renonciations de l'association. Ils peuvent la consulter et l’activer lorsqu’ils sont prêts à recueillir des réponses.

Une fois activée, le club ne peut pas changer le document ou la plage d’âge contrôlés par l’association. Il peut désactiver la renonciation, mais ne peut pas en modifier discrètement le texte tout en continuant de la présenter comme celle de l’association.

3. Les participants répondent pendant l’inscription​

Lorsqu’une renonciation s’applique à un participant, Curling IO présente le document actuel de l’association pendant l’inscription. Le titulaire du compte l’accepte pour lui-même ou répond, lorsque nécessaire, comme tuteur légal du participant.

La réponse enregistrée contient le modèle géré, sa version et le document exact dont les variables ont été remplacées, tel qu’affiché à ce moment. Elle consigne aussi l’âge du participant, la personne qui a répondu et son lien de tutelle, le cas échéant.

4. L’association voit quels clubs l’utilisent​

Les rapports de l’association membre indiqueront quels clubs ont des réponses de participants liées à chaque renonciation gérée. C’est plus utile que de vérifier si une renonciation est activée. Un club peut l’activer sans inscrire personne, tandis qu’une réponse enregistrée prouve que le document géré a été présenté et a reçu une réponse.

Le rapport fournit la preuve que les clubs recueillent des réponses à la renonciation gérée par l’association. Il ne conclut pas automatiquement, sur le plan juridique, qu’un club a satisfait à toutes les conditions d’une police d’assurance. Ces polices peuvent imposer des exigences que Curling IO ne peut pas déduire.

Mettre à jour tous les clubs sans remplacer l’historique​

Lorsque le texte approuvé ou les exigences d’âge changent, l’association publie une nouvelle version du modèle géré. Elle devient immédiatement le document présenté par chaque club membre qui utilise cette renonciation.

Les personnes qui n’ont pas répondu voient la dernière version. Les participants qui ont déjà répondu pendant la saison ne sont pas sollicités de nouveau simplement parce que l’association a publié une mise à jour.

L’ancienne version et ses réponses ne sont pas écrasées. Les clubs membres peuvent consulter l’historique des versions et comparer les changements, mais ne peuvent pas ramener une renonciation gérée à une ancienne version ni appliquer la leur. Chaque réponse historique montre toujours le document exact présenté à ce participant.

Utiliser un modèle personnalisable lorsqu’un verrouillage n’est pas requis​

Un contrôle central n’est pas toujours nécessaire. Une association peut proposer un texte de départ utile que les clubs adaptent à leurs programmes, installations ou conseils juridiques locaux. Elle peut alors publier un modèle personnalisable. Voici les différences pratiques :

Choisir un modèle personnalisable préremplit un nouveau formulaire de renonciation. Le club peut modifier le contenu avant d’enregistrer, et la renonciation obtenue lui appartient. C’est pratique, mais la commodité et la conformité sont deux choses distinctes. Si l’assureur exige un texte inchangé dans tous les clubs, le modèle géré est conçu pour conserver ce contrôle.

Plus qu’un document téléversé et une case à cocher​

Un simple champ de renonciation peut afficher un texte et recueillir un accord. Il ne donne pas à une association le contrôle de ce document dans des clubs indépendants, ne conserve pas chaque version et ne relie pas chaque réponse à sa source gérée.

Ce lien est l’élément important de la conception de la version 3. L’association publie l’exigence. Les clubs l’utilisent sans la copier. Les participants répondent au document actuel. Les dossiers obtenus indiquent la version présentée et l’endroit où elle a été utilisée.

Voici le plus récent article de notre série sur les fonctions à venir dans Curling IO v3. Nous continuerons de montrer les vrais parcours à mesure qu’ils prennent forme, y compris les changements pour les associations membres, les clubs membres et les personnes qui s’inscrivent.

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é.

La frontière que nous voulions​

Nous voulions répondre à une question simple : si le serveur disparaissait, pourrions-nous reconstruire Curling IO rapidement, sans état non documenté de l’ancien hôte et pratiquement sans perte de données clients?

Une récupération réussie devait :

• Recréer les disques en miroir et la disposition de démarrage EFI.
• Activer la configuration exacte de l’hôte.
• Rétablir sa capacité à déchiffrer ses secrets.
• Restaurer un état Caddy avec des certificats valides.
• Compiler et déployer la plateforme, le site public et l’application Operations depuis une seule révision Git figée.
• Restaurer et valider SQLite depuis Litestream.
• Vérifier le stockage des fichiers téléversés publics et privés.
• Créer et vérifier un instantané chiffré de la base de données dans une deuxième région.
• Réussir les vérifications locales, publiques, de stockage, de surveillance et du fournisseur.

Cela dépasse le provisionnement du système d’exploitation. NixOS est responsable de l’hôte, mais les versions applicatives et l’état des données clients ont leurs propres parcours.

Cette séparation tient bien. Nous pouvons changer l’hôte sans déployer une application, déployer la plateforme sans déployer le site public et restaurer une base sans réinstaller le serveur.

Les versions applicatives restent distinctes​

NixOS est responsable de l’hôte, pas de la compilation des applications. Nous compilons la plateforme, le site public et Operations avant le déploiement, les emballons en versions vérifiées, puis les téléversons par SSH. La production n’a besoin ni de code source, ni d’identifiants de dépôt, ni de chaînes de compilation ou de caches de compilation.

L’empreinte logicielle de production est donc plus petite : moins de paquets et d’outils exécutables, aucun dépôt de sources ou identifiant de compilation et moins d’état de compilation modifiable. Cela réduit la surface d’attaque et le fardeau des correctifs, sans remplacer le cloisonnement des services ou les mises à jour rapides.

Les changements d’hôte et les versions applicatives restent indépendants. La récupération a aussi une frontière simple : compiler depuis une révision Git figée, vérifier chaque paquet avant et après son téléversement, puis l’activer par le même parcours de déploiement qu’en fonctionnement normal.

Nix a deux parcours distincts de déploiement de l’hôte​

Le provisionnement habituel et la récupération sur un hôte de remplacement fonctionnent volontairement différemment.

Pour un changement normal de configuration, notre script bin/provision production envoie les sources d’infrastructure exactes et validées dans Git au serveur en fonctionnement. Celui-ci utilise Nix pour construire une nouvelle génération système immuable, la valider, y passer et garder la génération précédente pour un retour arrière.

La récupération sur un hôte vierge ne peut pas dépendre de ce parcours. Une image de récupération censée être complète ne devrait pas démarrer pour ensuite télécharger ou construire la majorité du système réel. Notre image BYOLinux contient donc :

• Un système d’amorçage minimal sans secrets, capable de démarrer et d’accepter SSH.
• La fermeture NixOS de production complète, c’est-à-dire tous ses éléments et dépendances, comme contenu inactif du magasin.

Après le premier démarrage, la commande de récupération active le système de production déjà intégré et ses secrets requis. Si l’image ne contient pas la fermeture nécessaire, la récupération s’arrête. Elle ne masque pas l’image incomplète en se rabattant sur une construction à distance.

L’image de récupération est donc un véritable artefact plutôt qu’un mince installateur. Les commits touchant seulement les applications peuvent la réutiliser, car sa dérivation dépend uniquement des sources d’infrastructure. Le code applicatif, la documentation et les fichiers de tâches n’imposent pas de reconstruire une image de plusieurs gigaoctets.

Le serveur physique garde le fournisseur dans la conception​

NixOS n’élimine pas OVH du parcours de récupération.

Notre premier installateur créait des métadonnées RAID logiciel valides avec un noyau Linux plus récent. Le noyau NixOS installé et le noyau de secours d’OVH refusaient tous deux de les assembler. Mettre seulement NixOS à jour aurait fait fonctionner le système installé, mais aurait laissé l’environnement de secours du fournisseur incapable de lire les disques.

Nous avons changé la répartition des responsabilités. OVH BYOLinux crée maintenant les systèmes de fichiers ext4 en miroir selon la disposition prise en charge par le fournisseur. Notre image fournit le système de fichiers NixOS et un hook de démarrage qui étiquette les systèmes de fichiers et installe GRUB EFI au chemin de média amovible sur les deux disques.

Le hook BYOLinux du fournisseur fonctionne dans un chroot restreint. Lors des premiers essais, il n’avait ni l’interpréteur de commandes ni le PATH attendus. La réussite de la construction d’image ne disait rien de la capacité d’OVH à exécuter le hook. Il a fallu :

• Utiliser un chemin absolu du magasin Nix pour Bash.
• Intégrer le hook directement plutôt que d’appeler un deuxième chemin du magasin absent de l’image.
• Utiliser les commandes internes de l’interpréteur jusqu’à la disponibilité du PATH du système intégré.
• Tester chaque chemin du magasin référencé contre l’image elle-même.
• Rejouer le hook dans un chroot semblable à celui du fournisseur.

C’était décevant. QCOW2 offre un format d’image standard, mais pas un contrat standard pour en faire une installation physique démarrable. Nous pensions que la frontière du fournisseur serait plus prévisible. OVH exécutait plutôt un hook qui lui était propre dans un chroot minimal, dont il fallait découvrir l’interpréteur, le PATH et les chemins du magasin par des tests. Le format était portable, pas le contrat d’installation.

La surveillance du fournisseur comptait aussi. Lors d’une première répétition, OVH a détecté l’interruption prévue et ouvert une intervention technique. Celle-ci a bloqué une demande d’API de changement de mode de démarrage. La vérification préalable désactive maintenant l’intervention automatique et le confirme avant toute réinstallation. Elle rétablit ensuite la politique choisie lorsque l’hôte récupéré a réussi ses vérifications.

Résoudre cette frontière avec le fournisseur a pris la majeure partie du temps d’ingénierie consacré au provisionnement de récupération. La réinstallation réussie a pris moins de huit minutes, mais y arriver a exigé des constructions d’images répétées, des hooks en échec, des démarrages de secours et des répétitions destructives.

La configuration générée exige un seul responsable​

Caddy a vite exposé le problème de la configuration modifiable.

L’ancien serveur avait des fragments générés copiés dans des répertoires modifiables. Après un changement de disposition, des fichiers périmés restaient et étaient encore chargés. La configuration était correcte dans le dépôt, mais erronée sur le serveur, qui contenait à la fois les anciennes et les nouvelles interprétations.

La configuration NixOS possède maintenant les fichiers Caddy générés sous forme de liens vers des chemins exacts du magasin Nix. Les chemins obsolètes sont supprimés explicitement, et la configuration assemblée est validée avant l’activation.

Cette leçon dépasse NixOS. Un déploiement Ansible peut imposer la même règle, mais doit le faire délibérément. Copier le dernier fichier souhaité ne suffit pas si un ancien fichier peut encore influer sur l’exécution.

L’état de récupération doit exister avant l’effacement​

Le serveur en panne n’est pas une source de récupération.

Avant de l’effacer, la vérification préalable contrôle :

• La révision d’infrastructure et l’image de récupération choisies.
• Les éléments requis pour récupérer les secrets.
• L’état actuel du RAID.
• Une sauvegarde déchiffrable de l’état Caddy avec des certificats valides.
• La réplique Litestream hors site et l’instantané chiffré dans un deuxième emplacement hors site.
• Les frontières de stockage des fichiers téléversés publics et privés.
• Les points d’accès publics et l’état OVH.

L’état Caddy est devenu un élément explicite après notre constat que l’émission des certificats ne devrait pas se trouver sur le chemin critique de récupération. NixOS vérifie les changements d’état Caddy toutes les cinq minutes et stocke des copies chiffrées hors site. Des emplacements de rétention hebdomadaire offrent un filet de sécurité.

Pendant la récupération, Caddy reste arrêté le temps de préparer la plateforme, le site, la base, les fichiers téléversés et l’instantané chiffré. Il ne démarre que lorsque le serveur peut présenter un système complet avec les certificats restaurés. Le renouvellement normal en arrière-plan reprend ensuite.

SQLite suit un parcours distinct. Litestream réplique continuellement hors site. Une tâche quotidienne restaure et valide cette réplique avant de créer un instantané complet, chiffré côté client, dans un deuxième emplacement hors site. La restauration empêche qu’un ancien instantané de sinistre se réplique vers la réplique principale pendant son test.

La récupération part d’une révision figée​

Une longue récupération ne peut pas suivre en toute sécurité une branche qui change.

La commande complète crée une copie de travail temporaire au commit choisi. La publication d’image, l’installation par le fournisseur, l’activation de l’hôte, les trois compilations applicatives, la restauration de l’état et la validation finale partent de cette arborescence figée. De nouveaux commits dans la copie normale ne peuvent pas modifier une récupération en cours.

Le parcours possède aussi des points de reprise durables :

1. Vérifier l’image et les éléments de récupération.
2. Demander à OVH d’installer l’image.
3. Activer la fermeture NixOS intégrée.
4. Construire localement les paquets applicatifs vérifiés.
5. Déployer la plateforme et le site public.
6. Restaurer et valider SQLite, puis vérifier le stockage des fichiers téléversés.
7. Démarrer Caddy.
8. Déployer Operations.
9. Exécuter les vérifications finales d’acceptation.

Si le déploiement applicatif échoue après le démarrage de l’hôte, nous reprenons au déploiement applicatif. Nous n’effaçons pas les disques une nouvelle fois. Le basculement du DNS public est une autre opération distincte et confirmée, après les vérifications directes de l’hôte de remplacement.

Les mises à jour utilisent la même vérification de santé​

NixOS cherche les mises à jour stables chaque nuit et garde la génération précédente pour un retour arrière. Une nouvelle génération n’est acceptée qu’après avoir réussi les mêmes vérifications de santé en lecture seule que la surveillance Operations.

Le provisionnement, les mises à jour automatiques, la récupération et la surveillance partagent donc une définition d’un serveur sain. Si les vérifications échouent, l’hôte retourne à la génération précédente.

Les leçons au-delà de NixOS​

La même rigueur permet d’aller assez loin avec Debian et Ansible :

• Provisionner depuis une révision exacte.
• Définir explicitement les responsabilités et le nettoyage.
• Fixer les versions des outils de récupération.
• Protéger les commandes destructives.
• Tester automatiquement tout le parcours sur un hôte de remplacement.

Rien de cela n’exige NixOS. La différence est qu’Ansible permet de sauter ces étapes et de continuer. NixOS rend les désaccords avec le système déclaré beaucoup plus difficiles à ignorer. Nous aimons ces garde-fous techniques chez Curling IO.

Décision​

Nous gardons NixOS.

Il ne compile pas nos applications, ne restaure pas les données clients, n’élimine pas le fournisseur et ne remplace pas les scripts de déploiement. Il donne à ces systèmes un hôte mieux défini et une frontière d’activation plus sûre.

Le plus utile n’est pas la reproductibilité comme propriété abstraite. C’est l’obligation de rendre explicites les hypothèses cachées :

• Quel système est responsable de ce fichier?
• Quelle clé peut récupérer ce secret?
• Quel artefact identifie cet hôte?
• Qu’est-ce qui survit à la perte du serveur?
• Qu’est-ce qui prouve qu’une nouvelle génération est saine?
• Où la récupération peut-elle reprendre après un échec?

Ces questions ont amélioré tout le système de déploiement, y compris les parties sans Nix.

Cet article est le neuvième de la série sur les fondations de Curling IO. Précédent : un panneau d’administration en direct sans écrire de JavaScript.

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.

Commencez par les noms utilisés au club​

Supposons qu’un club nous dise :

Nous offrons des ateliers d’initiation au curling et des camps juniors. Nous louons aussi de la glace de pratique, vendons des casiers et organisons un souper-bénéfice. Tout cela ne devrait pas se mélanger aux programmes ou aux produits.

Dans la version 3, ce ne sera plus nécessaire. Le club peut créer un type pour chaque activité, les ordonner comme le personnel s’y attend et désactiver ceux qu’il n’utilise pas.

Les nouvelles organisations reçoivent encore des types de départ familiers comme Ligues, Bonspiels, Programmes, Produits et Frais. Ce n’est pas un menu permanent imposé par Curling IO. Un administrateur peut les renommer, les réorganiser, les désactiver ou créer un autre type.

Ces catégories existent déjà sur le terrain​

Nous avons regardé les offres actives dans Curling IO plutôt que d’inventer des exemples. Voici quelques produits et services que les clubs et associations vendent actuellement :

Ces choix actuels ne sont pas des erreurs. Ils montrent la limite d’un ensemble fixe de types. Les clubs utilisent déjà Curling IO pour ces activités, mais la structure des produits ne parle pas toujours leur langage.

Un type définit plus que son nom​

Un type de produit détermine les outils disponibles pour ses produits.

Un club qui crée un type « Ateliers » pourrait activer l’achat, l’inscription de participants, les dates, la capacité, les listes d’attente et les directeurs de produit. Chaque atelier peut ensuite avoir un prix, un formulaire d’inscription, des dates d’ouverture et de fermeture, une limite de participants et du personnel affecté.

Un type « Locations de glace » pourrait avoir besoin des achats, des dates et de l’inventaire, sans inscription de participants. Un type « Dons » pourrait avoir besoin des achats et de la comptabilité sans dates, équipes ou liste d’attente.

Le résultat se reflète dans le reste de Curling IO. Les types activés apparaissent dans la section Produits, dans l’ordre choisi par l’organisation. Chaque type peut avoir son nom et son résumé bilingues, son code de compte et l’adresse de sa liste publique.

Des types familiers, sans cases imposées​

La plupart des clubs peuvent continuer d’utiliser Ligues, Bonspiels, Programmes, Produits et Frais. Aucun administrateur n’est obligé de concevoir un système de catégories avant d’ouvrir les inscriptions.

Mais le club qui organise des camps peut créer Camps. L’association qui donne des cours aux entraîneurs peut créer Cours. L’installation qui vend de la glace de pratique peut créer Locations de glace. La navigation administrative, les listes publiques et la configuration des produits peuvent refléter les activités que les gens connaissent déjà.

Les types de produits personnalisés arrivent dans Curling IO v3.

Le problème de sécurité est réel​

WordPress fait fonctionner environ 43 % des sites web. Cette part du marché en fait une cible immense pour les acteurs malveillants. Le rapport 2023 de Sucuri sur les sites piratés indique que WordPress représentait plus de 95 % des plateformes CMS piratées qu’ils ont réparées. Joomla et Drupal formaient la majeure partie du reste.

Le rapport 2024 de Patchstack sur la sécurité de WordPress a recensé 5 948 nouvelles vulnérabilités WordPress divulguées en un an. La grande majorité, plus de 97 %, se trouvaient dans les extensions et les thèmes plutôt que dans le cœur de WordPress. Le chiffre exact change chaque année, mais la tendance reste la même : les extensions et les thèmes concentrent la plupart des risques.

Les attaques de la chaîne d’approvisionnement​

Les bogues non corrigés ne sont pas le seul problème. En juin 2024, WordPress.org a révélé que plusieurs extensions du dépôt officiel avaient été compromises. Les attaquants avaient obtenu l’accès à des comptes de développeurs et publié des mises à jour malveillantes d’extensions de confiance comptant des dizaines de milliers d’installations actives. Le code créait des comptes administratifs non autorisés et exfiltrait des données.

Une tendance croissante est encore plus inquiétante : des acteurs malveillants achètent des extensions légitimes et établies à leurs développeurs d’origine, puis injectent du code malveillant dans les mises à jour suivantes. Les utilisateurs qui ont activé les mises à jour automatiques, comme on le recommande généralement, reçoivent la version compromise sans indication du changement de propriétaire.

La campagne Balada Injector, documentée par Sucuri, exploite des vulnérabilités connues d’extensions depuis 2017. Selon leurs estimations, elle a compromis plus d’un million de sites WordPress en injectant du JavaScript malveillant qui redirige les visiteurs vers des sites frauduleux.

En août 2024, une vulnérabilité critique de l’extension LiteSpeed Cache, utilisée par plus de cinq millions de sites, permettait de créer des comptes administratifs sur tout site utilisant la version vulnérable. Elle a été activement exploitée dans des attaques réelles.

Joomla et Drupal ne sont pas à l’abri​

Joomla a eu sa part de vulnérabilités critiques. En février 2024, une vulnérabilité XSS de gravité élevée dans le composant de filtrage du cœur de Joomla, CVE-2024-21726, pouvait mener à l’exécution de code à distance. Un code d’exploitation de démonstration a été publié peu après sa divulgation. Une vulnérabilité antérieure, CVE-2023-23752, qui divulguait les identifiants de base de données, était encore exploitée massivement en 2024 parce que de nombreux sites restaient sans correctif.

Drupal a un meilleur bilan de sécurité grâce à un écosystème d’extensions mieux encadré et à une équipe de sécurité dédiée. Sa complexité fait toutefois que moins d’organisations le gardent entièrement à jour. Les tristement célèbres vulnérabilités Drupalgeddon de 2014 et 2018 étaient encore utilisées contre des sites non corrigés des années plus tard.

L’automatisation aggrave la situation​

Le trafic automatisé représente déjà environ la moitié du trafic Internet, les robots malveillants comptant pour environ le tiers. Les outils IA ajoutent une couche : les attaquants peuvent s’en servir pour rechercher des vulnérabilités, générer du code d’exploitation et agir plus vite dès qu’une faille est publique.

Une étude de l’Université de l’Illinois a montré qu’un agent IA pouvait exploiter avec succès 87 % des vulnérabilités connues lorsqu’on lui fournissait leur description CVE. Microsoft et OpenAI ont confirmé que des acteurs affiliés à des États utilisent déjà les LLM pour la reconnaissance et les scripts d’attaque. Le délai entre la divulgation et l’exploitation active d’une vulnérabilité est passé de jours à des heures, en partie parce que les outils IA aident à transformer presque immédiatement l’information CVE publiée en moyen d’attaque.

Pour un écosystème CMS comme WordPress, où des milliers de vulnérabilités d’extensions ont été divulguées ces dernières années, chaque extension non corrigée devient une course contre la montre.

Pourquoi cela touche les clubs de curling​

La présence en ligne de la plupart des clubs est gérée par un petit groupe de bénévoles. Ils n’ont ni équipe informatique dédiée ni budget de sécurité. Lorsqu’une extension WordPress introduit une vulnérabilité, ils peuvent ne rien en savoir jusqu’à ce que leur site soit défiguré, redirige les membres vers des pages d’hameçonnage ou recueille discrètement des renseignements de paiement.

Le fardeau d’entretien est important même sans incident :

• Mises à jour constantes. Le cœur de WordPress, les thèmes et les extensions doivent être mis à jour régulièrement. Les retards ouvrent la porte aux piratages.
• Multiplication des extensions. Un formulaire de contact? Une extension. Des inscriptions aux événements? Une extension. Une galerie de photos? Une extension. Chacune est un vecteur d’attaque potentiel.
• Gestion de l’hébergement. Vous êtes responsable de tout : système d’exploitation, serveur web, version PHP, base de données, cœur du CMS et chaque extension.
• Sauvegardes et récupération. En cas de problème, il vous faut une sauvegarde récente et quelqu’un qui sait la restaurer.

Un CMS généraliste est conçu pour créer toutes sortes de sites. Cette souplesse apporte une complexité dont la plupart des clubs n’ont pas besoin pour un site d’information souvent assez simple.

Si vous tenez à utiliser un CMS​

Certains clubs ont peut-être des raisons de garder WordPress ou un autre CMS. Dans ce cas, faites de la sécurité une priorité non négociable.

Si quelqu’un d’autre gère le site, qu’il s’agisse d’un bénévole, d’un développeur local ou d’une agence, posez-lui des questions sur chacun des points suivants. Une réponse vague ou désinvolte est un signal d’alarme. La réputation de votre club et les données de vos membres sont en jeu.

Gardez tout à jour​

Activez les mises à jour automatiques du cœur du CMS et mettez les extensions à jour dans les 24 à 48 heures suivant la publication des correctifs de sécurité. Abonnez-vous aux avis de Wordfence ou de Patchstack pour WordPress, de la Joomla Security Strike Team ou de la Drupal Security Team. Un site non corrigé attend simplement d’être compromis.

Réduisez votre surface d’attaque​

Utilisez le moins d’extensions possible. Chaque extension installée est du code auquel vous confiez votre site et les données de vos membres. Avant toute installation, vérifiez la dernière mise à jour, le nombre d’installations et les vulnérabilités connues. Supprimez ce que vous n’utilisez pas au lieu de simplement le désactiver.

Utilisez un pare-feu d’applications web​

Placez un pare-feu d’applications web infonuagique (WAF) comme Cloudflare devant votre site. Il peut bloquer les méthodes d’exploitation connues avant même l’installation d’une mise à jour, offrant une protection contre les attaques de type jour zéro.

Renforcez l’authentification​

Imposez des mots de passe forts et activez l’authentification à deux facteurs pour tous les comptes administratifs. Limitez les tentatives de connexion contre les attaques par force brute. Changez le nom d’utilisateur administratif par défaut. Ces mesures de base bloquent un nombre surprenant d’attaques.

Choisissez un hébergement géré​

Si possible, choisissez un hébergeur géré spécialisé dans votre CMS, comme WP Engine ou Kinsta pour WordPress et Pantheon pour Drupal. Ils gèrent la sécurité du serveur et les sauvegardes automatiques, et incluent souvent l’analyse des logiciels malveillants. Cela coûte plus cher qu’un hébergement partagé à bas prix, mais la sécurité et la tranquillité d’esprit en valent la peine pour une organisation bénévole.

Surveillez votre site​

Configurez des alertes pour les modifications de fichiers non autorisées et la création inattendue de comptes administratifs. Faites régulièrement des analyses de sécurité. Préparez un plan en cas de compromission : qui contacter et où se trouvent les sauvegardes.

Envisagez une solution plus simple​

Si le site de votre club sert surtout à afficher les heures d’ouverture, les horaires de glace, les coordonnées et les nouvelles, vous n’avez peut-être pas besoin d’un CMS. Deux bonnes options existent :

Un site statique​

Des outils comme Hugo, Eleventy ou même du HTML simple hébergé sur Netlify ou GitHub Pages ont une surface d’attaque presque nulle. Aucune base de données à compromettre, aucun code serveur à exploiter. La performance est aussi excellente, sans traitement serveur ou requêtes de base de données pour ralentir le site.

Les agents IA comme Claude, ChatGPT et Gemini ont facilité cette approche pour les personnes qui ne développent pas de logiciels. Si vous payez déjà pour un de ces outils, demandez-lui de créer un site statique pour votre club. Il peut vous guider, montrer des maquettes, aider à choisir l’hébergement et accompagner le déploiement. Il peut aussi intégrer nos outils de site Curling IO et nos API.

Demandez aussi à l’agent de documenter ce qu’il a créé, l’hébergement et les déploiements pour que le prochain bénévole puisse prendre la relève. Demandez-lui également d’enregistrer le code source dans un dépôt comme GitHub. Cela peut sembler beaucoup, mais les agents vous guideront à chaque étape. Claude Code est particulièrement utile si vous acceptez de payer 20 $ par mois, et sert aussi à bien d’autres choses.

Si votre club a besoin d’un site sur mesure que Curling IO n’offre pas, nous recommandons fortement cette approche.

L’hébergement de site intégré à Curling IO​

Chaque club sur Curling IO peut activer un site hébergé sans frais supplémentaires. Il est volontairement minimaliste et convient surtout aux clubs qui n’ont pas besoin d’une multitude de fonctions accessoires.

Il comprend une page d’accueil personnalisable, des pages, des articles de nouvelles, des sections de commanditaires et du contenu réservé aux membres. Le tout est étroitement intégré à vos inscriptions, ligues et bonspiels. Aucun écosystème d’extensions à exploiter, aucun environnement PHP à maintenir, aucune mise à jour de CMS à manquer. Vous pouvez même y rediriger votre domaine existant.

Les deux approches éliminent toute la catégorie de vulnérabilités décrite ici. Le temps de vos bénévoles est mieux investi dans la gestion du club que dans les correctifs logiciels.

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.

L’agent en action​

Cette conversation se déroule après votre connexion à Curling IO et l’autorisation de l’interface en ligne de commande curling, expliquée plus bas :

Vous : Aide-moi à préparer la nouvelle saison. Prépare un rabais d’inscription hâtive pour la Ligue du mardi soir : 15 % de rabais pour les inscriptions avant le 1er septembre.

$ curling call admin.items.list --org vancouver
$ curling commands admin.discounts.create

$ curling call admin.discounts.create --org vancouver '{"params": {...}}'

Vous : La même chose pour le Mixte du lundi. Laisse tomber le vendredi, cette ligue se remplit toute seule.

$ curling call admin.discounts.create --org vancouver '{"params": {...}}'

Vous : Oui, fais-le.

$ curling call admin.waitlists.list --org vancouver '{"item_id": 31}'
$ curling call admin.emails.send --org vancouver '{"params": {...}}'

Vous : Où en sont les inscriptions cette saison?

$ curling call admin.items.list --org vancouver '{"season": "2026-27"}'

Vous : Oui, fais le point avec moi chaque semaine.

Préparation de saison, communications ciblées et rapports dans une conversation de cinq minutes.

La même approche permet de préparer les événements d’une saison complète, modifier les frais de plusieurs ligues à la fois, produire des rapports financiers ou traiter les listes d’attente. Tout ce qu’un administrateur peut faire dans l’interface web, un agent peut le faire en ligne de commande.

Ce n’est pas théorique. Nous le développons en ce moment.

Le fonctionnement​

En coulisses, l’agent appelle un outil en ligne de commande nommé curling. Tout agent IA ayant accès à un interpréteur de commandes peut l’appeler : OpenClaw, NemoClaw, Claude Code ou Codex.

Nous avons envisagé MCP (Model Context Protocol), une norme de connexion des modèles IA à des outils externes. Nous avons créé un prototype fonctionnel. Mais une interface en ligne de commande est plus simple, plus portable et fonctionne avec tous les cadriciels d’agents, au-delà de ceux compatibles avec MCP. MCP pourra arriver plus tard comme mince couche supplémentaire.

L’outil se connecte au même serveur que l’administration web Curling IO. Chaque opération d’administration disponible dans le navigateur l’est aussi en ligne de commande. Lorsque nous ajoutons une fonction à l’administration, elle devient automatiquement accessible aux agents sans mise à jour du client.

Authentification​

Avant qu’un agent gère votre club, vous lui donnez accès. Une seule fois, en environ 30 secondes.

curling login

L’outil affiche une URL. Vous l’ouvrez, vous vous connectez à Curling IO et approuvez l’accès. C’est tout. L’outil stocke un jeton et gère ensuite son renouvellement silencieusement.

Il utilise le parcours d’autorisation d’appareil OAuth 2.1 (RFC 8628), la même norme que GitHub CLI, Google Cloud CLI et AWS SSO. Les équipes de sécurité la connaissent bien, et elle fonctionne dans tous les environnements.

Après la connexion, l’agent découvre les clubs que vous gérez :

curling orgs

Il limite ensuite la portée de ses commandes en conséquence :

curling call admin.events.list --org vancouver

À qui cela s’adresse​

La véritable cible est un agent IA qui agit pour un gestionnaire de club. Les utilisateurs naturels de l’outil sont les administrateurs qui adoptent tôt les outils IA et utilisent déjà des agents pour gérer leurs courriels, rédiger des communications et automatiser les tâches répétitives. Leur donner accès à curling est la prochaine étape logique.

Nous concevons l’outil comme si un expert humain pouvait l’utiliser directement. Aucun assistant de configuration, aucun accompagnement pas à pas. Une sortie concise et précise. Un --help complet qui récompense la lecture. Les agents évoluent vers des comportements humains, alors une bonne interface en ligne de commande sert les deux publics.

La vue d’ensemble​

Les logiciels de gestion de club ont toujours été conçus pour des humains qui naviguent dans des interfaces web. C’est la bonne conception pour la plupart des utilisateurs la plupart du temps. Mais les administrateurs ont du travail répétitif et structuré : préparer une saison, modifier les tarifs en lot, produire des rapports et approuver des files d’inscription. Un agent peut s’en charger.

La plupart des clubs n’y pensent pas encore, mais nous croyons qu’ils le feront dans les prochaines années, à mesure que les outils et agents IA prendront de la place. À court terme, seuls quelques gestionnaires à l’aise avec la technologie essaieront probablement, et ils ne reviendront probablement jamais en arrière.

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 fonctionnement​

Le générateur de formulaires est un outil de glisser-déposer dans l’administration du produit. À gauche, un panneau de questions disponibles. À droite, un canevas vide. Faites glisser une question sur le canevas pour l’ajouter au formulaire d’inscription. Ramenez-la dans le panneau pour la retirer. Réorganisez les questions en les déplaçant dans le canevas.

Chaque question a une largeur définie de 1, 2 ou 3 colonnes qui détermine sa place dans la grille. Une question d’une colonne, comme « Pointure », occupe le tiers de la rangée. Une question de deux colonnes, comme « Adresse municipale », en occupe les deux tiers. Une question de trois colonnes, comme « Notes », prend toute la largeur. La grille de type maçonnerie rapproche les questions sans laisser de trous.

Les séparateurs divisent visuellement le formulaire en sections. Les questions au-dessus d’un séparateur y restent. Une nouvelle section commence sous celui-ci.

Chaque question peut être obligatoire ou facultative. Les questions obligatoires portent un astérisque dans le formulaire public et doivent être remplies avant l’envoi.

Ce que voient les curleurs​

Le formulaire public affiche la mise en page conçue par l’administrateur. Quand vous commencez à saisir du texte, le libellé de la question remonte au-dessus du champ pour garder le formulaire compact. Les indications prennent la forme d’icônes d’information qui se développent au survol.

Le formulaire s’adapte à l’écran. Sur téléphone, tout s’empile en une colonne. Sur tablette, deux colonnes. Sur ordinateur, les trois colonnes s’affichent.

Les questions disponibles​

Le générateur comprend un catalogue de questions prédéfinies : coordonnées, contacts d’urgence, renseignements médicaux, questions propres au sport, tailles de vêtements, restrictions alimentaires et plus encore. Les clubs peuvent aussi créer leurs propres questions pour recueillir les autres renseignements nécessaires. La liste permet la recherche, et tout produit peut utiliser une combinaison de questions prédéfinies et personnalisées.

Certaines questions sont liées aux paramètres de l’événement. Si l’administrateur configure un libellé de nom d’équipe, la question correspondante apparaît automatiquement sur le canevas et reste verrouillée. C’est la même chose pour la question d’alignement lorsqu’une option d’alignement est sélectionnée. Désactiver ces paramètres retire les questions verrouillées du générateur.

Les éléments Espace et Séparateur servent à la mise en page; ils ne recueillent aucun renseignement. Ajoutez un espace pour laisser une cellule vide dans la grille. Ajoutez un séparateur pour diviser visuellement le formulaire en sections.

Le générateur de formulaires fait partie de Curling IO v3. Nous présenterons d’autres fonctions de la version 3 à l’approche du lancement.

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.

Qu’est-ce qu’un composant serveur?​

Phoenix LiveView a popularisé l’idée : produire le HTML sur le serveur, envoyer les modifications au client par WebSocket et traiter les événements de la même façon. Le navigateur devient une mince couche d’affichage. Lustre, le cadriciel d’interface de Gleam, intègre cette notion sous le nom de « composants serveur ».

Un composant serveur Lustre est une application suivant l’architecture Elm (modèle, mise à jour, vue) qui fonctionne comme processus BEAM. Lorsque le modèle change, Lustre compare l’ancien et le nouveau DOM virtuel, puis envoie une modification JSON par WebSocket. Le client l’applique. Les événements du navigateur, clics, envois de formulaire et changements de saisie, retournent en JSON. Toute la boucle prend moins de dix millisecondes sur un réseau local.

Côté client, un élément personnalisé nommé <lustre-server-component> se charge de tout. Vous lui indiquez une route WebSocket, et il crée le DOM fantôme (shadow DOM), adopte les feuilles de style, applique les modifications et transmet les événements. Lustre fournit l’environnement d’exécution client dans un seul fichier JavaScript à inclure dans la page.

L’architecture​

<html>
  <head>
    <link rel="stylesheet" href="/static/css/app.css">
  </head>
  <body>
    <lustre-server-component route="/ws/admin?url=/en/admin/products">
    </lustre-server-component>
    <script src="/static/lustre-server-component.mjs"></script>
    <script src="/static/js/admin-live.js" defer></script>
  </body>
</html>

fn(_connection) {
  let assert Ok(runtime) =
    lustre.start_server_component(admin.app(), flags)

  let self = process.new_subject()
  let selector =
    process.new_selector()
    |> process.select(for: self)

  server_component.register_subject(self)
  |> lustre.send(to: runtime)

  #(SocketState(runtime:, self:), Some(selector))
}

Naviguer sans charger les pages​

Les pages rendues côté serveur se rechargent habituellement à chaque navigation. Cela nuit à un panneau d’administration où l’on passe constamment d’une section de produit à l’autre. Il nous fallait le comportement de navigation côté client, avec pushState et le bouton de retour, sans routeur client.

La solution tient en environ 90 lignes de JavaScript sans cadriciel dans admin-live.js. Elles relient l’API d’historique du navigateur au composant serveur et gèrent trois parcours :

Clics sur les liens. Un écouteur de clics sur le composant serveur intercepte les balises <a>, empêche le chargement, appelle history.pushState et informe le serveur de la nouvelle URL. Les touches de modification, comme cmd+clic, les liens externes et target="_blank" sont laissés au navigateur. L’écouteur utilise composedPath() pour franchir la frontière du DOM fantôme et trouver le véritable élément <a>.

Boutons précédent et suivant. Un écouteur popstate détecte la navigation par les boutons du navigateur et envoie la nouvelle URL au serveur sans l’ajouter à l’historique, déjà mis à jour par le navigateur.

Navigation déclenchée par le serveur. Lorsqu’un enregistrement redirige vers une autre page, par exemple du formulaire de modification à l’aperçu, le serveur émet un événement personnalisé avec la nouvelle URL. Le client l’intercepte et appelle pushState.

Les trois parcours communiquent avec le composant serveur par la même astuce : des éléments <input> cachés dans le DOM fantôme. JavaScript définit la valeur du champ à la nouvelle URL et déclenche un événement change. Le gestionnaire d’événements Lustre côté serveur le reçoit. Les événements DOM ordinaires ne franchissent pas cette frontière de façon fiable, mais ceux des éléments de formulaire remontent dans les mécanismes internes du composant. Nous avions d’abord essayé des événements personnalisés et passé du temps à déboguer avant d’arriver à cette solution.

DOM fantôme et feuilles de style​

Lustre produit le rendu dans un DOM fantôme, ce qui offre une véritable encapsulation. Les styles ne traversent pas la frontière dans un sens ou l’autre. Le CSS de l’administration n’affecte pas le reste de la page, et vice versa. Mais il faut faire entrer les feuilles de style dans la racine du DOM fantôme.

Lustre s’en charge automatiquement avec adoptedStyleSheets, une API du navigateur qui permet aux racines de DOM fantôme de partager les feuilles de style du document parent. Au montage, le composant parcourt toutes les feuilles du document et les ajoute au tableau adoptedStyleSheets de sa racine. Si une feuille ne peut pas être adoptée directement à cause des restrictions d’origine, il copie les règles CSS dans une nouvelle feuille. Si cela échoue aussi, il clone l’élément <link> ou <style> dans la racine. Trois stratégies, par ordre de préférence.

Cela a fonctionné directement avec Tailwind et notre bibliothèque de composants Basecoat. Un point nous a fait trébucher : les propriétés CSS personnalisées. Nos variantes de couleur d’alerte utilisaient --success, --warning et --info, mais ces variables n’étaient jamais définies. Les styles étaient bien adoptés, mais color: var(--success) ne donnait rien, car la variable n’existait pas. Il a suffi d’ajouter les définitions à :root. Les propriétés CSS personnalisées sont héritées à travers les frontières du DOM fantôme, contrairement aux règles CSS ordinaires. Une fois définies dans :root, elles sont donc disponibles partout.

Ce qui fonctionne sur le serveur et sur le client​

La séparation est simple. Le serveur gère tout ce qui ne demande pas de rétroaction visuelle en moins d’une image d’affichage :

• Navigation et routage
• Saisie et validation des formulaires
• Interrupteurs de fonctions
• Chargement des données, synchrone depuis SQLite
• Alertes temporaires
• Ouverture et fermeture de la barre latérale

Le client gère le raccordement de la navigation, soit 90 lignes de JavaScript, et l’adoption des feuilles de style intégrée à Lustre. C’est tout. Toute l’interface d’administration est écrite en Gleam, y compris la barre latérale, le fil d’Ariane, les champs, les tableaux et les alertes.

Nous excluons explicitement du composant serveur les minuteries, le glisser-déposer, les animations et les observateurs de redimensionnement. Leurs boucles de rétroaction côté client surchargeraient le WebSocket. Le créateur de tableaux et le glisser-déposer d’équipes seront des « îlots » Lustre : de petites applications Gleam côté client, compilées en JavaScript et intégrées à certaines pages. Le composant serveur rend la page; l’îlot gère le widget interactif.

Nos erreurs en cours de route​

Boucle infinie du bouton de retour. Notre première navigation utilisait un seul message NavigateTo pour tout. Le serveur demandait au client d’ajouter une URL à l’historique, et le client le faisait. L’utilisateur revenait en arrière, le navigateur déclenchait popstate, le client envoyait l’ancienne URL au serveur, qui émettait un autre pushState. Une boucle. La solution : séparer NavigateTo, qui ajoute à l’historique, d’UrlChanged, qui ne le fait pas.

Clignotement de la barre latérale. Pendant le chargement entre deux pages de produit, nous effacions le contexte du produit. La barre se repliait à son état par défaut, puis se dépliait au chargement. Nous avons conservé le contexte du produit dans le modèle d’administration pendant les navigations au sein du même produit.

Disparition des messages temporaires. Enregistrer un rabais ou des frais d’association mène à la liste avec un message temporaire. Mais nous avions aussi ajouté l’effacement de ce message à la navigation. L’enregistrement définissait le message, puis appelait NavigateTo, qui l’effaçait. Il fallait définir le message après la navigation.

Ce que nous avons obtenu sans effort​

Le chargement de code à chaud de BEAM s’applique aux composants serveur. Lorsque l’outil de surveillance du développement recompile un module, le processus en cours utilise le nouveau code au message suivant. Le WebSocket reste connecté, l’état de la session est conservé et le prochain clic ou changement de page affiche la nouvelle vue. Nous n’avons rien créé ou configuré pour cela. Un jour, nous l’avons remarqué pendant le développement et compris que BEAM le faisait depuis le début.

Pourquoi pas du SSR ou une SPA?​

Par rapport au SSR​

L’administration de la version 2 utilise le rendu serveur avec des rechargements complets. Cela fonctionne, mais chaque interaction a une latence visible. On active un interrupteur et attend le rechargement pour voir le résultat. On change de section de produit et perd sa position de défilement.

Avec le composant serveur, activer un interrupteur met immédiatement l’interface à jour. Le processus BEAM est là, sans aller-retour réseau vers une base de données. L’enregistrement d’un formulaire peut mener instantanément à une autre page avec un message temporaire. La barre latérale reste en place, car elle appartient à la même application en cours d’exécution.

Par rapport à une SPA​

Pour l’utilisateur, le composant serveur ressemble exactement à une application monopage (SPA). La navigation ne recharge pas la page, l’état persiste et les mises à jour sont instantanées. La différence est l’endroit où le travail se fait.

Une SPA télécharge un paquet JavaScript avant que l’utilisateur voie quoi que ce soit. Une administration React modeste avec bibliothèque de composants, routeur et gestion d’état atteint facilement 200 à 500 Ko de JavaScript. La nôtre envoie environ 15 Ko de HTML initial par WebSocket et aucun JavaScript applicatif. L’environnement client Lustre est un script générique de 10 Ko, pas du code d’application.

Une SPA exige aussi une API REST ou GraphQL pour parler au serveur : points d’accès à concevoir, données à sérialiser en JSON puis à désérialiser côté client, états de chargement, cache et synchronisation des types client et serveur. Avec le composant serveur, la fonction de mise à jour a directement accès au domaine et à la logique métier. Aucune mécanique d’API ne s’interpose. Lorsqu’un formulaire est enregistré, elle écrit dans la base et retourne le nouveau modèle. La vue est comparée automatiquement. Toute l’administration est un seul ensemble de code Gleam avec l’état au même endroit.

Expérience de développement​

Chaque page d’administration est un module Gleam avec Model, Msg, init, update et view. Les types imposent le traitement de tous les messages. Ajouter une page revient à ajouter une variante de route, dont le compilateur indique tous les endroits à traiter, un module de page et son raccordement à la fonction de mise à jour de l’administration. Aucun langage de modèles ni objets de contexte transmis par intergiciel. Des fonctions à tous les niveaux.

Les chiffres​

Pour situer ce que nous utilisons :

• La structure HTML d’administration a 6 lignes de contenu : métadonnées, une feuille de style, l’élément personnalisé et deux scripts.
• admin-live.js contient 89 lignes de JavaScript sans cadriciel.
• Le montage initial envoie tout le DOM virtuel, soit environ 15 à 30 Ko selon la page.
• Les modifications suivantes font généralement moins de 1 Ko, seulement les différences.
• Chaque session est un seul processus BEAM qui consomme quelques centaines de Ko de mémoire.
• Les requêtes SQLite fonctionnent dans le processus. Le chargement des données lors des changements de page est donc synchrone et mesuré en microsecondes.

Il y a aussi un avantage de volume transmis par rapport au SSR traditionnel. Chaque requête HTTP transporte des en-têtes : témoins, type de contenu, jetons CSRF, en-têtes d’acceptation et directives de cache. Cela représente généralement 1 à 2 Ko supplémentaires par aller-retour, dans les deux sens. Une trame WebSocket ne contient que la charge utile avec quelques octets d’encadrement. Une session d’administration peut compter des centaines d’interactions : activer des interrupteurs, changer de section, enregistrer des formulaires. En HTTP, chacune paie le coût des en-têtes. En WebSocket, la connexion est déjà établie et authentifiée. Un interrupteur qui change un booléen envoie peut-être 80 octets de JSON et reçoit une modification de 200 octets. Le POST HTTP équivalent ferait 2 à 3 Ko avec les en-têtes, la redirection et le nouveau rendu complet.

La suite​

Le composant serveur couvre les 95 % des pages d’administration faites de formulaires, tableaux et paramètres. Les 5 % restants, le créateur de tableaux, la gestion des équipes par glisser-déposer et les tableaux de pointage en direct, seront des îlots Lustre côté client. Ils communiqueront avec le serveur par le même WebSocket ou par des appels d’API distincts.

Cet article est le huitième de la série sur les fondations de Curling IO. À suivre : améliorer la récupération avec NixOS.

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.

La boucle de rétroaction qui compte​

Tous les agents de programmation IA fonctionnent de la même façon : écrire du code, vérifier qu’il fonctionne, corriger ce qui est brisé et recommencer. La qualité de l’étape de vérification détermine tout.

Dans un langage typé dynamiquement, vérifier que le code fonctionne signifie exécuter la suite de tests. Cela prend du temps. Les tests ne couvrent pas nécessairement ce qui est réellement brisé, et ils sont eux aussi du code : chaque test ajouté augmente la complexité du projet. Beaucoup de bogues ne se manifestent qu’à l’exécution, parfois bien plus tard en production. L’agent écrit du code qui semble correct. Vous le révisez, et il vous semble correct aussi. Puis un utilisateur rencontre une erreur nil à deux heures du matin.

Dans Gleam, vérifier signifie compiler. Cela prend quelques secondes. Quand la compilation échoue, les messages sont précis : voici le fichier, la ligne, ce que vous avez écrit et ce qui était attendu. L’agent les lit, corrige et compile à nouveau. Après quelques cycles, la structure du code est saine.

Ce que le compilateur détecte​

Aucune valeur nulle​

Gleam n’a pas de valeur null. Les valeurs facultatives sont représentées par Option(T), soit Some(value) ou None. Vous ne pouvez pas déréférencer une valeur nil par accident. Le compilateur oblige à traiter les deux cas. Les erreurs liées aux valeurs nulles sont l’exception la plus fréquente en production. Une étude portant sur plus d’un milliard d’événements les a trouvées dans 70 % des environnements de production.

Lorsqu’un agent écrit du JavaScript, il doit penser à vérifier les valeurs nulles partout. Il ne le fait pas toujours. Gleam élimine entièrement cette possibilité.

Les références nulles sont connues comme l’erreur à un milliard de dollars, et ce n’est pas qu’une préoccupation théorique. En juin 2025, une seule valeur nulle dans un champ de base de données s’est propagée dans le système Service Control de Google Cloud et a mis plusieurs produits GCP et Workspace hors service dans le monde pendant des heures. Cette valeur a atteint un parcours sans gestion d’erreur, s’est répliquée mondialement en quelques secondes et a causé une panne résolue complètement après près de trois heures. Le type Option de Gleam aurait obligé le développeur ou l’agent à traiter le cas manquant avant de compiler. Il n’empêche pas toutes les défaillances d’une telle chaîne, mais élimine la catégorie précise de bogue qui l’a déclenchée.

Il y a aussi un enjeu de sécurité. Des valeurs nulles non traitées peuvent laisser une application dans un état inattendu : vérifications d’authentification sautées parce qu’un nil s’est glissé dans le parcours, ou données exposées sur une page d’erreur qui n’aurait jamais dû être atteinte. Chaque catégorie d’erreur éliminée par le compilateur représente une surface d’attaque que l’agent ne peut pas introduire par accident.

Changements structurels​

Voici un exemple réel de notre code. Supposons que l’agent ajoute un champ à un type :

pub type Listing {
  Listing(
    id: Int,
    name: String,
    capacity: Int,
    waitlist_enabled: Bool,  // new field
  )
}

En JavaScript, ajouter une propriété à un objet ne change rien avant l’exécution. Si un modèle ou un point d’accès API n’inclut pas le champ, vous ne le saurez que lorsque ce parcours sera exécuté. Les tests peuvent le détecter, ou le manquer si la couverture est incomplète.

En Gleam, toutes les fonctions qui construisent ou déstructurent un Listing cessent alors de compiler. Le compilateur liste chaque endroit à mettre à jour. L’agent suit la liste, fait les changements et obtient une compilation réussie.

Cela vaut pour tous les changements structurels : renommer un champ, passer un type de String à Int, ajouter une variante à un type union. Les agents s’en sortent bien. Les humains oublient des éléments dans les listes.

Filtrage par motifs exhaustif​

Le compilateur Gleam exige que le filtrage par motifs couvre tous les cas possibles. Pour un Result, il faut traiter Ok et Error. Pour un type union personnalisé à quatre variantes, il faut traiter les quatre. Le compilateur vous signale tout oubli.

Prenons un type d’état de paiement :

pub type PaymentStatus {
  Pending
  Completed
  Refunded
  Failed
}

Si quelqu’un ajoute une variante Disputed, toutes les expressions case qui filtrent un PaymentStatus dans le code cessent de compiler tant qu’elles ne traitent pas Disputed. Dans un langage typé dynamiquement, l’agent écrit un switch ou une chaîne de if pour les cas courants et oublie le cas limite. Une erreur d’exécution attend de se produire. En Gleam, le compilateur la détecte avant toute exécution.

Une syntaxe simple, moins d’erreurs possibles​

Gleam est un petit langage. Une seule façon de définir une fonction et de traiter les erreurs et les valeurs facultatives : Result et Option. Aucune exception, conversion implicite ou macro.

C’est important pour les agents, car un espace de décision réduit signifie moins de mauvaises décisions. Quand il existe six façons de faire quelque chose, l’agent doit choisir, et il ne choisit pas nécessairement l’approche idiomatique. En Gleam, il n’y en a généralement qu’une. L’agent n’a pas à connaître les préférences stylistiques de la communauté ou les conventions de gestion d’erreurs du projet. Le langage a déjà tranché.

Le formatage suit la même logique. gleam format fait autorité. Aucune configuration, aucun débat de style. Après formatage, le code de l’agent est identique en apparence au code écrit à la main. Impossible de voir la différence, et ce n’est pas nécessaire.

Les espaces ne comptent pas​

Je préfère en fait les langages où les espaces sont significatifs. Elm et Haskell sont parmi mes préférés. Une indentation nette me semble plus belle que des accolades partout. Mais les agents ne la maîtrisent pas encore. D’après mon expérience, ils trébuchent constamment sur les modèles Slim. Les erreurs d’indentation sont fréquentes dans le code produit par les LLM. Le modèle peut mélanger tabulations et espaces ou se tromper d’un niveau d’imbrication. Ces erreurs sont silencieuses et sémantiques : elles changent ce que fait le code.

Gleam utilise des accolades. Les espaces ne comptent pas pour le compilateur. gleam format les normalise. Une catégorie d’erreurs en moins pour les agents.

Des boucles de rétroaction rapides​

Une compilation rapide​

Le compilateur Gleam traite notre projet complet en quelques secondes. Une suite de tests typique dans un langage typé dynamiquement prend de 30 secondes à quelques minutes. Lorsque l’agent itère, l’écart entre quelques secondes de compilation et plusieurs minutes de tests s’accumule rapidement.

Des tests rapides​

Les tests sont rapides aussi. Chacun a sa propre base SQLite en mémoire sans état partagé, ce qui nous permet de tous les exécuter en parallèle. Environ 800 tests se terminent en moins d’une seconde. Ce gain s’accumule pendant une session où l’agent compile et teste des dizaines de fois.

Moins de données d’entraînement, un vrai coût​

Gleam a moins de données d’entraînement que JavaScript, TypeScript ou Python. Les agents produisent du code Gleam de moins bonne qualité au premier essai. Ils utilisent des approches inexistantes et inventent des fonctions absentes de la bibliothèque standard.

Le coût est réel : l’agent prend plus de temps à écrire le code initial en Gleam qu’en JavaScript.

Mais voici ce que j’ai constaté : le délai entre le début du travail et le déploiement d’un code correct est plus court en Gleam. L’agent écrit plus lentement, mais le compilateur détecte immédiatement les erreurs. En JavaScript, il écrit plus vite, mais les erreurs apparaissent plus tard, dans les tests ou en production.

La méthode en pratique​

Voici le déroulement d’une fonctionnalité typique :

1. Nous écrivons une spécification de ce que nous voulons. C’est itératif : nous l’affinons avec l’agent avant d’écrire du code. Une bonne spécification fait la différence entre un résultat utile et du rebut.
2. L’agent écrit l’implémentation : types, requêtes de base de données, gestionnaires de requêtes et vues.
3. Il lance gleam build. La compilation échoue avec 5 à 10 erreurs.
4. L’agent lit chaque erreur, corrige et recompile. Il fait quelques cycles.
5. La compilation réussit. L’agent lance les tests. Ils passent ou échouent sur la logique métier, pas sur des erreurs de valeurs nulles ou de types incompatibles.
6. Nous révisons les différences, en regardant la logique, l’intention et la redondance.

Les agents ont tendance à dupliquer du code plutôt qu’à réutiliser les fonctions existantes, probablement à cause des limites de leur fenêtre de contexte. Repérer les occasions d’extraire une logique partagée est notre commentaire le plus fréquent.

Nous écrivons encore beaucoup de code à la main. Les agents n’ont pas toujours raison. Ils produisent parfois du code laid ou redondant qu’il faut repérer et réécrire. Nous intervenons lorsque l’agent tourne en rond et essaie de corriger la même erreur sans avancer. En Gleam, cela arrive beaucoup moins que ce que nous avons vu dans les langages dynamiques.

Les autres langages​

D’autres langages à typage statique avec de bons compilateurs partagent certaines de ces propriétés. Rust, OCaml, Haskell et Elm ont tous des systèmes de types forts qui détectent les erreurs à la compilation.

Mais Gleam combine des caractéristiques qui conviennent particulièrement aux agents :

• Une syntaxe simple et facile à générer.
• Une compilation rapide pour des boucles de rétroaction courtes.
• Un formatage de référence qui donne au code de l’agent l’apparence du code écrit à la main.
• Aucune valeur nulle, ce qui élimine une catégorie d’erreurs très courante.
• Un filtrage par motifs exhaustif qui empêche d’oublier des cas.
• Des espaces non significatifs, pour que les erreurs de formatage ne changent pas le comportement.

Il fonctionne aussi sur BEAM, qui offre la tolérance aux pannes et la concurrence, mais c’est un autre sujet.

Le compromis est la maturité de l’écosystème et les données d’entraînement. Gleam est jeune. Les bibliothèques sont moins nombreuses. Le code des agents demande plus de corrections au premier passage. Cet écart se réduit à mesure que les données d’entraînement augmentent.

Le pari​

Je crois que les agents IA écrivent déjà la majorité du code dans un nombre croissant de projets. Le choix de langage est évalué autrement. La vitesse à laquelle un humain peut écrire compte moins. Le temps de révision exigé du développeur compte davantage que tout.

Le développeur est le goulot d’étranglement. Nous sommes lents comparés aux ordinateurs. Si le compilateur a déjà vérifié la structure du code avant l’arrivée des différences à l’écran, la personne qui révise peut se concentrer sur la logique et l’intention plutôt que de chercher les vérifications nil manquantes.

Nous avons choisi Gleam pour d’autres raisons, mais sa compatibilité avec les agents de programmation IA a été un avantage énorme.

Addenda : où en est la programmation assistée par IA​

Prenons du recul par rapport à l’argument technique. La programmation assistée par IA est là pour rester. Même si la technologie ne s’améliore pas sensiblement, elle est déjà assez utile pour que les développeurs l’adoptent en masse.

Les exigences augmentent​

Les agents sont déjà assez bons pour beaucoup de tâches d’applications métier, mais cette affirmation vient avec une grosse réserve. Chaque modification demande un examen attentif. Le développeur doit être un expert du domaine, de la sécurité et de la programmation. La vitesse de production du code a augmenté le niveau d’expertise requis du développeur plutôt que de le réduire.

Attendez-vous à plus de vulnérabilités​

Les agents produisent du code qui fonctionne, mais le fonctionnement et la sécurité sont des critères très différents. Ils détecteront probablement les problèmes évidents comme l’injection SQL. Les problèmes moins évidents sont dangereux : par exemple, ne pas réaliser qu’une décision prise trois demandes plus tôt rend indirectement les renseignements personnels de tous vos clients accessibles par une URL publique. Cela exige une compréhension de l’ensemble que les agents n’ont pas encore. Je pense que ce phénomène deviendra visible dans les prochaines années, à mesure que du code écrit par des agents arrivera en production sans révision suffisante.

Le secteur évolue​

Le secteur cherche activement les bonnes abstractions pour le développement assisté par IA. Deux tentatives se démarquent :

Mog est un langage conçu pour être écrit et lu par des IA plutôt que des humains. Je suis sceptique. Si le développeur qui révise les différences est le goulot d’étranglement, privilégier la lisibilité machine au détriment de la lisibilité humaine aggrave la situation.

Codespeak propose une autre approche : des spécifications et du code comme représentations interchangeables, avec un passage dans les deux sens. Je pense que les deux sont importants et qu’aucun ne suffit actuellement seul. Une spécification aide à réfléchir à l’ensemble, mais manque des détails qui comptent lorsque les choses tournent mal. Le code contient tous les détails, mais sa lecture permet difficilement de prendre du recul sur tout le système. Ils se situent à des niveaux de détail différents. Les fusionner en une seule chose fait perdre l’utilité propre à chacun.

Les langages à typage statique ont un avantage : les types se documentent eux-mêmes. Un type bien défini en Gleam communique déjà une bonne partie de ce qu’une spécification dirait de la structure des données et des limites d’une fonction, sans document distinct.

La suite​

Le rôle du développeur se déplace vers la supervision. Cela pourrait signifier beaucoup plus de logiciels créés, beaucoup moins de développeurs employés, ou les deux. Et ce rôle de supervision pourrait lui-même disparaître si les agents deviennent capables de boucler le travail seuls. C’est une possibilité réelle qu’il faut reconnaître honnêtement.

Après un an à développer des logiciels en production avec des agents de programmation IA, je constate que cela fonctionne si l’on fait l’effort de vérifier tout ce qui en sort. Gleam n’a pas été conçu pour les agents IA, mais une bonne conception du langage compte finalement plus que les outils créés expressément pour eux.

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.

Pourquoi l’exécution séquentielle était le choix par défaut​

L’exécuteur de tests de Gleam, gleeunit, délègue au cadriciel EUnit d’Erlang. Par défaut, EUnit exécute les modules de test un à la fois. C’est le choix prudent, car la plupart des suites partagent quelque part un état modifiable : une connexion à une base, un processus nommé ou un fichier sur disque. Exécuter ces tests simultanément produit des échecs qui passent localement mais échouent en intégration continue, ou qui passent le mardi et échouent le mercredi.

Nos tests ne partagent aucun état modifiable. Chaque test clone sa propre base. Deux tests ne touchent jamais la même connexion. L’article précédent explique toute la configuration, mais en résumé, test_db.setup() clone une base modèle en cache par l’API de sauvegarde SQLite et retourne une nouvelle connexion indépendante. À la fin du test, le ramasse-miettes récupère la connexion et la base disparaît.

Ce qui est réellement isolé​

Avant d’activer le parallélisme, nous avons vérifié chaque catégorie d’état partagé :

Les entrées persistent_term sont des caches écrits une seule fois. Plusieurs tests peuvent tenter d’initialiser la base modèle simultanément, mais la première initialisation est conservée, et les appels suivants ne font que lire la valeur en cache. C’est sûr.

Les tables ETS des tests, pour le limiteur de débit, sont créées sans l’option named_table. Chaque appel à ets:new retourne donc une référence de table unique. Aucun conflit.

L’implémentation​

EUnit prend en charge l’enveloppe {inparallel, Tests}, qui distribue les fonctions de test entre les ordonnanceurs BEAM. Elle existe depuis des années, mais gleeunit ne l’expose pas. Nous avons proposé une demande de fusion pour ajouter une fonction main_parallel(). On nous a fait remarquer que cela convenait mieux à une solution propre au projet qu’à une modification du cœur de gleeunit. C’est logique. Nous avons fermé la demande et écrit un module Erlang local au projet qui reproduit la découverte des tests et appelle EUnit directement.

-module(parallel_test_runner).
-export([main/0]).

main() ->
    Options = [verbose, no_tty,
               {report, {gleeunit_progress, [{colored, true}]}},
               {scale_timeouts, 10}],
    Files = filelib:wildcard("**/*.{erl,gleam}", "test"),
    Modules = [to_module(list_to_binary(F)) || F <- Files],
    case eunit:test({inparallel, Modules}, Options) of
        ok -> erlang:halt(0);
        _  -> erlang:halt(1)
    end.

to_module(Path) ->
    case filename:extension(Path) of
        <<".gleam">> ->
            binary_to_atom(
              binary:replace(
                binary:replace(Path, <<".gleam">>, <<"">>),
                <<"/">>, <<"@">>, [global]),
              utf8);
        <<".erl">> ->
            binary_to_atom(
              binary:replace(lists:last(binary:split(Path, <<"/">>, [global])),
                <<".erl">>, <<"">>),
              utf8)
    end.

Ce module fait la même chose que gleeunit : chercher les fichiers de test avec un motif glob et convertir leurs noms en atomes de module. Il enveloppe toutefois la liste dans {inparallel, ...} plutôt que de la passer à plat. Il réutilise gleeunit_progress de la dépendance Hex pour afficher un point coloré par test. La sortie des tests reste donc la même.

Le point d’entrée tient en une ligne :

@external(erlang, "parallel_test_runner", "main")
pub fn main() -> Nil

Aucun fork, aucun sous-module. Le gleeunit standard reste une dépendance dans gleam.toml, car nous l’utilisons encore pour l’affichage de progression. Seul le paquet serveur utilise l’exécuteur parallèle. Les paquets partagé et client gardent le main() séquentiel standard de gleeunit, car ils ont beaucoup moins de tests et n’en ont pas besoin.

Les résultats​

Les paquets partagé et client n’ont pas changé, car ils s’exécutaient déjà en moins d’une seconde.

EUnit sérialise les rappels de son écouteur dans un seul processus. Les points de progression arrivent donc toujours dans l’ordre. La sortie standard de chaque test est livrée après sa fin. Les sorties des tests simultanés ne s’entremêlent donc pas. La sortie des tests est identique à celle d’avant, simplement plus rapide.

Garder cette approche fonctionnelle​

Cela fonctionne parce que l’architecture des tests est saine. Si quelqu’un ajoute un test qui enregistre un processus nommé avec un atome fixe ou écrit dans un chemin de fichier partagé, deux copies de ce test entreront en conflit et produiront des échecs instables. Les règles sont simples :

• Ne partagez pas de connexions entre les tests. Utilisez test_db.setup().
• N’enregistrez pas les processus avec des noms fixes. Si un processus nommé est nécessaire, incluez le nom du module de test.
• N’utilisez pas de tables ETS nommées. Transmettez plutôt la référence de table.
• N’écrivez pas dans le système de fichiers pendant les tests.

Si un test ne peut pas suivre ces règles, EUnit permet de mélanger {inparallel, ...} et {inorder, ...} dans une même exécution. Nous pourrions conserver une liste de modules séquentiels dans l’exécuteur et les regrouper séparément :

Sequential = [some_integration_test],
Parallel = Modules -- Sequential,
eunit:test([{inparallel, Parallel}, {inorder, Sequential}], Options)

Les modules séquentiels s’exécuteraient un à la fois pendant que les autres resteraient parallèles. Nous n’en avons pas encore eu besoin, mais quelques lignes suffiraient.

Le gain inattendu​

Rien de cela n’était prévu. Nous avions choisi des bases SQLite par test pour éliminer le nettoyage, les dépendances d’ordre et les tests instables causés par des fuites d’état. Nous sommes encore un peu surpris qu’une accélération permanente de 4,7 fois, dont nous profiterons pendant toute la vie du projet, ait demandé un après-midi et 25 lignes d’Erlang.

Trente-sept lignes au total, avec les 12 lignes du module FFI de l’article précédent, pour isoler les bases par test et exécuter les tests en parallèle sur tous les cœurs disponibles. Aucune extension de cadriciel de test, aucune configuration. Le tout se compile avec gleam build et s’exécute avec gleam test.

Cet article est le septième de la série sur les fondations de Curling IO. À suivre : un panneau d’administration en direct sans écrire de JavaScript.

La liste complète​

• Curling Alberta
• Curl BC
• CurlManitoba
• CURLSASK
• Curling Ontario
• Northern Ontario Curling Association
• Curling Québec
• New Brunswick Curling Association
• Nova Scotia Curling
• Newfoundland & Labrador Curling Association
• Curl PEI
• Curling NT
• Nunavut Curling Association
• Yukon Curling Association

Ce que les associations en font​

Les associations provinciales utilisent Curling IO pour leurs compétitions : championnats provinciaux, séries de qualification et qualifications régionales. Elles gèrent les inscriptions des équipes, planifient les séances, saisissent les pointages en direct et publient les résultats. Les partisans et les participants voient les tableaux, les classements et les tableaux de pointage se mettre à jour en temps réel.

Les associations perçoivent aussi les frais d’affiliation par la plateforme. Lorsqu’un curleur s’inscrit à son club, les frais d’inscription du club et les frais d’affiliation de l’association peuvent être perçus en une seule transaction. Les frais de l’association et ceux du club apparaissent au même passage à la caisse. Aucune facturation distincte, aucun rapprochement manuel.

Le lien avec les frais d’affiliation est facultatif. Les clubs peuvent utiliser Curling IO indépendamment sans devoir appliquer les frais de l’association ni lui transmettre les données de leurs membres. Pour les clubs qui choisissent ce lien, la perception des frais et la production des rapports sont automatisées.

La plateforme est entièrement bilingue, en anglais et en français. C’est important pour des associations comme Curling Québec et pour les clubs de partout au pays qui comptent des membres francophones.

Ce que cela apporte aux clubs​

Lorsque votre association provinciale utilise Curling IO, vous avez quelques avantages.

Vos curleurs ont déjà des profils. Un curleur qui s’est inscrit à un bonspiel provincial ou a joué dans un championnat existe déjà dans le système. Lorsqu’il s’inscrit à votre club, il retrouve son profil. Pas besoin de saisir de nouveau son nom, son adresse ou ses contacts d’urgence.

Les compétitions sont liées. Les résultats d’un curleur dans les ligues de club, les qualifications provinciales et les championnats nationaux sont dans le même système. Son profil le suit des ligues de club aux compétitions provinciales et nationales.

Ce que cela apporte aux curleurs​

Pour un curleur, Curling IO est un seul compte. Il s’inscrit à sa ligue du mardi soir au club local, à un bonspiel de fin de semaine dans un autre club, puis se qualifie pour un championnat provincial. Même connexion, même profil, même parcours de paiement.

Le système compte actuellement environ 150 000 profils de curleurs dans des centaines de clubs actifs et les 14 associations membres provinciales et territoriales. Ce nombre augmente chaque saison avec l’arrivée de nouveaux clubs.

Pour commencer​

Si votre club relève d’une association provinciale canadienne, celle-ci utilise déjà Curling IO. Vos frais d’affiliation et votre base de données de curleurs sont donc liés dès le premier jour. Il n’y a aucuns frais de configuration, aucuns frais mensuels et aucun contrat.

Les clubs hors du Canada peuvent aussi utiliser Curling IO, sans le lien avec l’association.

Consultez notre guide de démarrage ou la page Curling IO de votre association provinciale pour voir le fonctionnement.

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.

Le problème de la base de données partagée​

Dans une configuration de test Postgres ou MySQL traditionnelle, chaque test communique avec le même serveur de base de données. Il faut une stratégie pour empêcher les tests de se contaminer :

Annulation de transaction. Encapsuler chaque test dans une transaction, puis l’annuler à la fin. Cela fonctionne jusqu’à ce que le code utilise ses propres transactions ou crée des processus qui doivent voir les données du test, le problème classique du bac à sable Ecto.

Vidage des tables. Supprimer toutes les lignes de toutes les tables entre les tests. C’est lent, et il faut respecter le bon ordre pour éviter les violations de clés étrangères.

Outil de nettoyage de base de données. Une gem ou bibliothèque qui combine les deux stratégies avec une configuration des tables à nettoyer, de la stratégie et du moment du nettoyage. Cela fonctionne, mais cette mécanique existe uniquement à cause de la base partagée.

Ce sont toutes des solutions de contournement à la même contrainte architecturale : un serveur de base de données, plusieurs tests.

SQLite en mémoire : une base de données par test​

SQLite ouvre une base de données à partir d’un chemin de fichier. Passez plutôt :memory: pour obtenir une base en mémoire qui existe seulement pendant la durée de la connexion. Elle est rapide, sans entrées-sorties disque, et complètement isolée. Rien d’autre ne peut la voir, et fermer la connexion libère tout.

pub fn setup() -> sqlight.Connection {
  let assert Ok(conn) = sqlight.open(":memory:")
  let assert Ok(_) = sqlight.exec("PRAGMA foreign_keys=ON;", conn)
  let assert Ok(_) = sqlight.exec(schema_sql, conn)
  conn
}

pub fn should_reject_duplicate_registration_test() {
  let conn = test_db.setup()
  // Insert test-specific data
  insert_org(conn, test_org())
  insert_listing(conn, test_listing())
  // ... test logic, assertions
  // conn goes out of scope, database vanishes
}

Aucune contamination croisée n’est possible, car rien n’est partagé. Les tests A et B utilisent littéralement des bases différentes. Vous pouvez les exécuter en parallèle dans des processus BEAM sans coordination.

Le coût de l’exécution du schéma​

Cette approche a un coût évident : chaque test exécute tout le schéma. Chez nous, cela représente 77 instructions CREATE TABLE, CREATE INDEX et CREATE VIEW. Nous l’avons mesuré :

• Ouverture d’une base SQLite en mémoire : 15 microsecondes.
• Exécution de 77 instructions de schéma : 1 100 microsecondes, soit 1,1 ms.

À 1,1 ms par test pour environ 500 tests qui ont besoin d’une base, cela donne environ 550 ms d’exécution du schéma. Ce n’est pas terrible, mais pas gratuit non plus. Le coût augmente linéairement avec le nombre de tests et la taille du schéma.

L’API de sauvegarde de SQLite : cloner les pages​

SQLite possède une API de sauvegarde conçue pour copier des bases entre des connexions. Elle travaille au niveau des pages : elle copie les pages brutes de la base d’une connexion à l’autre sans analyser ou exécuter de nouveau le SQL.

Once at startup:  open(":memory:") → execute full schema → template
Per test:         open(":memory:") → backup_copy(template) → ready

-module(test_db_ffi).
-export([clone_db/1]).

clone_db(Template) ->
    {ok, Dest} = esqlite3:open(":memory:"),
    {ok, Backup} = esqlite3:backup_init(Dest, "main", Template, "main"),
    '$done' = esqlite3:backup_step(Backup, -1),
    ok = esqlite3:backup_finish(Backup),
    {ok, Dest}.

@external(erlang, "test_db_ffi", "clone_db")
fn clone_db(
  template: sqlight.Connection,
) -> Result(sqlight.Connection, Nil)

fn template_db() -> sqlight.Connection {
  case get_cached("test_template_db") {
    Ok(conn) -> conn
    Error(Nil) -> {
      let assert Ok(conn) = sqlight.open(":memory:")
      let assert Ok(_) = sqlight.exec("PRAGMA foreign_keys=ON;", conn)
      let assert Ok(_) = sqlight.exec(schema_sql, conn)
      cache("test_template_db", conn)
      conn
    }
  }
}

pub fn setup() -> sqlight.Connection {
  let assert Ok(conn) = clone_db(template_db())
  let assert Ok(_) = sqlight.exec("PRAGMA foreign_keys=ON;", conn)
  conn
}

Les chiffres​

Au passage à la méthode de clonage, nous avions 594 tests et 77 objets de schéma. Nous sommes encore au début de la réécriture et approchons déjà les 1 000 tests. D’ici le lancement, nous prévoyons près du double d’objets de schéma et environ 5 000 tests.

Voici les mesures à 594 tests :

Le coût d’exécution du schéma est passé d’environ 550 ms à presque zéro. Les 2,6 secondes restantes correspondent à la logique réelle des tests, soit l’insertion de données, l’exécution de la logique métier et les assertions, ainsi qu’au démarrage de la machine virtuelle BEAM.

Les économies deviennent plus importantes à grande échelle. Une configuration Postgres traditionnelle viderait les tables entre les tests avec un TRUNCATE TABLE sur chaque table, dans un ordre respectant les clés étrangères, par un socket vers le serveur. Avec environ 100 tables et 5 000 tests, une estimation prudente pour notre réécriture complète, qui pourrait réalistement compter deux à trois fois plus de tests, cela représente 500 000 instructions de vidage envoyées au serveur. Même à moins d’une milliseconde par instruction, le total s’accumule.

Avec la sauvegarde, le clonage coûte environ 25 microsecondes par test, peu importe la taille du schéma. Pour 5 000 tests, cela donne 0,125 seconde au total. Aucun ordre de vidage à respecter, aucun aller-retour par socket.

Il s’agit d’une vraie suite de tests applicatifs couvrant les opérations de panier, le traitement des paiements, la validation des inscriptions, les frais d’association, les renonciations, la génération de tournois à la ronde, la planification des horaires, les pointages et plus encore. Ce ne sont pas des tests triviaux.

Pourquoi cela fonctionne si bien​

L’API de sauvegarde est une bonne optimisation, mais le principal gain vient de SQLite dans le processus, qui élimine complètement le problème de la base partagée.

Avec Postgres, le processus de test communique avec un serveur de base de données par un socket. Chaque test qui écrit des données le fait au même endroit. L’architecture exige donc des stratégies d’isolation.

Avec SQLite dans le processus, la base vit dans la mémoire de ce processus. En créer une autre est une allocation mémoire, pas une connexion réseau. Aucun serveur avec lequel se coordonner, aucun pool de connexions à gérer. L’isolation découle gratuitement de l’architecture.

Cela signifie aussi :

• Aucune dépendance à l’ordre des tests. Chaque test est entièrement autonome.
• Un parallélisme sûr. Chaque processus BEAM reçoit sa propre base sans coordination.
• Aucun code de nettoyage : ni teardown, ni after_each, ni database_cleaner.
• Aucun test instable causé par un état partagé qui fuit entre les exécutions.

Les compromis​

Il reste des compromis. Vous ne testez pas avec le même moteur de base de données qu’en production, sauf si vous utilisez aussi SQLite en production, comme nous. Des tests SQLite pour une production Postgres manqueraient les comportements propres à Postgres : types personnalisés, verrous consultatifs, opérateurs jsonb, etc.

Dans notre configuration, chaque test construit aussi ses données à partir de zéro. En pratique, c’est un avantage, car il déclare explicitement ses dépendances, mais cela demande plus de code de préparation par test qu’un jeu de données partagé. C’est toutefois un choix, pas une limite de la technique. Vous pourriez tout aussi bien insérer des données de départ dans la base modèle avant de la mettre en cache. Chaque clone commencerait avec ces données. Si votre suite profite d’un ensemble bien défini d’utilisateurs, d’organisations ou d’autres données de référence, préparer le modèle ainsi réduit simplement la préparation par test tout en conservant une isolation complète.

Au-delà de BEAM​

Nos exemples utilisent Gleam et Erlang, mais l’API de sauvegarde est une fonction de SQLite au niveau C. La plupart des langages l’exposent :

# Python 3.7+ has it built in
source = sqlite3.connect(":memory:")
source.executescript(schema_sql)

dest = sqlite3.connect(":memory:")
source.backup(dest)

// Node.js better-sqlite3
const template = new Database(":memory:");
template.exec(schemaSQL);

const dest = template.backup(":memory:");

// Rust rusqlite
let template = Connection::open_in_memory()?;
template.execute_batch(schema_sql)?;

let mut dest = Connection::open_in_memory()?;
let backup = backup::Backup::new(&template, &mut dest)?;
backup.run_to_completion(5, Duration::ZERO, None)?;

Le modèle est le même dans chaque langage : construire un modèle une fois, puis le cloner par test avec l’API de sauvegarde. Notre détour FFI par esqlite est nécessaire seulement parce que notre pilote Gleam ne l’expose pas encore.

L’ensemble de l’infrastructure​

Voici toute notre infrastructure de test :

• test_db.setup() clone une base modèle en cache avec l’API de sauvegarde SQLite.
• test_db.tz_db() retourne une base de fuseaux horaires en cache, chargée une seule fois plutôt que par test.
• persistent_term est le cache global BEAM du modèle de base et des données de fuseaux horaires.
• Douze lignes de FFI Erlang enveloppent l’API de sauvegarde SQLite.

C’est toute l’infrastructure de test. Aucune extension de cadriciel de test, aucune gem de nettoyage de base, aucune stratégie de vidage. SQLite et 12 lignes d’Erlang.

Cet article est le sixième de la série sur les fondations de Curling IO. À suivre : les tests parallèles sans effort supplémentaire.