Lorsqu’elle avait principalement lieu oralement, au téléphone, ou par radio, la com- munication de crise était éphémère, volatile. Sur les médias sociaux, en revanche, toute activité de communication en situation de crise produit des traces facilement accessible aux chercheurs (Palen et al., 2009). Dans cette section, nous décrivons les méthodes et les outils permettant de collecter des traces d’usage sur différentes plateformes de médias sociaux. Nous présentons ensuite quelques analyses pouvant être réalisées à partir de ces données, mais aussi les limites et biais d’interprétation qui peuvent y être associés.
3.2.1
Collecte des traces d’usages
La plupart des services web actuels, dont les médias sociaux, constituent des « silos informationnels » : l’information est stockée de manière centralisée, laissant très peu
de contrôle à l’utilisateur33 (Yeung, Liccardi, Lu, Seneviratne, & Berners-Lee, 2009).
Beaucoup de ces plateformes disposent cependant d’interfaces de programmation (API) donnant accès à certaines de leurs données, pour permettre à des tiers de développer
30. « [I started to be interested in measuring] when I heard my friends, having three kids, were
worrying about radiation ... [I] wanted to know if my neighbourhood was safe enough or not. And [I also] wanted to have my own resource to make decisions » (traduction personnelle)
31. https://www.facebook.com/groups/225718720808063/
32. Une petite communauté anglophone est également représentée sur les médias sociaux mais beau- coup moins active : https://www.facebook.com/groups/211114495683282/
33. Par exemple pour supprimer complètement les informations le concernant, ou les transférer vers un autre service
des programmes interagissant avec la plateforme. Ces API peuvent également être uti- lisées par les chercheurs pour collecter des traces d’usage des médias sociaux : données relatives aux profils des utilisateurs, connexions et interactions entre les utilisateurs, médias et messages publiés. Selon les plateformes, l’accès à certaines informations re- quiert des autorisations spécifiques ou l’approbation explicite de l’utilisateur dont les données sont collectées.
La collecte de données à travers les API constitue un échange client-serveur – de type push ou pull – entre le chercheur et la plateforme de médias social. Dans le cas des interfaces pull, les plus fréquentes, le client est à l’initiative : le chercheur envoie une requête au serveur (la plateforme de média social) qui, en réponse, fournit les données appropriées (ou, le cas échéant, un message d’erreur) (Figure 3.4a). Certains sites proposent également des interfaces push dédiées la collecte de données en temps
réel (e.g. les messages d’un utilisateur au fur et à mesure qu’il les publie)34 : après une
première requête du client, c’est le serveur qui notifie au client l’existence de nouveaux
contenus. Plusieurs médias sociaux (e.g. Flickr35, Instagram36) implémentent pour
cela le protocole PubSubHubHub37, qui définit un écosystème d’éditeurs (Publisher ),
d’abonnés (Subscriber ) et de relais (Hub). Pour recevoir les derniers contenus publiés par un éditeur, l’utilisateur envoie une requête d’abonnement à un relais. L’éditeur, de son côté, se contente de notifier le relais lorsqu’il publie un nouveau contenu et le relais transmet l’information à ses abonnés (Figure 3.4b). Twitter, en revanche, utilise une interface push spécifique : la requête initiale du client ouvre une connexion permanente, à travers laquelle le serveur envoie en continu les nouveaux contenus à mesure qu’ils
sont publiés38 (Figure 3.4c).
Pour aider les développeurs, les plateformes de médias sociaux fournissent généra- lement quelques implémentations de leurs API sous forme de librairies dans un langage de programmation courant. Des développeurs tiers se chargent ensuite de compléter l’offre en proposant des versions dans d’autres langages. Pour faciliter la collecte des données, des outils « clefs en main » ont été développés, dont certains spécifiquement à
l’usage des chercheurs. Netvizz39, par exemple, permettait d’extraire des données, no-
34. Avec un système pull, la collecte en temps réel peut être simulée en envoyant régulièrement des requêtes au serveur pour obtenir les dernières données disponibles. Plus l’on souhaite s’approcher du temps réel, plus la fréquence de requête devra être élevée, occasionnant un usage excessif des ressources du client comme du serveur (processeur, réseau).
35. https://www.flickr.com/services/api/flickr.push.subscribe.html 36. https://www.instagram.com/developer/subscriptions/
37. https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html 38. https://dev.twitter.com/streaming/overview
(a) Interaction « push » classique
(b) Distribution en temps réel via PubSubHubHub
(c) Collecte en temps réel sur Twitter
Figure 3.4 – Modes d’interaction avec les API des médias sociaux
tamment relatives aux réseaux d’utilisateurs, sur Facebook40(Rieder, 2013). Sur Twit-
ter, l’offre est particulièrement riche, avec entre autres YourTwapperKeeper41 (Bruns
& Liang, 2012) et DMI-TCAT42 (Digital Methods Initiative Twitter Capture and Ana-
lysis Toolset) (Borra & Rieder, 2014), particulièrement adaptés à la collecte en temps
réel, AIDR43 (Artificial Intelligence for Disaster Response), classifiant les tweets re-
latifs à des crises, (Imran, Castillo, Lucas, Meier, & Vieweg, 2014), ou encore Chorus
Analytics44(Brooker, Barnett, Cribbin, & Sharma, 2015). Enfin, certains autres outils,
tels que NodeXL45, sont capables de collecter des données sur plusieurs plateformes de
médias sociaux simultanément (Smith et al., 2010)46.
40. Certaines fonctionnalités ont depuis été retirées, suites à des changements dans le fonctionnement des API de Facebook
41. https://github.com/540co/yourTwapperKeeper
42. https://github.com/digitalmethodsinitiative/dmi-tcat 43. http://aidr.qcri.org/
44. http://chorusanalytics.co.uk/ 45. https://nodexl.codeplex.com/
46. Une liste assez complète d’outils pour collecter des données sur les médias sociaux, mais aussi pour traiter et analyser ces données, peut être trouvée ici : https://wiki.digitalmethods.net/ Dmi/ToolDatabase
Figure 3.5 – Architecture du système de collecte de tweets DMI-TCAT47
3.2.2
Métriques et outils d’analyse
Les données et métadonnées collectées à l’aide des API offrent de nombreuses pos- sibilités pour l’analyse des profils utilisateurs et des messages qu’ils échangent (Bruns & Liang, 2012). Ainsi, dans le cas de Twitter, les pourcentages de retweets, de réponses ou de messages contenants des URL permettent de déterminer les types d’échanges qui ont lieu sur la plateforme à un moment donné. Ces métriques peuvent notamment être exploitées afin de comparer les processus de communication lors de différents événe- ments ou au sein de différents groupes (Bruns & Stieglitz, 2012). L’évolution de ces indicateurs au cours du temps peut également apporter un éclairage intéressant sur la dynamique temporelle de l’événement étudié (Bruns & Liang, 2012). Il peut en outre être utile de calculer certaines métriques sur différents sous-ensemble de données, tels que les publications des utilisateurs les plus ou les moins actifs, afin de mieux appré- hender l’organisation des échanges (Bruns & Stieglitz, 2012).
Différents outils peuvent par ailleurs être utilisés pour le traitement automatique des corpus de données recueillies sur médias sociaux. Des programmes d’analyse de texte permettent d’extraire les thèmes principaux d’un ensemble de messages (Guille, Favre, Hacid, & Zighed, 2013) – par exemple pour comparer les thèmes abordés par différents utilisateurs ou à différentes périodes – mais aussi de classifier automatiquement les messages en fonction des opinions (positif ou négatif) ou des émotions (e.g. joie, peur, tristesse) exprimées dans le texte (Johansson, Brynielsson, & Quijano, 2012) et de leur intensité (Thelwall, Buckley, & Paltoglou, 2012).
La nature des relations et des échanges sur les médias sociaux se prête également bien aux méthodes d’« analyse structurale des réseaux sociaux ». Ces outils qualitatifs s’appuient sur la théorie des graphes pour étudier la structure des relations qui relient les individus ou les communautés. Un réseau est représenté sous la forme d’un graphe
composé d’un ensemble fini de nœuds reliés par des arêtes ou des arcs (Forsé & De- genne, 2004 ; Mercklé, 2011). Sur les médias sociaux, on peut considérer une grande variété de réseaux constitués par les connexions, les messages, les mentions entre les utilisateurs, ou encore les co-occurrences de thématiques ou de mot-clefs au sein des mêmes messages. L’analyse structurale peut également porter sur des réseaux hétéro- gènes, associant non plus un seul mais deux types différents de nœuds : les utilisateurs et les thèmes qu’ils mentionnent, ou encore les mots-clefs et les URL apparaissant dans les mêmes messages (Bruns & Liang, 2012) (Figure 3.6). L’analyse structurale propose ensuite de nombreuses métriques locales – qui qualifient la position d’un nœud dans le graphe (e.g. centralité) – et globales – portant sur le graphe dans son ensemble (e.g.
densité, connexité). Plusieurs logiciels, tels que Gephi48 ou NodeXL facilitent le traite-
ment des graphes, le calcul de ces métriques, la création de représentations graphiques variées. Certains proposent en outre des fonctionnalités additionnelles telles que la dé- tection automatique des communautés à l’aide d’algorithmes de clustering (Bastian, Heymann, Jacomy, & others, 2009 ; Smith et al., 2010).
(a) Réseau homogène de mention d’utili- sateurs
(b) Réseau hétérogène d’utilisateurs et de hashtags
Figure 3.6 – Exemples de graphes de données issues de Twitter
Bien entendu, l’interprétation des résultats de ces analyses doit prendre en compte les biais et artefacts générés par l’ensemble des outils et des méthodes utilisés au cours des différentes étapes de collecte, stockage, traitement et présentation de l’information. Par exemple, les critères de collecte des données (e.g. comptes utilisateurs, plage tem- porelle, mots clefs) sont généralement fondés sur des hypothèses préalables quant à la distribution du phénomène étudié (e.g. personnes impliquées, durée, thématiques). Ces hypothèses, qui définiront les limites du corpus constitué, sont susceptibles d’affecter notre perception et notre compréhension du phénomène (Gerlitz & Rieder, 2013). De même, les métriques d’analyse et les représentations visuelles ne peuvent être consi- dérées comme des outils neutres et objectifs (Barats, 2013). Plutôt que de les utiliser
comme des « boîte noires », le chercheur se doit d’essayer d’en connaître le fonction- nement, afin de comprendre les biais qu’ils peuvent induire dans ses résultats (Barats, 2013 ; Bruns & Liang, 2012).