Combien de vos règles d’architecture cassent le build ?

· Publié le · 2 min de lecture

Quelle architecture permet un usage robuste et continu de l’IA malgré une mise à l’échelle ?

Celle qui apporte un maximum de règles vérifiables par une machine, de façon déterministe.

La verbosité n’est plus le problème

On reproche souvent aux architectures structurées (Clean Architecture, Hexagonale, DDD…) d’être verbeuses. Mais avec l’IA, cela devient de moins en moins un problème. Le coût d’écriture dégringole… pendant que celui de lire et vérifier explose.

Et là, l’architecture ultra standardisée devient un atout, malgré sa potentielle verbosité.

Une IA produit du code qui ressemble à du code juste… très souvent sans l’être. La défense pour passer à l’échelle n’est pas une relecture ligne par ligne (vous ne tiendrez pas le rythme, et personne n’est infaillible) mais un harnais qui valide si oui ou non le code est correct.

Une intention contre une contrainte

Exemple de règle : le code métier du domaine n’importe rien de l’infrastructure (si on fait de la Clean Architecture ou de l’Hexagonale, par exemple).

Cette règle dans un README ou un CLAUDE.md, c’est une intention. Mieux que rien… mais souvent non lue ou ignorée.

Placée dans une config, elle devient une contrainte :

// eslint.config.js, appliqué aux fichiers src/domain/**
"no-restricted-imports": ["error", {
  patterns: ["**/infrastructure/**", "pg", "express"]
}]

La règle ne peut plus être contournée.

Le réflexe pour démarrer un projet en 2026

C’était déjà vrai avant… mais ça l’est encore plus aujourd’hui.

Une fois choisie une architecture cohérente avec le projet (un CRUD n’a pas besoin d’une Clean Architecture avec du DDD…), elle doit être standardisée à outrance.

Pour chaque règle :

  • Le Graal : la rendre impossible à contourner, comme dans l’exemple ci-dessus.
  • Le fallback (certaines règles ne peuvent tout simplement pas être imposées par un harnais) : une régularité telle que le prompt tient en deux lignes, et que toute divergence saute aux yeux.

Demain, posez-vous la question : combien de vos règles d’architecture cassent le build ?

Les autres sont en réalité des intentions.

dependency-cruiser applique la même idée à l’ensemble du graphe d’imports.

Le même réflexe vaut pour la séparation des données entre clients d’un SaaS : un tenant omis doit rendre zéro donnée, pas une fuite.

PS : une règle qui passe ne dit pas que la règle est bonne. Réfléchir et faire les bons choix pour le contexte de chaque projet n’est pas en option.

Sources