Pourquoi Boldo repose sur Neo4j
Un choix à contre-courant
Neo4j est aujourd'hui principalement associé aux knowledge graphs pour l'IA, à la détection de fraude et à l'analyse en cybersécurité. Ce sont les cas d'usage que la communauté met en avant, ceux que Neo4j elle-même utilise dans sa communication.
Boldo a pris une direction différente. Il y a deux ans, l'équipe a choisi Neo4j comme base de données opérationnelle principale pour construire un outil d'Architecture d'Entreprise. Pas comme moteur d'analytics ou comme couche de recommandation. Comme socle de données du produit.
Deux ans de production plus tard, le bilan est contrasté. Certaines hypothèses se sont confirmées au-delà des attentes. D'autres ont demandé plus de travail que prévu. Ce qui suit est un retour factuel, sans promotion.
Le raisonnement de départ
L'Architecture d'Entreprise est fondamentalement une histoire de connexions. Les applications dépendent d'une infrastructure. Les processus reposent sur des applications. Les équipes sont responsables de processus. Tout est relié à tout, et c'est précisément ce que la plupart des outils du marché modélisent mal.
Dans une base de données relationnelle, ces connexions se traduisent par des tables de jonction. Plus le modèle est riche, plus les jointures se multiplient. Plus les jointures se multiplient, plus les requêtes deviennent complexes et coûteuses. L'hypothèse de départ était qu'une base de données orientée graphe permettrait de modéliser cette réalité de manière plus naturelle. Les nœuds représentent les actifs (applications, processus, équipes, infrastructures) et les relations entre eux portent leur propre contexte, sans intermédiaire.
Base relationnelle vs Neo4j pour l'Architecture d'Entreprise
| Critère | Base relationnelle | Neo4j (graphe) |
|---|---|---|
| Modélisation des relations | Tables de jonction, jointures multiples | Relations natives avec attributs |
| Évolution du schéma | Migration SQL, interruption possible | Édition de nœuds et relations, sans interruption |
| Requêtes de traversée (ex : impacts) | Jointures imbriquées, coût croissant | Traversée de graphe, coût stable |
| Intégrité des données | Contraintes intégrées au schéma | Validation applicative à construire |
| Écosystème et documentation | Très large, patterns éprouvés | Plus restreint, apprentissage par expérimentation |
| Flexibilité du métamodèle | Rigide, lié au schéma | Dynamique, le métamodèle est un sous-graphe |
Ce qui fonctionne
Le métamodèle vit dans le graphe lui-même
C'est probablement la décision architecturale la plus structurante du produit. Le métamodèle de Boldo, la structure qui définit quels types d'actifs existent et comment ils peuvent se relier, est lui-même un sous-graphe dans Neo4j. C'est un graphe qui décrit un graphe.
En pratique, cela signifie que chaque organisation peut façonner son propre modèle. Ajouter un nouveau type d'objet, créer une nouvelle catégorie de relation, modifier la structure existante : tout cela revient à éditer des nœuds et des relations dans la base. Il n'y a pas de migration de schéma à planifier, pas d'interruption de service, pas de script de mise à jour à exécuter.
Pour une startup qui a besoin d'itérer rapidement sur son modèle de données, cette flexibilité a été un avantage réel. Les premières versions du métamodèle de Boldo ont évolué plusieurs fois par semaine pendant les premiers mois de développement. Avec un schéma relationnel classique, chaque changement aurait impliqué une migration.
Les relations sont des objets à part entière
En Architecture d'Entreprise, le lien entre deux actifs a souvent plus de valeur que les actifs eux-mêmes. Savoir qu'un flux de données existe entre l'application A et l'application B est une information. Savoir que ce flux transporte des données personnelles, qu'il passe par un middleware spécifique et qu'il a été créé dans le cadre d'un projet donné, c'est une information exploitable.
Dans un modèle relationnel, ce type de contexte se répartit sur plusieurs tables. Dans un graphe, la relation elle-même porte ces attributs de manière native. La requête pour retrouver tous les flux transportant des données personnelles entre deux domaines métier est directe. Elle ne traverse pas six tables de jonction.
Ce qui a été plus difficile que prévu
L'intégrité des données repose entièrement sur l'application
Neo4j n'impose pas de contraintes de schéma implicites. Quand le métamodèle est lui-même dynamique, la couche de validation doit être suffisamment intelligente pour suivre ses évolutions. Les règles de cohérence sont définies par l'application, et c'est l'application qui les fait respecter.
L'équipe a sous-estimé la discipline que cela demande. Dans une base relationnelle, le schéma empêche par défaut certaines incohérences. Dans Neo4j, rien n'empêche de créer un nœud orphelin ou une relation entre deux types d'objets qui ne devraient pas être connectés. La couche de validation côté applicatif a représenté un investissement de développement significatif.
Tout ne se modélise pas bien en graphe
Après plusieurs mois de production, Boldo a évolué vers une architecture hybride. Le graphe reste le cœur du modèle opérationnel, celui qui gère les actifs, leurs relations et le métamodèle. Mais certaines données sont stockées ailleurs, dans des systèmes plus adaptés à leur nature.
Accepter que le graphe n'est pas la réponse à tous les besoins de stockage a été une étape importante. La tentation initiale de tout centraliser dans Neo4j a cédé la place à une approche plus pragmatique, où chaque type de donnée est stocké dans le système le mieux adapté.
L'écosystème est plus restreint
Comparé aux bases relationnelles, l'écosystème Neo4j offre moins de contenu en ligne, moins de patterns éprouvés pour des applications transactionnelles standard, et moins de retours d'expérience documentés pour des cas d'usage opérationnels.
En pratique, cela signifie que beaucoup de problèmes se résolvent par l'expérimentation plutôt que par une recherche rapide. Les réponses sur Stack Overflow sont moins nombreuses. Les patterns d'architecture pour des produits SaaS construits sur Neo4j sont rares. L'équipe a appris en construisant, ce qui prend plus de temps qu'en s'appuyant sur des solutions documentées.
Récapitulatif
| Aspect | Constat après 2 ans |
|---|---|
| Métamodèle dynamique | Tient ses promesses. Le graphe qui se décrit lui-même permet aux organisations de façonner leur propre modèle sans migration de schéma. |
| Relations contextualisées | Gain réel. Les attributs portés par les relations simplifient les requêtes et enrichissent le modèle. |
| Intégrité des données | Plus coûteux que prévu. L'absence de contraintes de schéma implicites impose une couche de validation applicative robuste. |
| Architecture hybride | Nécessaire. Le graphe couvre le modèle opérationnel, mais certaines données sont mieux servies par d'autres systèmes de stockage. |
| Écosystème | Plus restreint. Moins de patterns documentés, plus d'apprentissage par expérimentation. |
Le bilan après deux ans
Neo4j n'a pas été un choix de tendance. C'était un choix structurel. Quand le produit que l'on construit traite fondamentalement de la manière dont les choses se connectent, et quand la définition même de "comment les choses se connectent" doit rester flexible, un graphe qui se décrit lui-même était l'architecture la plus cohérente à disposition.
Le choix a tenu ses promesses sur la flexibilité du métamodèle et sur la richesse des relations. Il a demandé un investissement plus important que prévu sur la validation des données et sur la gestion des cas où le graphe n'était pas le bon outil.
L'équipe referait ce choix. Avec une meilleure anticipation de la complexité que cela implique.
