Au-delà d'une simple collection d'algorithmes : La valeur de GDS

Pour de nombreuses équipes découvrant la bibliothèque Graph Data Science (GDS) de Neo4j, la première impression est souvent celle d'un simple "catalogue d'algorithmes de graphes". Bien que cette perception ne soit pas entièrement fausse, elle est réductrice. La véritable puissance de GDS ne réside pas uniquement dans la mise à disposition de fonctions telles que PageRank, Louvain ou les plus courts chemins. Elle offre plutôt une approche d'ingénierie complète pour l'analyse graphique : comment transformer un graphe métier en une représentation optimisée pour l'analyse, exécuter des algorithmes sur ce graphe en mémoire, réécrire les résultats dans la base de données, effectuer de l'ingénierie de fonctionnalités, des embeddings de nœuds, de la prédiction de liens, et même intégrer des pipelines de Machine Learning basés sur les graphes en production.

Si Neo4j, en tant que base de données, excelle dans la "représentation naturelle des données relationnelles", GDS répond à la question "comment véritablement exploiter la structure relationnelle pour le calcul". Cette distinction, bien que subtile en apparence, marque le passage d'un projet de base de données d'un état "interrogeable" à un état "analysable, prédictible et décisionnel".

Une observation fréquente dans les projets de graphes est que de nombreuses équipes adoptent une base de données graphique sans pour autant passer à la phase d'intelligence graphique avancée. Elles utilisent le graphe comme une fondation de requête améliorée, mais n'explorent pas les opportunités en matière d'algorithmes, d'insights et de prédiction. GDS est précisément conçu pour ouvrir cette voie.

La Position de GDS : Un environnement d'exécution pour l'analyse graphique

La documentation officielle de GDS est claire : il s'agit d'une bibliothèque dédiée à l'analyse et au Machine Learning sur graphes, offrant des capacités d'algorithmes de graphes, de transformations, de gestion de graphes et de pipelines de Machine Learning. Il est crucial de noter que le terme "algorithmes" n'est pas le plus important ici, mais plutôt "gestion de graphes" et "pipelines de Machine Learning".

En d'autres termes, GDS ne se limite pas à "quelques procédures appelables ajoutées à la base de données", mais constitue un environnement d'exécution complet pour l'analyse graphique. Il aborde les problèmes à trois niveaux distincts :

1. Construction de la vue analytique : Le graphe de production n'est pas toujours directement adapté à l'exécution d'algorithmes, nécessitant une étape de projection de graphe.
2. Exécution d'algorithmes et gestion des résultats : L'exécution d'un algorithme ne se limite pas à un score unique ; elle implique la réécriture des résultats, la sortie en continu, les statistiques et la gestion des ressources.
3. Workflows de Machine Learning sur graphes : De la génération de fonctionnalités nodales et d'embeddings à l'entraînement et à la prédiction, GDS prend en charge des responsabilités d'analyse intelligente de plus en plus complètes.

La difficulté d'apprentissage de GDS pour certaines équipes ne provient généralement pas de la complexité syntaxique, mais plutôt du fait qu'il s'agit d'un paradigme d'analyse complet, et non d'une simple collection d'appels de fonctions.

Pourquoi la science des données graphiques diffère de la science des données traditionnelle

La science des données traditionnelle excelle dans le traitement des caractéristiques tabulaires. Un modèle apprend les relations statistiques entre les champs à partir d'échantillons organisés en lignes. La science des données graphiques, quant à elle, ajoute une dimension cruciale : l'information structurelle.

En matière de détection de fraude, par exemple, le niveau de risque d'un compte ne dépend pas uniquement de ses attributs propres, mais aussi de sa participation à un réseau avec des appareils, des cartes bancaires, des adresses, des commerçants ou d'autres comptes. Dans les systèmes de recommandation, la pertinence d'un article ne se limite pas à ses ventes et à ses étiquettes, mais aussi à ses schémas de connexion dans le graphe des comportements utilisateurs. Dans les graphes de connaissances, l'importance d'une entité est déterminée non seulement par son texte descriptif, mais également par sa position dans le réseau de relations sémantiques.

