ARCHITECTURE SOCIALE

Rétro engineering des réseaux sociaux

Comment l’utilisation des APIs nous permet de mieux comprendre le fonctionnement intrinsèque d’un réseau social en fonction de la découverte de sa colonne vertébrale ?

 

Nous avons repris une partie du travail réalisé par http://www.social-nexus.net/ qui s’appelle ‘TheHiddenU’ qui s’est amusé (oui, même quand ils travaillent, quand bien même ce serait en plein jour, les G33ks s’amusent toujours) à rétroengineerer les modèles conceptuels de données (un bon vieux diagramme de classe typé UML, ça vous remue de vieux neurones ?) de 3 grosses plateformes, en fonctions des données qui pouvaient être extractées depuis les API courantes de ces services. Ces 3 plate-formes sont Facebook, LinkedIn et Google+.

Les « dessins » que nous vous présentons ci-dessous sont des schémas dont nous avons choisis assez peu arbitrairement de mettre en exergue, et si possible le plus visuellement possible un certain nombre d’entités parmi toutes les classes retrouvées et d’en faire un commentaire.

Notons tout d’abord qu’aussi étonnant que cela puisse paraitre, sur Google+ on ne retrouve pas la notion de « CIRCLE ».
Une hypothèse pourrait être qu’ils se basent sur les données dispo via des APIs, par exemple, après vérification il montre que Google+ API ne fournit pas les friends.
De la même façon, on ne retrouve pas la notion de ‘possède une APP, utilise telle ou telle APP’ dans Facebook.

Sur le dessin de Facebook, ce qui apparaît immédiatement c’est que bien que ce soit un réseau social composé de personnes, l’API montre la reconstruction d’une typologie « ultra user » centré utilisateur. De cet utilisateur nous pouvons joindre toutes les méta entités (ressources liées / connections) importantes qui définissent finalement cet utilisateur : ses feeds, ses liens, ses photos (dans des albums), où il vit, va, et vient, ses intérêts, sa géoloc en général. Ses ‘like’ et ses liens.

?? ce stade, la notion de réseau social n’apparaît car il est en contact qu’avec des ‘Friends’. Dans le diagramme, un seul trait de classe ne le figure mais c’est beaucoup : Facebook devrait atteindre le milliard de membres rapidement (c’est peut être déjà le cas si vous lisez cet article fin 2012). Par contre, si vous lisez cet article en 2300 et que vous ne connaissez pas Facebook, merci de nous faire un mail : on vous racontera.

Pourquoi le modèle relationnel de Facebook paraît-il aussi complexe ?

Une réponse : à la base, Facebook et un graphe uniformément représenté par les objets et  les connections entre objets. L’utilisateur est l’objet le plus important vu le nombre d’attributs d’identité (nom, prénom, adresse, boulots, ‘) et les connections liées (friends, albums, groups, pages, ‘). Facebook a un modèle flexible, ‘sans schéma fixé’ comme représentent les diagrammes UML, et extensible, susceptible d’ajouter d’autres types d’objet et de connection. Toute transformation du modèle graphe en modèle relationel sera compliquée et incomplète.

Pour Google+, qui est aussi un réseau social de nature différente (il est plus une extension de Google qu’un ‘simple’ concurrent de Facebook), on retrouve dans une certaine mesure la forme de la typologie des classes d’entité de Facebook. On notera cependant que pour un certain nombre de méta entité (comme les photos, les reply, les shares, les +1), Google considère qu’elles ne sont pas la propriété d’un utilisateur mais qu’elles sont l’ensemble de ses ‘activités’. Si l’on veut être encore plus précis : la présence de clés étrangères (‘actor’) dans la classe ‘activité’ semble vouloir démontrer que l’activité attachée à l’utilisateur n’est qu’une composante (puisque à ce stade on ne connait pas encore quelles sont les natures d’activités que l’on nous propose) et que c’est un réseau très centré utilisateur.

Pour LinkedIn, on a encore affaire à un réseau social mais cette fois-ci qui a deux caractéristiques : d’une part, on a une personne qui a principalement deux sous-classes : quelle scolarité et quel(s) cursus, et d’autre part, et c’est ainsi que LinkedIn semble concevoir sa notion de réseau : quels groupes ont les personnes en commun, et quelles appartenances communes les personnes ont : même entreprise …

De fait, ce dernier réseau social semi annuaire semble déformé et ce n’est pas si étonnant par rapport à nos deux réseaux sociaux G+ et FB : Linkedin semble accorder de l’importance à qui vous êtes avant de savoir à qui vous êtes lié, et ce que vous faites plutôt qu’avec qui vous le faites. C’est en ces sens que l’on peut distinguer LinkedIn des deux autres plateformes.

Références :
Google+ API
Facebook Graph API
LinkedIn API

Source

 

Article rédigé par Vincent et Xuan / aka team RetD 50A

Nos Derniers Articles

3 Commentaires

  • Reply
    Fenina Iskander
    10 mai 2013 at 19 h 23 min

    Je veux bien avoir d’autres diagrammes UML si vous permettez pour entamer la partie conception d’un site web « Rencontre a l’INSA  » un site web qui ressemble trop a un réseau social.Merci d’avance :)

    • Reply
      admin
      17 mai 2013 at 8 h 24 min

      #Transparence
      Suite à votre commentaire nous avons
      Aucune trace de « Fenina Iskander » et « Rencontre a l’INSA » sur Google. J’ai trouvé le site « Rencontre IF à INSA de Lyon » une sorte de forum (one day) entreprises & étudiants.

      En lisant son commentaire, il me semble qu’il veut avoir d’autre UMLs moins complexes ou veut extraire la partie la plus commune pour créer sa propre UML pour un site qui peut avoir des connections à-priori entre les personnes.

      Les UMLs que l’on a mis sur notre blog s’agissent des rétroengineering faits par des chercheurs en investiguant les sites de Facebook, Twitter et Lindekin il y a deux ans.
      1/ ils ne correspondent plus à l’état actuel des réseaux sociaux comme Facebook ou LindedIn qui ont switché en mode « Object Graph ». 2/ on va pas certainement dépenser notre resources et notre temps pour faire nous aussi des pareils rétroengineerings.

      Voilà

      Nicolas

  • Reply
    ELBedoui Mouoifek
    15 février 2014 at 12 h 36 min

    J’ai un projet fin d’étude en Génie informatique qui consiste à une plateforme de travail collaboratif basé sur Node.js et MongoDB
    J’ai besoin des diagrammes de classe en UMl afin d’assimiler le fonctionnement de systèmes avec le NOSql

  • Répondre

    Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.