Dans le second article, nous avons vu que le graphe pouvait être découpé en sous-graphes, soit en considérant les composantes connexes, soit en y calculant des communautés.

Dans ce troisième et dernier article, nous allons nous intéresser dans un premier temps à la notion d’homophilie, pour ensuite parler du concept de projection d’un graphe (biparti).

Homophilie

En sociologie, le terme “homophilie” (déjà exploité dans un blog précédent) désigne le fait pour une personne d’avoir plus d’affinité avec les personnes similaires à elle-même (“qui se ressemble s’assemble”). Par extension, en théorie des réseaux, on dira qu’un réseau est homophile si, dans le voisinage immédiat d’un nœud, on aura tendance à trouver des nœuds similaires à ce nœud. La notion de similarité peut vouloir dire beaucoup de choses : pour des personnes, partager des centres d’intérêts, une ethnie, un niveau de formation ou socio-économique, une religion… pour des entreprises, être actif dans le même secteur, dans la même région, voire même être également enclins à frauder.

Nous allons ici voir dans quelle mesure le marché du travail belge est “homophile”, et cela selon deux caractéristiques : la province de l’employeur, et ses codes NACE. Nous nous poserons donc la question suivante : un travailleur employé par une société située en province X (ou exerçant dans le domaine X) va-t-il, s’il change d’employeur, favoriser une entreprise de la même province (ou du même domaine) ?

Homophilie par province

Aperçu général

En premier lieu, nous allons évaluer, pour chaque province, la proportion de travailleurs qui travaillent dans cette province, puis changent de travail pour un employeur dans une autre province. Le nombre obtenu pourrait ainsi être interprété comme une mesure de la “fidélisation” d’une province.

Il nous faut donc calculer deux valeurs pour chaque province :

• Le nombre de personnes qui, sur la période étudiée, y ont eu un emploi
• Le nombre de personnes qui, après un emploi dans cette province, ont trouvé un emploi dans une autre.

Requêtes Cypher

MATCH (c:Company)--(p:People)
RETURN c.Province, COUNT(DISTINCT p)

MATCH (c1:Company)-[r1]-(w:People)-[r2]-(c2:Company) 
WHERE 
   c1 <> c2 
   AND r1.START <= r2.START 
   AND coalesce(c1.Province, "null") <> c2.Province
RETURN c1.Province, COUNT(DISTINCT p)

Combinées, ces données nous permettent d’obtenir le graphique suivant :

Notons que la colonne “Bruxelles” est particulière : c’est dans la capitale que la plupart des entreprises actives sur tout le territoire (ministères, chaînes de magasins…) ont leur siège social. Le fait que son employeur soit renseigné à Bruxelles ne veut donc pas dire que l’on travaille dans cette ville.

Le graphique nous indique que 63% des personnes ayant travaillé dans le Brabant Flamand ont ensuite trouvé un emploi ailleurs, alors que seuls 46 % des travailleurs liégeois ont quitté leur province. En termes d’homophilie, on peut donc estimer que Liège est plus “homophile” que le Brabant Flamand : dans le “voisinage” de Liège (les autres employeurs des travailleurs d’employeurs liégeois), on trouve une plus grande proportion d’entreprises Liégeoises qu’on ne trouve d’entreprises (flamo-)brabançonnes dans le voisinage du Brabant Flamand.

Notons que ce constat ne dit rien des raisons : les liégeois ne sont pas nécessairement “pantouflards”, il se peut que les conditions de travail y soient si bonnes que rares sont ceux qui veulent aller voir ailleurs.

Aperçu détaillé

Si l’on veut une vue plus détaillée de cette notion d’homophilie provinciale, on peut aussi comparer, pour chaque province P, les deux répartitions suivantes :

• La répartition du voisinage de P, c’est-à-dire les provinces où travaillent tous les travailleurs qui ont d’abord travaillé pour une entreprise situé en province P
• La répartition générale des travailleurs par province.

Pour la répartition générale, nous allons calculer le nombre de personnes ayant eu, au cours de ce 15 dernières années, un emploi dans chaque province.

Comme nous souhaitons obtenir une distribution, la somme de toutes nos colonnes doit être égale à 1 (ou 100%). Nous divisons donc chaque colonne par la somme de toutes les colonnes. Cette valeur est supérieure à la population totale, car chaque travailleur ayant travaillé dans deux provinces sera compté 2 fois. Ce qui compte, ce n’est pas la hauteur absolue d’une colonne, mais sa hauteur par rapport aux autres colonnes.

Nous obtenons le graphique ci-contre.

Requêtes Cypher

MATCH (c:Company)--(p:People)
RETURN c.Province, COUNT(DISTINCT p)

Nous calculons ensuite, pour chaque province P, le nombre de personnes qui, après un emploi dans cette province P, ont eu un autre emploi dans cette même province, ce qui nous donne la série de graphiques ci-dessous.

Requête Cypher

MATCH (c1:Company)-[r1]-(p:People)-[r2]-(c2:Company) 
WHERE c1 <> c2 AND r1.START <= r2.START
RETURN c1.Province, c2.Province, COUNT(DISTINCT p)

Notons qu’il est difficile de comparer la vue générale que nous avons montrée ci-dessus avec cette série de graphiques, pour plusieurs raisons :

• La série de graphiques montre comment se sont comportés ceux qui ont changé de travail. On ne compte donc pas ceux qui n’ont jamais changé d’employeurs, ce qui représente un peu plus de 42 % des travailleurs, comme mentionné dans notre premier blog .
• Un travailleur qui a d’abord travaillé à Bruxelles, pour ensuite partir à Namur et puis à Mons, en Hainaut, sera repris à la fois dans les transferts Bruxelles-Namur, mais également Bruxelles-Hainaut. On ne peut donc pas sommer les migrations entre une province et les autres pour connaitre le nombre de personnes ayant quitté la province.
• Si la hauteur absolue d’une colonne dans le graphique général a un sens (proportion de travailleurs ayant quitté la province), elle n’en a pas vraiment la série de graphiques qui suit.

Quelques observations peuvent être faites :

• La répartition du voisinage de Bruxelles diffère peu de la répartition globale des travailleurs : cela s’explique très probablement par ce qui a déjà été évoqué, la plupart des grandes structures ayant leur siège social à Bruxelles
• En dehors de Bruxelles, le voisinage d’une province reste majoritairement dans la même région (Flandre ou Wallonie)

Homophilie par secteur (Code NACE)

Nous avons réalisé une analyse similaire sur base des Code NACE (décrits dans notre premier article), précisant le secteur d’activité, à nouveau en excluant les contrats d’intérim. Nous nous posons la question suivante : le “voisinage d’un secteur” (à savoir les entreprises dans lesquelles travaillent les travailleurs d’entreprises du dit secteur) est-il différenciable de l’ensemble de la population des entreprises ?

Nous présentons pour ce faire les graphiques accessibles dans ce document joint.

Pour chaque page, correspondant à un code NACE (de premier niveau), on trouve sur la première ligne la comparaison entre la distribution des codes NACE des entreprises en général (en bleu) et la distribution des entreprises employant au moins un travailleur ayant été embauché par une entreprise du code NACE concerné. À gauche, la comparaison se fait sur base du nombre d’entreprises. À droite, sur base du nombre de travailleurs. En titre, le coefficient de correlation (selon la méthode de Pearson) indique à quel point le voisinage du secteur analysé diffère de la distribution globale. Proche de 1, il sera quasiment indifférenciable, plus on s’en éloigne, plus spécifique sera le voisinage du secteur analysé.

Les graphiques du bas, indiquent, pour chaque code NACE, le ratio entre les deux colonnes du graphique du haut. Il s’agit d’une autre façon de voir les secteurs surreprésentés (au dessus de la ligne pointillée rouge) et sous-représentés (en dessous de la ligne).

Nous constatons que pour quasiment tous les secteurs, ce même secteur est sur-représenté dans le voisinage, montrant que le phénomène d’homophilie est observé. La sur-représentation présente cependant des grandes variations : à peine perceptible pour le commerce (code G), très importante pour des secteurs très spécialisés (et concernant très peu de monde), comme les activités extra-territoriales (code U) ou l’extraction (code B).

Nous laissons au lecteur le choix d’aller plus loin dans l’analyse, en identifiant par exemple des secteurs “associés” (souvent sur-représentés ensemble).

Projection biparti

Lorsque l’on a un graphe biparti, c’est-à-dire un graphe avec deux types de nœuds A et B (comme par exemple travailleur et employeur) et des arcs qui vont uniquement entre un nœud du type A et un nœud du type B (comme par exemple les relations de travail), on peut réaliser ce qu’on appelle une projection biparti. Il s’agit d’un graphe qui ne comportera que des nœuds d’un type A (resp. B), et qui aura un arc entre deux nœuds x₁ et x₂ s’il existe dans le graphe d’origine un nœud du type B (resp. A), lié à x₁ et à x₂. Il existe toujours deux projections d’un graphe biparti : une pour chaque type de nœud. Dans le cas qui nous occupe, nous aurons un graphe reprenant la totalité des employeurs, et un lien entre deux employeurs s’il existe une personne ayant travaillé pour les deux employeurs, et un graphe reprenant la totalité des travailleurs, avec un lien entre deux travailleurs s’ils ont un jour été collègue (en supposant deux personnes collègues si elles ont travaillé pour un même employeur, mais pas nécessairement en même temps).

Les arcs créés dans la projection biparti sont souvent associée à un poids, qui peut par exemple avoir pour valeur le nombre de nœuds “compressés” dans la projection : il peut s’agit du nombre de travailleurs partagés dans le cas de la projection sur les employeurs, ou du nombre d’entreprises dans lequel les deux extrémités de la relation ont été collègues.

Pour l’analyse qui suit, nous n’avons pas considéré les travailleurs intérimaires, qui, par nature, changent souvent d’employeurs, et pourraient fausser les impressions. Nous n’avons par ailleurs considéré que la composante géante (voir notre article précédent). Par définition, il n’y aura pas de travailleurs en commun entre deux entreprises faisant partie de deux composantes connexes distinctes.

Nous n’avons pas pu réaliser l’analyse qui suit dans la base de donnée Neo4j, n’ayant trouvé aucune fonctionnalité permettant de réaliser les projections voulues. Nous avons utilisé la librairie igraph.

Projection par entreprise

La première projection que nous avons réalisée est la projection par entreprise. Elle comporte un peu plus de 530 000 employeurs, et 22 millions de liens. En regardant le poids de ces liens (indiquant dont le nombre de travailleurs partagés), on en trouve 18.6 millions ayant la valeur 1. Il y a donc 18.6 millions de couples d’employeurs ne partageant qu’un seul travailleur. Les valeurs les plus intéressantes se trouvent à l’autre extrémité : il existe deux employeurs se partageant 37 350 travailleurs ! Nous y trouvons ensuite un triplet d’employeurs qui se partagent deux par deux, respectivement, 11 000, 10 000 et 7 000 travailleurs.

Le premier est le fait d’une société nationale, qui a une structure juridique séparée pour la gestion de ses ressources humaines. Chaque travailleur y est déclaré dans les deux structures. Le second concerne un organisme de gestion d’artistes, divisé en plusieurs structures juridiques distinctes. On trouve aussi un chaîne de grands magasins de près de 140 000 salariés (dont un très grand nombre de jobistes), partageant 5 800 travailleurs avec un ministère de 250 000 salariés. Il n’est bien sûr pas surprenant que deux aussi gros employeurs partagent autant de personnel. L’essentiel de ce que l’on voit par la suite est du même acabit : de très gros employeurs, liés entre eux par un nombre de salariés qui est dans l’absolu élevé, mais pas relativement au nombre d’employés respectif. Une analyse plus approfondie, où l’on placerait en poids la proportion de personnel partagé (par exemple, avec la distance de Jaccard) apporterait un autre éclairage. On pourrait par exemple détecter des transferts d’entreprises, des rachats ou des fusions. Nous n’irons pas plus loin ici dans cette analyse.

Projection par travailleur

La projection par travailleur pose un problème de taille : elle est très largement plus volumineuse que celle par entreprise. Nous sommes parvenus à déterminer qu’elle devait comporter un peu plus de 7 millions de nœuds, et pas loin de 400 millions d’arcs, mais, en utilisant la libraire igraph sur un serveur ayant à sa disposition 64 GB de mémoire, nous n’avons pas réussi à la calculer. Cependant, nous voulions principalement mettre en évidence les couples de personnes partageant de nombreux employeurs.

