En tant que product designer et co-responsable produit chez iQspot j’ai mené le design et le suivi de développement d’une fonctionnalité d’alertes énergétiques de la solution logicielle iQspot. Cette fonctionnalité vise à assister les gestionnaires immobiliers et energy managers dans le suivi de l’énergie de leurs bâtiments en leur permettant de positionner des alertes énergétiques se déclenchant en cas de surconsommation. Ces alertes énergétiques répondent à un besoin des gestionnaires d’un suivi “fin” des consommations pour réagir au plus vite en cas de surconsommation énergétique, un besoin initialement rapporté par les commerciaux et les energy managers.

Cette situation peut être problématisée ainsi :

Comment outiller les gestionnaires immobiliers pour leur permettre un suivi fin des surconsommations énergétiques ?

Mais derrière cette question directe se tient plusieurs difficultés :

• La diversité des profils que recouvrent le terme de “gestionnaire”
• Les compréhensions diverses des gestionnaires de leur bâtiment
• Le rapport de ces gestionnaires à l’automatisation

Prototype n° 1 : configuration manuelle

Notre premier travail a été de modéliser ce que peut être une “alerte énergétique”. Lors d’une réunion de conception incluant nos energy managers (en interne) et nos développeurs, nous avons dressé l’ontologie d’une alerte énergétique. Une alerte est désignée par un intitulé, observe une donnée (électricité, eau, gaz), se focalise sur une zone du bâtiment, peut avoir plusieurs temporalités (jour, semaine, mois, année), se limiter à un certain nombre de jours couverts dans la semaine, sur des horaires donnés, et selon un seuil d’énergie donné.

Cette définition précoce avec un minimum de recherche utilisateur a permis un prototypage rapide de la fonctionnalité de la part du développeur en charge du projet qui a pu coder le script de détection d’alertes sur la base d’une première maquette FIGMA. Le premier panneau de configuration d’alerte est très sommaire :

Une fois la configuration terminée, une alerte s’affiche dans la liste des alertes :

Cette première interface nous a servi de base pour entamer des recherches qualitatives : nous avons mené 3 entretiens qualitatifs avec des gestionnaires immobiliers, en discutant des enjeux génériques du suivi énergétique avant de leur présenter le prototype de panneau de configuration. Les conclusions, certes attendues, sont venues de la bouche des utilisateur·ices potentiel·les :

• Les informations du panneau modélisent effectivement une alerte énergétique ;
• Les variables du panneau sont difficilement manipulables par des profils non-techniques, notamment le seuil à fixer en kWh (quantité d’énergie) ;
• La configuration d’un tel panneau nécessite une connaissance fine du bâtiment : sur quels jours ouvrés et quels horaires “vit” le bâtiment ? Quelle est sa consommation habituelle ?
• Pour connaître la consommation habituelle, il faut sauter de l’écran de visualisation des consommation à l’écran de configuration des alertes, ce qui est rapidement fastidieux.

Pour répondre à la diversité des profils des gestionnaires, aux connaissances disparates de leurs bâtiments et aux questions d’UX posées par la navigation intempestive d’un écran à l’autre, nous avons pensé une deuxième version du prototype.

Prototype n° 2 : configuration augmentée

Les entretiens qualitatifs nous ont montré que les gestionnaires immobiliers peuvent certes avoir des profils d’ingénieur, mais aussi des profils plus administratifs ou juridiques, moins à l’aise avec les échelles de grandeurs et les variables relatives à l’énergie. Nous avons également relié cette tâche de configuration d’alertes aux consommations connues du bâtiment. Notre deuxième version compte de nombreuses modifications :

• Des algorithmes de recommandation des valeurs de seuils à ne pas dépasser pour les bâtiments.
• L’ajout d’une représentation graphique du seuil dans la consommation habituelle du bâtiment.
• Nous avons également précisé la sensibilité de l’alerte au regard des consommations antérieures du bâtiment.
• Une phrase de synthèse en langage naturel résume les nombreuses variables de l’alerte énergétique configurée.

Prototype n° 3 : configuration automatique

D’après nos entretiens qualitatifs, certains gestionnaires immobiliers déplorent (et en même temps comprennent) que leurs collègues aux profils moins techniques n’aient pas la motivation de configurer les alertes minimales d’un bâtiment pour éviter de grosses dérives énergétiques.

Nous avons donc pensé un nouveau prototype de configuration énergétique qui serait quasi-intégralement automatisé. Dès lors que les capteurs d’un bâtiment accumulent 1 mois de données énergétiques, un script calcule la consommation habituelle d’un bâtiment pour générer des seuils d’alertes sur certains fluides.

Pour comprendre quelles alertes les gestionnaires immobiliers et energy managers ont coutume de configurer, j’ai opté pour une recherche quantitative : j’ai demandé à l’équipe technique un export des bases de données des alertes énergétiques sur les trois plus grands parcs de bâtiments suivis par iQspot. Après avoir reformaté et épuré cette base de données, l’exercice a mis en valeur des phénomènes intéressants, nous listons ici les deux principaux :

• Les alertes sur l’eau sont les plus fréquemment configurées. D’autant plus sur les périodes d’inactivité des bâtiments. Cela permet de détecter des fuites d’eau.
• Les alertes sur l’électricité sont les deuxièmes plus fréquemment configurées, positionnées sur les périodes d’inactivité des bâtiments. Cela permet de détecter des équipements mal réglés, qui ne sont pas réduits pendant la nuit.

Afin d’assurer un service minimum de détection des dérives énergétiques, nous avons développé un algorithme qui configure automatiquement des alertes sur l’eau puis sur l’électricité. Après 1 mois d’agrégation de données, ce type d’alerte apparaît :

Précisons que cette automatisation n’est pas une proposition de valeur attendue par les profils techniques qui préfèrent recevoir des alertes qu’ils et elles ont créé :

Justement le fait de les avoir créés – en me disant par exemple qu’entre 22h et 5h du matin je ne dois avoir aucune consommation sur l’eau – je sais à quoi elles correspondent et je sais comment les gérer.

Conclusion

En articulant recherche qualitative et quantitative, nous sommes arrivés au design d’une fonctionnalité qui propose différents modes de configuration :

• Une configuration manuelle, pour qui connaît parfaitement le comportement énergétique de son bâtiment ainsi que les variables énergétiques.
• Une configuration augmentée, pour assister divers profils d’utilisateur·ices dans leur configuration par une recommandation des valeurs de seuil en fonction d’un contexte donné, une représentation graphique et des traductions des variables en langage naturel.
• Une configuration automatique, soit un algorithme qui crée des alertes que les utilisateur·ices activent ou désactivent selon leur façon de gérer un bâtiment.

Annexes

Résumé

Période : entre 2017 et 2019
Contexte : designer intégré pour iQspot
Collaboration : Alexandre Brébant (data science), iQspot
Utilisateur·ices : gestionnaires immobiliers, energy managers
Besoin : suivi fin des surconsommations énergétiques d’un bâtiments