Neo4J (www.neo4j.org) est une base de données orientée graphe, c’est-à-dire qu’elle stocke à la fois les entités caractérisées par des attributs (nœuds du graphe ou services urbains dans notre cas) et également les relations caractérisées (attributs) qui lient ces entités entre elles (arcs du graphe). Ces entités peuvent être des personnes, des groupes, des services, des entreprises, etc. Dans le cadre de cet exemple simple, il existe seulement un type de relation :
« NEEDS », qui symbolise les besoins d’un service urbain pour fonctionner. On pourrait étendre cette analyse à des relations de type « contrôle », « valide », etc. Les requêtes exécutées par Neo4J sont en Cypher. Elles fonctionnent toutes sur la même architecture : MATCH “service urbain ou relation” WHERE “condition” RETURN « le résultat souhaité:
liste de propriétés, somme de propriétés sur l’ensemble des relations, description des services urbains; etc. »
Vocabulaire : (Nœud 1) –[relation1] ->(Noeud2) forme un chemin comprenant deux nœuds et une relation.
Toubin [Toubin, 2014] décrit les dépendances entre services urbains de la ville de Paris face au scénario de la crue centennale de la Seine. Ce sont ses données qui seront utilisées dans ce paragraphe. Elles proviennent des ateliers collaboratifs entre les services urbains organisés dans le but d’évaluer et d’améliorer la résilience de la ville de Paris sur les aspects techniques et organisationnels. Le Table 18 liste les 18 services urbains (SU) concernés. Afin de recenser les liens de dépendances de ces services vers des organisations non rencontrées, 5 services
« passifs » ont été créés (Voirie, Autres syndicats d’eau, Hydrocarbures, Autres transports et Autres opérateurs).
Table 18 : Services urbains étudiés dans [Toubin, 2014]
N° Services urbains Services produits N° Services urbains Services produits
1 ERDF Electricité 13 PC Lutèce Régulation trafic
2 GRDF Gaz 14 EVESA Eclairage
3 CPCU Chauffage 15 Fonctionnelle Viabilité
4 Climespace Climatisation 16 Voirie Déplacement
5 Hydrocarbures Carburants 17 RATP bus Transport
6 Eau de Paris Eau potable 18 RATP metro Transport
7 Autres syndicats Eau potable 19 Autres transports Transport
8 SAP Assainissement 20 Orange fixe Téléphone
9 SIAAP Assainissement 21 Orange mobile Mobile
10 Propreté Collecte déchets 22 Orange internet Internet
11 SYCTOM Traitement déchets 23 Autres opérateurs Télécommunications
12 Véolia Transport déchets
Toubin a caractérisé les dépendances (existence et importance) entre services urbains. Le résultat est reporté sur la Figure 33. Sur celle-ci, il faut lire les dépendances en vertical : par
exemple, le service n°1 dépend des services n°3, 5, 6, 7, 11, 16, 21 et 23 pour fonctionner.
Cette matrice sert de base de données pour notre analyse sous Neo4J et pour quantifier l’importance relative des différents SUs, en termes de dépendances directes et indirectes.
Figure 33 : Dépendances entre services urbains parisiens, évaluation de leur importance [Toubin, 2014]
Les relations proviennent des portraits (description détaillée) des services urbains, réalisés sur la base d’entretiens avec les gestionnaires de ces services responsables de la gestion du risque inondation. Ils sont plus approfondis que la seule notion « d’importance » des relations : Ces portraits décrivent l’importance des ressources entrantes pour le service urbain et l’autonomie du service face à une rupture d’approvisionnement, les délais de remise en route du système suite à une rupture d’approvisionnement, la fiabilité des fournisseurs, mais également l’importance du service rendu vis-à-vis des clients du service. La structure générale de ces portraits est présentée sur l’exemple de GRDF sur la Figure 34. Cependant tous ces portraits ne sont pas accessibles dans la thèse de Toubin. Nous avons donc analysé dans Neo4J seulement les relations présentées dans la Figure 33. Cela constitue une base de données avec 23 services urbains et 167 relations de dépendance.
La matrice représentée ici est relativement simple car elle n’a que deux dimensions et un nombre très restreint de lignes. Cependant la représentation matricielle des dépendances rend difficile l’analyse d’une base de données qui serait plus fournie (plus de SUs par exemple) et
détaillée (plus de critères que juste la notion d’importance) que celle utilisée ici. Le cas se présente quand plusieurs propriétés caractérisent le même lien de dépendance, obligeant à analyser plusieurs matrices à la fois. C’est pourquoi l’utilisation d’un logiciel de gestion de base de données de type graphe (Neo4J ici, d’autres exemples peuvent être trouvés) facilite le traitement des données disponibles. Neo4J a permis notamment de répondre rapidement aux objectifs suivants, sélectionnés pour leur utilité pour la sécurité civile à comprendre l’écosystème des relations. Les requêtes permettant d’y répondre sont présentées dans cette section comme une ébauche de système automatisé d’analyse des interdépendances entre SUs.
· Obtenir tous les services urbains (SUs) reliés directement puis indirectement au SU étudié en précisant le nombre d’intermédiaires possibles.
· Comparer l’importance des relations entre services urbains.
o Identifier parmi les fournisseurs indirects les chemins les plus importants dans la hiérarchie des relations de dépendance.
o En connaissant l’autonomie des services urbains face à une défaillance d’un autre service, identifier les chaînes de défaillances prévisibles au cours du temps. Identifier les chaînes les plus importantes et connaître leur autonomie.
o Identifier les décalages d’autonomie entre l’autonomie directe déclarée face à la perte d’un fournisseur, et l’autonomie constatée avec Neo4J lorsque l’on prend en compte l’autonomie des fournisseurs indirects.
Ce paragraphe démontre alors en quoi la prise en compte de la défaillance successive de services urbains ne peut pas être assimilée à une modélisation d’effet cascade en elle-même, et en quoi les relations de dépendance sont trop généralistes pour avoir un modèle utile pour la gestion de crise ou la planification. Toubin proposait déjà une analyse de graphe sur ces données, avec le nombre de relations entrantes et sortantes par SUs et une analyse de l’ensemble des interactions [Toubin, 2014]. La démarche innovante de cette section se situe sur l’utilisation d’une base de données orientée graphe pour répondre à des requêtes précises, avec un but opérationnel. Elle a pour but de démontrer la faisabilité d’analyse d’un graphe de relation qui serait constitué à l’échelle de l’infrastructure, et d’illustrer son potentiel intérêt opérationnel.
L’analyse des chaînes de dépendance ne se fera pas au-delà d’un SU intermédiaire (donc trois SUs impliqués). En effet, Toubin montre que, en moyenne, deux SUs sont reliés par moins d’un intermédiaire (allongement moyen du graphe des relations de 1,794). La majorité des SUs sont dépendants de l’ensemble des autres SUs par des chemins de longueur deux (donc avec un intermédiaire).
Une fois importée dans Neo4J, la base de données de relations est représentée telle que sur la Figure 35. La visualisation en 2D des relations de dépendance est trop complexe pour être analysée simplement de façon visuelle. Il faut passer par des requêtes pour obtenir des résultats d’analyse.
Figure 34 : Portrait sectoriel de GRDF d’après Toubin [Toubin, 2014]
Figure 35 : Relations entre services urbains parisiens représentés avec Neo4J
3.3.2 Potentiel opérationnel de l’utilisation d’une base de données orientée graphe