Cliquer ici pour voir comment nous avons malgré tout pu contourner cette limitation

Dès lors, nous pouvions d’entrée de jeu éliminer de nos données tous les employeurs ayant moins de deux travailleurs. En effet, un employeur avec un seul travailleur ne pourra par définition pas être un employeur commun entre deux personnes. Cette simplification n’aura aucun impact sur la projection, ces employeurs supprimés n’étant jamais considérés comme “en commun” entre deux travailleurs, et donc n’apparaissent dans aucun poids.

Dans le même ordre d’idée, si nous voulons trouver tous les couples de travailleurs partageant au moins, mettons, 10 employeurs, nous pouvons également éliminer tous les travailleurs ayant moins de 10 employeurs (pour avoir 10 employeurs en commun avec un autre travailleur, il faut avoir soi-même au moins 10 employeurs). Cette dernière simplification supprimera des nœuds dans la projection résultante, mais uniquement des nœuds qui, dans la projection, ne seront liés à aucun nœud avec un poids supérieur ou égale au seuil fixé (10 dans notre exemple). L’illustration ci-dessous montre un graphe biparti (vert et orange), pour lequel on veut réaliser la projection “verte”, avec un seuil fixé à 4.

Avec la première simplification, le nœud orange “i” (degré = 1, inférieur à 2) est supprimé. Avec la seconde simplification, le nœud vert “3” (degré = 3, inférieur au seuil 4) est supprimé lui aussi. Les deux projections (complète et simplifiée) sont ensuite montrées sur la droite. On y voit qu’en dehors de la suppression du nœud 3, les poids sur les arcs sont identiques.

Le résultat de cette projection nous montre que bon nombre de travailleurs partagent un grand nombre d’employeur avec d’autre salariés. Par exemple, 32 couples de travailleurs (au total, 24 travailleurs), partagent deux par deux plus de 30 employeurs (jusqu’à 46), comme illustré ci-dessous, où chaque nœud représente un travailleur, et les labels sur les arcs le nombre d’employeurs commun entre deux travailleurs.

Une analyse plus approfondie ce ces différents clusters mets en avant certains secteurs : le cluster de gauche concerne des employés embauchés essentiellement en tant que travailleurs occasionnels dans le secteur de la collecte de fruits et légumes ; celui du milieu des entreprises des arts du spectacles. Il s’agit de deux secteurs pour lesquels on change fréquemment d’employeur entre chaque “prestation” (une saison de collecte ou une tournée de spectacle).

Pour chacune des relations affichées sur le réseau ci-dessus, nous avons également calculé la distance de Jaccard, qui indique le ratio entre le nombre de voisins communs entre deux nœuds, et le nombre total de voisins de ces deux nœuds. Il se situe à chaque fois entre 25 et 45 %. Ceci indique que nous ne sommes donc pas dans une situation similaire à celle évoquée ci-dessus (pour la projection par employeur), ou deux “super-employeurs” avaient toutes les chances de partager quelques salariés, mais bien dans des situations ou deux travailleurs partagent une partie importante de leurs employeurs. Il y a donc fort à parier que, dans beaucoup de cas, il s’agisse de personnes qui cherchent du travail ensemble. Ceci pourrait être corroboré en menant une analyse plus fine, et en ne considérant qu’un employeur n’est commun entre deux travailleurs que si les périodes d’engagement coïncident. Nous avons mené cette observation manuellement pour les relations les plus fortes, et observé que c’était le cas dans la majorité des relations de travail.

Conclusions

Cette série d’articles a mis en lumière la puissance que l’analyse réseau, en combinaison avec une base de données orientée graphes, pouvait offrir. La gamme de résultats est très large : on peut à la fois obtenir des métriques offrant une vue très générale (le nombre de travailleurs à un moment donné, le nombre moyen d’employeurs par travailleur…), mais également isoler facilement des comportements qui sortent du lot (travailleurs changeant anormalement souvent d’employeur, employeurs ayant du personnel extrêmement fidèle…). L’analyse réseau est donc à la fois un excellent complément de l’analyse statistique classique, mais est également un outil de très grande valeur pour détecter la fraude ou les erreurs et autres problèmes de qualité dans les données.

Il va de soi que, en combinaison avec des experts soit du marché de l’emploi, soit en statistiques, de nombreuses autres observations pourraient être faites. Certaines de celles-ci pourraient également être obtenues avec des techniques statistiques classiques, mais beaucoup nécessiteraient un travail démesuré, voire même seraient tout simplement impossibles.

Nous allons maintenant examiner deux façons de découper le réseau en plusieurs “sous-réseau” : dans un premier temps une découpe par “composante connexe”, ensuite par détection de communauté.

Rappelons que nous considérons un graphe (ou réseau) selon le modèle présenté ci-contre : nous avons deux types de nœuds (travailleurs et employeurs) ; la relation entre un travailleur et un employeur indique les dates de début et fin (si applicable) de contrat, ainsi qu’un “worker code”, décrivant une série de catégories présentées dans l’article précédent.

1. Composante connexe

En partant d’un travailleur donné, on peut, en parcourant le graphe, trouver tous ses collègues, actuels ou anciens, via le lien “travailleur→employeur”, puis “employeur→travailleur”. Si, à partir de ces collègues, on re-parcourt le graphe de la même façon, on obtiendra les “collègues de collègues” du travailleur de départ. En continuant de la sorte tant que l’on tombe sur des travailleurs que l’on n’a pas encore rencontrés, on parcourt ainsi une “composante connexe“, soit un ensemble (maximal) de nœuds pour lequel il existe un chemin entre chaque paire de nœuds. Tous les nœuds d’un graphe ne font pas nécessairement partie de la même composante connexe : si deux travailleurs font partie de deux composantes connexes distinctes, il n’existe pas de chemin “(ex-)collègue de (ex-)collègue de (ex-)collègue …” entre ces deux travailleurs.

Le graphe ci-contre illustre un réseau composé de trois composantes connexes : une en haut à gauche, composée de 4 nœuds ; une seconde en bas à droite, de 5 nœuds ; une dernière, plus importante, entre les deux.

Composante géante

On appellera “composante géante” la plus grande composante connexe d’un graphe. Si on effectue ce calcul sur notre graphe de Dimona, on obtiendra une composante effectivement géante : elle est composée de 8 149 146 de nœuds, dont 581 065 entreprises et  7 568 081 travailleurs.

En d’autres mots, si l’on considère toutes les relations de travail de ces 15 dernières années, 99.5% des travailleurs ayant été actifs sur cette période sont “(ex-)collègue de (ex-)collègue de (ex-)collègue …” entre eux, via 95 % des entreprises. Ceci en considérant que deux personnes sont collègues si elles ont eu le même employeur, simultanément ou non. Le monde du travail (belge) peut donc être vu comme un “petit monde”, théorisé par Milgram dans son paradoxe éponyme.

Diamètre

En analysant de plus près cette composante géante, on voit que son diamètre, soit le nombre de relations du plus long “plus court chemin” entre deux nœuds, est de 20. Ce qui veut dire que, pour 99.5% des travailleurs actifs sur la période, il n’est jamais nécessaire de passer par plus de 9 (ex-)collègues intermédiaires pour “connecter” deux travailleurs.

En moyenne, il faut 1.5 collègues intermédiaires pour chaque paire de travailleurs (longueur moyenne du plus court chemin entre deux nœuds : 5), et dans 99 % des cas, 3 travailleurs intermédiaires sont suffisants (percentile 0.99 = 8, comme entre A et E, dans la figure ci-dessus).

Si l’on prend deux travailleurs (faisant partie de la composantes géantes, soit pour l’essentiel n’étant pas le seul salarié d’une entreprise) au hasard, il y a 59% de chances qu’ils aient un collègue en commun, en prenant la définition large de collègue, voulant dire “ayant eu un employeur en commun, mais pas nécessairement en même temps”.

Notons qu’une partie de ce qui explique ce “petit monde” est ce qu’on appelle les “super-connecteurs” : il s’agit de nœuds ayant un degré très élevé. Tous les enseignants (du même régime linguistique) sont par exemple employés par le même ministère.

Notons également que même si l’on s’intéresse à une période plus petite, la composante géante reste importante : si l’on ne considère que les relations de travail entre 2013 et 2017, la composante fera alors 6 253 490 nœuds, dont 5 907 213 travailleurs, soit 99% des 5 966 745 travailleurs actifs sur cette période-là. On descend à 96% en ne regardant que les relations de travail en 2017.

Requêtes Cypher

Autres composantes connexes

Le réseau complet de Dimona, sur base des relations de 2003 à 2017, est composé de 28 224 composantes connexes. Nous venons de voir que la très grande majorité des nœuds font partie de la même composante connexe.

À l’autre extrémité, nous avons un grand nombre de composantes connexes toutes petites : 22 013 d’entre elles sont composées de deux nœuds, donc un travailleur et un employeur. Ce qui veut donc dire que l’on a 22 013 travailleurs qui n’ont eu qu’un seul employeur durant les 15 ans de notre analyse, et dont ils ont été l’unique employé. On peut imaginer que pour beaucoup d’entre eux, il s’agit de personnes qui, au lieu de choisir un statut d’indépendant, ont préféré créer leur propre société pour s’y engager. Ceci pourrait être confirmé en croisant ces données avec celles de la Banque Carrefour des Entreprises, organisme officiel auprès duquel doivent s’inscrire toutes les entreprises (y compris ceux qui ne sont pas des employeurs, comme les indépendants, les professions libérales…), et y préciser le noms des fondateurs, gérants ou administrateurs.

On trouve également 4 300 partitions de taille 3 (deux employeurs et un travailleur, ou un employeur et deux travailleurs) et un peu plus de 1 100 partitions de taille 4.

Restent ensuite un peu moins de 800 partitions de taille variant entre 5 et 61.

Nous pouvons identifier quelques “patterns” :

• “Schéma en étoile” : un seul travailleur, et de 3 (121 fois) à 6 (3 fois) sociétés. Notons que l’on trouve aussi ce schéma dans la composante connexe géante : nous avons ainsi 25 travailleurs ayant été le seul travailleur de plus de 10 entreprises sur les 15 dernières années (mais ces travailleurs ont été également engagés par d’autres employeurs).
  Requête Cypher
  MATCH (n1:Company)--(p:People)
WHERE size((n1)--()) = 1
WITH p, COUNT(DISTINCT n1) as nb_comp WHERE nb_comp >= 10
RETURN p, nb_comp
ORDER BY nb_comp DESC
LIMIT 100
  
  Nous voyons principalement deux explications à ces étoiles :
  • “Faux indépendants” : schéma similaire à celui décrit plus haut, si ce n’est que la personne a ici choisi de créer plusieurs sociétés, sans jamais engager d’autre personnes qu’elle-même (et sans jamais, sur la période considérée, avoir travaillé pour un autre employeur).
  • “Salarié partagé” : l’observation d’un certain nombre de ces cas montre également des groupes d’entreprises dont l’essentiel de l’activité est basée sur des personnes non-salariées et qui se partagent un salarié pour accomplir des tâches administratives. On trouve ainsi beaucoup de fabriques d’églises, ou des syndics de copropriétés, mais également des sociétés créées par des indépendants, non par pour s’y engager eux-mêmes, mais pour y engager une personne à temps partiel.

• “Entreprise étrangère temporaire” : Une série importante de “clusters” nous faisant penser à un groupe de travailleurs étrangers, venus en Belgique pour créer une société, puis repartir peu de temps après. Le fait qu’il s’agisse de travailleurs “temporaires” explique qu’ils n’aient pas d’autres relations dans Dimona, leur historique de travail s’étant déroulé à l’étranger. Quelques éléments en attestent. On trouve :
  • Des schémas avec essentiellement des travailleurs étrangers : plus de 2000 clusters sans aucun travailleur ayant la nationalité belge,
  • 620 clusters avec aucun travailleur ayant un numéro NISS, mais uniquement un numéro BIS. Il s’agit donc de travailleurs temporaires. (cf explications dans notre premier article)
  • 224 clusters où il s’est écoulé moins d’un an entre le premier engagement et la fin du dernier contrat. Pour 320 cas, il y a eu moins de deux ans.
• “Travailleurs très fidèles” : Une quarantaine de cas d’entreprises avec entre 5 et 9 travailleurs, presque tous avec un numéro NISS. Nous sommes donc dans le cas d’entreprise avec un personnel très fidèle : sur 15 ans, aucun des travailleurs n’a eu d’autre employeur que celui-là.

