Une plateforme d’agents IA pour les participants au programme de Michał Połuch

Le client et ses difficultés

Michał Połuch propose un programme éducatif vendu sous forme de produit numérique. Les participants devaient disposer d’un ensemble d’agents IA pour les aider dans des tâches concrètes du programme, comme générer des idées de bonus. Jusqu’alors, ces outils étaient dispersés et quelqu’un devait gérer manuellement chaque accès.

Le premier défi était de réunir tous les éléments dans une expérience cohérente. Le chat avec les agents, les comptes utilisateurs, les abonnements et le suivi après-vente devaient former une seule application, et non un assemblage d’outils reliés par des liens. Le participant devait se connecter à un seul endroit pour tout retrouver.

Le deuxième enjeu était le contrôle d’accès. Chaque requête aux agents a un coût : l’accès devait donc dépendre d’un abonnement actif et l’utilisation être limitée par jour. Les messages indiquant qu’un quota est épuisé ou qu’un accès n’est pas actif devaient aussi être compréhensibles, faute de quoi chaque cas deviendrait une demande au support.

Troisièmement, le parcours entre l’achat et l’activation du compte ne devait nécessiter aucune action du propriétaire du programme. Enfin, les prompts et les modèles des différents agents devaient pouvoir être modifiés sans publier une nouvelle version de l’application, et une panne du service de configuration externe ne devait pas arrêter la plateforme.

Ce que nous avons mis en place

Nous avons développé l’application avec Next.js et confié la gestion des comptes, de la base de données et des autorisations à Supabase. Des règles d’accès au niveau des lignes empêchent chaque utilisateur de consulter les conversations d’un autre. Nous avons créé les modules d’inscription et de connexion, un espace de compte avec profil et une interface de chat capable de gérer plusieurs agents.

Avant qu’une requête atteigne un modèle, le serveur effectue deux contrôles : l’abonnement est-il actif et le quota journalier est-il encore disponible ? La vérification côté serveur ne peut pas être contournée depuis le navigateur.

Les réponses sont générées via OpenRouter et diffusées en continu, afin que le texte apparaisse au fil de sa génération plutôt qu’après plusieurs secondes de silence. Les prompts et modèles de chaque agent sont stockés dans Agenta Cloud : modifier son comportement ne nécessite ainsi qu’un changement de configuration, pas un déploiement. Si ce service devient indisponible, la plateforme utilise la dernière configuration connue au lieu de refuser de répondre.

Nous avons relié les ventes à Publigo par webhook. L’événement d’achat est signé puis vérifié ; une fois sa signature validée, le système crée automatiquement le compte et active l’abonnement. L’historique des conversations est conservé pour que le participant puisse reprendre un fil existant. Enfin, nous avons ajouté une réponse automatique aux messages reçus en dehors des heures de travail, envoyée par Resend et assortie d’une limite de fréquence pour éviter qu’une même personne reçoive cinq fois le même message.

Fonctionnement actuel

Le projet a duré environ une semaine et s’est déroulé en quatre étapes : cartographie du parcours d’achat et d’accès et conception du modèle de données ; développement de l’application et de la connexion ; intégrations aux modèles et automatisations des ventes ; enfin, stabilisation et mise en production.

Aujourd’hui, le participant achète le programme et reçoit son compte prêt à l’emploi peu après, sans contacter le support. Il se connecte, choisit un agent et démarre une conversation dont les réponses arrivent au fur et à mesure. Les échanges sont enregistrés. Les plafonds quotidiens contrôlent discrètement les coûts et ne signalent leur atteinte que lorsqu’elle se produit. Le propriétaire du programme peut modifier les prompts et les modèles depuis la configuration lorsqu’il souhaite qu’un agent réponde autrement.

Résultats

Une plateforme unique remplace un ensemble d’outils dispersés. L’accès s’active automatiquement après l’achat, de sorte que le support ne ralentit pas les ventes. L’abonnement et le quota journalier contrôlent l’accès aux agents et maîtrisent le coût des modèles. La configuration des agents est séparée du code et une panne du service de configuration n’interrompt pas la plateforme.

Ce que nous ferions autrement

Le webhook de vente s’est révélé être le point le plus sensible. C’est le seul endroit où un système externe peut créer un compte : la vérification de signature et la résistance aux événements répétés devaient donc être présentes dès la première ligne de code. Nous les avons bien mises en œuvre, mais n’avons effectué les tests qu’à la fin, avec le parcours d’achat réel. Pour le prochain déploiement, nous mettrons en place dès le début un moyen de rejouer ces événements dans un environnement de test.

Nous avons également sous-estimé le mode de secours en cas d’indisponibilité de la configuration externe des agents. La première version supposait que le service serait toujours accessible. Une seule interruption a suffi à montrer que la réponse par défaut devait reprendre la dernière configuration connue, et non afficher une erreur.