À une époque où la vie sociale numérique se déroule de plus en plus au sein d'applications fermées et au design unique, un nouveau cadre de recherche appelé Graffiti propose une vision radicalement différente : n'importe qui peut créer sa propre application sociale qui répond précisément aux besoins de sa communauté, sans perdre ses contacts existants ni ses données. Il s'agit d'une couche de communication et de données conçue pour la création simple d'outils sociaux personnalisés à l'aide de technologies front-end typiques (HTML, CSS, JavaScript), avec une interopérabilité intégrée entre différentes applications et la propriété des données stockées sur une infrastructure décentralisée par les utilisateurs.

Pourquoi les applications sociales personnalisées devraient-elles même exister

Imaginons une salle de concert indépendante qui souhaite rassembler un public local autour de nouveaux artistes : échange de recommandations, courts extraits de répétitions, sondages rapides avant le programme, listes de chansons après le concert… Tout cela peut tenir dans une seule application sociale spécialisée, conçue sur mesure pour la micro-communauté. Le problème survient au moment où – au nom de cette personnalisation – le public doit « déménager » vers un nouveau service et y reconstruire son graphe social, tandis que les créateurs de l'application doivent maîtriser et maintenir un back-end complexe. Graffiti brise ce cercle vicieux de two manières : il simplifie le développement en offrant une couche d'arrière-plan commune à laquelle toutes les applications accèdent, et en même temps, il garantit que les publications et les liens sociaux peuvent être vus et utilisés dans n'importe quelle application compatible, sans perte de continuité entre les personnes.

L'idée clé : l'interopérabilité sans le consentement du propriétaire de la plateforme

Contrairement aux réseaux sociaux conventionnels où l'interopérabilité est généralement limitée aux API définies par le propriétaire de la plateforme, Graffiti propose un niveau de protocole où toutes les actions sociales sont « transformées » en données qui peuvent être lues, partagées et interprétées dans différentes applications clientes. Les auteurs appellent cette approche la réification totale : chaque interaction – de la publication et de la réponse au « j'aime », au blocage, au signalement ou à la modération – est enregistrée comme un artefact de données distinct. Les applications décident ensuite, selon leurs propres règles, comment afficher (ou ignorer) ces artefacts, ce qui permet à différentes politiques et philosophies de conception d'être mises en œuvre simultanément sur le même graphe social.

En pratique, cela signifie que les communautés peuvent choisir leurs propres modérateurs et leurs propres règles, tout en restant « sur le même réseau » avec les autres. Si une application décide de masquer les publications qu'une certaine personne a marquées comme inappropriées, une autre application peut utiliser le même ensemble de méta-données uniquement pour un avertissement ou pour un classement. La modération passe ainsi d'une intervention monolithique et centralisée à une concurrence de politiques et d'outils que les utilisateurs choisissent.

Résoudre l'« effondrement du contexte » avec des canaux