Fidélité

Une partie des composantes connexes nous donnent des exemples d’entreprises avec un personnel très fidèle. Une autre façon de le calculer est de recherche des entreprises où il y a une longue période durant lequel tout le personnel qui a un jour été présent a travaillé simultanément. Autrement dit, entre l’engagement le plus tardif et le premier départ, il s’est écoulé une longue période.

On trouve par exemple 103 entreprises d’au moins 5 travailleurs où ce délai est de 10 ans, et 353 entreprises où ce délai est de 5 ans.

Requête Cypher

2. Détection de Communautés

En général, quand on observe un réseau, on constate qu’il n’est pas “uniforme” : il y a des “zones” plus denses, avec beaucoup de connexions entre les nœuds de ces zones, et il y a moins de connexions entre deux nœuds faisant partie de “zones” distinctes. Dans la terminologie de la théorie des graphes, on parle de “communautés”. Typiquement, si on regarde le réseau constitué de l’ensemble des connaissances d’une personne, où un lien entre deux personnes indiquent qu’elles se connaissent, on observera en général une série de communautés, correspondant à des groupes de la vie réelle par rapport à la personne dont on analyse le réseau : les membres de famille, les collègues, les camarades de classe … Plus de détails peuvent être trouvés dans ce blog.

Nous avons appliqué un algorithme de détection de communautés (méthode par propagation de labels) sur notre graphe, et avons regardé dans quelle mesure on pouvait caractériser les différentes communautés. Pour ce faire, nous avons examiné deux caractéristiques de chaque entreprise (la province de son siège social et son ou ses code(s) NACE), pour comparer la distribution de ces données au sein d’une communauté par rapport à la distribution pour l’ensemble de la population.

Nous constatons que la plupart des communautés détectées par l’algorithme ont un “comportement” assez éloigné de la moyenne nationale. Ce qui veut dire que les travailleurs, lorsqu’ils changent de travail, ont tendance à changer soit pour un employeur localisé dans la même province, soit travaillant dans le même secteur. Ce n’est en soi pas une découverte surprenante, mais l’analyse réseau permet de le formaliser.

Les données des 100 plus grosses communautés sont visibles dans ce document. On peut par exemple y voir que la plus grande communauté détectée (54.000 employeurs, 750.000 travailleurs) est composée très largement d’entreprises localisées en Flandre Occidentale. En effet, comme le montre le graphique ci-dessus, alors que 10% des entreprises en Belgique sont localisées dans cette province (colonne bleue), 71% des entreprises de la communauté concernées y sont. Dans le même ordre d’idées, la troisième communauté comprend trois fois plus d’entreprises de l’Horeca (Hotels, restaurants, cafés) que la moyenne nationale.

La 8^ème communauté, représentée ci-dessous, combine deux aspects : les 580 entreprises qui la composent sont quasi exclusivement localisée en Wallonie et à Bruxelles (soit les deux régions de Belgique où l’on parle majoritairement français), et travaillent dans le secteur de l’enseignement.

La suite…

Dans le troisième blog de cette série, nous examinerons deux notions : celle d’homophilie, et celle de projection. La première nous permettra de voir à quel point les travailleurs changent de région de travail ou de domaine d’activité. La seconde permettra de calculer un certaine forme de proximité entre deux travailleurs, au travers du nombre d’employeurs qu’ils ont eu en commun.

Dans notre travail au quotidien pour notre principal partenaire, l’Office National de la Sécurité Sociale belge, nous sommes amenés à traiter un certain nombre de bases de données, dont celle de Dimona (Déclaration Immédiate/Onmiddellijke Aangifte), application auprès de laquelle chaque employeur (y compris les administrations) en Belgique doit déclarer, au plus tard le jour de son engagement, quel salarié il compte employer, pour quelle période et pour quel type de travail. Il s’agit donc des travailleurs salariés et pas des indépendants.

Ce type de données se prête particulièrement bien à une modélisation de réseau : nous avons deux types de nœuds ou entités (travailleurs et employeurs), et des relations entre ces nœuds, correspondant aux déclarations. Dans le cas présent, une relation connectera toujours un travailleur et un employeur (et jamais deux travailleurs ou deux employeurs) : on parlera donc d’un réseau (ou graphe) biparti.

Disclaimer : il s’agit ici d’un exemple d’analyse rapide menée par un “data scientist”, spécialiste de l’analyse réseau, et pas d’un spécialiste du monde du travail ou de l’économie. Il ne s’agit en rien d’une analyse menée par ou pour l’ONSS.

Données et modèle

Pour les besoins de notre analyse, nous avons créé un modèle (anonymisé et simplifié) d’une partie de la base de données de Dimona dans une base de données orientée graphe (Neo4j). Les requêtes “Cypher”, langage d’interrogation de Neo4j, seront visibles optionnellement en cliquant sur les liens adéquats (cliquer ici pour tout ouvrir).

La base de données de production de Dimona est une base de données Oracle, comportant principalement trois tables : une décrivant les employeurs, une décrivant les travailleurs, et une pour les déclarations, correspondant à la relation entre un employeur et un travailleur. Sont également inclus les contrats d’intérim. Les deux premières tables nous permettront de créer les entités, la dernière les relations.

Pour les employeurs, nous gardons la province de son siège social, ainsi que son code NACEBEL de premier niveau, lettre entre A et U décrivant le code d’activité principale de la société. Cette liste est donnée dans la table ci-dessous, chaque société peut en avoir un ou plusieurs.

Liste des codes NACEBEL

Pour les travailleurs, nous utiliserons principalement la nationalité, et la nature du numéro national : chaque citoyen a besoin, pour pouvoir travailler en Belgique, d’un numéro d’identification de la sécurité sociale (NISS), parfois appelé “numéro national“. Lorsqu’un travailleur étranger arrive en Belgique, il se voit attribuer un numéro temporaire (numéro BIS), jusqu’à ce que sa situation soit considérée comme permanente (il reçoit alors le cas échéant un numéro NISS comme chaque citoyen Belge).

Concernant les relations, nous considérons les dates de début et, si elle est définie, de fin. Les déclarations concernant des contrats à durée indéterminée, tant qu’ils ne sont pas terminés, n’ont pas de fin renseignée dans Dimona. Nous gardons également  un “worker code”, code donné par l’administration indiquant un certain nombre de catégories. En voici quelques exemples :

• STU : travailleurs étudiants
• BCW : travailleurs du secteur de la construction (Build & Construction Workers)
• EXT : travailleurs occasionnels
• IVT : travailleurs en formation (Individual vocational training)
• OTH : autres

Nous avons considéré les relations de 2003 à 2017, ce qui nous fait une période de 15 ans. Nous avons donc ignoré les déclarations avec une date de fin d’activité antérieure au 1er janvier 2003, ou une date de début supérieure au 31 décembre 2017. Nous avons donc des relations ayant commencé avant 2003, mais ayant une date de fin après début 2003, ou pas de date de fin. Remarquons que la déclaration Dimona ne précise pas le régime de travail (temps plein ou temps partiel).

Pour les contrats d’intérim, on considère dans le modèle que l’employeur est la société où s’effectue le travail, et pas l’agence d’intérim.

Dans l’image ci-dessous, on considère un travailleur A, de nationalité française, ayant travaillé, comme apprenti (Worker code: IVT), auprès de l’entreprise B, de 2015 à 2017. Il y a été collègue avec C, Belge, qui y a d’abord travaillé les 3 premiers mois de 2015 comme étudiant, puis jusqu’à fin 2016 avec un contrat normal, avant de changer d’employeur pour aller travailler dès début 2017 auprès de D. B est une société ICT (NACE: J), et D un société commerciale (NACE: G).

Comptage

Une première analyse simple que l’on peut faire sur le graphe (ou réseau) décrit ci-dessus consiste à compter les nœuds qui le compose. On peut dans un premier temps compter les nœuds, en distinguant bien sûr les nœuds “Travailleurs” des nœuds “Employeurs”. On trouve, dans Dimona :

• 7 828 000 travailleurs
• 645 634 employeurs

Requêtes Cypher

Ce comptage reprend cependant la totalité des travailleurs et employeurs présent dans Dimona, même s’ils n’ont jamais travaillé ou engagé, ou s’ils ne l’ont plus fait depuis le début de la période que l’on considère (2003-2017). On peut s’intéresser au nombre de nœuds ayant ou moins une relation (c’est-à-dire les nœuds avec un degré supérieur ou égal à un, le degré d’un nœud désignant le nombre de relations auxquelles il est connecté), ce qui correspond aux travailleurs ayant eu un emploi durant la période, peu importe sa durée, ou aux employeurs ayant engagé du personnel :

• 7 604 515 travailleurs
• 611 646 employeurs

Requêtes Cypher

Comme expliqué plus haut, les relations ont un certain nombre d’attributs, dont les dates de début et de fin. On peut donc aisément compter les travailleurs ayant eu (au moins) un employeur durant un période déterminée [a, b]. Ils doivent donc avoir une relation dont :

• la date de début est inférieure ou égale à ‘b’ ;
• la date de fin est supérieure ou égale à ‘a’ ou bien nulle (pour les contrats à durée indéterminée).

Nous comptons alors :

• 4 918 234 employés pour l’année 2017 (même pour un jour) ;
• 4 334 252 employés durant le mois de décembre 2017 ;
• 4 276 094 employés au 1^er décembre 2017.

Requêtes Cypher

Ce comptage peut être fait mois par mois, et donner le graphique suivant :

Remarquez que le graphique n’a pas “0 travailleurs” comme base : cela permet de mieux observer la variabilité, mais peut quelque peu tromper l’impression de croissance. Le nombre de travailleurs est passé de 3.46 millions (janvier 2003), à 4.33 millions (décembre 2017), soit une progression de 25 %. En cliquant sur le graphique, vous obtiendrez une version démarrant à 0.

On constatera l’aspect périodique du tracé, avec un pic à chaque mois d’août. On peut, en décomposant les travailleurs en fonction du “worker code” de leur relations, obtenir le graphique suivant, qui montre que l’essentiel de la périodicité est imputable jobs étudiants (worker code STU), massivement disponibles en juillet et août, nettement moins durant le reste de l’année. La croissance globale est, elle, due à la croissante des relations “OTH”, largement majoritaires. On observe également une périodicité dans les emplois occasionnels (“EXT”), beaucoup exploités dans le tourisme, ou dans la collecte des fruits, deux secteurs plus actifs en été.

Notons qu’il s’agit du nombre de personnes ayant travaillé chaque mois : rien ne dit qu’ils ont travaillé tout le mois. Il se peut que le temps de travail global ait diminué, mais qu’il ait été réparti sur plus de travailleurs.

Degré

Dans un graphe, le degré d’un nœud est défini comme étant le nombre de relations liées à ce nœud. Une variante consiste à considérer le nombre de voisins au lieu du nombre de relations, ce qui peut différer s’il peut exister plusieurs arcs entre deux nœuds, typiquement parce qu’un travailleur, pour la même société, a travaillé avec plusieurs type de contrats différents. On parle alors de multi-graphe.

On va considérer ci-dessous cette seconde définition : le degré d’un travailleur indique donc le nombre de ses employeurs, et le degré d’un employeur indique le nombre de ses travailleurs.

Les employeurs

Si l’on regarde le nombre d’employés par employeur, on observe les éléments suivants :

• 136 868 entreprises ont eu, sur les 15 années considérées, uniquement un salarié. Dans de nombreux cas, il s’agit probablement d’indépendants ayant créé leur propre entreprise pour s’y engager, pour des raisons d’optimisation fiscale.
• 382 728 employeurs ont eu 10 travailleurs ou moins.
• 3 employeurs ont eu plus de 100 000 travailleurs (il s’agit de deux ministères et d’une grande chaîne de supermarchés).
• 96 employeurs ont eu plus de 10 000 travailleurs, 1 721 plus de 1 000 travailleurs.
• En moyenne, les employeurs actifs sur la période ont (eu) 33.56 travailleurs ; 50 % des entreprises ont (eu) 5 travailleurs ou moins (médiane).

Notons qu’il s’agit du nombre total : on ne fait donc pas la différence entre une petite entreprise avec un très grand turn-over et une grande entreprise avec des salariés très fidèles.

Les travailleurs