C'est pourquoi de nombreux modèles traditionnels montrent une efficacité limitée dans les scénarios de graphes. Les données ne sont pas que des valeurs, elles sont aussi des connexions. Le rôle de GDS est de transformer cette structure de connexion en un objet calculable, quantifiable et entraînable.

La Projection de Graphes : Une étape essentielle avec GDS

La documentation officielle de GDS insiste sur un concept fondamental : avant d'exécuter un algorithme, il est impératif de projeter le graphe dans un graphe nommé et de le gérer via un catalogue de graphes. Il s'agit d'une notion centrale.

Le graphe de votre base de données de production peut être considéré comme une "vue transactionnelle", tandis que le graphe projeté par GDS est une "vue analytique". Cette dernière est organisée en une structure en mémoire optimisée pour les calculs de graphes efficaces.

Données du graphe métier
   -> Sélection des étiquettes de nœuds / types de relations / propriétés
   -> Création d'un graphe nommé
   -> Ajout au catalogue de graphes GDS
   -> Exécution d'algorithmes ou de pipelines de Machine Learning
   -> Sortie des résultats / Réécriture dans le graphe original

Pourquoi ne pas exécuter directement sur le graphe original ? Les raisons sont pratiques :

• Le graphe transactionnel privilégie la cohérence en lecture/écriture et la structure de stockage.
• L'exécution d'algorithmes nécessite une efficacité de traversée et une disposition en mémoire spécifiques.
• L'analyse ne requiert souvent qu'une partie du graphe métier, pas l'intégralité.

Cette étape est parfois perçue comme fastidieuse par les débutants, mais elle est précisément la source de la valeur d'ingénierie de GDS. Elle force la distinction entre un "graphe de production" et un "graphe d'analyse", évitant ainsi de tout mélanger.

Projections Natives vs. Projections Cypher : Compromis entre performance et flexibilité

Selon la documentation officielle, GDS propose deux méthodes de projection courantes.

1. Projection Native

Cette méthode génère un graphe nommé en déclarant directement les étiquettes de nœuds et les types de relations. Elle est rapide, simple et plus efficace en termes de mémoire.

CALL gds.graph.project(
  'reseauCommercial',
  ['Client', 'Article'],
  ['ACHETE', 'CONSULTE']
)

Cas d'utilisation idéaux :

• Les étiquettes et types de relations sont déjà bien structurés.
• Aucun filtrage complexe n'est nécessaire.
• L'objectif est la rapidité de projection et l'efficacité de l'analyse.

2. Projection Cypher

Cette méthode utilise des requêtes Cypher pour définir les nœuds et les relations, offrant une flexibilité nettement supérieure.

CALL gds.graph.project.cypher(
  'grapheFraude',
  'MATCH (n:Compte) WHERE n.statut <> "fermé" RETURN id(n) AS id',
  'MATCH (a:Compte)-[r:TRANSFERE_VERS]->(b:Compte) RETURN id(a) AS source, id(b) AS cible, r.montant AS poids'
)

Cas d'utilisation idéaux :

• Nécessité de filtrer par propriétés.
• Chargement de poids sur les relations.
• Analyse d'un sous-graphe spécifique du graphe métier.

Le conseil est simple : privilégiez la projection native si possible, car elle est plus stable et plus rapide. N'utilisez la projection Cypher que lorsque la logique de filtrage métier est véritablement complexe. De nombreuses équipes commencent par utiliser la projection Cypher pour tout, ce qui, bien que flexible, transforme chaque analyse en un processus ETL partiel.

Classification des algorithmes GDS : Plus qu'une simple liste

Le système d'algorithmes de GDS est complet. Pour en saisir la valeur métier, il est préférable de les comprendre à travers cinq catégories principales.