L'interopérabilité a aussi un côté sombre : le contenu créé pour un public peut se retrouver devant un public complètement différent. Ce phénomène, connu dans la littérature sous le nom d'effondrement du contexte (en anglais context collapse), peut provoquer des malentendus et des dommages sociaux lorsqu'un message est sorti de son cadre prévu. Graffiti aborde ce problème avec le concept de canaux. Un canal est une « clôture » flexible autour d'un message (ou d'un fil de discussion entier) qui représente un contexte spécifique – une personne, une application, une organisation, un lieu, un événement ou une unité thématique. Les publications visibles dans un canal ne doivent pas nécessairement « fuir » automatiquement dans un autre ; l'auteur peut définir plus finement le public et ainsi empêcher le mélange indésirable des contextes.

Développement front-end sans back-end lourd

L'une des ambitions attrayantes de ce cadre est d'abaisser le seuil d'entrée pour le développement d'applications sociales. Comme le stockage du contenu et l'échange de données se font sur une infrastructure commune et distribuée, les auteurs soulignent qu'il est possible de créer des clients sociaux fonctionnels uniquement avec des outils front-end : HTML, CSS, bibliothèques de composants ou des cadres populaires comme Vue. Au lieu que les équipes écrivent et maintiennent leurs propres serveurs, Graffiti standardise la manière de stocker et de récupérer les événements réifiés, ce qui permet de réorienter l'énergie vers l'expérience utilisateur, les politiques de sécurité côté client et l'itération rapide de nouvelles fonctionnalités.

Propriété des données et identité portable

La promesse centrale des réseaux sociaux décentralisés est la suivante : les utilisateurs conservent leurs données et leur identité même lorsqu'ils changent d'application. Graffiti rend cela opérationnel en faisant en sorte que les données n'« appartiennent » pas au client mais se trouvent dans un stockage distribué auquel différents clients peuvent se connecter. L'identité et le graphe social deviennent ainsi portables, de sorte que changer d'application ne signifie plus perdre ses connexions. Une telle architecture s'inscrit dans les tendances plus larges du web social décentralisé qui explore depuis des années comment éviter d'être enfermé dans des silos – de la norme ActivityPub qui alimente le fedivers, aux approches plus récentes comme le protocole AT sur lequel une série d'applications interopérables est en cours de construction.

En quoi Graffiti diffère des protocoles décentralisés existants

ActivityPub (une recommandation du W3C de 2018) repose sur une fédération de serveurs qui échangent des activités au format ActivityStreams 2.0 ; il est utilisé par Mastodon et d'autres services du fedivers. Le protocole AT, qui sous-tend un écosystème croissant d'applications, offre des identités portables et une séparation du stockage et des clients, ainsi que des flux algorithmiques flexibles et des outils de modération ouverts. Graffiti partage avec eux l'objectif de portabilité de l'identité et des données, mais se distingue précisément par la réification totale des actions sociales et un modèle de données universel et agnostique aux applications où la modération elle-même est enregistrée comme une donnée. Ce niveau de représentation facilite la coexistence de règles contradictoires et permet à différentes communautés d'appliquer simultanément leurs propres politiques de visibilité et de comportement sur le même graphe.

Exemples d'utilisation : des scènes culturelles aux équipes de travail

Les auteurs ont déjà présenté plusieurs applications créées sur ce cadre – d'une interface de microblogage ressemblant aux réseaux sociaux « classiques » à l'édition collaborative de contenu dans le style d'une encyclopédie, l'échange de messages courts en temps réel et des applications dédiées aux communautés locales. Dans l'exemple concret et apparemment modeste de la salle de concert, Graffiti permet au public d'ouvrir des canaux thématiques (par exemple, par genres, artistes ou salles), de partager des extraits et des playlists, et aux modérateurs – choisis par la communauté elle-même – de définir des règles de visibilité, sans craindre que ces déterminants n'« inondent » les profils des utilisateurs en dehors du contexte du canal musical.

Il est également applicable dans des environnements professionnels : les équipes peuvent assembler un outil minimal pour une coordination rapide avec des fils de discussion par projet, tandis que des comportements comme « aimer », « pinger » ou « escalader » sont enregistrés comme des données que d'autres clients peuvent traduire dans leurs propres modèles d'interface utilisateur. Le résultat est une mosaïque d'applications compatibles d'esthétiques et de profondeurs différentes, mais avec le même « réservoir » social.

La modération comme un marché de services, et non une commande centrale

Une objection courante aux systèmes décentralisés concerne l'application des règles : qui « retire » le contenu illégal ou nuisible ? Graffiti n'offre pas une police de contenu unique, mais permet à des services de modération concurrents d'agir sur le même ensemble de données sociales. Les utilisateurs – ou des communautés entières – choisissent un ou plusieurs services, les décisions (étiquettes, blocages, avertissements) étant enregistrées comme des événements réifiés. Les applications interprètent ensuite ces événements selon leurs propres règles. Cela évite une norme unique qui est nécessairement trop rigide pour des contextes culturels et juridiques variés, mais ouvre également de sérieuses questions de recherche sur les limites de la protection personnelle et collective.

Sécurité, confidentialité et limites de l'interopérabilité

Quelle que soit l'approche de l'interopérabilité, une tension non résolue subsiste entre l'ouverture et la prévention de la diffusion de contenu au-delà du public visé. Les canaux aident, mais ils ne suppriment pas la responsabilité des concepteurs de clients et des gardiens de communautés de définir des paramètres de visibilité par défaut raisonnables, la possibilité de « bifurquer » les fils de discussion vers des espaces plus fermés, ainsi que des indicateurs de contexte clairs. De plus, la réification des blocages et des plaintes crée des métadonnées qui – si elles не sont pas protégées – peuvent révéler des modèles de relations sociales. Le renforcement de la confidentialité implique donc des mécanismes cryptographiques, des approches de « divulgation sélective » et des politiques strictes de conservation des données, ce que les auteurs ont annoncé comme une direction future pour le développement.

Statut de la recherche et reconnaissances

L'article qui présente systématiquement le concept et la mise en œuvre de Graffiti a été présenté à la conférence annuelle UIST 2025 qui s'est tenue du 28 septembre au 1er octobre 2025 à Busan. Le programme de la conférence mentionne précisément cette publication signée par Theia Henderson, David R. Karger et David D. Clark, et l'article a également été inclus parmi les articles primés de la conférence. Un manuscrit évalué par les pairs est également disponible en accès libre.

Le contexte de recherche lui-même s'inscrit dans les efforts de plusieurs années des communautés universitaires et technologiques pour construire des systèmes d'information décentralisés qui redonnent aux utilisateurs le contrôle sur leurs données et leur identité – une tradition que le MIT représente symboliquement par le travail de groupes dédiés aux paradigmes du web décentralisé.

Comparaison des paradigmes de conception : que signifie un web social « composable »

Dans le web sémantique, nous avons déjà eu une série de tentatives pour standardiser la communication via des objets et des activités génériques (par exemple, ActivityStreams). Graffiti ramène cet esprit du côté client et le rend pratique pour la construction d'applications : au lieu de nous adapter à une application « principale » qui dicte à quoi ressemble une publication, une réponse ou un signalement, Graffiti standardise la représentation des événements, tandis que l'interface, les flux et les règles d'interprétation restent une question de choix. De là découle une conséquence inattendue : il est plus facile de construire des « ponts » entre les protocoles (par exemple, vers le fedivers ou l'écosystème du protocole AT) car la traduction s'effectue au niveau de l'événement, et non par le clonage forcé de toute la logique de la plateforme.