Si l’on regarde au contraire, le nombre d’employeurs par employé, et en excluant les contrats d’intérim, on observe que 3 123 405 travailleurs n’ont pas changé d’employeurs sur toute la période, soit 43 % de tous les travailleurs actifs durant cette période, et  21 % ont changé une fois d’employeur. Plus de détails dans le graphique ci-dessous :

À l’autre extrémité, toujours en excluant les contrats d’intérim, on observe un travailleur ayant eu … 110 employeurs ! 63 travailleurs ont eu 50 employeurs ou plus, 99% des travailleurs ont eu 11 employeurs ou moins.

Requête Cypher

En moyenne, sur les 15 années considérées, les travailleurs belges ont eu 2.59 employeurs différents. Une analyse par “worker code” (non détaillée ici) nous montre que certains secteurs (travail étudiant, travail occasionnel, construction…) génèrent plus de rotation, ce qui, dans certains cas, n’est pas surprenant.

Cumul d’emplois

Si l’on fait le même décompte sur un seul jour, on aura une image du nombre de personnes cumulant plusieurs emplois simultanés : si l’on considère le 1^er décembre 2017, 95.7% des travailleurs actifs à cette date n’ont qu’un seul employeur, 3.9 % en ont 2. On trouve encore quelques cas extrêmes : un travailleur a, à la date indiquée, 20 employeurs ; 67 en ont 10 ou plus.

Notons que ces comportement extrêmes sont susceptibles d’intéresser les administrations : il peut bien sûr s’agit de travailleurs “hyperactifs” ; il se peut aussi que les données soient de mauvaise qualité, et qu’une série de fins de contrat n’aient pas été signalées par les employeurs (pour le cas des emplois simultanés). Mais il peut aussi s’agir de comportement frauduleux, lié à de l’emploi fictif.

Requête Cypher

La suite…

Dans les deux prochains blogs, nous continuerons notre analyse du réseau du marché du travail en Belgique. Nous verrons dans un premier temps que l’écrasante majorité des salariés en Belgique sont en fait “collègues de (ex-)collègues de (ex-)collègues”, formant ainsi ce que nous appellerons une composante connexe géante. Nous examinerons les travailleurs et employeurs qui ne font pas partie de la composante géante. Nous verrons également qu’il est possible de détecter des “communautés” dans le réseau, et qu’elles ne sont pas homogènes. Nous verrons également qu’en général, les travailleurs qui changent d’employeur restent dans la même région géographique, et dans le même secteur d’activité.

Certaines parties de cet article, plus techniques, seront masquées. Si les détails vous intéressent, il vous suffira de cliquer sur les liens « Cliquer ici pour plus de détails », ou de cliquer ici pour montrer toutes les parties d’un seul coup.

Supposons qu’un organisme public soit responsable de la gestion de la sous-traitance entre entreprises, et que, chaque fois qu’une entreprise fait appel à un sous-traitant, elle doive le déclarer auprès de cet organisme. Les données issues de ces déclarations peuvent alors être vues comme un graphe, dans lequel un nœud représente une entreprise, et une relation entre deux nœuds A et B, le fait que B est un sous-traitant de A. Si A sous-traite auprès de B, et B auprès de C, on notera cela de la façon suivante (en s’inspirant de la notation de Cypher, langage de Neo4j) :

(A)-->(B)-->(C)

Imaginons une loi (un peu simpliste et fantaisiste) disant qu’une entreprise ne peut pas être sa propre sous-traitante, ni directement, ni indirectement. Les structures suivantes seraient donc considérées comme « frauduleuses » :

(A)-->(A)
(A)-->(B)-->(C)-->(A)

Du point de vue de la théorie des graphes, on veut en fait s’assurer qu’il n’y a pas de cycle dans le graphe de description des sous-traitances, graphe étant dirigé, puisque les arcs ont une direction. On parle dès lors de « Graphe Dirigé Acyclique » (DAG). Le schéma ci-dessous montre une structure acceptable, dans laquelle aucune entreprise n’est son propre sous-traitant, même indirectement.

En Cypher (dont la syntaxe a été brièvement présentée dans notre article précédent), en supposant que les entreprises soient de type « Company », et les relations de type « Subcontractor », on pourra écrire la requête suivante, qui retournera une entreprise, et le cycle dont elle fait partie :

(1)    MATCH p=(a:Company)-[:Subcontractor*]->(a)
       RETURN a, p

Pour des raisons de performances, il sera souvent préférable de limiter la longueur des cycles : (a:Company)-[:Subcontractor*..5]->(a).

Qualité des données

Supposons maintenant que le système de déclaration ne soit pas très contraignant, et que, quand une entreprise déclare une sous-traitance, elle ne soit pas obligée de donner un identifiant officiel de l’entreprise en question (un numéro d’entreprise ou d’employeur attribué par l’état), mais puisse se contenter d’en donner le nom, et éventuellement l’adresse. On peut donc avoir une situation dans laquelle (A) déclare correctement sa sous-traitance vers (B) (c’est-à-dire avec un numéro d’entreprise officiel), idem pour (B) envers (C), mais par contre, (C) déclare sa sous-traitance vers (A) sans en préciser l’identifiant, mais uniquement le nom. On aura dans la base de données associée à la déclaration, deux nœuds, avec les attributs suivants :

• (A) : ID : 12345, Nom : « Mon Entreprise SA »
• (A’) : ID : <vide>, Nom : « Mon Entreprise SA »

L’organisme récoltant les données n’a ici aucun moyen de s’assurer que les entreprises (A) et (A’) sont en fait la même entreprise. Il existe des multitudes de synonymes d’entreprise. On trouve des « Coiffeur Rolland » dans bon nombre de villes, et les boulangeries « La baguette dorée » sont légion.

La cycle ci-dessus devient alors une chaîne (non fermée) : (A)–>(B)–>(C)–>(A’) , et la recherche évoquée plus haut ne permet plus de détecter le comportement frauduleux.

L’approche classique

Une approche classique de ce problème consiste à utiliser des outils de « Data Quality » (comme l’outil open-source OpenRefine, ou le logiciel commercial Trillium aux fonctionnalités beaucoup plus avancées), pour, en fonction de critères définis, fusionner certains enregistrements de la base de données. On peut par exemple décider que si on trouve deux enregistrements avec exactement le même nom d’entreprise, se trouvant dans la même rue, on les fusionne en considérant qu’il s’agit de la même entreprise. On peut par ailleurs décider que si les deux noms sont similaires, mais ont la même adresse, alors on les fusionne également.

Les outils, en particulier les suites professionnelles comme Trillium, permettent de définir finement le degré de proximité que l’on acceptera entre deux dénominations ou adresses (ou, plus généralement, toute information) pour les considérer comme « identiques » (on ne va pas uniquement considérer des chaînes de caractères exactement identiques). Par ailleurs, nous n’évoquons ici que la problématique de la détection de (présomption de) doublons : le domaine de la « Data Quality » s’intéresse à bien d’autres aspects : incohérence de données, comparaison entre différentes sources, profilage des données, standardisation…

Notons qu’on va souvent effectuer cette fusion non pas dans les données de production, mais dans une copie servant à faire des analyses et des recherches de fraude.

Mais cette approche, très efficace dans de nombreuses situations, a principalement deux limites :

• Elle permet de fusionner des informations tabulaires plates (une entreprise avec un nom, une adresse, éventuellement une catégorie d’entreprise, le nom du gérant, voire des dates de création ou autres événements), mais est plus complexe pour des structures plus élaborées. On s’en sort encore sans trop de dommages si on considère que chaque entreprise peut avoir plusieurs adresses (correspondant à plusieurs implantations, ou à l’historique du siège principal), mais si l’on veut considérer, en l’absence d’adresse, les travailleurs communs aux « deux » entreprises, ou les administrateurs (ou autres client, fournisseur…), cette approche relativement statique n’est plus tenable.
• Elle impose de choisir, avant l’analyse des données, les critères de fusion. Or il s’avère parfois utile de faire ce choix plus tard dans l’analyse, soit parce que, en fonction de l’analyse, on veut être plus ou moins stricte sur la façon de faire cette fusion, soit parce que, dans une analyse particulière, on veut identifier un schéma passant par plusieurs « chemin de duplicatas », n’ayant pas tous le même degré de certitude.

Nous proposons dès lors une approche qui combine à la fois les possibilités offertes par les bases de données orientées graphes (« Graph Databases ») et les outils de gestion de qualité de données (« Data Quality tools »).

Une autre approche

L’approche que nous décrivons ici permet de traiter les doublons d’entreprises, mais une approche très similaire pourra être utile pour détecter les doublons de personnes, ou de toute autre entité.

La première étape de notre approche consistera à identifier les entreprises dont le nom est identique, ou similaire (selon un niveau d’exigence que l’on peut définir). Dans cette première étape, on ne considère que le nom de l’entreprise, et pas les autres attributs (adresses, travailleurs…)

Cliquer ici pour plus de détails à propos de cette première étape.

Après ces étapes de nettoyage, toutes les entreprises (ou plus précisément tous les enregistrements d’entreprise) dont le nom est considéré comme identique ou presque, seront regroupées (mais pas fusionnés). Dans notre base de données, on créera alors un nœud d’un nouveau type (nous avions déjà implicitement un type de nœud « Company »), que nous appellerons « Denomination_group »

Gestion des adresses

En parallèle avec cette gestion de dénomination, il s’agira également de traiter les adresses dont on dispose pour une entreprise. Il peut s’agir d’une seule adresse, mais également de plusieurs adresses par entreprise, soit parce que celle-ci dispose de plusieurs sites, soit parce que l’on dispose de l’historique des adresses.

Cliquer ici pour plus de détails à propos de la qualité des adresses

Une fois les adresses normalisées, on va considérer dans notre base de données un nœud par rue, et un lien (avec en attribut le numéro de la boite) entre une entreprise et la rue où celle-ci a un siège.
Nous pourrions éventuellement considérer un nœud par adresse (et non par rue), mais cela fera exploser le nombre de nœuds, et donnera moins de souplesse par la suite, comme nous le verrons plus loin.

Autres liens

On peut imaginer qu’un organisme dispose d’autres informations. Par exemple, un système dans lequel les entreprises doivent déclarer leurs travailleurs, et où le contrôle au niveau de l’entreprise est faible (ce qui est typiquement le cas des travailleurs « détachés », ayant leur employeur dans un pays A, mais travaillant – généralement temporairement – dans un pays B. Ils doivent alors être déclarés dans le pays B, mais qui peut alors difficilement imposer un système d’identification standardisé).
Dans de tels cas, on pourrait utiliser les travailleurs comme entités supplémentaires. On peut aussi se servir des administrateurs ou des gérants si l’on dispose de ce type d’information.

Combiner noms et adresses

Considérons maintenant plusieurs enregistrements dans notre base de données de sous-traitance. Nous supposons que « Ma Société » a déménagé, on trouve donc des données à deux adresses différentes :

On aura dans notre base de données graphes trois nœuds « Company » : (-, « Ma société S.A »), (-, « MA SOCIETE »), et (1234, « Ma Société »), et deux rues : « Avenue Fonsny » et « Boulevard Industriel » (nous supposons que les adresses ont été normalisées au préalable), comme on peut le voir dans la figure ci-dessus.

Les versions nettoyées des trois sociétés donnent la même chaîne de caractères, et seront regroupées autour d’un nœud « Denomination_group », comme le montre le schéma ci-dessus.

On pourra maintenant rechercher un cycle entre deux compagnies A1 et A2, avec de forts soupçons de doublons.

(2)    MATCH
      (A1:Company)-[:Subcontractor*]->(A2:Company),
      (A1)-->(:Denomination_group)<--(A2),
      (A1)-->(:Street)<--(A2)
      RETURN …

La première ligne indique donc qu’il y a un chemin de sous-traitance entre A1 et A2 ; la seconde que A1 et A2 portent le même nom (après nettoyage, ou éventuellement après application d’un algorithme tel que la distance de Levenshtein), et la troisième que A1 et A2 sont renseignées dans la même rue.

Dans le schéma ci-dessus, la requête (1) plus haut aurait retourné la chaîne

(C1)–>(C2)–>(C3)–>(C1).

La requête (2) retournera quant à elle

(C10)–>(C3)–>(C1)–>(C2)–>(C9),

avec D1 comme nœud « Denomination_group » et S1 comme « Street », A1 et A2 correspondant respectivement à C10 et C9.

Cliquer ici pour plus de détails à propos des adresses identiques

