Neo4j : la liberté du graphe, avec un modèle strict

La force de Neo4j vient d'abord de son modèle très simple. Une donnée est représentée par un nœud. Une relation relie deux nœuds. Les nœuds et les relations peuvent porter des propriétés. Un label permet ensuite de classer un nœud : Client, Produit, Utilisateur, Contrat, Étape, Document, Organisation, Permission, etc.

Techniquement, un nœud reste un nœud. Ce n'est pas une table figée. Il peut avoir zéro, un ou plusieurs labels. Il peut aussi évoluer dans le temps : un même nœud peut être à la fois une Personne, un Contact, un Administrateur ou un Acteur dans un processus métier. Cette liberté est très puissante parce qu'elle permet de modéliser le réel sans l'écraser trop tôt dans une structure rigide.

Mais cette liberté peut devenir dangereuse si elle est utilisée sans méthode. Un graphe sans règles devient vite illisible : trop de labels, trop de relations vagues, des propriétés placées au hasard, des concepts qui se recoupent. Notre approche consiste donc à garder la souplesse de Neo4j, tout en construisant un modèle strict : noms de labels, types de relations, sens des relations, propriétés obligatoires, contraintes, index, règles de lecture et règles d'évolution.

Dans nos logiciels, on aime beaucoup le polymorphisme. Le mot peut sembler abstrait, mais l'idée est simple : plusieurs objets différents peuvent être manipulés avec une logique commune, parce qu'ils partagent un comportement, une interface ou une structure de base.

Par exemple, un Utilisateur, une Entreprise, un Site, un Document ou une Tâche peuvent être des objets métier très différents. Pourtant, ils peuvent tous être reliés, historisés, autorisés, affichés dans un arbre, attachés à un projet ou concernés par une règle de workflow. Le polymorphisme permet d'écrire une logique générique pour ces comportements, au lieu de dupliquer le même code pour chaque type d'objet.

Neo4j se prête très bien à cette manière de penser. Comme un nœud peut représenter différentes choses, et comme les labels servent à lui donner ses rôles, on peut construire des structures plus génériques, plus récursives et plus durables. Une organisation peut contenir des équipes, qui contiennent des personnes, qui portent des droits, qui s'appliquent à des projets, qui contiennent eux-mêmes des sous-projets. On peut traverser cette structure sans devoir réinventer une jointure ou une table de liaison à chaque niveau.

Beaucoup de métiers ne sont pas plats. Une entreprise a des filiales, des agences, des équipes, des rôles et des exceptions. Un produit peut être composé de sous-produits. Un chantier peut contenir des phases, des lots, des interventions, puis des contrôles. Un processus peut avoir des étapes, puis des sous-étapes, puis des conditions de passage.

C'est ce qu'on appelle une structure récursive : une chose peut contenir une chose du même type ou d'une famille proche. Dans une base relationnelle classique, ces modèles deviennent souvent lourds à maintenir, parce qu'il faut multiplier les tables, les clés étrangères, les cas particuliers et les requêtes complexes.

Dans Neo4j, on peut représenter cette logique de manière beaucoup plus naturelle. On ne demande pas seulement : quelle est la ligne dans la table ? On demande : par quels chemins cette donnée est-elle reliée aux autres ? C'est souvent là que le graphe devient très efficace.

Un autre avantage important de Neo4j n'est pas seulement technique. Il est pédagogique. Quand on travaille avec un client, on peut lui présenter le modèle sous forme de ronds et de relations : ici un Client, ici un Contrat, ici un Site, ici une Intervention, ici le lien qui explique que cette intervention dépend de ce site et de ce contrat.

Même une personne non technique peut alors participer à la discussion. Elle peut dire : ce lien n'est pas exact, cette information devrait être sur la relation, cette règle appartient plutôt à l'étape, cette notion doit exister indépendamment. On ne lui demande pas de comprendre une base de données. On lui montre comment son métier est structuré.

Cette phase est essentielle pour nous. Elle permet de reconstruire proprement la connaissance métier avant de construire les écrans. Elle évite de développer un logiciel qui fonctionne techniquement mais qui décrit mal l'entreprise. Un bon modèle de données, c'est souvent ce qui fait la différence entre un logiciel fragile et un logiciel qui peut grandir.

Les schémas ci-dessous sont volontairement simplifiés. Les ronds représentent des nœuds, donc des objets métier. Les flèches représentent des relations typées. Les éléments entre accolades sont des propriétés placées sur la relation quand elles décrivent le lien lui-même.

Ce format est très utile en atelier client : on peut pointer un rond, pointer une flèche, et décider ensemble si l'information est au bon endroit. C'est là que Neo4j devient très concret.

Neo4j donne beaucoup de liberté. C'est précisément pour cela qu'il faut être strict. Dans nos projets, on ne laisse pas le graphe se remplir au hasard. On définit les concepts, les labels, les relations, les propriétés et les invariants. On décide ce qui doit être un nœud, ce qui doit être une relation, et ce qui doit simplement être une propriété.

Cette décision est fondamentale. Si une information a sa propre identité, si elle doit être reliée à plusieurs objets, historisée, filtrée, partagée ou interrogée indépendamment, elle mérite souvent d'être un nœud. Si elle décrit seulement un état simple, elle peut rester une propriété. Si elle qualifie le lien entre deux choses, elle appartient peut-être à la relation.

Cette discipline permet d'utiliser Neo4j pour produire une ingénierie riche sans tomber dans le n'importe quoi. On garde un modèle lisible, auditable et évolutif.

Notre objectif n'est pas seulement de faire fonctionner la première version. On prépare les données pour que le logiciel tienne dans le temps. Les métiers changent, les équipes changent, les droits changent, les parcours utilisateurs changent. Un modèle trop fermé oblige souvent à casser la structure au bout de quelques mois.

Avec une approche graphe bien cadrée, on peut mieux absorber ces évolutions. On peut ajouter un nouveau type de relation, un nouveau rôle, une nouvelle profondeur hiérarchique ou une nouvelle règle métier sans tout reconstruire. Le logiciel reste vivant, mais son modèle reste compréhensible.

C'est pour cela que nous aimons Neo4j dans certains projets sur mesure. Il nous permet de concevoir des systèmes qui respectent la complexité du métier, tout en gardant une architecture claire.

Neo4j n'est pas le bon choix pour tous les logiciels. Si le besoin est un CRUD simple, un catalogue classique ou un reporting très standard, une base relationnelle ou documentaire peut être plus adaptée. Le bon choix technique est celui qui sert le problème, pas celui qui semble le plus original.

En revanche, Neo4j devient très intéressant quand les relations portent la valeur du logiciel : gestion de droits complexes, organisations multi-niveaux, cartographie d'actifs, dépendances techniques, moteurs de recommandation, workflows, réseaux d'acteurs, traçabilité, connaissance métier, données fortement connectées.

Dans ces cas-là, le graphe n'est pas une coquetterie technique. C'est une manière plus juste de représenter le monde du client. Et quand le modèle est juste, le logiciel devient plus simple à expliquer, plus simple à faire évoluer et souvent beaucoup plus robuste.