Les agents IA codent vite. Sans garde-fous, ils dérivent tout aussi vite. Aujourd'hui, nous lançons Agent Hub — une nouvelle section dans Archyl qui permet de définir des règles de conformité, de parcourir un catalogue de 96 garde-fous prêts à l'emploi, et de fournir aux agents IA le contexte architectural dont ils ont besoin avant d'écrire la moindre ligne de code.

Agent Hub : Des garde-fous architecturaux pour les agents IA autonomes

Quelque chose de fondamental a changé dans la manière dont le logiciel est écrit.

Il y a six mois, un développeur passait deux jours à construire un nouveau service. Il consultait les ADRs, demandait à un collègue quelle base de données utiliser, respectait les conventions de nommage qu'il avait intériorisées au fil des mois, et poussait du code cohérent avec l'architecture parce qu'il comprenait l'architecture.

Aujourd'hui, un agent IA fait le même travail en vingt minutes. Le code compile. Les tests passent. Mais l'agent a utilisé MongoDB alors que l'équipe s'était standardisée sur PostgreSQL. Il a disséminé des appels à fmt.Println au lieu d'utiliser du logging structuré. Il a placé une requête base de données directement dans un handler HTTP, contournant la couche service qui avait demandé trois sprints à mettre en place.

L'agent est plus rapide. Mais il ne sait pas ce qu'il ne sait pas.

Le vrai coût de la vitesse sans gouvernance

Nous entrons dans une ère où la vélocité de production de code est essentiellement illimitée. Claude Code, Cursor, Copilot Workspace, Devin — ces outils peuvent produire des services entiers en quelques minutes. Les équipes qui livraient chaque semaine livrent désormais chaque jour. Le goulot d'étranglement est passé de « à quelle vitesse peut-on écrire du code » à « à quelle vitesse l'entropie architecturale peut-elle détruire notre système ».

Imaginez ce qui se passe quand cinq agents IA travaillent simultanément sur la même base de code :

L'agent A ajoute un nouvel endpoint REST avec des patterns Express. L'agent B en ajoute un autre avec des patterns Fiber. Vous avez maintenant deux frameworks API dans le même service.
L'agent C crée un module de paiement qui interroge directement la base de données. L'agent D crée un module de commande qui passe par la couche repository. Vous avez maintenant deux patterns d'accès aux données.
L'agent E adopte une bibliothèque dépréciée par votre tech radar depuis six mois. Elle fonctionne parfaitement. C'est aussi une bombe à retardement.

Aucun de ces cas n'est un bug. Ils passent tous la CI. Ils fonctionnent tous en isolation. Mais ensemble, ils transforment silencieusement votre base de code en un patchwork de patterns contradictoires qu'il vous faudra des mois pour démêler.

C'est le problème qu'Agent Hub a été conçu pour résoudre.

Les garde-fous architecturaux : le linter de votre architecture

Les règles de conformité sont des vérifications déterministes — aucune IA impliquée — qui valident les changements de code par rapport à vos décisions architecturales. Pensez-y comme ESLint pour l'architecture : elles ne s'intéressent pas à la syntaxe, mais à la structure.

Sept types de règles couvrent les besoins de gouvernance que nous avons observés dans des centaines d'équipes :

Required Pattern — Le plus simple et le plus puissant. Définissez des patterns qui doivent exister ou ne doivent pas exister dans votre code. Interdisez fmt.Println en Go, console.log en TypeScript, eval() partout. Exigez set -euo pipefail dans chaque script shell. Bannissez SELECT * des requêtes SQL.

Naming Convention — Imposez des règles de nommage pour les fichiers, les types et les fonctions. Les fichiers Go doivent être en snake_case. Les composants React doivent être en PascalCase. Les modules Python doivent suivre la PEP 8. Quand un agent génère du code, il suit les conventions de votre équipe, pas ses propres valeurs par défaut.

