Pour générer ses publications dans leurs différentes versions HTML, ePub, PDF web et imprimée, à partir des fichiers XML, D-BookeR utilise la plate-forme Calenco. Or depuis sa dernière version majeure, celle-ci fonctionne avec une base de données Neo4j ! Nous n'allions pas rater l'occasion d'interroger ses concepteurs sur les raisons de leur choix.

Interview de Camille Bégnis, CEO de NeoDoc, éditeur de la plate-forme SaaS Calenco
[22/11/2018]

Bonjour Camille, pour commencer peux-tu présenter en quelques mots la plate-forme Calenco ?

Bonjour Patricia, Calenco est une plate-forme SaaS qui permet aux entreprises de produire leurs documents de manière beaucoup plus efficace qu'avec les traditionnels traitements de texte ou outils de PAO. Entièrement collaboratif, cet outil permet de rédiger des documents 2 fois plus rapidement, de les traduire, et de les diffuser sur tous supports (papier, web, mobile, etc.). Il permet aussi de fiabiliser l'information que diffuse l'entreprise, ce qui est crucial dans notre ère rapide, ultra-connectée et exigeante.

La V3, lancée en production début 2018, est une version entièrement refaite de la plate-forme initiale, beaucoup plus ergonomique, flexible et rapide. Et pour cela, vous avez changé de technologie sous-jacente, puisque Calenco est désormais fondé sur une base de données graphe Neo4j. Pour mieux comprendre ce changement et ce qu'il a apporté, j'aimerais qu'on reparte de la V2 et que tu nous expliques comment elle avait été développée et les limites que vous rencontriez.

Depuis la V1, Calenco était basé sur une source de données unique, non pas une base de données, mais une base de contenus, basée sur le standard JCR (Java Content Repository). Cette base était particulièrement bien adaptée à notre utilisation, puisqu'elle permettait de stocker et gérer de manière automatique les documents et les modules de contenus qui les composent, ainsi que les métadonnées associées, le versionning, etc. Un système d'associations entre les nœuds de la base de contenus permettait de gérer notamment les dépendances entre les modules de contenus et les documents de manière récursive. L'interface V1 était assez simple, et cette organisation nous convenait. Toutefois, lors du passage à la V2, nous avons ajouté de nouvelles fonctionnalités de visualisation de l'information, qui permettaient notamment de naviguer facilement entre un document et ses multiples dépendances, textuelles ou graphiques. Et alors que les tailles de contenus de nos clients grandissaient de manière significative, les temps de réponse de l'interface ont augmenté significativement. En parallèle, nous sentions bien que l'ajout de nouvelles fonctionnalités comme le workflow par exemple nous obligeait à créer de nouvelles associations dans le système JCR, qui n'était pas fait pour cela initialement.

Graphes représentant les dépendances entre les fichiers (à gauche) et les relations entre auteurs et révision (à droite) sous Calenco.

Quelles sont les pistes que vous avez envisagées et pourquoi avoir privilégié Neo4j ?

Compte tenu de la nature intimement connectée de nos données, les bases de données n'étaient pas adaptées, et de toutes les options NoSQL qui florissaient à l'époque, les bases de données orientées graphes correspondaient parfaitement à la modélisation de nos données en permettant de stocker les liens entre les différentes entités que nous gérons (documents, modules, images, utilisateurs, sociétés, versions, etc.) et les métadonnées associées. Parmi toutes les implémentations de bases de données orientées graphe open-source, Neo4j nous a semblé celle qui bénéficiait de la plus grande base d'utilisateurs, dont une communauté importante en France, et donc avec des chances de pérennité plus grandes.

Quelles sont les autres technologies utilisées et comment interagissent-elles avec Neo4j ?

Neo4j n'étant pas adapté au stockage de fichiers, nous avons continué à garder JCR pour stocker les modules de contenu. Le tout est accessible via l'API de Calenco qui cache l'implémentation technique. De fait l'API de Calenco a peu changé entre la V2 et la V3, seules les routines d'accès aux données ont été réécrites pour accéder à Neo4j au lieu de JCR pour certaines d'entre elles. Le fait de connecter Neo4j à Calenco grâce au protocole Bolt nous permet aussi d'héberger Neo4j sur une machine différente et ainsi répartir la charge de manière plus efficace.

Représentation du workflow rédactionnel

Quelles sont les difficultés que vous avez rencontrées ?

Pour une petite entreprise comme la nôtre, effectuer une changement d'une telle ampleur sur le cœur même de l'application, représente une énorme quantité de travail. Par ailleurs, nous ne pouvions pas nous permettre de stopper les améliorations fonctionnelles pendant deux ans. Nous avons donc opté pour une stratégie de petits pas, en réécrivant les routines d'accès aux données petit à petit, en commençant par les plus cruciales.

Comment s'est passée la migration des données de la V2 à la V3 ? Quelles étaient vos contraintes ?

Nous avons donc étalé la migration sur plusieurs versions successives de Calenco 3, chacune apportant son lot de migration de données ainsi que l'adaptation des routines d'accès correspondantes. Dans la philosophie des versions incrémentales des méthodologies agiles, ceci nous a permis de tester les changements fonctionnalité par fonctionnalité sans tout casser d'un coup. Cela nous a aussi permis de monter en compétence sur Cypher petit à petit au fur et à mesure de l'évolution de nos besoins en complexité.

"Notre directeur technique s'émerveille encore régulièrement
de la souplesse du langage Cypher"

Presqu'un an après son lancement, quel est ton retour ? Neo4j répond-il à vos attentes ?

Neo4j répond entièrement aux attentes, et notre directeur technique, Fabián, s'émerveille encore régulièrement de la souplesse du langage Cypher. Il permet d'effectuer des requêtes très complexes, minimisant ainsi les traitements à effectuer côté serveur avant de renvoyer l'information à l'utilisateur. Nous avons en outre récemment ajouté dans Calenco une API "graphdb" qui nous permet de rajouter des requêtes sur la base Neo4j de manière dynamique, sans avoir à redémarrer le serveur. Ceci nous permet de rajouter de nouvelles fonctionnalités sur l'interface web de manière entièrement dynamique, sans aucune interruption de service pour l'utilisateur, et avec une infrastructure technique très simple.

Merci pour ces réponses. Souhaites-tu ajouter quelque chose ?

C'est un plaisir de répondre à cette interview, D-BookeR ayant joué un rôle important dans notre choix en nous parlant de cette technologie dès 2014. Et j'aime la nature récursive du cercle virtueux de cette relation : Le livre Neo4j a permis de faire évoluer Calenco qui permet d'écrire le livre...

Merci à Fabián Mandelbaum, CTO de NeoDoc, pour nous avoir fourni les graphes qui illustrent cette interview !

L'interface de Calenco