Une plateforme SaaS Symfony et React pour piloter des robots
Retour d’expérience sur Aliz, branche de TED Consulting, où j’ai développé seul, en alternance puis en freelance, la plateforme SaaS Symfony et React qui vendait et pilotait des robots Python : API partagée avec une autre équipe, abonnements Stripe facturés à l’usage et outils annexes.
Aliz est une branche de TED Consulting, une société de conseil IT spécialisée en data strategy et en automatisation des processus (RPA) auprès de grands groupes. Elle met cette expertise au service des TPE, des PME et des indépendants : des assistants, c’est-à-dire des robots qui travaillent pour le compte du client, automatisent leurs tâches répétitives. J’ai rejoint TED Consulting en septembre 2020, en alternance, pendant ma formation à Epitech puis à 3IS Executive, et j’y suis resté jusqu’en novembre 2022, avant de poursuivre quelques mois en freelance. Seul développeur web, j’ai surtout travaillé sur Aliz, en plus du site vitrine de TED. Le cœur des robots, écrit en Python, était développé par une équipe spécialisée ; mon rôle consistait à construire la plateforme SaaS qui permettait de s’y abonner, de les configurer et de suivre leur travail.
Aliz et ses assistants
La plateforme proposait trois à quatre assistants, chacun dédié à une tâche précise, comme la déclaration de TVA, la gestion de patientèle ou la vérification de données légales d’entreprises. Le client s’inscrivait par e-mail ou avec son compte Google ou Microsoft, choisissait un assistant et une formule, puis accordait les autorisations nécessaires, par exemple l’accès à Google Drive pour les assistants qui en avaient besoin.
Côté technique, la plateforme reposait sur une API Symfony, un front React séparé pour les clients et un back-office d’administration pour gérer les clients, les abonnements et les robots. Le client disposait d’un espace complet, avec un tableau de bord de statistiques, la facturation, ses moyens de paiement, le parrainage, des notifications et des tutoriels.
Comment la plateforme et les robots communiquaient-ils ?
L’API servait deux types d’appelants très différents. Le front React l’appelait pour le compte des utilisateurs, tandis que les robots Python l’interrogeaient de façon autonome. Des routes leur étaient réservées, protégées par un filtrage des adresses IP et un token, pour :
- récupérer la liste des utilisateurs à traiter et leur configuration ;
- mettre à jour les données produites par leur travail ;
- remonter leur consommation pour chaque utilisateur ;
- enregistrer des logs, consultables ensuite pour suivre leur activité.
Nous avons défini ces échanges avec les développeurs des robots, au fil de réunions, de documentation partagée et d’essais. La principale difficulté venait du rythme d’évolution rapide des robots. Le format des données échangées changeait souvent, si bien qu’il fallait vérifier en permanence la compatibilité avec la partie web, grâce à des retours réguliers entre nos deux équipes.
Comment facturer un abonnement Stripe en partie à l’usage ?
Chaque assistant était proposé en trois formules (Starter, Business et Premium), au mois ou à l’année, à un prix différent. Dans Stripe, chaque abonnement combinait deux prix : un prix fixe, propre à la formule et à la périodicité, et un prix facturé à l’usage.
Lorsqu’un robot remontait sa consommation, l’API l’enregistrait sur l’abonnement Stripe du client, qui la reportait sur la facture suivante. Le tableau de bord du client relisait ces mêmes données pour afficher sa consommation en cours. Les webhooks Stripe tenaient de leur côté la plateforme à jour lorsqu’un abonnement était créé, modifié ou résilié.
Les premiers utilisateurs ont pu tester les assistants gratuitement, et certains de ces clients de la première heure ont ensuite bénéficié de codes promo.
Travailler seul, avec l’appui d’un développeur senior
Seul développeur web, je touchais à tout, de l’API au front en passant par le back-office et les intégrations avec Stripe, Google et Microsoft. J’en retiens surtout d’avoir su être autonome et productif, alors que mon expérience du développement était encore toute jeune.
Un développeur senior m’épaulait ponctuellement. Il m’aidait surtout à prendre la bonne direction sur l’architecture et les bonnes pratiques, avec à l’occasion une revue de code ou une séance de pair programming.
alizCalendar et alizVerif, des applications à part
À partir de 2021, deux applications sont venues compléter la plateforme. J’ai repris le développement d’alizCalendar, l’assistant de prise de rendez-vous démarré par un autre développeur, puis assuré ses évolutions ; l’article sur la reprise d’une base de code existante revient sur ce type de situation. Écrite en Symfony avec des pages rendues côté serveur, elle synchronisait les rendez-vous avec Google Agenda et Outlook et était déployée avec Docker sur Google Cloud.
alizVerif permettait de rechercher et de vérifier les données légales d’entreprises, une par une ou en masse à partir d’un fichier. J’en ai conçu les maquettes et développé l’application React, ainsi que les routes d’API qui transmettaient les demandes aux robots chargés de la vérification.
Ce que cette première expérience m’a appris
Avec le recul, je cadrerais davantage le travail dès le départ, avec plus de documentation et des specs écrites avant de développer. Sur un projet où l’on est seul côté web et où une autre équipe dépend de vos routes, ce cadre sert de référence commune et évite de redécouvrir les règles au moment de les modifier.
C’est aujourd’hui ma façon de travailler : une fonctionnalité non triviale commence par une spec et un plan, comme je le décris dans l’article sur Claude Code au quotidien.