Fiche pratique :

Fiche data et tableau des connexions

Introduction

Afin de réaliser concrètement votre spécification smart et votre projet, il est nécessaire de décliner les principes énoncés (Définir les objectifs et principes du lot smart) en outils pratiques. Cette page fourni deux outils simples permettant de comprendre les besoins en data liés à chaque cas d'usage et les interactions nécessaires avec les systèmes d'information ou les applications afin de réaliser ces cas d'usage :

  • le tableau des connexions systèmes

  • la fiche data


L'une des premières étapes concrètes d'un cahier des charges de système d'information est de lister les cas d'usages auquel le système doit répondre et donc les services digitaux qu'il devra fournir. Dans la cadre du bâtiment digital, cette liste peut être longue et le projet est contraint dans le temps. Il est donc important de prioriser les cas d'usages qui devront être viables lors de la livraison du bâtiment, et ceux qui pourront être progressivement mis en œuvre dans le cadre de l'évolution digitale courante (rendue possible grâce au Building Operating System).

Cette priorisation se fait au minimum suivant deux contraintes :

  • La "criticité" du service : soit pour un bon fonctionnement du bâtiment soit pour des raisons d'image

  • Le coût de mise en œuvre du service : est-ce plus coûteux si le service est installé pendant ou après le projet de construction

Suivre le référentiel R2S de la Smart Building Alliance (SBA) ; qui préconise un réseau IP unifié, accessible et sécurisé pour l'infrastructure de communication du bâtiment et le choix de systèmes d'information ouverts avec des API accessibles et documentées ; permet déjà de rendre possible le développement de futur services en limitant les couts d'accès à l'information. Mais il reste encore à construire concrètement les "connecteurs" assurant l'échange d'information entre systèmes et les outils de data management permettant la gouvernance des données. À ce stade, plusieurs questions se posent :

  • Quels sont les données utiles pour chaque cas d'usage ?

  • Quels systèmes ou applications fournissent ces données ? (il peut y avoir de la redondance)

  • Quels sont les connecteurs à créer ?

  • Combien de connecteurs doivent être créés en fonction de l'architecture choisie ?

  • Quels sont les données de référentiel utiles pour la majorité des services ?

  • ...

Les outils "fiche data" et "tableau des connexions" permettent de formaliser de manière simple et lisible les réponses à ces questions.

Le tableau des connexions

Le tableau des connexions est construit de la manière suivante :

  • Les cas d’usages et leur déclinaison sont reportés sur les lignes (une ligne correspond à une tâche spécifique)

  • Les systèmes d’informations, applications ou sources de données sont reportés sur les colonnes (une colonne pour un système). Les producteurs de données sont classés en fonction de leur nature :

    • référentiels : données importante partagées par un grand nombre de services digitaux

    • OT : systèmes automatisés appartenant à l'infrastructure du bâtiment qui dépendent du déploiement d'objets physiques (capteurs, actionneurs, automates, IoT)...

    • IT : Systèmes informatiques de gestion pouvant être complètement virtualisés (et souvent déployés dans le cloud)

    • producteur de données personnelles : système IT spécifique qui fournissent des données personnelles

  • Une interaction ou un besoin en données est matérialisé par une case cochée entre un cas d'usage et un producteur de données. Il est important de noter que pour chaque case cochée, un "connecteur informatique" doit exister (un connecteur est un logiciel qui utilise les API pour aller récupérer et traduire les données).

Dans le tableau fourni, la liste des cas d'usage et des systèmes est indicative et n'est pas exhaustive. Elle sert d'exemple pour illustrer le tableau et devra être complétée lors de la phase de consulting amont. Vous pouvez copier ce tableau et vous entrainer à remplir les cases !

Tableau des connexions

Le tableau donne une vue résumée et complète des besoins en connexion pour chaque cas d’usage et permet de comprendre :

  • Pourquoi l’accès aux données de chaque système est important (API ouvertes, communication sur un réseau IP standard et accessible)

  • Pourquoi le croisement des données est important (les cas d’usage ont besoin des données de description du bâtiment croisées avec les données de consommation et d’usage réel par exemple)

  • Pourquoi l'homogénéisation des données est importante (pour le croisement des données de plusieurs silos)

  • Quels sont les silos de données les plus critiques (ceux qui servent le plus souvent, les données de référentiel reviendront très souvent...)

  • Quels sont les services ou cas d’usage les plus critiques en terme d’usage des données (nombre de sources de données différentes par cas d'usage)

  • Quel serait le nombre de connecteurs logiciels à réaliser entre systèmes en cas d’architecture spaghettiware (nombre de cases cochées dans le tableau)

  • La diminution drastique du nombre de connecteurs et la capacité à partager les référentiels dans le cadre d’une architecture rationnelle avec un BOS

La fiche data

En complément du tableau précédent, qui est un outil offrant une vision d'ensemble des connexions à prévoir, la fiche data permet de se focaliser sur un cas d'usage particulier et de préciser de manière plus fine les besoins en données et le détail du cas d'usage.

Dans la fiche data fourni, la liste des systèmes est indicative et n'est pas exhaustive. Elle sert d'exemple pour illustré la fiche et devra être complétée lors de la phase de consulting amont. Vous pouvez copier cette fiche et vous entrainer à remplir les cases !

Fiche data.pptx