Packs de règles de conformité

Rules grouped by type, with packs and a browsable catalog

Les packs de règles sont des collections de règles de conformité sélectionnées avec soin, qui encodent les bonnes pratiques des patterns d'architecture courants. Au lieu d'écrire vos règles de zéro, installez un pack et obtenez en quelques secondes un ensemble de règles affirmé et éprouvé.

Pourquoi des packs de règles ?

La plupart des équipes suivent des patterns bien connus : microservices, clean architecture, systèmes event-driven. Chaque pattern s'accompagne de contraintes qui devraient être appliquées automatiquement :

  • Les microservices ne devraient pas partager de bases de données
  • Les couches domaine ne devraient pas importer de code d'infrastructure
  • Les événements devraient respecter un contrat de schéma

Les packs de règles transforment ces principes en garde-fous exécutables.

Packs disponibles

Pack Règles Axe
Microservices 10 Frontières entre services, déploiement indépendant, communication encadrée
Clean Architecture 9 Frontières entre couches, isolation du domaine, respect du pattern ports/adaptateurs
Event-Driven 8 Conformité des canaux, exigences de schéma, dead letter queues
API-First 8 Contrats obligatoires, versioning, documentation de l'authentification
Security Baseline 8 Passage obligatoire par la passerelle, gestion des secrets, contrôle des accès externes

Installer un pack

Via la skill archyl-developer

Demandez à votre agent de code IA :

Install the microservices conformance rules pack

L'agent appelle le serveur MCP d'Archyl et crée toutes les règles en une seule opération.

Via le SDK

import { ArchylClient } from "@archyl/sdk";

const client = new ArchylClient({
  apiKey: process.env.ARCHYL_API_KEY,
  organizationId: "your-org-id",
});

// Install a pack by name
await client.governance.installPack("microservices");

Via l'interface

Rendez-vous dans Hub Agent > Packs et cliquez sur Installer sur le pack de votre choix.

Contenu de chaque pack

Microservices (10 règles)

  • Pas de bases de données partagées — Chaque service doit posséder ses données. Les requêtes entre services passent uniquement par des APIs.
  • Déploiement indépendant — Aucune dépendance de compilation entre services. Les bibliothèques partagées doivent être versionnées.
  • Communication encadrée — Les services communiquent via des contrats d'API ou des canaux d'événements définis, et non par accès direct à la base de données ou par partage de fichiers.
  • Isolation des services — Aucun import entre services. Chaque service a son propre arbre de dépendances.

Clean Architecture (9 règles)

  • Pureté de la couche domaine — Le code du domaine n'a aucun import externe. Ni framework, ni ORM, ni HTTP.
  • Sens des dépendances — Les dépendances pointent vers l'intérieur. Les handlers dépendent des services, les services dépendent du domaine, jamais l'inverse.
  • Respect du pattern ports/adaptateurs — Les préoccupations d'infrastructure (base de données, HTTP, messagerie) vivent dans des packages d'adaptateurs, pas dans les couches domaine ou service.
  • Frontières par interfaces — Les services consomment des interfaces (ports), pas des implémentations concrètes.

Event-Driven (8 règles)

  • Conformité des canaux — Les producteurs et consommateurs d'événements doivent utiliser les canaux d'événements déclarés. Pas de création de topics à la volée.
  • Exigences de schéma — Chaque événement doit avoir un schéma défini. Pas de payloads non typés.
  • Dead letter queue — Les consommateurs doivent configurer une DLQ pour traiter les messages en échec.
  • Conventions de nommage des topics — Les topics suivent un schéma de nommage cohérent (par exemple, domain.entity.event).

API-First (8 règles)

  • Contrat obligatoire — Chaque endpoint public doit disposer d'un contrat OpenAPI, gRPC ou AsyncAPI enregistré.
  • Versioning — Les endpoints d'API doivent inclure un préfixe de version (/v1/, /v2/).
  • Documentation de l'authentification — Les schémas de sécurité doivent être documentés dans le contrat.
  • Aucun endpoint non documenté — Les fichiers de handlers sans documentation de contrat correspondante déclenchent une violation.

Security Baseline (8 règles)

  • Passage par la passerelle — Le trafic externe doit passer par une passerelle d'API ou un load balancer. Aucun service n'est exposé directement.
  • Gestion des secrets — Aucun secret, clé API ou mot de passe en dur dans le code source. Utilisez des variables d'environnement ou un gestionnaire de secrets.
  • Contrôle des accès externes — Les services qui acceptent des requêtes externes doivent imposer une authentification et une limitation de débit.
  • TLS obligatoire — Toute communication entre services doit utiliser TLS. Pas de HTTP en clair entre services.

Personnaliser les règles

Une fois un pack installé, chaque règle est entièrement modifiable :

  • Changer la sévérité — Abaissez une règle de critical à medium si elle ne correspond pas à votre tolérance au risque
  • Désactiver certaines règles — Désactivez individuellement les règles dont vous n'avez pas besoin, sans retirer tout le pack
  • Modifier la configuration — Ajustez les globs de fichiers, les patterns, les imports autorisés ou les définitions de couches à la structure de votre projet

Rendez-vous dans Hub Agent et cliquez sur l'icône de modification d'une règle pour la modifier.

Combiner les packs

Les packs se cumulent. Installez plusieurs packs pour couvrir différentes préoccupations d'architecture :

Combinaison Cas d'usage
Microservices + API-First + Security Baseline Plateforme de microservices pilotée par les APIs, avec des garde-fous de sécurité
Clean Architecture + Security Baseline Monolithe aux frontières de couches strictes, avec une bonne hygiène de sécurité
Event-Driven + Microservices Système de microservices en event sourcing
API-First + Clean Architecture Monolithe ou monolithe modulaire piloté par les contrats

Si deux packs contiennent des règles qui se recoupent, Archyl les déduplique : aucun conflit.

Contribuer

Les packs de règles sont open source. Vous pouvez proposer de nouveaux packs, ajouter des règles aux packs existants ou signaler des problèmes :

Étapes suivantes