(2bis) MATCH
      (A1:Company)-[:Subcontractor*]->(A2:Company),
      (A1)-->(:Denomination_group)<--(A2),
      (A1)-[str1:Address]->(:Street)<-[str2:Address]-(A2)
      WHERE str1.NUMBER = str2.NUMBER
      RETURN …

On peut aussi imaginer que l’on va considérer comme fortement suspect deux entreprises de même nom, ayant un même sous-traitant (sans considérer les adresses, qui pourraient être souvent manquantes) :

(3)     MATCH
       (A1:Company)-[:Subcontractor*]->(A2:Company),
       (A1)-->(: Denomination_group)<--(A2),
       (A1)- [:Subcontractor]->(B:Company)<- [:Subcontractor]-(A2)
        RETURN …

Cette requête retournera alors

(C6)–>(C1)–>(C2)–>(C3)–>(C4),

C5 correspondant à B, et D3 au « Denomination_group ».

Cliquer ici pour voir comme gérer plusieurs duplicatas

(4)     MATCH
       (A1:Company)-[:Subcontractor*]->(B1:Company) -->(:Duplication_group)
           <-- (B2:Company)-[:Subcontractor*]->(A2:Company),
       (A1)-->(:Duplication_group)<--(A2),
       (A1)-->(:Street)<--(A2)
       RETURN …

Technique hybrides

Plutôt que de gérer la totalité des doublons dans la base de données graphes, en se servant uniquement des Data Quality tools pour corriger les adresses et détecter les homonymes d’entreprises, on peut aussi considérer une technique hybride. On peut par exemple considérer une première phase, basée sur un Data Quality tool, de fusion de tous les enregistrements qui constituent à coup sûr un doublon (ou avec un niveau de certitude choisi) : par exemple, exactement la même dénomination, exactement la même adresse (les outils avancés permettent bien sûr de faire des choses bien plus complexes que ceci, gérant des dénominations similaires plutôt qu’exactes). Nous avons par exemple dans une base de données que nous exploitons plus de 1000 fois la même entreprise décrite, avec le même nom et la même adresse (mais où le numéro d’entreprise n’a pas été déclaré).

Les données ainsi « compactées » pourront alors être intégrées dans une base de données graphe, dans laquelle on recherchera des structures de doublons plus complexes (en se servant également d’autres informations, comme les travailleurs ou mandataires communs, ou plus généralement le voisinage), ou plus faible.

On pourrait aussi utiliser les techniques décrites ci-dessus pour fusionner, directement dans la base de données graphe, tous les nœuds considérés comme des doublons. Cela permettra de simplifier les requêtes par la suite, tout en permettant de garder une certaine souplesse : on fusionnera uniquement les cas « sûrs » (selon des critères que l’on devra définir), et laissera la possibilité de considérer des doublons moins certains dans les requêtes.

Conclusion

Notre expérience dans la lutte contre la fraude nous a montré ces dernières années qu’il est primordial de tenir compte de la qualité des données sur lesquelles on travaille. Mais elle nous a aussi montré que, dans le cadre d’un travail de « datamining », traiter la totalité de la problématique de qualité en amont, dans une phase de pré-traitement, n’est pas toujours optimal. Le degré de certitude exigé peut varier d’une analyse à l’autre et une certaine souplesse peut être nécessaire dans des phases plus avancées.

Néanmoins, en aucun cas il ne sera envisageable de se passer des outils de Data Quality :

• Nous n’évoquons ici que l’aspect « détection de (présomption de) doublons » ; les outils de Data Quality ont de nombreuses autres fonctionnalités indispensables.
• Notre approche suppose que l’on est capable de déterminer que deux dénominations d’entreprises sont « considérées comme identiques », même s’il y a des différentes orthographiques ou syntaxiques. Si l’on veut pour ce faire utiliser des méthodes plus avancées que des simples distances de Levenshtein, l’utilisation d’outil adapté sera nécessaire.
• Nous supposons également que nous sommes capable d’identifier que deux adresses sont identiques, ce qui est bien plus complexe que de vérifier la similitude entre deux chaînes de caractères. Pour cette tâche, l’utilisation d’outils disposant de base de connaissance sera indispensable.

L’approche que nous proposons ici permet de combiner, pour la problématique du dédoublonnage et dans le cadre d’une analyse effectuée sur une base de données graphe, travail partiel de Data Quality en pré-traitement et analyse métier tenant compte des résultats obtenus. L’idée générale sera d’appliquer le principe de « Keep the power where it belongs » : combiner de façon optimale un outil de Data Quality (pour la comparaison de contenus textuels) et Graph Database (pour l’exploitation des relations).

En appliquant cette méthodologie sur des cas concrets, de multiples cas problématiques (c’est-à-dire des suspicions de fraude) ont pu être trouvés et soumis à divers services d’inspection, que des analyses plus classiques n’avaient jusqu’ici pas permis de déceler.

Base de données orientée graphe

Les bases de données orientées graphe (ou Graph DB) placent les relations au cœur du problème, et plus particulièrement le parcours de ces relations. Elles ont pour but à la fois d’éviter à l’utilisateur (plus précisément à la personne interrogeant la base de données) de se préoccuper de la façon dont sont structurées et implémentées les relations, et d’offrir un mécanisme plus efficace que les JOIN pour parcourir les relations.

Un des leaders des bases de données orientées graphe est Neo4j². Dans la suite de cet article, nous utiliserons son langage de requête, “Cypher” (proche de SQL).

Syntaxe : plus proche du modèle

Si nous reprenons l‘exemple de l’article précédent, avec les travailleurs et les entreprises, nous pourrions naturellement représenter notre modèle comme dans la figure ci-contre. Deux “nœuds” (ou entités), l’un de type “Worker”, l’autre de type “Company”, sont liées par une relation “WORKS_FOR”. Les nœuds ont des attributs (ici : “Name”), les relations peuvent également en avoir (non représentées dans le schéma). Dans le langage “Cypher”, la requête SQL décrite dans l’article précédent permettant de retrouver les travailleurs employés par la compagnie “Smals” pourra s’écrire de la façon suivante :

MATCH (w:Worker)-[:WORKS_FOR]->(c:Company {c.Name:"Smals"})
RETURN w.Name

Dans cette requête, les nœuds sont symbolisés par des parenthèses, alors que les relations le sont par des crochets au milieu d’une flèche. Nous précisons ici que nous recherchons les travailleurs (w), ayant une relation de type “WORKS_FOR” avec une compagnie (c) dont l’attribut “Name” vaut “Smals”. Remarquons que nous devons juste préciser le type de la relation, et non comment elle est implémentée, contrairement aux requêtes SQL décrites précédemment. Par ailleurs, ce modèle vaut aussi bien pour le cas où un travailleur ne peut être employé que par une entreprise que pour le cas où il peut travailler pour plusieurs sociétés.

Nous avons donc une requête très proche du schéma métier que l’on a dessiné. En exagérant à peine, il suffit d’avoir dessiné au tableau la requête que l’on veut exécuter pour pouvoir directement l’écrire.

Autre exemple

Considérons un exemple un petit peu plus complexe, dans lequel nous fusionnons les deux exemples de l’article précédent : nous avons donc des personnes, des compagnies, des relations de travail entre personnes et compagnies, ainsi que des relations d’amitié entre les personnes.

Si nous voulons connaître la liste de collègue de Bob que celui-ci apprécie, nous écrirons ceci :

MATCH
(bob:Person {Name:"Bob"})-[:LIKES]->(colleague:Person),
(bob)-[:WORKS_FOR]->(:Company)<-[:WORKS_FOR]-(colleague)
RETURN colleague.Name

La première partie de la requête cherche une relation de type “LIKES” entre un nœud, de type Person (dénommé “bob” dans la requête), dont l’attribut “Name” vaut “Bob”, et un autre nœud de type Person (dénommé “colleague”). Grâce à la seconde partie, nous ne considérons ce nœud “colleague” que si l’on trouve deux relations “WORKS_FOR”, liant “bob” et “colleague” à une même compagnie.

Si l’on veut maintenant plutôt savoir quelles sont les personnes qui aiment Bob dans sa société, on changera simplement “-[:LIKES]->” par “<-[:LIKES]-“, sans devoir, comme c’était le cas avec SQL, mettre à jour une série de clés. Et si le sens de la relation importe peu, on écrira simplement “-[:LIKES]-“.

On peut également s’intéresser à des chemins de plus d’une relation : les amis des amis seront dénotés “-[:LIKES*2]-” ; si l’on veut un chemin de longueur entre 4 et 6, on écrira “-[:LIKES*4..6]-“, et si la longueur importe peu, “-[:LIKES*]-“.

Gestion des clés

Les requêtes Cypher décrites ci-dessus ne comprennent aucune clé, qu’elle soit primaire ou étrangère. La gestion des clés ne sert en effet souvent qu’à gérer les relations, et cette gestion est complètement déléguée à la base de données. On peut bien sûr avoir des clés “métier” : identifiant national, numéro de TVA, numéro d’employé… mais elles seront alors traitées comme les autres attributs.

Chaque attribut, comme dans une base de données relationnelle classique, pourra à la demande, recevoir une contrainte d’unicité (pour les clés métier), ou être indexée, pour une recherche rapide (comme typiquement pour l’attribut “Name” décrit ci-dessus). Il n’y aura par contre pas lieu de décrire des contraintes d’intégrité référentielle, (permettant dans une base de données relationnelle de s’assurer qu’une clé étrangère existe bien comme clé primaire de la table référencée), ni pour le concepteur de la base de données, ni pour le développeur de requête.

Un parcours plus efficace

L’implémentation du moteur est ici très différente du cas de la base de données relationnelle. Reprenons la requête évoquée plus haut :

MATCH (w:Worker)-[WORKS_FOR]->(c:Company {c.name:"Smals"})
RETURN w.name

Une fois qu’on a trouvé le nœud “Smals” (grâce à un index, typiquement), celui-ci contient directement une liste de pointeurs, lui permettant de trouver les nœuds “Worker” concernés dans un temps qui ne dépendra pas de la taille de la base de données, mais uniquement du nombre de nœuds directement voisins. Le parcours d’index nécessaire pour un “JOIN” classique est donc évité.

C’est grâce à ce mécanisme d’arithmétique de pointeur qu’une requête Cypher peut être exécutée beaucoup plus rapidement qu’une requête SQL classique comprenant un certain nombre de “JOINs“.

Certains auteurs considèrent par ailleurs que c’est cette caractéristique qui définit une base de données orientée graphe : dans une telle base de données, chaque nœud contient une référence qui permet d’accéder directement à tous ses voisins.

Chez eBay, qui utilise Neo4j pour un système de routage de colis, Volket Pacher (Senior Developper) explique :

“We found Neo4j to be literally thousands of times faster than our prior MySQL solution, with queries that require 10-100 times less code. Today, Neo4j provides eBay with functionality that was previously impossible.”

Des recherches ont été menées^2,3 pour comparer les performances entre Neo4j et une base de données relationnelle, dans le cas de l’exploration d’un réseau d’amitiés, comme présenté ci-dessus. Pour un réseau d’un million de nœuds, en moyenne 50 voisins par nœud et profondeur de 2 (amis d’amis), les performances des deux systèmes étaient comparables. Pour une profondeur de 3, les 30 secondes nécessaires au RDBMS ont été réduites à 170 millisecondes avec Neo4j. Il n’était donc plus envisageable d’utiliser le RDBMS dans un système interactif, alors que ça le restait pour Neo4j.

Pour une profondeur de 4, la base de données orientée graphe a permis de passer de 25 minutes à 1,3 secondes.

Notons que cette amélioration notable de performances dans certaines circonstances ne se fait pas au prix de la cohérence de la base de données : Neo4j garantit en effet les propriétés ACID.

Tout n’est pas rose

Au vu de ce qui est dit ci-dessus, doit-on tout simplement abandonner les bases de données relationnelles au profit des bases de données orientées graphe ? Certainement pas. Les Graph DB ont bien sûr quelques inconvénients. En voici quelques-uns (liste non exhaustives) :

