Cet article est le troisième d’une série de 3 articles.

  1. La première visualisation de notre système de collecte : Entre créativité et veille technique
  2. Pourquoi la connaissance métier est primordiale
  3. Être à l’écoute des besoins utilisateurs

Comme on l’a vu dans l’article précédent, la connaissance métier est primordiale pour les développeurs.

Malheureusement, il n’est pas possible d’acquérir cette connaissance une fois pour toutes puis de passer à autre chose. En effet, les métiers n’ont de cesse d’évoluer, et si l’on ne veut pas devenir obsolète, il est nécessaire de se mettre régulièrement à jour.

Dans cet article, je vais tenter d’illustrer cette idée en revenant sur une de nos activités principales : la collecte de courbes de charge.

Être à l’écoute des besoins utilisateurs

La charge des courbes de charge

Chez Deepki, on collecte une grande variété de données, et notamment les courbes de charge. Lorsqu’on a commencé à les collecter, c’était pour quelques clients qui voulaient analyser leurs consommations des mois passés. On était loin du temps réel, et on pouvait se permettre quelques retards sur une partie du parc.

Mais au fil des ans, Deepki est passée du statut de petite start-up disruptive, au statut de jeune entreprise innovante, jusqu’à celui de leader sur le marché français. Et au-delà des apparences, l’évolution de ce statut a traduit non seulement une évolution des ressources humaines, technologiques et financières, mais aussi l’évolution d’une offre et d’une clientèle.

Les attentes clients se sont ajustées à notre offre, et cela s’est ressenti à de nombreux niveaux, notamment au niveau de la collecte.

Aujourd’hui, non seulement on ne peut plus se permettre des retards sur une partie du parc, mais c’est la définition même du retard qui a changé. Il y a quelques années, on n’aurait pas eu besoin de se justifier face à une courbe de charge qui n’aurait pas été mise à jour depuis 3 semaines ; aujourd’hui on peut être mis en difficulté face à une courbe de charge qui n’a pas été actualisée depuis 48 heures.

Ce n’est pas que le client a augmenté ses exigences de manière démesurée, mais que ses besoins ont évolué. En effet, il ne s’agit plus uniquement d’analyser sa consommation sur les mois passés, mais bien d’actionner différents leviers en fonction de sa consommation immédiate. Deepki s’engage par exemple à détecter les anomalies de consommation, et dans de tels cas, il est souvent conseillé d’agir très vite. Il est donc tout à fait normal que les exigences clients vis à vis de la collecte de courbes de charge aient évoluées.

Le besoin métier a donc évolué au cours du temps et cela a eu un impact technique sur notre application et sur la façon de la monitorer. En effet, une tâche technique (ici la collecte de courbes de charge), parce qu’elle est soumise à des besoins différents, doit répondre à des exigences nouvelles, et adapter ses performances.

Cela dit, ici, le moteur de cette évolution de besoin, c’était nous. Deepki a fait évoluer son offre, et c’est cela qui a entrainé une mise à niveau des performances de notre système. Cette mise à niveau était désirée et prévisible. Dès lors, la question qui me vient à l’esprit est la suivante :

Que se passe-t-il lorsque les besoins utilisateurs évoluent indépendamment de notre volonté ?

La marche du marché

On l’a dit juste au-dessus : lorsqu’on a commencé a collecter des courbes de charge, c’était pour quelques clients seulement. Pourquoi pas pour tous ? Tout simplement parce qu’à ce moment-là collecter des courbes de charge coûtait relativement cher, et que le client lambda n’y trouvait pas son compte. Les clients intéressés étaient des clients experts, qui les collectaient déjà bien avant d’utiliser notre application. Mais un jour, tout changea.

En 2018, Enedis a mis à disposition une API pour que chacun puisse accéder à ses courbes de charge “gratuitement”. Cela eut un impact majeur dans tout le secteur, qu’on pourrait trivialement résumer ainsi :

Soudain, tout le monde voulait des courbes de charge.

Cela impacta évidement notre équipe, puisqu’il fallut non seulement développer des outils pour se connecter à cette API, mais aussi dédier complétement un serveur à ce service.

Cet impact venait bien d’un changement extérieur, indépendant de notre volonté. Mais peut-on réellement parler d’un changement inattendu ? Bien sûr que non. Enedis a communiqué sur son API plusieurs mois avant de la déployer en production, ce qui nous laissa largement le temps d’enquêter auprès de nos clients afin d’évaluer à l’avance leurs attentes et la charge de travail que cela représenterait pour nous.

On se pose alors la question suivante:

Les besoins utilisateurs peuvent-ils évoluer de manière complétement imprévisible ?

Le monitoring au temps du confinement

Des événements imprévisibles, il en existe. Le confinement de mars 2020 en est un bel exemple. Ses répercussions furent nombreuses et impactèrent plusieurs secteurs, notamment ceux de l’énergie (cf la baisse des consommations énergétiques des bâtiments de bureaux) et du monitoring (cf l’envol de la cotation boursière de datadog).

Pour la plupart de nos clients, un des enjeux du début de ce confinement, fut de s’assurer de la fermetures des sites. Mais comment s’assurer qu’un site est bien fermé lorsque les libertés de déplacements sont restreintes ? Vous l’avez deviné, c’est possible grâce au monitoring, et plus particulièrement grâce au monitoring de courbes de charge. En effet, à la lecture d’une courbe de charge, on sait immédiatement si un site est fermé ou non, on peut même savoir à quelle minute précisément il a été fermé.

Dès lors, la collecte de courbe de charges répondait à un nouveau besoin, un besoin qu’on n’aurait pas pu anticiper 1 mois plus tôt, celui du suivi de fermeture en masse des sites. Et pour répondre à ce besoin, on se concentra sur la collecte des dernières données accessibles, au jour le jour, quasiment en temps réel.

Heureusement pour nous, notre système fut capable d’encaisser ce choc sans évolution majeure. Ce qui nous permit d’être très réactif et de réaliser des success stories, notamment avec Unibail-Rodamco-Westfield.

Néanmoins, il aurait très bien pu s’agir d’un besoin pour lequel notre système était inadapté. Il faut donc garder en tête que l’imprévisible peut se produire et qu’il faut toujours être prêt à s’adapter.

Conclusion

On a pu le voir, les facteurs qui mènent à l’évolution d’un produit sont multiples : il peut s’agir d’une volonté de l’entreprise d’élargir son offre, d’une augmentation du nombre de clients, ou d’un facteur extérieur, qui touche directement ou indirectement le secteur de l’entreprise.

Parfois, ces évolutions invalident les indicateurs qui permettaient jusqu’alors de mesurer le bon fonctionnement du produit et nous posent des défis techniques inattendus.

Ainsi, réévaluer les besoins des utilisateurs, la pertinence des solutions techniques et les outils de monitoring, n’est pas le signe d’autant d’échecs lors de leur élaboration originale, mais plutôt le signe d’une évolution naturelle d’un produit ancré dans un contexte qui change. En d’autres termes, on aurait tort de s’accrocher à de vieux indicateurs, car finalement, être obligé de les remettre en question, c’est la preuve que l’application évolue, ce qui est une bonne nouvelle.

Il est donc important de constamment se questionner sur les besoins de ses utilisateurs et sur la manière dont on y répond.

Et justement, ma nouvelle collègue est toujours à côté de moi, coincée entre des indicateurs au vert et un client insatisfait, ce qui m’oblige à vous avouer : il est temps pour moi de retourner bosser !