Référentiels et ontologies¶

Structurer l'information pour qu'elle soit trouvable et réutilisable à l'échelle — sans structure, la connaissance accumule sans capitaliser.

Le problème de la connaissance non structurée¶

Une base de connaissances sans structure est un entrepôt dans le noir : l'information est la, mais on ne peut pas la trouver. A petite échelle, la mémoire individuelle compense — on sait a peu pres ou chercher, on se souvient d'avoir vu quelque chose sur tel sujet. À l'échelle d'une DSI de taille moyenne, avec des dizaines de systèmes, des centaines de documents et des équipes tournantes, la mémoire individuelle ne suffit plus.

La structuration de l'information passe par plusieurs niveaux d'abstraction : le vocabulaire contrôle (nommer les choses de façon cohérente), les taxonomies (les organiser en hiérarchies), les thesaurus (exprimer les relations entre concepts), et les ontologies (formaliser la semantique jusqu'au raisonnement automatise).

Ces niveaux ne s'excluent pas — ils s'empilent. Une CMDB bien structurée mobilise un vocabulaire contrôle (les types de CI), une taxonomie (les catégories d'infrastructure), des relations typees (dépend-de, heberge, déployé-sur) qui s'approchent d'une ontologie opérationnelle.

Vocabulaire contrôle¶

L'importance de la terminologie partagee¶

Les ambiguites terminologiques ont un coût direct en DSI. "Application", "service", "composant", "module" : ces termes sont utilisés de façon interchangeable dans la plupart des organisations, avec des définitions implicites qui varient selon les equipiers, les équipes et les contextes. Deux équipes qui parlent du même objet avec des termes différents, ou de choses différentes avec le même terme — le terrain idéal pour les malentendus, les incidents et les pertes de temps.

Exemple concret : dans une DSI, "service" désigné pour l'équipe infrastructure un processus système (un daemon), pour l'équipe architecture un microservice dans le sens DDD, et pour la direction métier une prestation fournie aux utilisateurs. Un ticket de "dégradation de service" peut traverser trois équipes qui ne parlent pas de la même chose sans que personne ne s'en rende compte.

Un vocabulaire contrôle est un ensemble de termes autorises avec leurs définitions, leurs relations d'équivalence (synonymes) et leurs contextes d'usage. Il ne prétend pas être complet — il prétend être cohérent.

Les glossaires techniques¶

Le glossaire technique est la forme la plus simple de vocabulaire contrôle. Il liste les termes utilisés dans un domaine, avec :

• La définition de référence
• Les synonymes toleres (et celui qui est préféré)
• Les termes a éviter et pourquoi
• Les contextes d'usage
• Des exemples concrets

Un glossaire vivant est maintenable. Un glossaire statique devient obsolète. La gouvernance du glossaire doit être explicite : qui peut ajouter un terme ? qui valide une définition ? comment signale-t-on une ambiguite ?

Les ambiguites coûteuses¶

Quelques exemples d'ambiguites terminologiques fréquentes dans les DSI et leurs conséquences :

Taxonomies¶

Principe et conception¶

Une taxonomie est une hiérarchie de catégories permettant de classer des objets. Elle répond à la question : "Dans quelle catégorie est ce que je cherche ?" Une taxonomie bien conçue est exhaustive (tout objet peut être classe), exclusive (chaque objet appartient a une seule catégorie), et equilibree (les catégories de même niveau ont une granularité comparable).

La conception d'une taxonomie commence par les objets a classer, pas par la hiérarchie elle-même. L'erreur classique est de commencer par la structure et d'y "forcer" les objets — produisant des catégories trop génériques ("Divers", "Autres") qui absorbent tout ce qui ne rentre pas ailleurs et deviennent inutiles.

Processus de conception :

1. Inventorier les objets a classer (échantillon representatif)
2. Les grouper intuitivement par similarite (card sorting)
3. Nommer les groupes en verifiant que le nom est suffisamment distinctif
4. Vérifier l'exhaustivité et l'exclusivite
5. Iterer avec les utilisateurs cibles
6. Documenter les règles de classification pour les cas limites

Navigation et catalogues¶

Les taxonomies sont la structure de base des catalogues. En DSI, les catalogues les plus critiques a structurer :

Le catalogue de services — quels services l'IT fournit aux métiers, avec leurs caractéristiques (niveau de service, responsable, modalites de demande). La taxonomie structure les familles de services : infrastructure, applicatif, données, sécurité, support.

La CMDB — la base de gestion des configurations est fondamentalement une taxonomie des composants du SI : types de CI (Configuration Item), leurs attributs et leurs relations. Une CMDB sans taxonomie rigoureuse devient un dump d'inventaire inutilisable.

Le catalogue d'API — les API exposees, groupees par domaine fonctionnel et par type (publiques, internes, partenaires). La taxonomie facilite la découverte et evite la duplication.

Exemples de taxonomies IT¶

Taxonomie d'une CMDB (niveau 1 / niveau 2) :

graph TD
    IP["Infrastructure physique"]
    IP --> SRV["Serveurs"]
    SRV --> SRVC["Serveurs de calcul"]
    SRV --> SRVS["Serveurs de stockage"]
    SRV --> SRVV["Serveurs de virtualisation"]
    IP --> RES["Reseau"]
    RES --> SW["Commutateurs (switch)"]
    RES --> RT["Routeurs"]
    RES --> EQS["Equipements de securite"]
    IP --> STK["Stockage"]
    STK --> SAN["SAN"]
    STK --> NAS["NAS"]
    STK --> SOBJ["Stockage objet"]

    IL["Infrastructure logique"]
    IL --> VM["Machines virtuelles"]
    IL --> CTN["Conteneurs"]
    IL --> NS["Namespaces Kubernetes"]
    IL --> VNET["Reseaux virtuels<br/>(VLAN, VPC)"]

    APP["Applications"]
    APP --> AMET["Applications metier"]
    AMET --> ERP["ERP"]
    AMET --> CRM["CRM"]
    AMET --> ASPE["Applications specifiques"]
    APP --> ATECH["Applications techniques"]
    ATECH --> MW["Middleware"]
    ATECH --> BDD["Bases de donnees"]
    ATECH --> MON["Outils de monitoring"]

Thesaurus¶

Relations entre concepts¶

Un thesaurus va plus loin qu'un vocabulaire contrôle en formalisant les relations entre les termes. Il est le standard de référence pour les systèmes documentaires et les moteurs de recherche specialises. Le format SKOS (Simple Knowledge Organization System, W3C) en est la formalisation moderne.

Trois types de relations fondamentales :

Relations hierarchiques (BT/NT — Broader/Narrower Term) Exprime les relations de generalisation et specialisation. Exemple : Conteneur NT Pod Kubernetes NT Init container

Relations associatives (RT — Related Term) Exprime les relations semantiques non hierarchiques. Exemple : Circuit breaker RT Resilience RT Timeout RT Bulkhead

Relations d'équivalence (UF/USE — Used For / Use) Exprime les synonymes et les termes preferes. Exemple : Microservice USE Service applicatif (terme préféré) ; Nano-service UF Microservice

Usage dans la recherche¶

Un moteur de recherche integrant un thesaurus peut étendre automatiquement les requêtes. Une recherche sur "disponibilité" retrouve aussi les documents utilisant "SLA", "uptime", "SLO" si ces termes sont marques comme associes dans le thesaurus. La recherche devient robuste aux variations terminologiques des auteurs.

En DSI, le thesaurus est particulièrement utile pour :

• Les bases de connaissances avec des auteurs multiples aux conventions variees
• La recherche dans des corpus historiques avec des terminologies datees
• Les systèmes qui aggregent des sources hétérogènes (tickets ITSM + wiki + documentation technique)

Ontologies¶

De la taxonomie à l'ontologie¶

Une taxonomie classe. Une ontologie décrit. La différence est la richesse semantique : une ontologie formalise non seulement les catégories et les relations, mais aussi les règles qui gouvernent ces relations, permettant un raisonnement automatise.

Une ontologie comprend :

• Des classes — les types d'entités (Application, Service, Composant, Infrastructure)
• Des propriétés — les attributs et les relations entre classes (déployé-sur, dépend-de, expose, consomme)
• Des instances — les individus concrets (l'application "Facturation v2", le service "auth-service")
• Des axiomes — les contraintes et règles (un Service doit appartenir a exactement un Domaine, un CI critique doit avoir un propriétaire)

OWL et SKOS simplifie¶

SKOS (Simple Knowledge Organization System) est le standard W3C pour les vocabulaires contrôles, taxonomies et thesaurus. Il est adapté aux cas où la classification et la navigation sont les objectifs principaux. Extensible en XML/RDF, il est lisible par les moteurs de recherche semantique.

OWL (Web Ontology Language) est le standard W3C pour les ontologies formelles avec raisonnement. Il permet d'exprimer des contraintes complexes et de deduire des faits implicites. Il est plus puissant mais aussi plus complexe à maintenir. En pratique, la plupart des DSI n'ont pas besoin d'OWL — SKOS suffit pour les besoins de knowledge management.

graph TD
    Vocabulaire["Vocabulaire controle\n(termes + definitions)"]
    Taxonomie["Taxonomie\n(hierarchie de categories)"]
    Thesaurus["Thesaurus\n(relations BT/NT/RT/UF)"]
    Ontologie["Ontologie\n(classes + proprietes + axiomes + raisonnement)"]

    Vocabulaire --> Taxonomie
    Taxonomie --> Thesaurus
    Thesaurus --> Ontologie

    style Vocabulaire fill:#e8f5e9
    style Taxonomie fill:#c8e6c9
    style Thesaurus fill:#a5d6a7
    style Ontologie fill:#81c784

Quand une ontologie est justifiee¶

Une ontologie complète (OWL) est justifiee dans peu de cas en DSI :

• Les catalogues de données d'entreprise avec des schémas complexes et des lineages métier critiques
• Les CMDB de grande échelle avec des règles d'association complexes et du raisonnement automatise
• Les systèmes de gestion des risques avec des chaînes de dépendances et d'impact formalisées

Pour la plupart des besoins de knowledge management, une taxonomie bien maintenue avec un thesaurus suffit — et est infiniment plus facile à maintenir.

Metadata management¶

Schémas de metadonnees¶

Les metadonnees sont les données sur les données — les informations qui décrivent un artefact sans être son contenu principal. Elles sont essentielles pour la découverte, le gouvernance et la maintenance.

Un schéma de metadonnees standardise garantit que les mêmes informations sont collectees de façon cohérente pour tous les artefacts d'un même type. Sans schéma, chaque créateur d'artefact invente ses propres champs — produisant une hétérogénéité qui rend l'agrégation et la recherche impossibles.

Dublin Core est le schéma de metadonnees générique de référence (15 éléments : title, creator, subject, description, publisher, contributor, date, type, format, identifier, source, language, relation, coverage, rights). Il est adapté aux documents généraux. Pour les contextes IT spécifiques, des schémas etendus sont nécessaires.

Metadonnees pour les artefacts DSI¶

Tagging et gouvernance des tags¶

Le tagging libre (chaque auteur invente ses tags) produit une explosion combinatoire : "kubernetes", "k8s", "Kubernetes", "K8S", "kube" pour le même concept — et donc un moteur de recherche qui ne consolide pas les résultats.

La gouvernance des tags passe par :

• Un vocabulaire de tags contrôle (liste des tags autorises avec leurs définitions)
• Des tags obligatoires par type d'artefact (le tag domaine est obligatoire pour tout service)
• Des règles de validation à la création (impossible de publier sans les tags obligatoires)
• Une revue périodique des tags "orphelins" (utilisés une seule fois, suspects)

Catalogues de données¶

DataHub, Amundsen, OpenMetadata¶

Les catalogues de données sont des plateformes specialisees dans la découverte et la gouvernance des assets data à l'échelle. Ils combinent metadata management, data lineage et data quality en un point d'entree unique.

DataHub (LinkedIn, open source) — catalogue mature avec un modèle de metadonnees riche et extensible. Points forts : lineage graphe interactif, integrations nombreuses (Spark, dbt, Airflow, BigQuery, Snowflake), UI avancee. Point de vigilance : complexité d'installation et de maintenance pour les équipes sans expertise.

Amundsen (Lyft, open source) — focus sur la découverte par les data users. UI orientée recherche et popularité des datasets. S'appuie sur Neo4j pour le graphe de connaissances. Plus simple qu'un DataHub complet mais moins extensible.

OpenMetadata (open source) — projet plus récent mais avec un périmètre large : catalogue, quality, lineage, collaboration. API-first avec un modèle de metadonnees ouvert. Adoption croissante pour les nouvelles mises en œuvre.

Data lineage¶

Le data lineage trace l'origine et la transformation des données de leur source jusqu'à leur consommation. Il répond aux questions : "D'ou vient cette métrique ?", "Quels pipelines utilisent cette table ?", "Si cette source change, quels dashboards sont impactes ?"

Le lineage est critique pour :

• L'analyse d'impact avant de modifier un schéma ou une source
• Le diagnostic d'anomalies ("les chiffres de vente semblent incorrects — retracez le lineage")
• La conformité (savoir précis?ment quelles données personnelles passent par quels traitements)
• La confiance des utilisateurs dans les rapports et les métriques

Data quality intégration¶

Un catalogue de données sans informations de qualité est un catalogue de promesses non verifiees. Les dimensions de qualité a capturer :

• Completude — taux de valeurs manquantes par colonne
• Fraicheur — anciennete de la dernière mise à jour
• Validite — conformité aux règles de format et de contrainte
• Cohérence — alignement avec d'autres sources de référence
• Unicite — absence de doublons

Les outils comme Great Expectations, dbt tests, ou Soda s'intègrent avec les catalogues pour alimenter ces métriques automatiquement.

Applications : référentiels opérationnels DSI¶

La CMDB comme ontologie opérationnelle¶

La CMDB (Configuration Management Database) est le référentiel de référence de la gestion opérationnelle. Elle est, en pratique, une ontologie opérationnelle : elle définit des classes de CI (Configuration Items), leurs propriétés et leurs relations.

La valeur de la CMDB est proportionnelle a sa qualité : une CMDB incomplète ou desynchronisee de la réalité est inutile pour l'analyse d'impact et dangereuse pour la prise de décision. Les problèmes classiques :

• Discovery incomplet — des composants ne sont pas enregistres car découverts manuellement
• Relations non maintenues — les dépendances changent avec les évolutions, la CMDB ne suit pas
• Doublon de CI — le même composant existe en plusieurs entrees avec des noms différents
• Propriétés non renseignees — les champs critiques (propriétaire, criticite) sont vides ou génériques

La gouvernance d'une CMDB efficace nécessité un propriétaire dedié, une automatisation du discovery (intégration avec les outils de provisioning IaC, les plateformes cloud et Kubernetes), et des revues périodiques de cohérence.

Le catalogue d'API¶

Le catalogue d'API est le référentiel de toutes les API exposees — internes, partenaires et publiques. Il sert à la découverte (quelles APIs existent, pour quels usages), à la gouvernance (conformité aux standards, cycle de vie des versions) et à la sécurité (surface d'exposition, contrôle d'accès).

Un catalogue d'API efficace contient :

• La description fonctionnelle de chaque API (ce qu'elle fait, pour qui)
• La spécification technique (OpenAPI / AsyncAPI)
• Les informations de SLO et de disponibilité
• Le propriétaire et l'équipe responsable
• L'état de depreciation et le calendrier de sunsetting
• Les consommateurs connus (pour l'analyse d'impact des changements)

Outils : Backstage (Spotify), Kong Konnect, Gravitee, Apicurio.

Le référentiel d'architecture¶

Le référentiel d'architecture (parfois appelé "cartographie du SI") est la vue consolidee de l'ensemble des composants applicatifs, de leurs interactions et de leur alignement avec les capacités métier.

Il répond aux questions strategiques : "Quels systèmes supportent le processus Commande-a-Livraison ?", "Quelles applications devront migrer si on abandonne ce fournisseur ?", "Quels composants ne sont plus supportes ?"

Outils : ArchiMate + EA tools (Sparx, Mega Hopex, LeanIX), Backstage pour le composant technique, draw.io pour les vues légères.