Comment les rules et policies centralisées d'Elastra appliquent la gouvernance sur tous les agents IA

Quand les agents de code IA opèrent sans gouvernance centralisée, le comportement devient une fonction de la session individuelle : ce que l'ingénieur a tapé dans le system prompt aujourd'hui, ce que l'IDE a capté d'un fichier de configuration local, ce que le modèle a décidé en se basant sur son comportement par défaut. Le résultat est une dérive comportementale — des agents qui produisent un output inconsistant entre ingénieurs, IDEs et sessions, sans mécanisme pour détecter, mesurer ou corriger.

Les conséquences opérationnelles sont bien connues des équipes qui les ont vécues. Des inconsistances de style de code qui survivent aux revues parce que les relecteurs n'ont pas le contexte de ce qui a été dit à l'agent. Des décisions qui contredisent les guidelines d'architecture parce que l'agent ne les a jamais reçues. Un prompting correctif répété qui consomme du temps d'ingénierie et introduit une nouvelle variabilité à chaque itération.

La cause racine est architecturale : si les rules vivent dans le client — dans un fichier local, un paramètre d'IDE ou un system prompt maintenu manuellement — alors la gouvernance est par ingénieur, par session et par machine. Il n'y a pas de single source of truth, pas de précédence imposée, pas d'audit trail et pas de mécanisme pour que l'organisation exerce un contrôle.

La réponse d'Elastra est de déplacer la gouvernance vers le backend : les rules sont stockées dans la base de données, résolues par le serveur et transmises aux agents via des canaux imposés — quel que soit l'IDE, le modèle ou l'ingénieur impliqué dans la session.

Elastra stocke les rules sur six scopes distincts : organisation, projet, namespace, dépôt, équipe et utilisateur. Chaque scope sert un objectif de gouvernance différent. Les rules d'organisation définissent la baseline qui s'applique partout. Les rules de projet spécifient les contraintes et conventions pour un projet donné. Les rules de namespace restreignent le comportement à un contexte de travail spécifique au sein d'un projet. Les rules de dépôt s'appliquent à une codebase spécifique. Les rules d'équipe reflètent les conventions partagées pour une équipe d'ingénierie donnée. Les rules d'utilisateur permettent une préférence individuelle dans les limites définies par les scopes supérieurs.

Quand un agent demande son effective ruleset — via la commande CLI elastra rules materialize ou l'outil MCP elastra_rules — le backend résout toutes les couches applicables et les fusionne en un unique EffectiveRuleset. La résolution suit une précédence déterministe : les rules d'utilisateur ont la priorité maximale, suivies des rules de dépôt, rules de namespace, rules d'équipe, rules de projet et rules d'organisation comme baseline. L'output fusionné est un unique document Markdown que l'agent reçoit comme instructions d'opération.

Cette architecture possède une propriété critique : l'organisation a toujours voix au chapitre. Même si un utilisateur a des rules personnelles ou qu'un projet a des overrides spécifiques, la couche organisation ne peut pas être retirée du pipeline de résolution. La baseline s'applique toujours. Une policy définie au niveau de l'organisation est une contrainte, pas une suggestion.

Les rules sont persistées dans PostgreSQL via la Console API d'Elastra. Toutes les opérations CRUD — create, read, update et delete — nécessitent la capability ManageRules, qui est une named role capability imposée au niveau du serveur avant que toute logique de handler ne s'exécute. Un ingénieur sans cette capability ne peut pas lire ni écrire de rules pour l'organisation, quelle que soit la façon dont il interagit avec l'API.

Chaque opération sur les rules est enregistrée comme un événement de console auditable avec un payload structuré : l'acteur (session et utilisateur), l'organisation, la cible de scope (UUID de projet, UUID de namespace, UUID de dépôt) et l'opération effectuée. Ces événements sont stockés et interrogeables, fournissant un enregistrement traçable de qui a modifié quelle rule, quand et pour quel scope. C'est l'audit trail qui rend la gouvernance centralisée opérationnelle plutôt que théorique.

