Aller au contenu principal

L’assistance intégrée dans Curling IO

· 9 minutes de lecture
Dave Rapin
Dave Rapin
Fondateur chez Curling IO

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

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.

L’assistant des commandes examine pourquoi l’inscription payée de Madison n’a pas reçu le rabais Jeunesse.

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

Une proposition de remboursement pour la commande de Madison montre le participant, la ligue, le rabais Jeunesse, le paiement à rembourser, la destination et le montant du remboursement, le nouveau total de la commande et le bouton Approuver le remboursement.

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.

La commande de Madison après l’approbation, avec la réduction de 137,50 $ et le remboursement enregistrés 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é.

Une proposition de diffusion de courriel montre le public, les quatre destinataires actuels, l’objet, le message et les boutons Refuser et Appliquer à la diffusion, tandis que le formulaire modifiable reste inchangé.

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.