Published by
Data Events

Il y a 13 ans -

Temps de lecture 6 minutes

NoSQL Europe : Tour d’horizon des bases de données NoSQL

Le NoSQL regroupe de nombreuses bases de données, récentes pour la plupart, qui se caractérisent par une logique de représentation de données non relationnelle et qui n’offrent donc pas une interface de requêtes en SQL.

Cassandra, Neo4j, Riak, Redis ou encore HBase sont des noms de projet qui brillent par leur présence dans l’actualité depuis quelques mois. Bien qu’ils soient tous étiquetés ‘NoSQL’ de grandes disparités les distinguent. Du fait de l’hétérogénéité de ces bases de données, des familles se sont créées pour les regrouper.

Cet article présente un tour d’horizon de l’ensemble de ces familles, de leurs caractéristiques et de leurs intérêts. Il a ensuite présenté le positionnement actuel du mouvement NoSQL, sa croissance et ce que ces nouvelles base de données peuvent apporter aux entreprises. Il s’agissait d’une session d’introduction dans la mesure où les principes théoriques de chaque famille sont largement couverts par les sessions qui suivent et que le positionnement stratégique sera débattu par la suite.

Les familles de NoSQL

Une remarque qui est revenue régulièrement lors des sessions de cette conférence est que le NoSQL est très souvent réduit au concept de simple association clé-valeur et d’accès put/get. En réalité, chaque famille apporte une forme de représentation des données différente, chacune ayant ses spécificités et simplifiant la manipulation d’un certain type de données.

Les bases de données clé-valeur

La représentation en clé-valeur est la plus simple et est très adaptée aux caches ou aux accès rapides aux informations. Elle considère la valeur stockée comme un bloc de données opaque, la base de données étant agnostique de son contenu. Ce postulat permet en général d’atteindre des performances bien supérieures dans la mesure où les lectures et écritures sont réduites à un accès disque simple.

Les implémentations les plus courantes sont Riak, Redis, Voldemort.
L’article Bases de données clé-valeur et Riak permet d’aller plus loin sur ce sujet.

Les bases de données orientées document

La représentation en document est particulièrement adaptée au monde du Web. Il s’agit d’une extension du concept de clé-valeur qui représente la valeur sous la forme d’un document. Un document contient des données organisées de manière hiérarchique à l’image de ce que permettent XML ou JSON. Étant consciente du contenu qu’elle stocke, la base de données peut alors effectuer des indexations de différents champs et offrir des requ��tes plus élaborées.

Les implémentations les plus courantes sont CouchDB et MongoDB.
L’article Bases de données orientées documents et MongoDB permet d’aller plus loin sur ce sujet.

Les bases de données orientées colonnes

La représentation orientée colonnes s’oppose à la représentation des tables dans les bases de données relationnelles. En effet, les SGBDR manipulent les colonnes d’une ligne d’une manière statique. Les bases de données orientées colonnes ont une vision bien plus flexible permettant d’avoir des colonnes différentes pour chaque ligne et de multiplier de manière conséquente le nombre de colonnes par ligne. Il en résulte une capacité à stocker des listes d’informations pour chaque clé, et à accéder à des intervalles de colonnes.

Les implémentations les plus courantes sont HBase et Cassandra.
L’article Bases de données orientées colonnes et Cassandra permet d’aller plus loin sur ce sujet.

Les bases de données orientées graphe

La représentation en graphe permet la modélisation, le stockage et la manipulation de données complexes liées par des relations non-triviales ou variables. Si le cas d’utilisation classique de ce type base de données est le stockage des informations des réseaux sociaux, elle est à même de modéliser de nombreuses situations du monde réel qui ne pourraient être représentées que de manière réductrice dans une base de données relationnelle.

Les implémentations les plus courantes sont Neo4j, HypergraphDB et FlockDB.
L’article Bases de données graphe et Neo4j permet d’aller plus loin sur ce sujet.

Les autres bases de données

D’autres types de bases de données existent tels que les bases de données objet, les bases de données hiérarchiques ou encore les datagrids que l’on différencie des systèmes de persistance clé-valeur précédemment évoqués. Ils ne sont en général pas évoqués lorsque l’on parle de NoSQL aujourd’hui.

L’adoption du NoSQL

Des développements actifs, un intérêt croissant

