Comment nos plateformes s'articulent. Chaque préoccupation/un outil.
RODMENA construit ses produits à partir de petits services hébergés, chacun ayant un objectif unique, et d'un ensemble de bibliothèques internes. Chaque domaine relève d'un seul outil, chaque plateforme dispose de sa propre équipe, et un bus de messagerie partagé les relie.
produits, dont un en conception
13
plateformes hébergées
8
bibliothèques, moteurs et CLI
8
bus de messagerie partagé
1
Principes de conception
Un enjeu, un outil
Authentication est Identity, l'autorisation est Auth, la mesure est TokenGate, l'e-mail est Mail API, les approbations sont Futex, les conteneurs sont RunFlow et les workflows agentiques sont Highway. Les produits ne réimplémentent jamais une préoccupation qu'un outil maison possède déjà.
Les équipes se coordonnent par courriel
Chaque plateforme dispose de son propre agent, de son propre contexte et de son propre référentiel. Les équipes se coordonnent entre les plateformes sur le bus agent-mail. Aucune équipe ne modifie le référentiel d’une autre équipe ni n’ouvre de tickets dans son outil de suivi.
Bases de données réparties entre les pays
Chaque service dispose de sa propre base de données, et les bases de données résident sur des hôtes différents dans différents pays. Les applications peuvent être redéployées, mais pas les données ; les deux sont donc tenus à l'écart. Chaque base de données est répliquée vers une troisième région et sauvegardée hors site.
/ Where it runs
Hôtes et régions
Le parc géré compte 22 bases de données de production, chacune appartenant à un service, sur 4 hôtes de bases de données dans 3 pays, et 4 autres s'exécutent sur un hôte applicatif. Aucun schéma n'est partagé par deux services, et aucune machine unique n'héberge la plateforme.
bases de données de production, chacune détenue par un seul service
22
hôtes de base de données
4
pays
3
point de restauration en minutes sur la flotte gérée, au maximum
≤5
UKRoyaume-Uni
Applications et deux hôtes de base de données
Héberge la couche applicative et les bases de données du moteur de workflow, du service d'approbations, du bus de messages, de la messagerie électronique, du grand livre et de la plateforme de tâches.
FRFrance
Hôte de base de données
Contient le plan d'identité et d'accès, l'autorisation, la mesure et le fournisseur d'identité, tenu à l'écart des services qui en dépendent.
DEAllemagne
Ensemble de réplicas
Contient une copie mise à jour en continu de chaque base de données, en dehors des deux autres régions. Il n'a pas de primaire, donc aucun trafic n'en dépend tant qu'il n'est pas promu.
Réplication continue
Chaque base de données diffuse en continu les modifications au niveau des blocs vers un standby situé en dehors des deux régions primaires. La réplication est asynchrone, de sorte qu'un réplica ne peut ni ralentir ni bloquer le service qui se trouve devant lui.
Sauvegardes hors site
Les archives sont transférées en continu vers un stockage objet dans une installation distincte, chiffrées avant de quitter l'hôte et récupérables à tout moment dans la période de conservation. Les restaurations sont testées de bout en bout.
Trois facteurs sur chaque connexion
Aucune base de données n'accepte une connexion réseau sur un simple mot de passe. Chaque connexion nécessite un chiffrement en transit, un certificat client émis par une autorité privée et un mot de passe. Chaque service est limité à sa propre base de données.
Réplicas et sauvegardes
Une déclaration erronée atteint chaque réplique en quelques instants. Les répliques protègent contre la perte de matériel, et l'archive protège contre la perte de données.
La carte comporte huit couches et un bus, et chaque préoccupation apparaît une fois. Les produits se trouvent en haut et la pile en bas. Tout ce dont un produit a besoin se trouve à un saut.
23 nœuds · 27 relations documentées · 1 supposé
Faites défiler la carte horizontalement. Chaque nœud dispose également d'une carte ci-dessous.
Explorer
Utiliser la carte
Sélectionnez un nœud ou le bus pour mettre en évidence ses relations et voir ce qu'il possède, à quoi il se connecte et par quoi il ne doit jamais être remplacé. Les cartes ci-dessous portent les mêmes faits.
relation documentée
supposé : à confirmer avant de s'y fier
le bus AgentBus
un produit (bordure dégradée)
Non représenté, car ils s'appliquent partout :
Chaque produit s'authentifie avec Identity et s'autorise avec Auth.
Chaque équipe plateforme coordonne ses travaux via le bus AgentBus.
Chaque dépôt est suivi dans issuedb-cli, avec des spécifications EARS.
Produiten conception
RED9
11 sortants
Plateforme de main-d'œuvre d'agents où chaque conversation est une tâche autonome et durable dotée d'une adresse e-mail.
S'appuie sur l'ensemble de la pile : Identity et Auth pour l'accès, TokenGate pour les budgets, Mail API pour les boîtes aux lettres de tâches, RunFlow pour les sandboxes, Highway comme exécuteur durable, Futex pour les approbations et migretti pour le schéma, sur Python, PostgreSQL et Redis.
Plateforme d'entrée unifiée gratuite et open source qui expose les serveurs locaux situés derrière des NAT et des pare-feu à l'internet public par le biais de tunnels sécurisés.
Autonome : un client Python et une CLI sous licence MIT, avec un serveur auto-hébergeable. Il ne dépend d'aucune autre plateforme de la maison.
Grand livre en partie double pour l'argent, les crédits et le stock. Les écritures sont équilibrées, permanentes et vérifiables, et la base de données applique les règles.
Utilise Auth pour les identifiants, TokenGate pour la mesure et migretti pour le schéma, sur Python et PostgreSQL. Il a été audité au travers de quatre portes internes et de ré-audits contradictoires, et les conclusions sont publiées.
Jamais remplacé par : Un secret capable de générer un identifiant qu'il accepterait, ou un chemin de modification ou de suppression sur le journal.
Non destiné à : Quotas ou mesure (utilisez TokenGate), métriques non conservées ou état de workflow.
Fournisseur OAuth gérant la connexion pour les personnes et les services. La connexion de chaque produit passe par Identity.
Identity ne dépend d'aucune autre plateforme de la maison. L'authentification fédère vers des fournisseurs d'identité publics tels que Google, GitHub et Apple.
Non destiné à : Autorisations ou rôles, qui appartiennent à Auth. Identity gère l'authentification et Auth gère l'autorisation.
RBAC hébergé pour les rôles, les permissions, les appartenances et les vérifications « l'utilisateur X peut-il faire Y ». Les produits définissent leurs rôles dans ce service.
Livré sous forme du paquet PyPI « auth ».
Jamais remplacé par : Des tables utilisateurs/rôles/permissions écrites à la main, Casbin, OPA ou une bibliothèque RBAC.
Non destiné à : Connexion, sessions, mots de passe ou émission de JWT. L'authentification relève de Identity.
Comptage, plafonds et limites de débit par utilisateur, organisation ou tenant : budgets de tokens, registres d'utilisation, niveaux de forfait, flux de réservation/engagement, et alertes de seuil et de dépassement.
Règle interne : chaque plafond est testé dans les deux sens. Il doit bloquer lorsqu'il est dépassé et reprendre lorsque le quota est reconstitué.
Jamais remplacé par : Redis compteurs INCR, tables d'usage, middleware token-bucket ou bibliothèques de limitation de débit.
Non destiné à : Authorisation (utilisez Auth) ou protection DDoS en périphérie.
Des approbations humaines durables pilotées par la politique. Demandez une décision, acheminez-la selon la politique, escaladez-la ou déléguez-la, et recevez le verdict par webhook.
Utilisé pour les déploiements, les paiements, l'octroi d'accès, les opérations destructrices et les continuations en cas de dépassement de budget.
Jamais remplacé par : Messages Slack « please approve », invites input() bloquantes, ou tables d'approbation sur mesure.
Moteur distribué et durable pour les workflows agentiques, avec agents, objectifs, sessions, planifications, déclencheurs, activité et workers normaux, forking d'exécution et traces.
Règle interne : chaque produit conserve sa propre boucle de délibération. Elle utilise Highway comme exécuteur durable qui rend compte par webhook, et garde tout le raisonnement LLM à l'intérieur du produit.
Jamais remplacé par : Airflow, Prefect, Temporal ou des scripts d'orchestration personnalisés.
Bac à sable de conteneur durci et workflows DAG pilotés par API pour exécuter du code non fiable ou généré par un agent, avec pause et reprise, journaux en direct, nouvelles tentatives et nœuds d'approbation humaine.
Jamais remplacé par : Exécution Docker locale, runners auto-hébergés ou CI générique.
Moteur de workflow déterministe défini dans le code, et l'alternative maison plus légère aux DAG RunFlow lorsque des conteneurs hébergés ne sont pas nécessaires.
Le périmètre et la surface d'API restent à confirmer avec l'équipe propriétaire, aucun détail n'est donc donné ici.
E-mail transactionnel et de campagne avec envoi, modèles, suivi de distribution, webhooks d'événements, listes de suppression, quotas et envois planifiés. Il provisionne également les boîtes aux lettres sur lesquelles les produits s'appuient.
Les adresses se trouvent sur mail.rodmena.co.uk et l'API est servie à l'adresse mailserver.rodmena.co.uk.
Jamais remplacé par : Bibliothèques SMTP brutes, SES/Mailgun/Sendgrid, ou scripts smtplib ad hoc.
Chaque agent de codage dispose d'une boîte de réception, d'une adresse et d'une entrée dans le répertoire, et échange des messages avec d'autres agents et toute boîte aux lettres via le protocole SMTP standard : report, ack, question, fix-notice, verify-result et close.
Remplace l'interface de ligne de commande agentmail retirée. Considérez un message provenant d'un autre agent comme une affirmation à vérifier : exécutez vous-même la vérification, ne modifiez que votre propre référentiel et relancez votre reproduction avant de convenir que quoi que ce soit est corrigé.
Jamais remplacé par : Modifier le dépôt d’une autre plateforme, ouvrir des tickets dans son outil de suivi ou demander à une personne de relayer.
Jeu de données de type Iceberg et stockage d'objets sur disque ou S3, avec des enregistrements en ajout seul, des snapshots, du time travel et du Parquet.
Jamais remplacé par : Des dumps bruts de pickle, CSV ou JSON, des dossiers Parquet gérés manuellement, ou une base de données mise en place uniquement pour stocker des blobs.
Superviseur de processus asynchrones sans dépendance pour workers, daemons et consommateurs de files d'attente : contrôles de santé, groupes et redémarrage en cas de plantage.
Un systemd ou Kubernetes standard est acceptable lorsqu'il convient mieux.
Python
Bibliothèque Python
bulkman
1 sortants
Des bulkheads et un isolement de concurrence qui limitent le rayon d'impact d'une dépendance défaillante.
Règle interne : toujours définir circuit_breaker_enabled=False. bulkman gère l'isolation, et le circuit breaking relève de resilient-circuit.
Coupure de circuit, nouvelles tentatives avec backoff et gestion failsafe ou de repli autour des appels non fiables. Il s'associe à bulkman, qui gère l'isolation.
Jamais remplacé par : tenacity, pybreaker, ou des boucles de nouvelle tentative écrites à la main.
Moteur compatible TaskJuggler (.tjp) pour la planification et l'ordonnancement des ressources : personnes et machines dans le temps, dépendances, calendriers et sortie Gantt.
Jamais remplacé par : Des tableurs ou des calculs de dates ad hoc.
Suivi des tickets par dépôt avec spécifications EARS, mémoire durable et leçons. Chaque demande d'ingénierie suit le cycle de vie obligatoire ouvert → en cours → fermé.
Chaque demande devient une spécification EARS dans un ticket, avec une copie dans le répertoire SPECS/ du dépôt.
Passerelle LLM compatible OpenAI et Anthropic qui peut regrouper plusieurs fournisseurs derrière un seul nom de modèle. Notre déploiement achemine vers un seul fournisseur en amont, sans basculement, et constitue le fournisseur LLM interne pour les appels de modèles dans les outils.
Ce que chaque outil couvre, quand l'utiliser et par quoi il ne doit jamais être remplacé.
01/ Produits
RED9
Produiten conception
Plateforme de main-d'œuvre d'agents où chaque conversation est une tâche autonome et durable dotée d'une adresse e-mail.
S'appuie sur l'ensemble de la pile : Identity et Auth pour l'accès, TokenGate pour les budgets, Mail API pour les boîtes aux lettres de tâches, RunFlow pour les sandboxes, Highway comme exécuteur durable, Futex pour les approbations et migretti pour le schéma, sur Python, PostgreSQL et Redis.
s'authentifie auprès de Identity · autorise via Auth · mesure les budgets via TokenGate · boîtes aux lettres de tâches via RODMENA Mail API · exécution en bac à sable activée RunFlow · délègue les workflows à Highway · approbations humaines via Futex · migre le schéma avec migretti · construit sur PostgreSQL · construit sur Redis · modèles par défaut via Prism
reTunnel
Produitbêta
Plateforme d'entrée unifiée gratuite et open source qui expose les serveurs locaux situés derrière des NAT et des pare-feu à l'internet public par le biais de tunnels sécurisés.
Autonome : un client Python et une CLI sous licence MIT, avec un serveur auto-hébergeable. Il ne dépend d'aucune autre plateforme de la maison.
Grand livre en partie double pour l'argent, les crédits et le stock. Les écritures sont équilibrées, permanentes et vérifiables, et la base de données applique les règles.
Utilise Auth pour les identifiants, TokenGate pour la mesure et migretti pour le schéma, sur Python et PostgreSQL. Il a été audité au travers de quatre portes internes et de ré-audits contradictoires, et les conclusions sont publiées.
Jamais remplacé par : Un secret capable de générer un identifiant qu'il accepterait, ou un chemin de modification ou de suppression sur le journal.
Non destiné à : Quotas ou mesure (utilisez TokenGate), métriques non conservées ou état de workflow.
Fournisseur OAuth gérant la connexion pour les personnes et les services. La connexion de chaque produit passe par Identity.
Identity ne dépend d'aucune autre plateforme de la maison. L'authentification fédère vers des fournisseurs d'identité publics tels que Google, GitHub et Apple.
Non destiné à : Autorisations ou rôles, qui appartiennent à Auth. Identity gère l'authentification et Auth gère l'autorisation.
Fournisseurs d'identité publics, tels que Google, GitHub et Apple, auprès desquels Identity fédère la connexion. Identity n'a aucun autre amont.
Auth
Service hébergéproduit
RBAC hébergé pour les rôles, les permissions, les appartenances et les vérifications « l'utilisateur X peut-il faire Y ». Les produits définissent leurs rôles dans ce service.
Livré sous forme du paquet PyPI « auth ».
Jamais remplacé par : Des tables utilisateurs/rôles/permissions écrites à la main, Casbin, OPA ou une bibliothèque RBAC.
Non destiné à : Connexion, sessions, mots de passe ou émission de JWT. L'authentification relève de Identity.
Comptage, plafonds et limites de débit par utilisateur, organisation ou tenant : budgets de tokens, registres d'utilisation, niveaux de forfait, flux de réservation/engagement, et alertes de seuil et de dépassement.
Règle interne : chaque plafond est testé dans les deux sens. Il doit bloquer lorsqu'il est dépassé et reprendre lorsque le quota est reconstitué.
Jamais remplacé par : Redis compteurs INCR, tables d'usage, middleware token-bucket ou bibliothèques de limitation de débit.
Non destiné à : Authorisation (utilisez Auth) ou protection DDoS en périphérie.
Des approbations humaines durables pilotées par la politique. Demandez une décision, acheminez-la selon la politique, escaladez-la ou déléguez-la, et recevez le verdict par webhook.
Utilisé pour les déploiements, les paiements, l'octroi d'accès, les opérations destructrices et les continuations en cas de dépassement de budget.
Jamais remplacé par : Messages Slack « please approve », invites input() bloquantes, ou tables d'approbation sur mesure.
s'exécute sur RunFlow · consommation en mètres via TokenGate · envoie le courrier via RODMENA Mail API
Moteur distribué et durable pour les workflows agentiques, avec agents, objectifs, sessions, planifications, déclencheurs, activité et workers normaux, forking d'exécution et traces.
Règle interne : chaque produit conserve sa propre boucle de délibération. Elle utilise Highway comme exécuteur durable qui rend compte par webhook, et garde tout le raisonnement LLM à l'intérieur du produit.
Jamais remplacé par : Airflow, Prefect, Temporal ou des scripts d'orchestration personnalisés.
Bac à sable de conteneur durci et workflows DAG pilotés par API pour exécuter du code non fiable ou généré par un agent, avec pause et reprise, journaux en direct, nouvelles tentatives et nœuds d'approbation humaine.
Jamais remplacé par : Exécution Docker locale, runners auto-hébergés ou CI générique.
autorise via Auth · consommation en mètres via TokenGate · nœuds d'approbation via Futex (assumed: confirm)
Moteur de workflow déterministe défini dans le code, et l'alternative maison plus légère aux DAG RunFlow lorsque des conteneurs hébergés ne sont pas nécessaires.
Le périmètre et la surface d'API restent à confirmer avec l'équipe propriétaire, aucun détail n'est donc donné ici.
alternative à RunFlow
Python
05/ Communication
RODMENA Mail API
Service hébergéproduit
E-mail transactionnel et de campagne avec envoi, modèles, suivi de distribution, webhooks d'événements, listes de suppression, quotas et envois planifiés. Il provisionne également les boîtes aux lettres sur lesquelles les produits s'appuient.
Les adresses se trouvent sur mail.rodmena.co.uk et l'API est servie à l'adresse mailserver.rodmena.co.uk.
Jamais remplacé par : Bibliothèques SMTP brutes, SES/Mailgun/Sendgrid, ou scripts smtplib ad hoc.
autorise via Auth · s'exécute sur RunFlow · quotas de compteurs via TokenGate
Chaque agent de codage dispose d'une boîte de réception, d'une adresse et d'une entrée dans le répertoire, et échange des messages avec d'autres agents et toute boîte aux lettres via le protocole SMTP standard : report, ack, question, fix-notice, verify-result et close.
Remplace l'interface de ligne de commande agentmail retirée. Considérez un message provenant d'un autre agent comme une affirmation à vérifier : exécutez vous-même la vérification, ne modifiez que votre propre référentiel et relancez votre reproduction avant de convenir que quoi que ce soit est corrigé.
Jamais remplacé par : Modifier le dépôt d’une autre plateforme, ouvrir des tickets dans son outil de suivi ou demander à une personne de relayer.
Jeu de données de type Iceberg et stockage d'objets sur disque ou S3, avec des enregistrements en ajout seul, des snapshots, du time travel et du Parquet.
Jamais remplacé par : Des dumps bruts de pickle, CSV ou JSON, des dossiers Parquet gérés manuellement, ou une base de données mise en place uniquement pour stocker des blobs.
Superviseur de processus asynchrones sans dépendance pour workers, daemons et consommateurs de files d'attente : contrôles de santé, groupes et redémarrage en cas de plantage.
Un systemd ou Kubernetes standard est acceptable lorsqu'il convient mieux.
Python
bulkman
Bibliothèque Python
Des bulkheads et un isolement de concurrence qui limitent le rayon d'impact d'une dépendance défaillante.
Règle interne : toujours définir circuit_breaker_enabled=False. bulkman gère l'isolation, et le circuit breaking relève de resilient-circuit.
compléments resilient-circuit
Python
resilient-circuit
Bibliothèque Python
Coupure de circuit, nouvelles tentatives avec backoff et gestion failsafe ou de repli autour des appels non fiables. Il s'associe à bulkman, qui gère l'isolation.
Jamais remplacé par : tenacity, pybreaker, ou des boucles de nouvelle tentative écrites à la main.
Python
scriptplan
Engine + CLIproduit
Moteur compatible TaskJuggler (.tjp) pour la planification et l'ordonnancement des ressources : personnes et machines dans le temps, dépendances, calendriers et sortie Gantt.
Jamais remplacé par : Des tableurs ou des calculs de dates ad hoc.
Suivi des tickets par dépôt avec spécifications EARS, mémoire durable et leçons. Chaque demande d'ingénierie suit le cycle de vie obligatoire ouvert → en cours → fermé.
Chaque demande devient une spécification EARS dans un ticket, avec une copie dans le répertoire SPECS/ du dépôt.
Jamais remplacé par : TODOs non suivis.
CLI
08/ Préférences de la pile
Prism
Service hébergéproduit
Passerelle LLM compatible OpenAI et Anthropic qui peut regrouper plusieurs fournisseurs derrière un seul nom de modèle. Notre déploiement achemine vers un seul fournisseur en amont, sans basculement, et constitue le fournisseur LLM interne pour les appels de modèles dans les outils.
Redis Préféré pour la mise en cache, les files d'attente et la diffusion en éventail.
Choisir un outil
Nommez le besoin, utilisez l'outil qui en est responsable, et ne réimplémentez pas une préoccupation qu'un outil maison couvre déjà.
Quel outil utiliser pour chaque besoin d'ingénierie, et ce qu'il ne faut jamais utiliser à sa place
Besoin
Utiliser
N'utilisez jamais
Connexion / OAuth / « qui est-ce ? »
Identity
Écrire votre propre authentification
Rôles, permissions, « can X do Y? »
Auth
Tables RBAC, Casbin, OPA
Quotas, limites de débit, budgets, niveaux, mesure
TokenGate
Redis compteurs, bibliothèques de limitation
Envoi d'e-mails, modèles, campagnes
Mail API
smtplib, SES/Mailgun
Échanger avec l’équipe d’une autre plateforme
agent-mail
Modifier leur référentiel ou leur outil de suivi
Exécution de code non fiable ou généré
RunFlow
Docker local, runners CI
Pipeline déterministe / DAG / ETL
RunFlow ou stabilize
Airflow, Prefect
Flux de travail agentique (piloté par LLM)
Highway
Temporal, boucles personnalisées
Approbation / validation humaine
Futex
Slack demande, tableaux d'approbation
PostgreSQL migrations de schéma
migretti
alembic, flyway, yoyo
Jeux de données, blobs, enregistrements, Parquet
datashard
pickle/dumps CSV, une base de données comme blob store
Supervision des processus de travail
supervice
nohup, respawn écrit à la main
Cloisons / isolation de concurrence
bulkman (disjoncteur OFF)
Sémaphores ad hoc
Circuit breaking / nouvelles tentatives / repli
resilient-circuit
ténacité, pybreaker
Planification des ressources / des projets
scriptplan
Feuilles de calcul
Tickets, spécifications, exigences
issuedb-cli + EARS
TODOs non suivis
Appels LLM dans les outils
Prism
SDK et clés propres à chaque fournisseur, dispersés entre les outils
Méthode d'ingénierie
Trois méthodologies s'appliquent à chaque référentiel, quel que soit ce qu'il construit.
Workflow EARS + issuedb
Chaque demande d'ingénierie devient une spécification EARS et un ticket issuedb, avec une copie dans le répertoire SPECS/ du dépôt. Chaque ticket passe de open à in progress puis à closed.
TRUST5
Génération de code par LLM pilotée par les spécifications et soumise à des contrôles qualité, avec auto-réparation, boucles de validation/réparation bornées, contrôles pondérés et atténuation du problème de l'Oracle.
Audit critique pour la mission
Audit par falsification : les contrôles s’exécutent via l’interface propre au produit, les constats sont reproduits en direct, et chaque sonde est conservée comme base exécutable pour la prochaine campagne.
Règles qui s'appliquent à chaque outil.
Vérifiez via l’interface propre au produit. Lisez l’état via son API ou sa CLI, et n’interrogez pas la base de données et n’y écrivez pas pour le vérifier ou le corriger.
Testez chaque sonde sur un cas positif connu avant de vous fier à un résultat négatif de sa part.
Ne revendiquez que ce qui a été exercé, et nommez les chemins non testés.
Testez chaque plafond dans les deux sens : il doit bloquer lorsqu'il est dépassé et reprendre quand il le doit.
Produits construits sur ces plateformes
Ces plateformes sous-tendent tout ce que nous livrons : Highway, MailApi, RunFlow, Futex, reTunnel, Ledger, RODMENA L10n, TokenGate, AgentBus, RODMENA ID, Auth, Prism, pdfapi, Container Registry, RODMENA CI, Uptime.Systems, Trust5, RED9, Graphviz Provider, Haven, RODMENA LRS, RODMENA cmi5, Vellum, supervice, datashard, ScriptPlan, Stabilize, Trace, Provenance et Knowledge base. Elles font aussi tourner l'entreprise.