Agents · Automatisation
Agent de réservation padel
Réserver un terrain de padel en envoyant un simple message : « réserve un padel demain 18 h 30 à Chartres ».
En résumé
- Problème
- Réserver un terrain de padel, c'est ouvrir une appli, chercher un club, comparer les créneaux, ajouter les joueurs et partager le paiement. Une dizaine d'étapes pour une décision toute simple.
- Solution
- Un agent qui comprend une phrase, cherche les vrais créneaux disponibles, propose, puis prépare la réservation. Et qui ne peut jamais payer sans confirmation.
- Ce que ça apporte
- La réservation tient en un message, et la décision de payer reste toujours humaine.
- Où il en est
- Prototype pour notre usage personnel. Les briques sont codées et le déploiement est prêt, mais une réservation complète par WhatsApp n'a pas été refaite récemment.
- Mon rôle
- J'ai conçu les outils que l'agent peut utiliser, le lien avec la plateforme de réservation et le verrou qui l'empêche de payer seul.
Le problème
Réserver un terrain de padel prend une dizaine d'étapes : ouvrir l'appli, chercher un club, comparer les créneaux, choisir, ajouter les joueurs, partager le paiement. Alors que la décision, elle, tient en une phrase.
Ce que fait l'agent
Il lit un message tout simple, comme « trouve un padel vers 19 h près de Bastille, on joue à trois », et le transforme en actions : chercher les clubs proches, lire les vrais créneaux disponibles, retrouver les joueurs dans un carnet de contacts, préparer la réservation et le partage du paiement.
Le choix le plus important
L'agent ne paie jamais seul. Il prépare le paiement et s'arrête.
C'est ce qui m'a demandé le plus de réflexion. Faire comprendre une phrase à une IA est devenu facile. Décider de ce qu'elle peut faire sans que personne ne vérifie, beaucoup moins. Et quand il s'agit d'argent, la réponse est claire : rien sans confirmation.
Voir les détails techniques
Des outils plutôt que du texte
Pour agir, l'agent appelle des outils déclarés à l'avance, chacun avec un rôle précis : chercher un club, lire les créneaux, ajouter un joueur, préparer un paiement. Un seul outil très large aurait rendu son comportement impossible à contrôler.
Les intégrations
Trois modules : le client de la plateforme de réservation, le carnet de contacts, et la localisation qui permet de comprendre « à côté de la tour Eiffel ».
La messagerie
Deux services de messagerie branchés séparément. Comme c'est la seule porte d'entrée du service, dépendre d'un seul fournisseur était le risque le plus évident.
Ce qui manque
Des tests automatisés. Pour un outil qui touche à des réservations et à des paiements, c'est la priorité.
Chiffres
4
briques développées
recherche de créneaux, compréhension des messages, réservation, messagerie
Source · suivi d'avancement du dépôt
2
services de messagerie
deux fournisseurs branchés séparément, pour ne pas dépendre d'un seul
Source · serveurs webhook du dépôt
3
modules d'intégration
client de réservation, carnet de contacts, localisation des lieux
Source · arborescence du paquet d'intégration
Ce que j'ai fait
Architecture
J'ai découpé le projet en quatre briques indépendantes : la recherche, la compréhension, la réservation et la messagerie.
Conception des agents
J'ai défini les outils que l'agent peut appeler, et dans quelles conditions.
Développement assisté
Le client de réservation, le carnet de contacts et la localisation des lieux ont été écrits en Python avec des assistants de code.
Contrôle qualité
J'ai prévu le verrou de paiement : l'agent prépare le paiement, il ne le déclenche jamais.
Intégration
J'ai branché deux services de messagerie, pour ne pas dépendre d'un seul.
Preuves
Un agent qui utilise des outils précis
vérifiéL'agent n'écrit pas une réponse au hasard : il appelle des outils précis, comme chercher un club, lire les disponibilités, ajouter un joueur ou préparer un paiement. Son comportement reste donc vérifiable.
- Source
- définition des outils et boucle d'appel du dépôt
- Vérifiable par
- Lecture de la définition des outils et de la boucle de traitement.
Il ne peut pas payer seul
vérifiéL'agent prépare le paiement et s'arrête là. Le paiement demande toujours une action humaine.
- Source
- flux de réservation du dépôt
- Vérifiable par
- Lecture du flux de réservation et du point d'arrêt de paiement.
Un déploiement prêt
vérifiéLa configuration du serveur et des deux services de messagerie est écrite et versionnée.
- Source
- fichiers de déploiement et de messagerie du dépôt
- Vérifiable par
- Lecture des fichiers de configuration et de la documentation associée.
Limites
- Le service n'est pas ouvert au public, et personne d'autre que nous deux ne l'a utilisé.
- La réservation passe par l'application Playtomic, pour un usage personnel. Ce n'est pas une intégration approuvée par Playtomic.
- Si Playtomic change son fonctionnement, la recherche de créneaux ne marche plus.
- Le code est privé, il n'est donc pas consultable depuis ce site.
- Il n'y a pas encore de tests automatisés. C'est la première chose à ajouter.
- C'est un projet à deux : toutes les briques ne sont pas de moi.
Ce que j'en retiens
- Le plus difficile n'était pas de faire comprendre la demande à l'agent, mais de décider ce qu'il pouvait faire seul. Le verrou de paiement m'a demandé plus de réflexion que tout le reste.
- Donner à l'agent plusieurs petits outils précis plutôt qu'un gros outil général rend son comportement prévisible.
- Brancher deux services de messagerie plutôt qu'un a pris une journée, et évité de tout faire reposer sur un seul fournisseur.
Ce que ça peut apporter à une entreprise
- N'importe quelle prise de rendez-vous par message (garage, cabinet, salle de sport) peut fonctionner pareil, avec la même validation humaine avant de payer.
- Un service client peut donner à un agent quelques outils précis sur son système de réservation, sans lui ouvrir toute la base.
Technologies
- Python
- API Anthropic (tool use)
- Playtomic
- WhatsApp Business API
- Twilio
- Render