Il ne s’agit pas d’un glossaire figé. Ces concepts sont nés de l’observation de la manière dont les équipes comprennent les systèmes, structurent l’information et prennent des décisions.
13 conceptsReprésentation
La manière dont la connaissance est exprimée.
L’information ne reste pas neutre lorsque sa forme change. Une liste, une table de décision, un diagramme ou une conversation peuvent contenir les mêmes faits tout en produisant des niveaux de compréhension très différents.
Langage commun
Une compréhension partagée qui donne le même sens aux concepts métier, d’une équipe à l’autre.
Plusieurs départements peuvent travailler avec les mêmes données sans parler exactement de la même chose. Un langage commun permet d’aligner les termes, les définitions et les hypothèses avant de les inscrire dans les processus, les modèles de données ou les intégrations.
Contexte
Le niveau minimal de compréhension nécessaire avant de pouvoir raisonner.
Le contexte indique où se situe un problème, quelle partie du système compte et quel modèle mental doit guider l’analyse. Sans lui, un raisonnement techniquement juste peut commencer au mauvais endroit.
Charge cognitive
L’effort mental nécessaire pour comprendre et utiliser une information.
La complexité devient plus difficile à gérer lorsque les relations, priorités et exceptions restent implicites. Une bonne conception de l’information réduit l’effort inutile sans masquer la complexité métier.
Mémoire collective
Ce qui permet à une équipe de continuer à comprendre lorsque les personnes changent.
Une organisation ne peut pas dépendre indéfiniment de la mémoire individuelle. La documentation, les décisions enregistrées et les modèles partagés rendent la connaissance réutilisable, même lorsque leurs auteurs ne sont plus disponibles.
Coût de recherche
L’effort nécessaire pour trouver la connaissance avant que le travail utile puisse commencer.
Une équipe peut déjà posséder la réponse et perdre pourtant du temps à la retrouver. Le coût de recherche apparaît dans la propriété floue, la documentation absente, les noms imprécis et les transmissions répétées.
Fiabilité
Le niveau de confiance nécessaire pour réutiliser une connaissance existante sans tout reconstruire.
Une information peut exister sans être suffisamment claire, récente ou crédible pour guider une décision. Lorsqu’une équipe ne peut pas s’y fier, elle finit souvent par recréer une solution à un problème déjà résolu.
Historique du système
L’accumulation des décisions intégrées dans un produit au fil du temps.
Les composants, configurations et comportements portent l’histoire d’anciens besoins clients, de réglementations et de choix d’architecture. Une petite demande peut donc toucher une structure bien plus vaste que sa surface visible.
État cible
Une manière de fonctionner conçue délibérément pour guider le changement au-delà de la simple reproduction des processus existants.
Les projets de transformation préservent souvent les contraintes historiques par défaut. Un état cible donne une direction commune pour décider quels comportements conserver, modifier ou créer.
Validation par l’usage
Vérifier une décision métier en faisant réellement utiliser la solution par ses futurs utilisateurs.
Une spécification ou une démonstration montre comment la solution est censée fonctionner. La validation par l’usage permet de tester le modèle dans des gestes concrets et de révéler les frictions avant de figer l’implémentation.
Validation
Le processus qui consiste à vérifier qu’une interprétation ou une décision reste crédible face aux preuves.
La validation n’est pas une approbation finale. C’est une comparaison répétée entre un modèle, les comportements réels et les conséquences de ce modèle.
Réalité du terrain
Les situations métier qui ne deviennent visibles qu’une fois le produit utilisé dans des contextes réels.
Les spécifications décrivent les scénarios attendus, tandis que la production révèle l’interaction réelle entre utilisateurs, exceptions et workflows. Cette réalité peut approfondir la compréhension sans invalider l’analyse initiale.
Conformité
L’alignement continu entre l’intention réglementaire, le comportement du produit et la réalité opérationnelle.
La conformité n’est pas extérieure au design du produit. Elle façonne les choix, les workflows, le langage et les preuves, et doit être continuellement validée à mesure que l’usage réel révèle de nouveaux contextes.