Ce paragraphe a pour but de répondre aux objectifs d’analyse 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 également présentées dans cette section.
· Obtenir tous les services urbains (SU) reliés directement puis indirectement en précisant le nombre d’intermédiaires possibles. Les points ci-dessous illustrent les caractéristiques du graphe étudié.
o Trouver les SUs dont dépend directement (par exemple) Véolia.
o Trouver tous les fournisseurs (par exemple de Véolia) directs et indirects avec un intermédiaire au maximum.
· 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 d’effets cascade 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.
Les requêtes pour obtenir tous les services urbains (SU) reliés directement puis indirectement en précisant le nombre d’intermédiaires possibles sont présentées ci-dessous brièvement. La
représentation des résultats permet de mieux appréhender les caractéristiques du graphe étudié.
1. Les SUs dont dépend directement (par exemple) Véolia sont obtenus avec la requête suivante.
MATCH r=(n)-[ ]->(liens) WHERE n.nom="Véolia"
RETURN liens
Le résultat demandé correspond à la liste des SUs directs de Véolia. Neo4J indique en bas à gauche de la fenêtre qu’il a identifié 7 SUs, et qu’il existe entre ces 7 SUs 15 relations de dépendance (Figure 36).
Figure 36 : Services urbains dont dépend directement Véolia
2. Les SUs dont dépend directement et indirectement (par exemple) Véolia sont obtenus avec la requête suivante. Nous considérons un intermédiaire au maximum. En effet l’allongement moyen du graphe est de 1,794, ce qui veut dire qu’un chemin avec plus d’un intermédiaire pourrait relier l’ensemble des SUs de la base de données.
MATCH r=(n)-[*..2]->(liens) WHERE n.nom="Véolia"
RETURN n,liens,nodes(r )
La requête identifie 18 SUs (sur les 22 hors Véolia) reliés directement ou indirectement avec un intermédiaire. La commande « nodes(r) » détaille les SUs du chemin entre Véolia et les SUs recherchés. Neo4J indique avoir identifié 29 résultats, soit 29 chemins possibles entre Véolia et ses fournisseurs directs, ou indirects avec un intermédiaire (voir un exemple de chemin sur la Figure 11). Cette connaissance a cependant seulement un intérêt si l’on s’intéresse aux propriétés des différents liens de dépendance entre SU et que l’on peut hiérarchiser ces liens.
Figure 37 : Captures d’écrans du résultat représenté par Neo4Jet d’un des chemins identifiés
3. Identifier parmi les fournisseurs indirects les chemins les plus importants.
Le paragraphe suivant permet d’analyser les propriétés des chemins identifiés entre ces services urbains. Toubin a identifié dans sa base de données des relations de dépendance plus ou moins importantes pour chaque service urbain [Toubin, 2014]. Cette importance repose notamment sur la capacité du service urbain à ne pas dégrader ses services suite à une rupture d’approvisionnement. Chaque relation client-fournisseur entre services urbains a été renseignée dans la base de données avec son importance pour le client.
La requête suivante permet de sommer par chemin l’importance des liens qui ont exactement un intermédiaire, puis les trie par ordre décroissant.
MATCH r=(n)-[*2..2]->(liens) WHERE n.nom="Véolia"
RETURN reduce(acc=0, x in relationships(r)|acc+x.criticity) as CRITICITE, nodes(r) ORDER BY CRITICITE DESC
Neo4J identifie 23 chemins avec un intermédiaire, avec des importances allant de 8 pour la plus forte à 4 pour la plus faible, comme le montre la
Table 19. Les quatre relations les plus importantes passent par ERDF comme fournisseur intermédiaire. Si la place d’ERDF comme fournisseur central n’est pas une révélation, la présence du service d’assainissement (transport et traitement des déchets) SIAAP comme fournisseur direct de chemins avec une forte importance aurait été moins évident à mettre en avant sans l’utilisation d’un graphe relationnel et de cette requête.
Table 19 : Extrait de la table de comparaison de l’importance des fournisseurs indirects
7 Véolia SIAAP autres transports
7 Véolia SIAAP RATP métro
Toubin évalue de façon qualitative l’autonomie des SUs sur la base d’entretiens avec les SUs concernés. Nous avons ajouté celle-ci dans la base de données afin d’avoir une analyse des effets cascade sur deux critères de comparaison. La Table 20 présente les hypothèses prises sur les durées quantitatives d’autonomie pour chaque estimation qualitative de Toubin. Ces durées ont uniquement une vertu illustrative, permettant de sommer les différentes autonomies. Elles ne correspondent en aucun cas à une estimation d’autonomie. Nous cherchons à répondre aux questions suivantes.
4. En connaissant l’autonomie des services urbains face à une défaillance d’un autre service, quelles sont les chaînes de propagations de défaillances prévisibles au cours du temps ? Quelles sont les chaînes les plus importantes, avec quelle autonomie ? Table 20 : Classes qualitatives d’autonomies d’après Toubin [Toubin, 2014] et
hypothèses quantitatives d’autonomie associées
Catégories d’autonomie dans la thèse de Toubin
Aucune <12 h Quelques jours Plusieurs semaines
Toutes les dépendances non renseignées sur les capacités d’autonomie ont été volontairement surestimées (1000 h) de façon à ce que l’analyse des chaînes rapides d’effets cascade entre services urbains ne soient pas perturbées par celles-ci. Les requêtes suivantes illustrent les possibilités d’analyse et les intérêts opérationnels potentiels liés à l’utilisation d’une base de données orientée graphe.
· Pour trouver toutes les relations de fournisseur d’ordre 2 avec Véolia par exemple, qui n’ont aucun délai d’autonomie (causes d’interruptions aux conséquences immédiates sur Véolia), il faut exécuter la requête suivante.
MATCH r=(a)-[r1]-()-[r2]-(liens)
WHERE a.nom="Véolia" and r1.autonomy<1000 and r2.autonomy<1000
RETURN reduce(acc=0, x in relationships(r)|acc+x.autonomy) as autonomie, nodes(r) order by autonomie
· Pour trouver la chaîne de conséquences et les délais associés (si un SU est défaillant, par exemple Véolia, quels sont les autres services affectés ?), il suffit d’inverser la commande précédente.
MATCH r=(a)<-[r1]-()-[r2]-(liens)
WHERE a.nom="Véolia" and r1.autonomy<1000 and r2.autonomy<1000
RETURN liens, reduce(acc=0, x in relationships(r)|acc+x.autonomy) as autonomie, nodes(r) order by autonomie
Les SUs ne doivent pas être tous considérés de la même façon dans l’analyse des chaînes de défaillances. Le rôle central du SU ERDF est relativement évident. Ce paragraphe illustre sur l’exemple d’ERDF en quoi une modélisation de conséquences à l’échelle du SUs ne peut pas être considérée comme une modélisation d’effet cascade, et justifie le besoin de descendre à une échelle d’analyse plus fine : celle de l’infrastructure.
· Lorsque l’on parle d’électricité, il faut parler de délai d’autonomie, mais également de l’importance des liens à l’électricité. La commande ci-dessous permet de trier en fonction de l’importance décroissante et de l’autonomie croissante les services urbains dépendants au degré 2 de l’électricité.
MATCH r=(a)<-[r1]-()<-[r2]-(liens)
WHERE a.nom="ERDF" and r1.autonomy<1000 and r2.autonomy<1000
RETURN liens,reduce(acc=0,x in relationships(r)|acc+x.criticity)as importance, reduce(acc=0, x in relationships(r)|acc+x.autonomy) as autonomie, nodes(r)
order by importance DESC, autonomie
Comme il existe plusieurs intermédiaires entre deux SU, les SUs peuvent apparaître plusieurs fois dans les résultats. Comme les données d’autonomie ne sont pas précises, aucune analyse approfondie ne peut être faite. En revanche, cette requête illustre les possibilités d’analyse de Neo4J en temps extrêmement court (en 765 ms) pour cet exemple. Elle montre également qu’à un niveau général d’analyse, il existe des boucles de rétroaction relativement courtes. La requête identifie par exemple qu’une panne électrique peut impacter la RATP qui impactera à son tour le fonctionnement général des services de propreté. Mais les services de propreté eux-mêmes sont touchés directement par cette panne, et peuvent impacter en deuxième temps les services de la RATP selon les données de [Toubin, 2014]. Ces courtes boucles de rétroactions étaient prévisibles dès lors que le graphe a un allongement moyen à 1,794.
Cependant il est intéressant de hiérarchiser ces boucles de rétroaction en fonction de l’autonomie calculée et de l’importance des liens de dépendance.
La démarche précédente permet à la sécurité civile d’identifier les boucles d’impact suite à une coupure d’ERDF les plus problématiques par leur manque d’autonomie et l’importance du service fourni. C’est une démarche de compréhension générale, mais qui apporte peu pour la planification ou la gestion de crise. En effet elle ne reflète pas les différences d’autonomies des infrastructures derrières les SUs. Constituer à une échelle plus fine une base de données de dépendances permettrait d’obtenir avec les requêtes précédentes des résultats de boucles bien plus utiles pour la sécurité civile. La base de données à l’échelle macro permet néanmoins de comparer la cohérence des autonomies directes déclarées par les SUs face à une coupure d’électricité, avec l’autonomie indirecte constatée en prenant en compte les effets indirects avec la requête suivante. La Table 21 compare les résultats obtenus par celle-ci, en considérant les dépendances d’ordre 2 (un intermédiaire), avec l’autonomie calculée sans intermédiaire face au service défaillant (ERDF ici).
MATCH r=(a)<-[r1]-(b)<-[r2]-(liens), p=(a)<-[r3]-(liens)
WHERE a.nom="ERDF" and r1.autonomy<1000 and r2.autonomy<1000 and 1000>r3.autonomy and r3.autonomy>r1.autonomy and r3.autonomy>r2.autonomy
RETURN r3.autonomy as autonomieDir,(r1.autonomy + r2.autonomy + ABS(r1.autonomy - r2.autonomy))/2 as autonomieIndi,liens as SU,b as intermediaire
Table 21 : Différences d’autonomie entre les dépendances directes et la prise en compte de dépendances d’ordre 2
SU dépendants
La prise en compte de chemins indirects modifie les délais d’autonomie initialement estimés pour certains SUs (Orange, PC Lutèce, Eau de Paris, GRDF). Il serait intéressant pour la
sécurité civile d’analyser en priorité ces liens de dépendances avec les opérateurs pour discuter des estimations d’autonomie vis-à-vis du risque d’effet cascade. On est donc bien sur un outil de compréhension des interdépendances entre SUs et non pas sur un outil d’aide à la décision en tant que tel.
3.3.3 Limites de l’approche base de données orientée graphe à l’échelle du service