Note de lecture : A Little Riak Book 2.0, par Eric Redmond & John Daily

Note : 2 ; Un livre à décoder plutôt qu’à lire !

Edité à compte d’auteur par un (gros) contributeur Riak, ce livre est assurément petit car il dépasse à peine la centaine de pages. Il n’a pas non plus d’ISBN ce qui est hélas un premier indice sur sa qualité éditoriale. Autant le dire tout de suite : elle est médiocre.

Je m’attendais à un petit tutorial pour mettre le pied à l’étrier. Si c’est effectivement la cible de ce texte, l’objectif est quand à lui bien raté. La prose fait de nombreux raccourcis qui nous font rater une bonne compréhension. Ainsi l’articulation entre bucket et bucket-type reste-t-elle nébuleuse. L’auteur semble parler de clés hiérarchiques mais … finalement non. Quand aux « rings » on en est encore à se demander comment cela fonctionne. L’ouvrage n’est pas dénué d’illustration ou d’extraits de code ou de configuration, mais c’est plutôt du matériel brut ne soulignant pas ce qu’il y a à voir. Bref : encore raté.

Le chapitre 1 est une courte introduction. Il liste les fonctionnalité de Riak 1 et met en évidence les nouveautés de Riak 2 avec des concepts qui ne sont pas expliqués, donc incompréhensibles. On est bien avancés. Le chapitre 2 aborde les concepts : ce devrait être le chapitre le plus intéressant. Mais là aussi les auteurs parviennent à introduire de la confusion. Il reste toutefois le chapitre le plus instructif.

Lire la suite

Publicités

Note de lecture : Neo4J : Des données et des graphes, 2. Déploiement, par Sylvain Roussy, Nicolas Rouyer & Nicolas Mervaillie

Note : 7 ; Au théâtre ce soir, avec Sylvain, Patricia, Philippe, Christophe et Brian !

Ce second volume ne s’inscrit pas directement dans la continuité du premier. Le prérequis en est un peu d’expérience solide de Neo4J, lorsque le précédent s’adressait aux grands débutants. En fait, le titre induit un peu en erreur : il ne s’agit pas seulement d’adresser le volet exploitation (qui comptera au nombre des sujets), mais en fait d’aborder son utilisation dans un véritable cas d’étude !

On compte 220 pages pour ce volume de format plutôt réduit, donc plutôt environ 170 pages dans un format plus classique. A cela il faudra rajouter les annexes dont nous reparlerons. Pour cette partie principale on comptera seulement 5 chapitres. Je préfère généralement des chapitres assez courts, ce n’est pas le cas ici, mais le style adopté efface ce que je considère habituellement comme un inconvénient. Parlons-en justement. Le story telling est une technique puissante, qui a la vertu de nous immerger dans le texte, mais peu d’auteurs l’emploient. Ceux de ce volume vont plus loin : l’ensemble du livre (hors annexes) est une pièce de théâtre où l’on découvre la mise en œuvre de Neo4J avec ses fonctionnalités dans les échanges entre les impétrants. On soupçonnera que Sylvain, le sénior de l’équipe ressemble beaucoup à l’auteur principal dont il partage le prénom. Sans doute Christophe et Philippe incarnent-ils donc les deux autres co-auteurs ? Patricia la chef de projet et Ilko le commercial ont des rôles plus marginaux qui servent à l’introduction et au débriefe de chaque chapitre (deux excellentes idées, au passage). N’oublions pas non plus Brian, le stagiaire, qui lui semble complètement idiot.

Lire la suite

Note de lecture : Neo4J : Des données et des graphes, 1. Prise en main, par Sylvain Roussy

Note : 5 ; Un tutorial (vraiment) amélioré.

On a besoin de tutoriaux. Mais en tant que livres, ils n’atteignent pas chez moi des notes très élevées. Mais il arrive qu’on en rencontre de très correctes. Ce volume est de ceux-ci. L’objet lui-même accuse un format plus petit que les éditions habituelles du même genre, tout en étant nettement plus grand que le format poche. Pratique pour lire dans les transports. Toutefois, si la finition extérieure est correcte, la qualité est un peu faible. C’est probablement le prix à payer d’un tout petit éditeur. C’est malheureusement aussi vrai de la mise en page et de l’impression qui sont assez moyennes. Mention spéciale aux polices grisées vraiment peu lisibles. Pour les diagrammes c’est pire : ils se décodent avec peine et le texte à l’intérieur est illisible.
Heureusement pour nous, le fond prédomine sur la forme et là c’est nettement mieux.

