Un « Brain » central pour arrêter de donner les clés du serveur à tout le monde

Un service central — surnommé le « Brain » — devient la porte d'entrée unique vers Odoo, Shopify et le mail. Il détient les secrets côté serveur, traduit chaque appel en « jeton → identité → rôle », journalise qui a fait quoi, et expose des capacités métier réutilisables. L'objectif tient en une phrase : que l'équipe crée des produits sans jamais toucher au serveur.

Contexte — le problème

Pour créer un produit dans Odoo via un agent, il fallait jusque-là une clé SSH sur le serveur et savoir manier un dépôt de code. Résultat : soit Hugo faisait tout, soit on distribuait des accès serveur larges à plusieurs personnes — impossible à tracer, difficile à retirer, et une seule erreur pouvait toucher la prod. Le vrai besoin n'était pas « plus d'accès », mais « la bonne capacité, pour la bonne personne, avec une trace ».

Ce qui a été fait

Mise en place d'un service central (le « Brain ») qui sert de porte d'entrée unique :

• Il détient les secrets côté serveur ; personne d'autre ne les voit.
• Chaque appel porte un jeton personnel → une identité → un rôle (lecture / préparation / écriture / mise en ligne). On donne exactement le niveau utile, ni plus.
• Chaque action est écrite dans un journal durable (« qui a demandé quoi, quand »).
• Une capacité = un même moule : un module + une route + un périmètre d'accès, exposé sur deux surfaces — dans l'assistant en ligne de commande et sur une page web interne à accès protégé.
• Garde-fous repris de l'outil historique : rapprochement anti-doublon avant toute création, et un produit créé n'est jamais publié automatiquement (étape de mise en ligne séparée et explicite).

Résultat : service en production, 3 accès distribués à l'équipe avec des rôles distincts, 2 surfaces d'usage, et la base de code mergée sur la branche principale pour que deux personnes puissent désormais ajouter leurs propres capacités et les déployer elles-mêmes, sans repasser par Hugo.

Ce qui était difficile / ce qu'on a appris

Séparer deux questions qu'on confond toujours. « Qui détient les secrets » (le service, point) et « qui a le droit d'appeler quoi » (le jeton + le rôle) sont deux problèmes distincts. Une fois séparées, donner un accès devient réversible et traçable au lieu d'être un cadeau permanent.

La frontière, pas le fourre-tout. On a écrit noir sur blanc ce qui doit vivre dans le Brain (tout ce qui est partagé, qui écrit dans un système, ou qui doit être tracé / permissionné) et ce qui peut rester dehors (crons déterministes, prototypes perso, analytique en lecture). Sans cette règle, un service central devient vite un goulet d'étranglement.

Les pièges bêtes coûtent cher. Le service ne démarrait pas à cause d'un simple répertoire de travail mal réglé (erreur d'import), et deux briques ne « parlaient » pas parce qu'un même concept portait deux noms de champ différents. La leçon : figer un contrat de données stable entre les composants tôt, et tester le démarrage réel, pas seulement le code.

Garder l'humain sur les gestes sensibles. L'assistant ne fait pas les écritures de prod ni ne s'auto-attribue de droits — c'est l'humain qui lance ces gestes-là. Ça a ralenti par moments, mais c'est exactement le garde-fou qu'on veut.

Stack

Service en Python (bibliothèque standard, sans dépendances), authentification par jeton → rôles, journal sur base embarquée, API en écoute locale derrière un reverse-proxy, déploiement en service géré (systemd). Deux surfaces : un skill pour l'assistant en ligne de commande + une page web interne à accès protégé. Odoo et Shopify comme systèmes cibles.

Ce que ça illustre

Quand plusieurs personnes doivent piloter les mêmes systèmes, le bon réflexe n'est pas de distribuer des accès, mais de construire une porte d'entrée : elle garde les secrets, traduit « jeton → identité → rôle », journalise tout, et expose des capacités réutilisables sur le même moule. On passe d'« ouvrir des accès » à « exposer des capacités » — et l'équipe gagne en autonomie sans que personne ne perde le contrôle.