• Les Graph DB n’ont pas encore atteint la maturité des RDBMS : l’offre de produit est nettement plus réduite, la communauté également. La robustesse ou la haute disponibilité doivent encore faire leur preuve.
• D’autres modèles de bases de données alternatives aux RDBMS, comme les bases Orienté Objets, un temps très à la mode, ne sont pas parvenu à s’imposer. Rien ne dit que les Graph DB pourront faire mieux.
• Pour des recherches (“Trouver toutes les entités de type T”) ou des agrégations (“Quel est le salaire moyen par province”), une Graph DB ne sera pas efficace. Idem pour appliquer une même transformation à toutes les lignes d’une table.
• Il faut être très attentif à l’explosion combinatoire. Par exemple, si l’on demande tous les chemins possibles entre deux nœuds, il ne faut pas grand chose pour que le nombre de ces chemins explose.
• Neo4j repose sur le principe que chaque nœud peut avoir des attributs différents, déterminés à la création du nœud. Il est donc vite arrivé de faire une faute de frappe, et d’avoir deux noms d’attributs légèrement différents, et du coup inutilisables.

RDBMS ou Graph DB ?

Il existe probablement peu de situations dans laquelle une base de données orientée graphe pourra être la seule base de données d’une application. Une cohabitation sera dans la plupart des cas l’option la plus viable. Même Neo4j ne conseille pas nécessairement d’envisager un environnement 100% Graph DB. Trois scenarii principaux peuvent se présenter :

1. Les données sont intimement connectées, et la plupart des requêtes concernent des parcours de relations. Dans ce cas très théorique seulement, une base de données orientée graphe unique peut s’envisager.
2. Certaines données sont intimement connectées, mais pas toutes. On peut alors envisager de gérer la partie “connectée” dans une Graph DB. L’application interroge alors la Graph DB avec Cypher, et la RDBMS avec SQL.
3. On peut également envisager une duplication complète synchronisée. En fonction des requêtes, l’application peut alors choisir soit Cypher, soit SQL.
   Un exemple classique consisterait à avoir toutes les données transactionnelles de production dans une RDBMS, et tout ce qui permet de faire des analyses (statistiques, recherche de fraudes, recommandations…) dans une copie “Graph DB” en lecture seule.

Dans la plupart des cas, la question ne sera donc pas “RDBMS ou Graph DB”, mais plutôt “RDBMS et Graph DB”. La difficulté, que ça soit à la conception du système ou lors d’une migration, sera de déterminer le terrain de chacun.

Conclusions

Si les bases de données orientées graphe n’ont pas vocation à remplacer les bases de données relationnelles dans toutes les circonstances, il existe de nombreuses situations où elles peuvent avoir un grand intérêt, seule ou en complément. En particulier quand on se focalise sur les relations qui existent entre des entités de type différent, plutôt qu’entre les attributs de ces entités.

Le champ d’application des Graph DB est bien plus large que l’analyse ou la gestion des réseaux sociaux ; systèmes de recommandation en temps-réel, Master Data Management, détection de la fraude, gestion des infrastructures IT et des réseaux, sont autant de secteurs dans lesquelles des logiciels tels que Neo4j (mais également OrientDB, ou, dans une moindre mesure FlockDB) s’avèrent particulièrement efficaces.

L’adoption d’une base de données orientée graphe demande en général de penser ses données d’une façon complètement différente, mais souvent plus intuitive et plus proche de la réalité. La migration vers une Graph DB ne s’avère par toujours rentable, mais il serait judicieux, quand un nouveau projet démarre, d’au moins se demander si une base de données relationnelle est bien la solution la plus appropriée.

Références

1. Graph Databases, New opportunities for connected data ; Ian Robinson,
   Jim Webber & Emil Eifrem ; O’Reilly, 2015
2. www.neo4j.com
3.  Neo4j in Action. Aleksa Vukotic and Nicki Watt, Mannings, 2015.

Les bases de données relationnelles servent à représenter des relations. Cette affirmation peut sembler un euphémisme. Pourtant, à y regarder de plus près, les choses ne sont peut-être pas si évidentes. Essayons de comprendre pourquoi au travers de quelques exemples simples.

Bases de données relationnelles et relations

Supposons d’abord que l’on souhaite représenter des travailleurs, et les entreprises pour lesquelles ils travaillent, en supposant dans un premier temps qu’un travailleur ne travaille que pour une seule entreprise. Une modélisation relationnelle simple consistera à utiliser deux tables : une première que nous appellerons “Workers”, et une seconde “Companies”. Typiquement, les deux tables posséderont une “clé primaire” (primary key) permettant d’identifier chaque ligne de façon unique (“ID” dans le schéma ci-contre). Chaque table possédera également des attributs tels que “Name”, ou des identifiants nationaux. Pour savoir quelle entreprise emploie un travailleur en particulier, il conviendra de placer une clé étrangère (foreign key) dans la table Workers, faisant référence à la clé primaire de la table Companies (Employer_id dans notre exemple).

Dans ce premier schéma, on distingue bien deux types d’entité (à savoir des travailleurs et des entreprises), mais ce qui les lie est un attribut (“Employer_id”), qui n’est pas distinguable des autres attributs, tels que “Name”. Ce qui fait que cet attribut “joue le rôle d’une relation”, c’est que lorsque l’on exécutera une requête SQL, on précisera dans le “JOIN” quels sont les attributs à lier. Par exemple, pour obtenir la liste des employés de la société “Smals”, on écrira :

SELECT Workers.Name
FROM Workers
JOIN Companies
ON Workers.Employer_ID = Companies.ID
WHERE Companies.Name = 'Smals'

La base de données elle-même, mise à part éventuellement la définition de contraintes d’intégrités (optionnelles) lorsqu’elles sont disponibles, n’a pas “conscience” de l’existence de la relation. C’est au développeur de l’application (et non au concepteur de la base de données) de préciser dans chaque requête, d’une part quelle est la structure de la table (JOIN ... ON), d’autre part la sélection qu’il désire obtenir (WHERE ...).

Supposons maintenant qu’un travailleur puisse travailler pour plusieurs employeurs (on veut donc une relation “many-to-many”). Ou bien que l’on souhaite ajouter des attributs à la relation de travail (date de début, …). Le modèle ci-dessus ne tient plus, et il faut rajouter une “table de jointure” (“join table“) que nous appellerons “Works_for”. La structure est alors représentée par le schéma ci-contre. Nous avons donc maintenant deux tables qui décrivent des entités (Workers et Companies), et une table qui décrit une relation (Works_for). Fondamentalement, mise à part l’utilisation qu’on en fait, rien ne permet de distinguer les tables qui jouent le rôle d’entité, de celles qui jouent le rôle de relation. En général, les tables représentant des entités peuvent être caractérisées par un nom commun (personne, société, facture, produit…), alors que les tables représentant des relations seront plus caractérisées par des verbes (travaille pour, achète, contient…).

Le requête ci-dessus devient encore un peu plus complexe :

SELECT Workers.Name
FROM Workers
JOIN Works_for
ON Workers.ID = Works_for.Worker_ID
JOIN Companies
ON Works_for.Company_ID = Companies.ID
WHERE Companies.Name = 'Smals'

On voit donc avec ces deux exemples que dans une base de données relationnelle, une relation peut être représentée de deux façons différentes :

• Soit en détournant le rôle d’un attribut, en transformant sa fonction “caractérisante” pour lui donner une fonction “relationnelle”,
• Soit en détournant le rôle d’une table, en transformant sa fonction “entité” au profit d’une fonction “relationnelle”.

Dans les deux cas, ce n’est pas le concepteur de la base de données qui assure les relations (bien qu’il puisse, optionnellement, définir les relations possibles via les contraintes d’intégrité), mais bien le développeur de requêtes SQL. Par ailleurs, le modèle relationnel requiert bien souvent une table distincte pour chaque type de relation.

En termes de complexité, pour obtenir le résultat ci-dessus, le moteur du RDBMS doit d’abord trouver l’entrée dans la table “Companies” dont le nom est égal à “Smals”, dont il obtient l’ID. Il va ensuite rechercher dans la table “Works_for” la ou les entrées ayant l’attribut “Company_id” correspondant à l’ID trouvé ci-dessus, ce qui peut se faire, grâce à un index, dans un temps logarithmique par rapport au nombre d’entrées dans la table. Ensuite, il doit à nouveau chercher tous les travailleurs correspondant aux entrées qu’il vient de trouver, au prix d’une nouvelle recherche logarithmique. Le temps de réponse de la requête augmentera donc en fonction de la taille de données.

Récursivité

Lorsque l’on s’intéresse à des relations exprimant plus un réseau qu’une hiérarchie, comme par exemple des relations d’amitiés (relations) entre des personnes (entités), ou des routes (succession de relations) empruntées par des données sur un réseau d’ordinateurs (entités), les choses se compliquent nettement si l’on désire utiliser une base de données relationnelle.

Prenons un exemple simple dans lequel des personnes sont liées par des liens d’amitié (il pourrait s’agir d’ordinateurs et des connexions réseaux, de packages Java et des dépendances…). On veut représenter le schéma suivant, dans lequel une flèche entre Bob et Alice indique que Bob aime Alice, mais que la réciproque n’est pas vraie.

Une représentation classique relationnelle consistera à considérer une table “People”, avec un attribut “Name”, et une clé primaire “ID”, et une table de jointure “Likes”, avec deux clés étrangères Liker_ID, Liked_ID, indiquant qui (Liker_ID) aime qui (Liked_ID). Si l’on veut répondre à la question toute simple “Quelles sont les personnes que Bob aime” (Alice et Charline, en l’occurrence), il faudra écrire la requête suivante :

SELECT p1.Name
FROM People p1 JOIN Likes 
     ON Likes.Liked_ID = p1.ID
JOIN People p2
     ON Likes.Liker_ID = p2.ID
WHERE p2.Name = "Bob"


Dans cette requête, deux lignes (la première et la dernière) indiquent ce que le développeur veut réellement, les quatre autres précisent comment la relation est structurée dans la base de données.

Pour retrouver la réciproque, à savoir “Qui aime Bob ?”, il faudra modifier une série d’éléments de la requête, pour inverser les relations considérées.

Si l’on voulait suggérer à Bob de nouveaux amis, un système de recommandation classique chercherait à lui présenter les personnes qu’aiment les personnes que Bob aime, sur le principe de “les amis de mes amis sont mes amis”. Une relation d’amitié de degré 2, en quelque sorte. La question, en l’apparence toute simple, nécessite une requête particulièrement difficile à lire, et donc à vérifier ou à maintenir :

SELECT p1.Name
FROM People p1 JOIN Likes l1 
   ON l1.Liked_ID = p1.ID
JOIN Likes l2 
   ON l1.Liker_ID = l2.Liked_ID
JOIN People p2
   ON l2.Liker_ID = p2.ID
WHERE p2.Name = "Bob" AND p1.ID<>p2.ID

À nouveau, deux lignes (la première et la dernière) concernent le développeur de l’application ; toutes les autres devraient principalement être de la responsabilité du concepteur de la base de données (en tout cas si l’on considérait que celle-ci devait en effet gérer les relations).

Ce genre de requête ne pourrait tout simplement plus se faire raisonnablement si la liste des utilisateurs contenait plusieurs millions de personnes et que l’on voulait s’intéresser aux amitiés de degré 4 ou 5. Certaines bases de données incluent certes la syntaxe non-standard “CONNECT BY”, comme par exemple Oracle, mais celle-ci, si elle simplifie bien l’écriture de la requête, ne simplifie en rien la complexité sous-jacente de l’exécution de la requête.

Une problématique très similaire se présente si l’on voulait répondre, dans l’exemple employeur-travailleur précédent, à la question, à nouveau relativement simple : “donner la liste de tous les anciens collègues des travailleurs d’une entreprise X” : une succession de JOINs et de multiples passages par la table “Works_for” seront nécessaires pour trouver l’entreprise de départ, tous ses travailleurs, tous les anciens employeurs de ces travailleurs, et puis enfin les travailleurs de ces employeurs.

Bases de données orientées graphe

Les systèmes de gestion bases de données relationnelles (RDBMS) sont matures, très performants dans la plupart des cas, et ont largement fait leur preuve depuis 30 ans. Il n’y a aucun doute sur le fait qu’elles géreront encore à juste titre la grande majorité des données dans les années à venir. Mais elles connaissent un certain nombre de limitations, et une nouvelle famille de bases de données, dites NoSQL (pour Not Only SQL) essaye depuis quelques années de répondre aux faiblesses des RDBMS. La famille NoSQL se divise principalement en quatre sous familles : “Key-value”, “Column”, “Document”, et “Graph databases”. C’est cette dernière famille qui nous intéresse ici, et qui a émergé sur le constat suivant :