Qu'est-ce que cela signifie pour les créateurs de contenu et les petites organisations

Pour les médias locaux, les organisations culturelles, les écoles, les associations et les startups, le plus grand obstacle jusqu'à présent a été la combinaison de la complexité technique et du risque de la « pièce vide ». Si la communauté doit quitter son réseau existant, le projet a du mal à décoller. Graffiti s'attaque à ce problème en offrant trois avantages pratiques : (1) la création d'un MVP uniquement avec le front-end, (2) la portabilité de l'identité et des données sans « réinitialiser » les liens sociaux et (3) une interopérabilité native qui permet aux publications d'une application d'être visibles dans une autre – sans être contraint à un design unique ou à des règles centralisées.

Exemples de scénarios et de modèles d'utilisation

• Microblog pour les quartiers de la ville : canaux par quartiers et par thèmes (calendrier des événements, appels au bénévolat, objets trouvés) ; dans chaque canal, des règles de modération différentes que la communauté choisit en « s'abonnant » à des services de modération.


• Coopérative éditoriale : édition de textes sous forme de « fils de discussion wiki » où les modifications, les révisions et les étiquettes de qualité sont également des événements réifiés ; un autre client peut afficher les mêmes données sous la forme d'un flux de révision par les pairs classique.


• Scène musicale : les publications des répétitions, les set-lists et les enregistrements des concerts voyagent à travers les canaux des artistes, des clubs et des promoteurs ; le public choisit un client axé sur l'audio, quelqu'un d'autre un client avec des fils de discussion de type forum – tous partagent le même ensemble de données.