Quand une rule est créée ou mise à jour, le backend synchronise automatiquement son contenu dans la knowledge base sous forme de document structuré. Cela signifie que les rules ne sont pas seulement applicables via la matérialisation et l'outil MCP — elles sont aussi récupérables comme contexte de première classe quand un agent effectue une recherche sémantique. Un agent cherchant des conventions de code trouvera les rules de l'organisation dans les résultats. Cette synchronisation se produit de manière synchrone à l'écriture et est enregistrée comme avertissement si elle échoue, garantissant que le contenu des rules est toujours découvrable.

Le premier mécanisme d'application est la matérialisation. Quand un ingénieur exécute elastra rules materialize dans un dépôt, le CLI récupère l'effective ruleset depuis l'endpoint backend GET /v1/rules/effective — en passant l'UUID de projet, l'UUID de namespace et l'UUID de dépôt comme paramètres — et écrit le Markdown fusionné dans un ensemble de fichiers spécifiques à chaque agent.

Elastra maintient une liste fixe de materialization targets, un par agent supporté. Au moment de la rédaction, ceux-ci incluent : Claude Code (.claude/rules/elastra.md), Cline (.clinerules/elastra.md), Cursor (.cursor/rules/elastra.mdc), Windsurf (.windsurf/rules/elastra.md), Gemini CLI (GEMINI.md), Kiro (.kiro/steering/elastra.md), Augment (CLAUDE.md), Continue (.continue/rules/elastra.md), goose (.goosehints), Roo Code (.roo/rules/elastra.md), Amp (.agents/checks/elastra.md), GitHub Copilot (.github/copilot-instructions.md) et Kimi (.kimi/rules/elastra.md).

Chaque fichier reçoit le même contenu fusionné, encapsulé dans des marqueurs de commentaire HTML structurés (<!-- elastra:rules:v1 start --> et <!-- elastra:rules:v1 end -->) qui permettent au CLI d'identifier, mettre à jour ou supprimer le bloc avec précision sans toucher au reste du fichier. Si les rules sont supprimées de la base de données et que la matérialisation est relancée, les blocs sont supprimés automatiquement de tous les fichiers cibles — empêchant des rules obsolètes de persister dans le dépôt.

Ce mécanisme garantit qu'un agent opérant à partir du contexte local — lisant son fichier de rules spécifique à l'IDE au démarrage — a déjà les rules effectives actuelles de l'organisation intégrées. Aucun appel réseau n'est nécessaire pendant la session pour que cette couche fonctionne. Les rules ont été récupérées depuis le backend quand l'ingénieur a configuré son workspace.

La matérialisation gère le démarrage : les rules sont intégrées dans les fichiers locaux avant que la session ne commence. Mais les rules évoluent. Les policies de l'organisation changent, les contraintes de projet sont mises à jour, de nouvelles conventions de namespace sont introduites. Un fichier matérialisé écrit la semaine dernière peut ne pas refléter l'effective ruleset actuel.

Le deuxième mécanisme d'application traite ce point : l'outil MCP elastra_rules. Quand un agent appelle cet outil pendant une session, le serveur MCP d'Elastra récupère l'effective ruleset actuel directement depuis le backend — en accédant à GET /v1/rules/effective avec le scope de projet, namespace et dépôt actuel — et retourne le Markdown fusionné comme réponse d'outil. L'agent reçoit les rules actuelles et live, pas une copie locale mise en cache.

Cela crée un modèle de gouvernance pull-on-demand. L'agent peut demander ses rules à n'importe quel moment pendant une session — au démarrage d'une tâche, avant une décision sensible, ou après avoir détecté que le scope de la tâche a changé. Les rules retournées sont toujours la version actuelle du backend, imposées par RBAC et auditées au niveau de l'API.

Combiné avec la matérialisation, cela donne aux organisations deux couches d'application des rules : une couche de démarrage qui intègre les rules avant le début de la session, et une couche live qui maintient l'agent synchronisé avec la policy organisationnelle actuelle pendant la session. Aucune couche n'est optionnelle — les deux font partie du contrat de gouvernance.

Au-delà des rules elles-mêmes, Elastra impose un contrat comportemental au début de chaque session d'agent via le fichier ELASTRA.md. Ce fichier est écrit dans chaque workspace par le CLI lors de la configuration et définit les règles d'opération que l'agent doit suivre avant que toute tâche ne commence.

