Eros C.

EDITION DE LOGICIELS

Rendre le catalogue de skills accessible comme connecteur MCP depuis Claude et ChatGPT, pour la sortie du « Claude for Legal » d'Anthropic. Enjeu business : figurer dans les directories Anthropic, avec un trafic anticipé x10-50.Un serveur MCP doit reposer sur OAuth2 conforme à la spéc, avec du Dynamic Client Registration, face à des clients hétérogènes qui implémentent chacun le standard à leur manière : déconnexions intempestives (refresh tokens), scopes rejetés selon le client, conformité pointilleuse, limites de tokens.FastMCP couplé à un serveur d'autorisation Ory Hydra auto-hébergé, isolé du réseau : l'admin API de Hydra (non authentifiée, root sur l'identité) n'est jamais exposée publiquement, accès par DNS interne uniquement, protection par isolation et non par auth applicative. Un shim de DCR proxy normalise l'enregistrement des clients ; les autorisations incrémentales (scope step-up) ouvrent les skills privés sans réinstallation côté client/utilisateur. Côté catalogue, modèle de progressive disclosure : plutôt qu'un outil MCP par skill qui sature la tools/list et alourdit le contexte à chaque session (MCP abstraction tax) une façade de recherche BM25-like doublée d'une exposition orientée ressources skill://. L'agent découvre, cherche, puis ne charge le manifeste complet d'un skill qu'à la demande.Delivery autonome, infrastructure en IaC OpenTofu. Arbitrage d'architecture : d'abord un outil par skill pour la découvrabilité, puis pivot derrière la recherche-parapluie une fois la saturation de la liste d'outils constatée (avec + 150 skills). Arbitrage de perf : fuite mémoire en prod (~26 MB/h, OOM ~20 h) due à une ré-hydratation du catalogue à chaque appel, corrigé avec cache TTL 60 s avec asyncio.Lock + double-check pour dédupliquer le thundering herd au franchissement du TTL (10 requêtes concurrentes = 1 seul hit DB).

EDITION DE LOGICIELS

Le client faisait passer sa marketplace de skills juridiques d'un catalogue à un produit multi-tenant : praticiens avec compte personnel, mais aussi cabinets organisés en équipes, avec rôles et partage de skills. Sans ce socle : pas de propriété, pas de partage privé, pas de RGPD.Deux difficultés se cumulaient. Protéger les secrets d'identité (hash de mot de passe, secret MFA). Et, plus structurant, modéliser une autorisation multi-tenant sans trou : qui, dans quelle organisation, avec quel rôle, peut voir, exécuter ou éditer quel skill.Authentification maison : sessions cookie-first, OAuth Google/LinkedIn ou email/mdp, MFA TOTP, CSRF signed double-submit. Sur l'autorisation, un modèle d'organisation inspiré de GitHub : rôles owner/admin/member, équipes avec un invariant une-équipe-par-membre, owner court-circuitant les permissions d'équipe. Partage privé par grants au niveau ligne (skill_access), cycle de vie de publication par deux machines à états xstate (marketplace vs organisation). Décision structurante : descendre l'autorisation en base via Row-Level Security, jusqu'à la ligne, pas la rejouer dans chaque requête.En delivery autonome. Friction la plus coûteuse : ce RLS généralisé s'est propagé partout. Sous FORCE RLS, une requête oubliée ne lève pas d'erreur, elle renvoie zéro ligne en silence. Les bugs surgissaient loin de leur cause, surtout côté organisation : invitations, suppression d'org, skills partagés invisibles, serveurs MCP non chargés. Chaque accès a dû passer par le bon contexte (withRLS, withSystemRLS, SECURITY DEFINER), verrouillé par un test échouant à tout accès direct.Avec le recul, je modéliserais le graphe d'autorisation (rôles, équipes, grants) et les politiques RLS avant d'écrire le moindre flux.

EDITION DE LOGICIELS

Le client édite une marketplace de skills juridiques i.e. des automatisations publiées sous licences open-source. Pour améliorer la conversation, avant son téléchargement, l'utilisateur doit pouvoir tester l'automatisation via un environnement de test.L'enjeu : exécuter un wrapper de la CLI Claude Code sous le modèle BYOS. Faire tourner du code tiers non vérifié exposait l'infrastructure à des injections système, des path traversal, des endpoints non authentifiés et des fuites de jetons d'accès. La facturation des microVMs au CPU et au stockage rendait impératif un contrôle strict des ressources, sous peine de dérive budgétaire.Le SDK Claude Agent a été écarté car facturé à l'usage par clé API, ce qui bloquait l'exploitation des abonnements grand public des utilisateurs. J'ai conçu une architecture à la demande via des microVMs éphémères (sprites.dev), les flux TTY/STDIN encapsulés dans des tunnels WebSocket persistants pour garantir l'interactivité temps réel. L'isolation repose sur une défense en couches : egress deny-by-default avec allowlist par skill, restriction des capacités de l'agent (chmod/curl/wget interdits, CLAUDE.md verrouillé contre la prompt injection), un secret-token serveur propre à chaque sprite protégeant les endpoints de manipulation, un rate-limit par IP, et une défense en profondeur anti-exfiltration de jetons.En delivery autonome, j'ai implémenté le routage WebSocket/microVMs. La friction majeure : le cycle de vie des instances face aux déconnexions abruptes. J'ai développé un orchestrateur sur mesure recovery par re-création à l'état identique sur micro-coupure, et reapers purgeant les instances à la fermeture/au timeout, coupant court à toute facturation inutile.Avec le recul, j'aurais mis en place un warm pooling de microVMs pré-chargées avec les dépendances plutôt que de tout orchestrer à la volée, pour accélérer drastiquement l'initialisation.