Règles d'Analyse Personnalisées : Votre Architecture, Vos Standards

Les analyses d'architecture sont l'une des fonctionnalités les plus populaires d'Archyl depuis le lancement. Pointez l'analyseur vers votre architecture et il identifie les problèmes potentiels : points uniques de défaillance, dépendances circulaires, éléments orphelins, documentation manquante. Les équipes nous disent que c'est comme avoir un architecte senior qui révise continuellement leur conception système.

Mais nous entendions sans cesse le même retour : "Cet avertissement ne s'applique pas à nous."

Peut-être que vos microservices partagent intentionnellement une base de données pendant une migration progressive. Peut-être qu'un composant a beaucoup de dépendances entrantes parce que c'est une bibliothèque utilitaire partagée—pas un problème de couplage, juste une bonne réutilisation de code. Ou votre équipe a décidé que huit connexions à un service c'est bien, même si notre seuil par défaut le signale.

Les règles génériques ne peuvent pas prendre en compte votre contexte. Alors nous vous donnons le contrôle.

Sept Règles, Vos Seuils

Archyl vous permet maintenant de personnaliser les règles d'analyse qui examinent votre architecture. Nous avons identifié sept patterns qui comptent pour la santé architecturale, et vous pouvez maintenant ajuster chacun pour correspondre aux standards de votre équipe.

Le détecteur de Point Unique de Défaillance trouve les éléments dont trop d'autres composants dépendent. Par défaut, nous signalons tout ce qui a trois dépendances entrantes ou plus, mais si votre architecture centralise intentionnellement certaines préoccupations, vous pouvez augmenter ce seuil à cinq, dix, ou ce qui a du sens. Les infrastructures critiques comme les bases de données reçoivent toujours une attention supplémentaire—nous avons appris qu'une base de données devenant un SPOF vaut presque toujours la peine d'être connue.

L'analyse du fort couplage regarde dans les deux directions : les éléments qui dépendent de trop de choses (sortant) et les éléments dont trop de choses dépendent (entrant). Les valeurs par défaut—six sortants, quatre entrants—fonctionnent bien pour la plupart des bases de code, mais une équipe plateforme construisant des bibliothèques partagées pourrait vouloir des seuils plus élevés qu'une équipe produit construisant des fonctionnalités ciblées.

Les éléments sur-connectés attrapent un problème différent : les composants qui ont tellement de connexions totales qu'ils sont difficiles à comprendre. Huit connexions peuvent être bien pour votre API gateway mais préoccupantes pour un service de domaine. Ajustez le seuil pour correspondre à vos patterns d'architecture.

Les dépendances circulaires sont presque toujours problématiques—elles rendent les tests plus difficiles, créent des maux de tête d'initialisation, et signalent des frontières peu claires. Cette règle est binaire : activée ou désactivée. Si vous utilisez intentionnellement des références circulaires pour une raison quelconque, désactivez-la. La plupart des équipes la laissent activée.

Les éléments orphelins trouvent les composants d'architecture sans aucune connexion. Parfois c'est un oubli de documentation ; parfois c'est un service obsolète que vous avez oublié de supprimer. La règle les signale pour que vous puissiez décider.

Les patterns de sécurité détectent des choix architecturaux préoccupants comme les systèmes externes avec accès direct à la base de données. Ce sont des résultats de sévérité critique que la plupart des équipes veulent connaître immédiatement.

La documentation manquante aide à maintenir la couverture, mais sur une base de code avec des milliers de composants, signaler chaque élément non documenté crée du bruit. Vous pouvez définir un seuil—ne vérifier la documentation que si vous avez moins de 20 composants, ou 50, ou 500. Adaptez la règle à la taille de votre architecture.

Cohérence à l'Échelle de l'Organisation

Ces paramètres s'appliquent à toute votre organisation, pas par projet. Nous avons fait ce choix délibérément.

