Cas anonymisé — Système de gestion pour un centre de tutorat à 3 succursales : horaires, présences, décompte des forfaits et paie dans une seule chaîne
Remplacer un logiciel SaaS de planification facturé par utilisateur par un système de gestion sur mesure pour une chaîne de tutorat de trois succursales : les présences sont la source unique de vérité, et le décompte des forfaits, les factures et les heures des enseignants en découlent.
Un système de gestion sur mesure pour une chaîne de tutorat de trois succursales, en remplacement d’un SaaS facturé par utilisateur : dossiers des élèves et des familles, catalogue de cours, horaires récurrents avec détection des conflits, suivi des présences, forfaits de cours, factures et paiements; les heures des enseignants sont transmises automatiquement, au moyen d’API versionnées, à un système de gestion du personnel pour la paie. Identité du client anonymisée.
Le problème opérationnel d’un centre de tutorat n’est jamais « une fonctionnalité manquante » : c’est une chaîne de données rompue. Les horaires sont dans un système, les présences dans des tableurs, le rapprochement des forfaits se fait à la main et les heures des enseignants sont recomptées à la fin du mois. Chaque maillon peut céder, et chaque mois, le même travail recommence. Le SaaS étranger qu’utilisait le centre facturait par utilisateur, ne s’adaptait pas aux flux de travail locaux et ne laissait pas sortir les données. Nous avons conçu pour lui un système de gestion sur mesure reposant sur une décision de conception centrale : les présences sont la source unique de vérité, et tout le reste en découle.
Note de confidentialité : le nom de l’établissement et les renseignements sur les élèves ont été retirés. Seuls l’architecture, le flux de travail et les résultats livrés sont décrits.
Le défi
Les trois succursales partageaient un logiciel SaaS de planification facturé par utilisateur : les cours récurrents entraient en conflit, les présences ne concordaient jamais avec le décompte des forfaits, les soldes des forfaits étaient tenus à la main et les heures des enseignants étaient compilées manuellement à la fin du mois. Plus de succursales signifiait plus de rapprochements et des erreurs plus difficiles à retracer.
Notre approche
Reconstruire la chaîne de données autour des présences comme source de vérité. Les dossiers des élèves et des familles, le catalogue de cours et les horaires récurrents (avec détection des conflits sur trois axes : enseignant, salle et élève) se trouvent en amont. Une fois les présences d’un cours confirmées, elles alimentent automatiquement tout l’aval : déduction des forfaits, production des factures, rapprochement des paiements et cumul des heures des enseignants. Les heures des enseignants ne sont plus compilées à la main : elles sont transmises automatiquement, au moyen d’API versionnées, au système de gestion du personnel que nous avons conçu pour le même groupe client, qui alimente la paie. Le système est livré en modules, avec des données unifiées et un cloisonnement des permissions par succursale.
Résultats
Les trois succursales fonctionnent désormais dans un seul système : les conflits d’horaire sont bloqués dès la création; une fois les présences confirmées, le décompte, les soldes et les factures se mettent à jour automatiquement, ce qui élimine le rapprochement manuel de fin de mois; les heures des enseignants s’accumulent en temps réel et alimentent directement la paie. Le centre a quitté le SaaS facturé par utilisateur et possède pleinement ses données.
Les présences comme source unique de vérité
Chaque flux d’argent et de temps dans le système découle des registres de présence :
- Présence confirmée → les heures du forfait sont déduites automatiquement, et les soldes sont visibles en temps réel.
- Présences cumulées → les factures sont générées à partir des cours réellement suivis; chaque ligne que voit un parent repose sur un registre de présence.
- Présences = heures → la rémunération des enseignants s’accumule à partir des présences confirmées, sans compilation de fin de mois.
- Modifications des présences tracées → chaque saisie rétroactive ou correction est consignée, ce qui rend le rapprochement traçable.
Cette conception élimine d’emblée la question « quel chiffre est le bon » : les présences sont la seule donnée saisie, tout le reste est calculé.
Horaires récurrents avec détection des conflits sur trois axes
La planification des cours de tutorat est difficile parce qu’elle est récurrente : un cours occupe la même plage horaire pendant 20 semaines, et les changements de salle, les remplacements d’enseignants et les transferts d’élèves en cours de session sont courants. Le système vérifie les conflits selon l’enseignant, la salle et l’élève à la création et à la modification : les conflits apparaissent avant l’enregistrement, pas le premier jour de cours.
Des heures directement versées à la paie : un échange versionné entre deux systèmes
Les enseignants cumulent des heures dans le système de gestion du centre et sont payés par le système de gestion du personnel. Les deux communiquent au moyen d’API versionnées : le système du centre transmet les heures issues des présences confirmées, et le système de paie les reçoit avec des contrôles d’idempotence et de version. Une nouvelle tentative ne paie jamais deux fois, et l’évolution des interfaces ne compromet jamais le rapprochement.
- Envois idempotents : les heures d’un même cours ne peuvent pas être comptabilisées deux fois à cause d’une nouvelle tentative.
- Interfaces versionnées : chaque côté peut évoluer sans compromettre le rapprochement de l’autre.
- Le système de gestion du personnel est notre propre produit autonome (12 modules activables : pointage, congés, évaluations, tâches, commissions, paie, etc.).
Détails techniques
- Back-end Python (Flask) + PostgreSQL + file de tâches Redis, front-end Next.js, déployés avec Docker Compose.
- Partage une même architecture de plateforme avec les produits CRM et de gestion du personnel du même groupe client : elle est copiée délibérément plutôt que couplée par une bibliothèque partagée, pour que chaque produit évolue de façon indépendante.
- Livraison modulaire : dossiers, horaires, présences, forfaits et facturation/paiements sont des modules indépendants, activés au besoin.
- Une seule base de données pour les trois succursales, avec cloisonnement des permissions par succursale; les rapports multisuccursales fonctionnent d’emblée.
Leçons à retenir
- La première décision de conception d’un système de gestion est le choix de la source unique de vérité. Faites le mauvais choix (ou n’en faites aucun) et tout ce qui est en aval devient du rapprochement.
- Remplacer un SaaS, ce n’est pas seulement économiser des frais d’abonnement : c’est posséder ses données et s’adapter aux flux de travail locaux, ce qui ne sera jamais la priorité d’un fournisseur SaaS étranger.
- Les interfaces financières entre systèmes doivent être idempotentes et versionnées, sinon chaque nouvelle tentative et chaque mise à niveau deviennent un incident financier.
Vous voulez des résultats semblables ?
Parlez-nous de votre entreprise et nous concevrons une preuve de concept.