--- title: "Objets : pourquoi nos choses sont-elles piégées dans les apps ?" code: "RP-0057" language: "fr" canonical: "https://regentspark.ai/fr/RP-0057/" html: "https://regentspark.ai/fr/RP-0057/" markdown: "https://regentspark.ai/fr/RP-0057.md" updated: "15 April 2026" --- # Note de recherche 005c — Objets *Regent's Park · mars 2026* --- ## Le problème Vous préparez un voyage. Vous avez une note dans Apple Notes avec des recommandations de restaurants. Un Google Doc partagé avec l'itinéraire. Un lieu épinglé dans Google Maps. Un moodboard dans Figma. Une confirmation de vol dans vos e-mails. Vous voulez tout étaler. Côte à côte. Comme des papiers sur une table de cuisine. Vous ne pouvez pas. La note est coincée dans Apple Notes. L'itinéraire est coincé dans Google Docs. L'épingle de carte est coincée dans Google Maps. Le moodboard est coincé dans Figma. Chacun vit dans son propre monde, derrière sa propre porte. Pour en voir un, vous ouvrez l'app. Pour les voir tous, vous ouvrez cinq apps et vous passez sans cesse de l'une à l'autre. Vous ne pouvez pas prendre une *chose* et la poser quelque part. Vous pouvez seulement ouvrir des *apps*. Cela ressemble à un petit désagrément. C'est en réalité une défaillance fondamentale. L'informatique n'a pas de concept de « chose » qui fonctionne comme vous le pensez. Elle a des fichiers, parfois. Elle a des entrées de base de données cachées dans des applications, souvent. Elle a des blobs cloud qui vivent sur le serveur de quelqu'un d'autre, de plus en plus. Mais elle n'a pas d'*objets* — des choses que vous pouvez tenir, déplacer, placer et combiner, quelle que soit leur provenance. --- ## Comment les gens pensent déjà ce problème Voici ce qui rend ce problème si frustrant : vous savez déjà ce qu'est un objet. Vous ne pouvez simplement pas en avoir un sur votre ordinateur. Quand quelqu'un dit « passe-moi cette photo », personne ne demande dans quelle app se trouve la photo. C'est une *chose*. Vous la prenez, vous la donnez à quelqu'un, la personne la regarde. Quand quelqu'un dit « mets ces notes à côté du tableur de budget », vous comprenez exactement ce que cela veut dire. Deux choses, l'une à côté de l'autre. Simple. Mais sur un ordinateur, ce sont des opérations radicalement différentes selon ce que sont les « choses » : - Une photo peut être un fichier sur votre disque dur, que vous pouvez déplacer - Ou elle peut être dans iCloud Photos, que vous pouvez plus ou moins partager par lien - Ou elle peut être dans Google Photos, où elle vit sur les serveurs de Google - Ou elle peut être intégrée dans une page Notion, comme entrée de base de données dans une autre entrée de base de données La photo est la même photo. Mais pour votre ordinateur, ce sont quatre *types* de choses complètement différents, avec quatre jeux de règles complètement différents sur ce que vous pouvez en faire. Essayez maintenant le même exercice avec une note. Une Apple Note n'est pas un fichier. Vous ne pouvez pas la trouver dans votre système de fichiers. Vous ne pouvez pas la glisser quelque part. C'est une entrée dans une base de données que seule Apple Notes peut lire. La seule façon d'interagir avec elle est d'ouvrir Apple Notes — qui vous montre *toutes* vos notes, parce que c'est ainsi que l'app fonctionne. Vous vouliez une note. Vous avez obtenu toute l'application. Voilà ce qui se passe quand on confond la *chose* avec le *lieu qui l'a produite*. **L'informatique a au moins trois réponses complètement différentes à la question « qu'est-ce qu'une chose ? » :** **Les fichiers.** La réponse originale. Un fichier est un blob de données avec un nom, posé dans un dossier. Vous pouvez le déplacer, le copier, le renommer, le mettre où vous voulez. Les fichiers vous donnaient une véritable marge d'action : vous pouviez arranger votre monde numérique. Mais les fichiers sont aussi du poids mort. Un fichier `.docx` n'est que des octets sans signification jusqu'à ce que Microsoft Word, ou quelque chose de similaire, l'ouvre. Les fichiers sont portables mais inertes. **Les entrées de base de données.** La réponse moderne, surtout sur téléphone. Apple Notes, Reminders, Messages : aucun de ces outils ne produit des fichiers que vous pouvez toucher. Vos notes existent comme lignes dans une base SQLite que l'app gère pour vous. Cela a simplifié les choses : plus besoin de se demander où enregistrer, moins de corruption de fichiers, moins de documents perdus. Mais cela les a aussi rendues captives. Vos notes sont dans Notes. Vos rappels sont dans Reminders. Vous ne pouvez pas tendre la main et en sortir un. **Les blobs cloud.** La réponse la plus récente. Un design Figma ne vit pas du tout sur votre ordinateur. Il vit sur les serveurs de Figma. Une page Notion vit sur les serveurs de Notion. Un Google Doc vit sur les serveurs de Google. Vous y accédez par un navigateur. Vous ne les « avez » pas vraiment : vous avez la *permission* de les consulter, accordée par l'entreprise qui les stocke. Pour vous, l'utilisateur, ces trois choses sont simplement du *contenu*. Des choses que vous avez faites, que vous voulez utiliser, que vous voulez poser à côté d'autres choses. La différence entre fichier, entrée de base de données et blob cloud est un détail d'implémentation que vous n'avez jamais demandé à connaître, mais qui dicte tout ce que vous pouvez ou ne pouvez pas faire. **Cette confusion va plus loin que le stockage.** Elle atteint le concept même d'« app ». Pensez à ce qu'est vraiment Apple Notes. C'est trois choses attachées ensemble : 1. **Un domaine** — Apple, qui fournit et gère le service 2. **Vos objets** — les notes que vous avez écrites 3. **Une interface** — l'app Notes, ce que vous voyez et touchez Ces trois choses sont fusionnées. Vous ne pouvez pas séparer vos notes du domaine d'Apple. Vous ne pouvez pas voir vos notes dans une autre interface. L'app *est* le domaine *est* les objets. Tout est soudé. Toutes les apps fonctionnent ainsi. Figma, c'est Figma-l'entreprise + vos designs + l'éditeur de Figma. Spotify, c'est Spotify-l'entreprise + vos playlists + le lecteur de Spotify. Gmail, c'est Google + vos e-mails + le client mail de Google. Les objets — *vos* objets — sont pris en otage par le bundle. --- ## Comment les objets fonctionnent partout ailleurs Quittons l'écran un instant. Pensez aux objets physiques. Un livre fonctionne sur n'importe quelle étagère. Vous pouvez prendre un livre dans votre bureau, le ramener chez vous, le poser sur votre table de nuit. Le livre se moque de l'étagère où il se trouve. L'étagère se moque du magasin d'où vient le livre. Le livre et l'étagère sont deux choses indépendantes qui se trouvent au même endroit pour le moment. Une photographie fonctionne dans n'importe quelle pièce. Encadrez-la, épinglez-la à un tableau, mettez-la dans un tiroir, donnez-la à quelqu'un. La photo n'a pas besoin de la permission de l'appareil qui l'a prise. Elle ne cesse pas de fonctionner si vous quittez la pièce où elle a été imprimée. Un marteau fonctionne quel que soit le coffre à outils d'où il vient. Achetez-le dans une quincaillerie, rangez-le dans n'importe quel tiroir, prêtez-le à un voisin. Le marteau est une chose. Il n'a aucune loyauté envers son point d'origine. Les objets physiques ont quelques propriétés que nous tenons pour acquises : - **Ils existent indépendamment.** Une tasse à café existe qu'elle soit dans la cuisine ou au bureau. - **Ils sont déplaçables.** Vous pouvez les prendre et les poser ailleurs. - **Ils sont combinables.** Vous pouvez poser un livre, un stylo et une tasse de café sur la même table. Ils n'ont pas besoin de venir du même fabricant. - **Ils survivent à leur contexte.** Vous quittez un appartement ; les meubles restent des meubles. Voyons maintenant les objets numériques : - Un design Figma n'existe que dans Figma. Sortez-le et vous avez... un PNG. Une image aplatie. Le *design* — avec ses calques, ses composants, son interactivité — a disparu. - Une Apple Note ne peut pas être déplacée. Elle peut être exportée vers un format plus pauvre, texte brut ou PDF, mais la *note* — avec sa mise en forme, ses liens, ses scans — reste captive. - Une playlist Spotify existe au bon vouloir de Spotify. Ils peuvent la modifier, retirer des titres, ou supprimer votre compte, et elle disparaît. Les « choses » numériques ne sont pas des objets au sens où le monde physique nous l'a appris. Ce sont des fonctionnalités d'applications. Des fenêtres à travers lesquelles regarder, pas des choses à tenir. --- ## Ce qui existe aujourd'hui et où cela échoue L'impossibilité de traiter les choses numériques comme de vrais objets n'est pas nouvelle. On essaie de résoudre ce problème depuis des décennies. Chaque tentative comprend une partie de la réponse et rate une autre partie. **Le système de fichiers** a été la première tentative, et à certains égards la plus honnête. Les fichiers sont déplaçables, arrangeables, nommables. Vous pouvez mettre un document Word et un JPEG dans le même dossier. Vous pouvez organiser par projet, par date, par caprice. Le système de fichiers vous donne une véritable marge d'action sur l'arrangement. Là où il échoue : les fichiers sont trop bas niveau. Ils vous obligent à penser aux formats, aux extensions, aux emplacements d'enregistrement, aux sauvegardes. « Où ai-je enregistré ça ? » est une question que personne ne devrait avoir à poser. Et les fichiers sont inertes : ce ne sont que des octets jusqu'à ce qu'une application les interprète. Le système de fichiers traite un fichier Photoshop et une déclaration d'impôts de la même manière : comme un blob avec un nom. **Le modèle des apps, surtout iOS,** est parti dans l'autre sens. Ne vous souciez pas des fichiers : ouvrez simplement l'app, et vos affaires sont là. Plus simple, plus propre, moins anxiogène. Apple Notes est fluide à utiliser *dans* Apple Notes. Là où il échoue : il a tué la possibilité de mélanger les choses. Vous avez perdu une vraie marge d'action en échange de simplicité. Vous ne pouvez plus prendre une note et la poser à côté d'un tableur. Tout est cloisonné. Chaque app est une nation souveraine avec ses propres frontières et ses propres règles sur ce qui peut entrer ou sortir. **Le cloud et le SaaS** ont rendu les choses accessibles partout : vos designs Figma sur votre ordinateur, votre téléphone, l'ordinateur d'un ami. La collaboration est devenue possible. Le cloud a « résolu » la synchronisation. Là où il échoue : vos objets ne sont pas à vous. Ils vivent sur le serveur de quelqu'un d'autre, sous les conditions de service de quelqu'un d'autre. Notion peut changer ses prix. Google peut arrêter un produit, et l'a fait à répétition. Vos objets n'existent que tant que le service choisit de les héberger. Le cloud a résolu l'accès et créé la dépendance. **Les données adressées par contenu** (IPFS, IPLD et projets similaires) ont proposé d'identifier les objets par *ce qu'ils sont*, leur contenu, plutôt que par *où ils sont*, un serveur ou un chemin. Un document aurait la même adresse quel que soit le serveur qui l'héberge. Idée élégante. Là où cela échoue : l'adoption. Les systèmes adressés par contenu restent de niche, en partie parce qu'ils exigent une nouvelle infrastructure, en partie parce qu'ils ne résolvent pas le problème de l'interface. Même si vos données sont adressées par contenu, il vous faut encore une app pour les rendre intelligibles. **Le presse-papiers** — humble, négligé, et peut-être le seul transporteur universel d'objets en informatique. Copiez quelque chose dans n'importe quelle app, collez-le dans n'importe quelle autre. Le presse-papiers se moque des domaines, des formats et des interfaces. C'est le seul endroit où « prendre une chose et la poser quelque part » fonctionne vraiment. Là où il échoue : il est avec perte, temporaire, et limité à une chose à la fois. Copier un design Figma riche et le coller dans un Google Doc ? Vous obtenez une image plate. La richesse ne survit pas au trajet. Le presse-papiers est un tuyau étroit entre royaumes murés : il prouve le concept, mais ne tient pas la promesse. **Le glisser-déposer** a les mêmes limites. Vous pouvez glisser un fichier du Finder vers un e-mail. Mais vous ne pouvez pas glisser un composant Figma dans Apple Notes de façon significative. Dès que les objets franchissent les frontières d'apps, ils se dégradent. **MCP (Model Context Protocol)** est le dernier entrant et peut-être le plus intéressant. MCP permet aux modèles d'IA d'entrer dans les applications et d'en sortir des données : une note précise d'Apple Notes, un design précis de Figma, un e-mail particulier. Le modèle agit comme pont entre domaines, extrait des objets et les présente dans un contexte unifié. Là où il réussit : MCP est, presque par accident, un *protocole de dégroupage*. Il sépare l'objet de l'app. Quand un modèle d'IA extrait votre note via MCP, cette note existe — brièvement — comme chose indépendante. Elle a été soulevée hors du domaine d'Apple. Elle peut être présentée à côté d'un frame Figma et d'une épingle Google Maps. Pour la première fois, le bundle domaine + objets + interface a été fissuré. Là où il échoue, pour l'instant : MCP reste surtout orienté lecture. Extraire des données est plus facile que pousser des changements en retour. Et le modèle d'IA devient le nouvel intermédiaire : vous dépendez de sa capacité à comprendre l'objet et à le présenter fidèlement. C'est tôt, et fragile. Mais la direction est importante. --- ## Ce que nous proposons Le motif devrait maintenant être visible. Chaque tentative de résoudre ce problème a saisi une partie de la réponse : - Les fichiers ont montré que les objets devraient être indépendants et déplaçables - Le modèle des apps a montré que les objets devraient être faciles d'accès - Le cloud a montré que les objets devraient être disponibles partout - L'adressage par contenu a montré que les objets devraient être identifiés par ce qu'ils sont, pas par où ils sont - Le presse-papiers a montré que les objets devraient franchir les frontières - MCP a montré que les objets peuvent être extraits des domaines Ce qui manque, c'est la *primitive* — le concept fondamental qui unifie tout cela. Nous proposons **l'Objet** : une chose numérique universelle qui existe indépendamment de toute application, peut être déplacée entre des espaces, et peut être consultée par toute interface compatible. Un Objet n'est pas un fichier : il est plus riche que des octets avec un nom. Un Objet n'est pas une entrée de base de données : il n'est pas coincé dans une application. Un Objet n'est pas un blob cloud : il ne dépend pas de l'existence continue d'un serveur particulier. Un Objet est une *chose*. Comme un livre, comme une photographie, comme un outil. Il a sa propre identité. Il porte assez d'informations sur lui-même pour être compris par plusieurs interfaces. Il peut vivre dans différents espaces à différents moments, ou dans le même espace que d'autres objets venus de sources entièrement différentes. **Le geste clé est le dégroupage.** Aujourd'hui, les apps soudent les domaines, les objets et les interfaces. Si vous les dégroupez : - **Les domaines** sont ceux qui gèrent et fournissent les données : Apple, Google, votre propre serveur. Vous avez une relation avec chaque domaine, ce qui se connecte à la primitive Personnes. Cette relation vous accorde l'accès à certains objets. - **Les objets** sont les choses elles-mêmes : vos notes, vos designs, vos cartes, vos messages. Ils existent indépendamment de celui qui les fournit. - **Les interfaces** sont la façon dont vous voyez et modifiez les objets — et, point crucial, elles n'ont pas besoin de venir de la même source que le domaine. Vous pourriez voir vos Apple Notes dans une autre interface. Vous pourriez modifier vos designs Figma dans un autre outil. Ce n'est pas du futurisme hypothétique. On voit déjà le dégroupage commencer : - Les modèles d'IA avec MCP peuvent extraire des objets de domaines et les présenter dans leur propre interface - Les standards du web signifient que beaucoup d'« apps » sont en réalité des interfaces vers des domaines cloud - Les formats ouverts (Markdown, SVG, JSON) signifient que certains objets sont déjà portables entre interfaces La question est de savoir si ce dégroupage se fera chaotiquement — chaque outil d'IA réinventant sa propre manière d'accéder aux données des apps — ou s'il sera ancré dans une primitive cohérente : l'Objet. **Et c'est ici que les quatre primitives se rejoignent.** Les Objets n'existent pas dans le vide. Ils existent dans des Espaces, les contenants où vous les arrangez. Ils appartiennent à des Personnes et sont partagés entre elles, avec des relations qui accordent l'accès. Et ils accumulent de la Mémoire, l'histoire de la manière dont ils ont été utilisés, modifiés et déplacés. Un Objet extrait d'Apple Notes et placé dans un Espace de projet, partagé avec un collaborateur, avec une trace de qui l'a ajouté et quand : voilà les quatre primitives qui fonctionnent ensemble. --- ## Complexités techniques Tout ce qui précède porte sur ce qu'un Objet devrait être. Maintenant : pourquoi est-ce difficile à construire ? **Représentation.** Si un Objet peut venir de n'importe quel domaine et fonctionner avec n'importe quelle interface, il lui faut une manière de se décrire. Pas un format unique : c'est la limite du système de fichiers. Plutôt quelque chose comme un contrat : « Je suis une note. J'ai un contenu textuel, une mise en forme, des images intégrées. Voici comment me lire. Voici comment me modifier. » C'est un problème de métadonnées et de capacités. Les objets ont différents niveaux de richesse, et les interfaces doivent savoir avec quoi elles travaillent. **Fidélité entre frontières.** Quand vous copiez aujourd'hui un design Figma riche, il se dégrade en image plate au collage. Une primitive Objet doit préserver la fidélité quand elle passe d'un contexte à l'autre — ou au moins se dégrader *gracieusement* et *transparentement*. Vous devriez savoir ce que vous perdez quand une interface ne peut pas rendre toute la richesse d'un objet. **Synchronisation d'état.** Si un Objet peut exister dans plusieurs espaces et être consulté par plusieurs interfaces, les changements doivent se propager. Modifiez une note dans un espace, elle devrait se mettre à jour dans un autre. C'est le problème de synchronisation en temps réel, difficile mais bien étudié (CRDT, transformations opérationnelles, etc.). Le nouveau défi est de le faire entre domaines, pas seulement à l'intérieur d'une application. **La séparation domaine/interface.** Dégrouper les apps signifie que les domaines doivent exposer les objets d'une manière standard, et que les interfaces doivent les consommer d'une manière standard. MCP est le candidat le plus prometteur ici : il est déjà conçu comme protocole pour extraire des données de sources et les présenter à des consommateurs. Reste à voir si MCP évoluera pour gérer les écritures, les transactions et les mises à jour en temps réel. **Rétrocompatibilité.** Des milliards de dollars de logiciels existent comme apps groupées. Les Objets ne peuvent pas exiger que toutes les apps se réécrivent. L'approche doit être incrémentale : des objets peuvent être extraits des apps existantes, MCP le fait déjà aujourd'hui, et avec le temps les apps peuvent exposer des interfaces Objet plus riches. Différents niveaux de capacité — certains objets en lecture seule, d'autres pleinement interactifs — permettent une adoption graduelle. Comme le web n'a pas remplacé les apps de bureau du jour au lendemain ; il a grandi à côté d'elles jusqu'à devenir le défaut. **Identité et permissions.** Si les Objets se déplacent entre espaces et sont consultés par plusieurs personnes et agents, qui contrôle l'accès ? Cela se connecte directement à la primitive Personnes : les relations accordent des capacités, et ces capacités s'étendent à des objets précis. Votre collaborateur peut voir cette note mais pas celle-là. Votre assistant IA peut lire votre calendrier mais ne peut pas envoyer d'e-mails en votre nom. Les permissions doivent voyager avec l'objet, pas rester verrouillées dans l'app. --- ## Où cela mène Nous utilisons les ordinateurs pour travailler avec des *choses*. Notes, designs, documents, messages, plans, photos, musique, code. Ce sont les matières premières de nos vies numériques. Mais nous n'avons jamais construit un vrai concept de « chose » dans l'informatique. À la place, nous avons construit des *applications*, et enfoui les choses dedans. Puis nous avons construit des *services cloud*, et enfoui les choses encore plus profondément. Maintenant, nous nous souvenons à peine de l'endroit où vivent nos affaires, sans parler de les prendre et de les poser quelque part d'utile. La primitive Objet n'arrivera pas comme un protocole unique ou une nouvelle app. Elle arrivera comme un déplacement d'hypothèses : de « les choses vivent dans les apps » vers « les choses existent, et les apps sont une manière d'interagir avec elles ». Ce déplacement est déjà en cours, poussé en partie par les outils d'IA qui apprennent à entrer dans les silos d'apps et à en sortir les objets. La question est de savoir si nous reconnaissons ce déplacement pour ce qu'il est, et si nous construisons correctement la primitive — ou si nous le laissons se produire accidentellement pour finir avec une nouvelle génération de silos, cette fois avec l'IA comme gardien au lieu des apps. Les Objets veulent être libres. L'informatique ne les a simplement pas encore laissés faire. --- *Regent's Park · Note 005c · v0.1* *Dans la série des quatre primitives : Personnes · Espaces · Objets · Mémoire* 🌳