Collecte linéaire de vidéos court-format
Pierre Depaz - Universität Basel - pierre.depaz@unibas.ch
Logiciel de recherche de vidéos court-format
développé à l'école de design de karlsruhe avec Marc Hudnut (KIT)
observation de la place grandissante des VCF dans le mix médiatique
format bien particulier qui essaime sur diverses plateformes (tiktok, puis insta, puis youtube)
Personal Scroller, logiciel de collecte automatique de vidéos court-formats.
Deux problèmes
Un technique, et un méthodologique.
À la base de ce projet, il y a deux observations qui découlent de l'observation qu'ont soit entrés dans une ère "post-API"
(benkler, cautionary notes)
La restriction drastique d'accès aux APIs1.
Ce fut le cas de Facebook dès 2018, puis de Twitter en 2023, et cette tendance s'observe aussi avec les vérifications additionnelles effectuées par YouTube pour s'assurer que l'usage est bien légitime. Cela ne va pas s'arranger avec la course aux données motivée par l'envie d'entraîner des grands modèles de langage.
Donc évidemment, ça pose la question de l'autorisation, de l'autorité, et qui dit autorisation dit en fait dépendance à l'autorité.
Néanmoins, quand on parle d'accès à l'information, une API c'est principalement juste un accès privilégié, et pas
et de la copie de l'information (si c'est sur un écran, c'est copiable)
Si c'est sur un écran, c'est déjà copié2.
Cory Doctorow présente le problème assez bien en considérant que l'application du droit de propriété intellectuelle (effectivement, la limitation de la copie de l'information) est fondamentalement opposée au fonctionnement de l'ordinateur, puisque la machine de Turing c'est avant tout une machine qui copie.
Donc d'un côté, il y a un accès qui disparaît (l'API); de l'autre il y a un accès qui demeure (l'écran)
C'est aussi le concept de l'analog hole.
La cartographie vs. la trajectoire3.
Un autre problème que je considérais, c'est celui du point de vue de la collecte et de l'analyse de données.
Le point de vue de la cartographie, c'est tendre à la systématisation, et non à la subjectivisation (le but est de représenter une totalité, et non pas un fragment).
Donc si on va représenter la fachosphère en France, on va apprendre des choses sur sa structure, ses composantes, et ses relations, mais pas forcément sur les rapports qu'ont des individus spécifiques.
C'est quelque chose que Benkler avait noté en 2019 sur la différence entre la preuve de l'action, et la preuve de la conséquence. Dans son contexte, il s'agit de dire qu'on observe effectivement l'action de propagande, mais qu'il est plus compliqué d'observer l'action de l'impact, c'est à dire les conséquences sur des personnes spécifiques, subjectives.
Un écran, c'est aussi un point de vue.
Donc face au problème technique de devoir passer par du scraping, et face au problème méthodologique d'une approche dominante qui considère un point de vue généralisé, on a considéré pouvoir combiner ces deux approches.
Donc un écran, ça représente autant un endroit où l'information est copiée, qu'un point de vue.
Avant d'être un réseau, les VCF sont une trajectoire.
C'est valable pour beaucoup de contenu sur des réseaux sociaux, mais l'aspect plein-écran et algorithmique de la présentation des VCF rend cela beaucoup plus évident la disparition de l'enchaînement des vidéos alors même que cet enchaînement est le résultat d'un éditorial algorithmique.
L'approche marionettiste
Simulation d'un navigateur pour automatiser le point de vue.
Si la force de l'API c'était d'automatiser la demande d'information (en plus d'avoir une grande qualité de structure de l'information), le contrôle automatique d'un logiciel nous rapproche de cette facilité.
Donc le logiciel consiste principalement en la gestion d'une instance de manipulation de navigateur (nous, on a choisi Puppeteer, principalement)
Cela nous permet aussi de choisir quelles étapes sont automatisées, et quelles étapes sont toujours manuelles. Par exemple, l'acceptation de cookies et la connexion à un compte utilistaeur sont laissées manuelles afin de ne pas briser les CGU.
Similarité des plateformes (YouTube Shorts, Instagram Reels, TikTok)
interface Video {
scroll_id: string
user_id: string
id: string // (yt, ig, tt)
url: string // (yt, ig, tt)
created_at: date // (yt, ig, tt)
title: string // (yt, tt)
description: string // (yt, ig, tt)
comments_count: number // (yt, ig, tt)
likes_count: number // (yt, ig, tt)
comments: Comment[] // (yt, ig, tt)
}
Un autre aspect qui nous a intéressé c'est que, en partant de l'observation que le format des VCF est essentiellement le même, la structure des données accompagnant ces vidéos, et les interfaces sont sensiblement semblables, et le schéma des données l'est aussi. Là, on peut justement consulter la documentation des API des plateformes, ainsi que les requêtes faites par le navigateur pour constituter le schéma.
Cela permet une redondance de l'information: ce qu'on voit à l'écran, ce que la plateforme définit officiellement, et ce que le navigateur requiert.
Donc avec une même structure de données, on peut addresser différentes plateformes.
Séparation entre comportement et plateforme.
Donc la zone de superposition du diagram de Venn est non-négligeable, et on en a profité dans la conception. Il y a deux parties principales: le controller et l'operator.
Un controller régit un comportement d'usager (scroller, collecter des informations, liker une vidéo, visionner et collecter des commentaires, prendre une capture d'écran, télécharger une vidéo, etc.)
Un opérateur traduit les directives du controller pour les affordances spécifiques d'une plateforme. Donc on peut faire les mêmes choses sur TikTok, YouTube et Instagram, en séparant les deux problématiques.
Une architecture de plug-ins et d'évènements: onTraitRecorded et preScroll.
Cela permet d'effectuer certaines actions à partir d'évènements.
Par exemple, faire une analyse de NLP simple sur des occurences de mots-clés ou dans le titre, ce qui ferait ensuite clicker sur le bouton like
Ou bien, en général, une série d'actions à prendre avant de commencer une série de scrolls, par exemple aller visionner une série de vidéos prédéfinies afin d'aiguiller l'algorithme,
Donc le flux de fonctionnement, c'est de configurer un comportement, une plateforme, de lancer la session, d'accepeter les cookies et de se connecter à son compte.
Pour l'instant, on arrive à scroller un nombre infini TODO: check
Et le résultat, c'est un grand nombre de fichiers JSON
Quelques problèmes:
- la matérialité d'HTML
- la danse du chat et de la souris
- la zone grise de la légalité
La matérialité d'HTML, c'est que le markup est généralement complètement asémantique (par exemple le markup d'Instagram), et donc dur à comprendre et traduire en un opérateur, ou bien il peut être très éphémère, "changer sans changer", puisque l'apparence à l'écran est la même, mais la structure est différente. Mais il est toujours possible de ré-examiner une page HTML et modifier l'opérateur pour arriver aux résultats escomptés.
Cette danse du chat et de la souris, elle se passe dans un contexte plus large de scraping commercial, avec beaucoup d'entreprises qui offrent des services pour collecter des données via scraping, soit pour faire un portrait de la concurrence, soit pour bootstraper des nouvelles plateformes—comme l'a fait AirBnB—, soit pour entraîner des systèmes d'apprentissage profond. Donc les plateformes se défendent, mais en même temps elles sont obligées de laisser accès puisque c'est le coeur de leur produit...
Donc par exemple, il existe des systèmes comme puppeteer-ghost, qui introduise des pauses aléatoires, mettent des User-Agent réalistiques, proposent d'utiliser des proxy, etc.
Et le dernier problème, c'est celui de la légalité des données récupérées, et c'est le point sur lequel nous sommes le moins sûr, surtout qu'il s'agit de jongler avec différentes CGU de différentes plateformes, et de séparer création de contenu et figuration d'individus dans ce contenu. Cf. e.g. https://info.lse.ac.uk/staff/divisions/research-and-innovation/research/Assets/Documents/PDF/ethics-Using-internet-and-Social-media-data.pdf
Pistes de recherches
Jusqu'à présent, on s'est beaucoup concentrés sur la méthode, maintenant on va passer aux genres de questions de recherches qui se prêtent à ce genre de recherche.
Une analyse comparative de l'offre par défaut.
Il s'agit d'inspecter les choix par défaut d'éditorialisation. Qu'est-ce que TikTok va proposer aux nouveaux et nouvelles venues?
Mais aussi à travers, des proxys, les localités géographiques, ou variant avec des vidéos de départ.
Et cela avec une attention particulière à certaines thématiques: e.g. à quelle vitesse est-ce qu'on arrive sur du contenu sexué? sur du contenu politique?
Profil utilisateur.rice vs. vidéos scrollées -> convergence ou divergence?
En complément de cette approche par défaut, il est possible d'étudier des trajectoires plus individuelles en fonction du goût particulier. Par exemple complémenter avec des questionnaires afin de saisir les positionnements et intérêts généraux, et comment ceux-ci sont reflétés (ou non!) dans l'éditorialisation.
Fréquence d'apparition de vidéos thématisées, répétitions et superpositions4.
En plus d'une approche individualisée, puisque c'est ce que se targuent d'être les algorithmes d'éditorialisation, il faudrait aussi pouvoir examiner la fréquence et la redite de vidéos spécifiques (un meme), ou de catégories spécifiques (un dirigeant politique, ou des femmes en maillot de bain)
Est-ce que Vladimir Poutine arrive à chaque fois? Est-ce que tous les dirigeants politiques arrivent à chaque fois?
Pareil pour les images de jeune femmes en bikini?
La représentation d'une ligne plutôt qu'un réseau.
Si chaque vidéo a la particuliarité de faire partie d'une trajectoire, ce n'est donc pas un réseau. Mais avec plusieurs trajectoires, est-ce qu'il existe des "zones" communes dans ces algorithmiques? Est-ce que, à partir de ces trajectoires, on peut reconstituer la topologie des vidéos courts-formats par plateforme?
Une opportunité de critical technical practice5.
- travail avec des user stories plutôt que des vraies chercheuses et chercheurs
- un système simple qui devient complexe (e.g. les plug-ins)
- l'absence d'itération
What are the goals, conditions and practice of such technical work?
La CTP, tiré des travaux de Philip Agre, c'est une approche de la recherche technique qui est tant technique que critique, en cherchant notamment à élucider les buts, conditions, et pratiques de tout travail technique.
Le but c'est de donner plus de visibilités sur les consommations audiovisuelles contemporaines. Le but c'est aussi de créer un logiciel pour réaliser le but précédent (il y aurait peut-être d'autres manières de s'y prendre, comme du travail d'observation, ou de commentaire).
Conditions: - dépendence sur des sources commerciales - essor des financements pour des projets techniques en SHS (l'outil devient parfois la création) - pas d'accès à des chercheurs et chercheuses en sciences sociales, donc travail avec des chercheurs et chercheuses hypothétiques (user stories)
Practice: - focale sur l'outil, et la conception d'un usage technique, plutot que scientifique de l'objet - intérêt personnel des personnes qui implémentent, et qui vont influencer la direction et la forme de l'outil - itération de structure principalement, et non pas de fonctions. "recherche exploratoire"? "recherche putative"? en gros développer alors qu'on ne vérifie pas le vrai processus de recherche) -> dissonance entre itération et test
Conclusion
- automatisation d'un navigateur pour une collecte située
- attention particulière à la séquentialité des vidéos
- choix architecturaux particuliers (séparation comportement et plateforme, systèmes de plug-ins)
- pistes de recherches sur l'éditorialisation (par défaut, personnalisée, récurrences de vidéos, zones thématiques)
Personal Scroller
gitlab.com/periode/personal-scroller