Aller au contenu principal

Comprendre le métamodèle piloté par les données

La plupart des outils d'architecture d'entreprise codent en dur leur modèle objet dans le code source de l'application. Canopy adopte une approche différente : chaque concept structurel – types de fiches, champs, sous-types, relations, rôles des parties prenantes et champs calculés – est stocké comme des données dans la base de données, pas comme du code. Cette page explique pourquoi cette décision a été prise et ce qu'elle signifie en pratique.

Ce qu'est le métamodèle​

Le métamodèle est le schéma de votre modèle d'architecture d'entreprise. Il définit :

  • Les types de fiches – les types d'entités que vous suivez (Application, BusinessCapability, Initiative, etc.)
  • Les champs – les propriétés que ces entités peuvent avoir (statut de cycle de vie, coût, propriétaire, pile technologique, etc.)
  • Les sous-types – des variantes fines d'un type qui partagent le même ensemble de champs (par ex. Application → Microservice, SaaS, AI Agent)
  • Les types de relations – les liens autorisés entre les types (Application « s'exécute sur » ITComponent, Initiative « réalise » BusinessCapability, etc.)
  • Les rôles des parties prenantes – les rôles que les utilisateurs peuvent tenir sur une fiche précise (Technical Owner, Business Owner, Data Steward, etc.)
  • Les champs calculés – des formules qui déduisent des valeurs de champs à partir d'autres données au moment de l'enregistrement

Tous ces éléments sont des lignes dans card_types, relation_types et des colonnes JSONB associées. Aucun d'eux ne nécessite de modification du code ou de redémarrage de l'application pour être modifié.

Pourquoi des données et non du code ?​

Personnalisation sans fork​

Les différentes organisations ont des métamodèles d'architecture d'entreprise très variés. Certaines équipes suivent « Vendor », « License » et « SLA ». D'autres suivent « Data Domain », « ESG Capability » et « Value Stream ». Si le métamodèle était du code, chaque personnalisation nécessiterait soit un fork du produit, soit un système de plugins – les deux sont coûteux à maintenir.

Avec un métamodèle piloté par les données, un administrateur peut ajouter un nouveau champ, renommer un type de fiche ou définir un type de relation personnalisé en quelques minutes via l'interface ou l'API. Le frontend s'adapte automatiquement : la grille d'inventaire gagne une nouvelle colonne, la page de détail de la fiche affiche la nouvelle section et les rapports peuvent filtrer sur le nouveau champ. Aucun déploiement requis.

Évolution du schéma sans migrations par client​

Lorsque Canopy livre un nouveau type de fiche ou un nouveau champ intégré, il le fait via seed.py – une routine de démarrage qui vérifie si la ligne intégrée existe et ne la crée que si elle est absente. Les personnalisations existantes ne sont jamais modifiées. Cela signifie :

  • La mise à niveau de Canopy n'écrase pas vos champs personnalisés
  • Les types intégrés restent modifiables (vous pouvez changer l'icône, la couleur ou l'étiquette de « Application » sans créer de fork)
  • Si une valeur par défaut intégrée s'écarte de sa valeur d'origine, une migration Alembic gardée ne corrige que les lignes non modifiées

Multilocation dans une seule base de code​

Comme le métamodèle est constitué de données, un seul déploiement de Canopy peut servir des équipes avec des modèles objet complètement différents – ou le même déploiement peut être entièrement reconfiguré sans toucher à la base de code.

La structure fields_schema​

Chaque type de fiche stocke ses définitions de champs comme un tableau JSONB de sections :

[
  {
    "section": "Technology",
    "columns": 2,
    "fields": [
      {
        "key": "techStack",
        "label": "Technology Stack",
        "type": "multiple_select",
        "options": [{"key": "java", "label": "Java"}, {"key": "python", "label": "Python"}],
        "weight": 2
      }
    ]
  }
]

Le weight sur chaque champ alimente le score de qualité des données – les fiches sont notées de 0 à 100 % en fonction du nombre de champs pondérés renseignés. Cela transforme le métamodèle en mécanisme d'application de la qualité : vous définissez ce à quoi ressemblent des « bonnes » données en attribuant des poids plus élevés aux champs les plus importants.

Ce que vous ne pouvez pas modifier via le métamodèle​

Le métamodèle régit la forme, pas le comportement. Quelques éléments restent dans le code :

  • Le moteur de calcul – le bac à sable sécurisé qui évalue les formules est une bibliothèque Python (simpleeval). Les formules elles-mêmes sont des données, mais l'évaluateur est du code.
  • Le système de permissions – l'ensemble des clés de permission valides est une liste d'autorisation dans backend/app/core/permissions.py. L'ajout d'une nouvelle clé de permission (pas seulement son attribution) nécessite une modification du code.
  • Le schéma de base de données – l'ajout d'une nouvelle table de niveau supérieur (par ex. un nouveau module comme PPM ou GRC) nécessite une migration Alembic. Le schéma des attributs de fiche s'étend sans migrations car les attributs sont en JSONB.

Voir aussi​