1. Algorithmes de Centralité : Identifier les nœuds clés

Algorithmes représentatifs : PageRank, Betweenness Centrality, Degree Centrality, etc.

Cas d'utilisation :

• Analyse d'influence sur les réseaux sociaux.
• Identification d'entités clés dans les graphes de connaissances.
• Localisation des nœuds intermédiaires essentiels dans la détection de fraude.
• Identification des services centraux dans les chaînes d'appels.

La popularité de PageRank ne tient pas à son ancienneté, mais à sa capacité à répondre à une question fondamentale dans de nombreux réseaux : quels éléments sont structurellement les plus importants ?

2. Algorithmes de Détection de Communautés : Regrouper et segmenter

Algorithmes représentatifs : Louvain, Label Propagation (LPA), Weakly Connected Components (WCC), etc.

Cas d'utilisation :

• Identification de groupes frauduleux.
• Segmentation des cercles d'intérêt des utilisateurs.
• Détection de clusters dans les chaînes d'approvisionnement.
• Découverte de thèmes dans les graphes de connaissances.

En matière de lutte contre la fraude, la détection de communautés est inestimable. Elle peut souvent signaler l'existence d'un "groupe suspect" avant d'analyser en détail les acteurs principaux au sein de cette structure.

3. Algorithmes de Chemin : Découvrir les connexions

Algorithmes représentatifs : Dijkstra, A*, Shortest Path, etc.

Cas d'utilisation :

• Logistique et planification d'itinéraires.
• Localisation de chaînes de dépendances de services.
• Traçage en amont dans les chaînes d'approvisionnement.
• Explication des chemins de relations entre entités dans les graphes de questions-réponses.

4. Algorithmes de Similarité : Trouver des objets analogues

Algorithmes représentatifs : Jaccard, Cosine, Overlap, etc.

Cas d'utilisation :

• Construction de listes de candidats pour les systèmes de recommandation.
• Analyse de la similarité des profils utilisateurs.
• Déduplication d'entités et appariement de candidats.

5. Algorithmes d'Embeddings et de Machine Learning sur Graphes : Transformer la structure en caractéristiques

Algorithmes représentatifs : FastRP, Node2Vec, GraphSAGE, ainsi que les pipelines de Machine Learning pour la prédiction de liens et la classification de nœuds.

C'est dans cette catégorie que GDS se démarque d'une "bibliothèque d'algorithmes de graphes ordinaire". Il ne se contente pas de calculer sur le graphe, mais commence à intégrer la structure du graphe dans des tâches prédictives.

Un Workflow Typique : De la projection à la réécriture des résultats

De nombreux utilisateurs, en consultant les exemples GDS, trouvent le processus simple : créer un graphe, exécuter un algorithme, obtenir des résultats. En réalité, les équipes expérimentées gèrent généralement le processus avec plus de précision.

Workflow Recommandé

Définir le problème métier
   -> Sélectionner les nœuds, relations, propriétés pertinents
   -> Créer un graphe nommé
   -> Exécuter en mode 'stream' pour validation
   -> Confirmer les paramètres et l'utilisation des ressources
   -> Choisir le mode 'write' ou 'mutate'
   -> Réécrire les propriétés de nœuds ou de relations
   -> Consommer les résultats via Cypher ou une application externe

L'utilisation préalable du mode stream pour la validation est une excellente pratique. Elle permet d'examiner la distribution des résultats, d'évaluer leur pertinence par échantillonnage, avant de décider de les réécrire.

Exemple avec PageRank :

CALL gds.pageRank.stream('grapheCommerce')
YIELD nodeId, score
RETURN gds.util.asNode(nodeId).nom AS nom, score
ORDER BY score DESC
LIMIT 10

Une fois les résultats validés, on peut les réécrire :

CALL gds.pageRank.write('grapheCommerce', {
  writeProperty: 'scorePageRank'
})
YIELD nodePropertiesWritten, ranIterations