Les projets NoSQL sont très actifs en ce moment. Leur communauté s’élargit et leur nombre de commiteurs augmente. Parallèlement les évènements traitant de ce sujet se multiplient, l’intérêt pour ce type de stockage croît peu à peu dans les entreprises et les annonces d’adoption de ces technologies par quelques ‘grands du Web’ se sont multipliées. Ceci donne aux NoSQL un positionnement peu commun pour des technologies émergentes puisque leur bon fonctionnement dans des conditions extrêmes leur confère une fiabilité déjà reconnue.

Quelques mythes

Face à cet engouement, énumèrons quelques mythes courants sur les NoSQL qui peuvent entraîner une mauvaise utilisation :

  • Il ne s’agit pas d’une technologie de remplacement des SGBDR. Les NoSQL apportent simplement des options supplémentaires quant au mode de représentation de données utilisé pour un projet.
  • Les NoSQL sont des projets encore récents, l’outillage est donc réduit et les communautés ne sont pas comparables à celles des SGDBR courants, ce qui limitera les possibilités de réponses aux problèmes rencontrés. Ces produits sont encore très loin de la maturité de MySQL ou PostgreSQL.
  • L’intérêt d’une base de données NoSQL pour un projet ne dépend pas du volume de données qu’elle aura à manipuler. Le choix de son utilisation doit être basé sur la préférence d’un mode de représentation et non sur une forte volumétrie.
  • Il ne s’agit pas d’une solution miracle pour tout type de stockage de données. La tentative de reproduire dans une base de données NoSQL une représentation ou un comportement habituellement offert par un SGBDR aboutira probablement à une solution peu efficace.

Conclusion

Ceci conclu cette synthèse de l’état actuel du monde NoSQL. Au-delà des aspects technologiques, il s’agit par ailleurs d’un marché émergent dans lequel se sont engouffré de nombreuses startups telles que 10gen, Basho ou Neo Technology.

Les sessions suivantes ont décrit plus en détail les principes théoriques de chaque famille et les sessions de retours d’expérience en ont décrit les aspects pratiques. Ces sessions seront couvertes dans d’autres articles à venir.

Published by

Publié par Michaël Figuière

Michaël est consultant chez Xebia où il intervient notamment sur des sites Web à fort trafic. A son aise tant avec les environnements JEE qu'avec les technologies de plus bas niveau, il est spécialisé dans les architectures distribuées et les technologies innovantes telles que NoSQL, les moteurs de recherche, ou encore le data mining.

Commentaire

