Socle API Pop

Le produit

Chaque application du groupe avait commencé avec son propre intermédiaire vers l’ERP. Le socle les remplace par un seul service, avec un jeu de routes centralisé et une base d’authentification commune : une même personne peut être consultant dans une application et jury dans une autre.

Architecture

• Une application FastAPI, des routeurs séparés strictement par préfixe (/certif, /network, /popcom, /mentor), chacun derrière sa propre chaîne de dépendances d’authentification
• Une identité, plusieurs profils : un seul compte Supabase, mais une table de profil par application, et un rôle toujours résolu dans le périmètre du produit appelé pour empêcher qu’un droit déborde d’une application à l’autre
• Deux clients Odoo : JSON-RPC sans état pour l’un, session Odoo renouvelée automatiquement pour les autres, avec appels aux contrôleurs des modules sur mesure
• Un proxy RPC sur liste blanche pour les fronts qui lisent directement certains modèles de l’ERP
• Des tâches de fond (synchronisations, relances, rappels) élues sur un seul worker par verrou de fichier, pour ne jamais envoyer un email en double quand le service tourne sur plusieurs workers

Ce que j’ai construit

• Les routeurs des trois produits dont j’avais la charge et leurs gardes d’accès
• La séparation identité / profil, mise au point avec un collègue quand le compte partagé a posé problème
• Les synchronisations Odoo vers Supabase et les envois déclenchés par changement d’état