Risk est un utilitaire d'évaluation et de gestion de risques destiné à la prospection et au développement de projets d'énergies renouvelables. Dès la conception du projet au sein de Valeco, il a été pensé comme deux parties d'un tout qui coexisteraient au sein d'un même ensemble applicatif. Ainsi, il s'agissait véritablement du premier projet dans l'entreprise où j'étais en contact direct avec les Key Users de différents services (prospection et développement) dont les besoins étaient à ce point différents.

Chaque service n'était présent lors des revues de sprint que si le contenu du sprint était pertinent pour eux. Initialement, je n'y ai donc croisé que l'équipe de prospection, mais le nombre d'interlocuteurs a rapidement augmenté dès que nous avons commencé à développer les deux aspects de Risk en parallèle. Tout au long du développement, concilier les demandes de ces deux services et jongler entre leurs besoins pour s'assurer de n'en délaisser ou frustrer aucun des deux est resté un challenge, surtout étant donné l'équipe réduite de deux développeurs que nous pouvions à ce moment mobiliser sur ce projet.

La partie de l'outil destinée à la prospection était entièrement consacrée à l'identification de risques prédéfinis, avec des risques amenant à des situations fixes, chacune associée à un niveau de danger donné, pour chaque type de projet. L'objectif concret pour les utilisateurs était d'être amené à s'interroger, lors des phases préliminaires des projets de l'entreprise, sur la présence ou non d'une liste de risques potentiels en utilisant des templates de fiches d'analyse.

Lors de mon retour chez Valeco pour mon alternance, la partie de Risk destinée au service de prospection était déjà très avancée, avec la logique des différents templates mis en place. J'ai donc pu me faire la main sur des tâches d'amélioration afin de prendre en main l'outil et de m'habituer au paradigme utilisé au sein de l'entreprise pour l'évaluation des risques.

Pour le calcul de risques sur ses projets, Valeco commence par évaluer ce qu'on considère comme les deux composantes fondamentales d'un risque, chacune notée de 1 à 5 : la probabilité, et la gravité. La première désigne les chances que l'événement lié à ce risque se réalise, et le second mesure les conséquences si cela venait à arriver. On multiplie ensuite les deux scores ensemble pour obtenir une note sur 25. Par exemple, les chances qu'une espèce protégée comme un aigle royal ne vienne s'écraser sur les pales d'une éolienne sont faibles (probabilité : 2/5).

Cependant, cela pourrait entraîner de graves problèmes légaux qui forceraient la mise à l'arrêt de tout le parc éolien associé le temps qu'un jugement soit rendu, voire définitivement en fonction du jugement en question, sans parler de l'amende qu'il faudrait potentiellement régler (gravité : 4/5). En multipliant les deux valeurs ensemble, on obtient alors un score de 8, ce qui correspond à un risque moyen mais acceptable. La décision reviendra alors à Valeco d'essayer de prendre des mesures pour tenter d'atténuer l'une ou l'autre des composantes de ce risque, et faire baisser son score final.

Ainsi, le service de prospection sera amené lors de la recherche de terrains où installer des éoliennes ou des panneaux solaires à faire une analyse préliminaire de ces risques afin de déterminer l'endroit le plus propice à l'installation d'un parc d'énergies renouvelables. A cette fin, ils rempliront la fiche d'analyse préliminaire des risques, divisée en plusieurs catégories et sous catégories, et devront pour chaque projet renseigner l'ensemble des risques standards liés à ce type de projet.

Initialement, ces risques décrits n'étaient pas configurables, chaque template en avait une liste impossible à modifier autrement qu'en intervenant directement sur la base de données de Risk qui n'est pas accessible aux utilisateurs. Seules les sous catégories restent modulables, puisqu'il est possible d'en insérer de nouvelles, ces sous catégories correspondant généralement à des situations particulières hypothétiques qu'il convient de comparer entre elles pour fournir une analyse complète. Ainsi, à chaque changement significatif d'un template, nous devions intervenir nous-mêmes sur l'outil, ce qui réduisait grandement la modularité et l'indépendance de l'application.

Ce mode de fonctionnement pouvait être pertinent pour une première itération étant donné le caractère préliminaire de l'analyse menée par le service de prospection. Cependant, une fois cette fiche d'analyse transmise au service de développement territorial, celui-ci aurait pour mission d'en tirer une analyse définitive et exhaustive des risques encourus, et de mettre en place des mesures d'atténuation quand cela est jugé possible et nécessaire. Un mode de fonctionnement aussi rigide que pour la prospection n'était donc pas envisageable. Il nous fallait concevoir un modèle plus flexible permettant une meilleure analyse au cas par cas.

Nous sommes tout de même repartis sur l'idée des templates associés à chaque type de projet (solaire, éolien, …) afin de pouvoir y renseigner des risques considérés comme standard, qui devront toujours être évalués pour un type de projet donné (par exemple, il faudra toujours considérer le danger pour les espèces protégées lors d'un projet éolien). Pour chaque projet dont l'analyse préliminaire des risques a été effectuée, les utilisateurs du service développement peuvent alors créer un « Registre de risques ». Un registre de risques est nécessairement associé à un projet et à un type de template spécifique.

Ce template leur fournira alors une liste de risques standards à évaluer pour ce projet, répartis en catégories pour une meilleure lisibilité. Pour chacun de ces risques, la probabilité et la gravité devront être évaluées, et si celles-ci dépassent un certain seuil, des mesures d'atténuation devront être mises en place pour gérer ce risque. Ainsi, la page du registre de risques permet de connaître d'un simple coup d'œil l'ensemble des risques initiaux et atténués du projet, et de savoir facilement sur lesquels il reste du travail.