Il est fortement conseillé de ne pas utiliser directement le mode write. Les résultats d'algorithmes de graphes, une fois écrits comme propriétés de nœuds en production, peuvent influencer les requêtes ultérieures, les recommandations et même les décisions métiers. La validation avant la persistance est une discipline fondamentale.

Pipelines de Machine Learning : GDS entre dans l'ère de la "capacité prédictive"

La documentation officielle décrit clairement la section Machine Learning : elle offre un workflow de bout en bout, prenant en charge le cycle de vie complet, de la configuration à l'entraînement et à l'application des modèles. Les tâches courantes incluent la classification de nœuds, la prédiction de liens et la régression de nœuds.

Cela signifie que GDS n'est plus seulement une boîte à outils d'algorithmes, mais évolue vers une plateforme de Machine Learning sur graphes.

Un pipeline de Machine Learning typique comporte trois étapes :

1. Configuration du pipeline.
2. Entraînement du modèle.
3. Application du modèle pour la prédiction.

En pratique, les applications les plus représentatives sont généralement la prédiction de liens et la classification de nœuds.

Prédiction de Liens

Cas d'utilisation :

• Prédire si un utilisateur achètera un certain produit.
• Prédire l'existence de relations anormales potentielles entre comptes.
• Détecter des relations manquantes dans un graphe de connaissances.

Classification de Nœuds

Cas d'utilisation :

• Identification des niveaux de risque d'un compte.
• Attribution d'étiquettes d'intérêt à des utilisateurs.
• Catégorisation d'entités.

La documentation met également en avant les capacités de gestion des catalogues de modèles et de pipelines. C'est crucial car dès qu'un modèle entre en production, il ne peut plus être traité comme un résultat expérimental unique ; il nécessite une gestion de version, un déploiement, une obsolescence et un retour arrière.

Embeddings de Nœuds et Prédiction de Liens : Les compétences clés de GDS

1. Embeddings de Nœuds

Les embeddings de nœuds consistent à compresser la structure du graphe en représentations vectorielles. Pourquoi est-ce important ? Parce que cela permet de transformer la question "qui est structurellement similaire à qui" en un problème de distance dans un espace numérique.

FastRP est un choix courant pour de nombreuses équipes débutantes en raison de sa rapidité et de sa robustesse, le rendant particulièrement adapté aux systèmes de recommandation, à la recherche de similarités et au prétraitement pour l'ingénierie de fonctionnalités.

GraphSAGE va plus loin en combinant les propriétés des nœuds avec la structure du graphe pour des tâches d'apprentissage plus complexes.

2. Prédiction de Liens

C'est, à mon avis, l'une des capacités de GDS qui offre le plus de valeur métier. La raison est simple : de nombreuses activités commerciales reposent sur la capacité à prédire si "deux objets se connecteront à l'avenir".

Par exemple :

• Un utilisateur va-t-il acheter ce produit ?
• Une entreprise va-t-elle devenir un nœud de propagation du risque pour un fournisseur ?
• Une relation sémantique est-elle manquante entre deux entités ?
• Existe-t-il une connexion anormale potentielle entre deux comptes ?

Les bases de données graphiques stockent les "connexions connues", tandis que GDS aide à prédire les "connexions inconnues". Une fois cette étape maîtrisée, la valeur de Neo4j dépasse celle d'un simple système de requête pour devenir un système de décision intelligent.

Client Python, Workflows de Science des Données et Synergie avec GDS

De nombreuses équipes de données ne se limiteront pas à l'interface du navigateur Cypher ; elles intégreront GDS dans leurs workflows Python. Le client Python officiel pour Graph Data Science est conçu à cet effet : permettre aux scientifiques des données de se connecter à Neo4j, gérer des graphes nommés, exécuter des algorithmes et récupérer des résultats dans Pandas ou d'autres modèles en aval, le tout de manière familière.

Cette évolution reflète une tendance majeure : l'analyse graphique passe d'une compétence exclusive aux bases de données à une capacité quotidienne consommable par les équipes de science des données.

