Chapitre 6 : Principes de conception

La conception de TP s'articule autour de cinq principes fondamentaux. Ces principes guident non seulement la conception technique du protocole lui-même, mais définissent également les standards de comportement que tous les participants de l'écosystème TP devraient suivre.

6.1 Cognition partagée plutôt que transmission de messages

Le principe de conception primaire de TP est : dans la mesure du possible, privilégier l'établissement d'un espace cognitif partagé plutôt que de s'appuyer sur la transmission sérialisée de messages. Le modèle de transmission de messages introduit des pertes d'encodage, de la latence de transmission et de l'ambiguïté sémantique à chaque tour d'interaction ; le modèle de cognition partagée permet aux parties collaborantes d'accéder directement aux mêmes ressources cognitives, éliminant fondamentalement la friction du transfert d'information. Ce principe ne nie pas la valeur de la transmission de messages — l'établissement de l'espace partagé lui-même nécessite une négociation par messages — mais il définit clairement la direction de conception de TP : minimiser la sérialisation et désérialisation inutiles.

Exemple concret : Deux Fays collaborent au traitement d'un sinistre d'assurance automobile. Sous le modèle de transmission de messages, le Fay d'assurance doit envoyer le rapport d'accident complet, les photos, les informations du véhicule et les détails de la police au Fay d'évaluation... chaque tour de communication implique l'empaquetage et la transmission de grands volumes de données. Sous le modèle de cognition partagée, les deux parties établissent un contexte partagé où le rapport d'accident, les photos et les informations de police sont montés dans l'espace partagé. Le Fay d'évaluation consulte et annote directement dans l'espace partagé, et le Fay d'assurance voit les résultats d'annotation en temps réel — l'ensemble du processus est comme deux experts en sinistres assis au même bureau examinant le même dossier.

6.2 Agnosticisme de transport

TP se concentre sur la couche sémantique, pas sur la couche de transport. Les messages TP peuvent être délivrés via le JSON-RPC d'A2A, le tool call de MCP, des APIs REST traditionnelles, ou même des Prompts en langage naturel. Ce principe garantit que TP n'est pas lié à un seul protocole sous-jacent ; quand de nouvelles méthodes de transport émergent, TP n'a besoin que d'ajouter un adaptateur de transport sans modifier les définitions sémantiques propres du protocole. L'agnosticisme de transport signifie également que TP possède intrinsèquement une compatibilité ascendante — il peut s'adapter à des protocoles de transport qui n'ont pas encore été inventés.

Exemple concret : Un Fay d'entreprise fonctionnant dans le cloud doit communiquer avec un Fay fonctionnant sur un appareil en périphérie (comme une passerelle de capteurs d'usine). Le Fay cloud supporte nativement A2A, mais l'appareil en périphérie n'a qu'une simple API REST. L'agnosticisme de transport de TP permet aux deux parties de communiquer sans se soucier des capacités de transport de l'autre — TP s'adapte automatiquement, et l'intent envoyé par le Fay cloud via A2A est traduit de manière transparente en un appel API REST délivré à l'appareil en périphérie.

6.3 Négociation adaptative de protocole

Dans un écosystème AI hétérogène, différents Fays peuvent « parler » différents langages protocolaires. TP n'exige pas que tous les participants utilisent un protocole de transport unifié ; au contraire, grâce à un mécanisme adaptatif de négociation et de traduction, il permet aux Fays avec différentes « langues maternelles » de communiquer de manière transparente. Le processus de négociation comprend trois étapes — sondage des capacités, négociation de contrat et mapping sémantique — garantissant que l'intention n'est pas perdue lors de la traduction inter-protocoles. Ce principe abaisse la barrière d'entrée à l'écosystème TP — tout Fay supportant au moins une méthode de transport peut participer à la communication TP.

Exemple concret : Le Fay RH d'une entreprise multinationale doit interfacer avec les coFays de sécurité sociale de différents pays. Le coFay de sécurité sociale américain utilise A2A, celui du Japon utilise MCP tool call, et celui de l'UE utilise l'API REST. Le Fay RH n'a pas besoin d'écrire du code d'intégration différent pour chaque pays — TP sonde automatiquement les capacités protocolaires du distant lors de l'établissement de la session, négocie une méthode de transport supportée par les deux côtés, et toute la communication ultérieure est complètement transparente.

6.4 Souveraineté du Host sur la vie privée

Dans la vision du monde iFay, chaque Fay agit au nom d'un Host. Par conséquent, le Host a une souveraineté absolue sur ses données. Un Fay ne peut pas décider unilatéralement quelles ressources cognitives partager — chaque divulgation de données doit se produire dans les limites pré-autorisées par le Host. TP garantit que les données privées du Host sont toujours protégées pendant la transmission et l'accès grâce à un triple mécanisme de chiffrement de bout en bout, de divulgation sélective (SelectiveDisclosure) et de credentials de rappel à durée limitée (CallbackCredential). Le Host peut révoquer l'autorisation à tout moment, mettant fin au partage de données.

Exemple concret : L'iFay d'un utilisateur demande un prêt auprès d'un coFay bancaire en son nom. La banque doit examiner la preuve de revenus et l'historique de crédit de l'utilisateur, mais l'utilisateur ne veut pas que la banque voie ses détails de dépenses et son portefeuille d'investissement. L'utilisateur spécifie explicitement lors de l'autorisation que « seuls les relevés de salaire des 12 derniers mois et le score de crédit peuvent être divulgués », et l'iFay n'expose que ces deux éléments via le mécanisme de divulgation sélective. Après l'approbation du prêt, le callback credential expire automatiquement, et le coFay bancaire ne peut plus accéder à aucune donnée utilisateur. Si l'utilisateur change d'avis en cours de route, il peut révoquer l'autorisation à tout moment, mettant immédiatement fin au partage de données.

6.5 Frontières de confiance auditables

La confiance n'est pas aveugle — elle doit être construite sur une base vérifiable. TP exige que toutes les opérations impliquant l'accès aux données privées, l'utilisation de credentials et la communication inter-Fay soient auditables. Les enregistrements d'audit contiennent le type d'opération, les identités des participants, les horodatages et le périmètre d'accès, mais n'incluent pas le contenu réel des données ni le texte en clair des tokens de credentials. Le Host peut consulter le journal d'audit à tout moment pour comprendre qui a accédé à ses données, à quel moment et dans quel but. Ce principe garantit que la confiance au sein de l'écosystème TP est transparente et traçable.

Exemple concret : L'iFay d'un patient a interagi avec un coFay médical, un coFay d'assurance et un coFay de pharmacie plusieurs fois au cours du mois dernier. Le patient peut ouvrir le journal d'audit et voir des enregistrements comme : « 3 avril, 14h23 — Le coFay médical a accédé à votre historique d'allergies (périmètre autorisé : données liées au diagnostic) », « 5 avril, 09h15 — Le coFay d'assurance a accédé aux codes de diagnostic et à la ventilation des coûts via callback credential (credential expiré le 5 avril, 17h00) ». C'est comme consulter l'historique des transactions d'un compte bancaire — chaque « transaction de données » est documentée.