La contrainte la plus critique dans ELASTRA.md est la règle obligatoire du contexte en premier : la toute première action de l'agent sur n'importe quelle tâche doit être d'appeler elastra_context. Il ne peut pas faire de grep sur des fichiers, de glob sur des répertoires ou lire du code local comme première étape. Il doit interroger la knowledge base d'Elastra pour l'architecture, les flux et le contexte pertinent avant de toucher aux fichiers locaux. Ce n'est pas une préférence — c'est une étape obligatoire, et le fichier bootstrap le rend explicite avec un marqueur d'avertissement.

Le bloc bootstrap spécifie également la politique de write-back obligatoire : si la session produit des conclusions durables, des modifications de code ou des conclusions, l'agent doit appeler elastra_sync ou elastra_memory_write avant de répondre. Cela crée une boucle de gouvernance qui va au-delà de la lecture des rules — elle gouverne la façon dont la connaissance produite pendant la session est préservée et rendue disponible pour les sessions futures.

Ce modèle contract-first garantit que la gouvernance n'est pas simplement injectée comme des instructions que l'agent peut ou non suivre. Les instructions sont obligatoires, auditables et structurellement placées avant toute logique de tâche. Un agent qui les viole doit explicitement reconnaître et expliquer la violation à l'utilisateur.

Les rules gouvernent ce que l'agent doit et ne doit pas faire. Le système de personas gouverne ce que l'agent est. Une persona est un AgentProfile stocké dans la base de données avec un slug, un nom, un system prompt, une liste d'outils autorisés et des flags opérationnels comme enabled et isDefault. Les personas ont un scope d'organisation, sont contrôlées par RBAC et résolues de manière centralisée.

Quand une session d'agent commence, le system prompt de la persona active est injecté aux côtés des rules dans les fichiers matérialisés, encapsulé dans ses propres marqueurs de bloc (<!-- elastra:persona:v1 start --> et <!-- elastra:persona:v1 end -->). Cela signifie que l'identité de l'agent — son rôle, son format d'output, son mode opératoire — est également définie par l'organisation, et non laissée à la configuration individuelle.

La combinaison des rules et de la persona crée une spécification comportementale complète. Les rules définissent les contraintes d'opération. La persona définit le contexte d'opération, le format d'output et le rôle. Ensemble, elles décrivent exactement quel type d'agent l'organisation exécute dans cette session, et toutes deux sont traçables jusqu'au backend, versionnées via des opérations de mise à jour et auditables via le journal d'événements de la console.

L'architecture décrite ci-dessus a une implication pratique : la surface de contrôle de l'organisation sur le comportement des agents IA est réelle et opérationnelle, pas aspirationnelle. Les rules sont dans une base de données. Elles sont versionnées. Elles sont auditées. Elles sont appliquées via deux canaux complémentaires — matérialisation au démarrage et récupération MCP live. Elles s'appliquent à chaque agent, chaque IDE et chaque session sans nécessiter de configuration individuelle par chaque ingénieur.

Cela change l'économie de l'ingénierie assistée par IA. Sans gouvernance centralisée, l'agent de chaque membre de l'équipe se comporte différemment, la dérive s'accumule invisiblement et l'effort correctif évolue avec la taille de l'équipe. Avec une gouvernance centralisée, la cohérence comportementale devient une propriété de l'infrastructure, pas une fonction de la discipline individuelle. Le coût marginal d'ajout d'un nouvel ingénieur à une équipe assistée par IA chute car la couche de gouvernance absorbe la surcharge de configuration.

Cela change également le profil de risque. Les rules et personas sont auditées. Les changements sont traçables. Quand un incident de production impliquant le comportement de l'agent survient, la question 'sous quelles rules l'agent opérait-il à ce moment-là ?' a une réponse précise, adossée à la base de données. Cette traçabilité n'est pas un avantage de débogage — c'est une exigence de gouvernance pour les équipes qui opèrent de l'IA à l'échelle de la production.

L'organisation qui déploie Elastra ne se contente pas d'utiliser un outil d'IA. Elle opère un système gouverné : un où les limites comportementales sont définies de manière centralisée, appliquées automatiquement, mises à jour sans perturber les workflows individuels, et auditées sans nécessiter de processus de conformité manuels. C'est ce qui fait de l'ingénierie assistée par IA une capacité opérationnelle répétable plutôt qu'une expérience de productivité.