Cette direction est très pertinente. Les équipes de bases de données maîtrisent la structure, et les équipes de science des données maîtrisent la modélisation. Si la seule interaction se limite à JDBC et à l'export CSV, l'efficacité est compromise. GDS, combiné au client Python, raccourcit considérablement cette chaîne.

Gestion de la Compatibilité des Versions : Éviter les défaillances de déploiement dues aux détails d'environnement

Un aspect souvent négligé des projets GDS est la compatibilité des versions. Les versions de la base de données, de GDS, du JDK et du client Python doivent s'aligner dans une matrice claire.

Selon les pratiques courantes, il est essentiel de prêter attention aux relations de compatibilité, par exemple :

Version GDS	Version Neo4j	Version Java	Description
2.13	5.26	Java 17 / 21	Adapté aux environnements de production stables
2.21	2025.08.0 et versions récentes	Java 21	Plus adapté pour valider les nouvelles fonctionnalités et l'évolution continue

L'important n'est pas de mémoriser les numéros de version, mais de développer une habitude :

• Avant de mettre à niveau Neo4j, consulter la matrice de compatibilité GDS.
• Avant de mettre à niveau GDS, vérifier les changements d'interface des algorithmes et procédures.
• Maintenir une ligne de base fixe pour l'environnement de production et être plus audacieux pour l'environnement d'expérimentation.

De nombreux problèmes de "l'algorithme ne fonctionne pas" ne sont pas dus à une erreur d'algorithme, mais à un décalage dans la matrice d'environnement.

Quelques Leçons Tirées de Projets GDS

Premièrement, identifiez le problème avant de choisir l'algorithme. N'essayez pas d'appliquer chaque algorithme GDS à chaque problème métier. Un algorithme de graphe n'est pas une vitrine ; une mauvaise définition du problème est plus critique qu'un mauvais paramétrage.

Deuxièmement, la projection fait partie de la modélisation. Des résultats insatisfaisants ne proviennent pas nécessairement de l'algorithme lui-même, mais souvent d'un graphe projeté trop grand, sale, ou dont les relations sont mal définies.

Troisièmement, utilisez toujours le mode stream avant le mode write. Toute analyse à haut risque devrait d'abord être validée en examinant la distribution des résultats avant de décider de la persistance.

Quatrièmement, intégrez les résultats des algorithmes dans la chaîne d'explication métier. Pourquoi un score PageRank élevé est-il pertinetn ? Pourquoi un certain groupe est-il mis en évidence par la détection de communautés ? Sans une explication claire, les équipes métiers n'adopteront généralement pas les résultats.

Cinquièmement, considérez GDS comme une capacité de plateforme, et non comme une expérience isolée. Les entreprises qui réussissent avec GDS établissent progressivement des modèles d'algorithmes, des gabarits de projection, des normes de paramètres et des méthodes d'interprétation des résultats.

La valeur de GDS dépasse largement la simple capacité d'exécuter des algorithmes dans Neo4j. Le changement qu'il apporte est de faire passer la base de données graphique du stade de stockage et de requête à celui d'analyse, de prédiction et de décision intelligente. La projection de graphes distingue les graphes transactionnels des graphes analytiques, la classification des algorithmes permet de résoudre différents problèmes structurels de manière méthodique, les pipelines de Machine Learning intègrent la structure du graphe dans le monde de la prédiction, et les embeddings de nœuds ainsi que la prédiction de liens connectent davantage les capacités des graphes aux workflows d'IA modernes.

Si vous utilisez déjà Neo4j mais n'avez pas encore sérieusement exploité GDS, vous n'utilisez qu'une fraction de ses capacités. Ce qui rend véritablement une plateforme graphique "utile" plutôt que "jolie", ce n'est souvent pas l'instant de la modélisation, mais le moment où vous commencez à utiliser GDS pour transformer les structures relationnelles en insights, scores et prédictions.