--- title: "Personnes : pourquoi sommes-nous dispersés entre comptes ?" code: "RP-0129" language: "fr" canonical: "https://regentspark.ai/fr/RP-0129/" html: "https://regentspark.ai/fr/RP-0129/" markdown: "https://regentspark.ai/fr/RP-0129.md" updated: "3 May 2026" --- # Personnes : pourquoi sommes-nous dispersés entre comptes ? *La première primitive manquante de l'informatique n'est pas l'authentification. C'est la personne.* Vous êtes une seule personne, mais votre ordinateur voit des dizaines de fragments : un compte Google, un Apple ID, un login professionnel, un profil bancaire, un contact WhatsApp, un membre Slack, un participant calendrier, une passkey, un appareil, une session de navigateur. Chaque application crée une ombre locale de vous et appelle cela identité. Le résultat n'est pas seulement agaçant ; il est structurellement faux. Les personnes ne sont pas des comptes. Une personne est un acteur persistant avec des relations, de la mémoire, une réputation, des permissions, et la capacité d'agir directement ou par délégation. Cet essai soutient que l'informatique a besoin des Personnes comme primitive : un graphe relationnel portable qui permet aux humains, organisations, agents et services de participer entre espaces sans être recréés de zéro par chaque app. ## Vous n'êtes pas vos comptes > **Résumé :** L'informatique confond les enregistrements locaux d'accès avec les personnes. Cela force chaque app à créer son petit fantôme de vous, puis vous laisse recoudre les fantômes à la main. Vous avez trop de comptes. Pas au sens abstrait, gourou de la productivité. Au sens quotidien, pénible, « où est ce foutu mot de passe ». Vous avez un compte Google, un Apple ID, un login Microsoft professionnel, un login bancaire, un compte de compagnie aérienne, une app de salle de sport, trois comptes de réseaux sociaux que vous utilisez vraiment, et six que vous avez oubliés. Quelque part là-dedans, vous avez un gestionnaire de mots de passe avec des centaines d'entrées, chacune étant une petite relation bureaucratique que l'on vous a forcé à maintenir. On décrit généralement cela comme un problème d'authentification. Les mots de passe sont mauvais. Les passkeys sont meilleures. Le single sign-on est pratique. C'est vrai, mais trop petit. L'absurdité plus profonde est que votre amie Sarah existe dans votre téléphone comme contact. Elle existe aussi dans WhatsApp. Et Instagram. Et le Slack du travail. Et les e-mails. Et le Google Doc partagé que vous modifiez ensemble. Tout cela est la même personne. Votre ordinateur n'en sait rien. Pour votre téléphone, Sarah-dans-WhatsApp et Sarah-dans-les-e-mails sont aussi étrangères l'une à l'autre que Sarah et une inconnue au Pérou. Vous êtes la couche d'intégration. Vous portez la connaissance que ces fantômes numériques fragmentés sont une seule personne, parce qu'aucun système que vous utilisez ne prend la peine de le faire. Ajoutez maintenant les agents. Vous parlez à un assistant sur votre téléphone. Il connaît vos préférences, votre calendrier, votre style d'écriture, votre plan à moitié terminé. Vous passez à votre ordinateur portable, ouvrez un autre outil, et l'assistant est amnésique. Même vous. Autre trou de serrure. Recommencez. Ce n'est pas un petit agacement UX. C'est le symptôme de quelque chose qui manque. L'informatique a des utilisateurs, comptes, profils, contacts, sessions, appareils, identifiants, wallets, clés et handles. Elle n'a pas de concept durable d'une personne. ```mermaid flowchart TD Person(("👤 Sarah")) Phone["📱 Contact téléphone"] WhatsApp["💬 Profil WhatsApp"] Slack["🏢 Membre Slack"] Email["✉️ Adresse e-mail"] Doc["📄 Collaboratrice Google Doc"] Calendar["🗓️ Participante calendrier"] Person -. "même humaine" .- Phone Person -. "même humaine" .- WhatsApp Person -. "même humaine" .- Slack Person -. "même humaine" .- Email Person -. "même humaine" .- Doc Person -. "même humaine" .- Calendar Phone -. "non lié" .- WhatsApp WhatsApp -. "non lié" .- Slack Slack -. "non lié" .- Email Email -. "non lié" .- Doc Doc -. "non lié" .- Calendar ``` L'important n'est pas qu'une base de données ait oublié de joindre quelques enregistrements. L'important est que chaque application croit avoir le droit de définir la personne localement. Elle ne reçoit pas Sarah comme participante d'un monde plus large. Elle frappe une entrée en forme de Sarah dans son propre royaume. C'est pourquoi quitter une plateforme ressemble à une petite mort bureaucratique. Vous ne perdez pas seulement des posts ou des fichiers. Vous perdez des relations, de l'histoire, de la confiance, des permissions et du contexte, parce que la plateforme a traité ces relations comme son propre état interne. Le compte n'est pas la personne. Ce n'est qu'un enregistrement d'une relation entre une personne et un service. ![Une personne entourée d'ombres en forme d'apps de la même relation](fr/content/RP-0129/illustrations/people-fragmented-accounts.png) > **Alt text:** Une personne au bureau relie par des fils plusieurs profils flottants représentant la même personne dans différents contextes. > **Description:** L’illustration montre une personne de dos assise au centre d’un bureau, occupant le premier plan, avec les bras levés comme si elle reliait des fils entre plusieurs fenêtres flottantes autour d’elle. À gauche, au centre, en haut à droite et à droite, plusieurs cartes rectangulaires semi-transparentes affichent chacune le profil en silhouette d’une même personne vue de côté, mais dans des contextes différents, reliées par des lignes fines qui convergent vers les mains de la personne centrale. Ces fenêtres suggèrent des fragments distincts d’une même identité, tandis que l’espace entre elles reste vide, renforçant l’idée de dispersion entre services ou contextes. En bas, sur le bureau, on voit des objets de travail simples — une pile de livres, un carnet ouvert avec stylo, une tasse, une petite plante et une lampe — qui ancrent la scène dans un environnement de réflexion ou de coordination. L’image communique qu’une personne unique doit recoller manuellement plusieurs représentations séparées d’elle-même. > **Image source:** fr/content/RP-0129/illustrations/people-fragmented-accounts.png ActivityPub distingue déjà Actors, Objects et Activities : une personne, une organisation, un service ou une application peut effectuer des actions sur des objets. Ce vocabulaire est un précédent utile, mais il vit surtout dans le réseau social fédéré. La primitive Personnes demande la version plus large pour l'informatique : des acteurs capables de se déplacer entre espaces, porter des permissions, construire une réputation et déléguer l'action à travers de nombreux types de logiciels. Voir l'ontologie des entités pour le relevé ontologique et les notes sur ActivityPub. ## Une personne est un graphe relationnel > **Résumé :** L'identité n'est ni un profil ni un nom d'utilisateur. L'identité est le graphe vivant des relations autour d'un acteur : ce qui est partagé, ce qui est mémorisé, ce qui est permis, et ce qui peut être fait. Vous avez déjà un meilleur modèle de l'identité que votre ordinateur. Vous êtes une personne. Vous le savez. Quand vous passez de votre cuisine à votre bureau, vous ne cessez pas d'être vous. Quand vous passez d'une conversation avec votre mère à une conversation avec votre patron, vous êtes toujours vous, mais une autre facette de vous est active. Autre histoire. Autres permissions. Autres attentes. Votre identité n'est pas un profil statique. C'est la somme de vos relations. Vous êtes : - la personne que votre mère appelle le dimanche - la personne à qui votre banque accorde une ligne de crédit - la personne à qui votre collègue écrit à propos du plan trimestriel - la personne que le barista reconnaît avant votre commande - la personne que votre médecin connaît par son dossier médical - la personne que votre assistant peut réveiller, interrompre, protéger ou représenter Chaque relation a une forme différente. **Ce qui est partagé :** votre mère connaît votre enfance ; votre banque connaît votre salaire ; votre barista connaît votre commande de café. Presque aucun chevauchement. **Ce qui est permis :** votre employeur peut vous inviter à des réunions ; votre banque peut débiter votre compte ; votre ami peut appeler tard ; votre dentiste ne peut pas lire vos documents de travail. **Ce qui est mémorisé :** votre mère se souvient de décennies ; votre banque se souvient des transactions ; votre collaborateur se souvient de l'argument qui a changé le design ; votre assistant se souvient de la préférence que vous avez répétée trois fois. C'est cela, l'identité. Un graphe de relations délimitées, chacune avec sa mémoire, ses permissions, sa réputation et ses obligations. Cela se connecte directement à la confiance aux arêtes. La confiance n'est pas un score universel attaché à un profil ; elle vit dans des relations spécifiques. Vous pouvez être digne de confiance comme vendeur, peu fiable comme participant à des réunions, aimé comme ami, et inconnu comme emprunteur. Aplatir tout cela en un profil détruit le contexte qui rendait la confiance signifiante. ```mermaid flowchart TD You(("👤 Vous")) Mother["Famille\nhistoire partagée, confiance élevée"] Bank["Banque\npermissions financières"] Doctor["Médecin\ncontexte médical"] Work["Employeur\nrôle + devoirs"] Sarah["Sarah\namie + collaboratrice"] Agent["Agent IA\nautorité déléguée"] Coffee["Café\nreconnaissance légère"] You -->|"peut appeler / connaît l'histoire"| Mother You -->|"peut effectuer des transactions / audité"| Bank You -->|"peut partager les données médicales"| Doctor You -->|"rôle pro + accès"| Work You -->|"mémoire partagée + confiance"| Sarah You -->|"agit en votre nom"| Agent You -->|"commande habituelle"| Coffee ``` Le monde physique gère cela presque sans effort. Vous entrez dans un café. Vous ne « créez pas un compte ». Vous êtes simplement là. Le barista peut vous reconnaître, ou non. S'il vous reconnaît, la relation s'active. Sinon, vous pouvez quand même parler. Vous pouvez pousser une demande dans le monde avant qu'une relation profonde existe. Mais vous ne pouvez rien tirer de privé sans permission. Vous pouvez dire bonjour à un inconnu. Vous ne pouvez pas lire son journal. Vous pouvez donner une carte à quelqu'un. Vous ne pouvez pas entrer chez lui. Le push est bon marché et sans permission ; le pull exige de la confiance. Les relations s'approfondissent aussi dans le temps. Vous rencontrez quelqu'un à une fête. Arête fine. Vous échangez vos numéros. Arête un peu plus épaisse. Vous travaillez ensemble. Une mémoire partagée s'accumule. Un jour, cette personne pourra vous présenter à quelqu'un d'autre, se porter garante de vous, ou vous donner accès à quelque chose de précieux. Le graphe social travaille pour vous. L'informatique jette surtout cela. Chaque app commence avec un nouveau compte et vous demande de reconstruire le graphe relationnel depuis zéro. Votre histoire ne voyage pas. Votre réputation ne voyage pas. Vos permissions ne voyagent pas. Votre amie ne voyage pas. Votre agent ne voyage pas. Vous n'entrez pas vous-même dans un nouvel espace. On vous remet une nouvelle carte d'identité à la porte de chaque bâtiment où vous entrez, puis on vous dit de commencer une nouvelle vie. Les systèmes juridiques comprennent depuis longtemps la « personne » comme catégorie fonctionnelle, pas biologique. Des sociétés, municipalités, navires, successions, et parfois des rivières peuvent être traités comme personnes à des fins précises : porter des droits, supporter des obligations, entrer en relation et être tenus responsables. Voir La personnalité au-delà de la biologie pour la version plus profonde de cet argument. Le point n'est pas que les ordinateurs devraient traiter toutes les entités comme moralement équivalentes. Ce serait absurde. Le point est structurel : une personne est une entité qui participe à un système par l'identité, les relations, les permissions, la mémoire, la réputation et la capacité d'agir. Cette entité peut être un humain. Elle peut être une organisation. Elle peut être un agent IA agissant au nom de quelqu'un d'autre. Elle peut être un service ou un appareil doté d'une autorité étroite. La primitive devrait pouvoir les représenter toutes sans prétendre qu'elles sont le même type d'être. ## Les comptes sont des ombres locales > **Résumé :** Les systèmes d'identité existants résolvent des morceaux du problème — authentification, portabilité, handles, preuve, fédération — mais aucun ne porte le graphe relationnel lui-même. Le paysage de l'identité n'est pas vide. Des gens essaient d'en résoudre des morceaux depuis des décennies. **Les noms d'utilisateur et mots de passe** sont le monde par défaut. Chaque service vous donne une identité locale dans sa base de données. Cette identité est facile à gérer pour le service et pénible pour tous les autres. Vous devenez une ligne dans le système de quelqu'un d'autre. **Se connecter avec Google ou Apple** réduit le nombre de mots de passe, mais centralise le graphe. Cela répond à « cette plateforme peut-elle garantir que vous êtes le même compte ? ». Cela ne répond pas à « pouvez-vous porter vos relations indépendamment de la plateforme ? ». La commodité s'achète en laissant quelques entreprises voir davantage de votre vie. **Les passkeys** sont une vraie amélioration. Elles rendent l'authentification plus simple et plus sûre en remplaçant les mots de passe par des identifiants cryptographiques adossés à l'appareil. Mais les passkeys prouvent l'accès à une relation ; elles ne portent pas la relation. Votre passkey Amazon est invisible pour votre banque, vos outils de travail, votre agent ou l'espace collaboratif de votre ami. **Les DID et Verifiable Credentials** visent l'identité portable et la preuve cryptographique. Les idées sont importantes. L'écosystème est aussi tentaculaire et difficile à livrer. Un standard peut décrire une identité portable sans rendre le graphe relationnel quotidien utilisable. **Nostr** prend la route radicale : vous êtes votre clé. Générez une paire de clés et vous avez une identité portable entre clients. C'est élégant et utile, mais mince. Une clé peut signer des messages. Elle ne résout pas à elle seule la récupération, la réputation, la divulgation délimitée, la mémoire relationnelle ou la délégation. **AT Protocol et le Fediverse** améliorent la portabilité dans les écosystèmes sociaux, mais restent surtout des systèmes d'identité sociale. Un handle Bluesky ou un compte Mastodon se déplace peut-être mieux qu'un ancien profil Facebook, mais il ne devient toujours pas la personne que votre banque, calendrier, agent, médecin et espace de projet peuvent tous comprendre. Pour le paysage large des précédents — Nostr, DID, ActivityPub, AT Protocol, World ID, passkeys, et la primitive Actor manquante — voir le paysage de l'identité. La conclusion importante ici est plus étroite : l'authentification n'est pas l'identité, et l'identité n'est pas encore un graphe relationnel portable. L'une des raisons pour lesquelles Nostr revient souvent dans les notes RP n'est pas qu'il résout magiquement l'identité. C'est qu'il prouve qu'une couche basse utile peut être radicalement simple : une clé signe des événements, des relais les déplacent, des clients rivalisent au-dessus. la pile Acteur explore comment cela pourrait se composer avec les paiements Lightning, l'état partagé CRDT et le contrôle d'accès par capacités. Ce chapitre reste délibérément un niveau plus haut. Chacun de ces systèmes résout un fragment. Authentification. Portabilité. Preuve. Handles lisibles par les humains. Fédération. Souveraineté. Récupération. Identité sociale. Aucun ne résout le problème central : ce qui fait de vous une personne vit dans les relations, et rien ne porte ces relations entre contextes. C'est pourquoi « exporter mes données » ne suffit jamais. Vos posts ne sont pas votre vie sociale. Vos contacts ne sont pas vos relations. Vos identifiants ne sont pas votre réputation. Votre archive de compte n'est pas le graphe vivant de ce que d'autres personnes savent, font confiance, permettent, se souviennent et attendent de vous. Un fichier ZIP téléchargé est un cadavre. Utile pour l'archéologie. Inutile pour la participation. ## Les agents rendent le manque impossible à ignorer > **Résumé :** Les humains peuvent contourner l'identité fragmentée en se souvenant, en copiant-collant, en s'excusant et en improvisant. Les agents ne le peuvent pas. Ils ont besoin d'identité explicite, de délégation, de permissions, de mémoire et de rails de paiement, sinon ils échouent. Pendant des années, cette notion cassée de la personne en informatique est restée survivable parce que les humains sont une excellente colle. Nous nous souvenons que Sarah sur WhatsApp est Sarah du travail. Nous copions du texte d'une app à l'autre. Nous réinitialisons des mots de passe. Nous transférons des captures d'écran. Nous expliquons le contexte. Nous accordons manuellement l'accès. Nous savons quand « Nico de Telegram » est le même Nico dont le calendrier dit « N S ». Nous vivons dans les fissures et faisons discrètement le travail d'intégration. Les agents sont mauvais à cela exactement de la manière qui expose l'architecture. Un assistant IA agissant en votre nom doit savoir : - qui il est - qui vous êtes - quelle relation il a avec vous - ce qu'il est autorisé à faire - dans quels espaces il peut entrer - quels objets il peut toucher - quelles personnes ou agents il peut contacter - ce qu'il peut mémoriser - ce qu'il peut dépenser - comment son autorité peut être révoquée Sans ces primitives, les systèmes d'agents deviennent des piles de clés API, de scopes OAuth, d'intégrations fragiles, de hacks de navigateur et de dialogues de confirmation humaine. Suffisant pour des démos. Pas assez pour un monde où des participants logiciels font un vrai travail ensemble. La partie difficile est la délégation. Si un agent réserve une réunion, envoie un e-mail, paie une facture, commente un document ou négocie avec un autre agent, de qui est-ce l'action ? Celle de l'agent ? La vôtre ? Celle de l'organisation ? La réponse ne peut pas être « ce que l'app courante a décidé d'implémenter ». ```mermaid sequenceDiagram participant You as Vous participant Agent as Votre agent participant Space as Espace de projet participant Sarah as Sarah participant Service as Service de paiement You->>Agent: Délègue l'autorité de planification Note over You,Agent: relation délimitée et révocable Agent->>Space: Entre comme participant délégué Space->>Agent: Accorde l'accès au calendrier + notes Agent->>Sarah: Propose des créneaux de réunion Sarah->>Agent: Accepte vendredi Agent->>Service: Paie les frais de réservation dans la limite Service->>Space: Enregistre l'action + preuve Space->>You: Montre ce qui s'est passé et pourquoi ``` C'est là que l'ancien langage d'« acteur » est utile. Tout participant en forme de personne n'est pas un être humain. Une entreprise peut agir. Un bot peut agir. Un appareil peut agir. Un assistant peut agir au nom de quelqu'un d'autre. Ce qui compte n'est pas la conscience. Ce qui compte est la participation avec identité, relations, autorité, responsabilité et mémoire. « Actor » ici ne désigne pas le modèle d'acteurs Erlang/Akka, même s'il y a un air de famille. Dans le langage de Regent's Park, un Actor est un participant persistant de l'informatique : quelque chose qui peut être identifié, mis en relation, recevoir une délégation, être jugé fiable ou non, et tenu responsable. La version technique de la pile vit dans la pile Acteur. Les agents rendent la primitive manquante urgente parce qu'ils ne peuvent pas s'appuyer sur des intuitions floues. Un humain peut inférer que « réserve l'endroit habituel » signifie le café près du bureau, pas le restaurant de sushi de l'été dernier. Un agent a besoin d'accéder à la mémoire relationnelle qui rend « habituel » signifiant. Un humain peut décider que transférer un message sensible est socialement mauvais même si c'est techniquement possible. Un agent a besoin de permissions qui encodent non seulement l'accès, mais le contexte. Si nous ne construisons pas Personnes comme primitive, chaque plateforme d'agents inventera son propre modèle de compte, son système de permissions, son silo de mémoire et son interface de délégation. Nous recréerons le marécage des comptes, mais cette fois avec des acteurs autonomes qui s'y promènent. Ce n'est pas un avenir. C'est un incident de conformité avec une UI. ## Ce que la primitive Personnes doit faire > **Résumé :** Une primitive Personnes n'est pas un profil global ni un login universel. C'est un substrat relationnel portable : identité plus relations délimitées, mémoire, réputation, délégation et récupération. La mauvaise réponse tentante est de construire un gigantesque système d'identité. Un profil. Un login. Un graphe. Un wallet. Un annuaire universel de tout le monde et de tout. C'est le piège de la super app avec un plus beau manteau. Cela centraliserait précisément ce que nous essayons de rendre portable. La primitive Personnes devrait être plus petite et plus basique. Elle devrait rendre les relations lisibles entre systèmes sans forcer tous les systèmes dans une seule base de données. Dit plus nettement : la primitive n'est pas un export de graphe. C'est une manière de reconnaître, porter, limiter, prouver et oublier les arêtes. Si tout ce que nous faisons est copier une plus grande liste de contacts entre apps, nous avons reconstruit le même marécage avec une meilleure papeterie. Une primitive Personnes utile doit préserver trois tensions à la fois : - **continuité sans captivité** — l'acteur persiste, mais aucune app ne le possède - **portabilité sans exposition totale** — les relations peuvent voyager, mais seules les affirmations pertinentes sont révélées - **délégation sans usurpation d'identité** — un agent peut agir pour quelqu'un sans prétendre être cette personne Au minimum, elle a besoin de six propriétés. ### 1. Identité persistante Une personne a besoin de continuité. Le même acteur devrait être reconnaissable entre espaces, appareils et applications sans être possédé par l'un d'eux. Cela implique probablement une identité cryptographique quelque part près de la base. Mais « utiliser une paire de clés » n'est pas la réponse à elle seule. Les gens perdent des clés. Les appareils cassent. Les familles partagent l'autorité. Les organisations font tourner les rôles. Les agents sont créés, mis en pause, délégués, révoqués et remplacés. La persistance doit inclure récupération et cycle de vie, pas seulement une chaîne permanente. ### 2. Relations délimitées La relation est l'unité qui compte. Vous n'avez pas une identité que tous les services devraient voir en entier. Vous avez différentes relations avec différents périmètres. Votre médecin, banque, ami, employeur, assistant et café local ne devraient pas tous recevoir la même vue de vous. Une vraie primitive Personnes doit permettre à chaque arête de porter ses propres permissions, mémoire, obligations et règles de divulgation. ### 3. Mémoire relationnelle Une relation sans mémoire est à peine une relation. Le système devrait se souvenir de ce qui s'est passé entre deux acteurs : confiance construite, promesses faites, échecs observés, permissions accordées, permissions révoquées, préférences apprises, contexte partagé. Cette mémoire ne peut pas être seulement locale à une app. Si Sarah et vous avez collaboré entre e-mails, docs, chat et espace de projet, la relation ne devrait pas être brisée simplement parce que le médium a changé. ### 4. Réputation aux arêtes La réputation n'est pas une note globale en étoiles. Elle est contextuelle. Quelqu'un peut être un designer brillant, un répondant lent aux e-mails, un payeur fiable, un mauvais participant de réunion et un ami de confiance. Aplatir cela en un score unique détruit précisément ce que la réputation est censée capturer. La primitive de réputation utile vit aux arêtes : ce que cet acteur a démontré dans ce type de relation, garanti par qui, visible sous quelles conditions. Scores de crédit, notes de plateformes, Web of Trust de PGP, verifiable credentials et réputation blockchain montrent tous différents modes d'échec de la confiance portable. La leçon récurrente de la confiance aux arêtes est que le contexte n'est pas une métadonnée ; le contexte est la confiance. Un bon système devrait permettre de prouver sélectivement une propriété relationnelle, pas d'aplatir la personne en nombre. ### 5. Agence déléguée Les personnes agissent par représentants tout le temps. Un avocat signe au nom d'un client. Un employé agit pour une entreprise. Un parent agit pour un enfant. Un assistant réserve un voyage pour une dirigeante. L'informatique a besoin de ce motif explicitement. Votre agent IA devrait pouvoir agir pour vous dans un périmètre borné. Votre organisation devrait pouvoir donner à un employé un accès pour un rôle, puis le retirer proprement quand le rôle change. Un service devrait pouvoir prouver qu'il agit sous autorité déléguée, pas qu'il prétend être la personne derrière lui. Les systèmes de capacités sont l'ancêtre technique ici. Au lieu de demander « qui êtes-vous ? » puis de chercher tout ce que vous pouvez faire, une capacité dit « le porteur peut faire exactement ceci ». L'ontologie des entités couvre le modèle de capacités de Dennis & Van Horn, le travail de Mark Miller et les tokens de style UCAN ; la pile Acteur applique le même motif aux acteurs participant à l'état partagé. ### 6. Portabilité sans exposition Porter les relations ne veut pas dire déverser toute votre vie dans chaque nouveau contexte. Une primitive Personnes devrait vous laisser apporter assez de vous-même pour être reconnu, digne de confiance et utile, tout en ne révélant que ce que la relation exige. Le graphe devrait être portable, mais la divulgation devrait être sélective. C'est la différence entre « venir avec soi-même » et « téléverser son âme ». Le premier est la civilisation. Le second est un chef de produit sans supervision adulte. La divulgation sélective compte parce que l'identité devient dangereuse quand elle devient échappement. Une banque peut avoir besoin d'une preuve de revenus ; elle n'a pas besoin de votre graphe d'amis. Un bar peut avoir besoin de prouver que vous avez plus de dix-huit ans ; il n'a pas besoin de votre date d'anniversaire. Un espace de projet peut avoir besoin de savoir que votre agent peut modifier le brief design ; il n'a pas besoin d'un accès complet à votre calendrier. Les Verifiable Credentials et l'effort EU Digital Identity Wallet sont pertinents ici parce qu'ils se concentrent sur la preuve sélective : présenter seulement l'affirmation nécessaire à une relation. Cela ne résout toujours pas la mémoire relationnelle ou la réputation, mais c'est un ingrédient important. Voir le paysage de l'identité et la confiance aux arêtes. ```mermaid flowchart LR Person(("Personne / Acteur")) ID["Identité persistante"] Rel["Relations délimitées"] Mem["Mémoire relationnelle"] Rep["Réputation contextuelle"] Del["Pouvoir d'action délégué"] Rec["Récupération + cycle de vie"] Apps["Apps"] Spaces["Espaces"] Objects["Objets"] Agents["Agents"] Services["Services"] Person --> ID Person --> Rel Rel --> Mem Rel --> Rep Person --> Del Person --> Rec ID --> Apps Rel --> Spaces Mem --> Objects Del --> Agents Rep --> Services ``` Remarquez ce qui n'est pas dans cette liste : un protocole imposé, un fournisseur, une base de données canonique, un graphe social universel, un wallet global, un score de réputation mondial. ![Une personne portant un graphe relationnel entre différentes pièces numériques](fr/content/RP-0129/illustrations/people-relationship-graph.png) > **Alt text:** Une personne centrale reliée par des lignes à plusieurs scènes distinctes représentant un contact, un médecin, une institution, une réunion et un agent robotique. > **Description:** L'image montre au centre une personne debout de profil, portant un manteau brun, qui sert de noyau à un petit réseau de nœuds colorés dans ses mains. Autour d’elle, cinq grandes « pièces » encadrées représentent des contextes distincts : en haut à gauche, une femme assise dans un salon avec une lampe, une plante et un tableau mural ; en bas à gauche, un médecin en blouse blanche assis avec une tablette dans une chambre ou un cabinet ; en haut à droite, un homme derrière un large bureau dans un bâtiment institutionnel à colonnes ; en bas à droite, deux personnes en réunion autour d’un ordinateur portable ; et en bas au centre, un petit robot dans une niche bleue. Des lignes courbes relient la personne centrale à chacun de ces contextes, en partant de points de couleur différents, ce qui suggère une même personne connectée à plusieurs rôles ou services. Le dessin communique l’idée qu’une seule personne traverse plusieurs espaces sociaux et techniques, mais que chaque espace ne voit qu’une facette locale de cette personne. Il n’y a pas de labels textuels lisibles dans l’illustration elle-même, seulement des scènes et des liaisons qui structurent le sens. > **Image source:** fr/content/RP-0129/illustrations/people-relationship-graph.png La primitive n'est pas un produit. C'est la forme que de nombreux produits et protocoles devraient pouvoir partager. ## Ce que cela change > **Résumé :** Une fois que les Personnes existent comme primitive, les Espaces deviennent des lieux avec participants, les Objets ont des histoires d'usage et de propriété, la Mémoire s'attache aux relations, et les agents peuvent agir sans prétendre être des extensions de navigateur anxieuses. Les Personnes sont la première primitive parce que les autres ont besoin d'acteurs. Un Espace sans Personnes n'est qu'un contenant. Ajoutez des Personnes et il devient un lieu où des participants peuvent entrer, sortir, se souvenir, collaborer, accorder l'accès et partager la responsabilité. Un Objet sans Personnes n'est que de la donnée. Ajoutez des Personnes et il peut avoir un auteur, propriétaire, steward, lecteur, signataire, acheteur, vendeur, témoin et historique d'usage. La Mémoire sans Personnes n'est qu'un log. Ajoutez des Personnes et la mémoire devient contextuelle : qui a décidé, qui s'est opposé, qui était présent, qui est autorisé à savoir, à quelle relation cela appartient-il ? Les Agents sans Personnes ne sont que des outils dans des comptes. Ajoutez des Personnes et les agents deviennent des participants délégués avec identité, périmètre, réputation et responsabilité. Cela n'exige pas que toutes les apps disparaissent. Bien au contraire. Une primitive Personnes devrait rendre de nombreuses applications plus utiles en les laissant cesser de prétendre qu'elles possèdent tout l'humain. Un calendrier peut être un calendrier. Une banque peut être une banque. Un outil de design peut être un outil de design. Un espace de projet peut être un espace de projet. Chacun peut entrer en relation avec les mêmes acteurs sous des périmètres différents sans frapper une identité de remplacement complète. Ce qui change, c'est le substrat en dessous. Aujourd'hui, les apps demandent : « Créez un compte. » Un meilleur système demande : « Quelle relation sommes-nous en train de former ? » Ce seul changement recadre tout. Le login devient reconnaissance. Les permissions deviennent des arêtes négociées. La réputation devient contextuelle. Les agents deviennent des délégués. La collaboration devient participation dans un espace partagé, pas captivité synchronisée dans une app. C'est pourquoi Personnes n'est pas simplement une primitive d'identité. C'est la couche acteur de l'informatique. L'ordinateur devrait savoir ce que vous savez déjà : vous êtes une seule personne, les personnes dans votre vie sont réelles, et les relations devraient survivre au logiciel qui se trouve les médiatiser.