Technology Constraint — Verrouillez la pile technologique par container. Le backend doit être exclusivement en Go. Le frontend doit être en TypeScript, pas en JavaScript. Pas de lodash (utilisez le JS natif). Pas de moment.js (utilisez date-fns). L'agent ne peut pas introduire accidentellement une dépendance que votre équipe a déjà écartée.

Layer Boundary — C'est là que ça devient puissant. Définissez vos couches architecturales et quelles couches peuvent importer depuis quelles autres. Le domaine ne peut pas importer depuis l'adapter. Le service uniquement depuis le domaine. Les handlers doivent passer par les services, jamais accéder directement aux repositories. Clean Architecture, architecture hexagonale, DDD — appliqués automatiquement, à chaque changement, quel que soit celui (ou ce) qui a écrit le code.

Contract Compliance — Validez que les endpoints du code correspondent à vos contrats d'API. Si vous avez une spec OpenAPI dans Archyl, le moteur de conformité vérifie que vos handlers l'implémentent réellement. Pas d'endpoints fantômes, pas de routes manquantes.

Dependency Rule — Chaque import dans le code doit avoir une relation correspondante dans le modèle C4. Si le Service A commence soudainement à appeler le Service B, mais qu'il n'y a pas de relation « uses » dans l'architecture, la règle le détecte. La dérive architecturale devient immédiatement visible.

Event Channel Compliance — Si votre système utilise Kafka, NATS ou tout autre message broker, cette règle valide que les producteurs et consommateurs dans le code correspondent aux canaux d'événements déclarés dans votre architecture. Pas de topics sauvages, pas de consommateurs non déclarés.

96 règles, zéro configuration

Écrire des expressions régulières est fastidieux. Nous avons donc construit un catalogue de 96 règles prêtes à l'emploi couvrant 21 technologies, utilisables en un clic.

Le catalogue est organisé par catégorie :

Security (11 règles) — Pas de mots de passe, clés API ou secrets codés en dur. Pas de eval(). Pas de concaténation de chaînes SQL. Pas de vérification TLS désactivée. Pas d'origines CORS wildcard. Pas de MD5 ou SHA1 pour le hachage. Ce ne sont pas des suggestions — dans un monde agentique, ce sont des impératifs. Un agent IA codera avec plaisir un mot de passe de base de données en dur dans un fichier de configuration si personne ne lui dit de ne pas le faire.

Infrastructure (22 règles) — Pas de tag :latest dans les Dockerfiles. Exigez des limites de ressources dans les manifestes Kubernetes. Pas de containers privilégiés. Pas de hostNetwork. Exigez des health checks. Épinglez les versions des GitHub Actions aux SHAs de commits. Pas de credentials codés en dur dans Terraform. Pas de politiques IAM wildcard. Quand les agents génèrent de l'infrastructure-as-code, ces règles garantissent que le résultat est prêt pour la production, pas pour une démo.

Code Quality (18 règles pour 10 langages) — Go : pas de panic(), pas de init(), pas d'état mutable global. TypeScript : pas de type any, pas de déclarations var. Python : pas de except: nu, pas d'arguments mutables par défaut, pas de import *. Java : pas de System.out.println, pas de blocs catch vides. Rust : pas de unwrap(), pas de unsafe. Chaque règle existe parce que les agents IA commettent systématiquement ces erreurs quand ils manquent de contexte.

Architecture (5 règles) — Clean Architecture, architecture hexagonale, DDD en couches, séparation MVC, application handler-service-repository. Ce sont les garde-fous structurels qui empêchent le type de dérive le plus coûteux — celui où votre architecture mute lentement vers quelque chose que personne n'a conçu.

Testing (3 règles) — Pas de tests ignorés commités. Pas de .only() oublié dans les suites de tests. Pas de TODO/FIXME dans le code de production. De petites règles qui empêchent les commits bâclés que les agents IA génèrent quand ils optimisent pour « ça marche » plutôt que « c'est prêt ».

Contexte agent : un seul appel, toute la connaissance