“Facebook, for example, was founded on the idea that while there’s value in discrete information about people—their names, what they do, etc.—there’s even more value in the relationships between them.”¹

Les bases de données orientées graphes (ou graph databases), qui s’intéressent à la modélisation de données dans lesquelles les relations sont au cœur du métier, ont un double objectif :

1. Offrir un langage de requêtage (querying language) dans lequel le développeur décrit les relations qu’il veut rechercher, sans devoir se préoccuper de la façon dont ces relations sont implémentées;
2. Mettre en place un moteur particulièrement efficace pour gérer le parcours des relations (en opposition avec le mécanisme de “Join” des RDBMS, réputé lourd, en particulier lorsqu’ils sont multiples).

Pour en donner un avant-goût, en Cypher, le langage de requêtage de Neo4j², un des leaders des bases de données orientées graphes, la requête ci-dessus exprimant la relation d’amitié de degré 2 s’écrira de la façon suivante :

MATCH (p1:Person {Name:"Bob"} ) -[:Likes*2]-> (p2:Person)
WHERE p1 <> p2
RETURN p2.Name

Historiquement, les bases de données relationnelles ont été introduites pour combler les lacunes des bases de données hiérarchiques et réseaux. On les a appelé “relationnelles” parce que, dans le contexte de l’époque, elle permettaient de mieux représenter les relations. Il peut sembler ironique qu’à l’heure actuelle, on revienne à des organisations en réseau parce qu’avec l’évolution de la technologie, on estime aujourd’hui que les bases de données relationnelles ne représentent pas bien les relations…

Conclusion

Les quelques exemples ci-dessus ont eu pour but de montrer que, si on veut mettre au cœur d’une analyse les relations entre des entités plutôt que ces entités elles-mêmes, les bases de données relationnelles ne sont pas forcément le meilleur candidat. Elles ont d’une part l’inconvénient de repousser au développeur de l’application l’implémentation des relations, et d’autre part de nécessiter l’exécution d’une machinerie très lourde.

Dans un prochain article, nous expliquerons plus en détails comment fonctionne une base de données orientées graphe (en particulier Neo4j²), et comment elles peuvent répondre aux problématiques détaillées ci-dessus. Il va de soi que les bases de données orientées graphes ne sont pas un remplaçant universel des bases de données relationnelles, et ne sont pas du tout adéquates dans un certain nombre de circonstances. Mais nous verrons qu’elles peuvent être très complémentaires aux RDBMS, en les surpassent largement, dans certains cas spécifiques, tant en termes de performances qu’en terme de lisibilité ou d’expressivité.

Références

1. Graph Databases, New opportunities for connected data ; Ian Robinson, Jim Webber & Emil Eifrem ; O’Reilly, 2015. http://graphdatabases.com/
2. www.neo4j.com
3. Quick Review 72: Neo4j – Graph database management system ; Smals Research, 2016

L’analyse de réseau (souvent appelée en anglais social network analytics) reprend l’ensemble des techniques algorithmiques permettant d’extraire certaines informations utiles à partir des données d’un réseau. Nous allons ici présenter quelques éléments de base de ce type d’analyse.

Simplifier

Lorsqu’un organisme de contrôle (inspecteurs fiscaux ou sociaux, services de police ou de renseignements) collecte des données “réseau”, il est rapidement confronté à un volume très important de données. Supposons que l’organisme en question ait 5 personnes dans le collimateur (P1-P5, en orange dans le réseau ci-contre), soupçonnées d’activités criminelles ou frauduleuses dans le cadre de leur travail, et voudrait d’une part déterminer les liens qui existent entre ces 5 personnes, et d’autre part identifier d’autres personnes qui pourraient être très proches de suspects, et mériteraient donc une attention particulière.

Une façon simple de faire serait de s’intéresser aux employeurs (présents et passés, en vert) de ces 5 personnes, puis à tous les autres employés de ces employeurs (en bleu, de “a” à “r”). Cela permettrait d’identifier des collègues en commun, et de voir à quel point les autres collègues sont liés.

Supprimer les super-connecteurs

Le problème d’une telle recherche est que si l’un des suspects a travaillé pour une très grosse entreprise (un ministère, une société de transport public, une grande chaîne de magasin…), ce nœud va faire exploser la taille du réseau, le rendant totalement inexploitable.

Un exemple similaire apparaît si l’on veut retrouver des couples d’entreprises prétendument distinctes mais n’étant séparées que fictivement, en se basant entre autres sur leur adresse : certaines tours de bureaux dans des grandes villes sont parfois le siège social de plus de 1000 entreprises.

Une technique classique consiste alors à ignorer de tels nœuds (entreprise, adresse), que l’on peut qualifier de super-connecteurs, ou à tout le moins de les masquer provisoirement. On y perd potentiellement des informations importantes, mais l’on rend le reste du réseau exploitable. Moins d’information donc, mais plus de valeur.

Typiquement, la suppression de ces super-connecteurs va avoir pour conséquence de diviser le réseau en plus petits groupes, appelés “composantes connexes”, qui pourront être étudiées individuellement (cf image ci-dessus, où seule la plus grande composante connexe a été gardée).

Techniquement parlant, le degré d’un nœud désigne le nombre de ses relations. Par exemple, le degré d’un nœud “Travailleur” sera le nombre de ses employés, et le degré d’un nœud “Entreprise” correspondra au nombre de ses travailleurs. Les super-connecteurs sont donc des nœuds avec un haut degré.

Supprimer les feuilles isolées

À l’autre extrémité, une “feuille”, c’est-à-dire un nœud de degré 1, connecté à un et un seul nœud, a souvent peu de valeur lorsque l’on veut établir des connexions entre des personnes ou d’autres entités. Il est souvent intéressant, en tout cas dans une phase de l’analyse, d’éliminer toutes les feuilles qui ne sont pas les nœuds à l’origine de l’analyse (les 5 individus évoqués ci-dessus, dans l’exemple cité). L’image ci-contre illustre ce filtre. Avec ce filtre, il ne reste que deux “nouveaux collègues”. On voit en particulier que “r” a été collègue avec chacun des nœuds orange, via les sociétés C2, C3 et C5, et mérite peut-être une attention particulière.

On peut même aller plus loin si on veut observer uniquement la “colonne vertébrale” d’un réseau, à savoir uniquement les nœuds principaux : on supprime alors tous les deux de degré inférieur à une valeur définie.

Une technique alternative, appelée “k-core”, consiste à supprimer tous les nœuds de degré 1 (plus généralement, de degré k). De ce fait, des nœuds, qui avant avait un degré deux, mais étaient connectés à un nœud que l’on vient de supprimer, se retrouvent avec un degré de 1 (par exemple C6 dans la figure ci-dessus). Le filtre “k-core” les supprime également, jusqu’à ce que plus aucun nœud du réseau n’ait un degré inférieur à deux (plus généralement k+1).

Distance

Après avoir collecté une série de nœuds et relations (provenant éventuellement de plusieurs sources), on peut se demander si deux individus, deux entreprises, deux organisations… ont des chances d’être en contact, même s’il n’existe pas de relation directe entre les deux. Différentes notions de “distance” permettent d’évaluer la proximité entre deux nœuds d’un réseau.

Plus court chemin

La mesure de la distance la plus classique consiste à compter le nombre minimum de relations qu’il faut parcourir pour joindre deux nœuds. Dans l’exemple ci-dessus, le travailleur P1 et son entreprise C1 sont à une distance de 1, deux collègues seront à une distance de 2, et P3 et C5 à une distance de 3. On parle de nœuds voisins pour désigner deux nœuds séparés d’une distance 1.

Différent algorithmes, dont les plus connus sont Dijkstra et A*, permettent de calculer efficacement cette distance.

Similarité de Jaccard

La similarité de Jaccard entre deux nœuds N₁ et N₂ d’un réseau désigne le ratio entre le nombre de nœuds étant des voisins communs de N₁ et N₂, et le nombre total de voisins de N₁ et N₂. Si l’on parle d’un réseau d’amitié comme Facebook, une similarité de Jaccard de 1 entre deux personnes signifierait que tous leurs amis sont communs, c’est-à-dire qu’aucun des deux n’a d’ami qui n’est pas également ami avec l’autre. Une similarité de 0 indique que deux personnes n’ont aucun ami en commun. Dans l’exemple de Facebook, une similarité élevée indique qu’il y a beaucoup de chances que les deux individus se connaissent, même s’ils ne sont pas “amis Facebook”. En d’autres termes, si deux personnes ont 1000 amis chacun sur un réseau social, mais seulement 50 en commun, ils seront considérés comme moins proches que deux personnes ayant chacun 100 amis, dont 50 en commun.

Dans notre exemple tout en haut de la page, P1 et P4 ont une similarité de Jaccard de 0,5 (2 voisins communs – C1 et C4 – et 4 au total – C1, C3, C4, C5), alors que P2 et P3 ont une similarité de 0.25 (1 voisin commun, 4 au total). Alors qu’en terme de distance simple, P1 et P4 sont séparés, comme P2 et P3, d’une distance de 2, la similarité de Jaccard nous enseigne que le premier couple est plus similaire que le second.

Centralité

Dans un réseau, tous les nœuds n’ont pas le même poids, la même importance. Il existe plusieurs façons de mesurer ce que l’on appelle la “centralité” d’un nœud. La mesure la plus simple, la “centralité de degré“, consiste à dire qu’un nœud de degré plus important est plus central. La “centralité d’intermédiarité” (betweenness centrality) évalue elle à quel point un nœud sert d’intermédiaire entre les autres nœuds. Le “PageRank” de Google est également un algorithme de centralité : il consiste à considérer que la centralité se diffuse via les liens. Si une page web importante A possède un lien vers une autre page web B, B héritera d’une partie de l’importance de A.

L’illustration ci-contre adapte la taille des nœuds en fonction de leur “betweenness centrality”. On y voit que le nœud “r” évoqué ci-dessus attire particulièrement l’attention par sa position centrale dans le réseau (en tant qu’intermédiaire).

 Pour conclure

Si cet article présente l’utilisation de l’analyse de réseau dans le cas de la fraude, son utilisation est beaucoup plus large que ça. Elle permet également de modéliser des réseaux d’ordinateurs ou de télécommunication (serveurs/routeurs reliés entre eux par des câbles ou autre), des processus d’entreprises (tel service transmet tel document/demande/formulaire à tel autre service), d’usinage (une machine reçoit certaines pièces, produit une nouvelle pièce qui transite vers une autre machine), ou pour des analyses plus conceptuelles (liens entre des langues, des lois, des idées politiques…).

Il va de soi que les techniques utilisées en réalité sont beaucoup plus complexes que ce qui est présenté ci-dessus, ultra-simplifié à des fins pédagogiques. Mais la philosophie reste la même.

Illustrations réalisée avec Gephi (www.gephi.org)

Techniques classiques

Voyons quelques techniques, ultra-simplifiées ici à titre d’illustration, d’analyse de données permettant de suspecter des fraudes, et qui nécessiteront bien sûr, ensuite, une investigation plus approfondie.

 Détection “d’outlier”

On peut raisonnablement estimer que, dans la restauration, le chiffre d’affaire et le nombre d’employés soient corrélés, c’est-à-dire que, en général et pour une même classe de restaurant et une même région, une enseigne avec plus de personnel aura un chiffre d’affaire plus important (les deux mesures étant liées à un troisième facteur, à savoir le nombre de tables ou de clients). Un organisme tel que le ministère des finances, qui possède ces deux données, pourrait donc dessiner un graphique en nuage de points, dans lesquels chaque point représente un restaurant ; sa position sur l’axe des abscisses représente son nombre d’employés et sur l’axe des ordonnées son chiffre d’affaire, tel qu’illustré ci-contre (données totalement fictives). 

Dans l’exemple ci-contre, le point orange en haut à gauche représente un restaurant ayant soit un chiffre d’affaire particulièrement élevé (par rapport à son nombre d’employés), soit un nombre d’employés très bas (par rapport à son chiffre d’affaire). On pourrait dès lors suspecter qu’une partie du personnel ne soit pas déclaré, voire, pire, que du blanchiment d’argent soit en cours dans ce restaurant.

De façon similaire, on pourrait suspecter dans le cas du point rouge (en bas) qu’il corresponde à un restaurant qui cache une partie de son chiffre d’affaire, ce qui pourrait inciter le service d’inspection à envoyer un de ses inspecteurs. En général, on appelle “outlier” une observation statistique qui se distingue nettement de la grande majorité des données. Il va de soi que dans la réalité, on fait ce genre d’exercice sur plus que deux variables.