Comme je l’ai dit, l’ouvrage est de petit format. Il compte 220 pages, mais seulement 190 pour le texte principal, le reste constituant des annexes. De ces dernières, seul l’aide-mémoire Cypher m’a semblé de quelque utilité. Le texte s’adresse aux grands débutants, aussi si l’on a quelques connaissances de Neo4J, le livre s’avale assez vite. Tant mieux car question découpage, ce n’est pas ça : on compte seulement 4 chapitres pour tout le livre !

Le premier chapitre ne compte que 15 pages et nous permet de découvrir Neo4J. Il couvre bien les éléments de base : ce qu’est une base NoSQL en général et une base graphe en particulier, les différentes versions de Neo4J et les bases de son installation. Là où ça se gâte, c’est lorsque l’auteur nous propose des requêtes de base sur l’outil, mais sans expliquer celles-ci. Il s’agit d’un choix délibéré, mais qui me laisse dans l’expectative.

Lire la suite

Note de lecture : Elasticsearch in Action, par Radu Gheorghe, Matthew Lee Hinman & Roy Russo

Note : 3 ; Aussi passionnant qu’un manuel de référence !

J’aime bien la série « in action » de chez Manning. On n’y trouve pas les œuvres du siècle, mais grâce à un processus et une discipline éditoriale très strictes, ils sont souvent très bons, plus rarement moyens et rarement dessous. Hélas, le présent ouvrage tombe dans cette dernière catégorie. Je voulais en savoir plus sur Elasticsearch, en comprendre le paradigme, l’architecture et les cas d’utilisation. Les 370 pages de l’ouvrage ont fait un travail médiocre à cet égard. Passé les 3, peut-être les 4 premiers chapitres, ce ne furent plus que litanies pénibles de fonctionnalités, des lignes de cUrl, avec ses Json en entrée et en sortie, le tout jusqu’au bord de l’étouffement. Faisons un (rapide tour de ces 11 chapitres.

Le texte est découpé en 2 parties. La première d’entre-elle contient la majeure partie du texte, c’est à dire 8 chapitres, soit près de 260 pages. Les 20 pages du 1er chapitre donnent une vue de haut niveau du produit, ainsi que des informations pour l’installation. Rien de bien concret, mais c’est agréable à lire. Le chapitre suivant consacre ses 30 pages à rentrer dans le dur : l’architecture et la gestion des clusters, mais aussi la gestion des documents, des index et des shards. Il s’agit probablement de mon chapitre préféré.

Presque 30 pages sont également dédiées au chapitre 3 : création, mise à jour et suppression des index. Si on commence quelque peu avec le « mode catalogue », on n’en souffre pas trop à cette étape, les explications restant claires, et puis on est au cœur du produit ! L’horizon s’assombrit plus avec le chapitre 4 et l’exploration des différentes recherches et des options. Beaucoup de requêtes et de Json, déjà…

Lire la suite

Note de lecture : Storm Applied, par Sean T. Allen, Matthew Jankowski & Peter Pathirana

Note : 6 ; Clair sur la mise en jambe, mais insuffisant sur la gestion en production

J’ai une affection particulière pour Storm, car j’ai activement participé à l’amener dans un projet à une époque où les frameworks Big Data temps réel et plus particulièrement Storm n’étaient pas pris pour acquis. Il aura fallu attendre près de 2 ans de plus pour voir apparaître un ouvrage dédié de bonne facture. Comme nous le verrons, ce dernier ne se limite pas à Storm sensu-stricto.

Le présent ouvrage accuse ses 250 pages totalisant 9 chapitres. Des chapitre relativement longs en moyenne selon mon standard, donc. Le premier d’entre eux ne l’est pas, car il ne pèse que 10 pages. C’est une introduction de haut niveau dont le but est de camper la place de Storm dans le mode du Big Data, et plus précisément dans celui du Big Data temps réel que les auteurs re-segmentent en « stream » et « micro-batching ». En passant, les auteurs positionnent Storm par rapport non seulement à Hadoop, mais à Spark, Samza et Kafka Stream.

Le chapitre 2 est d’avantage dédié architecture et présente les concepts centraux de Storm : Typologie, Tuples, Bolts et Spout. Le tout est abondamment illustré, y compris par des extraits de codes qui ont le bon goût de ne pas être trop longs. L’homme pressé qui n’a pas trop de temps à consacrer pour comprendre Storm y trouvera à se nourrir ! J’avoue que je trouve ce chapitre particulièrement réussi.

Lire la suite

Note de lecture : Making Sense of NoSQL, par Dan McCreary & Ann Kelly

Note 4 ; NoSQL plus ou moins décrypté pour le manager

Voici un ouvrage « à priori » destiné aux managers. En tout cas son objectif est de donner une image du paysage NoSQL sans nécessité de voir une ligne de code. Dans le principe, le livre atteint son objectif : il couvre les différents types de bases NoSQL, avec toutefois un biais marqué vers les bases XML (qui ne sont généralement pas considérées comme des bases NoSQL), ces dernières ayant droit à leur propre chapitre contrairement aux autres ! Mais le texte me laisse quand même un sentiment d’inachevé, il ne permet pas vraiment de comprendre les patterns d’usage des différentes bases par manque de parti pris.

L’ouvrage est assez conséquent pour une introduction. Il compte 275 pages réparties sur 12 chapitres. Ceux-ci sont eux-mêmes regroupés en 4 parties. La première d’entre-elle est une introduction, courte d’un peu plus de 30 pages et de deux chapitres. Le premier répond au « pourquoi » en exposant succinctement quelques cas d’études des grands du Web, c’est hélas très superficiel. Le second s’attaque aux concepts : documents, sharding, théorème de CAP, cache, etc… C’est un peu brouillon et j’aurais préféré y voir une bonne exposition des typologies de bases.

Lire la suite

Waiting for the Storm…

Le Storm User Group, c’est une initiative de quelques collègues autour du « big data temps réel ». Aujourd’hui, nous parlons de Storm et quelques infrastructures qui peuvent s’y connecter. Demain, il s’agira peut-être de Spark ou d’autres…

Halte là ! Je vais peut-être un peu vite ? Et d’abord, Storm, qu’est-ce que c’est ? Voilà une question à laquelle une partie de cette première rencontre va être consacrée.

Oui, Storm, qu’est-ce que c’est ?

C’est Florian Hussonois qui va répondre à cette question. Nous pourrions résumer la chose en déclarant simplement qu’il s’agit d’un Hadoop « temps réel ». Il s’agit en quelque sorte d’un middleware permettant le traitement d’évènements en mode flux.

Un (petit) peu d’historique

Storm a été développé par Nathan Marz chez BackType en 2011. La société est rachetée ensuite par Twitter qui promeut le projet et le passe en Open-Source. La première release officielle date de 2011. En Septembre 2014, le projet devient officiellement « Apache Top Level Project » alors même qu’il n’a pas encore atteint la release 1.0 !

Ecrit principalement en Clojure et en Java, ce « processeur d’évènements » est conçu pour traiter un flux de très nombreux évènements (des tuples dans la terminologie Storm), à savoir 1 millions de tuples par seconde et par noeud (1 seul coeur processeur), avec tolérance aux fautes, gestion de la scalabilité et garantie de traitement !

image

Lire la suite

Neo4J contre SAP Hana

Il y avait un petit moment que l’on n’avait pas eu de meetup Neo4J sur Paris ! C’est donc avec une façon un peu provocante d’aborder un sujet à connotation BI que nous avons été invités !

Nous étions environ 30 à nous rendre ainsi dans le showroom Zenika.

image

Introduction

Cédric Fauvet, toujours égal à lui-même nous fait son habituelle introduction sur les graphes. Presque habituelle, devrais-je dire, car il fait un peu évoluer son propos de meetup en meetup, tout comme son support.

image

Aujourd’hui, le spectre des problèmes couverts par les bases orientées graphes couvre :

  • La collaboration
  • Le SCM
  • L’analyse géo-spatiale
  • L’étude des interactions moléculaires
  • L’analyse d’impact
  • Le MDM
  • La gestion de lignes-produit
  • Et bien entendu la recommandation et les liens sociaux !

En Juin, Neo4J France devrait nous gratifier d’une présentation d’un projet « Dropbox-like » réalisé par des étudiants !

Cédric attire également notre attention sur le talk de Volker Pacher expliquant pourquoi Neo4J augmentait la capacité de delivery de Shutl (acquis depuis par eBay).

Il est l’heure de la pause pizza, nous allons bientôt attaquer la pièce maîtresse de la soirée !

image

Analyse des tickets de caisse avec Neo4J

Nicolas Mervaillies et Charles Besselièvre nous présentent le projet qu’ils ont développé pour « un grand client retail ». Il s’agit d’un petit projet, c’est à dire moins de 100 j/h, qui devait être développé rapidement. Sur les projets analytiques orientés « real time », cette enseigne s’appuie généralement sur SAP Hana. Mais ce projet tactique présente des échéances de temps incompatibles avec ce type de projet, plus adapté à des solutions légères menées en agile.

image

La problématique est essentiellement simple : trouver des corrélations d’achats. Vous savez, celles qui ont permit de déterminer que les couches culottes sont souvent achetées en même temps que le bière le samedi ou qui ont permit à une enseigne d’apprendre via des bons d’achat à une jeune fille qu’elle était enceinte avant qu’elle même ne le sache ! Ici les corrélations doivent être croisées entre magasins et entre régions. Pour chaque magasin, il faut compter une volumétrie de 300 millions de lignes de ticket par an.

Phase 0 : Prototypage

Pour cela on utilise simplement la console Neo4J ! En fait, on ne représente pas chaque ligne d’achat en liaison avec le ticket de caisse : on agrège ces lignes par sous-familles. Bien sûr, les tickets sont associés à une date, un client et un magasin.

Grâce à cela, on voit avec Cypher si l’on parvient à produire les analyses que l’on souhaite.

Phase 1 : Construction initiale

Premier fonctionnement en production : les données de ticket de caisse sont récupérés tous les mois et injectés avec Spring Batch. Le client peut agréger les données en live via des requêtes Cypher : dans le temps, par famille de produits, par magasin.

Les couplages repérés avec de forts pourcentages sont donc mis en exergue dans certains magasins, on compare les éléments différenciants des magasins ayant de moins bons taux de corrélation !

On a toutefois un problème : trop de lenteurs, dû aux fortes volumétries, mais aussi au déploiement de Neo4J sur des serveurs virtualisés. La virtualisation et les bases de données, ce n’est pas le grand amour, même si certains ingénieurs système essaient de se convaincre du contraire !

Phase 2 : Focus sur le « top 15 »

En analysant les données des différents magasins, on perçoit dans le temps des réccurrences d’association, notamment dans le « top 15 ». Nos artistes choisissent donc de précalculer les associations significatives, celles correspondant au « top 50 » de chaque magasin, mais sans Marc Toesca !

Phase 3 : Optimisation de production

En dernière phase, il faut finalement réaliser des optimisations purement de production : gestion de l’infrastructure, mise en place de cache, etc…

En conclusion…

L’utilisation de Neo4J est parfaitement adaptée à ce type de projet tactique : on a la rapidité de de mise en place et la vitesse d’exécution de ce projet typique d’un projet agile ! Par rapport à SAP Hana, on gagne réellement en time to market !

L’équipe a aussi développé un front-end pour faciliter l’utilisation du système. Mais à la limite, cela aurait pu être omis !

Concernant l’infra : elle a été gérée complètement en interne pour des raisons de non exposition de données sensibles. Toutefois, on a une machine puissante qui ne sert que quelques heures, une fois par mois ! Ce type de configuration se marrie donc bien avec le Cloud.

Enfin, l’aspect communautaire de Neo4J permettant de trouver de l’aide sur les forum a été un plus important !

Faute de disposer du support de présentation, je vous propose ici l’enregistrement de la même session qui s’est déroulée au meetup Neo4J Lillois !

Ce que j’en ai pensé

C’est probablement le meetup Neo4J le plus interactif et le plus convivial auquel j’ai pu assister. Les interventions fort pertinentes d’un connaisseur SAP Hana ont été un gros plus dans la discussion, surtout quand, comme lui, on connait et sait reconnaitre les qualités de ce système. Il est là, juste derrière moi.

Pour clore ce compte-rendu et donner un avis éclairé sur cette confrontation, je le citerai :

« Remplaçons notre argent par notre intelligence ».

Cela me rappelle un peu un slogan des années 70 où il était question de pétrole…

… Et Neo4J devint CMS !

Lors de ce Meetup Neo4J de Janvier, toujours dans le zLocalHost de Zenika, nous avons pu découvrir Structr, et comment il adresse la problématique du CMS. Ou du moins, nous allons le faire.

Cédric Fauvet au pas de charge !

Cédric commence par sa très classique introduction à Neo4J. Introduction un peu écourtée d’ailleurs : c’était la soirée des problèmes techniques et il a fallu rattraper le temps perdu.

Le temps tout de même de donner quelques nouvelles de la communauté et de l’actualité. On s’attardera quelques instants sur la dernière référence Française : Meetic ! Bien entendu, comme pour Viadeo, le but est la recherche d’adéquation de profiles. Ce n’est d’ailleurs pas une première expérience pour Neo4J qui a équipé d’autres sites de rencontre avant de s’occuper du n°1 européen.

Autre nouvelle intéressante : la mise à disposition de cours en ligne ! J’ai hâte d’aller voir ça…

Structr

Axel Morgner est fondateur de Structr, il est venu spécialement de Frankfort pour évoquer son usage de Neo4J. Après avoir longtemps travaillé dans le domaine du CMS, il a décidé de changer d’horizon, de faire autre chose. Il a découvert Neo4J, et a décidé de construire avec … un CMS !

image

Structr c’est une société mais aussi un logiciel open-source. La motivation ? Construire des sites web dynamiques avec du contenu. La première release de la bête est apparue en 2011.

La première itération : c’est une classique webapp standalone, dont la partie front utilise freemarker.

Les choses changent radicalement en seconde itération ! C’est d’abord un changement de scope : Structr devient un pur back-end, le front-end est abandonné ! Le produit assure un mapping bidirectionnel entre JSON et le graphe. Et le produit intègre une notion de schéma et de contraintes (avec même une gestion des suppressions en cascade), des choses qui vont bien plus loin que les évolutions apportées par Neo4J 2.0 !

L’interface utilisateur revient en 3ème itération, mais elle s’est faite HTML5 ! Elle permet l’édition sur place, la visualisation des liens entre pages, etc…

Démo time !

Axel nous fait bien sûr une petite visite guidée de la bête. On commence fièrement par un import de page que l’outil digère pour le transformer en graphe. On peut utiliser alors l’édition sur place pour importer ou saisir du contenue … ou faire référence à du contenu dans le graphe, via des requêtes Cypher, par exemple !

image

La sécurité n’est pas en reste et elle se configure sur les noeuds. Elle est bien sûr transitive, suivant les liens “contains”. L’IHM est aussi synchronisée entre les clients, permettant l’édition de contenu collaboratif.
Mais tout cela, c’est du statique. Du “boring stuff” comme le dit Axel. Structr gère la dynamicité du contenu, en partie du fait qu’il ne gère pas de cache et se repose sur la performance de neo4J. L’une des clés est la référence qui peut être faite depuis les pages vers du contenu structuré lui-même dans le graphe.

Pour cela il faut créer un projet “data type”. C’est lui qui permet la structuration des données et les contraintes dont nous avons parlé plus haut. On y crée aussi des bindings qui peuvent être référencés par des noms symboliques.

L’une des question que je me posais pendant que la démo se déroulait concernait les contenu volumineux, de type “blob”. On sait que Neo4J n’est pas fait pour cela. Qu’a cela ne tienne, les data types peuvent référencer des fichiers ou même des répertoires ! Au-delà de cela, il y a aussi des concepts de “web components” et de “shared components area”, mais ne m’en demandez pas plus, car j’ai un peu perdu le fil à ce moment là !

Malgré quelques petits accrocs lors de la démo, il faut avouer que cette gestion de contenu est pour le moins étonnante et résolument différente de ce qui se fait !

Teasing

Cédric souhaitait innover en donnant une minute de parole au débotté à des participants du Meetup ayant un projet avec Neo4J.

Un étudiant de Supinfo Lille (désolé, je n’ai pas noté son nom) nous a donc parlé de son projet d’étude : un “Dropbox like” intégrant une dimension sociale de partage. L’utilisation de Neo4J permet ici de représenter les structures de fichiers, répertoires, partages et droits, tandis que les contenus eux-même peuvent être répartis sur différents serveurs de stockages, ces contenus étant simplement référencés dans le graphe.

Quand Sébastien Just est venu nous parler de Seij, j’ai cru que Structr venait de trouver son frère jumeau ! J’ai pu discuter un peu avec Sébastien et suis maintenant convaincu que ce n’est pas le cas. Certes les deux applications partagent nombre de concepts : le CMS basé sur des graphes Neo4J et la possibilité de constituer son contenu en assemblant les éléments issus des noeuds. Mais là où Structr s’appuie sur une structuration et un typage fort, Seij s’enorgueillis de son approche “free form”, un peu comme si l’on avait un Excel pour la gestion de contenu. Des concepts très proches mais un ciblage client très différents en font deux produits qui ne se comparent finalement pas. J’espère que Sébastien aura l’occasion de revenir nous le présenter et nous en parler !

Meetup Neo4J de décembre 2013 : Des recommandations en temps réel avec Recolytic

Ce sont deux sujets qui seront abordés lors de ce meetup. En effet, en introduction à la présentation de Rochdi Chakroun, Cédric Fauvet a évoqué le concours GraphGist, concours où il y a peu à gagner. Mais ce n’est pas l’objectif. Ici, il s’agit plutôt de monter de petits cas d’utilisation originaux. Neo4J souhaite visiblement pouvoir montrer beaucoup de cas d’utilisation créatifs et variés de sa base de données.

Cédric Fauvet débute généralement ces rencontres par une présentation de la société, des cas d’usage de Neo4… Celle-ci ne fit pas exception.

image

Bien sûr il nous présente les mêmes concepts, les même cas d’utilisation ou presque, mais le propos évolue quand même un peu à chaque fois. Et de plus, il y avait aujourd’hui Neo4J 2.0 à évoquer ! Il n’y a rien non plus de rébarbatif dans sa façon de présenter les choses. Après tout, avant d’être responsable de Neo4J France, Cédric était un développeur comme nous !

Mais avant de passer à la suite : Pizza time !

image

Recolytic

Rochdi Chakroun est architecte logiciel chez Vente Privée. Mais ce n’est pas à ce titre qu’il venait aujourd’hui, mais plutôt pour présenter le fruit d’un projet personnel : Recolytic.

image

Le constat de Rochdi est que les systèmes de recommandation sont aujourd’hui obscures : "nous allons faire progresser votre chiffre d’affaire, vous n’avez pas à savoir comment". Une position qu’il juge insupportable au regard de l’aspect stratégique de ce traitement.

Autre aspect que l’orateur a voulu adresser : la recommandation en temps réel. Les moteurs de recommandation s’appuient sur la plupart sur des algorithmes et des traitements de machine learning qui demandent de longs temps de traitement en différé pour fournir de nouveaux modèles mis à jour.

Recolytic se veut performant, facile à intégrer et transparent sur la stratégie. Il s’appuie bien sûr sur Neo4J, ici le modèle c’est le graphe. Et ce graphe est composé de triplets utilisateur – action -ressource. Il est à noter que Rocolytic est complètement agnostique sur la nature des ressources. Des poids peuvent être accorder aux actions ou aux ressources, par exemple pour donner plus d’importance à un achat par rapport à une consultation.

Pour ce qui est des APIs, Rocolytic en propose 3 catégories :

  1. Les API de collecte : pour récupérer les actions des utilisateurs.
  2. Les APi de recommandation. Elles permettent plusieurs stratégies.
  3. Les API de mesure. Afin de mesurer après coup la pertinence de recommandations et ajuster le paramétrage en conséquence.

A l’initialisation de Recolytic, on débute sans informations de l’utilisateur. Il est donc pertinent de commencer avec la stratégie par défaut : les plus populaires.

Il sera ensuite possible de basculer vers une autre stratégie, par exemple la similarité de panier.

Pour démontrer le produit, Rochdi nous propose de nous promener dans un site d’e-commerce de démonstration.
Rochdi ne s’est pas encore fixé d’objectif pour les prochaines étapes : en faire un open-source, ou une startup… Il avoue surtout avoir besoin de récupérer de ses efforts. On le comprend : il a quand même réalisé tout cela en gardant son activité chez Vente Privée !

En Janvier, nous rencontrerons un autre cas d’utilisation avec Structr.