Les règles disent aux agents ce qu'ils ne peuvent pas faire. Le contexte leur dit ce qu'ils devraient faire.

L'outil MCP get_agent_context fournit à tout agent connecté un briefing architectural complet en un seul appel :

C4 Model — Chaque système, container, composant et relation du projet
Architecture Decision Records — Les ADRs actifs avec leur justification et leurs décisions
Technology Stack — Les technologies utilisées à travers l'organisation
Active Guardrails — Chaque règle de conformité, pour que l'agent connaisse les limites avant d'écrire du code
API Contracts — Les specs OpenAPI, gRPC, GraphQL qui définissent la surface d'API
Event Channels — Les topics Kafka, les sujets NATS, les schémas de messages

L'outil génère également une version markdown — un fichier CLAUDE.md que vous pouvez commiter dans votre dépôt. Tout agent qui le lit démarre avec une connaissance architecturale parfaite, sans avoir besoin de se connecter au serveur MCP d'Archyl.

C'est la différence entre un agent qui devine et un agent qui sait. Entre du code qui marche et du code qui a sa place.

Pourquoi c'est important maintenant

Le paysage de la programmation assistée par IA évolue vite. Dans six mois, la plupart du développement professionnel impliquera une forme d'agent IA. Dans un an, les workflows multi-agents seront courants — différents agents travaillant simultanément sur différentes parties du même système.

Sans gouvernance, cela mène au chaos. Pas le genre spectaculaire — le genre lent et insidieux où chaque commit est individuellement raisonnable mais l'effet cumulé est la dégradation architecturale. Le genre où vous regardez votre base de code six mois plus tard et ne pouvez pas expliquer pourquoi il y a trois bibliothèques de logging différentes, deux patterns d'ORM et un service qui dépend de tout.

Les garde-fous architecturaux changent fondamentalement cette dynamique :

Pour les équipes adoptant les agents IA : Vos décisions architecturales ne sont plus du savoir tribal qui se perd quand un agent écrit du code. Elles sont encodées sous forme de règles appliquées automatiquement. L'agent bénéficie de la même gouvernance qu'un développeur senior fournirait lors d'une code review — mais instantanément, à chaque changement, sans fatigue de relecture.

Pour les équipes plateforme : Vous pouvez standardiser des patterns à travers des dizaines de services et des centaines de changements générés par l'IA sans les revoir manuellement un par un. Définissez les règles une fois, appliquez-les partout. Quand une équipe crée un nouveau service avec un agent IA, il suit automatiquement les conventions de votre plateforme.

Pour les industries réglementées : Les exigences de conformité peuvent être encodées sous forme de règles. « Tous les services doivent avoir des health checks. » « Pas de données personnelles dans les logs. » « Chiffrement au repos obligatoire. » Ces exigences deviennent vérifiables, pas seulement documentées. Les pistes d'audit montrent que chaque changement généré par l'IA a été validé par rapport aux règles avant d'être mergé.

Pour les mainteneurs open source : Les contributeurs (humains ou IA) qui soumettent des PRs reçoivent un retour instantané sur la conformité architecturale. Plus besoin de relire des PRs qui violent des conventions que le contributeur ne connaissait pas. Les règles documentent les attentes de votre architecture sous forme de contraintes exécutables.

Les équipes qui prospéreront dans un monde agentique ne sont pas celles qui ont les meilleurs agents IA. Ce sont celles qui ont les frontières architecturales les plus claires. Les agents sont interchangeables. L'architecture ne l'est pas.

Pour commencer

Agent Hub est disponible dès maintenant pour tous les utilisateurs d'Archyl. Cliquez sur l'icône Agent dans la barre latérale. Parcourez le catalogue, ajoutez quelques garde-fous, et laissez vos agents IA travailler dans les limites que vous avez définies.

Vos décisions d'architecture ne devraient pas être optionnelles pour l'IA. Désormais, elles ne le sont plus.

Agent Hub : Des garde-fous architecturaux pour les agents IA autonomes - Archyl Blog