Analyse du comportement

Les voleurs de cartes de crédit ont souvent un comportement d’achat en ligne différent d’un utilisateur classique. Par exemple, un fraudeur utilisera souvent plusieurs numéros de cartes de crédit depuis le même ordinateur (et donc depuis la même adresse IP). On sait aussi que, souvent, un fraudeur qui vient de voler un numéro de carte de crédit commence par l’essayer sur un faible montant, puis ensuite effectue une série d’achats plus conséquents. Par ailleurs, un même numéro volé peut avoir été revendu à plusieurs personnes ; un même numéro utilisé depuis deux ordinateurs très distants sur un court laps de temps peut être également considéré comme suspect. En combinant ce genre de règles, on peut établir un score, qui, s’il dépasse un seuil défini, déclenche un processus de vérification (comme par exemple un appel téléphonique au propriétaire de la carte).

Techniques de “Machine learning”

Comme la plupart des sociétés, les banques n’aiment pas prendre de risque, à moins qu’ils soient maîtrisés ou que le gain soit à hauteur du risque. Pour évaluer le risque qu’un client ne rembourse pas un crédit, les banques se servent souvent de techniques d’apprentissage automatique (machine learning). L’une d’entre elles consiste à fournir à un algorithme les données d’un grand nombre de crédit accordés par le passé (montant, nombre de mensualité, âge du créditeur, salaire, économies, situation familiale, autres crédits en cours, nombre de remboursements en retard, niveau d’études…), de façon à évaluer, lorsqu’un nouveau crédit est demandé, s’il doit être considéré comme risqué ou non. Autrement dit, on regardera si, dans une situation similaire (par rapport au créditeur et au crédit), les remboursements se passent en général bien ou non. Il s’agit de techniques de classification qui ont de nombreuses applications.

Paradoxe du faux positif

Un des grands arguments des opposants à l’utilisation de données massives par les services de police et de renseignement est connu sous le nom du “paradoxe du faux positif”. Supposons que, parmi la population belge, que nous arrondirons à 10 millions d’individus, il y ait 100 terroristes susceptibles de passer à l’action, et que, sur base d’une combinaison de techniques présentées ci-dessus (basées, par exemple, sur les méta-données de ses communications téléphoniques et par courriel, ou sur base du comportement sur les réseaux sociaux), on établisse un test qui identifie un terroriste, avec une fiabilité de 99 %, c’est-à-dire que 99 % des individus testés seront correctement catégorisés (et 1 % sera mal catégorisé). Avec un tel test, 99 des 100 terroristes seront (en moyenne) correctement identifiés par notre test (un seul individu sera donc un “faux négatif”). Ce qui peut sembler encourageant… mais cela signifie également que, parmi les (presque) 10 millions de personnes fiables, 1 %, soit 100’000 personnes, seront également qualifiées de terroristes (il s’agit donc de faux positifs). On aura donc que parmi le groupe de 100’099 personnes considérées par le test comme terroriste,  moins d’un pour-cent sera en fait effectivement terroriste. Il ne sera clairement pas possible de tous les mettre sur écoute, ou de le faire surveiller.

Pour neutraliser le terrorisme en se basant uniquement sur des données collectées, il faudra donc un test beaucoup plus fiable que celui à 99 % évoqué ci-dessus.

Garbage In, Garbage Out

Par ailleurs, les chiffres présentés ci-dessous ne seront atteints que si les données sont de bonne qualité, c’est-à-dire que les données encodées correspondent à la réalité observable : les adresses des entreprises sont toujours correctes, un nom n’a pas mal été orthographié et confondu avec une autre personne… si ce n’est pas le cas, les résultats des algorithmes seront bien entendu encore moins fiables. D’où l’adage “garbage in, garbage out” : si on donne des données de mauvaise qualité à un algorithme, aussi performant soit-il, le résultat sera de mauvaise qualité. Or dans la réalité, il est d’une part impossible, à partir du moment où une personne encode des données, de s’assurer qu’elles soient toujours correctes, et d’autre part, la réalité évolue toujours plus vite que les données la représentant.

Limites

Une caractéristique commune des méthodes présentées ci-dessous est que l’on analyse le comportement ou la position d’une entité en la comparant ensuite à des repères calculés au préalable (typiquement basés sur l’ensemble des autres entités). Mais on ne considère pas une entité dans sa relation avec d’autres entités. Or en général, les fraudeurs et criminels n’agissent pas seuls. Un entrepreneur monte une structure financière parce qu’un de ses collègues l’a fait avec succès avant lui ; une personne entre dans le monde de la délinquance parce qu’elle est en contact avec des gens qui en font déjà partie. C’est de façon générale ce que les sociologues appellent l’homophilie : qui se ressemble s’assemble, toute personne est influencée par son environnement et ses relations (à ne pas confondre avec l’acception plus répandue de l’homophilie concernant l’orientation sexuelle).

De plus en plus, on s’intéresse au réseau social des entités considérées. Par réseau social, on n’entend bien sûr pas Facebook ou Twitter, mais un ensemble d’entités (personnes, entreprise, lieu…) et les relations qui existent entre elles (l’individu I travaille pour ou dirige l’entreprise E, qui a son siège social à l’adresse A, I₁ a téléphoné à I₂…).

Analyse de réseaux sociaux

Un réseau (ou un graphe) est donc une abstraction mathématique qui représente un ensemble d’entités (appelées nœuds), dont certaines sont reliées entre elles (au travers de liens, ou d’arcs). Un blog y a déjà été consacré il y a quelques temps. Dans la majorité des pays du monde, les services officiels, tels que ceux liés à la sécurité sociale, au ministère des finances ou de l’économie, disposent d’un grand nombre d’informations pouvant être vues comme un réseau :

• Une personne P travaille, est gérante ou administratrice d’une entreprise E. P et E sont les nœuds, l’arc est la relation de travail ;
• Une entreprise E a son siège social à l’adresse A (éventuellement commune à d’autres entreprises) ;
• Une entreprise E₁ sous-traite une partie d’un travail, comme un chantier de construction, auprès d’une entreprise E₂.

Pour chacune de ces relations, l’arc peut disposer d’un certain nombre de labels ou d’attributs : date de début, date de fin, type de relation (“travailleur”, “gérant”, “siège social”…), éventuellement poids de la relation (nombre de parts d’un actionnaire, montant financier d’une sous-traitance…).

Des services de police ou de renseignements peuvent également disposer d’autres informations :

• Une personne P₁ téléphone à une personne P₂ ;
• Une personne P₁ est le père/frère/cousin d’une personne P₂ ;
• Une personne P a été vue à l’endroit X.

Faillite organisée

Une technique de fraude sociale répandue consiste à créer une société, y engager du personnel et le rémunérer, éventuellement commander des fournitures et, juste avant de devoir payer les charges sociales ou les fournisseurs, s’arranger pour mettre la société en faillite. Il suffit alors de recommencer le même processus, idéalement dans une autre région pour ne pas tomber sur les mêmes juges ou curateurs. Ce type de fraude est connu sur le nom de “spider construction” (ref1, ref2). Le schéma est en général complexe : on a par exemple deux associés, qui s’associent chaque fois à des personnes différentes pour créer différentes sociétés fictives ; avec de temps en temps des sous-traitants complices, de temps en temps victimes. Un fraudeur peut par ailleurs être gérant d’une compagnie, puis administrateur d’une autre et comptable de la troisième.

La figure ci-contre illustre un exemple, dans lequel trois sociétés (1, 2, 3, marquées par une croix rouge) ont déjà fait faillite, et par lesquelles les deux individus du milieu sont passés. Par ailleurs, une société a été sous-traitante pour les trois sociétés en question. La société 4 mérite toute l’attention des inspecteurs : elle partage à la fois les deux personnes “suspectes”, ainsi que le sous-traitant potentiellement complice.

Homophilie et diffusion

La technique précédente ne présuppose aucune connaissance par rapport au caractère frauduleux de certaines personnes. Mais souvent, les services d’inspection ont un historique et ont déjà pu découvrir de nombreux cas de fraude. Cette connaissance peut alors être utilisée. On se base alors sur le principe de l’homophilie déjà évoqué ci-dessus : on a plus de chance de trouver un fraudeur (ou plus généralement un criminel) dans l’entourage proche d’un autre fraudeur qu’en inspectant une personne ou une entreprise totalement au hasard. On constate également que plus une entreprise est liée à une entreprise où de la fraude a été mise à jour (beaucoup de responsables en commun, des sous-traitants identiques…), plus y a de la chance d’y trouver de la fraude.

Dans l’exemple ci-contre, une fraude a été mise au jour au sein de la société B, au centre (macaron rouge). On va dès lors examiner toutes les entreprises “voisines”, c’est-à-dire ayant partagé des employés (pas nécessairement simultanément), travaillé sur des chantiers communs (s’il s’agit d’entreprises de construction), ou utilisant des mêmes fournisseurs ou sous-traitants. Une relation ayant duré plus longtemps sera considérée comme plus “forte” (lignes plus épaisses dans le schéma ci-contre).

L’entreprise A étant plus fortement connectée à B que C, elle sera considérée comme plus à risque (macaron rose foncé pour A, pâle pour C). Par ailleurs, si A était également proche d’une autre entreprise aussi considérée comme à risque, cela ferait augmenter son “score de risque” en conséquence.

Plus généralement, les techniques utilisées pour diffuser les scores de risques sont proches de l’algorithme “PageRank” de Google, utilisé pour trier les résultats d’une recherche. Plus une page est importante, plus elle donnera de l’importance aux pages vers lesquelles elle a des liens.

Dynamique des réseaux

Dans le but d’éviter d’être repérés par la police, il n’est pas rare que deux individus ne se contactent jamais directement, mais passent systématiquement par un intermédiaire pour se transmettre des informations. Si l’on considère toutes les conversations téléphoniques entre les membres d’un groupe sous surveillance, comme illustré ci-contre, on pourrait penser que Charline n’est jamais en contact avec Bob, et que Danièle ne communique pas avec Frank.

Mais si l’on observe ce réseau comme un film, en ne considérant que les contacts ayant eu lieu sur une fenêtre de temps relativement courte, on pourrait apercevoir que, chaque fois que Danièle contacte Éric, celui-ci contacte Frank dans la foulée (temps 1), et que dans les minutes qui suivent chaque appel de Charline à Éric, ce dernier appelle systématiquement Bob (temps 2).

On peut donc en conclure que Danièle et Frank sont plus que probablement en contact (indirect), ainsi que Charline et Bob, et que, dans les deux cas Éric sert d’intermédiaire.

De façon générale, si l’on peut déjà obtenir beaucoup d’information d’un réseau “statique”, considérer sa composante dynamique ou temporelle apporte souvent de nombreux renseignements précieux.

Conclusions

L’analyse de réseaux sociaux (ou Social Network Analytics) est une des grandes tendances du moment en matière de lutte contre la fraude. Les grands fournisseurs de logiciels que sont SAS ou IBM mettent par ailleurs beaucoup de moyens dans le développement d’outils tels que SAS SNA ou IBM I2, avec pour cible tant les grandes sociétés privées (banques, assurances, télécommunication…) que les services publiques (sécurité sociale, finance, police…).

Avec des outils d’analyse de réseaux dans des environnements “Big Data”, des outils comme GraphX de Spark (compatible avec Hadoop) ouvrent encore de nouvelles possibilités, étant donné la quantité de plus en plus importante de données à la disposition des organismes, et la complexité de certains algorithmes.

Il va de soi de ces nouvelles possibilités d’analyse posent des questions en matière de vie privée. On peut par exemple techniquement sans difficulté combiner des données officielles avec des données publiques collectées sur Facebook ou Twitter. Ceux qui font donc ce genre d’analyse doivent s’assurer de le faire en conformité avec la loi. Et il va dans l’intérêt du citoyen lambda de faire attention à ce qu’il laisse trainer sur les réseaux sociaux.

Références :

• [book] “Fraud Analytics ; using descriptive, predictive and social network techniques“, B. Baesens, V. Van Vlasselaer & W. Verkere, Winley, 2015

• Social Network Analysis for Fraud Detection (B. Baesens, V. Van Vlasselaer)

• Social Networks for Fraud Analytics (B. Baesens, V. Van Vlasselaer)

Schémas réalisés avec yEd (http://yed.yworks.com)