Les standards d'architecture devraient être cohérents. Si votre équipe plateforme décide que quatre dépendances entrantes est le seuil pour le fort couplage, ce standard devrait s'appliquer partout. Les nouveaux projets héritent automatiquement des règles de l'organisation. Les équipes ne peuvent pas accidentellement (ou intentionnellement) définir des standards plus laxistes qui créent de la dette technique.

Les paramètres vivent dans la configuration de votre organisation. Toute personne avec des permissions d'édition peut les ajuster, et les changements prennent effet immédiatement—Archyl ré-analyse votre architecture avec les nouvelles règles et met à jour le tableau de bord des analyses.

L'Onglet Règles

Nous avons ajouté une section Règles dédiée à la page Analyses. Chaque règle apparaît comme une carte avec un interrupteur à bascule et, le cas échéant, des entrées de seuil.

Pour les règles basées sur des seuils, vous verrez la valeur actuelle, la plage autorisée et la valeur par défaut. Faites glisser le seuil vers le haut pour être plus permissif, vers le bas pour être plus strict. L'interface valide vos entrées—vous ne pouvez pas définir de valeurs impossibles ou créer des configurations qui n'ont pas de sens.

Pour les règles binaires comme la détection des dépendances circulaires, c'est un simple interrupteur on/off. La carte explique ce que la règle détecte pour que vous puissiez faire un choix éclairé sur son importance pour votre base de code.

Quand vous modifiez les paramètres, un bouton de sauvegarde apparaît en bas de la page. Cliquez dessus, et Archyl relance immédiatement l'analyse avec votre nouvelle configuration. En quelques secondes, vous verrez les analyses mises à jour reflétant vos règles personnalisées.

Il y a aussi un bouton de réinitialisation qui restaure toutes les valeurs par défaut si vous voulez repartir de zéro.

Ce qui Change en Pratique

Avec des règles personnalisables, le tableau de bord des analyses devient vraiment utile plutôt qu'une source de fatigue d'alertes.

Les équipes nous disent qu'elles jetaient un œil aux analyses, voyaient un mur d'avertissements qu'elles avaient déjà décidé d'ignorer, et fermaient l'onglet. Maintenant elles configurent les règles pour correspondre à leurs standards réels, et quand une analyse apparaît, c'est quelque chose qui vaut la peine d'être investigué.

Les niveaux de sévérité aident à prioriser. Les points uniques de défaillance dans l'infrastructure critique s'affichent comme Critiques. Les dépendances circulaires sont Hautes. Les éléments sur-connectés sont Moyens. La documentation manquante est Basse. Vous pouvez vous concentrer d'abord sur les éléments rouges, sachant que vos seuils sont calibrés pour votre contexte.

Et parce que les analyses se mettent à jour automatiquement quand les règles changent, vous pouvez expérimenter. Curieux de savoir à quoi ressemble votre architecture avec des règles de couplage plus strictes ? Ajustez le seuil, enregistrez, et voyez. Trop de bruit ? Réduisez. La boucle de feedback est immédiate.

Pour Commencer

Les règles d'analyse personnalisées sont disponibles sur tous les plans. Naviguez vers Analyses, cliquez sur l'onglet Règles, et commencez à ajuster.

Nous recommandons de commencer avec les valeurs par défaut et d'ajuster en fonction de ce que vous voyez. Si une règle particulière génère des avertissements que vous ignorez systématiquement, c'est un signal soit pour corriger l'architecture sous-jacente, soit pour ajuster le seuil. Les deux sont des choix valides—l'objectif est de rendre les analyses actionnables, pas de chasser des métriques arbitraires.

Votre architecture a ses propres caractéristiques, ses propres compromis intentionnels, sa propre définition de "suffisamment bon". Maintenant votre gouvernance peut refléter cela.

Vous voulez voir comment fonctionnent les analyses propulsées par l'IA ? Lisez notre article sur la Découverte Propulsée par l'IA pour comprendre comment Archyl analyse votre base de code et génère des recommandations architecturales.