• Équipes de travail : intégrations faciles avec d'autres protocoles et services : l'identité est portable, donc passer à un nouveau client ne perturbe pas le réseau de contacts ; les politiques de modération peuvent imiter les modèles de « revue de code ».

La vue d'ensemble : la course à la couche sociale interopérable

Les deux dernières années ont vu une prolifération d'initiatives visant à éviter la dépendance à une seule entreprise : le fedivers basé sur ActivityPub s'étend à travers divers logiciels et intégrations, tandis que l'écosystème basé sur le protocole AT connaît une croissance du nombre d'applications et d'utilisateurs ainsi que des campagnes qui mettent l'accent sur les « intérêts publics » et la reconfiguration de la propriété des infrastructures. Graffiti s'inscrit dans ce paysage comme une proposition de recherche qui libère au maximum les clients – les développeurs peuvent innover au niveau de l'expérience et des fonctions, sans pour autant briser l'interopérabilité.

Questions ouvertes et développement futur

Jusqu'où la modération « personnelle » peut-elle aller avant de devenir inefficace contre les abus organisés ? Comment empêcher que les événements réifiés (en particulier ceux qui indiquent des conflits sociaux) ne soient utilisés comme un outil de doxxing ou de harcèlement ciblé ? Quelles sont les normes de sécurité minimales pour les canaux nécessaires pour éviter la reconstruction de réseaux privés à partir de méta-données ? Et enfin, où tracer la ligne entre la liberté de conception et la responsabilité envers les groupes d'utilisateurs les plus vulnérables ? Les auteurs du projet ont déjà annoncé d'autres améliorations techniques – des outils pour la composition graphique de clients aux mécanismes plus solides de protection de la vie privée et de la sécurité – mais aussi des études longitudinales sur les effets sur le comportement des communautés.

À qui s'adresse Graffiti aujourd'hui

Le plus grand bénéfice immédiat peut être tiré par les organisations et les créateurs qui souhaitent une interaction sociale rapide et thématique sans construire de back-end et sans « faire déménager » leur public : les médias locaux et les institutions culturelles, les communautés éducatives, les équipes open-source et les associations. Avec quelques connaissances en front-end et une idée claire des canaux et des règles, ils peuvent assembler leur propre client, s'intégrer aux flux de contenu existants et conserver la propriété de ce qu'ils produisent. Pour une application plus large – des discussions publiques de masse aux sujets sensibles – la qualité des services de modération, l'ergonomie des clients et les normes de protection de la vie privée convenues par la communauté seront cruciales.

Comment commencer : lignes directrices de conception pour une première expérience

1. Définissez les canaux et le public : avant de créer l'interface utilisateur, cartographiez les contextes (personnes, équipes, lieux, événements) et décidez où quel contenu peut apparaître pour éviter l'effondrement du contexte. Introduisez des marqueurs visuels clairs du contexte et des paramètres de confidentialité par défaut.


2. Modélisez les interactions comme des données : décidez quelles actions seront réifiées (étiquettes de qualité, rôles, blocages, signalements, escalades) et comment votre application les interprétera. Prévoyez la possibilité qu'un autre client interprète les mêmes événements différemment.


3. Choisissez des services de modération : commencez avec au moins deux services indépendants pour tester la coexistence de différentes politiques. Ajoutez un affichage clair de la source des décisions de modération dans l'interface.


4. Assurez une identité portable : planifiez des intégrations avec des protocoles qui facilitent la migration et la conservation du graphe social et indiquez aux utilisateurs où leurs données sont stockées.


5. Itérez avec les utilisateurs : comme la création de clients est facile, utilisez des cycles de prototypage rapides ; suivez les effets sur la culture de la communication, en particulier au-delà des frontières des canaux.