Comment nos plateformes s’articulent. Chaque besoin/un outil.
RODMENA conçoit ses produits à partir d'un ensemble de bibliothèques internes et de petits services hébergés ayant chacun un rôle unique, et n'attribue chaque responsabilité qu'à un seul outil. Les plateformes disposent de leurs propres équipes et communiquent par le biais d'un bus de messagerie partagé.
produits
13
plateformes hébergées
8
bibliothèques, moteurs et CLI
8
bus de messagerie partagé
1
Principes de conception
Un besoin, un outil
L’authentification 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 un besoin qu’un outil maison couvre déjà.
Les équipes se coordonnent par e-mail
Chaque plateforme dispose de son propre agent, de son propre contexte et de son propre dépôt. Les équipes se coordonnent entre les plateformes sur le bus agent-mail. Aucune équipe ne modifie le dépôt d’une autre équipe ni n’ouvre de tickets dans son outil de suivi.
Bases de données réparties entre les pays
Les services disposent de leurs propres bases de données, sur différents hôtes dans différents pays. Une application peut être redéployée mais pas ses données, et nous séparons bien les deux. Toutes les bases de données sont répliquées vers une troisième région et sauvegardées hors site.
/ Where it runs
Hôtes et régions
Le parc géré comprend 22 bases de données de production, chacune détenue par un seul service, réparties sur 4 hôtes de base de données dans 3 pays, et 4 autres s'exécutent sur un hôte applicatif. Aucun service ne partage son schéma avec un autre, et la plateforme ne dépend d'aucune machine unique.
bases de données de production, chacune détenue par un seul service
22
hôtes de base de données
4
pays
3
minutes au maximum de point de reprise sur le parc géré
≤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
Toutes les bases de données transmettent les modifications au niveau bloc en continu vers un serveur de secours (standby) situé en dehors des deux régions principales. La réplication étant asynchrone, un réplica ne peut pas ralentir ni bloquer le service placé en amont.
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 restaurables à n’importe quel point dans le temps au cours de 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 de connexion réseau sur la seule base d'un mot de passe. Une connexion nécessite un chiffrement en transit, un certificat client délivré par une autorité privée ainsi qu'un mot de passe, et les services sont restreints à leurs propres bases de données.
Réplicas et sauvegardes
Une instruction erronée atteint l'ensemble des réplicas en quelques instants. Les réplicas protègent contre la perte de matériel, et l'archive protège contre la perte de données.
Sur les huit couches et le bus unique de la carte, chaque préoccupation n'apparaît qu'une seule fois. Les produits se trouvent au sommet, la pile technique à la base, et tout ce dont un produit a besoin est à portée directe.
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 surbrillance ses relations et voir ce qu'il possède, ce à quoi il se connecte et par quoi il ne doit jamais être remplacé. Les fiches ci-dessous répertorient également ces informations.
relation documentée
supposé : à confirmer avant de s’y fier
le bus agent-mail
un produit (bordure dégradée)
Non représentés, car ils s’appliquent partout :
Chaque produit s’authentifie avec Identity et gère ses autorisations avec Auth.
Chaque équipe plateforme coordonne ses travaux via le bus agent-mail.
Chaque dépôt est suivi dans issuedb-cli, avec des spécifications EARS.
Produitsur demande
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 technologique. Identity et Auth fournissent l'accès, TokenGate les budgets, Mail API les boîtes aux lettres de tâches et RunFlow les bacs à sable. Highway est l'exécuteur durable, Futex gère les approbations et migretti 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.
Un client et une CLI Python autonomes, sous licence MIT, fournis avec un serveur auto-hébergeable et ne dépendant d'aucune autre plateforme interne.
Grand livre en partie double pour les fonds, les crédits et les stocks. Ses écritures sont équilibrées, permanentes et vérifiables selon les règles appliquées par la base de données.
Conçu avec Python et PostgreSQL, utilisant Auth pour les identifiants, TokenGate pour le comptage et migretti pour le schéma. Il a fait l'objet de quatre jalons d'audit interne et de réaudits contradictoires, dont 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), des métriques qui ne sont pas des grandeurs conservées (sans équilibre débit/crédit) ou l’état d’un workflow.
Fournisseur OAuth gérant l'authentification des personnes et des services. La connexion à l'ensemble de nos produits s'effectue via Identity.
Identity ne dépend d’aucune autre plateforme 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 d’Identity.
Comptage, plafonds et limites de débit par utilisateur, organisation ou tenant. Il couvre les budgets de jetons, les registres d'utilisation, les niveaux de forfaits, les flux de réservation/validation, ainsi que les alertes de seuil et de dépassement.
Conformément aux règles internes, les plafonds sont testés dans les deux sens. Un plafond doit bloquer les requêtes lorsqu'il est dépassé et reprendre le traitement lorsqu'il est réapprovisionné.
Jamais remplacé par : Compteurs Redis INCR, tables d’usage, middleware token-bucket ou bibliothèques de limitation de débit.
Non destiné à : Autorisation (utilisez Auth) ou protection DDoS en périphérie.
Des approbations humaines durables pilotées par des politiques. Demandez une décision, acheminez-la selon une 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. Il fournit des agents, des objectifs, des sessions, des planifications, des déclencheurs, des workers d'activité et normaux, le forking d'exécutions et des traces.
Par règle interne, un produit conserve sa propre boucle de délibération. Il utilise Highway comme exécuteur durable qui transmet ses rapports par webhook et conserve l'ensemble du raisonnement LLM au sein du produit.
Jamais remplacé par : Airflow, Prefect, Temporal ou des scripts d’orchestration personnalisés.
Bac à sable (sandbox) de conteneurs renforcé et workflows DAG pilotés par API pour exécuter du code non approuvé ou généré par des agents. Les exécutions peuvent être suspendues et reprises, et disposent de journaux en direct, de nouvelles tentatives et de 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. Il s'agit de l'alternative interne plus légère aux DAG RunFlow lorsque les conteneurs hébergés ne sont pas nécessaires.
Nous ne donnons aucun détail ici, car le périmètre et la surface de l'API doivent encore être confirmés avec l'équipe responsable.
E-mail transactionnel et de campagne avec envoi, modèles, suivi de distribution, webhooks d’événements, listes d’exclusion, 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.
Un agent de codage dispose d'une boîte de réception, d'une adresse et d'une entrée dans le carnet d'adresses, et échange des messages avec d'autres agents et toute boîte aux lettres via le protocole SMTP standard. Les types de messages sont report, ack, question, fix-notice, verify-result et close.
Remplace la CLI agentmail retirée du service. Considérez tout message provenant d'un autre agent comme une affirmation et effectuez vous-même la vérification. Ne modifiez que votre propre dépôt et réexécutez votre reproduction avant de convenir qu'un élément 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.
Stockage de blobs et de jeux de données de type Iceberg sur disque ou S3 avec enregistrements en ajout seul, instantanés, voyage dans le temps (time travel) et 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 asynchrone sans dépendance pour les workers, les démons et les consommateurs de files d'attente. Il exécute des contrôles d'intégrité, gère des groupes et redémarre un processus 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.
La règle interne consiste à toujours définir circuit_breaker_enabled=False. bulkman gère l'isolation, et le coupe-circuit relève de resilient-circuit.
Disjoncteur (circuit breaking), nouvelles tentatives avec temporisation (backoff) et gestion des solutions de secours (failsafe ou fallback) autour des appels peu fiables. Associez-le à bulkman pour assurer l'isolation.
Jamais remplacé par : tenacity, pybreaker, ou des boucles de nouvelle tentative écrites à la main.
Moteur compatible TaskJuggler (.tjp) pour la planification des ressources. Il gère les personnes et les machines au fil du temps, les dépendances et les calendriers, et produit des diagrammes de Gantt.
Jamais remplacé par : Des tableurs ou des calculs de dates ad hoc.
Outil de suivi des tickets par dépôt intégrant spécifications EARS, mémoire durable et enseignements. Toutes les demandes d'ingénierie suivent le cycle de vie obligatoire open → in-progress → closed.
Les demandes d'ingénierie se transforment toutes en une spécification EARS au sein d'un ticket et dans une copie sous 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
Produitsur demande
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 technologique. Identity et Auth fournissent l'accès, TokenGate les budgets, Mail API les boîtes aux lettres de tâches et RunFlow les bacs à sable. Highway est l'exécuteur durable, Futex gère les approbations et migretti 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 sur 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
Produit
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.
Un client et une CLI Python autonomes, sous licence MIT, fournis avec un serveur auto-hébergeable et ne dépendant d'aucune autre plateforme interne.
Grand livre en partie double pour les fonds, les crédits et les stocks. Ses écritures sont équilibrées, permanentes et vérifiables selon les règles appliquées par la base de données.
Conçu avec Python et PostgreSQL, utilisant Auth pour les identifiants, TokenGate pour le comptage et migretti pour le schéma. Il a fait l'objet de quatre jalons d'audit interne et de réaudits contradictoires, dont 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), des métriques qui ne sont pas des grandeurs conservées (sans équilibre débit/crédit) ou l’état d’un workflow.
Fournisseur OAuth gérant l'authentification des personnes et des services. La connexion à l'ensemble de nos produits s'effectue via Identity.
Identity ne dépend d’aucune autre plateforme 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 d’Identity.
Comptage, plafonds et limites de débit par utilisateur, organisation ou tenant. Il couvre les budgets de jetons, les registres d'utilisation, les niveaux de forfaits, les flux de réservation/validation, ainsi que les alertes de seuil et de dépassement.
Conformément aux règles internes, les plafonds sont testés dans les deux sens. Un plafond doit bloquer les requêtes lorsqu'il est dépassé et reprendre le traitement lorsqu'il est réapprovisionné.
Jamais remplacé par : Compteurs Redis INCR, tables d’usage, middleware token-bucket ou bibliothèques de limitation de débit.
Non destiné à : Autorisation (utilisez Auth) ou protection DDoS en périphérie.
Des approbations humaines durables pilotées par des politiques. Demandez une décision, acheminez-la selon une 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 · mesure la consommation via TokenGate · envoie le courrier via RODMENA Mail API
Moteur distribué et durable pour les workflows agentiques. Il fournit des agents, des objectifs, des sessions, des planifications, des déclencheurs, des workers d'activité et normaux, le forking d'exécutions et des traces.
Par règle interne, un produit conserve sa propre boucle de délibération. Il utilise Highway comme exécuteur durable qui transmet ses rapports par webhook et conserve l'ensemble du raisonnement LLM au sein du produit.
Jamais remplacé par : Airflow, Prefect, Temporal ou des scripts d’orchestration personnalisés.
Bac à sable (sandbox) de conteneurs renforcé et workflows DAG pilotés par API pour exécuter du code non approuvé ou généré par des agents. Les exécutions peuvent être suspendues et reprises, et disposent de journaux en direct, de nouvelles tentatives et de 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 · mesure la consommation via TokenGate · nœuds d’approbation via Futex (supposé : à confirmer)
Moteur de workflow déterministe défini dans le code. Il s'agit de l'alternative interne plus légère aux DAG RunFlow lorsque les conteneurs hébergés ne sont pas nécessaires.
Nous ne donnons aucun détail ici, car le périmètre et la surface de l'API doivent encore être confirmés avec l'équipe responsable.
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 d’exclusion, 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 · mesure les quotas via TokenGate
Un agent de codage dispose d'une boîte de réception, d'une adresse et d'une entrée dans le carnet d'adresses, et échange des messages avec d'autres agents et toute boîte aux lettres via le protocole SMTP standard. Les types de messages sont report, ack, question, fix-notice, verify-result et close.
Remplace la CLI agentmail retirée du service. Considérez tout message provenant d'un autre agent comme une affirmation et effectuez vous-même la vérification. Ne modifiez que votre propre dépôt et réexécutez votre reproduction avant de convenir qu'un élément 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.
Stockage de blobs et de jeux de données de type Iceberg sur disque ou S3 avec enregistrements en ajout seul, instantanés, voyage dans le temps (time travel) et 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 asynchrone sans dépendance pour les workers, les démons et les consommateurs de files d'attente. Il exécute des contrôles d'intégrité, gère des groupes et redémarre un processus 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.
La règle interne consiste à toujours définir circuit_breaker_enabled=False. bulkman gère l'isolation, et le coupe-circuit relève de resilient-circuit.
complète resilient-circuit
Python
resilient-circuit
Bibliothèque Python
Disjoncteur (circuit breaking), nouvelles tentatives avec temporisation (backoff) et gestion des solutions de secours (failsafe ou fallback) autour des appels peu fiables. Associez-le à bulkman pour assurer l'isolation.
Jamais remplacé par : tenacity, pybreaker, ou des boucles de nouvelle tentative écrites à la main.
Python
scriptplan
Moteur + CLIproduit
Moteur compatible TaskJuggler (.tjp) pour la planification des ressources. Il gère les personnes et les machines au fil du temps, les dépendances et les calendriers, et produit des diagrammes de Gantt.
Jamais remplacé par : Des tableurs ou des calculs de dates ad hoc.
Outil de suivi des tickets par dépôt intégrant spécifications EARS, mémoire durable et enseignements. Toutes les demandes d'ingénierie suivent le cycle de vie obligatoire open → in-progress → closed.
Les demandes d'ingénierie se transforment toutes en une spécification EARS au sein d'un ticket et dans une copie sous 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 un besoin 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
Utilisez
N’utilisez jamais
Connexion / OAuth / « qui est-ce ? »
Identity
Écrire votre propre authentification
Rôles, permissions, « X peut-il faire Y ? »
Auth
Tables RBAC, Casbin, OPA
Quotas, limites de débit, budgets, niveaux, mesure
TokenGate
Compteurs Redis, 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 dépôt 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
Demandes sur Slack, tableaux d’approbation
Migrations de schéma PostgreSQL
migretti
alembic, flyway, yoyo
Jeux de données, blobs, fichiers d’enregistrement, 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
tenacity, 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 dépôt, quel que soit ce qu’il construit.
Workflow EARS + issuedb
Toutes les demandes d'ingénierie deviennent une spécification EARS et un ticket issuedb, et la spécification est copiée dans le répertoire SPECS/ du référentiel. Les tickets passent de l'état ouvert à en cours, puis à fermé.
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 des systèmes critiques
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 déclarez prêt que ce qui a réellement été éprouvé, 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, Steward, Tollgate, Haven, RODMENA LRS, RODMENA cmi5, Vellum, supervice, datashard, ScriptPlan, Stabilize, Trace, Provenance et Knowledge base. Elles font aussi tourner l’entreprise.