Jusqu'ici, on peut se dire que le fonctionnement ressemble beaucoup à celui des fiches d'analyses préliminaires, mais la force de ce nouveau système réside surtout dans deux outils indispensables à sa modularité que j'ai eu la tâche de développer. Le premier est un panel administrateur permettant d'éditer chaque élément d'un template et de décider quels risques appartiennent à quelle catégorie et doivent apparaître dans quel template. Ainsi, on rend les utilisateurs responsables de cet aspect de l'évolution de leur outil en leur donnant toutes les armes nécessaires pour ne pas avoir à solliciter une modification manuelle de la base de données.

Pour leur donner la possibilité d'être encore plus précis dans leur analyse, pour chaque risque, il est possible de donner des descriptions personnalisées à chaque niveau de probabilité et de gravité. Cela permet une meilleure standardisation des analyses tout en aidant les utilisateurs manquant encore d'expérience avec la méthode de notation à se familiariser avec.

Le second élément améliorant grandement la modularité du système de registres de risques est l'introduction de trois types de risques distincts. En effet, il était nécessaire d'affiner le comportement des risques afin de coller au mieux aux demandes des utilisateurs. Ainsi, une première distinction a été faite entre les risques obligatoires, ajoutés automatiquement aux registres de risque utilisant des templates où ils sont présents, et les risques facultatifs, non présents par défaut et pouvant être tout bonnement supprimés du registre de risque s'ils s'avèrent ne pas être pertinents.

Un risque peut bien entendu être rendu obligatoire ou facultatif à tout moment via le panel admin par un utilisateur ayant les droits suffisants pour y accéder. Ainsi, grâce à ce mode de fonctionnement, il est plus simple de différencier les risques essentiels à évaluer et ceux qui ne seront présents que sur une partie des projets, mais qui restent standardisés et pourront facilement être ajoutés à un registre de risque sans travail supplémentaire conséquent.

Afin d'aller un cran plus loin dans les options de personnalisation offertes par l'outil pour toujours mieux répondre aux besoins spécifiques de chaque utilisateur, un dernier type de risque a été ajouté à l'application : les risques non standard. En effet, certains projets présentent des conditions uniques qui demandent de prendre en compte des risques qui leur sont exclusifs et ne seront pas réutilisés ailleurs. Dans ce contexte, il ne serait pas pertinent d'ajouter ce risque à la liste des risques réutilisables dans tous les registres de risque : cela demanderait davantage de sollicitation des administrateurs de l'application et polluerait la liste des risques standards avec des options ayant très peu de chances d'être sélectionnées à nouveau.

C'est là qu'intervient la création de risques non standards. Si l'utilisateur ne trouve pas de risque convenant à sa situation précise dans la liste déroulante des risques liés à une catégorie, il peut alors décider de créer un nouveau risque non-standard. Celui-ci restera exclusif à ce projet, et ne pourra en aucun cas être réutilisé ailleurs tel quel. Une petite icône agrémentée d'un tooltip viendra d'ailleurs signaler par la suite qu'il s'agit d'un risque spécifique à ce projet uniquement. Bien entendu, afin de garder un œil sur l'état de ces nouveaux types de risques, ils sont intégralement consultables via le panel administrateur, où est également indiqué le projet dans lequel ils apparaissent.

Un système de tri simplifié pour fonctionner en un simple clic permet trois modes d'affichages dans le panel administrateur. On peut afficher uniquement les natures de risques standard, pour travailler seulement sur les éléments qui seront retrouvables dans tous les registres de risques, ou afficher uniquement les natures de risques non standard pour surveiller leur multiplication. Mais il est aussi possible d'afficher les deux dans le même tableau, ce qui permet de comparer aisément les différents types de risques. Ainsi, si on remarque un risque standard et non standard trop similaires, il sera possible de rattacher définitivement le dernier au premier, le remplaçant alors dans le projet où il se trouvait.

Enfin, il sera également possible si on remarque que des risques non standards identiques sont créés sur de nombreux projets, de standardiser un risque. Il sera alors disponible aisément à partir de n'importe quel projet, permettant aux administrateurs de faire évoluer naturellement l'outil grâce aux retours des utilisateurs sans même que ceux-ci n'aient besoin de les formuler explicitement, juste en observant la donnée générée.

Tout ce chantier est le résultat d'une longue phase de conception en amont, mais également des nombreux retours et commentaires des Key Users lors de nos revues de sprints, qui se sont avérés cruciaux pour la réalisation de ce projet. Risk fait appel à beaucoup de notions métier qu'il m'a fallu comprendre en profondeur, ce qui en fait un des projets pour lesquels la communication avec les clients était la plus cruciale. Il m'a véritablement fallu comprendre en détails le workflow des différents services impliqués et travailler main dans la main avec eux pour que la création d'un modèle de données robuste et d'une interface instinctive aboutisse à un outil aujourd'hui très largement utilisé et apprécié au sein de l'entreprise. Si l'outil est encore en constante évolution, il a été décidé après une demi année de développement dessus de me faire migrer sur l'autre projet majeur de Valeco pendant mon alternance, ACT, sans aucun doute le plus gros projet sur lequel j'ai eu l'occasion de travailler jusqu'à aujourd'hui.