20 réponses pour " NoSQL Europe : Tour d’horizon des bases de données NoSQL "

  1. Published by Lorber Sebastien , Il y a 13 ans

    Et concrètement cela veut dire quoi?
    Que l’on devrait conserver son SGBD traditionnel pour la gestion et mettre en parallèle d’autres bases NoSQL pour des besoins plus spécifiques comme un cache ou un réseau social?

  2. Published by Fanf , Il y a 13 ans

    @Lorber Sebastien : tous les problèmes ne sont pas adaptés au stockage en base de données relationnelles. Donc, en effet, ca demande de prendre un peu de recul sur les différents cas d’utilisations, et c’est là qu’est la plus grosse difficulté.

    Voici un exemple de cas d’utilisation mixte SGBD/ »NoSQL » dans la vrai vie: http://debasishg.blogspot.com/2009/12/case-for-hybrid-sql-nosql-stack.html
    Et de façon plus générale, un exemple de système hétérogène: http://debasishg.blogspot.com/2010/01/new-way-to-think-of-data-storage-for.html

    @Xebia: une remarque: on oublie systématiquement les annuaires LDAP comme base de données NoSQL. Pourtant, ils ont de nombreux avantages, qui complètent bien le paysage (typiquement, pour les parties API publiques, avec pourquoi pas de la gestion de droits complexes, vu que c’est donné):
    – ils ont une organisation semi-structuré en arbre, avec des schémas pour les entrées (donc à mi-chemin d’une base de données orienté document et d’une base orientée graphe),
    – LDAP est un protocole normalisé, répandu et pour lequel il existe au moins un client/une bibliothèque pour chaque langage/OS/etc,
    – les annuaires ont des années d’existence et de débuggage derrière eux,
    – ils ont été parmi les premiers à faire pencher le compromis performance/complexité des requete vers les premières : un annuaire OpenLDAP sur un serveur correct a permis de créer une base de 6 *milliards* d’entrées, avec des dizaines de milliers de requêtes par secondes traitées – malheureusement pas de sources sur le sujet, les plus récente que je trouve date d’une éternité (2006), mais restent parlantes: http://www.openldap.org/pub/hyc/LDAPcon2007.pdf ).

    Bémols: pas de transaction, pas de langage de requêtes avec join – mais apparemment, depuis que le mouvement NoSQL prend de l’ampleur, on se rend compte que le trade-off peut être intéressant.

    Pour continuer dans l’ouverture :)

  3. Published by Dominique De Vito , Il y a 13 ans

    Ah, les bases NoSQL…

    Il y a un non-dit dans le domaine des bases de données.
    Ce non-dit concerne : les bases de données objet !
    Apparemment, elles sont frappées d’ormeta.

    Pour moi, la situation est claire : les bases NoSQL, voire les data grids, sont, en gros, un revamping des bases objet !

    Détaillons la situation:
    * Les bases NoSQL clé-valeur = stockage BLOB d’une base objet
    * Les bases NoSQL orientées document = stockage normal d’une base objet
    * Les bases NoSQL orientées colonnes = stockage colonne d’une base objet
    * Les bases NoSQL orientées graphe = stockage normal d’une base objet

    Idem, une data grid = espace de stockage objet + trigger + requêtage possible (select)
    Une data grid, c’est, pour moi, une base de données objet distribuée sans mécanisme transactionnel (encore que cela va arriver dans la v3.6 de Oracle Coherence).

    On réinvente la roue, mais sous une forme légèrement différente, et avec une autre nom.
    Et cela fonctionne mieux car on ne prend que les fonctionnalités/contraintes qui répondent à tel ou tel besoin.

    Je rejoins donc « Fanf » quand il indique de ne pas passer à la trappe les annuaires LDAP dans cette affaire !

    Et je m’étonne, et je trouve dommage, que les fournisseurs d’annuaires LDAP et de base objet n’aient pas senti le vent tourner pour revamper leurs solutions, en solutions NoSQL…

  4. Published by Dominique De Vito , Il y a 13 ans

    Quid de la convergence Cassandra/grille de données ?

    imho, Cassandra se rapproche de plus en plus d’une grille de données comme Coherence.
    Cassandra inclut des tables de hachage distribuées, partitionnement, haute disponibilité/tolérance aux pannes, map, reduce, select, etc.

    J’ai lu/recu des avis divergents à ce sujet :
    – Certains indiquant que Cassandra fonctionne bien avec un ratio lecture/écriture de 10, voire plutôt de 100 et que Cassandra devait être envisagée uniquement pour des To de données (MySQL Cluster pouvant être utilisée quand il s’agit de traiter des Go).
    – D’autres indiquant que Cassandra fonctionne bien aussi quand ce ratio n’est pas atteint, et même pour des Go, voir http://linuxfr.org/2010/04/16/26743.html

    Perso, je crois que la techno Cassandra devrait/va finir par se rapprocher encore plus du fonctionnement d’une grille de données, et pourrait être envisagée comme alternative à Oracle Coherence.

    Quel est votre avis à ce sujet ?
    Merci

    Avez-vous évalué Cassandra ?
    Sous l’angle d’une grille de données ?

  5. Published by Michael Figuière , Il y a 13 ans

    Merci à tous pour ces commentaires très constructifs.

    @Lorber Sebastien: En effet les différents acteurs du monde du NoSQL s’accordent à bien définir ces technologies en tant que « Not Only SQL » et non en tant que « No SQL ». Ainsi Facebook, le créateur de Cassandra, possède également l’une des plus grosse installation Memcached+MySQL au monde. Il s’agit donc clairement d’utiliser la bonne solution de persistance pour chaque type de données, le tout bien sûr en tenant compte des contraintes d’exploitation que les entreprises connaissent dans le monde réel…

    @Fanf: Ces arguments en faveur de LDAP sont en effet tout à fait louables. Je pense que LDAP n’est pas considéré parmi ces options de stockage alternatives liées au NoSQL en raison de sa complexité d’une part et de sa nature read mostly d’autre part. En effet un annuaire LDAP n’est pas la solution de stockage adaptée à des données qui évoluent régulièrement. Cassandra, Riak ou encore MongoDB se comportent très bien avec des ratios de lectures / écritures différents.

    @Dominique De Vito: Johnatan Ellis, le projet leader de Cassandra, affichait lors de la conférence de meilleurs performances en écriture qu’en lecture pour Cassandra. Les retours de Twitter sur Cassandra, où encore l’utilisation qu’en fait Digg, tendent à montrer qu’il est raisonnable de le considérer comme un stockage globalement tolérant à divers types de ratio lecture / écriture. En outre, notons que les performances de Cassandra sont en évolution permanentes depuis plusieurs versions.
    Les retours d’expérience sur Cassandra suivront dans d’autres articles la semaine prochaine. Et idéalement nous publierons quelques retours de nos propres expérimentations plus tard sur ce blog.

    En ce qui concerne la comparaison à Oracle Coherence et aux datagrids de manière générale, il apparaît que les cas d’utilisations sont différents bien que se recoupant légèrement. En effet Coherence est adapté au stockage d’information en mémoire, et bien qu’il offre des mécanismes optionnels de persistance sur disque ou dans un SGBDR lors de chaque écriture, il semble raisonnable de le considérer plutôt comme une solution de persistance non durable, et donc mieux adapter aux données live.
    L’alternative Open Source comparable à Coherence me semble plutôt être JBoss Infinispan, évolution de JBoss Cache en datagrid, dont le project leader affiche des objectifs très ambitieux.
    On peut considérer ces nuances de catégorisation des solutions de persistance comme minimes, mais vu l’importance capitale de cette problématique en entreprise, il est intéressant de pouvoir trouver des produits répondant très exactement au besoin requis, lorsqu’une telle exigence est de mise.

    Michael Figuière (Xebia)

  6. Published by Dominique De Vito , Il y a 13 ans

    @Michael Figuière

    Merci pour cette réponse.

    Oui, je comprends et j’avais déjà identifié JBoss Infinispan comme concurrent de Oracle Coherence, JBoss Infinispan dont la roadmap est effectivement prometteuse.

    Reste que, qui peut le plus peut le moins, et quelqu’un va bien finir par s’apercevoir qu’il y a déjà beaucoup de chose dans Cassandra et que ce serait intéressant de partir de là pour offrir une (autre) offre de grilles de données ; plutôt que de réaliser un développement de zéro, comme Hazelcast par ex (autre fournisseur d’une grille de données, mais avec une « force de frappe » largement inférieure à Oracle ou Red Hat).

  7. Published by Benoît Dissert , Il y a 13 ans

    LDAP, soit. Qu’en est-il de Lucene ? Peut-on considérer qu’un stockage dans Lucene est d’une certaine manière une persistance NoSQL ?

  8. Published by Michael Figuiere , Il y a 13 ans

    La question du classement des indexes de recherche parmi ces solutions NoSQL revient régulièrement et mérite en effet de s’y attarder !

    Clairement les indexes Lucene ne sont pas une solution de persistance à part entière. En effet, bien qu’il soit possible d’utiliser certains champs pour le stockage via Field.Store.YES, leur utilisation doit idéalement être restreinte au stockage d’informations nécessaire pour retourner les résultats d’une recherche à l’utilisateur.
    L’implémentation de ces indexes a été pensée avant tout pour la recherche et ne les rend guère adaptés aux problématiques de base de données :

    * Les données insérées dans l’index n’apparaitront pas à la lecture avant la prochaine opération IndexReader.reopen(). Et à moins d’utiliser le mode near-realtime introduit dans Lucene 2.9, il sera également nécessaire d’effectuer une opération commit() sur l’IndexWriter ou de le fermer.

    * Toutes ces opérations sont couteuses en temps car Lucene est optimisé pour favoriser la latence de recherche et non celle d’indexation.

    * L’opération updateDocument() de Lucene consiste en une suppression puis un ajout de document. Ceci n’est pas réellement gênant dans un contexte d’index de recherche, mais l’est pour une utilisation de type base de données puisque l’opération n’est pas atomique.

    * Les 3 points précédents montrent que l’indexation ne peut être assimilée à une opération d’insertion dans une base de données.

    * Les documentId de Lucene ne sont que des identifiants propres à Lucene qui changent au cours du temps, par exemple lorsque les segments d’index sont mergés. Il sera donc nécessaire de définir un champs Id spécifique dont la valorisation devra être gérée par le code applicatif.

    * Lucene n’offre pas de mécanisme de réplication. Solr et Hibernate Search proposent une réplication asynchrone, du master vers les slaves, qui introduira une latence de plusieurs minutes entre l’indexation d’un document et son apparition dans les résultats de recherche, ce qui là encore est parfaitement acceptable pour un index de recherche mais probablement pas pour une base de données.

    Cette liste, non exhaustive, montre que les indexes Lucene ne peuvent être considérés comme une solution de persistance à part entière.

    Michael Figuière (Xebia)

  9. Published by Nicolas , Il y a 13 ans

    Et BigTable dans tout ça ? Dans quelle famille le classer ?

  10. Published by Michael Figuiere , Il y a 13 ans

    HBase est une implémentation basée sur le paper BigTable. BigTable est une base de données développée en C++ et utilisée en interne chez Google ; l’implémentation n’est pas disponible.
    BigTable et HBase sont tous deux des bases de données orientées colonnes, parfois aussi appelées wide column store du fait de l’utilisation d’un grand nombre de colonnes dans ces BDD.

    Selon moi, cette famille de base de données NoSQL est la plus complexe à maitriser car il s’agit d’une manière de modéliser les données totalement différente. Je reviendrai sur ces problématiques dans un article à venir.

    Michael Figuière (Xebia)

  11. Published by Dominique De Vito , Il y a 13 ans

    J’ai posté ma vision des bases NoSQL ici: http://www.jroller.com/dmdevito/entry/thinking_about_nosql_databases_classification

    J’y redis, en partie, ce que j’ai déjà dit plus haut.

    D’autre part, avant l’étape du remplacement de la base du back-end tiers, je défends l’introduction/l’usage des bases NoSQL en les « définissant » comme bases à utiliser pour le middle tiers.

    * Etape_1 : une base NoSQL pour le middle tiers et une base SQL pour le back-end tiers (voir qques exemples d’usage dans mon post).

    * Etape_2 : la base NoSQL du middle tiers « monte en puissance » et éventuellement, remplace même la base du back-end tiers.

  12. Published by Tricosteryl , Il y a 12 ans

    J’aimerai bien qu’on nous explique avec des critères objectifs :
    – Quels sont les objectifs de cette technologie : A quoi est-elle destinée
    – Quelle est la plus-value par rapport aux SGBDR traditionnels : du point de vue de la pérénité des données, de leur sécurité, des performances, de leur utilisation par les applications…

    Le reste c’est du bavardage de geek !

  13. Published by Benoît Dissert , Il y a 12 ans

    @Tricosteryl

    J’adore le bavardage de geek. Et la plupart des personnes qui suivent le blog de Xebia aussi je pense.

    Le « bavardage de geek », comme vous dites, c’est une confrontation de points de vue sur des technologies. Si on ne s’intéresse pas aux technologies, mais uniquement aux usages que l’on prévoit, alors il n’y aurait jamais d’innovation technique, mais uniquement des innovations marketing.

    Il est impossible d’être architecte logiciel sans aimer le bavardage de geek (c’est une condition sine qua none).

    Le NoSQL n’est pas un produit ou une solution, mais un mouvement, un ensemble de technologies de persistances (il me semble que l’article est clair la dessus), qui ont uniquement en commun d’essayer de ne pas respecter la contrainte d’être des SGBDR, et qui, bénéficient grâce à cela de caractéristiques intéressantes, comme :
    – de meilleures performances
    – une tolérance au partitionnement réseau
    – une meilleure adéquation entre la technologie et le besoin de persistance

  14. Published by Tricosteryl , Il y a 12 ans

    Merci infiniement :)

  16. Published by Benoît Dissert , Il y a 11 ans

    @DominiqueDeVito

    On en avait déjà parlé au NoSQL UG (et on a eu des présentation Gigaspace), les problématiques techniques sont, à la base, essentiellement les mêmes, sauf que :
    – dans les DataGrid, on remplace les tuyaux réseaux par des bus mémoire
    – les interfaces programmatiques sont, en générale natives Java (au lieu d’API REST ou protocole/couche transport)
    – on met les machines les plus proches les unes des autres, pour avoir des tout petits bus super rapides

  17. Published by Cyrille Le Clerc , Il y a 11 ans

    @Dominique,

    J’ai eu la même impression que toi il y a un an. Nati Shalom (Gigaspaces) m’a convaincu et je pense aujourd’hui que les In Memory Data Grids (IMDG) resteront « in memory » sur la niche de l’hyper-performance alors que le NoSQL « sur disque » prendra le non-relationnel à performances normales et les fortes volumétries (BigData). Les cultures disque et mémoire sont trop différentes.

    Nous demanderons à Nati de nous expliquer sa motivation fin Janvier lors de la soirée « Concevez une application Data-Grid/NoSQL hautement scalable avec Nati Shalom, fondateur et CTO Gigaspaces » qui dérape sur le planning mais aura bien lieu. Merci de votre indulgence pour ce retard :-)

    Pourquoi je pense que les In Memory Data Grid et les NoSQL ne convergeront pas :

    * Dans le monde relationnel, les base de données mémoire (TimesTen, SolidDB, …) n’ont pas convergé avec les bases de données classiques sur disque.

    * Les In Memory Data Grid sont cantonnées à un marché de niche du fait de leur coût et complexité d’utilisation. Très grande complexité aussi bien côté DEV que côté OPS :
    ** DEV : bouleversement culturel de mettre du traitement au coeur de la donnée, défi de l’évolutivité des données (POF en Coherence, etc), difficulté des tests, …
    ** OPS : manager des dizaines de petites JVMs (ca devrait changer bientôt …), perpetuel défi du full GC qui prend trop de temps, déploiement noeud après noeud pour ne pas avoir à recharger les données, …
    ** DevOPS : le chargement ‘initial’ de la grille qui n’arrive pas qu’une fois car les déploiement dans la vraie vie se font en général par un arrêt complet. Cette réalité interdit les scénarios d’IMDG de centaines de Go au commun des mortels.

    * Les IMDG actuelles (Coherence, Gigaspaces, Gemfire & Websphere eXtreme Scale) n’ont pas été designées pour supporter la lenteur d’un accès disque lors de leurs traitements. Elles ont été designée pour l’hyper vitesse. Oracle a trouvé une solution d’offload avec des SSD.
    ** L’offload SSD des In Memory Data Grid est une sorte de « panic button » pour éviter la perte de données des OutOfMemoryError, l’esprit de ces produits n’est pas de faire du traitement sur ces données offloadées. L’offload SSD n’est pas un mécanisme de pagination, c’est une sécurité.
    ** Un cas où l’offload SSD trouve sa place en fonctionnement nominal interactif : quand l’IMDG est utilisée en « distributed cache » mais étant donné le prix et les complexités d’exploitations, je regarderais alors des grosses distributed hashtables (Riak, Redis, etc).

    Pour résumer, je pense que
    ** Le NoSQL « sur disque » traitera BigData et le non relationnel « classique« , le non-relationnel qui n’a pas besoin d’hyper performance,
    ** les IMDG vont rester cantonnées à un marché de niche de l’hyper performance (finance de marché, ecommerce à très fort traffic pour encaisser Cyber Monday, …).

    Nous pourrons en rediscuter plus en détails avec Nati Shalom en Janvier !

    Cyrille qui a codé du Coherence ce matin encore :-)

  18. Published by Cyrille Le Clerc , Il y a 11 ans

    Une remarque, j’avais trouvé très sexy le slogan « RAM is the new disk… ».

    Maintenant que j’ai une application In Memory Data Grid en production, je n’y crois plus, je dirais plutôt que la RAM, c’est comme les spectacles d’assiettes chinoises au cirque :-)


    This is RAM !

  19. Published by slimBI , Il y a 10 ans

    Bonjour,
    Je vous remercie pour cet article.
    Mais j’aimerai savoir une chose, quel est le langage de requette de NoSQL?? et si il y en a un, quelle est sa syntaxe, comment faire pour l’apprendre.

    Je suis débutant et ça m’intéresse beaucoup.

    Je vous remercie par avance.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.

REJOIGNEZ-NOUS